Blog Without An Important Name

After a hiatus of about a year, I finally made a new release of eMusic/J. This was mostly caused by the change in the file format that eMusic provides for downloading albums. This version is (internally) quite different to the old one, as it is set up to make it easy to produce customised versions, so that one set of source code can produce both the downloader for Naxos’ Classicsonline service, and the regular eMusic/J.

The most important change in this is that it now supports both .emx files, as well as .emp files. It also now requires Java 1.5 (this is less of an issue now that Java is going properly open source), and is available for five platforms: Linux i686, Linux x86_64, Linux PPC, Windows (32-bit) and Mac OSX (Intel and PPC, but in one package). There were also numerous bugs fixed, mostly thanks to Naxos’s QA people, but nothing earth-shattering.

I also had the lead developer behind eMusic’s new download manager get in touch with me, and he provided me with some information that made this easier than it would have been otherwise, which was good.

Anyway, the new version can be found at the usual location.

Just recently, eMusic updated their download manager to one based on XULRunner, to the outcries of many people on the forums. So I took the work I did for Naxos a while back, and built Windows and Mac OSX versions of my formerly-Linux-only eMusic/J download manager. I’ve had feedback on the Windows version saying that it’s working great for people, which is good. I don’t have a Windows or Mac machine to test either of them on, so I wasn’t terribly confident.

Anyway, they can be found here:

• Windows version
• Mac version

I’m in need of a bit of a holiday, so I’ve booked myself to head up north for a bit over a week.

I fly in to Auckland on Friday the 24th of August, on the 25th I’m going to see Psyche, and then on the 28th spend the day bussing down to Wellington. This will be a good chance to visit all the people in those cities I haven’t seen for ages, and raid the music and bookshops there. I’ll be there until the 3rd, whereupon I head back to Dunedin.

If anyone in these places wants to get together, let me know!

I currently am doing some spare-time work for Naxos (the music label), customising my Java-based, open-source eMusic.com downloader, eMusic/J, to work with their Classicsonline download service. This means taking what was a Linux-only application and making it work on Windows and Mac OS X also. Getting the Linux version was obviously easy, I’d already done that; making a Windows version took a little more time, but most of that was learning how to make EXE files and installers (I’m using Launch4j and NSIS for that). However, making it work on Mac OS X was quite a trial, because this platform decides to do some things totally differently to the others.

The fundamental issue was an incompatibility between SWT, the GUI toolkit I’m using, and the Apple event system. Basically, to make SWT work you need to pass a special option to the JVM: StartOnMainThread. However, as soon as you do this, you lose the ability to catch events for things like “someone double-clicked one of my documents”. So I had the option of having a broken GUI, or no events. Neither of which is a possibility, as opening a particular file is the major purpose of this program. My theorising about what the actual issue is is in this message.

However, Azureus manages to do this, so I knew it was possible. With some help from the Azureus devs on IRC, and staring at undocumented code, I finally have a solution which I’m putting here in the hope that other people don’t spend hours of fruitless searching like I did.

It is possible, with some JNI hooks into the Carbon layer of OS X, to catch the events there and have them passed through to the application. Basically, you include this JNI code, create some callbacks using SWT, sacrifice a chicken and bleed a goat, and all of a sudden your code gets called when someone opens one of your files.

The code that I use is here. If you look at one of the ...Mac.java files, you can see the open doc handler being loaded, and inside that (OpenDocHandler.java), at the bottom of the target object, you have the bit that sends the files to the rest of the program. I don’t understand most of what it does, but it works. If I get around to it, I plan to refactor this and create a fairly stand-alone bit of code that means you can just register your own callback, and get the events without having to modify the handler. That would be pretty easy to do, I just didn’t want to touch it once I got it working. This method can probably be adapted to handle the other events, but I don’t need them so I stripped those parts out. Have a look in OSXAccess.java in the Azureus 2 code if you want to know how to do that.

Once you have this, and someone double-clicks a document type you have registered, you get told about it. Conveniently, you also get an event when your application is opened because someone opened your document.

Note: most of the code there is GPLed as I ripped it from Azureus (and eMusic/J is GPL too), but I think the actual C bit is probably something more liberal, as it was done by IBM and I expect they intend for it to be under something like the Apache licence. But I don’t know for sure, as the original file doesn’t have licence details.

So, hopefully very soon, Classicsonline will have a cross-platform, open-source download manager for its users.

I’d ordered some stuff from the US late last week, and it arrived today (faster than some headphones ordered within NZ about the same time, that still haven’t arrived - Post Haste seems unable to deliver anything at all ever). Here is the hoodie:

and here is the t-shirt:

For the uninitiated, these are both references to H.P. Lovecraft’s story At the Mountains of Madness.

