Sunday, July 29, 2007

Me like CruiseControl.NET

One of the things I've picked up from the big book of developer tools is CruiseControl.NET aka CC.NET. CC.NET is a continuous integration system that automates the entire build, test and deployment cycle.

Setting it up was a breeze. I've spent approximately 6 hours to set it up for all my home projects. At first I wanted to use NAnt, as I've heard a lot of great things about it. After playing with it for a while I decided to go with MSBuild instead. Why?

  • The <nunit2> was a real pain as I'm using NUnit 2.4.1.
  • The MSBuild Community Tasks are really sweet. The NAntContrib tasks are sweet too, but NUnit support is a big thing for me. The <nunit> task of the MSBuild Community Tasks is really, really easy to use.
  • MSBee is freaking cool. I've used it at work a while ago where we had one code-base that needed to get compiled for .NET 1.1 and .NET 2.0. This MSBuild extension let's you do just that and a lot more.

The only bad thing about NAnt and MSBuild is the fact that they are declarative programming languages. I don't like programming in XML!

The unit test, code coverage and FxCop results are nicely incorporated by CC.NET using publishers.

This stuff is supported out-of-the-box, so you don't have to do anything extra.

Now that I have my continuous integration server up and running, maybe it's time to automate my project management as well. There's this other product from ThoughtWorks, called Mingle, that looks very promising. I have to have a software application that manages my agile home projects, aren't I ;-)

Thursday, July 26, 2007

I wish ...

I wish I could be there. It would be a nice birthday present ;-)

Tuesday, July 24, 2007

I Hate SSIS

Check out the I Hate SSIS page on the Ayende's wiki. SSIS stands for SQL Server Integration Services. I've never worked with it before (I have little experience with DTS), but I know this guy at work who does this stuff most of his time. Apparently, this piece of technology is seriously broken. It seems that Oren is so fed up with this, that he started building his own open-source alternative named Rhino ETL. Why are people complaining that there are no heroes anymore? ;-)

Monday, July 23, 2007

Book review: Windows Developer Power Tools

Over the weekend, I finished reading Windows Developer Power Tools. Its this huge and heavy book with 1207 pages of 170+ free tool goodness.

The danger of buying a book like this, is that it gets quickly out-of-date. On the other hand, the book nicely explains the different tools. I even learned some new things about the tools that I'm already using. The authors give you a great introduction for each tool and point you to the available online resources and support web sites. The companion web site contains links to all the tools, so you don't need to carry the book around with you (thank god for that).

The only downside of reading this book is that my TODO list has grown  beyond imagination. I need the following weeks and months, in order to process this massive amount of information. You have to take your time while reading this book. When you try to speed things up, a brain overload is right around the corner and you won't get anything out of it. It (deliberately) took me about 1 month and a half to read it.

It's highly recommended reading material. It gets you up and running very quickly. It even does a better job describing some of the tools than their respective online documentation. Kudos to James and Jim.

TDD through the eyes of Jeremy D. Miller

Another excellent post on TDD by Jeremy D. Miller. The following quote is something that needs to be up on the wall:

DO learn how RhinoMocks works or DO NOT use it.  Seriously.  It's a very powerful tool when used correctly, but it punishes folks with a shallow understanding of the tool.  Understand what it does, don't memorize, and don't try to copy/paste RhinoMocks code you don't understand

When I started out with unit testing and TDD, I ignored the existence of dynamic mocking frameworks altogether. I wrote my stubs and mock objects by hand. I wanted to grab on to the core principles of unit testing. After feeling the pain of manually writing stubs and mock objects for a year or so, I started using RhinoMocks. Looking back, I still started way too soon. I still consider not using a mocking framework at first is still a good thing. It's easy to get overwhelmed.

In this other post of Jeremy, the following quote actually made my day:

The WebForms event lifecycle is the most gawdawful, overcomplicated piece of crap MS has ever rammed down our throats.

Nuff said.

Sunday, July 22, 2007

