Why I Haven't Bothered with HTML 5 Much Yet

I'll let the pictures do the talking this time...

Read More

How Old is a Computer?

Let's pretend it's exam time, mmmkay?  Goody!  I know you're jumping out of your seat with joy right now, so let's begin.

Scenario:  You're at your office desk on Monday morning, giggling out loud while reading the latest Dilbert strip on the web, when your phone suddenly rings. You normally ignore it, but the LCD (ok, maybe you have Lync alerts enabled) shows "CIO" is calling.  You sip your coffee/RedBull/Monster/hot tea/etc. and swallow before answering.

You: "Systems Engineering.  You stab 'em, we slab 'em.  How can I help you?"

CIO: "I need a report that shows how old each computer in our organization is, sorted by the oldest at top.  How soon can you have that to me?"

You: "Uhhhhhhhhh....."

You pause and realize you have Microsoft System Center Configuration Manager 2012 SP1 installed and everything is working smoothly, including inventory and reporting.  Then you realize that "age" isn't so clear cut of a thing when it comes to computers.  To avoid sounding like an idiot, you respond with your usual clever answer:

"I think I may have what you need, but let me verify anyway and I'll get back to you as soon as possible.  Would that be okay, [sir/ma'am]?"

CIO: "That's fine.  I'll need an answer before the board meeting at noon."

*click*

Question:  What is the most reliable method of determining the "age" of a given physical computer (server, desktop, laptop, tablet, etc.):

1. The install date of the operating system
2. The BIOS firmware date
3. The dateCreated property of the Active Directory account
4. The Purchase Order (PO) date
5. The manufacture's model sticker on the back/underside of the box
6. The CPU version information
7. The motherboard version information

Answer:  __ ?

4. The Purchase Order (PO) date

Unfortunately, options 1, 2, and 3 are easily changed by routine processes in the environment.  Option 5 isn't accessible from a programmatic (e.g. WMI, SNMP, etc.) perspective.  Options 6 and 7 don't necessarily indicate an aggregate "date" on which the computer began "life" (whatever that's defined as being).

That leaves option 4.  If your purchase order and invoicing system is online (rather than paper), and you have the means to tap into its database, you could run some queries and get what the CIO needs.  If the database is linkable to the Configuration Manager site database, you can do some SQL "joins" to leverage the goods on both sides of the aisle.  This makes for an easy CIO-pleasing result.

If your PO system is paper-based, or isn't accessible to running custom reports, well, you may be shit-out-of-luck.  But all is not lost!  If you stop and think about who was responsible for requesting the shitty, inefficient PO system for the organization, and that person is not on your list of friends, it could be an opportunity to play the office politics game and toss out one of those "See! I told ya so!" cards and call for a show of hands.  Then again, you may simply be shit-out-of-luck, in which case, you might want to finish your drink, take a deep, slow, meditative breath, and call the CIO back with the not-so-good news.

It's surprising, to me anyway, how often this situation arises.  A "computer" device isn't as monolithic as a human in some respects, which may sound really strange and ironic. A human has a single "birth date", which can be verified via a birth certificate, passport, military I.D., or driver's license.  A computer starts off with a duality of hardware + software, and even then, some of the hardware isn't so hard-coded (firmware updates).  If only computers had a singular, reliable, consistent "birth certificate".  Imagine what the little inked foot prints might look like. :)

Read More

Book Prices, Obama-Care, and Meteorites

What do these three things have in common?  I have no idea.  But I was thinking about blaming the latter two for why I had to raise the prices on two of my Amazon e-Books:  The Visual LISP Developer's Bible, 2011 Edition, and the original Visual LISP Developer's Bible (2003).  I raised each by $1.00 (USD) to help offset the overhead of supporting my four kids (yes, four, go ahead and joke), who all live at home.   I admit it: I slept through Sex-Ed too often, but I did pay attention when they talked about female anatomy.  That has to count for something. Four? (ba-da-bing!)

I tried changing the locks, moving and wearing disguises, but they found me anyway.  I'm kidding. Although, the idea has crossed my mind a few times.  Anyhow, the prices went up from $6.99 to $7.99, and $3.99 to $4.99, respectively.  I'm sure that will piss off some potential customers, but as the saying goes: You can't please all of the people all of the time, but you can always please yourself (oh, hey! I won't go there).

