Christmas Lights updated
· Dec 11, 05:40 PM by Thijs Kroesbergen for Brokenwire.NET
I just published a new version of the popular Christmas Lights. You can grab your free copy from the publish page right now.
So what’s new in this years update?
- New light bulbs: The new bulbs are bitmap based instead of “dynamic” WPF shapes, this reduces the CPU usage. And I think these look nicer too.
- Better stability: I resolved several issues which caused crashes when you changed the display resolution when the lights where active. Now you can also add/remove monitors while the lights are running.
- Plasma “burn-in” prevention: When this option is switched on the lights move a bit every minute so they don’t burn in your nice big plasma TV. :)
- Fully tested on Windows 7 but the lights will run on any pc having .NET framework 3.5(sp1). (This includes Windows XP, Vista, Server 2003)

I’ve already got some nice ideas for a future version, but suggestions (or patches) are always welcome!
Possible features for a next version:
- Make the blinking speed dependant on the power level of your laptop battery: As the battery gets empty the lights should blink slower (or faster).
- Make the lights blink when sound is detected, so they can sync up with your favorite Christmas tunes.
- Create more blinking patterns and add a pattern to cycle through all other patterns.
So prepare your PC for the Christmas season and install the lights!
And if you are curious about the code that makes all that goodness happen, take a look at the “Wpf Christmas Lights” CodePlex project page. There you can also report bugs or post suggestions.
Happy Holidays!