Dynamic Language Runtime

Earlier this week, I've been listening to the .NET Rocks podcast, John Lam on the DLR. I must admit, I'm looking forward to IronRuby.

Now, somewhere half way the show, Carl Franklin asked the following question to John Lam who gave the most excellent answer:

Carl Franklin: Let me ask you this question. Should you use a dynamic language if you're not using "test first" methodologies.

John Lam: I don't think you should be using any language if you're not doing some kind of unit testing inside of the software that you're creating. 

I find it most encouraging that this guy is working at Microsoft (I also just read that the Hanselman is going to work for Microsoft too).  I believe that Microsoft should be preaching unit testing more and more.

I'm going to attend TechEd in Barcelona this year. I wonder if there is going to be an agile track of some sort. I'm not counting on it though, but hey, one can dream about a better software development world. Besides that, I hope there will be a lot of sessions on the DLR and dynamic languages.

Tuesday, July 17, 2007

101 Ways To Know Your Software Project Is Doomed

This post made me laugh out loud. Here are a few that I really liked:

The Continuous Integration server has returned the error message “Fuck it, I give up”

I've actually seen something like this coming from our Team Foundation Server!

The lead web developer thinks the X in XHTML means ‘extreme’

This would be something ...

Your favorite software pattern is God Object

When I just started working for my current company, I met a guy who was actually proud of this.

Your team believes ORM is a ‘fad’

I've convinced the team, but not the ivory tower decision makers ;-)

The phrase ‘It works on my machine’ is heard more than once a day

It's a poster on our wall (ha, explicit sarcasm).

Your manager spends his lunch hour crying in his car

Nonetheless, letting a manager cry in public is actually one of my life goals.

Monday, July 16, 2007

Thursday, July 12, 2007

Read "Beautiful Code" and make this a better world

Good code should read like a good book. Combine these two and you get a book like Beautiful Code: Leading Programmers Explain How They Think. I've had it on my wishlist for a while, but now I'm glad its finally out there. Also, all author royalties will be donated to Amnesty International. Become a better developer: purchase this book and read it from cover to cover and make this world a better place. 

Tuesday, July 10, 2007

Agile Team Dynamics

If you're interested on agile development, this blog post on Agile Team Dynamics is a must-read. I especially like the idea of banning e-mails for inter-team communication.

Sunday, July 08, 2007

FCL Type Names

After a code review session earlier this week, I was wondering if I am the only one who uses the FCL type names (e.g. Int32) instead of their language-agnostic counterparts (e.g. int). Almost every article or book I've read about .NET tends to favor the use of the language specific aliases over the FCL type names (except for the book CLR via C#). Why am I still using the FCL type names?

  • One of the first things I've learned about .NET was that it is platform and language independent. I try to adhere to this principle by writing code that is CLS compliant. Although this discussion has nothing to do with being CLS compliant, I find it more clear to use the FCL type names, although they are not recognized by the syntax parsers of Visual Studio for giving them a nice differentiating color. An example of cross-language confusion is that in C#, a long maps to an Int64 while in C++/CLI a long maps to an Int32. I've seen several projects using different .NET languages. With this constant language switching, you have to do some alias switching too. When using the FCL type names, you don't have to worry about using the correct aliases. An Int64 in C# is the same as an Int64 in VB.NET, C++/CLI, ...etc.
  • The .NET Framework itself uses the FCL type names as part of method names (e.g. System.Convert.Int64). As a C# developer and a C++/CLI amateur, I find the following line of code rather confusing when using the C++/CLI aliases for the FCL types. 
long value = System::Convert::ToInt32(L"12");

I don't know about you, but I'd rather have the following line of code instead:

Int32 value = System::Convert::ToInt32(L"12");

Am I the only one who sees it like this? Why are the FCL type names not recognized in the code editor of Visual Studio? Why, why, why ... do I need a vacation :-) ?

PS: While I was writing this post, Windows Live Writer crashed on me, losing the content of almost the entire post. I'm not amused!