If you haven't done so already, you should definitely check out Jimmy Bergmark's course on "Autodesk Network License Manager". It covers a vast amount of information about setting up, configuring, managing and troubleshooting the FlexLM environment and your Autodesk products. Good stuff! Highly recommended.
Tuesday, 29 November 2011
Saturday, 26 November 2011
"Using scripts to process data is more like panning for gold than transmuting lead into gold. So if there is gold in the garbage, the scripts can find it, consolidate it, and output it in a shiny pretty form. If there isn't any gold, then you will just get some finely sorted and polished garbage." - Joe (Joeware.net)
I couldn't agree more. It takes the age-old phrase of "garbage-in = garbage-out" and sprinkles some technical context on it like a good seasoning on a grilled chicken (can you tell I'm hungry?)
This also reminded me of a quote from a colleague (and former supervisor) regarding the use of software-based "automation" for business processes: "If you automate a broken process, you only get an automated broken process." (fix the process before you try to automate it!!)
I couldn't agree more. It takes the age-old phrase of "garbage-in = garbage-out" and sprinkles some technical context on it like a good seasoning on a grilled chicken (can you tell I'm hungry?)
This also reminded me of a quote from a colleague (and former supervisor) regarding the use of software-based "automation" for business processes: "If you automate a broken process, you only get an automated broken process." (fix the process before you try to automate it!!)
Thursday, 24 November 2011
Since the dawn of mankind, the popular perception of the status quo for almost every single "technological" thing was "it works fine, why change it?" They said that about the chariot, the map of the heavens/planets/sun, the catapult, the bow and arrow, the wagon, the castle and moat, the front-loading single-shot pistol and rifle, Sulpha drugs, leeches, slavery, battleships, Model T cars, steam engines. Remember Roger Bannister? Yeah, EVERY single "expert" and physician of his time swore on a truckload of Bibles that any human who broke the 4 minute mile would die. The human body simply couldn't achieve that goal.
Then someone stuck their neck out and said "fuck that!". I'm sorry if that offends you, but that's essentially what they said/did. And for doing that they were ridiculed, shunned, banished, jailed and even killed. They dared to disagree with the Status Quo; the masses; the majority. Nearly every single one of the people the broke those de facto "rules" or "limits" endured mockery throughout their efforts to break the barrier they set out to overcome. Some never saw recognition, as they died before the "masses" woke up and realized that they had indeed done something incredibly helpful or history-changing for mankind.
Remember the story of Thomas Watson Sr. and Thomas Watson Jr.? The infamous head of IBM who insisted a "personal computer" was a dumb idea and would never be practical. Junior waited until his turn came up and then he seized upon the moment to introduce the "IBM personal computer". Same thing for HP and Atari and Steve Jobs and Steve Wozniak.
So, when I look around at the stupid crap we just "live with" and pay little attention to, saying things like "it's worked for years/decades, why change it?" I want to shake my head in disbelief that we've given up. A bar of soap? A toothbrush. Deoderant. Frying pans. Toasters (have they ever been improved? it's long overdue), Roofing Technology, Door ways. A coffee cup. Software. Computers. Aircraft. Surgical Procedures. Medicine. Cancer Treatments. Education systems. Weapons technology. Network routing and throughput. Movies. Music. Art. Food. The list goes on and on.
Never say "good enough"! Anything you point at can be improved upon. Anything. Maybe not in our lifetime. Maybe not until future discoveries lead to secondary potentials to be realized. But they will happen. The longer we stand still, point and say "it's fine as-is" the longer it will take to make it better.
Most people look at Cancer treatment and say "wow, look how far they've come.", until their 5 year old child is diagnosed with Cancer. Then it quickly becomes "when will it be cured?" and "why can't we make faster progress?" Aircraft are just fine until the next crash investigation reveals a design flaw. Music is just fine until you hear that one new song that grabs your attention and makes you ask "who is that?!" Same for art, movies and food by the way. And software? In 2004 there was no Facebook. There was no Twitter, FourSquare, Yelp or UrbanSpoon either. In 2000 there wasn't any Google either. No VMware. All the "smart" phones were bulky, limited and boring. Are you old enough to remember the first laptops? The first microwave ovens? The first video tape recorders? The first tablet prototypes in the 1990s? Today those things seem like steam engines. Remember when car companies swore air bags, even seat belts, were a complete waste of time? Remember when they thought stomach ulcers were just bad luck and you had to live with them?
Good enough is NOT good enough. Ever.
Wednesday, 23 November 2011
You know that nifty, clever feature, where you paste a URL into Facebook or Google Plus, and they chew on it for a second or two, and then create a mini-snippet to post? Usually, they pull in a graphic and maybe the page description, or meta-description. So, I noticed today how different they really are. I also noticed that, as much as I really don't like Facebook anymore, it does a better job of rendering and polishing that result before posting it. Case in point: I posted the URL to an interesting book (ha ha!)... http://www.amazon.com/Stuck-Up-Inserted-Ingested-ebook/dp/B0056DR5KY into Facebook and Google Plus. Here's how each of them rendered the result...
Facebook
Google Plus
Google Plus pulls in the authors and makes it part of the subject heading, but it ends up being too cluttered. The Facebook result is cleaner and easier to read. Also, the descriptions are very different. Entirely different, actually. I think the Facebook result wins.
Tuesday, 22 November 2011
I was driving home from work and thinking about ponderous experiences in my past career endeavors. I do that sometimes when I'm not speeding and weaving around like a blind man with Turrette's. It stemmed from a lengthy discussion with one of my nephews about our relative "quality of life" and "career satisfaction" stuff, and so on. Guys often get into this subject matter after blabbering about titties and power tools. (There's nothing wrong with either of those, but you can only talk about them so long before you run out of superlatives and metaphors.)
I said to him "I think I'm in the best situation I've ever been in, at least so far. I'm enjoying it while it lasts, because nothing lasts forever."
We digressed into two aspects of that statement: one for each sentence.
As for the second one (I'm working in reverse): I've been in too many "sure bet" situations that suddenly turned a wrong corner. Once after 10 years, another after 7 years, and another after only 5 months. Shit happens. When you've had a CEO shake your hand and hand you a mixed drink, smile, and tell you with utmost sincerity that "your job is as safe and secure as it could possibly be", only to close your office and lay you off two weeks later, it tends to leave to an impression. That was five months into the new job. The 7 year job was one I thought I'd retire from and live happily ever after. The CEO of that place turned into a vindictive paranoid dick and stabbed everyone, even his VP's, in the back and left with a golden parachute. Those two situations, along with the death of some very close colleagues, really hit home with me and given me a perspective that you have to plan for the worst, hope for the best, and be prepared for whatever comes next.
Enough of that though. On to the first sentence...
As far as building cool applications are concerned, at least where I define "cool" as (A) fun to write code for, (B) produce something that helps not only myself but those around me, and (C) is actually beneficial to my employer's line of business, I can point to three distinct experiences:
Employer 1 - I had an idea to build something that was helpful for my group, but the company pushed back hard at every turn. Their rationale? I was hired to do job "A", so working on something outside of that, even though it automated more than half of what job "A" entailed, was outside the duties of job "A". Period. In one situation, I was flat-out told (and I quote): "We are a defense contractor. We don't get paid to save time. We get paid for the time it takes to do it right." Awesome reflection of the true American work ethic. Regardless of being approached by four peer-level businesses to license it, and three government agencies, the employer refused and effectively killed the project.
Employer 2 - I had a manager with amazing vision and self-direction, who approached me to help him build something that was aimed squarely at automating our daily workload. It grew and grew, mostly with his ideas and direction, based on what he had seen accomplished at each step, and propelling it on to the next level. It was a cool project indeed. The company fought back, again, with a slightly different rational: "Your group is tasked with "A" not developing software. If you wanted a solution, you should have requested the AppDev group." Translation: feasibility studies, requirements analysis, pre-dev evaluation, code and test, evaluation, UAT, the whole stupid-ass CMMI assembly line. And this is to build something that really warranted none of that excessive bullshit. The real aim was control and something to provide time-charge coverage for a bunch of people with not enough work to cover them. In the end, I left and another developer was brought on to continue work on it, but it was eventually given over to the AppDev group and given the lobotomy treatment.
Employer 3 - Both my manager, and the entire management structure saw the results of a small example, pulled me aside and said "do more!". Regardless of my official duties, they allow me incredible latitude to push things as far as it makes sense, as long as it produces results that satisfy others. So far so good.
To sum this up: One place let me build a car but not let it out of the garage. The next place let me build a car, and get it out on the road, but not go faster than 55 mph. The next place let me build it, and take it out on a race track with no limits.
Conclusion
Regardless of technology. Regardless of technological potential. What most often holds back progress, or often outright KILLS it, are people. People with narrow vision, no concern for innovation as it pertains to making real progress, are what build speed bumps. Vision builds roads with few potholes.
No place is perfect. I'm not going to even attempt to say that Employer 3 is perfect. That would be nonsense. But finding the right balance between ideal and tolerable is what makes things work for each person. It's like a girlfriend or boyfriend. You'll never find perfection, but if you can find enough good traits to outweigh the bad ones, it can often work out great.
Each of the three employers had plenty of skilled, intelligent, funny and progressive people. The problem for two of them was a barrier of culture that keeps them from achieving their full potential. I know for certain that most of the people I had worked with, if placed into different environments, would damn near explode with positive results. A suppressed culture suppresses everyone within it. Whether it's by standing up roadblocks, meetings, committees, reviews, forms, forms and more forms, and decisions made by people with absolutely zero understanding of the case being decided, or by the nature of the work itself being limited to one road, rather than a network of roads with unlimited potential, the environment shapes the potential of every employee. The employees become the environment and it becomes them.
All I can suggest is this:
Look for the barriers, the obstacles, the roadblocks, and if you can't remove them, try to work around them. Find a way to get your ideas into action. My manager at Employer 2 did just that, and pressed ahead against incredible push-back and apathy, and refused to give up. I simply drafted behind him enjoyed the opportunity to break out of the assembly line work I was hired to do. If you have a good idea, find others who will listen. Band together and share your ideas and feed off each other's positive views. If you're lucky, that's an easy thing to do. For a lot of people it's a struggle, but don't give up. Do the homework and confirm your beliefs with hard facts and numbers. If you think it will save time and money, be ready to back up your estimates. It's really hard to argue against good numbers. The real people in power live on numbers.
When you run into people at work that just don't get it, move on and find the ones that do.
I said to him "I think I'm in the best situation I've ever been in, at least so far. I'm enjoying it while it lasts, because nothing lasts forever."
We digressed into two aspects of that statement: one for each sentence.
As for the second one (I'm working in reverse): I've been in too many "sure bet" situations that suddenly turned a wrong corner. Once after 10 years, another after 7 years, and another after only 5 months. Shit happens. When you've had a CEO shake your hand and hand you a mixed drink, smile, and tell you with utmost sincerity that "your job is as safe and secure as it could possibly be", only to close your office and lay you off two weeks later, it tends to leave to an impression. That was five months into the new job. The 7 year job was one I thought I'd retire from and live happily ever after. The CEO of that place turned into a vindictive paranoid dick and stabbed everyone, even his VP's, in the back and left with a golden parachute. Those two situations, along with the death of some very close colleagues, really hit home with me and given me a perspective that you have to plan for the worst, hope for the best, and be prepared for whatever comes next.
Enough of that though. On to the first sentence...
As far as building cool applications are concerned, at least where I define "cool" as (A) fun to write code for, (B) produce something that helps not only myself but those around me, and (C) is actually beneficial to my employer's line of business, I can point to three distinct experiences:
Employer 1 - I had an idea to build something that was helpful for my group, but the company pushed back hard at every turn. Their rationale? I was hired to do job "A", so working on something outside of that, even though it automated more than half of what job "A" entailed, was outside the duties of job "A". Period. In one situation, I was flat-out told (and I quote): "We are a defense contractor. We don't get paid to save time. We get paid for the time it takes to do it right." Awesome reflection of the true American work ethic. Regardless of being approached by four peer-level businesses to license it, and three government agencies, the employer refused and effectively killed the project.
Employer 2 - I had a manager with amazing vision and self-direction, who approached me to help him build something that was aimed squarely at automating our daily workload. It grew and grew, mostly with his ideas and direction, based on what he had seen accomplished at each step, and propelling it on to the next level. It was a cool project indeed. The company fought back, again, with a slightly different rational: "Your group is tasked with "A" not developing software. If you wanted a solution, you should have requested the AppDev group." Translation: feasibility studies, requirements analysis, pre-dev evaluation, code and test, evaluation, UAT, the whole stupid-ass CMMI assembly line. And this is to build something that really warranted none of that excessive bullshit. The real aim was control and something to provide time-charge coverage for a bunch of people with not enough work to cover them. In the end, I left and another developer was brought on to continue work on it, but it was eventually given over to the AppDev group and given the lobotomy treatment.
Employer 3 - Both my manager, and the entire management structure saw the results of a small example, pulled me aside and said "do more!". Regardless of my official duties, they allow me incredible latitude to push things as far as it makes sense, as long as it produces results that satisfy others. So far so good.
To sum this up: One place let me build a car but not let it out of the garage. The next place let me build a car, and get it out on the road, but not go faster than 55 mph. The next place let me build it, and take it out on a race track with no limits.
Conclusion
Regardless of technology. Regardless of technological potential. What most often holds back progress, or often outright KILLS it, are people. People with narrow vision, no concern for innovation as it pertains to making real progress, are what build speed bumps. Vision builds roads with few potholes.
No place is perfect. I'm not going to even attempt to say that Employer 3 is perfect. That would be nonsense. But finding the right balance between ideal and tolerable is what makes things work for each person. It's like a girlfriend or boyfriend. You'll never find perfection, but if you can find enough good traits to outweigh the bad ones, it can often work out great.
Each of the three employers had plenty of skilled, intelligent, funny and progressive people. The problem for two of them was a barrier of culture that keeps them from achieving their full potential. I know for certain that most of the people I had worked with, if placed into different environments, would damn near explode with positive results. A suppressed culture suppresses everyone within it. Whether it's by standing up roadblocks, meetings, committees, reviews, forms, forms and more forms, and decisions made by people with absolutely zero understanding of the case being decided, or by the nature of the work itself being limited to one road, rather than a network of roads with unlimited potential, the environment shapes the potential of every employee. The employees become the environment and it becomes them.
All I can suggest is this:
Look for the barriers, the obstacles, the roadblocks, and if you can't remove them, try to work around them. Find a way to get your ideas into action. My manager at Employer 2 did just that, and pressed ahead against incredible push-back and apathy, and refused to give up. I simply drafted behind him enjoyed the opportunity to break out of the assembly line work I was hired to do. If you have a good idea, find others who will listen. Band together and share your ideas and feed off each other's positive views. If you're lucky, that's an easy thing to do. For a lot of people it's a struggle, but don't give up. Do the homework and confirm your beliefs with hard facts and numbers. If you think it will save time and money, be ready to back up your estimates. It's really hard to argue against good numbers. The real people in power live on numbers.
When you run into people at work that just don't get it, move on and find the ones that do.
Monday, 21 November 2011
Unfortunately, there was a problem with formatting that was discovered after I published "The Packager's Pocket Reference, 2nd Edition" for Amazon Kindle. I have uploaded a corrected version and have asked Amazon to repost it and email customers to notify them of an updated version. The update is free for those who have already purchased it. I apologize for the inconvenience and as always: I appreciate your support.
Thank you! Dave
Thank you! Dave
After years of watching sci-fi TV shows, movies, etc. it's finally come to a point where even the so-called brightest of our authors and screenwriters are annoying the shit out of me. Why? Because the common, no, strike that, not "common", but more accurately, the "only" view they seem to follow is that interplanetary/intergalactic "aliens" will fit the following mold:
We all know about culture dichotomies like how cows are viewed in America versus India. How handshakes are viewed in the Middle East, versus Japan or Africa, and how showing the soles of your feet when sitting down is offensive to some cultures, as is offering your left hand to shake (or even wave hello). So we see cows as a source of milk and food in America. They exist to provide milk and be slaughtered for beef. In India they let them walk the streets like we view dogs and cats. What if aliens view horses and dogs the same way? What if they view skin tones in that way? What if brown skin is ok to have around, but pale skin means extra crispy batter coating? What if?
You're probably snickering. Most humans would. That's because we humans know everything. We can predict everything. We apply our logic to predict what can be possible beyond what we've experienced. We are awesome. That's why we can predict the stock market so well.
- Intelligent
- Two legs and two arms (yes, I've see the others with octopus bodies and heads like bugs)
- Two eyes and a mouth (or three eyes and no mouth)
- Most of them don't have a nose (wtf?)
- Their vision is in the same light spectrum as ours
- Their hearing is in the same frequency range as ours
- They sense heat and cold like we do
- They wear clothing to cover their naughty bits (or don't have any naughty bits)
- They don't smell really bad
- They don't make obnoxious sounds (farting, snoring) all the time
- They don't leave trails wherever they go
- They understand our body language and colloquial aspects
What if? What if they smell like shit? What if they ooze from all their pores all the time? What if they leave a slug trail? What if they find some of our gestures aggravatingly offensive? Imagine that some of our common names for things sound like words they use to describe offensive things. What if they introduce themselves and have names like "fuck" and "c**ksucker"? Go ahead and smirk and laugh, but what if they sounded so much like that we'd do a double-take? What if reaching out to offer a handshake is a sign of aggression in their culture? What if we look like food to them?
What if they like to be naked and they have six 24-inch penises sticking out from all around them?
What if they have eight testicles that hang from beneath their face?
We all know about culture dichotomies like how cows are viewed in America versus India. How handshakes are viewed in the Middle East, versus Japan or Africa, and how showing the soles of your feet when sitting down is offensive to some cultures, as is offering your left hand to shake (or even wave hello). So we see cows as a source of milk and food in America. They exist to provide milk and be slaughtered for beef. In India they let them walk the streets like we view dogs and cats. What if aliens view horses and dogs the same way? What if they view skin tones in that way? What if brown skin is ok to have around, but pale skin means extra crispy batter coating? What if?
You're probably snickering. Most humans would. That's because we humans know everything. We can predict everything. We apply our logic to predict what can be possible beyond what we've experienced. We are awesome. That's why we can predict the stock market so well.
Sunday, 20 November 2011
I'm not picking on, nor condoning, either one of these. I'm just doing a brief comparison and contrast...
| Argument | Hand Guns | Marijuana |
| Blame Assignment | "Guns don't kill people. People kill people" | "Gateway drug to Heroin and Crack" |
| Alternatives | Knives, Bottles, Bombs, Fire, Poison, Heavy Machinery, Fists, Feet (with or without boots), Blunt Objects, Piano Wire, Workshop Tools | Alcohol, Salvia, Meth, Paint, Cleaners and Solvents, Redi-Whip cans |
| Who Stands to Gain | NRA, Gun Manufacturers | Private Citizens, Fast Food Vendors, Pizza Shops, Chinese Take-Out, Soft Drink Vendors, Nabisco, Keebler, Kraft, Kellogg, General Mills, Coke, Pepsi, 7-11 and Convenience Stores, Concert Venues, Musicians, Theaters and Movie Producers, Cable TV PPV |
| Who Regulates | Federal, State, Local | Federal, State |
| Casualties | Thousands per Year | None documented |
| Accident Consequences | Death, Debilitation, Property Damage | Munchies, Sleep |
| Environmental Impact | From raw material extraction, to material stock refinement, to machine refinement, to chemicals and solvents, to combustion vapors, to spent shells. | Small amounts of smoke |
| Places Most Often Used | Target Range, Liquor Store, Pawn Shop, Back Alley, Living Room, Trailer Park, Bar Parking Lot, High School Cafeteria | Living Room, Den, Bedroom |
| Extreme Cases | SWAT team, Fire Department, EMT and Ambulances, Coroner, Evacuation | Red Bull |
It is now available on Amazon.com!
Download a free sample or buy it for only $7.99
Available for US, UK, Germany, and France Kindle shoppers.
Don't have a Kindle? No problem. You can download FREE Kindle Reader Apps for Windows, WP7, OSX, iOS (iPod, iPhone, iPad), Blackberry and Android
Still not satisfied? You can use the Kindle Cloud Reader to read books in your web browser too.
Friday, 18 November 2011
The 2nd Edition is out! Chocked full of new examples, reference information and new chapters on lab setups, methods and approaches to making packages through a variety of means. Scripting, packaging and all that stuff. Still in a compact "reference" format and size, makes it easy to navigate and find what you need fast.
Available soon* on Amazon Kindle and Kindle Reader apps (Windows, OSX, Android, Blackberry, iPad) for only... $7.99 (USD)
* submitted to Amazon 11/19/2011 and should be available for purchase within a few days afterwards.
If you've been unlucky enough to have read my blog for a year or more, you've seen me post crap about using "computer" or "service" accounts, instead of dedicated (manually created) AD accounts, for running scheduled or automated tasks. Things like back-ups, replication, monitors, etc. Well, the addition of MSA in Server 2008 R2 is also a great option. I forgot to mention that. In any case: If you are still using manually-created user accounts as "service" or "proxy" accounts, and are still maintaining passwords manually - STOP!!!!
http://feeds.4sysops.com/~r/4sysops/~3/ysFpAi-fBVA/
http://feeds.4sysops.com/~r/4sysops/~3/ysFpAi-fBVA/
I'm just a tiny bit buzzed on St. Bernardus Abbey Ale right now, so forgive my incoherent babbling ,please.
I've been head-down coding for weeks on a cool little project. The project builds a mountain atop the web-interface we have to SCCM+AD+ our asset management system. The new mountain extends it by essentially "snapshotting" an SCCM collection (computers and all their apps), into a standalone table where we can "model" future replacement needs before putting them back into production. All of this is via web interface. I have to say it was/is the most fun I've had writing code in a long time. I've been swimming around in the SQL end of Configuration Manager for months and learning new stuff every day. I'm dying to dig into 2012! I have RC1 in a virtual lab and will be diving into that asap. Some changes I've seen look really cool. I'm also eager to see what legacy trash they've finally cut loose.
The excitement I had for CAD programming during the 1990's and up until 2006 had faded when I parted ways with the Autodesk development world. The move into "mainstream" Microsoft infrastructure IT has been both exciting and scary at the same time. In some respects not nearly as interesting as writing code to automate design tasks, extracting and integrating data with graphical objects, automating design processes, let alone leaving the fucking awesome world of LISP programming (go ahead and laugh, it blows the shit out of your .NET, Ruby and Java stuff). Alas, the world doesn't stop moving. At 47 it's becoming more difficult to keep up.
St. Berndardus is 10% ABV by the way. Holy shit! A 2 pt bottle and I'm only half done. Bzzzzzzz.
Onward!
What I've missed most about LISP when moving into PHP, VB.NET and Powershell is things like (apply), (mapcar) and (lambda). And (defun), oohhhh. ohhhh.. I need a Kleenex. God - I miss that. There's just nothing in the newer "modern" languages that does that. Sure, they can mimic, but they don't really do it for me.
If I had to rate newer langauges for which is "more fun" I'd have to say it's a close tie between PHP and KiXtart. PHP probably wins out. And before you start moaning about KiXtart and your horrid memories of login scripts - STOP! It's much much MUCH more than that. The language is awesome. The engine is pure perfection. If Powershell could execute on a dime like Kix32.exe - well - let's just say you'd need to call for a cleanup on aisle 9 because I'd lose control of my bowels. Powershell is cool and all, but there's things that bother me about it (like the slow engine start-up, and the cruddy mirror of VBscript's NOW function), but it's still "the future" so we have to open up and drink the new Kool Aid.
I'm really buzzed, um.... yep.
Where was I? Oh yeah... got my Google+ YouTube player blasting. Hold on...
SCCM Collections to Distribution Points
So - one interesting thing about this web/sccm project has been tying intangibles to tangibles. A theoretical data integration model known as "tenuous relations" (sounds like a bad date). The concept is how to link things that are relatively static or predictable to things that aren't. Let's digress - Yes!
So, we have a collection built upon computers which are discovered that are members of a specific AD group. This group is intended to define a "department-based" group of computer assets. We need to identify which protected distribution point server they will hit (as a priority, not exclusively, mind you), but how do you do that?
You can perform a "select distinct" on the v_R_System table (view) using the AD_SiteName0 field (I may have mis-typed that name, don't sue me), and get a list of unique Site Boundaries. From that I can link to the site boundaries view vSMS_CurrentBoundary (more) and hop on through to the DP's via the v_DistributionPoint_Info view (again, I may have the name mis-typed). If you do the SQL joins properly you can pull it off.
Alternatively, if that's too much hair-pulling, you can do this the monkey-wrench way:
Open the MMC console, expand the Site and site management, then click on Site Boundaries. Right click and export to a tab-delimited text file. Save it to your web server, make a code page module to parse it using FSO and map the AD site to the left-most column to pull the list of link speeds and protected DP names.
Warning: The site boundaries do not show all the DP's. Only the protected DPs. If you need all the others (including the branch DPs) you have to query more database tables/views. It depends on which "list" you really need/want. Remember that clients won't exclusively pull from protected DP's if there are non-protected DP's in the same site (or over a fast link as well).
Eh. enough of this. I'm supposed to forget work stuff on Friday night.
I've been head-down coding for weeks on a cool little project. The project builds a mountain atop the web-interface we have to SCCM+AD+ our asset management system. The new mountain extends it by essentially "snapshotting" an SCCM collection (computers and all their apps), into a standalone table where we can "model" future replacement needs before putting them back into production. All of this is via web interface. I have to say it was/is the most fun I've had writing code in a long time. I've been swimming around in the SQL end of Configuration Manager for months and learning new stuff every day. I'm dying to dig into 2012! I have RC1 in a virtual lab and will be diving into that asap. Some changes I've seen look really cool. I'm also eager to see what legacy trash they've finally cut loose.
The excitement I had for CAD programming during the 1990's and up until 2006 had faded when I parted ways with the Autodesk development world. The move into "mainstream" Microsoft infrastructure IT has been both exciting and scary at the same time. In some respects not nearly as interesting as writing code to automate design tasks, extracting and integrating data with graphical objects, automating design processes, let alone leaving the fucking awesome world of LISP programming (go ahead and laugh, it blows the shit out of your .NET, Ruby and Java stuff). Alas, the world doesn't stop moving. At 47 it's becoming more difficult to keep up.
St. Berndardus is 10% ABV by the way. Holy shit! A 2 pt bottle and I'm only half done. Bzzzzzzz.
Onward!
What I've missed most about LISP when moving into PHP, VB.NET and Powershell is things like (apply), (mapcar) and (lambda). And (defun), oohhhh. ohhhh.. I need a Kleenex. God - I miss that. There's just nothing in the newer "modern" languages that does that. Sure, they can mimic, but they don't really do it for me.
If I had to rate newer langauges for which is "more fun" I'd have to say it's a close tie between PHP and KiXtart. PHP probably wins out. And before you start moaning about KiXtart and your horrid memories of login scripts - STOP! It's much much MUCH more than that. The language is awesome. The engine is pure perfection. If Powershell could execute on a dime like Kix32.exe - well - let's just say you'd need to call for a cleanup on aisle 9 because I'd lose control of my bowels. Powershell is cool and all, but there's things that bother me about it (like the slow engine start-up, and the cruddy mirror of VBscript's NOW function), but it's still "the future" so we have to open up and drink the new Kool Aid.
I'm really buzzed, um.... yep.
Where was I? Oh yeah... got my Google+ YouTube player blasting. Hold on...
SCCM Collections to Distribution Points
So - one interesting thing about this web/sccm project has been tying intangibles to tangibles. A theoretical data integration model known as "tenuous relations" (sounds like a bad date). The concept is how to link things that are relatively static or predictable to things that aren't. Let's digress - Yes!
So, we have a collection built upon computers which are discovered that are members of a specific AD group. This group is intended to define a "department-based" group of computer assets. We need to identify which protected distribution point server they will hit (as a priority, not exclusively, mind you), but how do you do that?
You can perform a "select distinct" on the v_R_System table (view) using the AD_SiteName0 field (I may have mis-typed that name, don't sue me), and get a list of unique Site Boundaries. From that I can link to the site boundaries view vSMS_CurrentBoundary (more) and hop on through to the DP's via the v_DistributionPoint_Info view (again, I may have the name mis-typed). If you do the SQL joins properly you can pull it off.
Alternatively, if that's too much hair-pulling, you can do this the monkey-wrench way:
Open the MMC console, expand the Site and site management, then click on Site Boundaries. Right click and export to a tab-delimited text file. Save it to your web server, make a code page module to parse it using FSO and map the AD site to the left-most column to pull the list of link speeds and protected DP names.
Warning: The site boundaries do not show all the DP's. Only the protected DPs. If you need all the others (including the branch DPs) you have to query more database tables/views. It depends on which "list" you really need/want. Remember that clients won't exclusively pull from protected DP's if there are non-protected DP's in the same site (or over a fast link as well).
Eh. enough of this. I'm supposed to forget work stuff on Friday night.
Thursday, 17 November 2011
I'm not a DBA, although I play one on breaks in the kitchen at work. I have worked with various databases for quite a few years, including MS SQL Server, MySQL, and Oracle. I don't count FoxPro or Access because I absolutely hate client-side databases due to the bullshit headaches they create for IT departments (and consultants like myself), but alas, I have already digressed on that subject in previous blog posts.
One thing I see quite a bit with ADO examples in particular is a lack of (a) error checking and (b) connection limiting. I'm not talking about connection throttling, but rather: applying some refactoring logic to how you open and close connections to optimize the use of the open pipeline without keeping it open too long (or re-opening it too many times).
As for error checking: This is a fairly standard/typical piece of VBscript/ASP code for running a "select" query via ADO against a database. It doesn't matter whether that database is local to the server/host where the code is being executed, well, it does actually, it matters more if it's remote, but whatever, let's chew and digest slowly here...
[CODE]
This looks simple enough. But there are quite a few places that could implode here if not handled explicitly. Granted, error handling with .NET is more robust, but indulge me here for a moment since (A) there's still 100 times more VBScript code strewn about this planet than .NET code, and (B) I'm old. The big three problems that are most likely to occur with this scenario are...
Connection Failure
Connection Delay / Time-Out
Recordset Access Failure (access denied)
Let's handle them one by one...
Connection Failure
Prior to the "conn.Open" statement, we should override the default error system and then check for the exit code from the .Open method and see what happened. If it was successful (exit code: 0), we continue on, otherwise we should handle the error and exit safely.
[CODE]
If you do your connection within a Sub() or Function() block, you should probably exit using Exit Sub or Exit Function, but that's not always true either.
Connection Time-Out
What if the connection is taking a longer time to resolve than usual? We can handle that too...
[CODE]
Recordset Access Failure
Another common issue is when you can successfully open the connection, but cannot read from a table or view because of security permissions.
[CODE]
Connection Management
I've seen more situations than I can count where a single page of code (script file, web page, etc.) makes repeated requests from a database in sequential order (as the page is rendered or the script is executed). Most often it's having to grab data from multiple tables and/or views, or execute multiple stored procedures or functions. In a lot of cases, the code doing the heavy lifting is being included from separate files (using "includes"). That's all nifty and modular, which is a good approach, but always be VERY careful with that approach that you don't have each module do it's own connection open/close management. This not only slows down the processing, but it requires more bandwidth and more load on the network and the database server as well.
A case in point might be a web page that renders a report of an employee, then it displays a table with performance evaluation records, followed by a table of employees managed by the employee in question. If those data repositories are all on different database servers that may be all you can do, but if they happen to be on one server, or even in one database, you should seriously review minimizing the number of open/close requests on your connections.
A brief sample of this using pseudo code:
open connection1
open recordset1
close connection1
open connection2
open recordset2
close connection2
open connection3
open recordset3
close connection3
might work a lot faster and better as...
open connection
open recordset1
open recordset2
open recordset3
close connection
Some people prefer to open a "global" or "session" connection, whereby the connection is opened upon login or initialization by each user session. The connection object itself is stored in the session stack and made available globally to that user throughout their session window. Each concurrent user has their own connection opened and maintained on a stack. Granted this makes it easier to run queries, updates, etc. without the overhead of managing connections at the more granular page/script level, but it definitely taxes the database server with a lot of unnecessary open connections. For a handful of users that may be fine, but with hundreds or thousands of users it can be a mess and make the database server drag.
Just some random thoughts after beer. Have any thoughts you'd like to share?
One thing I see quite a bit with ADO examples in particular is a lack of (a) error checking and (b) connection limiting. I'm not talking about connection throttling, but rather: applying some refactoring logic to how you open and close connections to optimize the use of the open pipeline without keeping it open too long (or re-opening it too many times).
As for error checking: This is a fairly standard/typical piece of VBscript/ASP code for running a "select" query via ADO against a database. It doesn't matter whether that database is local to the server/host where the code is being executed, well, it does actually, it matters more if it's remote, but whatever, let's chew and digest slowly here...
[CODE]
Set conn = Server.CreateObject("ADODB.Connection")
Set cmd = Server.CreateObject("ADODB.Command")
Set rs = Server.CreateObject("ADODB.Recordset")
query = "SELECT * FROM dbo.SomeTable WHERE id=" & _
idNumber & " ORDER BY ItemName"
conn.Open dsnString
rs.CursorLocation = adUseClient
rs.CursorType = adOpenStatic
rs.LockType = adLockReadOnly
Set cmd.ActiveConnection = conn
cmd.CommandType = adCmdText
cmd.CommandText = query
rs.Open cmd
If Not(rs.BOF And rs.EOF) Then
cols = rs.Fields.Count
rows = rs.RecordCount
Do Until rs.EOF
' do something stupid here
rs.MoveNext
LoopElse
Response.Write "oops, no records were returned"[/CODE]
End If
rs.Close
conn.Close
Set rs = Nothing
Set cmd = Nothing
Set conn = Nothing
This looks simple enough. But there are quite a few places that could implode here if not handled explicitly. Granted, error handling with .NET is more robust, but indulge me here for a moment since (A) there's still 100 times more VBScript code strewn about this planet than .NET code, and (B) I'm old. The big three problems that are most likely to occur with this scenario are...
Connection Failure
Connection Delay / Time-Out
Recordset Access Failure (access denied)
Let's handle them one by one...
Connection Failure
Prior to the "conn.Open" statement, we should override the default error system and then check for the exit code from the .Open method and see what happened. If it was successful (exit code: 0), we continue on, otherwise we should handle the error and exit safely.
[CODE]
On Error Resume Next
conn.Open dsnString
If err.Number <> 0 Then
' an error occurred, so something clever here
Response.Write "oops, cannot open a connection"
Response.End
End If[/CODE]
If you do your connection within a Sub() or Function() block, you should probably exit using Exit Sub or Exit Function, but that's not always true either.
Connection Time-Out
What if the connection is taking a longer time to resolve than usual? We can handle that too...
[CODE]
On Error Resume Next
conn.ConnectionTimeOut = 15 ' allow 15 seconds to establish the connection
conn.Open dsnString
If err.Number <> 0 Then
' an error occurred, so something clever here
Response.Write "oops, cannot open a connection"
Response.End
End If[/CODE]
Recordset Access Failure
Another common issue is when you can successfully open the connection, but cannot read from a table or view because of security permissions.
[CODE]
rs.Open cmd
If err.Number <> 0 Then
' do something awesome here
Response.Write "oops, unable to access the table or view"
Response.End
End If[/CODE]
If Not(rs.BOF And rs.EOF) Then
cols = rs.Fields.Count
rows = rs.RecordCount
Do Until rs.EOF
' do something neato here
rs.MoveNext
Loop
End If
rs.Close
conn.Close
Set rs = Nothing
Set cmd = Nothing
Set conn = Nothing
Connection Management
I've seen more situations than I can count where a single page of code (script file, web page, etc.) makes repeated requests from a database in sequential order (as the page is rendered or the script is executed). Most often it's having to grab data from multiple tables and/or views, or execute multiple stored procedures or functions. In a lot of cases, the code doing the heavy lifting is being included from separate files (using "includes"). That's all nifty and modular, which is a good approach, but always be VERY careful with that approach that you don't have each module do it's own connection open/close management. This not only slows down the processing, but it requires more bandwidth and more load on the network and the database server as well.
A case in point might be a web page that renders a report of an employee, then it displays a table with performance evaluation records, followed by a table of employees managed by the employee in question. If those data repositories are all on different database servers that may be all you can do, but if they happen to be on one server, or even in one database, you should seriously review minimizing the number of open/close requests on your connections.
A brief sample of this using pseudo code:
open connection1
open recordset1
close connection1
open connection2
open recordset2
close connection2
open connection3
open recordset3
close connection3
might work a lot faster and better as...
open connection
open recordset1
open recordset2
open recordset3
close connection
Some people prefer to open a "global" or "session" connection, whereby the connection is opened upon login or initialization by each user session. The connection object itself is stored in the session stack and made available globally to that user throughout their session window. Each concurrent user has their own connection opened and maintained on a stack. Granted this makes it easier to run queries, updates, etc. without the overhead of managing connections at the more granular page/script level, but it definitely taxes the database server with a lot of unnecessary open connections. For a handful of users that may be fine, but with hundreds or thousands of users it can be a mess and make the database server drag.
Just some random thoughts after beer. Have any thoughts you'd like to share?
Saturday, 12 November 2011
I don't know why it's taken me so long to comment on this. It's been about a decade since I really became involved with Microsoft SMS and later: Configuration Manager. The issue I'm referring to is the permissions delegation on the "System Management" container in Active Directory. The documentation, as well as all of the blogs, white papers, video tutorials and so on, all explain how to create the container, and then delegate permissions to the SMS/ConfigMgr site server account (the computer "$" account) so it can publish schema information to it during the site implementation process.
Well, every single Microsoft exam beats the same mantra into our heads that we should always, always, always use the A-G-Dl-P (or A-G-U-Dl-P) method for granting permissions to resources. If that's true, we should then create a Domain Local group and a Global group, in which to place the ConfigMgr site server, and nest the group appropriately, and then grant that group permissions to the container. But they don't. When I asked a Microsoft engineer about this years ago he scratched his head (literally) and looked confused. Then he responded: "I don't know. I suppose it provides greater security since you don't have to worry about someone adding an unauthorized account to the global or domain local group." That surprised me a bit. I was about to respond to that with "Sooo...... the A-G-D-P method isn't as secure as direct assignment?" but we were interrupted. It's a trivial issue, I know, but it's just something I had to mention.
Well, every single Microsoft exam beats the same mantra into our heads that we should always, always, always use the A-G-Dl-P (or A-G-U-Dl-P) method for granting permissions to resources. If that's true, we should then create a Domain Local group and a Global group, in which to place the ConfigMgr site server, and nest the group appropriately, and then grant that group permissions to the container. But they don't. When I asked a Microsoft engineer about this years ago he scratched his head (literally) and looked confused. Then he responded: "I don't know. I suppose it provides greater security since you don't have to worry about someone adding an unauthorized account to the global or domain local group." That surprised me a bit. I was about to respond to that with "Sooo...... the A-G-D-P method isn't as secure as direct assignment?" but we were interrupted. It's a trivial issue, I know, but it's just something I had to mention.
"You can't reason anyone out of something they didn't reason their self into." - Henry
"If you automate a broken process, you only end up with an automated broken process" - Paul
"If you don't have time to do right, when will ever have time to do it over?" - Mike
"People who mistreat animals almost always have something seriously wrong in their head. Quite often the same thing that serial killers have." - My Dad
"Someone is about to get beaten with the rubber chicken" - Chris
"Some people were just born to take out the trash" - Tommy
"Don't make me smack you with my pimp ring on." - Tony
"If it ain't broke, we can fix it" - Me
"If you automate a broken process, you only end up with an automated broken process" - Paul
"If you don't have time to do right, when will ever have time to do it over?" - Mike
"People who mistreat animals almost always have something seriously wrong in their head. Quite often the same thing that serial killers have." - My Dad
"Someone is about to get beaten with the rubber chicken" - Chris
"Some people were just born to take out the trash" - Tommy
"Don't make me smack you with my pimp ring on." - Tony
"If it ain't broke, we can fix it" - Me
Wednesday, 9 November 2011
Looking at my Calendar, it looks like there about 45 days until I retire from blogging. I'm kind of looking forward to it actually. Sounds odd. I have various reasons for sticking to this self-imposed plan, but most of all it's about running dry on interesting topics to blabber about. I admire guys like Scott Hanselman, who can chug along blogging for over a decade. God bless him. I don't have that much to say, at least not that much interesting stuff.
I suppose if any of this tied into my personal income in some way I'd have a bonafide reason to push myself harder and squeeze a few more drops of precious kool-aid mojo from my raisin-sized brain, but alas, that is yet another fine quality I do not possess. I'm sure I'll find something to occupy my time and to which I will impart my usual verbal slaughtering. I'll keep you posted if anything comes up.
The picture below is of the chairs on the beach that I will never be able to afford to enjoy, but I can gaze at them and imagine being there. Not so bad. I'm sure a lot of people stuck in a hospital bed would gladly trade places with me.
I suppose if any of this tied into my personal income in some way I'd have a bonafide reason to push myself harder and squeeze a few more drops of precious kool-aid mojo from my raisin-sized brain, but alas, that is yet another fine quality I do not possess. I'm sure I'll find something to occupy my time and to which I will impart my usual verbal slaughtering. I'll keep you posted if anything comes up.
The picture below is of the chairs on the beach that I will never be able to afford to enjoy, but I can gaze at them and imagine being there. Not so bad. I'm sure a lot of people stuck in a hospital bed would gladly trade places with me.
In 1974, one of my brothers was badly injured in a collision between his 750cc Suzuki water-cooled street bike and a station wagon, driven by an old lady who thought she could make a left turn in front of him. She was wrong. They were traveling in opposite directions at 30 mph each. My brother was thrown more than 100 feet from the collision site, suffering two broken legs, a broken pelvis, a broken right arm (his writing hand), and a fractured skull. He lay in a coma for six weeks, as the doctors tried to soften the blow to my parents that he'd likely never regain consciousness, let alone return to a "normal life".
After coming out of his coma, and gradually getting out of the bed and hobbling around, he was awarded a settlement from the driver's insurance company and went down to cash the check. This was several months after the accident, and he was still on crutches and his arm still in a cast (attached to a shelf on the right-hand crutch). He couldn't sign the settlement check legibly, and his bank obviously balked. Thinking quickly, he suggested they contact a branch employee from across town, whom he'd known since high school, to provide confirmation of his identity. They called. The employee drove over, confirmed his identity and the check was cashed.
The driver's license didn't cut it. The Social Security card and birth certificate didn't help. The signature was all that mattered to that bank manager.
Working in the Defense industry for over twenty-five years, I've seen many identification systems come and go. The latest fad seems to be the photo ID "smart card", containing a chip with a PKI encryption key and some additional bits. So what? In most large corporate environments, the only people who can attest to your identity are your immediate coworkers, supervisor, and a few secondary people you interact with. But once you leave your facility and travel to another facility, populated with employees who have never met you, what does that do? So you have a badge with your photo on it, and an encryption key. Does that "really" confirm it's YOU that it is pinned to?
You sign contracts, forms, letters, agreements and waivers all the time. How does anyone know it's really YOU signing them? How often are you asked to show identification to prove who you are before signing things? At doctor's office counters? At your kid's school? How about signing in at the receptionist when visiting business offices? So much of "identity" is built on trust and confirmation. The gadgets and biometrical aspects are merely shoring up the fortress of trust for others to gain comfort. Think about it though: How do we really "know" who someone is?
Epilogue: My brother recovered over the course of several years, eventually, and after finishing up his Masters in Electrical Engineering, finished law school and passed the Virginia Bar. It took more than ten years for him to fully regain memory from the days leading up to the accident. For the first two years he didn't remember me or my siblings, let alone friends, neighbors, coworkers and many of his favorite possessions. He still has not regained his sense of smell. I told him that's not really a bad thing since few things smell good (which is why we value good-smelling things so much).
After coming out of his coma, and gradually getting out of the bed and hobbling around, he was awarded a settlement from the driver's insurance company and went down to cash the check. This was several months after the accident, and he was still on crutches and his arm still in a cast (attached to a shelf on the right-hand crutch). He couldn't sign the settlement check legibly, and his bank obviously balked. Thinking quickly, he suggested they contact a branch employee from across town, whom he'd known since high school, to provide confirmation of his identity. They called. The employee drove over, confirmed his identity and the check was cashed.
The driver's license didn't cut it. The Social Security card and birth certificate didn't help. The signature was all that mattered to that bank manager.
Working in the Defense industry for over twenty-five years, I've seen many identification systems come and go. The latest fad seems to be the photo ID "smart card", containing a chip with a PKI encryption key and some additional bits. So what? In most large corporate environments, the only people who can attest to your identity are your immediate coworkers, supervisor, and a few secondary people you interact with. But once you leave your facility and travel to another facility, populated with employees who have never met you, what does that do? So you have a badge with your photo on it, and an encryption key. Does that "really" confirm it's YOU that it is pinned to?
You sign contracts, forms, letters, agreements and waivers all the time. How does anyone know it's really YOU signing them? How often are you asked to show identification to prove who you are before signing things? At doctor's office counters? At your kid's school? How about signing in at the receptionist when visiting business offices? So much of "identity" is built on trust and confirmation. The gadgets and biometrical aspects are merely shoring up the fortress of trust for others to gain comfort. Think about it though: How do we really "know" who someone is?
Epilogue: My brother recovered over the course of several years, eventually, and after finishing up his Masters in Electrical Engineering, finished law school and passed the Virginia Bar. It took more than ten years for him to fully regain memory from the days leading up to the accident. For the first two years he didn't remember me or my siblings, let alone friends, neighbors, coworkers and many of his favorite possessions. He still has not regained his sense of smell. I told him that's not really a bad thing since few things smell good (which is why we value good-smelling things so much).
Who outfits the Space Shuttle? Lowest bidder
Who installs cafeteria equipment in the schools? Lowest bidder
Who builds vehicles for combat duty? Lowest bidder
Who staffs security at 99.9% of public venues? Lowest bidder
Who produces 99.9% of the generic drugs you ingest? Lowest bidder
Who prepares 99.9% of the food you buy at the grocery store? Lowest bidder
Who repairs the aircraft you fly between airports? Lowest bidder
Who QA's the software that runs "mission critical" systems around the world? Lowest bidder
Who digs and runs commercial fiber for broadband networks? Lowest bidder
Who makes 99.9% of the after market parts used in your car? Lowest bidder
Who installs cafeteria equipment in the schools? Lowest bidder
Who builds vehicles for combat duty? Lowest bidder
Who staffs security at 99.9% of public venues? Lowest bidder
Who produces 99.9% of the generic drugs you ingest? Lowest bidder
Who prepares 99.9% of the food you buy at the grocery store? Lowest bidder
Who repairs the aircraft you fly between airports? Lowest bidder
Who QA's the software that runs "mission critical" systems around the world? Lowest bidder
Who digs and runs commercial fiber for broadband networks? Lowest bidder
Who makes 99.9% of the after market parts used in your car? Lowest bidder
Sunday, 6 November 2011
I tried to get my voice heard by Autodesk for much of the period between 1996 and 2006, but eventually I just gave up. I'm not trying to badmouth them or anything. The reason is simple: they're just too big to hear a tiny squeak anymore. I was going through some old e-mails and notes from discussions I had with AE's at Autodesk University in 1997, 1998, 1999, 2000, 2002, and 2004 (the last year I attended). Here's a summary of ideas I put forth into the vacuum of space...
- Upgrade Visual LISP IDE (VLIDE) to have a more modern interface and license OpenDCL to make it on par with VBA for dialog design. (2003)
- Restore network licensing for AutoCAD LT (2004)
- Standardize on ONE format for all software updates (preferrably .MSP) (2009)
- Standardize the Network Deployment wizard to make nothing but MSI components, no stupid .exe (yes, I'm talking about FARO). (2009)
- Fix the .NET 4 and DirectX silent install problem when pushing a network deployment through Configuration Manager advertisements. (2009)
- Include the NetBIOS name of computers that register standalone activation when sending the e-mails to the contract license owner (help customers nail thieves on their own) (2005)
- Figure out what to do with Raster Design. Some customers deploy it with AutoCAD, Mechanical, Map 3D, and so on. The licensing gets confusing at times. (2008)
- Buy Vital LISP from Basis Software and replace AutoLISP with it (they were already closing the deal when I suggested it, so I was late to the party on that one) (1997)
- Merge Mechanical Desktop with Inventor or just kill MDT and keep Inventor but make your mind up! (again, they were already executing the plan before I thought this up, although they took their time finishing up) (2000)
- No more spread-out AU locations per year, do it in one location (1998, Boston, horrible)
Saturday, 5 November 2011
It's been a while. Ok, a few days, whatever. I felt an urge to vent about two things that really bother me. I was going to say that they piss me the **** off, but then I thought that might be too crass and anti-intellectual. Whatever. So anyhow, here they are:
"It's all in God's hands"
"Never give up on your dreams"
"Everyone's good at something"
I'm sorry, but all of these are over-simplified turds of wisdom. Here's why...
I'm not going to poo-poo anyone's religion. That's not my place. I have no right or authority to do that. But, at what point does something STOP being in God's hands? If "everything" is in God's hands, then that explicitly means NOTHING is "out" of God's hands. After all, you can't have something be "Always" and "Never", or "Always" and "Sometimes" at the same time. That's as impossible as keeping lawyers out of Washington DC. So, I've made it a small project to ask people who range from non-religious all the way up to uber-religious about this phrase. My questioning kind of follows Penn's logic, sort of, which is: If you release all your worries by saying everything is in God's hands, then why look before crossing a street? Why put a seat belt on? Why take a shower? Why do anything? After all, if it's in God's hands, then that means God will take care of EVERYTHING; leaving NOTHING for us to take care of. So, why even get out of bed? We should simply sleep all day and wait for God to take care of everything and bring it all to us. Right? God will take care of the rent, the food, the electricity, the water, we don't need to take care of anything. There is a name for people that follow that belief: dead.
But, no one accepts that view. At least, no one I've met. So that really means that not "everything" is in God's hands. Some things are left for us to take care of. But what? Where is that line? How do we, as mortals, decide for ourselves what God says is the line? Is it for us as individuals to decide? Is it per church? Per city? Per state government? Per nation? For some it means Cancer is a trip to the hospital, but for others it means staying home and praying, with no medical intervention at all. For some it means courts of law to settle disputes and infractions, but for others it means prayer, while for others it means stoning to death. If everything was truly in God's hands, we wouldn't need pastors, ministers, preachers, priests, rabbis, or whatever they call the authorities in other religions.
This nebulous, and mystical "line" divides us from the things that we are to let God handle, but "we" don't have a clear definition or belief of where that line is. We can't even agree if the line is straight or drawn like a crayon between the toes of a Tourette's patient on Red Bull. This is the essence of centuries of war (and millions of dollars in profit for lots of big corporations, I might add). Too many times it's used as a scapegoat or cop-out. Can't find a job? "It's in Gods hands". No, it's not. Go out and look for a job. Child gets a nasty cut and is losing a lot of blood? "It's in Gods hands". No. Take the child to a doctor immediately. I'm sure there are appropriate uses of the phrase, but it's becoming as overused as politicians saying "I have a plan".
"Never give up on your dream"
Adam Carolla has dissected this little turd on several occasions. There is a point where dreams are not only to be left at the altar, but ground into dust like a cigarette butt under a steel toe construction boot. Don't believe me? Just watch American Idol. Ask yourself what most of the first round cuts end up doing with their singing career. That's right: they go back to busing tables, serving burgers and changing oil. Let's face, if you're 85 and you had a lifelong dream to be a heavyweight boxer, and you hadn't made it yet: It's time to let that go. Then again, maybe that's your idea of suicide by right-hook, which at 85 might not be so painful and drawn out.
"Everyone's good at something"
No. They. Are. Not. For most of the human race, this is probably true. By "most" I'm thinking 80 percent. But if you've ever been around crack heads, ex-convict drug addicts or watched "To Catch a Predator", you should have confirmed that there are some folks who's only skill is being fertilizer. No one is good at everything, this is true. Most of us are good at something and not-so-good at many other things. But *not* everyone is good at something. They also have a TV show for people that haven't yet found their true calling, it's called Tosh.O.
"It's all in God's hands"
"Never give up on your dreams"
"Everyone's good at something"
I'm sorry, but all of these are over-simplified turds of wisdom. Here's why...
I'm not going to poo-poo anyone's religion. That's not my place. I have no right or authority to do that. But, at what point does something STOP being in God's hands? If "everything" is in God's hands, then that explicitly means NOTHING is "out" of God's hands. After all, you can't have something be "Always" and "Never", or "Always" and "Sometimes" at the same time. That's as impossible as keeping lawyers out of Washington DC. So, I've made it a small project to ask people who range from non-religious all the way up to uber-religious about this phrase. My questioning kind of follows Penn's logic, sort of, which is: If you release all your worries by saying everything is in God's hands, then why look before crossing a street? Why put a seat belt on? Why take a shower? Why do anything? After all, if it's in God's hands, then that means God will take care of EVERYTHING; leaving NOTHING for us to take care of. So, why even get out of bed? We should simply sleep all day and wait for God to take care of everything and bring it all to us. Right? God will take care of the rent, the food, the electricity, the water, we don't need to take care of anything. There is a name for people that follow that belief: dead.
But, no one accepts that view. At least, no one I've met. So that really means that not "everything" is in God's hands. Some things are left for us to take care of. But what? Where is that line? How do we, as mortals, decide for ourselves what God says is the line? Is it for us as individuals to decide? Is it per church? Per city? Per state government? Per nation? For some it means Cancer is a trip to the hospital, but for others it means staying home and praying, with no medical intervention at all. For some it means courts of law to settle disputes and infractions, but for others it means prayer, while for others it means stoning to death. If everything was truly in God's hands, we wouldn't need pastors, ministers, preachers, priests, rabbis, or whatever they call the authorities in other religions.
This nebulous, and mystical "line" divides us from the things that we are to let God handle, but "we" don't have a clear definition or belief of where that line is. We can't even agree if the line is straight or drawn like a crayon between the toes of a Tourette's patient on Red Bull. This is the essence of centuries of war (and millions of dollars in profit for lots of big corporations, I might add). Too many times it's used as a scapegoat or cop-out. Can't find a job? "It's in Gods hands". No, it's not. Go out and look for a job. Child gets a nasty cut and is losing a lot of blood? "It's in Gods hands". No. Take the child to a doctor immediately. I'm sure there are appropriate uses of the phrase, but it's becoming as overused as politicians saying "I have a plan".
"Never give up on your dream"
Adam Carolla has dissected this little turd on several occasions. There is a point where dreams are not only to be left at the altar, but ground into dust like a cigarette butt under a steel toe construction boot. Don't believe me? Just watch American Idol. Ask yourself what most of the first round cuts end up doing with their singing career. That's right: they go back to busing tables, serving burgers and changing oil. Let's face, if you're 85 and you had a lifelong dream to be a heavyweight boxer, and you hadn't made it yet: It's time to let that go. Then again, maybe that's your idea of suicide by right-hook, which at 85 might not be so painful and drawn out.
"Everyone's good at something"
No. They. Are. Not. For most of the human race, this is probably true. By "most" I'm thinking 80 percent. But if you've ever been around crack heads, ex-convict drug addicts or watched "To Catch a Predator", you should have confirmed that there are some folks who's only skill is being fertilizer. No one is good at everything, this is true. Most of us are good at something and not-so-good at many other things. But *not* everyone is good at something. They also have a TV show for people that haven't yet found their true calling, it's called Tosh.O.
Thursday, 3 November 2011
Some of you are probably thinking: "Huh?" or "What the ****?". Let me explain, see, for about ten years I actually put gas in my truck, bought food and otherwise lived on playing drums in various types of musicality in and around the podunk area of southeastern Virginia. I gave it up in 1990 when I sold my kit and devoted my time to my wife and family. Choosing my path to fortune and, well, whatever. So I still hold a special place in my heart for percussion. I played, at various times, with full kits, congas, timbales, djembe, and various metalic striking things (cowbells, bells, chimes, cymbals, gongs, etc.). I do miss it. But right now it's just not something I can entertain due to logistics and budget.
On with it then...
Buddy Rich
Vinnie Colaiuta
Steve Gadd
Terry Bozzio
Matt Sorum
Elvin Jones
Simon Phillips
Chad Smith
Mitch Mitchell
Keith Moon
Neil Peart
Ed Shaughnessy
Aynsley Dunbar
Ed Mann
Ian Paice
John Bonham
Airto
Tony Thompson
Rod Morgenstein
Dave Weckl
Paul Wertico
Bill Bruford
Steve Smith
Mickey Hart
Ruth Underwood (ok, tuned percussion, but still...)
Lionel Hampton
I'm sure I forgot someone that should be on this list.
On with it then...
Buddy Rich
Vinnie Colaiuta
Steve Gadd
Terry Bozzio
Matt Sorum
Elvin Jones
Simon Phillips
Chad Smith
Mitch Mitchell
Keith Moon
Neil Peart
Ed Shaughnessy
Aynsley Dunbar
Ed Mann
Ian Paice
John Bonham
Airto
Tony Thompson
Rod Morgenstein
Dave Weckl
Paul Wertico
Bill Bruford
Steve Smith
Mickey Hart
Ruth Underwood (ok, tuned percussion, but still...)
Lionel Hampton
I'm sure I forgot someone that should be on this list.
Tuesday, 1 November 2011
First off: I'm still reading the Steve Jobs biography by Walter Isaacson, and it led to this blog post.
Second off: I don't care much for Isaacson's writing "style", if you can call it that. This book should have been written by someone else. The phrasing is awkward and sophmorish, and it just seems creepy-weird for someone to refer to their "friend" by their last name at every turn. And not only that, but within each paragraph, instead of using standard MLA form, and using the real name once and then "he" and "him" for the remainder, he used "Jobs" throughout. Yes, I know. I thought it was written by Nancy Pelosi (i.e. "Jobs. Jobs. Jobs...")
Don't get me wrong. The core information is fantastic. The quotes. The stories. The references. They are all great stuff. Just worded poorly by a hack of a writer cashing in on a no-lose deal. If I could have picked anyone to write his biography it would have been Anthony Bourdain. That's just me.
But one thing stuck out that grabbed my attention right off the bat: Steve's preference for walking whenever conducting a discussion or meeting. I've always liked that. It's perfect. The movement, fresh air, and sunshine (even when cloudy) stimulate the brain and help you focus. The trick is to do it where there's not so much distraction that it interferes with the discussion. It doesn't matter if you're in a wheelchair, get out and move when you're having a discussion. It's the best way to do it. Steve was known for a lot of innovative and inventive things, but this is one that will be overlooked by most, but not by me. I hope it instigates others to follow his habit. Namaste.
Second off: I don't care much for Isaacson's writing "style", if you can call it that. This book should have been written by someone else. The phrasing is awkward and sophmorish, and it just seems creepy-weird for someone to refer to their "friend" by their last name at every turn. And not only that, but within each paragraph, instead of using standard MLA form, and using the real name once and then "he" and "him" for the remainder, he used "Jobs" throughout. Yes, I know. I thought it was written by Nancy Pelosi (i.e. "Jobs. Jobs. Jobs...")
Don't get me wrong. The core information is fantastic. The quotes. The stories. The references. They are all great stuff. Just worded poorly by a hack of a writer cashing in on a no-lose deal. If I could have picked anyone to write his biography it would have been Anthony Bourdain. That's just me.
But one thing stuck out that grabbed my attention right off the bat: Steve's preference for walking whenever conducting a discussion or meeting. I've always liked that. It's perfect. The movement, fresh air, and sunshine (even when cloudy) stimulate the brain and help you focus. The trick is to do it where there's not so much distraction that it interferes with the discussion. It doesn't matter if you're in a wheelchair, get out and move when you're having a discussion. It's the best way to do it. Steve was known for a lot of innovative and inventive things, but this is one that will be overlooked by most, but not by me. I hope it instigates others to follow his habit. Namaste.
You wrote a cool script or program. Awesome. And then one of your users launches it. It prompts to enter a date in a text box. The user enters "Dog". Your awesome script/program implodes. The user immediately turns to his/her coworkers and proclaims your code is a piece of shit and you suck at writing it.
Is that person wrong?
11 Most Common Mistakes with Error Handling
Is that person wrong?
11 Most Common Mistakes with Error Handling
- Forgetting to handle errors
- Not checking data types
- Not checking formatting ("8005551212" or "800-555-1212" or "(800) 555-1212", etc.)
- Not checking/correcting string case where case matters ("Foo", "foo", or "FOO"?)
- Not trimming string input before Boolean operations (does "FOO " = "FOO" ?)
- Not controlling the UI (checkbox, radio buttons, lists, instead of text boxes)
- Not checking for specific error type following an exception
- Building error PREVENTION into the UI
- Documenting your code (especially in places where exceptions are most likely to occur)
- Using outdated error handling (if your language supports Try/Catch/Fail, etc. use it!)
- Forgetting to manage exit codes (raising errors)
The answer to the question above is "No", but they should still be smacked in the face just for being obnoxious.
Subscribe to:
Posts (Atom)