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…
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
January 29th, 2007
12:41 am
General
When running a suite of tests – either as part of a Continuous Integration build, or part of a check-in gate – speed is the enemy. You are always trying to find the balance between test coverage and time to complete the entire suite.
Both a check-in gate and continuous integration build have slightly different time pressures. The optimal duration for both will probably vary from team to team. A fish-eye suite is one way of formulating which tests should be included.
In a fish-eye suite, you focus on those tests which provide the best coverage for those areas of functionality currently being developed, whilst those areas not directly being affected have only minimal coverage. The logic goes that tests are there to pick up bugs, and therefore tests which cover the functionality currently being worked on are the most important.
Regularly changing the focus
In an iterative development process, working out where to change the focus of the suite can be easy. At the beginning of each iteration, the team as a whole decide which tests (or group of tests) should be run in each suite. During a development process where there is less segmentation, changing the suite on an ongoing basis may be more sensible
Reactive test suite
Rather than changing the focus of the suite at the start of each iteration, you can also decide to adapt the contents of the suite in certain situations – for example when the total time for the suite to run exceeds an agreed limit, or the number of bugs reported against a functional area increases.
For example, the team may decide that the check-in gate build should take 30 seconds, and the CI build should take no more than five minutes. The moment they take longer, the team as a whole should redefine what tests should be included. When removing tests, the team should look to remove those tests which cover areas of functionality furthest away from those currently being worked on.
Likewise if the number of bugs being raised against a certain functional area increase, the development team may decide that increasing the test coverage of a certain area makes sense. Again, the team may have to remove some tests in order to still be within the optimal build time. In which case, tests associated with areas of functionality with low defect rates make a good candidate for removal.
Source-Code Management
Being able to create and manage a fish-eye suite presupposes that you group your tests into functional areas. This can be an issue with typically packaging structures which are defined in horizontal terms, whereas the long running functional tests should cover a vertical slice of functionality.
Even if initially you aren’t going to use fish-eye suites, grouping your tests into functional (vertical) groupings rather than system (horizontal) groupings makes sense as it allows to to easily use this approach later. It also tends to make more sense to testers who see things in terms of usable functions rather than horizontal tiers.
