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.

Sun released Java 1.5 (or 5.0 or something) yesterday and today suddenly there’s a whole bunch of people complaining that Apple hasn’t yet ported it to Mac OS X. What the? People do realize that porting the JVM takes time right? Apple don’t get the final source code from Sun until Sun finish it (oddly enough) and Sun only just finished it. Sure Apple has had access to prerelease builds from Sun (and similarly Apple Select and Premiere developers have access to a seed release of Java 1.5). It will take time to for Apple to port the JVM and add in all the extra little details they provide (where little amounts to an entire L&F plus more). Then it has to go through QA (you do want it tested right?) and then it will be released. Daniel Brookshier” leads the charge with the whining. Of particular note is the comment:

I’ve had it. I officially declare that I am not part of the open source community. I am in no way associated with it at all. I may just happen to use open source projects, I may just happen to contribute stuff back from time to time and I may even have an apache.org email address but please don’t associate me with the open source community. So to Marc Fleury, Michael Tiemann and Jonathan Schwartz you can have open source – I don’t want it anymore. However I would still be proud to be considered part of the Apache Community (even though they just happen to create open source software) and probably a bunch of other organizations that just happen to create open source software that I’m yet to get involved with – I just don’t want to be associated with the pathetic one-up-manship and ego trips that has come to dominate the “open source community”. I don’t just mean from corporate blogs either (though that’s what set this rant off), there’s far too much emphasis on who’s better or who’s “more” open source or whether or not things are “open source enough” rather than concentrating on building a strong community which is directed towards a specific goal (which may just happen to involve creating open source software). The need to focus on community applies to pretty much anything where people have to work together, proprietary software teams need to work well together as a community of developers just as much as open source developers (having someone walk away from a project generally hurts a lot more in the commercial world). Oh and don’t even get me started on these people who try to insist that open source software isn’t the opposite of commercial software – the intent of the author is clear, get over it. If you want to be picky, Jonathan Schwartz is right on one thing – open source is not the opposite of proprietary. Just because you have the code doesn’t make it any less proprietary – it just makes it easier to develop interoperability solutions. Oh and for the record – yes this is just an incoherent rant that is most likely contradictory and only partially thought through. Heaven forbid it might also contain a misplaced apostrophe…

Ted Leung came out with an interesting comment in relation to the mass of communications mechanisms:

I need a whole display just for communications! In fact, that’s precisely how I use a second monitor when it’s available and how I use my laptop when I’m at work. The second monitor is there just to run the various IM clients, IRC clients, mail and iTunes. Typically I also have NetNewsWire open on the second screen to handle the mass of news/blogs/comics feeds. I don’t really find a second monitor useful for much else – I focus much better on single monitor so switching apps works better than switching monitors and most importantly, having to move the pointer a few thousand pixels to start working with a new app is extremely tedious.

Since someone got me thinking about copyright and related stuff I stopped and thought about which creative commons license I’m using for this blog. I was previously using the Attribute Share-Alike creative commons license, but have now changed to the Attribute license with no requirement to share alike. That seems to fit my views on how copyright should work and how I want this blog to be used fairly well. I did consider public domain but it would annoy me if no attribution was given and I don’t see any real reason to allow it given I would be annoyed. This change applies to all existing entries. Now lets see those creative uses of my incoherent ramblings! Perhaps turn one of the entries into a song? Rap or country would seem to be an appropriate level of quality – take that as you will….

