Archive for July, 2006

Ubuntu On The Desktop

So I’ve been running Ubuntu as my primary Desktop at home for the last four months or so.  I’ve never run a linux desktop before, and its been a while since I was a regular *n*x user, so there was a period of adjustment.  Some point form notes:

  • Breezy was good, but Dapper is really good – painless installation, and a lot of stuff just worked out of the box.
  • Maintenance is still a hassle – you can’t make a hard and fast rule, because some stuff is easy.  But when things don’t work, it can be a real pain — building from source, chasing obscure configurations, trawling forums for answers.  Who has time for this?
  • KDE looks great – I tell myself that I’m more worried about content than presentation – but on the other hand I just bought a MacBook which looks superb, and KDE was a no brainer for me, it just looks right.
  • Automatix sucks – it didn’t really break my system, but it actually removed some of my software and my sources.lst.  Thanks a lot Automatix!  I had to put in a couple of hours to get back to where I was.  EasyUbuntu on the other hand didn’t break anything, but it didn’t really give me anything I was missing.
  • Not ready for amd64 yet – If I had to start over, I probably would have built a 32 bit system, hardware and software.  The 64 bit issues are just too time consuming.

Overall I’m happy, I haven’t missed windows — but I have blown hours getting everything working (while some other stuff still doesn’t work), and that is time I’ll never get back.

Sometimes Your Team Isn’t Ready

A great paragraph from Refactoring To Patterns (italics are mine):

Refactoring embellishments out of a class can produce a design that is simple to those who are comfortable with object composition. To those who aren’t, code that used to be in one class is now spread out across many classes. Such a separation may make code harder to understand since because it no longer resides in one place. In addition, having code reside in different objects can make it harder to debug because debugging sessions must go through one or more Decorators before getting to a decorated object. In short, if a team isn’t comfortable with using object composition to “decorate” objects, the team may not be ready for this pattern.

Its great to see acknowledgement that some teams just aren’t ready for some object oriented designs.  Part of being pragmatic means acknowledging the strengths of your team, not being clever for the sake of showing off.  By all means seek to improve your teams skills, but realise that you can’t force them to understand.  In such cases you need to go with a design that is easily understood, in order for it to be maintainable.