I’ve been working on a tool called Hairball to track setter and constructor injection, and use of singletons in Java code. Right now, the tool is capable of creating dot diagrams (for use with GraphViz) and graphml diagrams (for display in yEd).
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.
Update: There is a workaround for this problem, which allows you to sign-up for a prepaid account with AT&T which sidesteps the need for a Social Security Number. The Unofficial Apple Weblog has the full details.
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…
I upgraded to the latest and greatest version of Wordpress at the weekend, but forgot to reconstitute my .htaccess file, so everything apart from the index page was 404ing. Normal service should now be resumed, but please let me know if you spot anything odd.
It’s that time again – after the success of March, what better than an April meet-up?
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.
February 25th, 2007
8:15 pm
General
I’ll be presenting on database refactoring and specifically dbdeploy at this year’s XTech conference. XTech 2007 runs from the 15th to the 18th of May in Paris, and my presentation will be first thing on the morning of the 17th.
See you there…
Update 1: OK, sorry for the change – but I’ve had to reschedule to Thursday 15th of March. Venue still tbc
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…
February 13th, 2007
2:15 pm
General
One of the struggles people can have when they first start pairing, is understanding when it is time to drive, and when it is time to watch. Developing a good tempo to the act of pairing – and understanding when the change over should occur – can make it seem like a much more fluid activity. When it is working well, outsiders will see the keyboard moving backwards and forwards between the pairs (albeit perhaps slightly slower than a game of table tennis!).
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!
I’ve long been a fan of Amazon’s emerging webservices such as S3 or the mechanical turk – without doubt they are doing some of the most interesting things with web services anywhere on the Internet.
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.
January 31st, 2007
10:25 am
General
When using a Continuous Integration build, before long you’ll break it. Breaking a build is not a bad thing, however it is typically the team’s top priority to have such a build fixed. Beyond the shame associated with having been named as the breaker, you then have the hassle of lots of people informing you you’ve broken it.
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:
- If you saw a CI build breakage, you looked for the flag
- If someone had the flag, you left them alone
- If you couldn’t see the flag, you tried to identify the person who made the last check in
- If you couldn’t find a likely culprit, you raised the flag and fixed it yourself
January 29th, 2007
11:22 am
General
List below, not neccesarily in any order, are the main reasons given for the lack of activity around both this blog and London 2.0:
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