Pimp my software
· Jun 23, 10:00 AM by Thijs Kroesbergen for Brokenwire.NET
Everyone who has done some (serious?) software development knows that we have several different methods to run our project. We also know that not all methods are equally successful. But one of our favorite things to do is compare our ways of doing things with others in the more “traditional” trades.
So a little while ago I was watching MTV’s "Pimp My Ride", and then I was thinking, what would software development look like if we did it the “Pimp My Ride” way?
So let’s see what that would look like. For those of you who don’t know the Pimp My Ride TV show, it goes like this:
The show starts by showing a teenager with a banged up car. That car gets picked up by the shows host and brought to a garage. Then a team of mechanics goes wild on the car by remodeling it completely. Then the owner is brought in, the car is presented and a happy guy (or girl) leaves the shop with a new ride. If you want to see this for yourself, take a look at the MTV website.
Now let’s break that down into the parties involved. The core group of people involved is of course the team of mechanics. This team designs and builds the car. The way this team is composed is that several people with different specialties are brought together in the right mix. In our world this would be team of highly skilled software engineers. This way each member should have its own specialty like data-access, user interfaces and such. Perhaps the most important thing to notice is that all team members are involved from start to finish.
Then there’s the host of the show, he gets to pick up the car, monitor the work on it and deliver it back to the owner. In the software development world this could be the project manager with a bit of help from some sales guy perhaps.
Last but not least we have the owner of the crappy car. This is comparable our customer, who has a problem (a crappy car, or some complex business process) and needs someone to solve it for him.
That wraps up the parties involved, now lets move to the process.
At the start of each episode (project) the old car gets picked up from some lucky bastard by the presenter of the show, a rapper known as “Xzibit”. They chat a bit and X gets a pretty good idea about the likes and dislikes of the car’s owner. This translates to an combination of sales and analysis. There’s communication with the customer, and both the scope and the requirements are set. For example, the owner drives a VW Beetle (scope) and likes to sing (requirement).
Once this is done the car is brought back to the garage and the whole team gets to take a good look at it. Then they sit together and each specialist tells what he thinks that needs to be done to the car.
Lets see how that meeting works out…
Paint specialist:
“I’m gonna put on a base layer of toxic green paint, and then I’ll airbrush some hot flames on the side of this wicked car!”
User Interface guy:
“I’m going to design a WPF based interface with nice glowing buttons which animate on mouse-over”
Engine tuner:
“Let’s upgrade the engine so it can do 0-60mph in 2.9 seconds! For that I’ll use this nice turbocharger kit.”
Database guru:
“I recommend that we store our data in a clustered SQL Server database, and we’ll use LINQ for our data access layer. This way we will have performance and speedy development all at once!”
You get the point ;). This meeting is like the project kickoff. Here the architecture is determined and the individual components are defined.
Then they get to work. Each specialist does what he does best, and they work together as the gears of a well oiled machine. Sometimes they encounter something unexpected, but with all the knowledge they have on board they will continue to deliver the finished product right on schedule. This is actually exactly the same thing that is (or should be) happening in any software delivery process.
Finally during the last minutes before the car’s owner arrives the finishing touches, such as polishing the car, are applied. Then the big unveiling takes place, and a happy customer leaves the building.
“You’ve officially been pimped”
The handover of the car’s keys translates to the delivery phase in our world. This where the happy customer accepts the finished product. And a happy customer is what we are aiming for!
To conclude this rant, lets see why this “Pimp My Ride” process should work for software as well:
- We both do the same trick over and over again. Almost every application is an assembly of standard components, just like a car is build of standardized parts.
- A mechanic is just as much an expert in his field of work as a software engineer is. We know what we are doing…
- Both teams are used to delivering a the project in a fixed (or rather, predictable) amount of time.
- In the end a happy (paying) customer is all that matters. The customer tells what he wants, and that is just what he’ll get.
But of course there are some differences as well, so why doesn’t this work for software?
- The “architecture” of a car hasn’t really changed in the last decades (Or has it…?), for software we have many different solution for many different problems. So is creating software that much more complex?
- If you get back your once-rusty now-pimped car for free, without cash involved, you are not going to be very picky about requirements. Software is usually well paid for, so the delivered product has to live up to much more well defined expectations. Does this mean we can’t educate our customers on what to expect? Have you ever seen them building a flying car? No? Maybe because it IS possible, but its just very hard to get right. Now compare that to software, how many times do we say something just isn’t possible?
- Perhaps the size of software development projects isn’t as consistent as the size of a pimping-a-car project is. Some project are like building a bike, others could be the size of building a complete cruise ship. Then again, for completing such a huge project you need to split it up in manageable chunks anyway. So the real question is, how big should a project be to have the optimal size?
- We tend to separate our teams in architects, designers and builders. But in the Pimp My Ride team each member is a specialist in both designing and building his part, from start to finish.
It looks like this comparison doesn’t hold up too well (but I had fun trying it anyway). I do think that we like to over-complicate things because with software it’s so easy to create anything our mind can come up with. And because of our human nature we just love to try stuff that hasn’t been done before. Perhaps, given some more time and thought, the expectations for software will become just as clear as the expectations we have of a car.
So what do you think? Does any of this make sense? Is building software harder then building a custom car? Are we spoiled by all the options we have and do we over-complicate?

Quick Visual Studio Tip
· Apr 19, 03:07 PM by Thijs Kroesbergen for Brokenwire.NET
Press CTRL + SHIFT + V to cycle through previous clipboard entries (and paste them). This way you can “cut” several pieces of code, and “paste” them somewhere else without going back and forth. (You could also use “copy” multiple times and then use this to “paste” that, but of course nobody is interested in copying code…)
There are more hotkeys in Visual Studio that are not so well known, take a look here.

Decrypting Sql 2005 SPs made easy
· Mar 25, 03:05 PM by Thijs Kroesbergen for Brokenwire.NET
Today I ran across a problem where I desperately needed to peek inside a stored procedure used by Team Foundation Server. The only trouble was that the stored procedure was created with the “WITH ENCRYPTION” clause appended, so I couldn’t see the source.
To decrypt the stored procedure I used a stored procedure called dbo.sp_SpDeObfuscation, which can be found here and/or downloaded here.
Please keep in mind that you need to run the SP from an DAC (Dedicated Admin Connection)