Anthony Towns give a good rundown about how there’s no evidence to support the claim that “pirate” DVDs support terrorist organizations. It should be noted that this is a highly tangential topic to what Anthony was writing about – he just got me started on this so linking to his entry serves as a means to let you catch up with my thought process while giving the added benefit of linking to a highly informative piece. I do feel somewhat compelled to point out that regardless of whether or not pirated DVDs support terrorists or not, the large scale for-profit infringement of copyright is highly unethical. Don’t take that to mean that I think it’s unethical to make a copy of your favorite CD so you can play it in the car, or put a copy on your iPod or even making a copy for a friend. In fact I’d go so far as saying that downloading a copy of your favorite song so you don’t have to pay for it is not necessarily unethical (questionable but not clearly unethical). However, when you start to make money off of copyright infringement I believe you’ve taken it too far. Artists do have a right to compensation, it’s all well and good to say that they still have their copy so they’ve lost nothing, but it is important that people can make a living out of creative works. Selling illegal copies of an artists work really rubs me the wrong way. Now, on the other hand if these “pirates” had taken an existing work and given it a swashbuckling sea shanty feel then rereleased it for profit then I’d put the actions back into the questionable area (and in fact I’d lean towards saying that it’s a good thing). Extremes are generally not good for society. So it’s not good that the MPAA, RIAA (and other similar organizations) want to completely eliminate fair use, nor that they want to lock up creative works under copyright law forever. Similarly, it’s not good to simply throw out all the copyright laws and leave artists with no way to recoup costs of creation or make a living out of their works. The trouble is finding where to draw the line. One of the things I find so frustrating about the current copyright laws is that it’s practically impossible to build on to existing works to create something better. This is essentially the case of our pirates providing a swashbuckling version of the latest hit that I mentioned earlier. I firmly believe that it is in societies interest to have a very active creative culture and I believe that building onto existing work is an important part of that culture of creativity. There are two main benefits provided by allowing people to build on top of other people’s work easily. Firstly, it provides a simple and effective way for new creators to get started. Thinking up a good, original idea for a song, screen play, musical, whatever is really hard and doesn’t happen often. Thinking up an interesting new viewpoint on an existing work however is fairly simple. This provides a simple starting point for people to get into creating and develop the skills required to execute a creative project without running into the roadblock of the original idea. More importantly however, building on top of additional works can improve on the original work either by being better written/performed, by taking a more interesting view point or simply by updating it for modern times. Romeo and Juliet is a classic love story, the essence of which can be enjoyed by people old and young alike. However, culture has moved on from Shakespearean times and while some may find that disappointing, it would sadden me to think that the pinnacle of writing was in the past. More importantly, it would be sad to lose the classic story line in Romeo and Juliet just because the writing style is outdated and doesn’t appeal to today’s audience as much. Fortunately, because the copyright has expired, people can build on Shakespeare’s work to produce updated versions like the sensational West Side Story and the movie of the same title which brought these works to a whole new audience to be appreciated in whole new ways. Having said that, I would be really annoyed if someone took my work, made only very minor changes and published it as their own. I would be thrilled if they added substantially to it and gave credit (even if they made a lot of money off of it and didn’t pay any royalties to me). I’d probably be annoyed if they made substantial changes but didn’t credit me with at least giving them some inspiration. So there is a fine balance here and a set of ethical behaviors need to evolve and be recognized. Such a set of behaviors is already in place when it comes to quoting research however those behaviors don’t directly apply to other mediums and other types of creative work so new sets of ethical standards need to be created and where (and only where) required backed up by law. The end aim, at least in my opinion, must be to improve the availability and quality of creative works within our culture and not to build or support an industry around creative works. Those two aims however are not entirely at odds with each other, in fact it is essential to have some kind of industry built around creative works to provide the monetary backing required to actually fund creative projects as well as to allow creators to pay their living expenses while devoting their full time effort to creative works. Where the right balance is and how you find it, I don’t know. I do know however that it isn’t what we’ve currently got and it doesn’t seem to be in the direction we’re heading.

For as long as I can remember there’s been a Yamaha electric organ at my parent’s place – I spent many, many hours playing it in my youth but since I moved out of home noone plays it. Now every time I come home my mother tells me the organ’s had it and broke down long ago. Of course once I plug it back in and actually try playing it everything works as well as it ever did. I’m not sure what I’d do with myself on my trips up home without that organ….

I’m heading up to Ingham (just north of Townsville in far north Queensland) tomorrow for a week holiday and my sister’s wedding. I’ve had to pack the absolute minimum clothing as I’m taking up a huge collection of musical instruments and assorted junk. 2 saxophones, a ton of music and I’m still not sure how I’ll fit my saxophone stand in. I’m borrowing my younger sister’s clarinet while I’m up there to play as the bride walks down the isle so I’ll have the week to learn to play that. It’s pretty similar to the sax and I’ve played clarinet previously without sounding too bad so it should come off okay. I’m more concerned about the rendition of “The Rose” on keyboard I’m meant to do as backing for my little sister while the register’s being signed. Somehow I liked the original idea of having a few musicians involved instead of just me but it’ll give me something to do anyway. Aside from that I need to find out a few things about the bridal party – most of whom I’ve never met – as I’m the MC for the evening and probably should have something half intelligent to say when introducing people. On the plus side, I’m far enough away that I haven’t had to worry about all this until now – everyone else has been madly organizing things for months.

