# Monday, 13 June 2005

Sigh.  It’s a constant battle.  I knew full well that XmlSerializer leaks temp assemblies if you don’t use the right constructor.  (The one that takes only a type will cache internally, so it’s not a problem.)  And then I went and wrote some code that called one of the other constructors without caching the resulting XmlSerializer instances. 

The result:  one process I looked at had over 1,500 instances of System.Reflection.Assembly on the heap.  Not so good. 

The fix?  Not as simple as I would have hoped.  The constructor that I’m using takes the Type to serialize, and an XmlRootAttribute instance.  It would be nice to be able to cache the serializers based on that XmlRootAttribute, since that’d be simple and all.  Unfortunately, two instances of an XmlRootAttribute with the same parameters return different values to GetHashCode(), so it’s not that easy.  I ended up using a string key compounded from the type’s full name and the parameters I’m using on XmlRootAttribute.  Not the most beautiful, but it’ll work.  Better than having 1,500 temp assemblies hanging around.

Work | XML
Monday, 13 June 2005 16:09:22 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Wednesday, 25 May 2005
Wired has a short piece on hams and hamfests that’s a good read for those not familiar with the subject.  I love to see the word ├╝bernerd in print. :-)
Wednesday, 25 May 2005 09:55:51 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 23 May 2005

Several times recently I’ve been bitten by “code-freeze”.  Granted, I’ve been bitten because I wasn’t tracking the “freeze” closely enough, my bad.  But there are alternatives to this (in my mind) counter productive process.  Developers need to be free to check in changes.  They fix bugs, or add new features, and need to get those things checked in.  Their dev machine could collapse catastrophically, they could forget to check them in, or the fixes could become irrelevant if they wait too long.  Plus, the farther you get away from the point where you made the changes, the more likely you are to get merge conflicts.  If the “freeze” lasts too long, multiple people may make changes to the same files, so that when the freeze is lifted, merge conflicts ensue, and that’s not fun for anyone.  Not good for continuous integration.  Code freezes pretty much take the continuous right out of it.

The solution, you ask?  Labels.  I think most people don’t realize how many groovy things you can do with good labeling policy.  Part of this stems from the widespread use of Visual SourceSafe.  If you are still using VSS, stop.  VSS and continuous integration just don’t belong in the same sentence.  Labeling doesn’t work right, branches are hard and have lasting consequences, etc.  The common excuse is “it comes for ‘free’ with my development environment”.  Of course, it’s not really “free” but that’s another issue.  Even if it were, there are several (much better) free alternatives.  CVS and Subversion top the list.  Much better choices, since they do labeling and branching right, and they discourage the exclusive check-out, which is pure evil anyway.  (Can you tell I have an opinion or two on this topic?)

What I have done (quite successfully) in the past is to use labels to “freeze” the tree rather than actually preventing people from making check-ins.  It runs something like this…  Every developer is responsible for checking in changes, and for deciding when those changes are stable.  It’s a common mistake to assume that the tip or HEAD of your source tree must always be pristine.  That keeps people from checking things in when they should.  So, decide on a label (like “BUILDABLE”) that represents that stable state.  That way developers can continue to check in changes, even potentially destabilizing ones, on the tip without causing havoc.  When the developer decides that his/her changes are stable, he or she can move the label out to encompass those changes. 

How does this work with continuous integration?  Your build server always builds from the label you’ve chosen to represent stability.  Not from the tip.  That way you should always get the latest stable build, even if that doesn’t represent the latest changes.  When it’s done successfully building, the build server should label whatever it just built with something like “BUILT” and the time/date (in another label).  Remember, each revision can have as many labels as you need, so extras don’t hurt. 

Another big benefit of this process is that if someone is just joining the team, or needs to build the software for the first time, they can pull from the BUILT label, and be assured that they are getting the most recent version that is known to be build-able. 

The end result is that you have two labels that move, leapfrogging each other as new things get marked as stable and then built, and some that don’t move indicating what was successfully built for each date/time/version.  That’s good information to have.  It’s also good for developers to be able to freely check in changes without having to worry about “freezes” or breaking the build.

Give it a shot.  It’s work up front, and requires a little training and discipline, but you’ll be glad you made the effort.

Monday, 23 May 2005 10:58:15 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, 20 May 2005

By now, no doubt, the three of you who read this have heard plenty of stuff about Episode III already, but I feel compelled to add my $.02.

It’s pretty darn good.

One of the “great films”?  No.

Entertaining?  Yes.  Sucks less?  Yes.  In fact, didn’t suck at all. 

It would have been an added bonus if there had been any acting by the principals.  I would have found Annikan’s descent into darkness way more plausible if he had even a shred of acting ability.  Sadly, he does not.  But I found I could suspend that bit of disbelief. 

Visually stunning, brings all the loose ends together in a way that’s plausible, no annoying comic relief in sight.  Very textured environments. 

Again, it would have been nice if the best acting in the film hadn’t been done by Yoda, but what can you realistically expect from Lucas?

Definitely worth seeing.  And just in case you’ve missed out, check out Darth Vader’s blog at www.darthside.com.  Genius.

Friday, 20 May 2005 10:13:59 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Tuesday, 10 May 2005

I’m a big fan of “appropriate technology”, so this story about the success of Morse Code over SMS messaging struck me as being pretty darn cool.  I’m just starting to study Morse Code in the hopes of qualifying for my General Class Amateur Radio license this summer, so I can fully appreciate the accomplishment. 

