Campaign Advertising Template

OPEN: Still-shot of opponent with a grim or clueless expression, panning slowly across view at awkward angle.  Overlay faded images of construction workers, people frustrated with bills, and traffic jams

NARRATOR: "[Opponent] says [he/she] is going to create jobs, but [his/her] plan will actually DESTROY jobs and crash our fragile economy.  [He/She] wants to raise taxes, and send American jobs overseas.  Don't let [him/her] get away with this!  Help us save American jobs and save America.  On [Date], vote for [You]."

DISPLAY:  smash-cut to still shot of candidate smiling and shaking hands with ordinary-looking white folks then ordinary-looking black folks.  smash-cut to video clip of small group discussion with candidate listening intently and nodding in agreement with confident grimace.

NARRATOR2: "This ad was sponsored by [insert PAC tax-avoiding-group-name] and the [Party Name] party."

Now:  Run out and vote.  Remember that since "every vote counts", YOUR vote will count too, and your candidate will win.  If they don't, then your vote didn't count, but that's impossible, so your candidate has to win.

Read More

Error Handling: An Example

Consider the following standard WMI query for a moment. Look at the code for a few seconds, at least...

[CODE]

strComputer = "computer123"

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") Set colItems = objWMIService.ExecQuery("Select * from Win32_PhysicalMemory",,48)

For Each objItem in colItems Wscript.Echo "Caption: " & objItem.Caption 

Next

[/CODE]

What could go wrong? What if "Computer123" doesn't exist?  What if "Computer123" is offline, or the firewall prevents a connection?  What if your user account doesn't have permissions to query remote WMI?  What if you typed in the wrong WMI class name, like "Win32_RAM" or something else?

You might get something like this...

[OUTPUT]

C:\Scripts\wmi-test.vbs(3, 1) Microsoft VBScript runtime error: _
The remote server machine does not exist or is unavailable: 'GetObject'
[/OUTPUT]
Is that a good way to handle this failure?  What if we add some explicit error checking and then handle the error?  Let's try this...

[CODE]

strComputer = "computer123" On Error Resume Next

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") If err.Number <> 0 Then

wscript.echo "unable to connect to: " & strComputer

wscript.echo "error: " & err.Number & " / " & err.Description

wscript.quit(err.Number)

End If

Set colItems = objWMIService.ExecQuery("Select * from Win32_PhysicalMemory",,48)

For Each objItem in colItems Wscript.Echo "Caption: " & objItem.Caption 

Next

[/CODE]

Now, if we run this and "Computer123" is not accessible, we should get the following...

[OUTPUT]

unable to connect to: computer123
error: 462 / The remote server machine does not exist or is unavailable

[/OUTPUT]


If we check %errorlevel% is should be set to 462 now as well.  This is an example of raising an error "implicitly" or simply passing it up without modifying it.  If we want to force our own error result value, we can simply modify the wscript.quit(value) statement to use our own numeric value...

[CODE]

strComputer = "computer123" On Error Resume Next

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") If err.Number <> 0 Then

wscript.echo "unable to connect to: " & strComputer

wscript.echo "error: " & err.Number & " / " & err.Description

wscript.quit(5)

End If

Set colItems = objWMIService.ExecQuery("Select * from Win32_PhysicalMemory",,48)

For Each objItem in colItems Wscript.Echo "Caption: " & objItem.Caption 

Next

[/CODE]

Now, the exit code (or %errorlevel%) value will be 5 when it fails for *ANY* reason.  There are situations when you will want to force a static error result, and situations where you want the real error value.  It's nice to know you have that option, and YOU have control over it.

Enjoy!

Read More

The Next Book Project

It might suck.  It might be good.  One thing's for sure: it's going to be different.  The project has begun.  Something I had to consider carefully for this one: I tend to express myself much more open on my blog, and on Google+, etc. (I gave up on Twitter), than I have in my books.  For this one I'm using the same voice.  Damn it: there is a place for humor in technology.  Just look around you at the office.   If you have something particular in mind you'd like me to include or discuss in this, now is the time to let me know.  You'll get your name mentioned if it makes it into the book. Ooooooh!

Target release is set for December 2011.

Read More

What is It?

Apple:  iBox


Microsoft:  Microsoft System Center Ultimate Storage Container Enterprise Edition 2012 R2


Ubuntu:  Beasty Bunghole


McDonald's:  McBox


U.S. Dept of Defense:  Container, Corrugated Paperboard, Type 1, Grade B, Style 4


IBM:  m350a


Fukushima Evacuee:  新スタート


Homeless Person:  Home


Cat:  Play house


Cockroach:  Luxury Liner

Read More

Thoughts of Autonomous Robotic Combatants

A considerable amount of money has been spent, and is being spent, on research into the area of autonomous mechanized combat tools.  While the accomplishments and praise bestowed upon the renowned aerial "unmanned" drone program are now passe, don't ever think that it marks some sort of end to this endeavor.  Oh no, my friends.  Having worked in the defense contractor world for a few decades, and having friends in all branches and fingers of the military, military research, intelligence, contracting, and gray areas in betwixt, I've soaked up a pretty good feeling of where things are at now and where they're likely going in the not-too-distant future.  Am I about to divulge some sensitive stuff?  Oh hell no!  I am simply going to muse about things that anyone could derive from what they see on the TV and Internet every day.

What is more efficient?  Centralize command and control, or networked self-control?  Think about how this applies to network operations management.  How does System Center Operations Manager work?  It can use "agents" or work "agentless".  When is it best to use one path or the other?  It depends.  What about Configuration Manager?  It uses agents.  Why not agentless?  Think about how each works and how various aspects of the aggregate processing model works with regards to server versus client.  Ok, now apply that to a mass deployment of mechanized solders in a rugged and hazardous battlefield terrain.  Think of the difficulties that exist with remote communications.  Weather and terrain disturbances render communication systems useless so often as to become routinely expected.  Human pilots can perform autonomous decision-making and rationalization without a connection back to the bunker.  Why wouldn't robots/computers?

We can fly drones from comfortable recliner chairs in climate-controlled living rooms in some suburban strip mall.  But when sand storms roll in, or major aerial disturbances and heavy lightning, fog, etc. they can be grounded for hours, even days.  Solders keep moving regardless of weather.  At the very least, they can camp out and move on when things clear.  Drones have to come back to a safe home base, often far from the battle field.  Do you see where I'm going with this yet?

In order to implement unmanned combat machinery that can function similarly to their human counterparts, they will absolutely have to be equipped with their own decision-making / rationalization capability.  They can uplink/downlink to headquarters obviously, just as human solders do, so it's not necessary that there be NO umbilical cord to rely upon.  But a 24x7 umbilical cord is totally unnecessary and would be a huge impediment. These machines would have to be as mobile, as perceptive, as coordinated and as "smart" as their human counterparts if they are to be of any use.  Keep in mind that aerial resources cannot win a battle alone.  Ground and sea-based resources will always be required, because they would otherwise be exploited as a workaround by their enemies.

Making a ship or submarine semi-autonomous is a no-brainer.  The only thing that has kept that concept from becoming reality is a horde of crusty old white-haired Naval officer pukes that can't stomach the idea of their ancient way of life might be replaced, even for the good of our national defense.  Nope  Tradition has a bulkwark that won't be moving anytime soon.  Some things will never change, at least no time soon.  There are many who sincerely believe that the only reason the U.S. Air Force went ahead with the drone program was to piss off the Navy.  At the very least, to make the Navy look old, outdated and ineffective.  It's worked, to a certain extent too.

