Archive for December, 2005

Looking forward to Groovy growing up

Integrating Spring, Groovy and WebMacro into a new web application is proving a little more painful than I’d hoped.

The main problem seems to be Groovy’s current immaturity. It’s a moving target and while it is possible to use it fine for applications now, it takes so long to work out how things work because the documentation is rather sparse.

Let’s hope they get the JSR completed ASAP and get all the TCKs in place so we can really start shipping products that use it.

  • Twitter
  • Slashdot
  • Delicious
  • Evernote
  • Share/Bookmark

12

12 2005

Ouch, why so much CPU for iTunes widget?

I was looking through Activity Monitor, the Mac OSX performance monitoring tool. I noticed widgets taking up to 8% CPU, and that only one was actually doing so – the iTunes Widget?!

Yes, the innocent looking default widget was using 7-8% CPU on my 1.42GHz mac mini, without the dashboard even being visible.

A hunch tells me it is siphoning off audio data all the time for some graphic equalizer display or something.

Duh! Bye bye iTunes widget.

  • Twitter
  • Slashdot
  • Delicious
  • Evernote
  • Share/Bookmark

12

12 2005

Shock horror – appalling “feature” in Mac finder

Drag and drop is great. Drag a folder called X over onto another folder called X to add new files to the original X folder.

WRONG! Not in Mac OS X finder. It will remove the old folder completely first and then copy the new one there. Therefore if you have a folder containing some new files and an original with some old (not in the new folder) you lose the old files not present in the new folder.

This is truly appalling, especially as it simply warns that you will replace the folder – it doesn’t say "and this means you will lose the files not in the new folder". For people coming from Windows this is insanity.

Here’s some other people talking about it.
Bad, bad bad, Fix it Apple.

  • Twitter
  • Slashdot
  • Delicious
  • Evernote
  • Share/Bookmark

05

12 2005

Subversion redeemed slightly

The config is still way too complicated, but I have managed to get it working without user accounts.

It turns out CRAM-MD5 support works on MacOS X (10.4 Tiger at least) and therefore you can have per-repository user databases. You have to follow the the (pretty poor) instructions and edit svnserve.conf to setup a password database. The biggest mystery for me was that I did not notice any docs saying that this file is in the actual repository’s directory tree in the <repos>/conf directory.

So I have it working without shell accounts for each user, without Apache, with per-repository user access control, and
it is running on MacOS as under launchd so it starts on demand.

The problem is that creating new repositories is a royaly hassle that requires shell access to the box and some know-how. How can this be in this day and age?

  • Twitter
  • Slashdot
  • Delicious
  • Evernote
  • Share/Bookmark

05

12 2005

Subversion disappointment

I was hoping to start using Subversion for version control on a new project, and run the server on an Mac mini to boot.

I had always perhaps romantically thought that Subversion was a fantastic easy to use replacement for CVS. Having spent a little while trying to set up an SVN server and looking at the issues involved I’m very disappointed.

What is it with "unix" people? Why can’t they make something that you can just drop in and run and administer easily?!

My biggest complaints/surprises with SVN server setup include:

  • If you don’t want to run SVN behind Apache (what a load of config hassle that is just for an SCM system) you have to look at either creating user accounts for everybody who uses SVN and run the risk of problems with umask not being set right abnd some users writing files to the SVN repository that other users will not be able to read/write – or look at using the CRAM-MD5 system which does not allow per-repository or per-project permission control. Therefore its useless in anything but a single project SVN server instance. Running SVN so that it uses per-user shell accounts to write files is not a very attractive option.
  • There is no GUI for admin. No matter how "hardcore" you are at the shell or command line, these days you simply must have a GUI for administering tools like this. It’s painful and error prone without them. Of course a GUI is not really that easy given the mess that is the authentication / serving configuration permutations.

I really was hoping SVN would be great, and I am genuinely disappointed.

I was going to revert to using the very easy to use but somewhat buggy SourceJammer pure Java solution which has a pretty good GUI and just runs within Tomcat. I may still use it as there is little choice out there for free SCMs (and CVS is not an option!) but because SJ uses SOAP it tends to break clients/servers when you change versions and that causes a real nightmare for compatibility between people running different client versions. Oh, and no IntelliJ IDEA integration.

Hmmm, maybe I will have to go back to SVN with CRAM-MD5 now, if OSX supports CRAM-MD5.

In my opinion there’s still a lot of room in the free SCM marketplace for a really top-notch solution – i.e. the kind of quality Jira brings to web-based issue tracking. First class client UI apps for all platforms, deploy server and configure it via the web. That kind of thing.

  • Twitter
  • Slashdot
  • Delicious
  • Evernote
  • Share/Bookmark

05

12 2005