Read More

Red Alerts for Bad Programming - Part 1

Even now in 2013, it often seems like certain aspects of our "civilized world" haven't evolved very much, if at all. I'm still amazed at what non-technical folks are willing to put up with from so-called (usually self-proclaimed) "technical professional" people. So, in order to help the non-technical peeps a little bit, I thought I'd offer a list of things to watch out for when dealing with the geeks that want their money.  This is going to have to be a multi-part series, so this is "Part 1" to kick things off.

Part 1 - Wading Into the Cesspool of Contracting-Out Work

Knowing What You Want

If you don't know what you're looking to hire someone for, holy cow, you are in for a dangerous ride!  Don't let that sinking, helpless feeling consume you and sway you into thinking/believing that you can trust the person you plan to hire to help you find what you really want.  And please don't confuse this with the scenario where you've been working with someone long enough already to have some trust and faith in what they recommend.  I'm not talking about that situation.  I'm talking about the initial engagement, your first meeting or first encounter, with the person(s) you are considering to pay to solve one of your business challenges.

Even if you know next-to-nothing about applications, software, web development, web design or any of the techno-babble-mumbo-jumbo, you have Google.  You have Bing! and Yahoo! and a bazillion web sites available to you to help you find what you want.  There are millions of articles, blogs and eBooks to help you educate yourself on everything from the most general aspects, down to the insanely granular minutiae  and everything in between.  There's no excuse in this age of the Internet to remain ignorant about something you're about to shell out hard-earned money for.

Basically, the more you become familiar about the things you are looking to have done for you, the more likely you are to be able to:

1. Ask intelligent questions and get meaningful, understandable answers
2. Communicate your ideas within the context of the limitations of the technologies involved
3. Be better-prepared to thwart bullshit schemes and scams
4. Intuitively relate certain aspects of the project with complexity and cost impacts
5. Impress others at social gatherings

If you don't know what HTML or XML are, good places to start are W3Schools (www.w3schools.com), or About.com, or but those are just two out of a million useful web sites that offer free, yet incredibly helpful information and examples. If your business challenge is worth paying your hard-earned money to solve, it's worth you investing a little time to become intelligent about the ways that challenge can be solved. (for the record, I have no relationship of any kind with any of the links mentioned above, nor do I reap any benefit from you going to their sites, other than that awesome, glowing feeling of knowing that I possibly helped another person learn something new).

Communicating What You Want

Check this out.  This is a scenario I personally witnessed more than a dozen times in the past five (5) years alone:  Customer sits down with a web developer to discuss building a new web site.  Customer lists the following "requirements" for the developer to accommodate:

1. Must be able to update content to add "News", "Events" and photos.
2. Must have a catchy, eye-grabbing animated graphic on the main "home" page.
3. Must have their official company logo in the banner on every page.
4. Must have a link to "Contact Us"

Developer nods in agreement, slides the SOW across the table, then the contract.  Both parties sign off and the developer heads off to code away.

A few weeks later the developer says "All done!  Here's your new web site!"  It looks all spiffy and has the official company logo and name on the banner.  It has the catchy, Flash-enabled animated graphic on the home page.  There are links to "News", "Events" and "Images", and it has a "contact us" link.

The customer starts poking around, smiles and strokes the final check payment (or clicks the PayPal invoice link, etc.).  After a few days of continued poking, the customer discovers that they can't seem to find a way to enter or upload "News" items, "Events" or upload photos.  And the "Contact Us" link simply opens a "mailto://" link, rather than a web form with some additional options to help categorize the nature of the contact request.  The customer feels somewhat frustrated and contacts the developer.

The developer reiterates the list of "requirements", and categorically insists each was satisfied according to the wording. The customer then realizes they never included details about "WHO" could upload content, or "HOW".  Nor were there any specifics provided about the contact request feature.  Now the developer insists that, since the original terms were met, and paid for, subsequent requests to update content would constitute additional work (service requests), and additional fees would apply.  The customer is dismayed and pissed off.

Who's to blame?

