Recently at my job I had to figure out how to publish a Windows app with [ClickOnce deployments](http://msdn.microsoft.com/en-us/library/t71a733d%28VS.80%29.aspx) from a centralized build server running [JetBrains TeamCity](http://www.jetbrains.com/teamcity/). This might be kind of an esoteric use for TeamCity, but I wanted to get my process down in my blog to perhaps save some future generations some time and Google searching.

The other day I had a very lively conversation about programming with my friends Pat & Warren. To paraphrase: Warren put forth the idea that coding is a lot like playing a game, and that game theory can be loosely applied to it. This led us to the idea that programmers *play* at building software, and in doing so, fall into two basic categories. Bear in mind, these are not absolutes, but merely ends of a spectrum that a coder can shift along over time. 1. The first type of coder/gamer is a person who likes the result of the game. They like the feeling that comes along with winning, or completing a level. If you played a dungeon-type discovery game such as Diablo with this person, generally they would be the person to reach the end of a level first. And then probably complain that you are taking too long. They enjoy the _completion_ more than the act of _playing_. In fact, to them, the idea of _playing_ is just the sum of all the completed levels so far. These types shall be known as the Completors. 2. The second type of coder/gamer is a person who likes the exploration and interaction of the game. Winning or completing a level is a secondary or n^th-erary aspect of the game. These people will want to explorer every possible room in a dungeon, possibly returning to visited rooms just to check "if anything new has shown up". Obviously, this drives the type 1s crazy, as these archetypes enjoy the act of _playing_ more than _completion_. Personally, this is the group I tend to fall into. These types shall be known as the Wanderers. So which is better? I don't believe the question is nearly as cut and dried as that. From a business point of view, *results matter*, and it would seem that a gang of Completors would the best team to create a business-critical on-time and under-budget enterprise-level highly-available software solution. Let me pause for a moment here, to let my jargon buffer refill. I think that a good level of success can be had with a group of coders more toward the Completor end of the spectrum. But that comes with a price. Because Completors are so results-oriented, once they find a good solution or strategy to beat "the game", they will just continue to apply it over and over. Why fix it if it ain't broke? The problem with the security of these repeatable results is that the world of software (and the world of games) marches on at a blistering pace. New [technologies](http://www.dotnetkicks.com/) and [methodologies](http://www.codinghorror.com/blog/archives/000856.html) spring up like dandelions in the summer. I personally spend a good deal of time just trying to keep up with a small amount of the New Stuff. Completors tend to shy away from personal growth and exploration because that's their nature. Over a career, or many careers, this can lead to a certain amount of software stagnation. Now let's look at the Wanderers. You might think after that last paragraph, that you _really_ want a team of Wanderers! Unfortunately, that group has some downsides as well: They tend to be the worst estimators ever. Some projects, because the game space is so large, will never actually reach completion. When faced with a very structured deadline or result, Wanderers may fail (for certain values of failure). Because the idea of exploration and self growth is very important, Wanderers tend to not have as much loyalty or "team spirit" as Completors. So what's the final answer? Just like in many things in life-- I believe that moderation is key. A group that is a well-mixed solution of different levels of these elements will reap benefits greater than the sum of it's parts. Wanderers will inspire and enlighten the Completors, The Completors will keep the Wanderers on the right track, possibly dragging them over the finish line with them. As a manager, or project leader, I think that understanding these two archetypes and using their strengths and weaknesses together can make for a most potent team. After all, who wants to play Diablo with a group solely consisting of Barbarians?

Now there is a title I never would have imagined. [The Day of the Triffids](http://www.imdb.com/title/tt0055894/) was one of my favorite B-grade horror movie staples. I was turned on to it by my uncle Paul when I was a small lad. I guess in the early 80s, the BBC did [a remake](http://www.bbc.co.uk/cult/classic/triffids/), but I never saw it. Today I noticed (albeit about 30 days post facto), that the BBC is making yet another [TV serial remake](http://www.guardian.co.uk/media/2008/nov/27/day-of-the-triffids-bbc). I am looking forward to finding a copy!

Jakki and I are both waiting with bated breath for the results of her nursing boards. As a Geek, I grew weary of manually refreshing the Dept. of Health website. Enter [Ruby](http://www.ruby-lang.org/en/). Without Rails, Ruby is still a fantastically useful scripting language. In about thirty minutes, I was able to write a script that grabbed the DOH page, parsed it with a handy [rubygem](http://www.rubygems.org/) called [hpricot](http://code.whytheluckystiff.net/hpricot/), checked to see if the status has changed, and if not, it goes to sleep for 5 minutes. When the the status *does* change, the script will launch FireFox and browse to the page. Maybe I'll make it send me an email or a text-message too. Right now it's a whopping seven lines of code.

Definitely not safe for work (unless you have headphones and a low visible-angle display), but hilarious nonetheless. Phil Francis, this one's for you bud! [The Website Is Down](http://thewebsiteisdown.com)

Notice my nifty table of my public Picasa albums over there on the left sidebar. Pretty cool huh? So do I have to publish in Movable Type every time I add a new Picasa album? No, that would be silly. Instead, I'm using some clever DHTML javascript to build an N-column table and populate it dynamically with a JSON call out to the Picasa web API. Read on for instructions and code on how I built mine.

As you can see, the blog is back to a usable and pretty form. The new template engine in MT4 is very easy to use and the widgets and widget sets make customizations a snap. Notice the nifty Picasa gallery widget I built. It uses JSON to make an AJAX call to the Google API and then processes the results into a table which it renders in-line. I'll try to write up how to do it later.