Once in a while, an absolutely brilliant post comes along. This is the type of post that you just cant add anything to, and the kind that you end up refering to and re-reading a few times to make sure you get every last nugget of information. This doesnt happen often, but when it does, its absolutely amazing. Jeremy Miller just posted one of these.

Entitled “My Programming Manifesto“, this absolutely sums up the way that I feel that software development should be done. The items on the right in normal text are important, but given a choice between that and the bold item on the left, Id take the item on the left any day of the week.

• Unit testing and testability over defensive coding, tracing, debugging and paranoid scoping
• Sharp tools over coding with the kid gloves on
• Writing maintainable code over architecting for reuse and the future
• Explicit code over design time wizards
• Software engineering over computer science

If you havent read this article yet, go do it now. If you have already, it probably would not be a bad idea to read it again. There is a great amount of brilliance in that post, and I want to thank Jeremy for this.

After a tremendous amount of research into what the right ASP.NET control vendor and control set would be for our team, we finally landed on telerik.

It’s always a tough decision to throw down $800 on a control library, but if you think about it, you really end up ahead. This particular suite offers 18 controls. Most controls are ajax enabled, with cross browser support, and .NET 1.1 and 2.0 support.

To get this type of functionality for only *1* of their controls, it would most certainly cost me more than the $800 price tag for the entire suite.

These controls are highly recommended not only by me, but by several other people out on the web. If you have not seen or used their controls, you certainly owe it to yourself to give them a look. There is a free trial version available.

As you may remember, a few months back I moved this site away from MovableType in favor of WordPress.

I’ve just now found the time to go through and entry by entry made sure that everything was transferred properly. Most of the problems I noticed were from the Textile and MTCodeBeautifier I was using with MovableType. This made it clear that its much better for content longevity to use standards like HTML, instead of relying on preprocessing text.

If you stumble across an entry that doesnt display properly, please dont hesitate to let me know.

On a tangent, it was very interesting to go back through each entry and see the things I was talking about back then. If you have never gone over your old entries, it’s definately an interesting trip down memory lane. I’d advise doing this sometime. :)

We’ve been diligently using Fitnesse for the past year or so to document and automate our acceptance tests. For the most part, this has been an inefficient process. Let me clarify a little…

I’m not suggesting that FIT or documenting or automating your acceptance tests is what’s causing the inefficiency. After watching people attempt to use this system for the past while, Im convinced that its the wiki itself that’s causing the confusions and inefficiencies.

First off, just getting something running on your machine turns into a relatively difficult ordeal. The documentation available for Fitnesse is sparse at best.

Next, is the syntax. All pages in a wiki have to conform to a wiki word syntax. To a person new to wiki in general, this can prove to be very confusing, and I’ve seen test pages that look something like ThIsShOuLdTeStSoMeThInG. A little less than readable, if you ask me.

Lack of an easy integration with CruiseControl is also a drawback. It would be nice if there was a concise way of running all of my FIT tests every time the build executes.

The last thing, the straw that broke the camel’s back, if you will is Fitnesse’s ability to get out of sync with your source code. Let’s say that I want to branch my source code… If I want to have non-failing tests, I need to spool up a new instance of Fitnesse, which can turn into a colossal PITA (see paragraph 3).

So, what would I do to solve this? Well, the first thing to realize is that FIT and Fitnesse are actually two separate things. I think the information out on the web has not been very good at driving this point home. FIT itself is the framework. Fitnesse is just a way to author and execute the tests. Fitnesse decided to use the wiki syntax to accomplish this.

So, knowing this, what we can do is create straight HTML pages, or even Excel spreadsheets, organize them into a folder structure of our choosing, and most of all, commit them right next to our source code. You do have a tests folder under your project in source control, right?

Running the tests at a time of your choosing is straightforward with the FIT runner. This can be launched from a command prompt and takes a folder location as an argument. It then iterates through the entire folder structure looking for and executing test fixtures. This way, the user can launch them whenever needed, and they can also integrate directly into CruiseControl. CruiseControl makes it very easy to tap into a post-build event to launch a command.

Seems to be a much easier way of utilizing FIT to document and run your acceptance tests…

Last night, we were at a tribute to John Vlissides, who passed away last year after a long struggle with complications caused by a brain tumour. At the tribute were Ralph Johnson and Erich Gamma. Richard Helm videotaped his tribute and sent it in a few days before. Most of you will recognize these names as the remaining three of the Gang of Four.

The tribute was nice, and each shared their memories of John. Erich’s was particularly nice, as he showed another side of John via emails that were exchanged during the writing of the Gang of Four Design Patterns book. After this, people from the audience were allowed to ask questions.

Of course, the question came: “What’s next?”. Erich answered fairly quickly, “we started Design Patterns, Second Edition in 1998″. This answer made it fairly apparent to me that this is something that will not be happening, especially considering that the first book was done in about 2 years.