You can blame the developer for not asking more thorough questions during the requirements discussion.  You could also blame the customer for not stating their requirements more accurately and concisely.  You would be correct on both, actually.

You might think this is a fictional scenario, but I have met so many clients that have had this EXACT same situation occur, that it's become part of my standard requirements interview topics.  Additional questions to ask (and, this is by no means an exhaustive or complete list) could include:

• Who exactly (individual names) will need permissions to change things on the site?
• What specific things/features/content should each person have permission to modify?
• On your contact request form, what kinds of information do you want to request from the submitter?
• Do most of your customers surf the web from a computer or from a phone or tablet?
• What is the target demographic or your intended audience?

The list I use is actually around thirty questions, but it varies by the nature of each engagement. Other topics include search features, SEO, advertisements, visitor tracking, types of content, mapping and charting, multimedia and streaming, and more.  The point isn't that you try to ask every possible question, but to ask every possible RELEVANT question pertaining to the task or project at hand.

Too Quick/Eager to Start Working

You might think this is a good thing, but in the context of providing a quality, comprehensive service to customers, a good professional will be patient (or, as patient as YOU are anyway).  The most important step in the initial phase of a new engagement is gathering requirements.  You might think that's boring or unimportant, but oh boy.

Let me put this into a different context: A PRE-OP visit with a surgeon.  You say something like "I want to lose weight.  Quickly!".  The doc says "No problem, I'll sedate you and get eighty pounds off of you in an hour.".  You jump up and scream "Holy shit!  When do we start!?".  He grabs the scalpel and gas mask and asks you to lay back on the table.  If you did that, you might wake up with both your legs amputated.  Yes, you may have discarded eighty pounds, but that probably would NOT be what you had in mind.

You can smirk and think "yeah, well, that's a medical scenario, not a computer scenario."  Here's what I'd say to that: If you woke up and found half of your business-critical systems no longer worked because you accepted a quick offer without reviewing the details and signing off on every single line item, well, how do you think you'd feel then?  Somewhat like having your business legs amputated, probably.  But, how would your boss feel about that?  If you're self-employed it could be a catastrophic mistake.  Yeah, you got your shiny new web application, but oops?  Entering information from the new app seems to be wiping out information in your business-critical CRM database, and your most recent backup is missing a lot of recent changes.  Dang!

Be specific.  Be nit-picky.  Be detailed and meticulous about what you want, and what you need (and do not ever confuse those two!).  If you want rounded, magenta, 4px wide corners on the top banner of your application / web site, then spell it out.  Better yet: provide an example.  Draw it up in PowerPoint or draw it on paper and take a picture of it.  Whatever. If you don't document exactly what you want, don't expect to get exactly what you want. Which brings us back to the part about Knowing What You Want.

Coming Soon...

Seven Warning Signs of Highly Dysfunctional Programming.  Don't worry, it's not going to be repeat/rip-off of this ancient post.  Check back soon!  It should be a fun read! :-)

Read More

Bullshitilizer 2013 Ultimate Edition

If you ask anyone who has worked in a large office (i.e. corporate) environment, whether or not they've found themselves in a situation where they had to change course, in mid-discussion, to avoid getting caught wasting valuable "company time", they will usually nod in agreement.  Standing in the doorway, having a heated discussion about any (or all) of the following topics:

• Last night's sports game
• Recent (or upcoming) episodes of "The Walking Dead"
• Gun Control
• Abortion
• Immigration
• Religion
• Politics
• Best TV SitCom
• Best late night talk show
• Gadgets (cameras, phones, etc.)
• Hot office babes (if you have any) and what they're wearing today

Suddenly, the CEO/CFO/CIO/CTO/CSO/CMO/CBO/CAO/COO/CXO turns the corner, with a dower look on his/her face.  The expression says "I'm ready to fire the next bastard I see shooting the shit in the hallway!!!"

What do you do?

Fear not!  I have a handy list of conversation jump-starters to pull out just for those pants-crapping moments.  But there's an important catch here:

You can't just switch conversation gears without being careful to select a topic that logically fits with your job role.  In other words, if you are a Network engineer, you don't want start jaw-jacking about Git, or UAT, especially if the "suit" passing by knows what your job role is.  So I've grouped them by job role to help you out.

