Monday, October 31, 2011
Campaign Advertising Template
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.
Sunday, October 30, 2011
Error Handling: An Example
[CODE]
strComputer = "computer123"
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 NextNext
[/CODE]
Now, if we run this and "Computer123" is not accessible, we should get the following...
[OUTPUT]
unable to connect to: computer123error: 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 NextNext
[/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!
Saturday, October 29, 2011
The Next Book Project
Target release is set for December 2011.
What is It?
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
Friday, October 28, 2011
Thoughts of Autonomous Robotic Combatants
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.
One More Time
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
Thursday, October 27, 2011
Infographic: Manual Installation vs. Packaged Installation
Wednesday, October 26, 2011
So, You Wanna Be a Software Repackager?
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
- 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.
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 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.
Monday, October 24, 2011
If You Don't Know - SAY You Don't Know
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.
Sunday, October 23, 2011
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.
Saturday, October 22, 2011
Signs of IT Failure
- 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
Monday, October 17, 2011
AutoCAD: PURGE, AUDIT, RECOVER, Repeat...
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.
Children's Guide to Politics and Elections
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.
Friday, October 14, 2011
What's Next?
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.
Thursday, October 13, 2011
Software Development Tips
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.
- 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.
- 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.
- 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.
- 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.
- 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!!
- 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.
- 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.
- 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.
PSEXEC, Computer$ and SYSTEM Access
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.
Winding Down, Weekend Brain Dump
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!
Tuesday, October 11, 2011
What if AutoLISP were Unleashed?
I’ll spare you the regurgitated history stuff, you can look that up online.
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.
Because it Was Overdue
Sunday, October 9, 2011
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
The AutoCAD Network Administrator's Bible, 2012 Edition
The Packager's Pocket Reference
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.
Friday, October 7, 2011
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.
- Package/Workstation engineer - (Wise Installer or AdminStudio, SCCM, Windows 7, etc.)
- Project Team Engineer - (VMware, Windows, Exchange, AD, light Cisco, SAN)
- Help Desk Analyst (Windows 7/Office/Light Networking/Great Client phone skills)
- Macintosh Engineer
- Engineer for option to hire for large client in Suffolk (Windows 2008, Exchange, Cisco, Light VMware)
- Engineer for option to hire for large client in Virginia Beach (Windows 2008, Exchange 2007/2010, AD, VMware)
- 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.
Thursday, October 6, 2011
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)
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.







