Contribute, look dumb, fear not, repeat.

I just found this great new blog for efficient and power concious living.  Check it out.

http://www.metaefficient.com/

So I've recently had the task of fetching some information out of system.nfo files to translate cryptic IDs numbers into human readable friendly names.  This is the thing that XML is supposed to excel at right?  Well you would think that task would be simple enough, and as it turns out it is.  However searching for this solution online proved to be difficult, so I'm going to retell my experience here in hopes that it might help anyone else with this problem out.

I started with what I thought was a nice elegant powershell script that would query the XML like a SQL DB and return my value.  Seems simple enough right?

$friendlyName = $sysinfo.MsInfo.Category.Category.Category.Data.DeviceName | where {$sysinfo.MsInfo.Category.Category.Category.Data.Device_ID -eq $global:deviceName} 
 

This would work with normal XML where your content is inside the XML tags.  However the system.nfo file uses CDATA objects and many nests of categories so you have to go one step further.  Since I don't know which Category sub-tree my offending device or data might be in, I ended up grabbing all of the data objects that met my criteria and doing a breadth first search.  Sounds ugly compared to the one liner up there, but it actually works and don't take that long.  The following code is in powershell.  The key here is that handy get_innertext() method.  Your standard .Value or .Text won't cut it with CDATA.

# Open the associated .nfo file

$sysinfo_file = $global:computer_name + ".nfo"

$sysinfo_path = $global:computer_name + "\" + $sysinfo_file

[xml]$sysinfo = get-content $sysinfo_path

$nodeList1 = @($sysinfo.GetElementsByTagName("Device_Name"))

$nodeList2 = @($sysinfo.GetElementsByTagName("Device_ID"))

$nodeList3 = @($sysinfo.GetElementsByTagName("Manufacturer"))

$i = 0

foreach($node in $nodeList2)

{

    $deviceID = $nodeList2[$i].get_innertext()

    if($deviceID -eq $global:device_name)

    {

        $friendlyName = $nodeList1[$i].get_innertext()

        $deviceManuf = $nodeList3[$i].get_innertext()

    }

    $i++

}

The purpose of this handy little script is to look up a cryptic device ID and return a friendly manufacturers name.

Got this off the Drudge Report this morning.  It's more writing on the wall, but it sets the context very well for what is coming.  There's no need to fight it, so we'd better get used to embracing China as the world's next super power.  Let's just hope it's a peaceful transition.  Their rise is affecting manufacturing job markets the most right now.  Software and IT services still hold an edge in experience because kids getting out of Chinese universities just haven't shipped software yet.  This will change though.  Right now most companies have a hard time getting the value out of overseas development houses that cost less.  I suspect the US and Silicon Valley have maybe 15 to 20 years before anyone working in those markets can be easily outsourced to very reliable, highly experienced developers in China or India.  So save up now, and start looking for property in less expensive regions where your VISA is valid, and the money you save now will go further, as income pressure for American IT workers will force real wages lower.

Today I had the opportunity to practice some more test driven development with a resident expert in the field, Scott Bellware.  Scott is a really excited and engaging guy to be around.  He's really taken on Domain Driven Design, he believes in it, and he can teach it like you would teach someone to tie their shoes.  It's simply second nature for him.  I consider myself a relatively accomplish IT professional.  I know my way around all flavors of C code, object oriented design, and implementation.  Typically I come from the school of thought that you plan what you are going to build before building it.  Write it all down, figure out the hard problems, chop them into smaller, more manageable ones.  Show your solution to someone else, let them tear it up, and before you start writing any code you have a pretty good idea of how version 1.0 of what you are creating will look like.  Now this is an abbreviated summary of development, but that being said you can push it into waterfall with milestones, or agile with a backlog and sprints. 

Milestones and sprints are both organizational process.  They have very little to do with actual development.  Domain Driven Design is the bible for this style of development, and we got to experience a little piece of it implementing just a few straightforward rules in part of a hypothetical system.  I have not read the book, although it is now on the top of my list. 