Timer.Elapsed event – The Silent Killer
· Feb 26, 12:54 PM by Thijs Kroesbergen for Brokenwire.NET
Yesterday we ran into some issue where exceptions would disappear into a black hole. We had some code running within the Elapsed event of a System.Timers.Timer which seemed to crash without us being able to catch the exception in our global “unhandled exception” exception handler. It looked like we had a Ninja in our code somewhere, deadly and accurate.
So we finally figured out what was happening and I’ll explain it to you here.
To start with the code to reproduce this looks like this:
An example project can be downloaded here: SilentKiller.zip
static void Main(string[] args) { Console.WriteLine("Starting..."); AppDomain.CurrentDomain.UnhandledException += OnUnhandledException; System.Timers.Timer aTimer; aTimer = new Timer(1000); aTimer.Elapsed += new ElapsedEventHandler(OnTimedEvent); aTimer.Enabled = true; Console.WriteLine("Press the Enter key to exit the program."); Console.ReadLine(); } private static void OnTimedEvent(object source, ElapsedEventArgs e) { Console.WriteLine("The Elapsed event was raised at {0}", e.SignalTime); Console.WriteLine("Ninja attack!"); throw new ApplicationException("Ninja!"); Console.WriteLine("You didn't see this one coming"); } private static void OnUnhandledException(object sender, UnhandledExceptionEventArgs e) { Exception ex = (Exception)e.ExceptionObject; Console.WriteLine("Caught an exception: " + ex.Message); }
The problem here is that you’d expect the OnUnhandledException method to fire, but this doesn’t happen. It seems like the exception is silenced within the timer! It took us quite a while to find that out. But actually the MSDN documentation is accurate about this, and my colleague Paul was the first to catch this line:
In the .NET Framework version 2.0 and earlier, the Timer component catches and suppresses all exceptions thrown by event handlers for the Elapsed event. This behavior is subject to change in future releases of the .NET Framework.
So it’s not a bug, it’s a feature!
And when you peek inside the System.dll assembly from the .Net framework you’ll see the following code for the handling of the Elapsed event
private void MyTimerCallback(object state) { if (state == this.cookie) { if (!this.autoReset) { this.enabled = false; } FILE_TIME lpSystemTimeAsFileTime = new FILE_TIME(); GetSystemTimeAsFileTime(ref lpSystemTimeAsFileTime); ElapsedEventArgs e = new ElapsedEventArgs(lpSystemTimeAsFileTime.ftTimeLow, lpSystemTimeAsFileTime.ftTimeHigh); try { ElapsedEventHandler onIntervalElapsed = this.onIntervalElapsed; if (onIntervalElapsed != null) { if ((this.SynchronizingObject != null) && this.SynchronizingObject.InvokeRequired) { this.SynchronizingObject.BeginInvoke(onIntervalElapsed, new object[] { this, e }); } else { onIntervalElapsed(this, e); } } } catch { } } }
Now I wonder who had the guts to break the rule “Never (ever) use an empty catch”! And why did they do this?!
(This would be a nice question for a Microsoft exam ;). How many of you knew about this?)

Super-easy access to the Sysinternals tools
· Feb 18, 11:54 AM by Thijs Kroesbergen for Brokenwire.NET
Leon Meijer blogged about the "new" way to access the sysinternals tools back in May 2008.
Today I found out another cool trick. You can not only use the http://live.sysinternals.com/ "Open Directory" server to download the tools, you can also do the following: (Start, run, type:)
And presto! You now have access to a network share with easy and up-to-date access to the tools!
You can also map a drive letter to this share if you want to, just type:
net use * \\live.sysinternals.com\Tools
If you consider yourself an "IT-Professional" and you haven't seen or heard of any of the Sysinternals tools, shame on you! (But hey, it's never too late to learn, so go check them out!)
(This trick depends on the Windows ability to access a WebDAV share as a regular network share, so this won't work on systems where the client bit (the WebDAV mini-redirector) isn't installed (such as my Windows Server 2003)). On Windows Vista this works straight out of the box.
Another reason for some of you to leave the "antique" versions of windows behind and move on?
