(I’m upping the anti)

The next person that whinges about restriction of smoking to private homes will receive a free gift. Yes ladies and gentlemen I shall stand next to them, and share with them the gaseous byproduct of my digestive process. It�s my RIGHT isn�t it? Isn�t it? — David Jericho No it is not. Quite the opposite in fact. As part of your right to life, you have the responsibility to not interfere with the right to life of others. Since smoking reduces the expected life span of the people around you via passive smoking, you are interfering with their right to l’#8217;m sure you could also word that around having the right to not have people reduce your health’#8217;m not sure how to word it clearly and the right to life is a far better established right. As for the threat to share the “gaseous byproduct of my digestive process”, were it enacted, I would be forced to remove the fire hazard with extreme prejudice (and the closest bucket of water). UPDATE: er, clea’#8217;m an idio’#8217;m agree with David entirely. I guess I got confused with the anti-antiness of it all.

If you ever try to download, burn and install the Ubunto warty ISO image on OS X you’ll find that Disk Utility crashes and hdiutil crashes. To get it to burn you need to install cdrecord using fink (fink install cdrecord) and then use the information on this page to work out how to burn it. On my PowerBook G4 with a DVD-R/CD-RW drive I used the command: sudo cdrecord -v speed=24 dev=IODVDServices warty-rc-install-powerpc.iso and it’s working fine. We’ll see how it goes from here on in.

Iain points to this gem of an article. Some choice quotes:

Dr Greening and colleagues asked 42 men to ejaculate every day for seven days Excuse me Sir. Yes, sorry to interrupt – would you mind doing me a favor? Yes, I just need you to jerk off every day for a week. … Say, how’d I wind up in hospital again?

I think it’s exciting Don’t we all Dr Greening. Don’t we all.

I’ve had my old powerbook lying around for a fair while now not doing anything so I thought it was time to put Linux back on my desktop. I’ve pulled the laptop back off the shelf, booted it and found Debian is already installed and running okay. So I officially have Linux running on the desktop! Now what?

Martin Pool gives an informative pros and cons list of Ubuntu Linux versus a number of other OSes. I’d like to jump off on a tangent. Martin gave a plus ot Ubuntu for:

• Less Macintosh historical baggage. Mac apps can be in the wierd state of running but having no windows open: GNOME designers just know this is silly. OS X suffers some friction between the Mac and Unix parts, in e.g. case sensitivity or resource forks. While there is definitely some historical baggage in Mac OS X (not much mind you – Apple were pretty ruthless with cutting things out), the ability for an application to be running without any windows open is actually a design feature and not historical baggage. When described as “the wierd state of running but having no windows open” it sounds downright stupid, but if you describe it as “the ability for the menubar to not disappear suddenly when closing a window” it makes a lot more sense. The Macintosh menubar is placed at the top of the screen because it’s significantly faster to access the menus when it’s placed there (plenty of research backs this up – essentially the sides of the screen have infinite depth so they’re easy to hit). Since the menus are at the top of the screen and not in the window, it makes no sense for the menubar to change when you close a window. Thus, when closing a window in an application the application continues running allowing you to open a new document, adjust preferences etc etc. That’s not the only reason though. Think of someone using pen and paper who has two tasks to complete. They start the first task by getting out a clean sheet of paper and writing on it until they are finished. Then they file that piece of paper away. Finally they start the second task by getting out another clean sheet of paper and starting writing again. In other words, the life cycle is:

1. Create a new document.
2. Work on document.
3. Save and close document (filing both saves the paper and removes it from the workbench)
4. Create a new document. If you were using Gnome, Windows or pretty much any OS other than Mac OS, step 3 would suddenly cause your pen to jump back into the drawer. You’d actually have to rethink the order you do things in to open a new document before you close the previous one. Now you might argue that people typically work on more than one thing at a time and they are likely to have both documents open anyway. They might indeed but in that case there is another subtle benefit. When they decide they’ve had enough of work and want to put it all away and play a game, they simply hit command-Q and all of the documents in that application close. It’s like having a bulldozer that can file things neatly. The disadvantage to the Mac OS way of doing things was that on OS 9, you didn’t realize the application was still running and either ran out of RAM or got really confused when you next double clicked on the application and nothing happened (in fact the menubar changed but noone seems to notice that). OS X (and the magic of modern computing) solves both these problems. Firstly, you won’t run out of RAM anymore because OS X has virtual memory and the ability to move things around in RAM (OS 9 loaded things in order and fragmented memory effectively couldn’t be reclaimed – plus the virtual memory was really bad). You could leave every application on your system open in OS X and it just wouldn’t matter because the unused applications would be paged out to virtual memory. Note that because they are unused they wouldn’t constantly have to be paged back in either so no hard drive thrashing. The second problem is solved in two ways. Firstly there is a reasonably obvious indicator that an application is open (the icon appears in the dock if it wasn’t already there and a black triangle appears under the icon). This helps a little, but not a lot. The biggest improvement is the Aqua Human Interface Guidelines change which now requires that when the user clicks on an application in the dock or double clicks it in the Finder (the same actions used for opening it) the application will bring it’s existing windows to the front if it has any, or create a new window if not. If you combine the effects of these two changes, the result is that the “weird state” of an application being open but with no windows effectively ceases to exist. The user can be completely unaware that the application is running and continue to go about their work without ever noticing. When they try to open the application again it behaves exactly as it would have when first opened and displays a new window. There is no noticeable impact on resources because the RAM can be swapped out to disk and made available to other applications and modern hard drives have plenty of space to cater for this. The user is now able to operate in their logical order without menubars unexpectedly changing on them. So as it turns out it’s the GNOME developers who got the UI design wrong predominately by putting the menubar in the window instead of at the top of the screen. Once they’d made a mess of that behavior, it wasn’t really an option to avoid the disappearing menubar problem because the menu is so inextricably linked to the window.

