I'M NOT THE ONLY ONE!!!!

Who gets it ;)

Google gets it too. Some excerpts that follow my philosphy:

Sometimes, value can be bought off the shelf, Merrill says, holding up a plastic fork as an example. But there are times when off-the-shelf software won't do. "Our culture is pretty deeply embedded in many of our processes," he says. "So what we don't want to do is buy a tool, which by extension changes the cultural aspects of the way we do things."

It is my experience that off-the-shelf rarely works completely. It can work in some capacity, but what good is using 40% of a product that lacks 60% of the features you need?

What I like about the Google example is, like a plastic fork, the best commercial products you can purchase is simple "blocks" whose value becomes the way it helps you go from A to B. Not A to C,D,E,1,3,5,6,7 but never getting to B or only doing it partially (or too much).

Google's unorthodox approach to managing its Ph.D.s drove its decision not to budget research and development separately, as most tech companies do. "You end up in many companies with this divide between research and engineering," explains Alan Eustace, senior VP of engineering and research. By dividing those budgets, he says, "you're pretty much guaranteeing institutionally that you won't be solving interesting problems."

And it's true where I was previously employed and am employed now. A divide between people who fix problems and those who work on ensuring those problems don't happen again.

"Our goal is to automate as many things as we can because it makes unfun things not happen," Merrill says. "Nobody wants to have a boring job, right?"

Creating automation IS fun! Doing repetitive tasks is not.

Merrill is evasive when asked what kinds of commercial PC software are used at Google. "More important than what we put on each desktop is how we think about what to put on each desktop," he says obliquely. "Goo-gle's philosophy is that choice is always better than control. Tightly centralized control gets in the way of innovation."

He then takes a jab at CIOs--which he describes as a title used by "old-world companies"--at other companies. "Most people in my job try to control. 'Here are the three things you can buy.'" Merrill explains. "I try to control as a little as I possibly can but make it easy to work within parameters that I know how to work with."

Merrill sees a distinction between tools that tell you something and tools that stop you from doing something. For example, he observes that some financial services institutions block instant messaging because of they way they interpret regulations. "We don't think that's the right approach here," he says.

The right approach, as Merrill sees it: Talk a lot; use data, not intuition; automate wherever you can.

That faith in group intelligence manifests itself in the lunch line. Google provides free meals to employees partly as a perk and to enhance productivity, but also to encourage interaction. It's about the pollination of ideas over salads and sandwiches. "If you want people to talk, if you want people to engage, how do you do that?" Merrill asks. "You give them lunch."

Interaction is the bane of all businesses. NO ONE in a business wants to communicate -- you have to force them in some capacity.

AutoCAD is a devil in saint's clothing

Whenever problems arrise with AutoCAD it's a frustrating experience. I'm sure that is coupled with my inexperience with troubleshooting this particular program. It all boils down to two things (in Windows) when a program fails:

1) It's a registry key gone crazy (incorrect permissions, wrong setting, wrong type, etc.)
2) It's a file that's become mangled (incorrect permissions, wrong version)

That's it. Every problem in Windows is related to one (or both) of those two issues.

AutoCAD is intimidating at first having never dealt with it. We have a custom menu that is activated when AutoCAD is run. On one particular user's machine, her AutoCAD was throwing up errors when trying to build this menu (cui file is write protected). In attempting to troubleshoot this, I found the cui file referenced is indeed write protected. But that wasn't the problem. Checking with other users, they could not write to the file so her AutoCAD was trying to write to the file for some reason. Launching her AutoCAD under my user account resulted in success... So it could not have been the AutoCAD program installed on the machine. This left two things:

1) Some file in her profile is causing the issue and AutoCAD calls that file
2) A registry key is incorrectly set

Removing AutoCAD from her HKCU resulted in AutoCAD reconfiguring itself on launch and we did not get the error message but got a very slimmed down menu missing many functions.

This indirectly is telling me that the registry is not the issue. If the registry was the issue, the total removal of AutoCAD from HKCU should have resulted in it coming up no problem. This leaves the other issue... A file is causing the headaches. But, before I continued I had the user log on to another machine to ensure it was not her account causing the issue --> AutoCAD worked fine on another machine under her account. So it was computer specific. Some file in her profile...

