Object Definitions Blog

I just switched to using a Linksys NSLU2 NAS server for my home network.
It’s a great little thing - you just connect USB drives to it and set up network shares using the nifty web administration utitlity.

None of this is new - the NSLU2 (or ’slug’, as they are known) has been around for years now, and there is a cottage industry of linux kernal hackers grown around it, to adapt it to do such things as streaming music etc.

What is new, however, is that it won’t work from Vista. Works like a breeze from XP.

The linksys requires LM authentication which was supported by default by XP, but apparently it is disabled by default in vista, which only supports NTLM out of the box. I suspect this is not Linksys’ fault. The upshot of this is that from your spanking new Vista laptop you won’t be able to log in to your home network devices any more. You’ll probably forget they’re even there. The only person who will be able to log into them will be the guy parked up in a van outside who’s hacking into your wireless network using Windows XP. How’s that for security?

The forums are riddled with messages complaining about this, for the linksys and other similar NAS devices.
Most of them refer to now defunct Vista system administration tools
Searching the Vista help gets you nowhere.

Eventually I found a post which contained a registry setting to edit, to enable LM authentication
A registry setting to edit? Whooo, lucky me.
Welcome to the wonderful world of Windows usability.
If there is a utility which allows you to set this, I’d love to know, Windows admin dialogs are a joy.
I suspect I might be still looking at Christmas given how intuitive the admin is in Vista.

Anyhow, the magic LmCompatibilityLevel registry setting can be changed to let you log in to your network devices:

Note, changing this won’t make your network more secure. However, for your home network it should be OK, provided you’ve secured your wireless network. Any self respecting burgler walking into your appartment probably won’t be spending too much time trying to hack your network passwords. They’ll simply pick up your NAS drive and stick it under their shirt while pretending to read the gas meter, and make off with any win XP laptops (although they may leave your vista machine where it is)

You can edit the registry using the regedit utility
Have fun!

I’ve seen far too many bugs lately involving lazy initialization.

In theory lazy initialization might seem a good idea. Why do extra work up front which might not be needed?

The problem is that it is simply too easy to introduce bugs when state is not completely loaded after construction. For example, a project I recently worked on made extensive use of init() methods to lazily load state on demand. The constructor would not do the initialization. Instead, each getter method would check whether initialization was complete, and if not kick off an init() process before returning data.

The reasons for this were fairly convincing. The loading of the state required a call to a database, which was slow. But the problem was that this lazy initialization pattern soon spread throughout the codebase like a rash. Soon it was rare to find a class which was guaranteed to be ready for use after construction.

Still other classes used lazy loading as a speculative performance optimization. Table models received events which invalidated their internal state. Instead of recalculating immediately, they propagated events to their listeners, delaying their own recalculation. The models would recalculate only when a client class called a method to ask for data, and forced a the model to check its state and recalculate. Again, it sounded good - why take on the overhead of immediate recalculation if your class has no active listeners?

The original coders left. The code base gradually expanded to more than a million lines of code. New programmers arrived. Predictable problems emerged.

In many cases, the new programmers would simply fail to realise that an object was not ready to use until its init method had been called. Init methods had become a part of some key abstractions - although in the vast majority of cases subclasses did not actually require any special initialization. So most objects ended up with an init method, just to cater for the few places where it was really necessary. Confusion reigned as to when and where initialization should take place.

Interfaces changed and classes needed to be modified. It was all too easy to forget to check the initialization status when adding methods to existing classes. Strange errors occurred in the table models. The data had changed some time before, but since the recalculations were delayed it was hard to work out from the logs what had actually triggered the problem. Sometimes the original coders had made mistakes and forgotten to check the initialization state for some methods. In other subclasses had overridden methods and forgotten to include the check. Problems could emerge quite unexpectedly, such as when the ordering of client class method calls changed. This often caused strange data corruption or null pointer exceptions at runtime, which brought down components.

The basic OO tenet that an object should be ready for use after construction really does make a lot of sense - try very hard to avoid lazy initialization wherever possible. It may seem clever, but it probably isn’t. If it seems that lazy initialization is the only way, reconsider every alternative design. Simplicity is key, and lazy initialization or lazy recalculation is rarely, if ever, simple. You’ll likely save yourself some headaches in the short term, and in the long term you’ll save even more for those who inherit the code once you have moved on.

Jetbrains recently sent out an email about a new companion product to Intellij idea - Structure 101. Structure 101 is a tool developed by headway software, which can be used to analyse the architecture and complexity of java applications. This is a very welcome addition to the marketplace for java development tools. (I say new - in fact it seems Structure 101 has been around for a couple of years now, so clearly I’ve not been paying attention!).

Structural problems in code

I am known to be opinionated about this and friends and ex-colleagues will already be bored with me going on about it! The majority of software is not well architected and well structured internally (perhaps in part because the tools to visualise structure at a package level have not been widely available). Some apps are structurally akin to a bowl of spaghetti, with all the negative implications of tight coupling between packages and cyclic dependencies. This is bad news for reuse - if software is full of dependency cycles, classes and packages can’t easily be reused in another context without sucking in everything else too. An acyclic structure is enormously important at the package and class level - not just at the level of the release unit. After all, a release unit today may need to be split into two in the future - to enable better reuse of some of the logic it contains.