In short, a 93 year old telegraph operator and a teenage girl with a cell phone faced off to see who could send the identical text the fastest, via Morse Code (or CW in ham parlance) and SMS text messaging respectively.  The telegraph operator not only won, but he sent every single character in the text, while the girl used txt abbreviations. 

Does my heart good…

Tuesday, 10 May 2005 12:51:18 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, 28 April 2005

[Update] Maybe it was just service problems.  I haven’t had any more crashes the last couple of days.  There are still some things in the interface that could have been a lot better, and it overall seems slow response wise.

I updated to the latest Real Rhapsody client, and I must say, I’m a bit disappointed.  I’ve been an avid user for some time, but if they don’t get their player shaped up pretty quick that might change.  I’d have to say the new client BLOWS!  It’s crashed on me 10–15 times in the last two days, often hangs, the UI randomly jumps around or locks up.  The flashy new graphics and the equalizer don’t make up for poor performance.  And the style of the UI is such a blatant iTunes rip-off that it’s nearly distracting. 

Apparently it’s not just me.  I hope they get it straightened out soon.

Thursday, 28 April 2005 13:08:27 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 27 April 2005

Just in case you haven’t heard yet, Scott Hanselman and I will be at tonight’s PADNUG meeting rapping about continuous integration and how we do our builds at work.  (That’s probably rapping in the 70’s fireside chat sense, rather than the Eminem kind, but you never know what could happen.)

The meeting’s at:

Portland Community College Auditorium
CAPITAL Center, Room 1508
18640 NW Walker Rd.
Beaverton, OR 97006

Wednesday, 27 April 2005 11:48:28 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 18 April 2005

I’m doing a little refactoring this week of some code (not authored by me) that involves a WinForms app that drives tests.  I didn’t set up to do any refactoring, but in trying to fix some bugs and add a few simple features, what I’m finding everywhere is

        private void btnTheButton_Click(object sender, System.EventArgs e)


            //all the program logic is here…



Time and again we see this “pattern” in code.  In order to use that same functionality in the context of a different UI action, I now have to take the time to factor out the program logic into a separate method which can be called from two different locations (as should have been done in the first place). 

Now, in defense of the guilty, WinForms encourages this behavior, which I must admit is my single biggest gripe about WinForms.  Say what you will about MFC, I loved the way MFC’s designers defaulted to the MFC Command/CommandHandler pattern.  Every UI action represented a command, and it was up to the command handler map to decide what method actually handled the command.  Thus, the default pattern made it easy to do things like having a button and a menu item that both fired the same action.  I wish some of that had rubbed off on WinForms instead of the current VB-esque, every-bit-of-code-gets-attached-to-an-UI-element pattern.

However, it’s not just in WinForms that this is a problem.  I found that when I was teaching Web Services using ASP.NET, I ran into the same pattern.  A Web Service should be thought of no differently than a UI.  It’s an external way to make things happen.  So, having all of one’s program logic right in the ASP.NET Web Service code (.asmx) introduces the same problem.  Do yourself (and whoever is going to have to maintain your code in the future) a favor and create separate “code behind” classes for your web service that hold the real logic.  All that should be in your ASP.NET web service code is argument processing and calls into your “code behind”.  A full-blown MVC architecture might be overkill for a web service, but removing your logic from what is essentially your “user-interface” will save many headaches later on down the road.

Monday, 18 April 2005 14:41:58 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [2]  | 
# Thursday, 14 April 2005

Last night I went to a very groovy CERT refresher training at the fire house.  The topic was “Light Search and Rescue”.  What we ended up doing specifically related to extracting people from cars.  They got a towing company to bring over a junker car, and the fire fighters proceeded to pretty much take the car apart.  It was sooooo cool.  If you’re into that kind of thing…

We learned the best way to break out the windows of a car to get access to the people inside, how to get the windshield off, etc.  For the finale, one of the fire fighters used a hand-help, battery powered sawz-all to take the whole top off the car.  Took less than three minutes.  :-) 

The second half of the class was all about knot tying.  There are a truly amazing array of things you can do with a 10’ length of tubular webbing.  Definitely handy to have around.  We learned the water knot, the figure eight (on the end or the bight), the “alpine butterfly”, double fisherman’s, etc.  It was kind of like a whole room full of grownups thrown back into scouting for the evening.  Of course, if I don’t practice, I won’t remember the knots in a week or two.  Time to get a length of rope and start practicing…

Thursday, 14 April 2005 15:58:17 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 12 April 2005

My friend Lori turned me on to O’Reilly’s new “Make” magazine this weekend.  Very cool stuff.  I love the current trend towards mainstreaming the hacking of stuff.  You can find similar, although a bit more technical, stuff on the Hack a Day blog. 

I’m dying to try Make’s project for “kite arial photography”.  Basically you build a cradle out of popsicle sticks and pure grit, put a disposable camera in it, and hang it from a kite string.  At some controllable interval after you get it in the air, it releases the shutter on the camera and you get some pretty cool aerial photos. 

There’s also a project for a $15 DIY steady-cam.  Pretty fun stuff, and most of it looks pretty easy to build. 

My son is chomping at the bit to try their electric motor made from a magnet, some wire, two safety pins and a D battery.  Good times.

Tuesday, 12 April 2005 12:48:34 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |