I complained before about Obnoxious Referrer Links and now Andy has stumbled across problems they cause in the real world.

It turns out that having a meme tracker for the feeds you subscribe to can produce some interesting results. The big issue is that some feeds either rewrite URLs to include a redirect through their server, or strip all HTML and just give you a snippet of the article. This makes it basically impossible to determine if two items link to the same article.

A lot of projects these days have taken to using a wiki as a way to get the community to write the documentation for them. This appears to work really well with a huge range of pages being created telling you how to do all kinds of stuff. Unfortunately, for anyone who actually needs to learn about the project, these pages are about as useful as tits on a charging bull.

Why is it that a hugely database dependent framework, that’s meant to be extremely quick to get up and running with is so infuriating when it comes to get it actually talking to the database? I know cross-language interfaces are always difficult, particularly when you try to make them work cross platform but if I can get Java, PHP and perl all talking to MySQL easily, why does it have to be so damn hard for ruby?

I realized an unintentional side effect of deciding to not use the ternary if (a ? b : c) – there’s a bunch of code that we don’t duplicate that we otherwise probably would have. In particular, when working with views there’s a very common pattern to convert between a Shape and a Rectangle1:

Rectangle bounds = shape instanceof Rectange ? (Rectangle)shape : shape.getBounds();

The reason for this is that getBounds() on a Rectangle will create a new Rectangle instance so if you happen to be getting the bounds a few thousand times every time you go to paint the text pane, you generate an awful lot of useless rectangles. Since every shape passed in is in fact a Rectangle, you can eliminate all of that junk without risking a ClassCastException if at some point you do get a different type of shape.

Once you have an automated build, the next step is to automate deployment1. A lot of people take this to mean that you should be able to check out the code, compile it and deploy it all from your local work station. I think this is largely a really bad idea.

Firstly, if you have deployment system that needs to vary, or might in the future need to vary, based on the version of the product, then your deployment scripts have to be in source control with the product and be branched and versioned just like the actual source code. If your product just spits out a zip file that is uploaded to a web server for clients to download, you my want to separate the deployment of that zip file from the code base since it will change based on changes to the web server, not changes to the code. You should however still be able to build the zip file from scripts that are versioned with your source code.

Having a fast build is an important part of XP so that the continuous integration cycle doesn’t take too long. Do people usually see this as including all the acceptance tests as well or does this just include the developer’s tests?

How do people handle acceptance tests failing? Does it cause the build to fail or not? What about acceptance tests that have been added for the current iteration but haven’t been implemented yet?

There’s a lot of talk about how you convert a legacy project over to TDD, and there’s a lot of talk about how you TDD on little code examples, but how do you get started on a real project? For a swing app, how do you TDD public static void main(String[] args)?

Atomic testing wants you to be able to mock out your dependencies, which leads to things like dependency injection. Somewhere along the line though, someone has to create those objects and pass them in. How do you atomically test that?

In James Shore’s chapter on Continuous Integration for his upcoming book, he strongly recommends using synchronous integration, where each time you check in you stop and wait for two builds to complete before moving on, in favor of asynchronous integration, where you check in and move on to your next task leaving an automated build server to check everything’s still okay. The whole point of continuous integration is that your team integrates regularly, so that you avoid conflicts. I can’t see how this is encouraged by adding up to twenty minutes of work1 every time you want to check in.

Recently there was a security flaw introduced by a security patch for IE, this obviously is a really bad thing and something the IE team1 have received a lot of criticism about for some time. Obviously, the IE team took it seriously and tried to find ways to make sure it didn’t happen again. One thing that really bothered me though was a statement in the IEBlog:

In parallel with making the right fix, we have been working through how we prevent similar mistakes from happening again. For instance, we have code-reviewed the past ten months of code check-ins from the developer responsible for this issue.

I’m glad Andy side-tracked into talking about us temporarily dropping pair programming – I’ve been considering the same kind of things but want to see what the rest of the team thinks about it before I say too much.

Slightly off topic, the development speed we’re achieving now is making me wonder if the tradeoffs when developing purely under Pair Programming are actually worth it.

There’s a lot more that has changed recently that has led to our sudden improvement in velocity – not just pair programming. For a start, we’re more focussed on the task because we’re not sharing the support load around the entire team. Plus, the business has really started to understand how difficult it will be for us to get things done so they’ve gotten off our backs about everything else and really focussed on hitting this big scary deadline. We were splitting our development efforts between two or three products and the context switching was killing us.

As part of the process to open source Java, Sun have switched from using codenames for Java releases to just using the actual name. Thank goodness for that. I’m not sure I know of anything more frustrating than attempting to have a conversation with someone using code names instead of actual versions. Was Dolphin before or after Mustang? Which Tiger do you mean, Mac OS Tiger, Java Tiger or Tiger Direct? How hard is it to just pick a version number and use it? Does marketing really need to mess around with that number at all, and even if they do, do they really have to wait until the very end of development to pick a number?

Sam Ruby – Time for a new HTML Validator?:

If people feel that HTML 5 deserves a better validator, I’m willing to invest some time into coding. Are there others interesting in contributing to the coding, the writing up of test cases, or the authoring of documentation?

 Is there a reason we need a new validator instead of just improving the existing one? The source code is available in CVS and there’s some brief instructions on how to contribute. Admittedly it doesn’t look like the easiest project on earth to jump into but it looks possible to do so. Is noone around to accept and apply patches?