For each functional group/department/team/division headlined below, use one of the phrases listed beneath it.  Each is intended to jumpstart a new conversation, but will only work if your accomplice is clued-in beforehand, unless he/she is astute enough to pick up on the hidden agenda and can improvise along with you.  And remember: These will only work if you keep a straight face.

Applications Development

• "I was looking over the changes in Service Pack 1, and ..."
• "I'm not sure I understand why they want to do the change that day, instead of..."
• "Have you seen the [product_name] from [vendor_name] yet?"
• "Oh yeah! I can't make that meeting because I'm scheduled for another at the time."

Applications Support

• "I was looking over the changes in Service Pack 1, and ..."
• "I'm not sure I understand why they want to do the change that day, instead of..."
• "Have you seen the [product_name] from [vendor_name] yet?"
• "Oh yeah! I can't make that meeting because I'm scheduled for another at the time."

Help Desk

• "Did you see that call about Outlook Inbox synchronization this morning?"
• "I'm not sure I understand why they want to do the change that day, instead of..."
• "Have you seen the [product_name] from [vendor_name] yet?"
• "Oh yeah! I can't make that meeting because I'm scheduled for another at the time."

Information Security (aka "InfoSec")

• "I was looking over the changes in Service Pack 1, and ..."
• "I'm not sure I understand why they want to do the change that day, instead of..."
• "Have you seen the [product_name] from [vendor_name] yet?"
• "Oh yeah! I can't make that meeting because I'm scheduled for another at the time."

Network Engineering

• "I was looking over the changes in Service Pack 1, and ..."
• "I'm not sure I understand why they want to do the change that day, instead of..."
• "Have you seen the [product_name] from [vendor_name] yet?"
• "Oh yeah! I can't make that meeting because I'm scheduled for another at the time."

Project Management

• "I was looking over the changes in the second review, and ..."
• "I'm not sure I understand why they want to do the change that day, instead of..."
• "Have you seen the [product_name] from [vendor_name] yet?"
• "Oh yeah! I can't make that meeting because I'm scheduled for another at the time."

Systems Engineering

• "I was looking over the changes in Service Pack 1, and ..."
• "I'm not sure I understand why they want to do the change that day, instead of..."
• "Have you seen the [product_name] from [vendor_name] yet?"
• "Oh yeah! I can't make that meeting because I'm scheduled for another at the time."

Good luck!

Read More

The Next Book

I have given up on the book-topic survey, as far as relying on the votes as a means for determining which course to pursue. The votes are just too scattered, with no clear "winner". (I said "scattered".. heh heh. Ok, too easy an not clever enough).

(do e-ebooks require e-glasses too?)

Anyhow, I decided to go with the book sales numbers to point me in the direction to go. Based on two months of numbers (December 2012 - February 2013), the topics appear to fall in place as follows (from most to least popular):

1. Software packaging and deployment
2. Visual LISP Programming
3. AutoCAD Network Administration and Packaging/Deployment
4. IT Project Management

Shoving this through a secondary logic-filter (somewhat like processing beer through a Randall), hopefully this arrives at a clear direction.  Here goes...

1. The responses from my recent blog post about Software Packaging were unexpectedly good.
2. Visual LISP is a dying language, unfortunately.  It was fun while it reigned supreme, and more fun when I actually worked with it.
3. I'm caught  up on 2013 network deployments for Autodesk products
4. I pretty much covered what I wanted to in IT Project Management