My Queen CDs are here! Yay! I ordered “Queen – Greatest Hits I, II & III” a week or so ago after getting hooked on both We Will Rock You and A Night At The Hip Hopera and it’s finally arrived. I’m in the process of dumping into iTunes now (Apple lossless encoding so even the purists should be happy) and will then commence burning a copy of the CDs to listen to in the car (CDs don’t tend to like the extremely high temperatures cars get to around here). I don’t particularly care if that illegal in Australia – I want my Queen in an accessible format and I don’t want the CDs to get wrecked. Besides, since I bought it from the US I get the same rights as if I were in the US right? I like that logic anyway. Besides, I just deserve it, I’ve earnt it – it’s my precious.

A little while back I said duplicate code was the biggest codesmell I knew of. I was wrong. There is a level of smelly code that goes well beyond duplicated code, in fact it goes well beyond anything a professional programmer would ever do. That is the smell of code that doesn’t have JavaDoc comments. From time to time every programmer will get lazy and not bother to add a comment for something but every so often you come across a code base that seems to have a systematic policy of removing any JavaDoc comments that might prove useful. Sadly, I was reminded of this when attempting to use BCEL. Vast swaths of that project are completely devoid of JavaDoc comments. Maybe the functionality of those methods are completely obvious to anyone who’s ever touched the codebase, but I’m trying to work out how to use the library so I need to at the very least be told “this method is not for you – go away”. In the end I gave up and used ASM which is still fairly light on JavaDocs at times and quite often the JavaDocs that are there are too abrupt to be particularly useful but at least there’s something. All the same, the process of using ASM is essential a case of trial and error unfortunately. So if you ever teach anyone Java, beat into them how useful, powerful and important JavaDoc comments are. It doesn’t matter how neatly laid out your code is or how obvious the functionality may be – most people who go to reuse the code are going to look only at the JavaDocs either through the generated HTML or through their IDE. Make sure the information there is useful.

It appears the java.net crowd picked up on my labeling some of them wingers – the response has been much more polite than I would have expected (or deserved really). The most well reasoned response so far is from Chris Adamson who points out the history of Java releases lagging behind on Mac as a reason for people to be worried. Before I go into Chris’s comments, let me point out that there are two main groups of people:

Oliver Hutchinson commented on my last code duplication entry:

Another way that duplication sneaks in is when people reimplementing something for which there is already a perfectly good library. For instance, your example of arranging dialog buttons in the appropriate order for the platform is taken care of very nicely by the JGoodies forms library. Actually Oliver, this is the perfect example of when you should duplicate code. There are a few reasons for this, the most obvious one being that JGoodies depends on Java 1.4 and our software currently only requires Java 1.3. Dropping support for Java 1.3 (and thus IE on Mac) isn’t really worth it to save writing 4 lines of code. Secondly (and far more importantly), the JGoodies forms library provides an entire library for laying out forms. We don’t want an entire library for forms layout – we already have that problem solved using the standard classes in the JRE. The JGoodies jar file would add an extra 80k to our applet which while not awful, would be 79k or more we didn’t need. Thirdly, adding an extra library increases the chances of a conflict occurring in our JavaBean version if one of our customers is using a different version of the JGoodies library. To avoid this we’d have to rename the package which results in duplicated code again except now the entire library has been duplicated. Finally, the JGoodies code is significantly more complex than it needs to be. It’s simply not a good implementation given the set of requirements we have. The JGoodies implementation uses a Factory class, a Builder class, an AbstractBuilder class and a custom layout manager as well as a host of other classes. Our implementation uses a JPanel and an if statement. Granted, the JGoodies implementation is capable of creating a wide range of different button dialogs that work in a much wider set of situations, however none of that provides any benefit to our project. Adding dependencies is a choice that has to be weighed up very carefully and should never be done just to avoid writing a few very simple lines of code. Furthermore, when replacing duplicated code with a common library, it is imperative that the requirements (as opposed to the implementation or results) of both pieces of code are the same. It is not enough that they be similar, they must be the same – they have to logically be the same function before they should be made actually the same function. On the other hand, if JGoodies had already been in use by our application, Oliver would have been completely correct that we should have used the existing function because it did meet all the requirements and despite the fact that it met a lot of requirements that weren’t needed because we would have to test the custom layout manager etc so the complexity wouldn’t matter so much.