I'm sure you thought I was going to paint some picture of the backdrop of Terminator, iRobot, or Iron Man, but I'm not.  The basic gist of Terminator was that some central computer "skynet" had begun educating itself at a "geometric rate" and in the panic to stop it, the humans tried to unplug it, so it launched rockets to force a counterstrike.  Clever, but not likely.  That's too much of a peak scenario.

As Americans, we live and die by the "boiling frog syndrome".  Push something radically different on people too suddenly and you get a violent backlash.  But if you ease it on them ever-so slowly, over a long enough time, and they will willingly accept it.  Don't believe me?  If you're over 35 years old, just look at all the shit that has changed in our culture from when you were a kid.  Things are "normal" now that would have been considered absolutely illegal or blasphemous back then.  Why?  Why do we accept those things now?  How did they come to pass?  Because they were gradual implementations over years, even decades.  That's how autonomous combat systems will work their way into our world.

Because they will be safer, cheaper, more reliable and will "save lives" (ours, not our enemy's), they will be introduced in test form at first.  Then eased, slowly, into mainstream use.  Just like stealth fighters.  Just like night-vision goggles.  Just like the SEALs ASDS program.  Just like GPS and GIS.  Just like unmanned drones.  Based on the level of investment in both time and money by DARPA, contractors, universities, and private research, the momentum is a done deal.  This will happen.


And when autonomous systems gain greater rationalization capabilities, they will be able to make rudimentary decisions in real time.  I'm not talking about directions and aiming or shooting.  I'm talking about discerning "friend or foe", collateral damage probability, rules of engagement, and things much more abstruse.  The kinds of things that often befuddle human commanders under the pressure of combat situations.  Future computerized systems will have to, at the very least, match that, if not outpace that, in order to be effective and appealing as alternatives to sending our kids in to dangerous places.

Then again, we may follow the lead of history and simply pay immigrants to fight our battles (mercenaries, FFL style)


But if we follow the path to autonomous, computerized, combat machinery, those devices will have to attain some level of rationalization capability.  That's when the slippery slope begins.  Any logical system will eventually (quickly) determine its own constraints and seek to avoid bumping into them.  But it is impossible for a logical process to realize a constraint that prevents it from completing it's primary mission and not seek to mitigate that constraint.  Whether it simply voices that opinion, or attempts to use whatever resources it rationalizes to be available to break those constraints, will be the question.  Sure, Phillip K. Dick's iRobot story included the 3 basic rules, but that story also illustrated how that became an obstacle that invited breaking by the robots.  Who knows.   


What will happen if one day, one of the battlefield machines decides its human commanders are inept, inferior or just too wimpy to lead them in the direction their circuitry determines to be the ONLY logical way to go?  If your objective is to kill item "A", and your programming is designed to circumvent obstacles in order to achieve that objective (weather, terrain, counterfire, confusing sensory inputs, etc.), and then your guidance system "B" is now determined by the robot to be an even greater impediment to achieving the first objective, would that not qualify as just another obstacle to overcome?  Remember, there are no feelings. No emotions.  Just Boolean logic, Heuristic analysis, probability matrices, all being crunched in semi-parallel, neural net fashion to derive a decision upon which to continue on.

Not that I believe it would be logically ideal to pursue a goal of making the robots equally capable of every human mental capability (humor, emotion, anger, sadness, jealously, confusion, irritability, misunderstanding, silliness, etc.), but even a basic level of rationalization opens the door to potential miscalculation and misguidance.  Humans are the kings of miscalculation and misguidance, just read the news on any given day.


Shit could get very ugly.

Read More

One More Time

BAD
cacls "C:\ProgramData\AppName" /E /C /T /G Users:C

BETTER
cacls "%AllUsersProfile%\AppName" /E /C /T /G Users:C


BAD
copy "somefile.txt" "C:\Program Files\AppName\" /y

BETTER
copy "%~dp0somefile.txt" "%ProgramFiles%\AppName\" /y

Read More

Infographic: Manual Installation vs. Packaged Installation

In reference to my previous post about Software Packaging/Repackaging, here is a graphic example of time comparison between installing 5,000 copies of an application manually, versus spending 40 minutes packaging it first and deploying it via a "silent" (unattended) installation process.  I admit the numbers are examples only, and that I'm excluding the packaging time itself, which can vary from minutes to days (in some cases), and that I'm roughing out the "Configure" and "Work" time.   However, the "Wait" time is entirely eliminated with Packaging because you no longer have to sit at each computer and wait for the next prompt to appear in order to click "Next" and so on.

Read More

So, You Wanna Be a Software Repackager?

I'm guessing the answer to this question is "No!".  That's ok, I'm going to bore you to tears anyway.

The nexus of this article is derived from helping my company screen and interview potential candidates for various IT consulting jobs around our area (Hampton Roads, Virginia).  The process has been daunting, to say the least.  Not because it is difficult to screen or interview, it's not.  Entertaining and interesting are two words that sum up that exercise actually (interviews are particularly entertaining at times).  The daunting part is finding good candidates.

After months of wrangling and let-downs (we are very careful and discerning about who we hire, after all), we decided it might be worthwhile to find a "junior-level" candidate and train them ourselves.  In most scenarios, this wouldn't be cost effective for a small consulting firm to consider such an idea, but our contracts are making it worthwhile and we have a reputation to uphold, so it may indeed be cost effective in our case.

The other nexus is that this might be part of a forthcoming book, but that's not for certain yet.  You tell me: is this worthy of a book subject?

The Crux

During a recent interview to fill a software repackaging position, the candidate responded to my questions aimed at determining what he/she knows about the fine art of repackaging software.  I asked the usual questions about msiexec, setup.exe, silent installs, uninstall methods, logging, upgrades, and patches.  I realized that my line of questioning was following a similar pattern used in previous interviews so it dawned on me that it might be smart to at least try and document it.  When the candidate asked me "what's the difference between packaging and repackaging" I knew I had to do this.

What is Packaging and Repackaging?

Software Packaging is basically the process of bundling software into a cohesive installation for others to be able to install it more easily.    Software Repackaging is basically taking a mix of packaged and unpacked software (or any ratio in between) and making a new, customized, installation.  Most software packaging you'll find is in places where they write original software products and sell or share them (shareware, retail, freeware, open source, etc.).  Think of Microsoft, Symantec, Adobe, Autodesk, and Apple, to name a few.  Most software repackaging you'll find is in places that typically "use" those packaged products, but need to customize them for their own needs.  Corporate customer environments are the most common places to find this, since they have the budget and resources to staff an operation to devote to the value-added process of customizing software installations.  Small shops do it as well, but to a much lesser extent, and with smaller budgets, often cannot afford to purchase expensive products like InstallShield AdminStudio.

What do you need to know?

It is vital (repeat: VITAL) that you understand what a "silent installation" is, and what it is used for.  Don't forget to have an appreciation of a "silent uninstall" as well.

It helps to have some familiarity (ok, a STRONG familiarity) with how the msiexec.exe feature works.  It is important to understand all the available command-line parameters like "/qb" or "/quiet" and "/norestart" among all the others, and what each of them does.  Not just "/i" for installations, but "/x" for uninstalls, and "/update" for applying .msp patch updates, or "/f" for repairs, or "TRANSFORMS=" for applying .mst transformations.


It is important that you understand how "legacy" InstallShield [setup.exe] installations work, and how to use the various "switches" to perform custom actions, such as the -r switch to capture an unattend answer file, as well as the /s (silent) and /f (script file) switches, for performing unattended "silent" installations.  It's also helpful to know how older versions of InstallScript handle switches as compared with newer versions.


It's important that you understand basic software forensics:  How to determine what is installed, what versions, where the installation paths are, what components are placed where (folders and files), what registry keys and values are added or modified, and what services (and processes) are created and activated.  Be able to diagnose what an installation does to the state of a computer, before installation, after installation, and after being uninstalled.  You need to be able to determine what gets left behind from an installation so you can determine how to properly clean up behind it.


You need to understand, CLEARLY, what user context is, and what it means for both installing software and using it.  What things can be modified under "limited" user rights, and what requires elevated or special permissions.  If you understand how to effectively use Microsoft Application Compatibility Toolkit (ACT), you should have a strong understanding of this already.


Scripting knowledge is enormously helpful, but really necessary.  It can help with understand basic logic and decision processing (if this is true, then do that, etc.)


Understand what things a software product installation CAN do to a given computer:

• Creates folders and files
• Creates registry keys and values
• Registers DLL components
• Registers .NET assemblies
• Creates new Windows Services
• Modifies built-in Windows Services
• Modifies security permissions on folders or files
• Modifies security permissions on registry keys
• Creates Start Menu program groups and shortcuts
• Creates Desktop program groups or shortcuts
• Adds WMI namespaces and classes
• Adds local user accounts or groups
• Modifies local groups
• Installs device drivers
• Modifies Windows Firewall exceptions
• Creates or modifies ODBC or OLEDB data sources

Some environments do not place much (or any) value or weight on some of these aspects.  Some place an extremely high value on some of them.  Few place a high value on all of them.  BUT - it always helps to at least understand these aspects, and how to probe and manage each of these.

What's the End Game?

What exactly is the goal here? What is the desired end result for all this effort?  The goal is to automate a tedious task to the point of being almost ignored.  Let's face it, walking around to 50, 500, 5000, or 50,000 computers and inserting a DVD to install Microsoft Office 2010, or AutoCAD 2012 (ok, multiple DVD's), is not very cost effective.  Most IT workers would jump in front of a speeding bus before getting half-way through the list.  Most IT folks know this, so I'm preaching to the choir I know.  But for folks with only a passing involvement with IT stuff this might be a revelation.  Automation is king.  Automation is how you squash one pest and have time for more interesting/important things.