So 1 + 1 = 1, errr, uhhh, what I mean is that I think I will follow up "Grinding Gears" with a newer/better-tasting/less-filling/no-wait-I-meant-MORE-filling version, focusing on Software Repackaging and Testing.  I think that makes sense.  If you strongly disagree, share your thoughts (and if you own a copy of any of my books, and you haven't posted a rating or feedback on Amazon yet, please do so?  I really depend on that to help me focus on what you want me to write about and what needs more work).

Read More

The Not-So Fine Art of Software Re-Packaging and Deployment

New and Improved / Amended Version!

Note: Thanks to Mikko Järvinen for reminding me about "Uninstall Testing", also known as "Package Removal Testing" or "PRT".  I added the changes below in blue (just FYI).

I had to prepare the following for an internal FAQ document to help our "customers" better understand the ramifications, and pontifications, with respect to processing a request to have software packaged (re-packaged) for deployment to their computers.  It's a work in progress, but this is where it stands right now...

Overview

Software can be installed in a variety of ways, but when it comes to installing software on a large number of computers in the shortest time, AND with the highest level of consistency and reliability, it requires a little more work.

Unfortunately, software vendors do not follow a common playbook when it comes to packaging their products for installation. Some products are packaged in a way that makes it easy to install them using automation tools. Most are not. When software is not packaged in a way that lends itself to being installed easily, it often requires "repackaging".

Packaging vs. Re-packaging

Packaging is the process whereby a software product is compiled into an original installation package. This is often a single ".exe" or "msi" file, but in many cases it results in a collection of many folders and files. An installer that comes as a single ".exe" file is referred to as an "Executable installer". An installer that comes as a single ".msi" file is referred to as a "Windows installer package".

Executable installer packages are the most common.  These are the familiar .exe packages (e.g. setup.exe). They often provide a built-in mechanism for launching them along with a list of options or settings to pre-configure the installation without having to step through a series of dialog input forms. In many cases, this includes the option for running it in "silent" mode. "Silent" mode allows the installation to run without displaying any forms or prompting for user input. This is essential for mass deployment using automation tools such as Microsoft Configuration Manager or Group Policy.

Repackaging is the process of taking the smelly crap that some vendors hand you, and mooshing it up into a new, less-smelly ball of goodness that can be installed "silently" and pre-configured, just the way your precious customers are begging for.  There are no limits to what qualifies as "repackaging".  It can be wrapping the installation parameters within a script file (pick your script language, it really doesn't matter that much), or it can be squeezing it through the meat-grinder of something like InstallShield, or AdminStudio, to make a whole new installation binary (i.e. a new .EXE, or a Windows Installer .MSI file, etc.).  I won't even bother with discussing .ZAP files because I just ate.

Did I just say that it doesn't really matter what scripting language you use? Well, that's sort of true.  I don't recommend you just pick a scripting language without considering how it will fit into what the rest of your organization uses.  Even more important, you need to consider what the environment will support (if you do everything in one language, you might find out some of the target devices don't support it).

Complications and Time Factor

One of the most commonly asked questions about packaging and re-packaging is "How long does it take?" The answer is always "It depends.". No two software installations work exactly the same. Because of this, it is impossible to predict how long it will take to get a workable unattended installation package prepared and tested. Some of the variables that play a critical role in determining the time it takes to re-package an installation include:

• The original installation package format and integrity
• Vendor licensing and activation requirements
• Removal or Upgrade of older versions
• Checking for, and resolving prerequisites
• Per-machine vs Per-user configuration settings
• Operating System dependencies
• Business-specific configuration settings
• Vendor compliance with Microsoft's recommended guidelines
• Client/Server dependencies

This is not an exhaustive list, and each of these can greatly impact the difficulty with re-packaging the installation. In some cases, it can render the re-packaging process ineffective, requiring manual installation and configuration; something we try to avoid at all costs.

Other factors that should be factored in:

• The relative chemical stimulant consumption rate of the under-paid coders hired by the vendor (on contract, of course).
• The address of the mobile trailer they call an "office"
• Whether they include "Grateful Dead Reunion Tour" dates as paid holidays
• When you say "InstallShield" and they respond with "What's that?"
• When you really have to explain to the vendor what a "silent install" is
• When you call their "support line" and reach the owner/president/senior architect/coder guy every time.

I'm sure I could add more, but I'm too tired right now.  Let's move on...

Testing and Validation

Once an installation package has been developed, the next step in the process is to test it. In most cases, this is done by using "test" computers whereby a designated user will "remote" into the test computer from their own location and test the software installation. This eliminates the need for customers to travel around to physically sit down at the test computer and allows greater flexibility with scheduling.

In most cases, a virtual machine "test computer" will suffice just fine.  It doesn't matter what you prefer to work with (VMware, VirtualPC, VirtualBox, etc.) as long as it works and users can remote into it and do what they do (crash and break things, usually).

In some cases, usually when special hardware devices are required to be used with the software, it may be necessary for the customer to physically sit down at the test computer and log on, so they can use the hardware devices properly.

The process whereby customers test the software prior to it being deployed into production, is referred to as "User Acceptance Testing", or UAT.  But be careful, as UAT is *NOT* the entire testing process.  It's just one piece of it.

The most basic testing process goes something like this:

1. Install the application using the normal means, on an isolated test computer.  This helps the repackager get familiar with how the application "normally" installs, and what options and settings it provides along the way to completion.  This is sometimes called "Installation Analysis Testing" or IAT.  It's also equally important to use this step for documenting the "footprint" an application installation leaves on a computer.  Having a complete list of changes it makes to the Registry, File System, Services and security environment, are all crucial pieces of information. This is required for making sure that you build an uninstall package that does a thorough job of cleaning up when the application is removed.
2. After repacking, use the new repackaged package (a mouthful, sorry), to do the install to verify that it (A) installs properly, even silently, and (B) launches and functions properly after installation. This is sometimes called "Initial Package Testing" or IPT.  After running the IPT, it is vital that you confirm that the installed application functions properly. This also adds a new dimension to the "footprint" by virtue of launching and using the application, which often initiates a chain of post-installation configuration processes that modify additional things in the Registry, File System, Services, and so forth.  This is where a wrench often comes flying in from left field during the uninstall testing (IRT), so be prepared to make some adjustments to your uninstall package.
3. After the repackaged package has passed IPT, it's time to load it up into your deployment/distribution system (i.e. Microsoft System Center Configuration Manager) - (and you thought I couldn't string a bunch of words together into a longer name than that, pffft!).  Once loaded into your deployment system, the next step is to target a test computer to verify that the deployment system delivers the installation package, and installs it successfully.  This is sometimes called "Package Deployment Testing" or PDT.
4. After PDT, it's time to go to User Acceptance Testing, or UAT.  In most situations, you can use the same targeted test computer from the PDT without have to do another deployment, but the choice is yours (and varies by individual circumstances).
5. Once UAT is complete, you should be ready to remove the safety lock and fire with both barrels.  In other words, you should be ready to go to Production Deployment.

