My initial motivation for hairball was as a tool to help me understand potential problems in my code bases – spot god classes, code that is hard to test, odd dependencies. The tool purposely doesn’t make any judgments about code bases – it just gives you the diagrams. What you do with them is up to you.

The first version doesn’t contain support for tracking of singleton dependencies, and the setter and constructor injection should very much be considered a first stab – so I could do with some beta testers. I’m looking to track down false positives and negatives, as well as get some general feedback. Is Hairball it easy to use? Does it misdetect dependencies? Can you read the diagrams? Does it blow up when trying to run on your mammoth code base (I’ve done nothing to tune performance)?

Future Features

I have a few more features I’d like to add, including:

• Singleton detection
• Displaying inheritance
• Support spotting attribute injection from frameworks like Picocontainer or Guice
• Overlaying other metrics (e.g. colour based on Emma output, make nodes taller based on number of instructions in the class)

The feedback I get will very much determine what gets added next.

Hairball is available now for download.

I’m working in the US at the moment, and decided to pick up an iPhone. I’m here long enough to justify it (well, justifying a $600 phone is pretty damn hard). No problems in getting one – the SF Apple Store had plenty.

The problem is that as part of the signup for AT&T, I need not only a credit card with US billing address, but also social security number. I have neither. The shop assistant knew I was from the UK but mentioned nothing about this.

So now I had an iPhone that is a very pretty brick. I guess it’ll be going back in the morning…

No fixed topic (as usual) so just a general chat about Web 2.0 technologies in the relaxed atmosphere of a Pub in central London next door to where Sweeny Todd used to butcher people.

Demos are welcome – so bring along your latest gadget/tool/service or whatever, although don’t expect any Wifi!

As usual, signup on Upcoming, and stay tuned to the calendar or this blog for updates.

Tags: london20, web20, london2.0, web2.0, london, meet-up, social, geek

See you there…

Update 2: The venue is now confirmed as the Old Bank Of England

OK – I thought getting filmed by someone from Microsoft last year was as surreal an experience as I could expect from London 2.0, but I think a plug on Wired News which I came across in Gmail takes the biscuit:

Londoners’ calendars are once again full of networking events, parties and meetups.

The setting is traditionally a London pub and, in the case of events like Beers & Innovations, appropriate liquid lubrication is on tap.

No damn plug for the blog though – or me! I suppose at least one Sam (Sam Sethi) gets a sound bite – even if he does have nothing to do with the event :-)

Anyway, after a not so brief hiatus, the next event will be on Wednesday March the 14th Thursday 15th of March. Details up as usual on the calendar, Upcoming and the official website. Venue tbc The venue will be at the Old Bank Of England, but please comment or update upcoming if you’re attending. QCon will be in town at the same time, so we may have a few gatecrashers…

If one pair member hogs the keyboard too much, the other member can feel that they are not properly involved with development. Depending on your development tools and build times, you may need to identify different points at which to pass control. The important thing is to ensure that both members of the pair get to feel equally involved in the development. Set yourselves a target for the maximum duration for each member to have control of the keyboard – ten minutes seems a good target to aim for, but a shorter duration may work better for you.

Example – Test, Implement, Refactor, Switch

When using Test Driven Development, a good way to develop this tempo is to use the acts of writing a test and making it pass to define when to change over. I’ve seen success in having the person A write the test, then have person B get the test to pass and refactor, then write the next test before passing the keyboard back to person A.

Extreme Example – Chess Clocks

This example was related to me by a colleague. The team in question had chess clocks at each pairing station. The idea was that each member of the pair got to drive for four hours of the eight hour day. To keep track, at each switchover they’d click the chess clocks to start the other persons timer. If at the end of the day if you’d used up all your time, you had to watch. Very quickly each pair worked out a dynamic in which the time became equally distributed – I’d certainly of liked some video footage though!

The mechanical turk is bridge between people who want work done, and people who want to do work. It handles payments, verification, matching qualifications etc. One of the first examples of it’s use was the art project to have drawings of 10,000 sheep done by people all over the world. Now Amazon have used the turk to help search for missing Microsoft Employee Jim Gray.

The turk is distributing satellite imagery of the area in which Jim’s boat went missing – and anyone with an Amazon account can help them out. I’m sure you can find worse things to do with ten spare minutes during your lunch hour.

Tags: amazon, jim-gray, mechanical-turk, web-services, webservices

As a way of letting the development team know that:

• You know the build is broken
• You are fixing it

A simple broadcast mechanism can be highly useful.

Example

Whilst I have seen high-tech solutions being recommended, the most effective example of a Build Fix Flag I’ve seen is simply using a giant paper flag. It was about 2 1/2 feet in height, and could be clearly seen above monitors. When a build failure was seen, a quick glance across the floor would indicate if someone was working on it.

What was nice was that before long, the same mechanism was used for notification of a number of development environments

Rules for the build fix flag

When using such a flag, we quickly decided on a set of rules as to how to use it:

1. If you saw a CI build breakage, you looked for the flag
2. If someone had the flag, you left them alone
3. If you couldn’t see the flag, you tried to identify the person who made the last check in
4. If you couldn’t find a likely culprit, you raised the flag and fixed it yourself

Conferences

With xtech, OSCon, Agile 2007 and XP 2007 I’ve been busy preparing submissions, and I’ll start hearing back from them soon. Rather than continue with my Lego XP Game dog and pony show, instead I’ve submitted presentations on dbdeploy, Buildix, and will hopefully be helping out on a workshop with some colleagues. More information when I get the rejection letters.

Christmas

Well, it was nice – as was the many mammoth Medieval Total War 2 and World Of Warcraft sessions.

Work

I spent a lot of time writing proposals (which I enjoyed) meeting new clients, and playing with Python & Django. I’m getting really impressed with both Django (and the very good Django book) and the mature tool set for python development as a whole. More soon perhaps

Apathy

Yeah, well..I had stuff on, you know? And series two of deadwood to watch

Expect a bit more traffic here, and a London 2.0 meeting for the end of feb

Tags: apathy