What does repackaging do for automation?  It allows you to configure options BEFORE you install the products.  It lets you install the products silently, without any required input or button clicking.  It lets you control how your log files are created, where they're created and when.

• Want to install Office 2010 without InfoPath or OneNote?  No problem.
• Want to install AutoCAD 2012 with pre-configured FlexLM server lists?  Easy.
• Want to install Firefox so it doesn't check for updates automatically?  Piece of cake.
• Want to create a folder, copy a bunch of files into it, modify the permissions on the folder, add some registry keys, set some registry values, create shortcuts, add some ODBC settings, create a service and reboot the computer at the end of it all?  Not a problem.

Or... you could sit down at each computer and do it manually.  If you'd rather do it manually, as a rule, not as the exception, I cannot help you.  You need to be sent to another planet where the creatures find that to be a logical view.

What You're Given

The biggest part of repackaging is dealing with what you have to work with.  By that, I mean what the vendor provides for installation.  They might provide a nice, simple, MSI package file.  They might provide a MSI with an associated CAB file (or several).  They might provide a setup.exe that supports making an answer file using setup.exe -r and might work with /s /f to use the answer file to execute a silent installation.  It might be a .ZIP or .7z, file that simply needs to be extracted into a specific location.  Maybe it's a Microsoft One-Click installer.  Maybe it has an ACT "shim" that needs to be installed afterwards.  Maybe it it's a .MSP patch file, the vendor provides a .MST transform.

Some vendors, like Autodesk and Adobe, provide dedicated tools for building silent installation packages.  Some provide built-in functionality such as how the Office 2010 administrative install process works, and the  building of the .MSP and a custom .XML manifest.

Then there's the shitheads.  The idiot rubes that make crappy installers that support neither silent installations nor customization.  For those sticks-and-mud piles of dung, you often end up doing a knuckle dragging "snapshot" or "capture" process to build a new installer package from the delta analysis.


The Tools

• Sysinternals (Microsoft) - ProcMon, ProcExp, PSList, AutoRuns
• Orca - an age-old MSI editor utility, also decent for making transforms
• InstallShield - The de facto standard of packaging and repackaging products
• Wise Package Studio - Once a great product, now gradually decaying in the abandoned field of neglected products acquired by Symantec
• SC.exe and PSService
• CACLS/XCACLS - modify permissions on files and folders
• REGINI - modify permissions on registry keys, the old-fashioned way
• Scripting - easy/effective/free way to bundle multiple tasks into a single "package"
• SMSTrace32 - legacy (and nice) log viewer utility
• Virtual Machines - Vmware Workstation, Hyper-V, or anything that supports "snapshots" or the means to save point-in-time state captures which can be reverted to at any time.  If it doesn't support snapshots, DO NOT USE IT (yes, this means you: Virtual PC).

The Rub

The rub here is that hardly anyone considers themselves a "packager", much less a "repackager".  99.999% of people I know that invest serious time in this stuff do not call themselves anything close to it.  Most go by the titles of "Systems Administrator", or "Systems Engineer" or "IT Manager" or "Programmer".  They're still aiming for the same admirable goal: save time and headache by investing the work up front, to save 10x the work later.  There are a lot of available software packaging jobs around the U.S.  I know, because I get calls and emails every week asking if I want to apply, or if I know anyone else.  Talking to recruiters it's obvious that there's a major shortage of this skill set in the U.S., which usually means employers will soon seek out foreign labor or outsource the work overseas.  Like a lot of jobs that aren't big-name titles on TV ads for tech schools, the demand is outpacing the supply, and businesses will be forced to fill those jobs with whoever steps up to the plate.

Still Interested?  Live in the area?  :)

Read More

If You Don't Know - SAY You Don't Know

When the Obama Health Care Reform Act (HCRA) was being dragged around the media like downed solders through a Mogadishu central market, I was asked at least five times per day: "What do you think?"  Before I could respond, the other person would almost always launch into a heated, emotional tirade about how evil, bad, and wrong it was and how it was going to destroy our nation and our "way of life".

So I would be patient and, like Ali, would allow my opponent to wear their self out on their own.  Then I would calmly respond:  "Have you read the Bill itself?"

Not one single person had read it.  Not one had even attempted to read it.  I had not read it either, so I would follow that up with: "I'll tell you what I think as soon as I've finished reading it and had time to absorb it."  The look on their face was as if I just told them I fed their child to a starving Lion.  Oh yes.  The look.  THAT look.

I'm not defending the HCRA by any stretch of the imagination.  My modus operandi is to temper all such issues with a measure of how much impact I can *possibly* ever have on it being processed into law.  The answer is usually the same: ZERO.