Some important notes pertaining to the above gibberish:

• Steps 2, 3 and 4 should be performed on a test computer for each type of target configuration.  In other words, if you will be expected to deploy this to Windows XP, Vista, Windows 7 and Windows 8 computers, you should definitely perform each test on an appropriate test computer.  And don't forget that 32-bit and 64-bit configurations add another layer of complexity (and testing).
• If your target user base does not (generally) have local Administrative permissions on their computer device, make sure you package and test with that expectation.  And more importantly: Be sure to have a user account logon and launch the application the FIRST TIME after being deployed, so that it will behave as it would on the other 99.99% of the target clients (unless you expect to walk around, or remote into, every computer after the deployment - which would probably suck).
• Useful tools in your arsenal for developing installation packages are InstallShield and AdminStudio.  But in addition to their primary capabilities, another useful aspect of AdminStudio is to use the Repackager "snapshot" feature to help compare "before" and "after" system states when doing your Uninstall development and testing.  For example, you can take a "before" snapshot, install and run the application, and then take an "after" snapshot.  The results of comparing both snapshots will reveal what aggregate changes were made to the system, thereby helping to shine some light on how to develop an effective package for removing the application completely and cleaning up behind it.

The level of testing you employ will depend upon the nature of your environment obviously.  The smaller and less complex an environment is, the less likely you will need to perform as many phases of testing. But it never hurts to test more than you think you should.  It usually saves you from yourself later on (if your poorly-tested, bad packaging output lands on 10,000 devices over a weekend, your Monday will very likely suck ass indeed).

Deployment

Once a software installation package has been tested and approved by the customer, the IT department can then begin to deploy it to the requested devices. The method we use is an automated deployment tool named Microsoft System Center Configuration Manager.

Final Thoughts

Software Packaging and Repackaging (two distinct processes) are a combination of science and art. While based upon technology (science), there is a lot of human intuition (art) involved as well.  If you expect to master these things using one or the other alone, you will be in for a tough time.  Also, be prepared to consume additional quantities of caffeine.

Read More