Improving structure to remove dependency cycles between packages and classes can be hard - but it is not insurmountably hard, especially if you have the right tools for the job. And it pays major dividends, resulting in far easier reuse and a more intelligible project in the long term. Changes made to projects developed with these principles in mind tend to be more deterministic in their impact, since the ripple-through effect is minimised. And the great thing is that the methods required to achieve this decoupling are well known and accepted as good programming practice in their own right - chief among these, that concrete classes should depend upon abstractions. Introducing an interface is the most common way to decouple a cyclic dependency between two classes.

Avoiding bad structure

This is where tools like Structure 101 come in. It allows you to zoom in to view dependency problems within your application, and makes it far easier to visualize the layering and package structure within your project. Not only that, but it gives a summary of complexity, highlighting classes and areas which need simplification.

This is not a radically new goal. Other tools have attempted the same thing in the past, for example ‘Pasta’ (which became OptimalAdvisor), and ‘SmallWorlds’ (which became SA4J). Both of those were promising products which were swallowed up by big companies and disappeared for a time, stagnated or became prohibitively expensive. However, there is some genuine innovation in Structure 101, over and above the others. I have found it to be effective in zooming to the areas of applications which are the most problematic. It lacks the refactoring support which OptimalAdvisor provides - but then most developers would use their IDE for refactoring in any case, so it is not clear this is a significant disadvantage.

One feature I particularly like is the ability to upload structure diagrams to a shared repository. IDE plugins are then provided which allow developers to validate their changes against a shared model - without having to purchase a license. This is a great idea, which will facilitate much wider use of the tool, and allow teams to collaborate much more easily to maintain a desired architecture. This may help to overcome the natural entropy shared by all multi-developer projects. However things are still not perfect - licenses are node locked, which means a developer may need two licenses to allow him/her to work from home and in the office.

All things considered, Structure 101 is a tool it is certainly well worth checking out - it is my new number one tool for validating the quality of code.

Time to join the vista rant-wagon.

I have now had the joy of installing vista on two of my machines.

Actually the first install wasn’t all that bad. It was an in place upgrade from XP, which actually worked ok. However, under vista the machine now seems to be accessing the disk on a fairly permanent basis. I think it’s possibly trying to defragment over zealously. Sure I could probably sort it out if I spent time tweaking, but actually that’s not why I buy an expensive operating system - If I want to tweak I’ll go with fedora or ubuntu, stay richer, and enjoy it a lot more!

The second machine has been a nightmare. First I tried the upgrade from XP (it’s an XP media centre machine, nothing particularly out of the ordinary hardware-wise). At least a year and a half old, so should be no problems with hardware compatibility you would think. You would be wrong. Although everything runs fine under XP, even something as mainstream as the nvidia graphics card (a 7600 series) seems to suffer strange glitches under vista. Switch on visualization when playing music and it blue screens instantly.

But even getting far enough with the install to find the media center bugs proved difficult.

After the upgrade there was a problem installing a patch to upgrade the .net framework. It was a critical security update, but it simply would not install. I read the ms support forums (lots of similar reports there), ran the tools to manually uninstall the current version and clean out install shield info from the registry- but still no joy. There was seemingly no way to get it uninstalled, and the inability to install the patch left the whole system open to random attacks.

So then, a complete reinstall was on the cards. Everything seemed to install OK - well almost OK. After installation 48 updates came down.
So as expected, vista installed them on shutdown. So far so good. And then it went into ‘configuring updates’ screen on the restart and sat there for 3 hours. After which it went into ’shutting down’ and sat there for 9 hours.
Nine hours - seti@home has almost discovered aliens in less time than that… There was disc access taking place, so I was loathe to turn it off.

Eventually, the next day, I pulled the plug. After a power cycle the same pattern happened all over again. ‘Configuring updates’ for several hours, followed by the failed shutdown. Judging by the amount of moaning on the inet, I guess I am not the only one this happened to. All vista pcs seem to suffer from this annoying need to ‘configure updates’ on restart, having seemingly installed them on shutdown - and whenever it happens it now sends me into a cold sweat. Will it hang? Won’t it hang? If you are really lucky, when you turn the pc back on it configures the updates and then switches the machine off for you, automagically. But hang on - I thought I just turned the back on? Now I’m just confused.

Anyhow, that was the weekend over, and still no working media center for you, squire. This was rapidly getting boring. Finally a safe mode boot seemed to break the configuring patches cycle - but what a waste of time. And there are still critical update patches which failed to install. So what now? OS X? But I don’t want to have to beg Steve Jobs for my next JVM, either. And I’d like to choose my hardware.