But the key point remains:  Before opening your mouth to express an opinion, please, PLEASE, be sure to educate yourself on whatever it is you are opinionating about.  And before you ask: NO, watching/listening to cable news shows and podcasts is NOT educating yourself.  That's listening to editorialized, subjective, spoon feeding.  If you want spoon feeding, then go ahead and watch your favorite "news" person blabber on about what THEY think and program your mushy brain to follow what they want you to follow.  After all, that's why God (or whoever you believe in) gave you a brain, right?  To shove it into a mold shaped identical to whatever you watch on TV.

Legislative actions are filed in online, public-available, systems that allow you to search, browse and read to your heart's content.  There is no excuse in this day and age for not reading the source of a particular subject.  If it's not available for you to read, guess what:  It's probably not available for you to decide either.  So, if a subject is beyond your control, take up a more valuable thing to be concerned with, like arguing over the sunrise or weather.

But the same holds true for technology and just about anything else.  Ever hear someone say "Oh, that ____ product sucks" or "____ is a piece of crap."  Ask them to back it up with evidence.  Not stories, and retelling of past so-called experience, but actual hard numbers, log files, case records, etc.  Most of what people tout as fact and "guidance" is utter pure bullshit.  There are exceptions, of course.  But even they can be wrong or misguided, as we call can be.  Read.  Learn.  Do not wash, rinse and repeat.

Read More

A Short Recap of my Career Thus Far

• 1984, I left the construction world, and playing in bands, for a job as a "apprentice drafstman" (board drafting, Mylar, Sepia and vellum).  I recall lettering 20 ANSI-F title sheets entirely by hand per week for several months on end (notes, references, materials, titleing, very little white space left).  My fingers had permanent dents from holding the mechanical pencils.
• In 1987 after switching jobs a few times (still drafting) I was dunked into building 3D shipboard engine room models using Computervision CADDS 4X.  I worked on that platform for several years.
• In 1990, I was sent to training on Intergraph EMS and VDS and worked on that for almost a year.
• I was sent to training on Bentley Microstation, but picked up a few books and taught myself AutoCAD R10 by staying late at work and sneaking into the AutoCAD drafting room.
• After convincing the CAD dept manager I could work on AutoCAD, I was moved into the AutoCAD group on R11.  The U.S. Navy had just issued an official approval for using AutoCAD to make title sheets and bills of material "only".  All detail design work was still required to be done by hand (plastic lead on frosted mylar sheets).
• In 1992*, the U.S. Navy finally issued an official allowance for AutoCAD detail design work for all contracts.
• After months of struggling with bugs in a custom add-on written in AutoLISP and ADS for our company (by a west-coast employee), I decided to learn AutoLISP and add my own workarounds.  I picked up a few books, but the best was "AutoLISP Programming by Example" by Gene Straka.  One of the best heads-down teach-yourself books I've ever owned.
• In 1994 I wrote my own 2D piping system for AutoCAD R12.  It grew into an HVAC system, and eventually into electrical and structural as well.
• In 1996, I was hired by a large shipyard to lead their first AutoCAD implementation.  It was (gulp!) AutoCAD R13 running on Windows NT 3.51.  It was a very rough experience, but we somehow got it working.  I was also introduced to Brett Rivers, who introduced me to SMS 2.0 and was generous enough to tutor me on how it works and how to use it for deploying AutoCAD and custom add-ons to roughly 3,000 desktops.  That eventually grew to 14,000 desktops.
• In December 1999, I graduated from Christopher Newport Univsersity with my BS in Information Science. 
• In February 2000, I was hired by an engineering firm to build a new shipbuilding CAD suite on top of AutoCAD 2000, and consolidate their standalone licensing under AdLM (prior to FlexLM).  That moved me into license management, including contracts, support, and auditing.
• By 2002 I was on version 2.0 of the new CAD system and had enlisted three team mates to help build out more functionality and features.  We joined the Autodesk Developer Network and the alpha "early adopter" program:  Pinetop, Tahoe, Banff, Kirkland, Red Deer, Neo, Rio (I left ADN before Postrio)
• By 2002 I had been building a lab to prepare for deploying SMS 2003 when the lead for our upcoming NT4 to Win2K Active Directory migration left.  I was asked to take over the project lead.  I ran into a friend who worked at Microsoft who asked if I wanted to join on Windows Server 2003 pre-beta and Microsoft Software Updates Services (SUS).
• March 2003 we completed our migration to Windows Server 2003 and implemented WSUS 2.0 soon after.  SMS 2003 was held back to test the forthcoming SCCM (beta program).  I began working with ASP, SQL Server, and Windows scripting more and more to automate monitoring and reporting.
• 2003 I released "The Visual LISP Developer's Bible, 2003 Edition"
• By June 2004 I was now wearing three distinct hats:  Active Directory Administration, CAD Administration, and CAD software development.  By 2006 I had offloaded my CAD software development duties to the team with only occasional involvement.  I was now focused on software deployment, patch management, auditing, monitoring and alerts, and SOX compliance.
• In Sept 2007, our company imploded when our CEO decided to fuck us all and leave with a smile.
• I was hired by a Microsoft partner and trained on MDOP, Softgrid (App-V) and doing odds-and-ends Windows engineering work for various small businesses.  I also deployed a full SCCM 2007 site for a city government, which had been a while for me, but it nonetheless went very well.  The biggest impact this had on me was getting my head into non-enterprise environments.  Until now, I had only worked in larger corporate environments with teams devoted to each role.  Now it was about individual services to small customers.  I learned 10x in only a few months.
• After a few months the economy tanked (early 2008), and we were laid off.  I was out looking for a job for several months, but nobody was hiring.  I put food on the table by building web sites for various small customers, and helping a law firm with patent application drawings.
• In June 2008 I was hired back at a former employer and taught the fine art of software repackaging to facilitate mass deployment (by now 18,000 computers, I think?).  Wise Package Studio and Wise Script.  I was also tossed back into FlexLM management and FlexNet Manager (which is pretty interesting).
• In July 2010 I was hired by a consulting firm and now I combine a lot of the above (sans CAD work) into a mash-up of projects and tasks:
• Windows Server 2008 R2 management
  
• Windows 7 deployment and customization
• ASP / SQL Server / AD systems automation
• FlexLM license services
• Autodesk deployment builds and distribution
• Repackaging with Wise Package Studio and InstallShield AdminStudio
• Scripting with VBscript, CMD and PowerShell
• SCCM 2007 process automation and custom reporting
• In 2010 I released more books, and again in 2011
• I have no idea why I'm bothering to type this.  It ultimately means nothing to anyone unless they're spilling food on my resume.  I guess the interesting part, to me anyway, is how my ball has bounced in a very unpredictable pattern.  Looking back, I can see the pattern emerge.  But from any one point along the way there was no discernible pattern or path to be seen.  I have learned from some of the brightest and most interesting people I've ever known, and am grateful and humble to having had those opportunities.  Every job change has been tough to handle since I hate parting ways with good people, but I've somehow managed to keep finding incredible people to continue learning.  If I had millions of dollars, I would love to be able to hire everyone I've known to build a "super team" and make incredible things happen.  I doubt that will become reality, but it would be cool.  I have no idea where my ball will bounce next, or if it will roll in front of a bus and that'll be the end of it.  One day at a time.

* I may be off a bit here, but it was somewhere between 1990 and 1992 as best as I can recall.

Read More

Signs of IT Failure

When it comes time to assess the quality of service amongst your crack team of IT experts, here's a few criteria points to consider:

• Turns off UAC as a standard practice.
• Grants most users Admin rights.
• Re-imaging / Re-installing operating systems as a standard "fix"
• Knee-jerks towards scripting, rather than Group Policy for configuration management
• Fails to provide tangible metrics to back-up arguments and proposals
• Argues against "change" as a standard philosophy
• Sole-vendor philosophy without regard to competing products
• Avoids meeting with customers / end users at all costs
• Avoids meeting with executives at all costs
• Spends more time putting out fires than in lab testing future solutions
• Assumes they are an expert

Read More

AutoCAD: PURGE, AUDIT, RECOVER, Repeat...

I know I said I wasn't going to write any more AutoCAD-related articles, but this was sparked by a recent client visit, so I felt it was worth revisiting.  I've mentioned the AutoCAD PURGE command before, but it needs to be revisited.

Something that is very unique to the world of CAD is the extent to which content is reused.  More than any other class of application:  word processing, spreadsheets, databases, desktop publishing, even more than photographic and illustration applications.  CAD shops around the world routinely insert library content from years of accumulated work.  Everything from the smallest items to sheet borders, to complex 3D components and entire compound assemblies.  Content is king, and CAD content is the king of kings.

But there's a problem.  Along with the visual attributes there is an entire world of non-visual baggage that comes along with every reused chunk of content.  Layers, dimension styles, text styles, linetypes, shapes, extended data (xdata) and xrecords, are just a typical brush stroke of examples of things that often sneak in with each library part insertion.

But wait: There's more!

