I'll spare you from a detailed explanation of why I bothered with this. It stemmed from lengthy discussion with one of my nephews. It's my own view of the stages/phases most American men go through in life. I'm spread between stage 7 and 10
Pre-teen
Early teens (single, pre-dating)
Late teens (single+dating)
The 20s (single or domestic partner)
30 and Single, or Married w/no Kids
First Child: Baby..Toddler
Child pre-teen
Child early teen
Child late teen
Child becomes yound adult (20s)
Child has kids: Grandparent stage
Retirement stage
Elder stage
What's interesting to me is that it seems that people in one stage are immune to unsolicited advice from other stages. Each stage feels they have it the hardest in life and that no other stages can understand their struggle, even if the others are in later stages.
So I map a drive letter to my server "music" share and add the songs to my iTunes library. Then I replace my server and remap the drives to the same share names. iTunes doesn't like it. It ignores M:\ and somehow stores the UNC path behind the mapping. It's too God-Damned stupid to figure out the song is in the same place on the same drive letter as it was before. Windows Media Player can figure that out. Hell, even WinAmp could do that 10 years ago! Apple doesn't hire the brightest people, just the ones who dress the part.
I've explained this to users for almost 15 years. I'm a bit tired of it, so I'm going to say it "here" one more time and then that's it. No more. After that I'm just going to point inquisitors to this site and tell them to "enjoy!"
AutoCAD drawings are structured in a quasi-database hierarchy. Among the many types of things inside a drawing file (.DWG file) there are entities, such as LINE, ARC, CIRCLE, ELLIPSE and TEXT entities. Another thing is "tables", which are essentially logical groups of things like LAYERS, DIMSTYLES, text STYLES, BLOCK definitions, and so on.
Entities refer to tables for things like what Layer they're on, what color and linetype they have (if not "by layer"), linetype scale, dimension style, text style (which in turn dictates the font, weight, size and so on), and that sort of stuff.
As things are created or inserted into a drawing, they bring along the relevant table information (if it's not already present in the current drawing). So if you insert a DWG as a BLOCK INSERT which includes entities on layer "FUBAR" which is blue, but the current drawing doesnt' have that layer, then that layer is also imported. If that layer already exists, but the color is green, the entities in the block insertion on layer "FUBAR" will be green.
So when you delete entities from your drawing, the table entries do not go away automatically. They remain. Using the preceding example, if you wanted the entities on layer "FUBAR" to insert and bring along their original layer properties, you would first need to clear out layer "FUBAR" from your current drawing. If entities in your drawing are using that layer, well, you can't clear out the layer. But if NOTHING refers to that layer, then you can remove it using the PURGE command.
Sometimes you have to purge multiple times to remove nested table references. By that I mean when you have a block insertion that contains a block insertion with another block insertion inside that. You get the idea. You explode the first block, but that leaves another block with a nested block. If you explode all of them (or programmatically reach into them and change their nested properties), and reset all of their entities to some other layer, and nothing refers to "FUBAR" anymore, then "FUBAR" can be purged.
WARNING: There may be some strong language used in this article.
I used to like to run (ok, jog), but my knees and hip joints don't like it anymore, so I bicycle. I usually make two or three rides per week, depending on circumstances, weather, etc. One of my favorite rides is the Cape Henry Trail. A roughly six-mile trek which consists of a mile of asphalt pathway going through a nice neighborhood, followed by a mile of asphalt through woods near a campground, followed by dirt through heavy tree cover. I usually get on the trail at Great Neck Rd and arrive at the end by 64th Street and Atlantic Ave a short time later (i haul ass usually in top gear the whole way).
Today however was different. The trail was loaded with joggers. Groups. Singles. Pairs. Whatever. As I approach them from behind, I always call out "passing left!" and say "thank you!" when they move over as I pass. Some behavioral patterns I noticed today:
Women share the path and are usually very courteous
Older men are usually courteous and share the path also
Younger guys jogging alone move over (no courtesy)
Younger guys in groups are dickheads and don't move, so I help them move over (I'm six feet tall and 200 lbs. Most joggers are barely 140 lbs and 5ft 7in or so. Do the math, and do it fast cuz I'm approach very fast)
Here's a few observations with comments as well:
Most joggers are white. Almost all of them.
Most of them spend a significant amount of money on special jogger clothing, and jogger shoes.
Most of them look other joggers up and down to assess their jogger clothing and shoes.
Most of them jog to be seen, not to really boost their health.
Most of them spend too much time worrying about their diet
I hate to bust your bubble but…
Not too many white folks win the Boston marathon, the NYC marathon, the SF marathon, the Chicago marathon, the, well, ANY marathon
It's usually some guys from Kenya, Ethiopia, Zimbabwe, or Morocco
Those guys don't spend shit on jogger clothing
Those guys don't spend shit on jogger shoes. In fact, some of them run ALL DAY EVERY FUCKING DAY BAREFOOT
They don't pause to look other joggers up and down to judge their clothing. They only look to see if you're in their way, which you are only possibly in their way at the very start of the race. After that you're a distant memory.
Most of them only care about one dietary aspect: IS THERE ANY FOOD.
The jogger clothing doesn't do shit. The jogger shoes don't do shit. The energy bar and vitamin pills don't do shit. The special drinks don't do shit. It's YOU that has to take the blame for doing shit.
So, as a proof of concept, a few months ago I setup a lab with the following ingredients:
A Windows Server 2008 AD domain controller
A Windows Server 2008 App-V / File server
A Windows 7 client
App-V packages for Office 2007, Paint.NET, FireFox
Group Policy Preferences: Drive Mappings, Desktop Shortcuts (to the server-based App-V shortcuts)
Net result:
Take a new computer, load it with Windows 7, join it to the domain. Reboot it. When the first user logs on they have all their drive mappings and shortcuts to the applications (the shortcuts appear as if they're already installed). When they double-click a shortcut, the App-V client briefly says it's caching the package and then it launches like a normal installed application. After that, it essentially *is* a normal installed application (after being cached once).
Almost zero-touch.
Add to this MDT and SCCM with OSD and you can absolutely have "zero-touch" deployments. Yes Virginia: It is possible.
This is obviously a basic setup and wouldn't work in a business environment without some adjustments and tweaking. But with Group Policy Preferences and Item Level Targeting, you can tailor policy settings to specific groups or computers with minimal effort. It can also help to determine which applications should be in the layer "0" image (WIM+sequence), and which should be in layers "1" and higher, and let Group Policy and App-V handle those. Keep in mind that applications which are managed by their own concurrent licensing service (think FlexLM and FlexNet Manager) can be deployed in layer "0" using a sequence and you can avoid pushing 10 Gb packages over the network (think Autodesk 3DS Max, Civil 3D or Inventor).
To me, this is where Microsoft shines, and they rarely get credit from mass media for how much they've accomplished at such a relatively low cost. If we were still on IBM and DEC technology it would cost millions of dollars to do this. Microsoft made it possible to do this for even the largest companies for basically chump change.
The WSUS Team blog posted an announcement regarding a new category to be added within the Drivers category which will be called "Important". I'm glad they did this and it will be a huge benefit to anyone using WSUS to update drivers. Until now, it's been a vast sea of murkiness. This should help bring the meaningful ones to the front and help admins out greatly. They also reminded us how you can import your own drivers into WSUS if needed. Nice to be reminded of that. Below is a copy of the original blog post…
WSUS Admins –
We would like to notify you of a change you will see starting next week. If your WSUS settings are configured to synchronize the “Drivers” update classification then your server will start syncing drivers designated as “Important.”
Important drivers are ones known to address a critical issue. Typically they fix a reliability issue that impacts use of the device or stability of Windows. Important drivers are subject to additional scrutiny and testing, relative to drivers offered optionally through WU to unmanaged clients. For more information, refer to the Windows Logo Program criteria for Important driver updates.
In the past, we heard feedback from the WSUS community that too many drivers for variants of similar hardware were crowding the admin consoles, because the drivers appeared identical in the admin console. Because of this feedback, we temporarily stopped targeting drivers to WSUS servers. We developed a solution to consolidate drivers that are applicable to multiple Plug and Play (PNP) IDs into a single driver update for you to manage and distribute. This drastically reduces the number of driver updates that need to be published, while ensuring you are receiving the latest driver updates that are proven to fix known issues. Even with this improvement, you will still see multiple driver updates for the same changes in some scenarios, but this should be less burdensome than before.
Which of these network environments is safest from malicious damage?
Site A: - web mail sites are blocked - social networking sites are blocked - cd/dvd-rw drives are not controlled - usb devices are not blocked or encrypted
Site B: - web mail sites are not blocked - social networking sites are not blocked - cd/dvd-rw devices are automatically encrypted or blocked (if not encrypted) - usb devices are automatically encrypted or blocked (if not encrypted)
Ok, and for added entertainment, see if you can pronounce the title of this article out loud ten times as fast as you possibly can (without screwing it up).
If you ask most people "on the street" what they consider to be the "ultimate crime", you can probably guess what they would say in response:
Murder
Rape
Arson
Robbery
etc.
I disagree. The most serious, and damaging crime is to subvert Mother Nature.
Before you knee-jerk: Hear me out, please...
I'm sure your first thought was about the big oil spill mess, or saving the rain forests, or recycling, or air and water pollution, etc. Nope. Not even close.
The biggest crime, the ultimate crime, is thwarting Nature's proven organic process of weeding out the STUPID. Yes. The STUPID. Nature normally takes care of eliminating the stupid. It keeps the population of stupid in check.
Modern mankind not only saves the stupid, we protect and even embolden the stupid. We often praise them. Let's compare how Nature handles the Stupid, versus how modern (e.g. "Western") civilization handles them...
Fails the First Grade aptitude test
Nature: Let's them fail, walk into oncoming traffic and be killed or eaten by hungry animals
Sociey: Either gives them a free pass, or allows for unlimited re-takes until they pass
Pours hot coffee in their own lap
Nature: Leaves a scar and educates idiot not to be careless with hot coffee
Society: Let's the idiot sue the person serving the coffee, the coffee company, and the company making the coffee cups
Crashes a private airplane while flying intoxicated
Nature: Let's weeds grow over the rusted wreckage and feeds the stray animals and birds
Society: Allows pilot's family to sue aircraft maker, flight controllers, suppliers of parts to build aircraft, liquor company and the property owner (for putting the ground in way of the falling aircraft)
Sprays can of deoderant into their own eyes
Nature: Happily accepts another blind person to join the growing flock of food for wandering hungry animals.
Society: Allows person to sue deoderant manufacturer and requires labels on all spray cans to warn of spraying into eyes.
Follows incorrect GPS directions to a missing bridge or into oncoming traffic
Nature: Adds another idiot to the fertilizer club.
Society: Allows person to sue GPS maker, map content supplier, bridge owner and person driving oncoming car. Person uses money to buy a mansion, a Ferrari, and starts a reality TV show on MTV.
Homeowner shoots unwanted intruder after they break in through window at night
Nature: Provides a handy target for shooting practice and fertilizer for homeowner's backyard garden
Society: Sues homeowner, takes house and gun and pays restitution to intruder for remaining years of life
Girl is upset by being sent home for wearing a thong and high-heels to her 3rd grade class
Nature: Eliminates them with AIDS or excessive repeat pregnancies.
Society: Creates a special classroom for these kids and forces all others to learn to appreciate yet more cultural diversity.
Boy expelled from school for bringing weapons
Nature: Accepts another ditch-digger.
Society: Sends him to sensitivity class for a week and then returns him to school. Later on, boy writes book and after describing it to Oprah, ends up on the NYT best seller list and he retires young and wealthy.
More examples?
Swallow too many pills and become a vegatable? Sue the pill maker
Drop a hammer on your foot? Sue the hammer maker
Doctor says you need to lose weight? Sue the doctor for defamation of character and psychological trauma
Seat too small on airplane? Sue for weight discrimination
Eat a can of dog food and get sick? Sue the dog food maker for failing to put bigger labels on the can.
Person can't spell, or pronounce words properly, wears underwear in public and drinks Malt Liquor for breakfast? Give them a reality TV show.
Why is it that nobody seems to be able to describe or explain "Object Oriented Programming" worth a shit? I'm serious.
During seven years of college (ok, 2 years for my AAS, and 5 for my BS, I can add, and my loans sure add up, but nevermind) all of the courses and textbooks and lectures tried to clear this up, over and over again. None of them hit the nail on the head. None. Nothing I've read since then either has done much to really clear this up or serve as the official definition for all levels of understanding and background.
Here's where they fail: They attempt to describe the concept to what they think is a target audience of programmers. A very bad choice.
I get it, as do most programmers, but then again: we're programmers. If you can't state the definition to someone who has NEVER programmed, what OOP means in ONE sentence, and they nod in complete and total understanding, then this is still unfinished business.
Anytime you want to explain something "clearly", think of your target audience as a room full of senior citizens who just consumed their daily dose of sedatives and laxatives and are lounging around the TV room waiting for their worthless kids to never visit (unless they need to discuss legal or financial matters, of course). These are the people you need to inform and impress. Pay attention, this will show up again in your life. Imagine the following conversation in a room of these people. One of them asks "what is 'object oriented programming' Jimmy?" (you're Jimmy of course)...
You respond: "Well George, it's where you define things in 'classes' and then 'instantiate'..." BANG! conversation is over. They already drifted off. Either towards the Wheel of Fortunate chatter on TV across the room, or just went comatose on you. You can snap your fingers, poke or pat their arm, or even straddle their wheelchair and grab their head with both hands and shake them like a paint can machine. It's not going to help. See that picture above? That's your audience. Start practicing.
This article on "Object-Oriented PHP for Beginners" written by Jason Lengstorf, on NetTuts (link: http://net.tutsplus.com/tutorials/php/object-oriented-php-for-beginners/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+nettuts+%28NETTUTS%29&utm_content=FaceBook) is very good, but it also joins the long list of nails whose heads have been left unscathed by the hammer of clarity. (Damn! That was a clever line. Hold on... I have to basque in the glory of having thought of something cool like this....I should copyright it. Ok, I'm back.) Near the beginning of this article, the author provides a quote box with the following OOP definition: "Object-oriented programming is a style of coding that allows developers to group similar tasks into classes."
This is 2010. Holy shit! WTF is that?! If a "programmer" doesn't know the definition, or at least a rough idea, of what OOP is, they are also likely new to programming in general. If you're talking to a noob, that statement doesn't cut it. This is exactly what I'm talking about. I am not picking on Jason here, he really is not to blame, and his article is very good indeed. The institutions of programming and training are to blame. Authors and instructors are to blame.
Programmers have an extremely tough time correlating tangible concepts to intangible concepts. At least those that are classically trained. Those that are self-taught often possess a good grasp of the conceptual relationships, but struggle to verbalize it to novices. It's one of those "I can drive there, but don't ask me for directions" kind of things. Let's face it, a lot of cooks can make awesome dishes but are incapable to sharing the details on how they're made. "A little of this" and "a little of that" don't really mean much to someone new to cooking. We need "a quarter teaspoon of this" and "2 cups of that".
So, you ask, "Why don't YOU attempt to correct this, Mr. Know-it-all? Hmmmm!?" I didn't say I have the answers. I just said that none of the other answers are worth a crap.
I did however attempt to employ my 11 year old son as a test subject (he calls it being a victim, but whatever). He was poking around learning Javascript because his friends told him it was the key to hacking his favorite online games. So he got a book at the library and started tinkering. I have no idea where this came from, but I was impressed of course. He got to the chapter on "OOP" and ran into the expected confusing blob of words that makes no sense to anyone except seasoned programmers.
I'll spare you the details, but essentially I used the common 'People' class example, with one of his friends 'Mark' as the object instance of the 'People' class. That was so-so. Then I used the 'vehicle' class example, with 'automobile' sub-class, 'chevy' sub-class, and my truck as the object (with a specific VIN to identify it from other trucks). He quickly reminded me that I sold the truck a year ago, so I had to back up and use the Subaru example.
He got the idea but it was almost as awkward and painful to get through as describing the birds and bees to him. Come to think of it, birds and bees could be an example for OOP, but only when they hit their teens. I'm sure he'd quickly raise his hand and ask how birds and bees are related at all, which is a good point. Someone should have used "bees and flowers" instead. Oh well. The point here is that OOP is tough to explain, clearly, in purely intangible terms. It always leads to using tangible metaphors and analogies, and then trying to stitch that together with a painfully clumsy jump to the intangible side, and that's like watching Gilbert Gottfried running a 100 meter hurdle race.
Like I said: I don't have a good answer. I'm just begging someone with literary skills, a decent grasp of OOP and an ability to think tangibly and intangibly, to take a better stab at this than I (or anyone else thus far) has been able to accomplish. Please. For the good of all nerdkind.
My kids often ask me to explain what a particular job title means and what it implies as far as duties performed. It's kind of funny, to me anyway, how titles have evolved (or devolved) over the past 30 years. Some have been deprecated, while new ones have emerged and been adapted into yet newer ones. But don't be fooled, here's what they really mean:
Technician – A low-level grunt doing the crap work for menial pay. It doesn't matter if it's health care, information technology, shipping, security, or office work. It's the lipstick on the pig to make the worker feel better about being lower than they think they really are.
Associate – Same as a technician only less lipstick on the pig.
Engineer – One of the most over-used title enhancements ever. Especially since the late 1990's. It simply means you have power to delegate work to technicians and associates, but you don't have any real managerial powers.
Representative – Lower than an associate
Assistant – An associate assigned to work for one person only.
Clerk – An assistant who the company doesn't feel worthy of making them feel important enough to call them an associate or technician.
Specialist – Same as an associate, only that it usually comes with more restrictions on the role or duties. An associate gets pulled into odd jobs more often than a specialist does.
Vice President – This was once referred to as a department or division manager. While it once held great meaning, since there were relatively few of them in a given company, these days there are often dozens of them in a company.
CxO – Unless it's CEO, CFO, COO, CIO or CTO it usually means the CEO, CFO and COO wanted the person to feel important even though they don't really get invited to the same strip clubs, poker games and golf outings.
President – Usually the same as the CEO. Some companies make a distinction, many do not, and many times it's the same person as the CEO. It's also often a landing position for a former CEO or founding member of the company.
Analyst – someone paid to analyze things and delegate the fixing to a technician or specialist. In some cases the analyst IS the technician, but the title is granted to make them feel better about doing two jobs for the pay of one.
I'm officially declaring an end to getting involved with public-facing web sites. Done. The customers that approach me for quotes, advice, etc. are becoming the same people that hang around yard sales. It doesn't matter if they're doctors, lawyers, real estate brokers, modeling agencies, retirement planners, or whatever. It's now all the same. The customers I deal with on intranet portal projects are entirely different, and much more reliable and trustworthy. So if you happen to be one of my past customers on a public-facing web site project, don't take it personal. I'm just over it. If you want a flashy, cute, CSS-golly-gosh web site, with animation junk, with 10 pages all for $50, go buy a template or hire one of a bazillion teeny-bopper web coders that flood the market. If you want a serious web application to empower your business, I'm all ears.
In smaller environments, the biggest obstacle to completing a successful software project is resources. Budget. Time. Materials. And by "smaller", I mean environments where there's no need (or desire) for layers of bureacracy between those that ask for things and those that provide them. I'm aware of all sorts of technical definitions for "small" and "large" in the business world, but let's face it: they are all subjective and contextual.
Having spent quite a few years in "small", "medium" and "large" environments, I have been lucky enough to have experienced the challenges and benefits each entails. To break it down in tabular style…
Small
Medium
Large
Biggest Challenge
Resources
Direction
Disconnect
Team Size
Usually Individual
2 or 3 at most
May be a department
Communication
Face-to-Face
Mixed
E-mail, MS-Project, ERP system, Visio, IM, WebEx, etc.
Frameworks
Industry Trends
Best Practices
Procedural and Instruction based
I could go on, but you get the point. And to be fair, it's not just a series of burdens brought forth by the software folks. No. It's also often equally matched by the customer or "user" side. It's not uncommon in the "large" environments to have customer "points of contact" (POC) or "customer lead", etc. They may in turn employ a hidden team of "power users" that help steer the requirements, do the testing and provide the final feedback. All of that being channeled (usually) through the POC. I tend to see this arrangement as a match-up of two pyramids with link between the two pinnacles. Then again, my head is pointy anyway, so that could be affecting my view.
The Handicaps of the Extremes
Whatever else may come into play, from what I've seen, the single biggest handicap to each of the "small" and "large" environments is almost a direct "fit" for the other. Where one excels, it is the answer to the other's failing.
For "large" environments, the problem is disconnect between participants in the project. From developers, to team leads, to project managers, to liaisons on both sides, to POC's to power users, to customer management, and (on both sides) back to the financial stakeholders. The comments you may likely hear from any one of those at any given time may be something like "I haven't had time to do my job *AND* keep ___ informed.". With the current economic downturn, and reduced or capped staffing levels, this is only becoming more common.
For "small" environments, the problem is often a lack of planning for the "long haul". Because projects are often staffed to the bare minimum, even single people doing each job function, there is a tendency to focus on the "hear and now". The drawback is not thinking out ahead to the next version, next quarter, or next year. Things may suffer such as documentation, code modularity, refactoring, and general optimization for future extensibility.
The best comparison might be the Tortoise and the Hare. The large environment is often MUCH slower to execute than the small environment. The small environment is often much shorter on long-term planning. One builds a product that will likely last and be more stable and reliable at 1.0. Yet the other oftens gets 1.0 out the door faster, and even with more defects, is more capable of making on-the-fly fixes to improve stability. However, the challenges remain, and need to be addressed.
The Speed Bumps
The biggest barrier to all of this is the entrenched views people have. It's pervasive regardless of rank. Managers, group leaders, and workers alike, all tend to have persistent, stubborn views about the other side. Teams in larger environments often scoff at the methods of smaller environments as "wild west show" or "shooting from the hip". Yet smaller teams often scoff at the methods of larger environments as "stodgy", "boring", "slow" and "inflexible".
A closed mind is not unique to just one side of this either. A small environment usually means being hostage to one developer with one view of how problems can be solved. A large environment usually means many more people, but no less flexible in their approach to solving problems. One is personal. The other institutional. Same problem.
They're both right. And they're both wrong. There are aspects to each "side" that can be of incredible use to the other. All it takes is a willingness to explore them, and a rigorous communications path throughout to foster it going forward.
Solutions
Believe it or not, the solutions to each of these challenges is rather simple:
For the small environment projects, employ someone familiar with large scale projects. Make sure they hold a substantial position in the project team. They must have significant input and steering capacity. If they only have power to offer advice it won't work. Even if you can't afford to hire someone on full time, at least try on a consultant. They don't have to write any code or prepare any documentation. Just pick their mind for ideas. Time is valuable, but ideas are way more valuable.
For the large environment projects, employ someone in each functional entity who is familiar with small environment projects. They too must have significant input and steering capability. They should also be encouraged to meet separately from the legacy team members so that they can compare experiences and share ideas. Legacy team members are often too burdened with policy and procedural concerns to free their minds to focus purely on the project. This is also important because no two of these former small-team folks will have the same small team experiences. It's important to foster and maintain their flexibility, and creativity to shore up the rigid policy-driven thinking already in place. Blending them in is usually a bad mistake that wastes the potential benefits they could deliver. And as with the comment in the preceding paragraph: consider a consultant to help spark new ideas and provide fresh insight into how you could shake things up.
Think of how Apple and Google differ, in every way, from IBM and Microsoft. From the products and services they pursue, to their marketing, to the ways they treat their employees. But this is way more than simply looking at well-known companies and how they're perceived. This is about *you* taking a different approach to how you view and tackle projects. If you're immersed in one of these worlds, it can be very difficult to think from the other side, or "think outside of the box" (your box). But you can at least try. Don't give in to the usual office joking about the "other" side of business strategy.
The Gains
If you're working in a small environment, you stand to gain efficiency, stability, reliability, extensibility and as a result, reduce support costs, and gaining more competitive advantages by just becoming more efficient and proficient. Taking on new projects becomes less complex and less expensive as well. You gain productivity.
If you're working in a large environment, you stand to gain flexibility, innovation, creativity, and spark enthusiasm in an otherwise drab landscape. Let's face it, following policies and procedures ad nauseum tends to kill enthusiasm for the task at hand. It's an assembly line perspective. It tends to bleed creativity and innovation. When you feed enthusiasm, you also feed productivity. Your products not only absorb new ideas and new capabilities from the new freedom of thought, you gain the added force of an energized staff. You gain productivity.
Do you see the common point?
I may be taking some time off from writing on the blog for a while. If you have any thoughts or comments, please post a comment. Thanks for reading!
If your company vision or mission statement is longer than one sentence: start over!
They should be as brief as a Chinese fortune cookie statement. I'm so tired of all the pompous, circle-jerking verbose crap being shoved into the faces of web site visitors. The stupid and meaningless MBA-babble that amounts to less-than-air. The usual "to persevere to endeavor to meet or exceed the expectations of our valued customers" blah blah blah.
If you're having writer's block, here's some mission statement suggestions:
"To kick ass, make money, and crush the competition"
How many times have you, or someone you know, spent more than 15 seconds blasting one political party or another? You know: "Typical Democrat!" or "Typical Republican!" Whatever.
Based on the logic that ALL members of a political party are exactly alike, and should be treated exactly alike, and that they are people, then we can apply that same generalization to any other aspect of their humanity.
Because John Conyers is exactly the same as Jim Webb? And Bobby Jindall is exactly the same as Ronald Reagan? John Anderson is the same as Ron Paul too? And you watch every vote tally for every bill as well. Right? So you KNOW that every member of each party ALWAYS votes along with their party. Always. Right? Sure.
So, using this empirical logic, all Christians, all Jews, all Hindus, all Muslims, all Blacks, all Asians, all Whites, all Hispanics, all Women, all Men, are the same as each other in their respective demographic groups. Exactly. Why not? If all Republicans are the same, and all Democrats are the same, then why aren't all Christians the same?
So, do me a favor, and the next time you feel like opening your mouth to spew something profoundly genius about how you heard something on Fox or CNN and it's clearly an example of the ____ political party, just STFU. Maybe you can fool someone into thinking you're really smart by not opening your mouth.
![jogging-exercise[1]](http://lh4.ggpht.com/_8gO-v9s9Ato/TEr6Wr5PWZI/AAAAAAAAHgw/cIXD3PNuokk/s1600-h/jogging-exercise%5B1%5D%5B6%5D.jpg "jogging-exercise[1]")
Why is it that nobody seems to be able to describe or explain "Object Oriented Programming" worth a shit? I'm serious.![big-dog-little-dog[1]](http://lh3.ggpht.com/_8gO-v9s9Ato/TDHopWVAVRI/AAAAAAAAHgU/nsvgS7bFWuE/s1600-h/big-dog-little-dog%5B1%5D%5B9%5D.jpg "big-dog-little-dog[1]")