Unwinding after a sprint

Over the years I've noticed that it seems I'm always extremely busy before and after taking time off from work. It's almost pointless to have time off from work since I always end up getting worked so hard that I end up needing the time off instead of just enjoying the time off.

At the beginning of August I found out about a new project at my day job that kicked off an intense week of planning before taking a week off in South Padre. It was suddenly a really bad time to take a vacation but it had been planned for months.

When I returned, I decided to pack up my office and move closer to the developers I'd be supporting. I spent the next two weeks `embedded` with this development team attempting to gain their trust, understand their problem domain, influence their software design choices and ultimately deliver the best build and installer experience possible. When I first started interacting with this team I wasn't sure it was going to go well but it actually turned out really nice. We completed our first sprint and delivered the first 10 of about 40 installs to QA. The ground work has been laid and the remaining 30 installs will just be details over the coming months.

Since then, I've spent the last two days enjoying labor day weekend with my family. It's been so relaxing. I've missed them so much and it's so nice to hear my family say "Daddy, where have you been? We miss you." It feels like I'm back in South Padre spending all day and all night with them once again.

Farewell EDS

I previously blogged early this year that it was going to be An Interesting Year Of Change To Come. At the time I wrote:

I can't help but notice the pendulum swing that's happening and I advise everyone to seek knowledge and apply it to your own personal situation. It seems that change is in the air again ( as it always is ) and it smells like recession driven merger and consolidation. Just about every industry that I've been in is seeing a lot of activity in this area and a few minutes ago I found out that I've been `sold` once again.

At the time, I had worked for a private company (Hart InterCivic) which was sold to a public company (Manatron) which was then sold back to another private company (TCB) who just happened to have also bought a software division (InstallShield) from another public company ( Macrovision ) to form a new company (Acresso). Then there was another private company I worked for ( Austin Information Systems ) which aquired private equity to become another company ( Overwatch Systems ) and finally sold to a public company ( Textron ). I didn't stick around for that deal to finish though.


Add in some contracting agencies, dot bombs and airlines ( which almost merged ) and my work history becomes somewhat confusing. Ohwell, at least there will always be a United States Marine Corps! Red and Gold baby, forget purple.

Anyways back to my original reason for posting. Today HP closes on the EDS deal for some $13.9 billion USD.

Wow. There were always rumors of a sale when I worked there (1996-1999,2000-2005) but today is finally the day. I always liked the teams I worked on for EDS but the company as a whole never really seemed like a real winner as evidenced by their really low profit margins over the year.

Well I yanked my 401K out last year and here's hoping that my pension fares well.

Farewel, EDS. You opened a world of opportunity for a young former Marine. I learned a lot from you and this eagle will miss you.

Don't Believe Everything You Read

While I've been a dedicated build/install guy for about 12 years now, I still spend a lot of time on the internet researching and honing my craft. During this time, I often come across posts from otherwise seemingly competent Software Engineers who grossly underestimate the complexity of setup. They frequently post messages in an expert voice that outline solutions that are far from best practice.

Tonight I read a message thread where someone was having a problem getting a WiX DTF Managed Custom Action to display a MessageBox. Another developer quickly replied with the traditional `Managed Custom Actions are Evil` mantra:

Using C# is the problem. You have to use a native Win32 DLL for a custom action, not managed .NET code. This is an ongoing debate because more and more programmers are .NET-only (which is, but this is strictly my personal opinion, a very big problem, programmers have to know several languages, including C, C++ and Pascal and similar to call themselves programmers but I digress) and .NET does offer a nice, cosy environment to do things in. Still, this is not an arbitrary limitation, it has it reasons. See http://www.tramontana.co.hu/wix/lesson3.php#3.5 for a short description and a link to Rob's blog detailing the issue.

Wow. This is simply not true... the debate is dead.

Anyone with more then a passing interest in Windows Installer knows that three months ago MSFT/WiX/Rob/et al did a 180 degree, ABOUT-FACE!, flip/flop and started supporting managed code custom actions when they released Deployment Tools Foundation (DTF). Rob's blogged it, Justin's blogged it, I've blogged it repeatedly ( with tutorials ), InstallSite has covered it, it gets discussed in the WiX list, the Platform SDK newsgroup and even the InstallShield Community forum. You simply can not be a Wi/Wix/IS/Setup Expert and not know about DTF. Period!

The interesting part is that the person who made this comment also runs the Tramontana WiX tutorial site which is often cited by beginning WiX developers as `I'd never gotten it done without this tutorial!`.

A quick review of that tutorial shows that the topic on managed code custom actions is full of out dated information citing outdated references.

Another interesting observation in my mind is this developers bias in implying that real developers should be able to code Win32 DLL's in multiple languages such as C, C++, Basic (what version? VB6 couldn't natively export Win32), D, Eiffel and Pascal in order to claim that they are real programmers. All of this while eschewing the .NET framework.

Very interesting. Anyways, I'm not meaning to hurt anyones feelings. I just wanted to point out that you should be very careful what you read on the internet. This site excepted of course. :) ( Seriously, when I make mistakes, please leave a comment.)