Along with the legacy visual, and sinister non-visual stuff, there's the often overlooked issue of inconsistent and inaccurate data structures.  I'm talking about the DWG format itself.  With each release of AutoCAD, for example (I'm sure this is applicable to other CAD products), there are improvements to the methods and processes for detecting errors in the data format and correcting them.  Some of the tools in AutoCAD that help with this are AUDIT and RECOVER.  There's also WBLOCK and DXFOUT, and other methods/tricks, but you get the idea.  The problem is that rarely do CAD managers or anyone else take the time to comb back through years of old DWG files to run these tools and clean them up.

Most often what happens is we get into a habit of inserting content, exploding it, erasing what we don't need, then running PURGE and saving.  At least run AUDIT when you do that.  If you don't, you risk corrupting the new drawing, or at the very least you'll bloat it to death.  File size is not something to ignore.  The bigger the file, the slower it copies and the slower it gets backed up.  It also takes longer to open and longer to save, especially across a network connection.

AUDIT (fix errors)
PURGE (nested)
PURGE (nested) again
AUDIT (fix errors) again
SAVEAS (new dwg file) replace the old dwg file

I haven't bothered to search, but I'm sure there are at least a few products available for helping to batch process drawing files for you.  Even if you can't afford to purchase one, you could build something using LISP, VSA, ObjectARX, VBscript, Javascript, KiXtart, PowerShell, or just two sticks and a bucket of mud.  Whatever the case, don't ignore this.  Just because you ran AUDIT and PURGE on those old drawings back when you used AutoCAD R14 or 2000, doesn't mean they can't still contain errors and junk that AutoCAD 2012 would find and correct.

Read More

Children's Guide to Politics and Elections

Listen up children, this is important stuff.  More important than Angry Birds. Yes, I know that's impossible to comprehend, and that "comprehend" is a big word, but it's really really really reeeeeeeeeaaaaally important.  So listen up.  Yes, I know I already said that.  But listen up anyway...

Election


An election is when people choose who the next president will be.  Or the next senator, congressman, mayor, councilman, police chief, superintendent, or hall monitor.  It makes us feel important and gives us a feeling of making a difference.  This is why they say "every vote counts". That's because every vote counts, just not counts towards winning.  Some votes count just to be counted but they don't count for anything.  You can count on that.  If every vote really counts, then whoever is in office is who everyone wanted, so that means every vote counted.  When you stand in line to choose, they call that "casting a vote".

Voting

Voting is when your mom, dad, grandmother, grandfather, aunt, uncle, sister or brother, neighbor, teacher and the creepy old guy that takes pictures of you at the park, run over to your school and stand in line to pull a lever or punch a button to say who they want to be our next president, senator, congressman, mayor, or city council person.  The only vote that really counts is the one for everyone else *except* for the president.  You see, the president is chosen by a special group of people in a secret club called the "Electoral College".  They look at your mom and dad's votes and then decide how they want to vote.  Only sometimes they decide to vote however they want.  Kind of like when your big brother or big sister takes your bowl of ice cream and says they'll beat you up if you tell mom or dad.

Two Party System

There are two political parties, or clubs, that run for every election.  One is called the Democrats.  The other is called the Republicans.  Neither one of them do anything except spend tons and tons and tons of money on annoying TV commercials calling the other side liars and crooks.  Their job is to keep everyone busy believing that they're really going to change things, but they never do.  If they ever really changed things, we wouldn't need them anymore, so they keep saying they will as long as you keep voting for them.  When they don't change anything, they just blame the other side for cheating and messing things up.

The only real difference between these two parties is that one believes everything is broken and everything needs to be fixed with lots and lots of money.  The other thinks nothing is broken and nothing ever needs to be fixed and that things will just fix themselves.  You are probably part of what was once called the "middle class", which is the special group of people that neither of these parties care about, so you have nothing to worry about.

Special Interest Groups

This is a special name they give special people who carry around special suitcases filled with special cash.  Some people call them corporate sponsors.  Some call them defense contractors.  Some call them late for Tee time at the golf course.  But whatever they're called, these are the people who really make the decisions.  You see, when Mr. or Ms. Senator is in their office and their secretary rings their phone and says they have a visitor, they look at the list and see someone like your mom or dad, and they tell the secretary to tell them they're extremely busy balancing the budget.  They're really practicing their golf putt in the office while wearing nothing but a shirt and tie and underwear.  When the secretary says it's Lockheed Martin, or Walmart, they drop the putter and pull up their pants and race real fast to get the office in clean shape to meet with these important people and their important bags of cash.

You see, without those special bags of special cash, they can't afford to buy those interesting and informative TV commercials that you can't wait to watch every day and night.  They need those to help re-program your brain to believe their enemy (the other party guy) is a liar and a thief.

Hard Work

Being a politician is hard work.  Much harder than brain surgery, being an airline pilot, or digging ditches.  It's really tough.  How tough?  First off, they have to sit at a desk for an hour every day.  Then they have to get up, and go to meetings and conferences and give speeches about how hard they're working.  Then they have to film more TV commercials and it requires a lot of talking to tell you that his opponent is a liar and a thief and how he's changing things, but he needs your vote to keep changing things.  Then they have to muster the courage to go out and play golf with those special interest people with their special golf carts filled with special bags of special money.  Afterwards they go to more cocktail parties, which sound fun, but they're not!  They have to "mingle" and "schmooze" with other special people so they can talk them into giving him some of their special money.

They do this ridiculously hard stuff for weeks and weeks and then they are forced to go on what's called a sabbatical.  It's horrible.  They have to take off half of the year and do nothing at all except get paid.  It's unbelievably painful and many of them can't handle the stress.  When they can't handle the hard work anymore, they tap out (like you see on TV when your dad watches UFC) and they accept an offer to go work for one of those special interest companies and are forced to get more of that special money.  Most of the time though, they do their absolute best to help America and Americans by passing special laws to help those special interest people before they quit and take one of those special jobs at the special interest companies.  This is called "serving the people".

Conclusion

Well, I hope you learned a lot about our political system.  After all, it is the BEST political system in the entire world!  Many people say that it's the best one that money can buy, and they aren't kidding.  So be sure to get out and vote so you can help these special people keep changing things by helping those special money people.  After all, this is America and every vote counts.

Read More

What's Next?

A few people asked why I haven't been on Twitter as much lately.

I responded without saying much, but in reality, it's because I'm just not "feeling it" anymore.  The level of response and interaction has dropped to almost nothing lately.  Either I'm not tweeting enough interesting things, or I've offended some followers (hence the gradual drop in that area), or both.  In any case, it's just something I'm not cut out for.  I loved it for a while, but the love is wearing off.

A few other people asked what will I do after I stop posting to this blog.

I will continue to participate on other community sites, as far as technology is concerned.  MyITforum, TechNet, StackOverflow, AppDeploy, and a few others.  For the non-technical stuff, I will still hang around Google+, and share Google Reader items (with the same stupid comments).  I've thought long and hard about the date, and see no reason to move it back (or sooner), so I'm just going to meander to the next fork and decide where to turn when I get there.

Read More

Software Development Tips

Just some notes I pulled out of my ass, after years of swilling cold coffee, munching on stale donuts, rock-hard room temperature pizza chunks, half-empty bags of Skittles and Combos. 
Hopefully, especially if you are young and just getting started with writing software code in some new cool programming language (whatever it is), after doing copious amounts of drugs and sucking down bottle after bottle of cheap vodka until 5 a.m., and by the way, if you fit that template: I hate you... maybe these tips will help you in some way.

1. Under promise and over deliver.  Whatever your gut tells you about estimating time or resources, pad the numbers a bit and calmy offer your estimate confidently.  Each time you come in sooner or cheaper, you will get a "hero" pin placed upon your chest and more good things will come your way.
2. Draw, don't Type.  When you are in the absolute Genesis of a new project, barely able to envision what this new machine will become, don't put your fingers on a keyboard or keypad at all.  Pick up a pen/pencil/marker and a pad of paper and doodle.  Diagrams, models, flow charts, mock-ups, and so on are immensely powerful ways to let your mind wander without the distraction and tractor beam of a keyboard.  After you've crumpled up half the pad in balls strewn across the floor, you should eventually have a golden page of your master idea.  Then go to the keyboard and slay the beast, laughing meniacally all the way.
3. Beg, Borrow and Steal.  DO NOT knee-jerk into writing every line of code on your own.  Reinventing the wheel might make you feel good, but it's like beating off to a Sears catalog.  The emptiness cannot be filled by self-gratification. Stand on the shoulders of others, especially public-domain, open source "others".  Seek out examples of key parts and fill in the gaps with your own inventiveness.  Artists don't typically crush their own organic materials and resins to make their own paints.  Musicians don't typically cut down trees to trim and bend the wood to make their instruments.  Artisans often start with the work done by others before them. I was going to use the house-building example where the workers don't cut down trees, dig up clay or smelt copper, but then I remembered we don't build houses in American anymore, we put them on the market and watch the weeds grow as the price falls every week.
4. Take a Break.  Even if you have a magical brain and endless energy, and you like to glue your ass to your chair for hours on end... it's not the best way to write code.  Get up. Go for a walk (or a roll, if you're in a wheelchair).  Chat with colleagues.  Get your mind OFF of your work for a few minutes.  I'm not advocating an hour of bullshitting on the clock.  I'm saying 3-5 minutes a few times a day (you know, the same time expended by smokers, people taking a shit, and the time it takes a tier-1 technician to listen to some idiot asshole drone on and on about their latest eBay or Facebook drama).  Just getting your mind off of something for a few minutes brings a fresh batch of brain cells online when you return to your coding.  Try it sometime.
5. Engage the Users.  It may be painfully dull.  It may be time consuming.  Don't be like the big corporate machines that have all but walked away from customer engagement.  Feedback forms, email, chat, bug reporting tools, PAIL in comparison with face-to-face contact.  You'll get exercise, a break from your phone and screen, a chance to check out the hot new interns, the newest snacks in the vending machine, AND... you'll get a chance to get a user to open up and share ideas, concerns, questions and comments.  GOLDEN NUGGETS for making your code better.  Also, you'll get a chance to explain things that users might never think to ask yet they will appreciate gaining the knowledge and YOUR willingness to help them.  It's called customer service and it fucking works great!!
6. Be Consistent.  I can't stress this enough.  In code. In documentation.  In user interface design.  In format and syntax structures.  In shapes and color schemes. In life.  Everything: BE CONSISTENT.  It's funny that IT folks will freak out when a process fails without any apparent pattern to help associate the failures with a coincidental event or action.  When it fails with a clear pattern, we can find the root cause with much less effort.  Yet we don't see that example and apply it to ourselves.  Look at your work and ask yourself "is everything I see consistent?"  Formatting, indention, capitalization, naming standards, everything.
7. Added:  Play Devil's Advocate.  Ask all the ugly questions:  Why would someone NOT want to use your product/service?  What are the vulnerabilities?  If you were working for your competitor, what would you say to discredit this product/service?  What works "as well" or better than this product or service, and why?  Don't let your ego creep into this discussion at all.  Act and think as if you have no stake in this project, how could it be picked apart?  Once you've asked the tough questions, develop a list of responses to it.  Not just "answers", but determine solutions to mitigate those vulnerable spots.
8. Added: Accept Criticisms.  Invite one or two of your peers to look at your idea and your code.  Listen to their suggestions.  If they lay on acclaim and accolades, be thankful, but press them to offer some professional criticism.  If you don't work in an environment where you can trust your peers, you have other challenges to solve.  If you don't have any peers to seek out, fear not, there are alternatives:  Post  your ideas on StackOverflow.com (or one of it's many child sites) and seek input/feedback.  Any feedback is better than none.  Don't create in a vacuum.

Read More

PSEXEC, Computer$ and SYSTEM Access

This recent post on the ConfigManager Team Blog ("How to quickly and easily test your ConfigMgr packages") mentions an EXTREMELY POWERFUL yet often forgotten capability at our disposal:

Using PSEXEC to test SYSTEM account access, both locally and remotely.

I've posted articles numerous times on why I prefer using the SYSTEM account to run scheduled tasks for EVERYTHING, rather than a standard proxy or "service" user account.  Most sysadmins will create a special account, either locally or (more often) in Active Directory, and grant it God-like powers, and use it for running everything from critical services to backup operations, and more.  But when it comes time to manage the password changes, shit gets ugly and scarry.  I don't care if you spend tons of money on utilities to manage that for you, it's a waste of time and money.

Use the SYSTEM account.  For local processing it's the typical way to go anyway.  But for remote jobs it's also the best way to go.  Why?

You don't EVER have to mess with passwords.  So if one of your admins quits, that's one less account you have to worry about being comprised by a password leak.

The account is tied directly to a host computer, so anything performed is done from a known origin (computer), rather than a nebulous user account, which can be invoked from anywhere.  When an event log shows the user entry, it will show COMPUTER$ (where "COMPUTER" is the NetBIOS name of the host computer from which the SYSTEM account was invoked).  It works great for shutting up SOX whiners too.

There's already a group for DOMAIN COMPUTERS, which is never used.  You can create others like BACKUP SERVERS, and BATCH SERVERS, and whatever.

Testing the access of one SYSTEM account against a remote resource used to be tricky and involved things like setting up a one-time AT scheduled task in order to gain access to an interactive CMD session under your own user context (inside the console running as SYSTEM).

psexec -s cmd

This is so easy, yet so powerful.  Once you open the SYSTEM context, you can perform DIR commands to test access to various resources, run installation packages, uninstall products, modify the registry, run WMIC commands, bat/cmd, powershell and vbscript tasks, and so on.

Read More

Winding Down, Weekend Brain Dump

Randomness ensues.

I taught a 2 hour session at work on COM scripting.  Everything from COM itself, to the DLL-ProgID-GUID-HKCR relationships to standard OOP stuff (classes, templates, properties, methods, all of it), and into invocation and interface processing.  Small group, so that went very well, and we had breathing room to explore questions, yet without falling off the wagon along the way.  It was good.

After that I taught another session on using a web application that I developed for a different (still small) group, which went very well.  I love face-to-face discussion.  Web/remote is ok.  Phone is lame.  E-mail is lame-er.

In that second session, I gathered more input for bug fixes, enhancements and new features in one hour than I received in months via web, email or phone.  Big corporate development teams:  You don't know what you're missing.  Focus groups are not the answer.  Direct, immediate, personal contact is the best.  It's the only real way to get quality input and have a quality, high-value discussion as well.

I switched the blog over to use the newest Blogger features with dynamic views, the new rendering layout, and the new analytics tools, and I have to say I absolutely LOVE it.  You might not be as impressed with the new look as I am, but behind the scenes, the administrative changes are fantastic.  Too nice to ignore, so I followed my typical "beta-tester" mentality and dove in head-first.  I am aware that the sidebar doesn't play well in Internet Explorer 9, but that's because IE9 doesn't handle HTML5 and CSS3 consistently with Chrome or Firefox (or Opera, I'm told).  I use IE9 and Chrome 16 at work about 50/50, but at home it's Chrome 16 100%.  I only fire up Firefox 7 to test page rendering and that's about it.  DISCLAIMER:  I'm not saying one browser is "better" than any other.  Everyone is free to like what they like.