Well David is right. Queen Fans do love A Night At The Hip Hopera. Definitely worth a listen and props to David for bringing it to my attention.

Benjamin makes some good comments about code duplication and software design. I think by and large I agree with him though I do think that less code duplication implies better design, it’s just that there are also other factors which may be more important as well. The critical thing about eliminating duplicated code is to identify duplicated code based on it’s requirements, not on what it looks like. For instance, today I added a new method to our UIUtils class (GUIs are the most common place where duplicate code is created unnecessarily), the method took as parameters an OK button and a Cancel button, created a panel and put them in it in the appropriate order for the platform. It’s about 5 lines of code all up and it’s duplicated all over the place when it should not have been. In many cases, when this code is duplicated, it doesn’t actually look the same – it might use different layout managers, be mixed in with other code or a wide range of variations. However, the requirement is extremely clear cut: On Macintosh the cancel button is on the left and the ok on the right, on all other systems the ok is on the left and the cancel is on the right. The buttons are separated by a gap of 4 pixels. Regardless of where ok and cancel buttons are used or how they are implemented, that requirement must be upheld. Once I re-factored it out into a utility method it also became apparent that OK and Cancel buttons also have to have their preferred size set in a specific way – something we had another utility function for already since the behavior is similarly well defined. So a call to the sizing function is added to the layout function and we have a standard library function that gives us an ok and cancel button pair ready for adding to a dialog. There are other things that need to be set about ok and cancel buttons (for instance their action listeners are almost always identical because of the way we write our code) but that’s getting too big for a static utility method and it’s not always common to every ok and cancel button. Having said that, I really should re-factor out the cancel listener because I can’t think of a cancel button that has different requirements plus it has to be used for the escape key and a bunch of other places. Getting rid of the extra class files the anonymous listeners create would probably save us a hundred k or so. Coming back on topic, the design used isn’t correct in terms of object oriented programming, in fact it’s almost aspect oriented programming as it forms a cross cutting concern across all GUI dialogs, however it is extremely effective, has an extremely clearly defined purpose and is short and simple to understand even at a glance. Possibly the biggest indicator that a utility method should be used is that if the requirements for one dialog’s layout of the ok and cancel buttons changes – the requirements for every dialog will also change. The need for consistency in implementation is a big red flag that there should be a single implementation. So of course now if we ever support a new system that orders the ok and cancel buttons like Mac OS does or perhaps some other layout, we only have to make the change in one place. Essentially, I think Benjamin and I are saying the same thing in slightly different ways, except that I don’t class code that should behave different as duplicated code – only code that has the same requirements is duplicated. On a side note, Benjamin used the phrase:

What’s the thing that most stands out as “gee, this is going to bite me later” code? For me it’s without a doubt code duplication. I really hate seeing duplicate code even if it has slightly different behavior (it should put the common behavior into a parent class or utility methods etc and then just have different code where the behavior is actually different). Every time I see code duplicated I just know that a bug will turn up in it at some point and it will wind up only being fixed in one of the copies. I also tend to design using generic plugins a lot. Sometimes I probably take it a bit too far but most of the time the generic approach winds up being much more flexible and robust, plus it’s usually easier to understand generic plugin style designs because they separate out functionality a lot more clearly – this plugin does this, that plugin does that. Of course, generic non-plugin type designs tend to have the opposite effect. There’s also this really messy middle ground between a plugin style design and a non-plugin design where things just wind up coming out ugly. Usually you get into that area when the functionality hasn’t been split up carefully enough or when the desired functionality is different enough to require separate functionality. One of the areas I haven’t found a design I’m happy with yet is for menu and toolbar code – particularly when the menu and toolbar is configurable. It’s exceptionally clumsy to manually create each menubar and toolbar as if they were completely different things (they’re not – they’re just buttons of different styles that wind up firing an event) but it can also get very messy if you try for an MVC approach because the behaviors can become disturbingly complex (think submenus, comboboxes, toggle buttons, radio buttons, enabled and disabled etc). I’ve tried out a number of ways to handle this and I’m not quite happy with any of them. I’d like to try out a design where each menu is created from a particular definition (a set of properties that describe how it behaves) but that there are separate categories for the different types – so there’d be a toggle button MVC, a plain button MVC, a sub menu MVC, radio button MVC etc all integrated somehow (an overarching MVC kind of pattern?). I don’t know, I’ll have to find a project that will let me put it into code at some point and see what comes out of the concept.