After thinking about it, it does make sense. The core patterns that they discussed in that book are probably the best things that could have happened to object oriented programming, and how people communicate about design of software. This was certainly ground breaking, however, with the advent of sites like patternshare.org, a second edition of that book doesnt really make that much sense. Other than updating the examples to use a relatively modern language (Java or C#, instead of Smalltalk), there’s not much else to do.

The book is a classic, and always will be the standard when it comes to pattern reference. I congratulate all of them for a fantastic job, and look forward to see what comes next from those guys.

Earlier today, I had the great priviledge to listen to Joshua Bloch’s invited talk here at OOPSLA. For those not familiar with Joshua, he is a Chief Java Architect at Google, formerly a Distinguished Engineer at Sun Microsystems, where he led the design and implementation of numerous Java platform features.

This talk alone was worth the price of admission to this conference, and Im really hoping to get a video or audio transcript of this conference so that everyone on my team  can see or hear this. It was that good!

Some of the things that came through loud and clear for me:

1. An API can be among your greatest assets or liabilities. A good API can greatly enhance your customer experience and can create customers for life. If you create a bad API, you’ve create a support headache.
2. A public API is forever. You have one chance to get it right. As soon as you put something onto an API, it is permanent.
3. When in doubt, leave it out. This is probably the most important thing when designing an API. Like the above point, an API is forever. It’s much easier to add to a public API than it is to remove something from the same API.
4. Minimize accessibility. This is a big thing for me. A lot of developers do not seem to be aware of a scope other than public. It’s perfectly valid to start something in a private scope, and only enhancing that scope as necessary.
5. Prefer composition to inheritance. Exposed classes should never subclass just to reuse implementation code. Create a subclass only if you can say that every instance of the subclass is an instance of the superclass. This is the Liskov Substitution Principle.
6. Constant feedback is imperative. Show your API to as many people as possible. Others will think about things that will pass you by.
7. It’s not preferred to provide an overload for every potential code path. If the two methods have different behaviour, name them differently.
8. Names are very important. Strive for intelligibility, consistency, and symmetry. Every API is a little language, and people must learn to read and write it. If you get an API right, code will read like prose.

There was so much more than these 8 items packed into this 90 minute talk. During the question and answer session afterwards, Joshua did hint that he is working on a book about effective API design and why you want to do it. I’m so looking forward to that. That title could certainly turn into required reading for any developer.

Yesterday, I was able to take in Robert (”Uncle Bob”) Martin’s talk at the OOPSLA Educator’s Symposium. He allowed the audience to choose the topic. Choices were ‘Clean Code’ and ‘Principles of OOD’. The audience ended up choosing ‘Principles of OOD’.

We brought Robert Martin in a little over a year ago and had him talk to our organization about agile development, and therefore, I kind of knew what kind of talk to expect. I have to say that I thoroughly enjoy his engaging speaking style. He’s very animated, very passionate, and does a fantastic job connecting with his audience.

His talk covered his SOLID principles of class design. These principles are:

Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

These are things that every developer should be familiar with and things thought should be considered every time you put together a new class. I’m not going to duplicated Uncle Bob’s talk here, but will rather point you to the article on his site that covers the principles in more detail. If you prefer a hardcover reference, check out Agile Software Development, Principles, Patterns, and Practices.

I have been to several flavors of VSLive among other development conferences. This is the first OOPSLA conference I’ve ever been to.

Which one do I prefer? OOPSLA, by a mile! You’re probably asking why…

VSLive works from a practitioner’s point of view. VSLive is very good at telling you how to do something. For example, this is how you should write a web service with ASP.NET. OOPSLA definately takes the academic route. OOPSLA gets you to think more about developing software from a hypothetical standpoint. It’s not expected to produce an immediate result. I’d much rather learn more on how to think about a problem, rather than being told how to solve a problem.

The stats for this years OOPSLA are about 1200 attendees from 46 countries. Over 430 people from overseas. This is pretty impressive. The other day, as part of the DesignFest, I ended up having lunch with my group, which included 2 people from Canada, one person from Switzerland, and another person originally from Russia, now living in Finland. Making these types of acquiantences and being able to talk with people on the other side of the world about how they develop software is something you will never get at a VSLive type of event.

OOPSLA 2007 is in Montreal next year. If you’ve never gone, I strongly encourage you to go. You have no idea what you’re missing. Knowing what I know now, Im fairly disappointed that I’ve not gone before now. I know for a fact that I will not miss next year…

So, yesterday I was going to end up going to either the SOA and Web Service Best Practices discussion or the Creating an Informative Workspace discussion. Ultimately, I ended up sitting in the Dynamic Languages Symposium. Some of the stuff I saw in there made my head hurt. It’s just amazing what some people out there are working on. It’s really true… the thing about OOPSLA is finding that next big thing.

We saw a very interesting web development framework called HOP. What was most fascinating about this was the demonstration. He had 3 browsers open, 2 instances of Firefox and 1 instance of Konqueror. As he edited a text area in one of the Firefox instances, the text on the other 2 browsers updated automatically. HOP is implemented as a web broker, which is something I did not quite get. It seems that to get this working correctly, you ultimately end up having to run something on your desktop, which sort of defeats a main advantage of the web, which is a seamless deployment model. It will be interesting to keep an eye on this project to see how it progresses though.

Adrian and I also got a great talk from Audrey Tang about PUGS, which is an implementation of Perl 6 written in Haskell. Some of the stuff that Audrey is doing was pretty impressive. One of the coolest things I’ve seen in a while was Audrey’s IRC chat session being projected up on the screen prior to her talk. She was running OSX, and her IRC client was VIM. You read that right… VIM, and she was flipping back and forth between two channels. That brings me to another point… You will not believe how many MacBooks are floating around here… It seems like it’s at least 30%. More and more people seem to be gravitating to them. Apple might just be on to something here… :)

Having just recently installed Vista RC2 as my main operating system on my laptop, I resolved to give Internet Explorer a fair shake to try and win me back as a user with version 7.

IE lost that battle after about 4 days of use. Recently, I discovered Google Reader and have really come to depend on it to read my RSS feeds. For whatever reason, IE just did not play nice with this application. The slow response time and piss-poor javascript performance is what finally did it in. I could deal with the occassional hiccup that caused my feeds to display incorrectly, or the occasional fart that skipped backwards when I hit next. The performance however was the last straw.

I’ve just installed Firefox 2.0 on this RC2 installation, and everything seems right in the world again… Other than the fact that Im still running it in Windows.