AutoCAD keeps files in the following two folders in the users profile:
C:\Documents and Settings\USER ACCOUNT\Local Settings\Application Data\AutoDesk
and
C:\Documents and Settings\USER ACCOUNT\Application Data\AutoDesk

A file or couple of files in one (or both) of those folders must be causing my issue.

Renaming those two folders to AutoDesk--old should resolve the issue if my troubleshooting is correct.

Because I haven't and won't troubleshoot further to determine the exact file I won't know exactly which file caused or causes that issue but the solution is effective and cheap anyways.

Other places preferences maybe stored are the My Documents folder. So watch out there as well if your still having problems.

The Upwards War And Downwards Cycle

Everything you face today is a struggle. Without clout, you ride the coattails of others until you can achieve clout enough to force issues out or complete them. I face that ride pretty quickly. Being with a company for six months and trying to offer new ideas to problems I had faced (and solved) previously can result in resentment. It took me a year to build up enough clout at Voodoo, a company of 25 or so employees, to start enabling changes. Can I do the same working at a company for only 3 months (+ 3 on contract)?

The people around me who've seen my work are sold on it. Unfortunately, it's the people who haven't seen it that make the decisions.

This Friday will tell.

Single Image Hardware Independent Operating System Independent Deployment

HOW TO:

1) Make a OPK share (usually OPKTOOLS)
2) Make a CFGSET and set it to be able to do Media Center / Tablet (use a Media Center 2005 CD's and combine the two CD's) IF possible. (optionalsources=YES under [WINPE] in Winbom.ini)
3) Boot a VM into WinPE and use the Winbom.ini created by the CFGSET to copy all the necessary files over. Once that's done the system should reboot, go back into WinPE immediantely.
4) Kill FACTORY.EXE upon entering WinPE *IF* it's going to "Install Configuration Set"
5) Make an IMAGE of the hard disk and call this "VIRGIN" (or clean or blank or whatever).
6) Copy out winnt.sif located in the $WIN_NT.~BT$ folder to a network share. Within this one single file is the product key that determines what version of Windows you are going to have (Pro, Tablet or Media Center --> as far as I know [but haven't tried] this will not work for HOME).

7) You can now image a machine with the VIRGIN image and then copy over a WINNT.SIF to $WIN_NT$.~BT that has the proper product key using WinPE and FIRM. Since this is before the blue text-mode setup it is hardware independent and Windows will automatically configure itself for the number of processors it can support automatically. As well, because it's before the GUI mode configures itself via the product key, changing the WINNT.SIF file will change the type of Windows it will install itself as!

Single Image Hardware Independent Operating System Independent Deployment (SIHIOSID)

Boom baby! :D

One Image to Rule them All!

Another blog that discusses WinPE!

And other technical things! Finally :)

Utilizing WinPE in deployments

Browsing the web I found a good page highlighting some advantages of WinPE.

The article is a little old and WinPE is now available to downlad from MS sites and will be available with Vista. As well there is now a way to load the whole WINPE CD image into RAM so you don't require a CD drive.

In my environment I use WinPE to help with the deployment process and it does it's job wonderfully. I've modified it to use Windows Post Installer (WPI) to give an interface for the apps that should be deployed to the target system.

My current environment is setup as follows:

1) WinPE boots and logs the IP address of the present machine onto a network share. Our company has a site license for RAdmin so that is installed on WinPE. This logging of its IP Address allows me to RAdmin into it and administer the WinPE environment without being physically present.

2) WinPE presents a batch file "choices" screen, Reimaging is one of the options.

Choosing reimage causes the following to happen:

3) WinPE prompts for your user name, password and computer name which are stored in text files on a RAM drive in WinPE.

4) WinPE opens up WPI with a list of programs.

5) Clicking "Begin install" causes WPI to output the programs selected into a text file on the WinPE RAM Drive.