So Much Testing, So Little Time

A year ago, I shared both my love of Hatch Green Chili Peppers and my favorite dip recipe. Well, it's that time of the year again to stock up on more of these lovely peppers. You see, I didn't plan well enough last year... I ran out of peppers near the end of January. Sadly, the Hatch Green Chili with Asadero cheese pork sausages and Hatch flour tortillas were gone even sooner.

So this year I've tripled my stockpiling to make sure that I won't be running out! While I was at it, I picked up this really interesting new recipe book from Central Market. The story behind this cookbook is foodies were asked to contribute recipes and a sample as part of a cook off. The recipes were then published without ever being edited or tested in any way. To me that just won't do so there is only one thing I can do about it....

So much testing, so little time!

Concurrent vs Consecutive Build Performance

Lately I've been working on integrating BuildForge with TFS Team Build. One feature missing in Team Build v2 is the ability to automatically load balance build servers. Hey Microsoft, DefaultBuildAgent=FirstAvailable would be REALLY cool!

Fortunately BuildForge has a useful ability to define a pool of build machines that meet a set of criteria ( Selectors and Collectors ) and then specify how many concurrent builds can run at a time ( _MAXJOBS=xx). With a little bit of plumbing I can use BuildForge as a bootstrapper to kick off Team Build's across a build farm.

Way Cool! But how's the performance? The numbers above were taken using an HP DL-380 G5 with 3.0GHZ Xeon, 16GB of RAM and a SAS RAD5 storage running Server 2008 Hyper-V. Not the fastest machine in the world but it'll do. Each build represent a small .NET 3.5 Windows Services project that also builds an InstallShield Merge Module and Product Installer.

As you can see, when running consecutively each individual build is about 30% faster. However when you compare the overall throughput the concurrent builds are nearly 3x faster!

Of course the real beauty is that this system is now scalable to N number of virtual build servers. Just drop another hypervisor in the rack, fire up some VM's and add them to the collectors.

How's that for a little zoom zoom zoom?

As an aside, I was monitoring the performance and I could see that I was DISK I/O bound. CPU and memory was fine.

Here we come Kindergarten!

It's hard to believe it was only 5 1/2 years ago that I was endlessly shoveling snow in a futile attempt to be able to get out of the drive way in case my wife was to go into labor. Soon, Ashley will be going to Kindergarten.

Wow.

I just spent the last week with my family in South Padre Island and it amazes me how grown up she is becoming. Only a few months ago she could barely pass her swim test at the YMCA and now I watch her swim and tread water in the deep without her floaties. I watch her make friends on the beach and go out to the surf zone on her boogie board. We do all of the rides at Schlitterbahn and a REAL roller coaster at Six Flags. Although I think she reconsidered that decision since she didn't want to ride it a second time. She sings all of the songs from our latest Laurie Berkner CD and she sounds out and recognizes words.

Wow, we are so proud to be her parents. I hope letting her go to school isn't too rough on us.

.NET 3.5 SP1 - 231MB 255.5MB - Ya, It's Really That Big!!!!

I've been enjoying my time in South Padre but tonight I noticed a couple things about the newly RTM'd .NET 3.5 SP1 release. As I've previouly blogged the framework is huge and it's only getting bigger and bigger and bigger.

1) The full package is a 231MB download. .NET 3.5 RTM weighed in at 197MB so that's a 17.26% increase. Christ, I really wish my 401K would do that instead.

2) The .NET 3.5 SP1 `Client Profile` is now a 255.5MB download. Huh? Why is it bigger then the full package? I thought it was supposed to be about 26-30MB?

[Edit: The client profile download is now a broken URL.]

3) If you want to use the (initially) tiny web download / bootstrapper version (2.8mb) don't expect it to actually work if your customer is using a firewall. Then again, that's probably a good thing considering if I ran a network I wouldn't want dozens of clients pulling down a quarter of a terabyte (edit: oops Gigabyte!) in data just to run a program written in managed code.

Now I'm a huge fan of .NET, C#, VSTS, TFS, et al but I'm really at a loss for this one.

Standing by for DTF Release

A little birdie has recently mentioned to me that today's WiX release will include a version of DTF that supports the MSI 4.5 Embedded UI Story.

Rock On!

I go on vacation for a week tomorrow and now I know what I'm going to be doing at night for fun. :-)

So hopefully in a few more hours it'll be here for download.

I'll be blogging about it once I have my arms around how to make it all work. As a teaser, here's where I plan on going with it: Imagine an InstallShield 2009 Basic MSI project stripped of it's UI sequence and driven by Winforms with a setup.exe bootstrapper uses setup prerequisites to install MSI 4.5 and .NET 2.0. Finally imagine a feature tree that merely has references to chained installs as feature prerequistes.

I have a new product line at work that I'm supporting that's going to be creating about 10 installs chaining different combinations of about 70 micropackages. All of the code is written in VS2008 so it should be very interesting. I'm thinking of trying to make this look as slick as the Visual Studio 2008 install.