I recently saw mention that Google had released Guice, their internal dependency injection framework. As an experiment, I ported a few parts of the web application I’m working on for work to use it. I’ve never used dependency injection before, and so it was a chance to learn about it too. The executive summary is that it works great. Previously I had a giant factory class handling all the instantiation of singletons (mostly which handle talking to the database), so I would do stuff like:
Configuration.getObjectRegistry().getNoticeHandler()
This worked well enough, but all the static references made testing hard, I couldn’t substitute in my own fake classes at all.

Now, for the classes that I’ve ported to use Guice, in my test case I can create a module that makes it load a bunch of fake classes to simulate what the real ones would do, so I only need to test the one class that I’m looking at. It also means I don’t have to set up database entries for everything that might get touched. I just add a line to the module like:
bind(INoticeHandler.class).to(FakeNoticeHandler.class).in(Scopes.SINGLETON);

The only gotcha I had was that I couldn't get it to inject into the servlet objects automatically. This is because you have no control over their instantiation, the application server handles that all itself. The solution to this is for the class that catches the application loading to store the Injector instance in the ServletContext, and have each servlet object load that and inject the dependencies into itself on init:

@Override
public void init(ServletConfig config) throws ServletException {
	super.init(config);
	ServletContext context = config.getServletContext();
	Injector injector = (Injector) context.getAttribute("injector");
	if (injector == null) {
		throw new UnavailableException("The Guice injector could not be " +
				"found in the ServletContext. It is expected to be named " +
				"'injector'.");
	}
	injector.injectMembers(this);
}

if every servlet extends the abstract class that contains this (and this extends HttpServlet), then it all magically just works.

Over time I plan to port the rest of the application to use this, but probably just as I’m working on those classes. In the documentation it says:

Dependency injection is viral. If you’re refactoring an existing code base with a lot of static methods, you may start to feel like you’re pulling a never-ending thread. This is a Good Thing. It means dependency injection is making your code more flexible and testable.

This is definitely the case, it would be easy to start and just keep following the thread of dependencies until the whole thing was done. However, I’m avoiding that now just due to a) being scared to refactor the whole damn thing at once, and b) I should be spending time on bug fixing and critical features right now. But, it probably won’t be too long before the whole thing is done, as a side-effect of testing.

For a while now, it’s been the thing to have computers associate ads with the content of the page they show up in. What computers can’t do so well yet is determine if a particular association is in bad taste or not. This inability leads to things like this:

I now have the maximum possible number of assurance points for CACert, 150. This means two things. One is that I can now get SSL and email certificates that last two years, and the other is that I can now allocate points to others.

So if anyone who happens to be in the same place as me (generally Dunedin, but right now various bits of Australia) wants some, they should get in touch.

A nice side effect is that there is now enough people in Dunedin to get another person up to the required 100 points so they can then allocate them, so the region can now bootstrap itself fairly easily.

Today was apparently the hottest day Sydney has seen so far this summer. As someone who finds 25 degrees uncomfortably warm, the 35-40 degrees we had today was a bit much. It didn’t help that most of what I was doing involved walking from Pyrmont (where I am right now) to The Rocks, and back in the middle of the day.

However, it was good. I was meeting a couple of people from the conference for a final lunch thing at The Australian, where they have regional beers, and a range of pizza. As toppings, we had emu, crocodile, and kangaroo. Crocodile and kangaroo are really quite good it turns out. Emu is not very remarkable.

Later that evening I went for a BBQ, and had kangaroo meat then, too. It’s extremely good like that, and apparently cheaper than regular steak.

It just makes me wonder what kind of reaction you’d get if you were cooking kiwi on the BBQ. Quite different I’d expect

My NZ SIM card has failed, and due to some weirdness of Vodafone, I can’t access voicemail by calling the international number. So should you need to reach me, I can be found at +61415951810 until the end of January (when I return to New Zealand). Email should be pretty reliable too, if you don’t mind waiting a bit.

I’ll also try to update this with more descriptions of talks from the conference. Although, planning to do that didn’t really pan out for last year, so I’ll make no promises.

(Jono Bacon)

Jokosher is aimed at being an audio production tool for Gnome, to replace things like Cubase. Jono is of Lugradio fame, and spent some time complaining about the lack of good audio mixing and editing tools on Linux, so the community got Jokosher started.

It’s looking quite good, and hopefully a near final release is coming out around March. I liked the approach they took to developing the GUI, basically questioning everything, and so it results in a nice simple and sensible-looking application.

The talk consisted of Jono providing background to the project, covering the design decisions, such as why they use things like gstreamer, python, and so on, followed by a demo of it working (mostly, it was from head).

A good effect of this project is that it’s stress-testing the gstreamer framework, and apparently has resulted in a large number of bugs being removed and features added/polished. So this will mean that a lot of audio-related stuff will work better.