The paradigm as experienced in an afternoon is code to the test, and isolate your functionality into 'domains.'  Coding to the test is essentially writing your tests first, simple ones.  Write a test, then write the code to get just that test to work.  As you make more tests work, you add more functionality without adding anything extra.  It goes against my grain because you see extensibilities and optimizations you want to make for future expansion or features you 'know' are coming simply because you've seen them done that way so many times before.  This is a lot like taking your past out of your coding future, and only writing what is necessary even if it feels incomplete.  If you come to a new feature, write it down, present it to the client, or whoever is writing the check before writing something no one may want.

The domain side of the coin revolves around setting rules for what to and not to write for given domains.  At the core of this is interoperability.  Make no piece of code dependent upon another.  If you add an include or a using, that is all it should take.  Everyone who has written software has gone through a project where they tried to get one little API or feature to work which required just one include.  That one begat another, which begat another, and another until you've written a state machine for Judges in the Old Testament.  Adhering to strict domains eliminates this.

Now I am not about to call myself an expert on DDD, but I did like what I saw.  For the purposes of our example, it worked very well and I can envision it to work well for large projects.  One thing is for sure, I will definitely be giving this new approach a few more cycles.  I'll just need the discipline to stick to it and not jump into coding before testing which is oh so tempting.

Last week I was in Seattle and Portland to visit friends, family, and business associates. The weekend turned out to be a marathon of meetings and traveling which produced a lot of results. Part of the trip was talking to potential employers in the area where I could work remotely from Texas.

My good friend Jason Herre has recently come under the employment of Microsoft working on a new team at Microsoft called 'Velocity.' He's been there for just a few months, and extols the virtues of the group and what they do regularly. Like many groups in Microsoft, they are expanding and therefore hiring. Jason felt I may be a fit for one of their heads, so I spent some time with their group on Friday finding out what they do.

Essentially they encourage and inspire OEM partners to make their machines faster and reduce the impact of their native software. When you first buy a new computer, that is as fast as it will ever be. Past day one, your machine gets slower and slower until you reformat and reinstall it. It's a terrible solution to hear from your tech savvy relative or support person, "Oh, you should just reinstall." The Velocity team tackles this with a very cool tool called Xperf. It's a diagnostic tool that hooks up to Microsoft's remote symbol server and analyzes everything that is using up system resources on your computer over a given period of time.

This might sound mundane, but there are key periods of computer use which infuriate consumers and myself alike. They are,

Startup; "I'm going to go get a cup of coffee or waste some time for a few minutes because I know that even though I can see the desktop, it's not going to respond to my inputs until the disk IO light goes off who knows how many minutes later."

Shutdown: "I swear I'm headed out the door as soon as this computer turns off. Get your keys. Where's my wallet? Do I have my phone? Do you have the directions to where we're going? Why hasn't this thing turned off yet?"

Sleep/Hibernate: "Why do you carry your laptop around open? Oh, it never really shuts off when I close the lid. It just heats up my bag and wastes battery. If I closed it, by the time I got to the meeting room, it would take longer to come out of sleep than if I just hard cycled the power."

Anyone who has used a laptop in a business environment has likely run into one or all of the above. Xperf shows the exact process, the exact driver responsible for taking up CPU, Disk IO, network, and a myriad of other resources. The tools is not discriminatory either. It points the finger at OEM software as well as Microsoft processes. It's the UV light at the crime scene that is your start up experience.

Looking at just one example OEM machine, I could easily tell symptoms like waiting for a network response, or waiting to detect a piece of hardware that isn't connected, or a piece of start up software that uses a lot of disk. In many cases there are layers of offenses that if addressed can shave 15-30 seconds from each of the above scenarios.  The best part is you can download the tools for free to find out where your machine is slow.