Trying to install vista has taken me all the way back to those dark days I spent trying to get Sonic the Hedgehog to load from a second hand tape deck on my Amstrad cpc6128. Still, to balance this, I have a slight feeling that buried deep underneath the security popups there is an OS in there somewhere which is better than XP. Perhaps service pack 1 will make it all worthwhile. If anyone can ever get it to install.

Well perhaps speed is not everything, but it is an important consideration when selecting a testing framework.

I was briefly brought in to help with a struggling project recently. In theory it was all good test driven development - that ought to improve the chances of somebody new to the project being able to set up a working development environment and make changes without breaking anything critical, since the tests are there to guard against any deliberate mistakes, right?

Well that is all good in theory, but in this case the unit and acceptance tests were taking well over three hours to run. To make things even worse, since the project was in trouble as I mentioned, there were some intermittent bugs lurking which had never been rooted out. This would mean that even after running for a couple of hours there was a good chance that the tests would fail in a manner which was not necessarily reproducible. Some of these bugs were probably associated with the testing framework code, rather than the actual product under test.

So what was the implication?

Well on any day, you could at most run the test suite twice, and even then the results could not be relied upon. For a new developer setting up an environment, it might take at least a couple of days just to achieve a first successful test run, or perhaps it might never be achievable. This totally negated all of the value normally associated with a comprehensive test suite, and actually made the tests worse than useless because of the time wasted waiting for the flawed tests suites to run.

As time went on, rather than spend time fixing the test framework and improving the speed, the team (because they were under pressure to fix the bugs, right?) opted to allow broken tests to stay broken, delaying their fixing to a single massive crunch in the days and hours immediately before each release.

This is probably not what the gurus of XP intended…

There are some lessons which can be learned here:

1. The tests are at least important as the product being tested, and should be maintained as such. Always fix tests immediately.
2. The testing framework is at least as important as the tests. Time spent improving it is time well spent!

And lastly, I have a new rule of thumb I am calling the long test suite conundrum:
The value of a test suite decreases as time taken to run it increases

Longer running test suites have lower value to a team. Of course many other factors affect the overall value as well, but it is pretty intuitive that a test suite that never completes has almost no practical value, whereas a test suite that can be run in seconds gives instant feedback, and therefore has high value. (This effect can be offset slightly by continuous integration environments which run the tests automatically, but the basic principle is still valid). Speed is therefore an issue of critical importance in a testing framework.

One of the side effects of the above rule (and the reason it merits the conundrum label!) is that by adding more tests you might actually be devaluing the test suite if your tests run slowly! So, even if you are improving the coverage, the overall effect may be detrimental, depending on how long the new tests take. So, it seems more tests are not necessarily a good thing. The ideal test suite has 100% coverage and executes instantly, whereas a suite of tests with zero coverage which never terminates is the worst possible. Either increasing the coverage or decreasing the run time will increase the practical value of a test suite to a team. So this is why it is even more critical that tests are optimized at least as much as production code, and that your team has tools which run tests quickly and efficiently. Simply adding more tests while overlooking optimization can have very bad long term consequences.

My current team recently rejected several Swing testing products since although they were rich in features, they increased our test suite time to well over an hour, from the current 5 minutes.

I recently had to draw some diagrams for a recent project involving a complex GUI. It is all too easy to get sucked into adding more and more detail to UML class diagrams, until in the end you lose the design message you were originally intending to convey. You end up spending more time drawing a diagram which is actually less instructive.

I was interested to see Martin Fowler’s comments on this, in his essay entitled ‘Is Design Dead‘ :

So here’s my advice for using diagrams well.

First keep in mind what you’re drawing the diagrams for. The primary value is communication. Effective communication means selecting important things and neglecting the less important. This selectivity is the key to using the UML well. Don’t draw every class - only the important ones. For each class, don’t show every attribute and operation - only the important ones. Don’t draw sequence diagrams for all use cases and scenarios - only… you get the picture. A common problem with the common use of diagrams is that people try to make them comprehensive. The code is the best source of comprehensive information, as the code is the easiest thing to keep in sync with the code. For diagrams comprehensiveness is the enemy of comprehensibility.

I suppose effective diagrams are often, by nature, a simplification of real life.
I am thinking now of the London tube map, which famously abandons geograpical accuracy in favour of legibility and good communication. In comparion to the map of the New York metro, it is fabulously easy to interpret.

I have seen far too many CVs recently which just list every possible technology acronym, in no particular order.
The latest applicant also helpfully listed patterns, and the four listed included the well know Startegy and Singeleton patterns! At least this gave me a starting point for the interview!

When I ask about patterns in interviews, applicants usually start by describing the Singleton pattern, and I inwardly groan. There are so many reasons not to talk about Singleton, or at least if you do, to mention its limitations. In fact, it is now practically considered an antipattern.

Why Singleton is practically an antipattern:

So, in summary, passing in a reference to an instance via a constructor or setter method is nearly always better and more flexible than accessing it using Singleton. If you find it is getting boring passing references to object instances around, consider using Spring, or a similar framework, to wire your application together declaratively, and remove the drudgery.