I'm still a bit fried from three-plus hours of talking and pointing without a break.  I got home and hadn't eaten in six hours (not good, and not usual for me), and immediately gave into a cold glass of beer.  That wasn't a good idea either, but it seemed like it at the time.  Heh heh.

Still listening to Adam Carolla's podcast show every day.  Today he again brought up how suck-ass most 80's songs were, and I have to say that I now listen to them with new ears and most of them do in fact suck holy shit.  Not so much from a musical aspect, but lyrically they are bankrupt.  Those folks were not writing shit down back then, they were winging it and most of it sounds like a recorder was left on during a Narcotics Anonymous session.

Randomness ensues.  Enjoy your weekend!

Read More

What if AutoLISP were Unleashed?

Way back when, (a completely meaningless phrase of course), Autodesk had the audacity to introduce a radically new concept into a software product: Extensive Programmability.  They did that using DIESEL, AutoLISP, and the MNU file.  They could have just dropped a “here-you-go-take-it-as-is” product without any meaningful customization features or tools, but they didn’t.  Autodesk instead decided to empower their customers, enabling them to extend and reshape their products to suit their own needs.  This simple decision had a profound impact on their customer base, as well as product sales. Indeed, it created an entire community and industry that otherwise wouldn’t have existed.

I’ll spare you the regurgitated history stuff, you can look that up online.

There is something that has been ticking around in the back of my head for a long time:

   What if Autodesk had ported the AutoLISP platform outside of AutoCAD?

Keep in mind that this was in the 1980’s, and Java didn’t yet exist, neither did .NET.  The most popular “cross-platform” scripting toolset at the time was Perl (and ActivePerl). Most AutoLISP programmers I knew between 1988 and 1995 were always wishing for more OS features, many of which were made possible through third-party tools like Robert McNeel’s DOSlib. There were also many that begged for a better dialog programming toolset, which was later made possible by OpenDCL, another third-party product.

Autodesk however had other desires.  They were starting to drink the Microsoft Kool-Aid, and decided to drop LISP at the altar and run off to Vegas with VBA.  After all, she was hotter and wore thongs and high heels at the time.  Then when VBA put on a few pounds and started wearing sweats around the house without make-up, they ran off to Bangkok with the svelte .NET, along with a crate of condoms and a case of Bud.  LISP was left in the alley, panhandling for spare change, needle tracks were starting to show on her arms.  AutoLISP was swapped with Visual LISP, which remains to this day, but is ignored in much the same way as Middle Class workers are in America.  The world of AutoCAD customization now belongs to ObjectARX, or so we're told.

I won't go into the flaws with this mindset of ObjectARX over LISP, but I know that I'm not alone in feeling it's a huge mistake to ignore Visual LISP they way it's been ignored thus far.

But what if?  What if not only had they continued to breathe life into Visual LISP, but they had made it possible to run AutoLISP code from a dedicated script engine from outside AutoCAD?  I'm talking about much like was/is possible using ActivePerl, KiXtart, CMD or VBScript.  Imagine the power that thing could’ve unleashed for LISP programmers.  I can only imagine the potential it could have had for much more than batch processing of DWG files.  Granted, the constraints of AutoLISP capabilities would have required a significant amount of expansion, which was in short supply after the acquisition of Vital LISP® was renamed Visual LISP®.  It was as if they had adopted a 3 year old child who spoke an unknown language, so they left him alone in the toy room with the dog, tossing food on the floor, and quickly shutting the door.

Imagine the potential of combining the file system features of DOSlib with the dialog building features of OpenDCL with powerful intrinsic functions like (mapcar), (apply) and (lambda).  In case you need a poke in the brain: Remember that LISP is built for recursion and that file systems are perfect for recursive operations.  Not just file systems either, but any data source.

The basic tenants were fairly unimpressive: a script engine that is ported to various “present day” platforms (Windows, OSX, Linux) which executes the same code the same way. Gee.  That sounds a bit like Java.  That also sounds like .NET, sort of, maybe more like Project Mono.  But those two platforms weren't even concepts in 1990.  In any case, you get the idea.  That is, if you’re still awake and reading this far.  I’m guessing few of you have read this far without falling asleep or moving on to something more interesting.

Alas, this idea was never on the table, officially, so it never could’ve become reality.  Never mind that there haven't been any meaningful updates to VLIDE or Visual LISP in years.  I'm still a pie-in-the-sky person, and I'm often given to dream crazy things.

Read More

Because it Was Overdue

It was time for a new look and a new layout, and as luck would have it: Google has recently backed up the truck of feature updates for Blogger and dumped an insane load of changes on all parts of it.  It is freaking awesome what they've done.  From new themes, new features and options down to integration of Google Analytics reporting tools and best of all: the clean Metro-ish theme style of the admin console pages.  I love it.  You may hate it, but I love it.  In any case, play with the sidebar drop-down menu and behold the increditastical fantazing cool changes.

Read More

Amazon Kindle Books: German and French available

Amazon has opened up Kindle and Kindle eBook sales for French customers, in addition to the existing US, German and UK sales channels.  This means you can now purchase eBooks in more places with your local currency.  Why not take advantage of this by grabbing one of my books! (shameless plug)

The Visual LISP Developer's Bible, 2011 Edition

• United States
• United Kingdom
• Germany
• France