Brad makes an excellent comment regarding the root logins via ssh issue:

I think the biggest disagreement we’re having here is where should this be solved. Adrian , as a developer, thinks it should be coded around. Myself, as a sysadmin, think the user should take some responsibility for their actions and check their setup on the critical pieces of software – in this case, the Internet accessible ones. It all makes sense now. I think the movie Babe probably best covers this when the sheep dog goes to talk to the sheep and talks very slowly and clearly because every sheep dog knows that sheep are stupid. When the sheep reply they do so very slowly and clearly because every sheep knows that wolves are ignorant. In this case every developer knows that all users are stupid and so they try to make everything work as safely and easily as possible. Then of course every sysadmin knows that programmers are incompetent and so they double check everything and always assume that the developer has stuffed up. It’s then quite natural (and indeed beneficial) for Brad and I to have differing reactions to this issue. As a sysadmin Brad knows that he should read the README.Debian files for the security related packages he installs and that he should double check configuration files (plus he often knows how to do this off the top of his head). As a developer however, I know that when the software gets into the hands of end users (as operating systems for PCs generally do), the users aren’t going to do any of this (mostly because they won’t know how) so the default configuration should be secure and stable to avoid the user having problems.

Brad comments on my condemnation of root login being enabled in the default SSH config for Debian systems (noting again that SSH is disabled by default).

Debian’s SSH package explicitly asks if you want to run the ssh daemon, and by choosing to do so, you take a certain level of responsibility into your hands. Granted – Sandra acknowledged this and I acknowledged this.

I don’t agree that its the software’s fault more than the users – as a maintainer you make some assumptions, some of which will not match the users requirements, and its up to the end user to ensure that it meets their needs. The assumptions should always err on the side of security. It is trivial for a user to turn something on if they discover it is missing – it is effectively impossible for them to (knowingly) turn something off if they don’t realize it’s turned on. Microsoft is very often criticized for leaving unneeded services on by default and not being configured securely by default – Linux should receive the same criticism when it falls into the same trap.

With the real planet humbug down, I’m only occasionally checking the temporary planet humbug since it’s not coming through my RSS feeds at the moment. While I wasn’t looking, there seems to have been a little bit of a stink kicked up about Linux’s security. The story as far as I can tell seems to be that Sandra Mansell had her Debian router compromised because the root password was a dictionary word, ssh was available to the world and root logins were allowed. She took responsibility for the compromise pointing out that it was “lazy” (I would have said careless or possibly even crazy) to use a dictionary word as the root password and then complained that Debian’s default settings were to allow root logins over SSH. Brad Mashall and Greg Black then provided some useful advice on setting up SSH and security in general. However, from both posts (particularly Brad’s) I got the impression that this was entirely the users fault. I’d very strongly disagree with that. Was the user at fault? Absolutely, and Sandra acknowledged that. Was the software more at fault? Absolutely. It is very common knowledge that allowing root logins via ssh is an unsafe practice and should be avoided. It’s completely inexcusable for the Debian developers to have root logins enabled by default and even worse that it (apparently) doesn’t even display a warning about this. It is simply not good enough for an OS to ship with insecure settings and expect ordinary users to perform a full security audit and know all about arcane config files to make their system secure. The OS installer should always make the system as secure as possible given the features the users have indicated they need. Specifically, the installer should have disabled SSH by default (I think it did) then when told that SSH was required, it should have left root logins disabled. Better yet, it could have asked which accounts were required, from which networks and hosts and whether or not it could generate a key pair to be used for authentication and disable password authentication. All of that however does make the installation more complex so there’s a balance to be reached, but since there’s almost never a reason to allow remote root logins I’d be quite prepared to criticize the developer responsible for that configuration being the default. I’d then set about making sure that the users understands where they went wrong and how to avoid similar problems in the future (most likely by pointing them at Brad and Greg’s comments, which I definitely suggest you read). Why is it that in commerce the customer’s always right but in software the user’s always wrong?