6) RDeploy is then called to image the drive with the corporate standard image (I've learned I may need to add a choice to select between Tablet, MultiProcessor or Single Processor soon. I've thought another way around it I'll describe later).

7) After imaging the drive, FIRM.EXE (File System Independent Resource Management) copies over the approriate sysprep.inf while which contains your user name, password and parses the computer name you entered earlier to determine the correct OU that the system will be placed under. With this information the sysprep file contains enough information to join the machine to the domain without user intervention.

FIRM also copies over all the text files that contain your user name and password onto the machine for parsing later (this later is to map file shares and execute commands under a domain account).

8) The machine reboots and joins to the domain as per the sysprep script.

More to come later.

Filter orders down to the hardware level

So we have basic detection based on customer orders but there is a way to do it based on hardware configuration. I consider hardware configuration to be a poor way of filtering, but it is sometimes necessary as a company won't always update SKU's or the file that we filter fast enough (bad business process in that case). Sometimes though, it's required if you want to limit installs to useful software. If you were an OEM and shipped NERO with every system, NERO may not be useful to users who have only CD drives (non-writeable). To filter thourgh to ensure usefullness, it now becomes a two stage process:

Find the SKU or customer order to ensure he gets, say, NERO.

--------------------------------
:Customer order file
:responses.txt
NERO-Y
--------------------------------

So we check to ensure that the client/customer has requested NERO:

------------------------------
:Check for NERO
findstr /I /C:"NERO-Y" responses.txtIF '%ERRORLEVEL%' == '0' (
SET NERO-FOUND=1
ECHO Nero was found!
) ELSE (
SET NERO-FOUND=0
ECHO Nero was NOT found!
)
------------------------------
And now we filter for the hardware ID using DevCon:

------------------------------
:Find the CD Burning Hardware ID
Devcon findall hwids * > "%userprofile%\desktop\HWIDS.TXT"

IF '%NERO-FOUND%' == '1' (
findstr /I /C:"IDE\CDROMSONY_CD-RW__CRX230ED" HWIDS.TXT
)
IF '%ERRORLEVEL%' == '0' (
:run silent setup command
NERO.EXE /S
ECHO Nero was installed!
)
---------------------------------

We don't need an "ELSE" in the above as we expect it to fail gracefully and not require more code to tell it to simply continue as it will do so anyways.

And now the OEM or corporation won't install useless software unless hardware that can take advantage of it is present. :)

Failing Gracefully is the essence of life

To someone like myself whose never taken a programming course, this is revitalizing stuff:

I am very much in awe of the guy who invented barcodes; they are incredibly elegant. One trick is to notice that every digit in a barcode is two black stripes and two white stripes, so if you've read black-white-black-white you know you have a digit, no matter how quickly it happened. (If it happened too quickly, you can decide you're reading garbage and just bail.)
One of the rules of writing algorithms that I've recently been sort of toying with is that we (as programmers) spend too much time trying to find provably correct solutions, when what we need to do is write really fast heuristics that fail incredibly gracefully.
This is almost always how nature works. You don't have to have every cell in your eye working perfectly to be able to see. We can put together images with an incredible amount of damage to the mechanism, because it fails so gracefully and organically.
This is, I am convinced, the next generation of programming, and it's something we're already starting to see: for instance, vision algorithms today are modeled much more closely after the workings of the eye, and are much more successful than they were twenty years ago.
Wait wait wait, can you elaborate on this heuristics bit being the next big thing, because you just bent some people's brains. When I normally think of heuristics in computer science, I think of either "an educated guess" or "good enough".
I.E., a game programmer doesn't have to run out Pi to the Nth degree to calculate the slope of a hill in a physics engine, because they can get something 'good enough' for the screen using a rougher calculation... but hasn't it always been like that out of necessity?
Heuristics (the way I'm using them) are basically algorithms that are not guaranteed to get the right answer all the time. Sometimes you can have a heuristic that gets you something close to the answer, and you (as the programmer) say, "This is close enough for government work."
This is a very old trick of programming, and it's a very powerful one on its own. Trying to make algorithms that never fail, and proving that they can never fail, is an entire branch of computer science and frankly one that I think is a dead end. Because that's not the way the world works.
When you look at biological systems, they are usually perfect machines; they have all these heuristics to deal with a variety of situations (hey, our core temperature is too hot, let's release sweat, which should cool us off) but none of them are anywhere near provably correct in all circumstances (hey, we're actually submerged in hot water, so sweat isn't effective in cooling us off). But they're good enough, and they fail gracefully.
You don't die immediately if sweating fails to cool you; you just grow uncomfortable and have to make a conscious reponse (hey, I think I'll get out of this hot tub now).
Programs need to be written this way. In the case of reading bar codes, you don't care if you read garbage a thousand times a second. It doesn't hurt you. If you write an algorithm that looks for barcodes everywhere in the image, even in the sky or in a face or a cup of coffee, it's not going to hurt anything. Eventually the user will hold up a valid barcode, it'll read it, the checksum will verify, and you're in business.
And the barcode recognizer doesn't have to understand every conceivable way a barcode can be screwed up. If the lighting is totally wrong, or the barcode is moving, the user has to take conscious action and, like, tilt the book differently or hold it still. But this kind of feedback is immediately evident, and it's totally natural.
Because I can try 1,000 times a second, I can give immediate feedback on whether I have a good enough image or not, so the user doesn't, like, take a picture, hold her breath for four seconds, have the software go "WRONG," try adjusting the book, take another picture, hold her breath...
Humans are incredibly good at trying new and random things when they get instant feedback. It's the basis of all learning for us, and it's an absolutely fundamental rule of UI design. (This is also the basis of the movement away from having modal dialogs that pop up and say, "Hey, you pressed a bad key!" If you have to pause and read and dismiss the dialog, the lesson you get is, "Stop trying to learn this program," not, "Try a different key."
The Mac and NeXTstep were pioneers in getting this right -- just beep if the user hits a wrong key, so if she wants she can lean on the whole keyboard and see if ANY keys are valid, and there's no punishment phase for it.)

Failing gracefully... That's key. It's in our blood ;)

Flexibility and accomdating clients

Last entry I covered the differences between flexible and static methods of deployment and the conclusion at the end was a mix of the two. It has been my experience that the best way to mix the two is ensure all variable information is gathered from the start. This does two things:

1) Eliminates technician wait time in that you shouldn't have to wait for a task to "catch up" till you can respond to it
2) Removes pauses that can extend the length of time an unsupervised process

To accomplish this we need ways of storing data from the client when they order the machine and a system of pulling the data out and configuring the machine.

STORING DATA:

Data can be stored in various fashions, a text-file is the fashion I use the most as it's simple, quick, and easy to parse. To generate a text file from a user's response we can use a simple batch script:
---------------------------
@ECHO OFF
set /p NAME=What is your name?
set /p OFFICE=Do you want MS OFFICE [y/n]?

ECHO %NAME% > "%userprofile%\desktop\responses.txt"
ECHO OFFICE-%OFFICE% >> "%userprofile%\desktop\responses.txt"
----------------------------

This will generate a text file that we can parse. The text file should look like this:

----------------------------
Trentent
OFFICE-y
----------------------------

We've now recorded some essential information to store for later when the time is required to utilize those responses.

To parse the file we can use tools such as find.exe the command FOR or IF.

Examples:
cd /d "%userprofile%\desktop"
for /f "tokens=*" %A IN (responses.txt) DO ECHO %A

This will bring two responses:
ECHO Trentent
ECHO OFFICE y

If we parse the file for known static "headers" (such as OFFICE) we can set variables for the stored responses.

FOR /F "TOKENS=* DELIMS= EOL=" %A IN ('findstr.exe /I "OFFICE" "%userprofile%\desktop\responses.txt"') DO SET OFFICE=%A

Now we can compare that value to determine if Office should be installed:
if /i '%OFFICE%' == 'OFFICE-y' (
ECHO Found Office
) ELSE (
ECHO Office NOT found
)

So if Office is found we can install it via a silent install command line.

So this lesson taught us to store reponses to be retrieved later. Stored responses can happen at any time -- when a user configures a system off a website, off a spreadsheet. These responses need to be stored in a known location such as a file share, in a database or downloaded off a webpage (wget.exe).