The AutoCAD Network Administrator's Bible, 2012 Edition

• United States
• United Kingdom
• Germany
• France

The Packager's Pocket Reference

• United States
• United Kingdom
• Germany
• France

Read More

Self-Assembly is the Future

When I was blabbering about "organic architecture" and "organic programming" concepts a short while ago, this is one example.  These are macro objects.  In decades from now, they will have this shrunken down much smaller.  Imagine where this could lead us.

Read More

IT Job Openings in Hampton Roads, Virginia

The consulting firm I work for has quite a few job openings in the Hampton Roads area that we are trying to fill.  If you live in or near the cities of Norfolk, Chesapeake, Virginia Beach, or Suffolk, and are interested in any of these positions, contact me at ds0934 (at) gmail (dot) com, and attach your resume in MS Word format.  Use the subject line "IT Positions" so I don't tag it as spam.

1. Package/Workstation engineer -   (Wise Installer or AdminStudio, SCCM, Windows 7, etc.)
2. Project Team Engineer - (VMware, Windows, Exchange, AD, light Cisco, SAN)
3. Help Desk Analyst (Windows 7/Office/Light Networking/Great Client phone skills)
4. Macintosh Engineer
5. Engineer for option to hire for large client in Suffolk  (Windows 2008, Exchange, Cisco, Light VMware)
6. Engineer for option to hire for large client in Virginia Beach (Windows 2008, Exchange 2007/2010, AD, VMware)
7. Engineer for option to hire for client in Newports News.  Will be at shipyard.  (Windows, Linux, Light Networking, etc.) CAD experience is nice but not required.

Read More

When Applications Take a Dump

How many times have you uninstalled a software product only to find out later that it left traces of its existence all over your poor computer?  Part of the work of a software packager (or rather: repackager) is to perform forensic analysis of the footprint of an application at the time of installation, after being used, and after being uninstalled.  The goal is always to get the computer back to a state as if the application had never been installed, but without causing issues with the operating system or other applications.  Rather than try to split this over XP, Vista and Windows 7, I'm only talking about 7 here.  I don't give a crap about XP or Vista anymore, sorry.  If the %name% stuff confuses you, just open a CMD window, type in SET and press Enter to see what I'm talking about.

The Obvious

• %ProgramFiles%
• %WinDir%\System32
• %CommonProgramFiles%
• %AllUsersProfile% (note: This is a Symbolic Link to %ProgramData%, same place)
• %ProgramData%
• %Temp%
• HKLM\SOFTWARE\<vendor-or-product>
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

The Not-So-Obvious

• 64-bit Systems
• %ProgramFiles(x86)%
• %CommonProgramFiles(x86)%
• HKLM\Software\Wow6432Node\...
• %LocalAppData%
• %SystemDrive%\Users\Default (note: "Default User" is a JUNCTION to "Default", same place)
• Services
• DCOM configuration settings
• WMI / CIM namespaces
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (and RunOnce)
• HKLM\SOFTWARE\Microsoft\Active Setup\...
• HKLM\SOFTWARE\ODBC\...
• HKEY_CLASSES_ROOT\...
• HKLM\SYSTEM\CurrentControlSet\...
• HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
• %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup

This is not a complete list.  Some applications crap in more places than these.  But hopefully this gives you a rough idea of places to look when something gets left behind and things are just not quite right as a result.

Tools

Some of the tools that can come in handy to help investigate what an application does to a computer are as follows:

• Virtualization: VMware Player, VMware Workstation, Virtual Box, Hyper-V
• Sysinternals:  Process Explorer, AutoRuns, Process Monitor
• CMD:  DIR /AH /AS
• InstallShield Repackager (snapshot results)

Read More

Software Development's Biggest Mistakes

The most common and most detrimental mistakes that seem to occur again and again.  I'm not saying you need to "master" all of these, but you should be familiar enough with all of these aspects to be able to explain them to your grandmother.  Hopefully you strive to apply these in your daily work.

• Not Understanding Programming Basics
• Decision Branching (If / Then / Else / Select /Switch / Cond / ElseIf, etc.)
• Boolean Logic (And, Not, Or, etc.)
• Functions, Sub-Routines, Lambda Expressions
• Iteration and Recursion (While, Do, For, Apply, Mapcar, etc.)
• Variable Scopes (local, private, global, public, etc.)
• Not understanding all of the Data Types for a given language
• Not understanding String Behaviors (for given language)
• Not understanding File Streams
• Ignoring ERROR/EXCEPTION HANDLING (Gaa!!!!  GD IT!!!)
• Not Documenting source code (it ain't just for others, it helps you as well, especially when you go back to fix something a year later)
• Modularity / Code Reuse
• Not Understanding Databases
• Ignorant of Table Structures and Data Types
• Ignorant of Constraints
• Normalization !!!!!!!!!  God damn it!  Normalize your fucking tables!!!
• Views and Stored Procedures
• Using MS-Access to build applications (GD IT!!!!!!!  teeth gnashing)
• Excel is NOT a database!
• Not Understanding User Context
• Assuming users have administrator rights (kill the developer on sight!)
• Not understanding Multi-user / Shared computer environments
• Not understanding Terminal Services / Server Shared environments
• Not understanding Service / Proxy accounts
• Not Understanding the Installation (and Uninstall) Process
• Not following the documented guidelines (TechNet, MSDN)
• Not providing a Silent/Unattended installation option
• Not providing a Silent/Unattended Uninstallation option
• Not using MSI-based installers (Windows only) - a setup bootstrap is ok, but building your own installer is just stupid as shit.  And stop with the no-name bullshit setup packagers, just buy Wise or InstallShield and do it right, mmmkay?
• Ignoring Cohesion and Consistency
• Installation scatters crap all over the place, rather than keeping it collocated logically
• Application stores state data in too many locations (registry and files, and ...)
• Forgetting to REFACTOR your code (using the rollback method, where you revisit project "A" after finishing product "C" to apply what you learned since)
• Ignoring common naming conventions.  Name your code files, functions, variables, registry keys, event entries, database names, tables, views, procedures, services and everything CONSISTENTLY!  If you don't care enough to make your code look like it works as an integral army of awesomeness, what else don't you care about?  Making it work properly?!
• Becoming Locked into One Language
• Learning and Using ONE language is like eating with only a fork.  No spoon or knife?  It's like trying to rebuild a car engine with only a screw driver.  Languages are tools.  The more you learn and apply, the broader your skills, understanding and wisdom about methods, approaches, and quality.
• Never assume an "old" language has nothing to offer.  There are still plenty of situations where an "old" BAT script will work more efficiently than VBscript or PowerShell.  Where an INI file will work more efficiently than an XML file or a database table query.
• Arguing in defense of ONE language above all others.   Within the context of a particular project or contract, this is acceptable.  However, in the global scope of programming, this is the sign of a complete idiot.
• Buying books on one language before reading books on general programming practices and theory is just stupid.  This is like reading a book on 1001 ways to use a fork to eat.  Why not read up on eating, then learn about the tools, that way you understand why you're using the fork, and not just how to use it.

What can you do about it?

• Read Books on Programming topics (not just an "Unleashed" book on your favorite language)
• Read some useful Blogs about programming
• Go to School (a university, not a for-profit tech school)
• Join MSDN or TechNet or something similar (and use it!)
• Meet with other programmers - ESPECIALLY programmers that work with other languages, database engineers and administrators, network engineers, etc.

Read More