I made a bad assumption about how JPA (with Hibernate) works a while ago, that came back to bite me recently. For a long time, I’d assumed that if you have an @Column annotation with a name attribute, that name would always be the name that gets used to match the field to a DB column i.e. @Column(name="someName") would always resolve to the DB column “someName”.

I was very much mistaken in that assumption.

When using Hibernate (and possibly other JPA implementations, I’ll need to check), it turns out that name just replaces the field name as it goes through the normal renaming process. That is, the name is still subject to all of Hibernate’s naming strategy code.

By default, that means that when using the ImprovedNamingStrategy (as most people are), “someName” becomes “some_name”. This is definitely a more db-like name, but took me a little by surprise when I saw this happening in someone’s code.

The lesson: never assume anything.

A relatively light February, with only two movies.

The Fighter, in many ways, is a film you’ve seen before. It’s underdog story about a boxer who gets beaten and eventually, with the love of a good woman, finds his way to glory isn’t particularly novel or surprising. No, what makes it stand out is the quality of the performances from the entire cast. Christian Bale as the titular character’s drug addict brother/trainer is outstanding. Seeing through every twitch and failing, he really makes the character stand out without seeming ridiculous, fully deserving his Oscar. Both Amy Adams and Melissa Leo put in outstanding performances (the later also Oscar-winning), as they tear at what they feel is best for the lead. You’ve seen the story before, sure, but never quite this well done. Very worthwhile. (See my The Fighter Twitter review).

Meanwhile, Paul sees Simon Pegg and Nick Frost team up with a CG alien (Seth Rogen) for a fun, if gentle, Saturday afternoon comedy. There are a lot of nice little nods for the sci-fi geeks out there, and some funny moments, but we’re not talking about a classic here. It’s got a good feel, and you could certainly watch a lot worse, but not even the surprise cameos can turn around the fact that this is a little better than average. Fun, but not fantastic. (See my Paul Twitter review).

As I’m sure you’ve guessed, The Fighter is the film fight winner for February.

If you buy a drill, you can can do whatever you like with that drill. Well, not whatever you like: you can’t use that drill as a weapon against someone, or using it on objects that you don’t own. You’d be arrested, beaten or feel other negative effects from society.

What you can do, though, is take it apart to see how it works. You can look at how they managed to fit a powerful motor into such a small space. You can see how the batteries are arranged for charging and replace them with something that holds much more power. You can replace any part with a part of your own choosing; putting together a simple set of instructions to give your drill twice as much torque, for example. You’ll likely void your warranty (as is fair) but, in short, you own that drill and it’s yours to play with.

That’s why I find it pretty ridiculous that George Hotz is being sued for doing the same thing with his PlayStation 3. He decided that he wanted to be able to run whatever he wanted to do on his own device (a computer that he paid for, just like a standard desktop) and set about figuring out how to do that. That’s a perfectly reasonable thing to do. I know not many people have the time, inclination or ability to do so but, just like the drill, it should be entirely up to the owner of a piece of property to decide what modifications they want to make to it.

Sony decided, instead, to sue him.

You see, a side-effect of being able to run anything on your own computer (in this case the PS3) is that you can run pirated software, if you choose to. George did not choose to do this. He merely put the instructions out there about how to run your own software on your own computer. It was other people who then misused these instructions.

That’s right: he didn’t break the law himself, but his modification made it easier for others to do so. He didn’t incite them to do so, he didn’t suggest that they should, he merely produced that side-effect. This is akin to blaming the drill modifier for someone else using a modified drill in in an illegal manner: unless they said “go attack someone with this modified drill”, it’s really got nothing to do with them.

The saddest part of this is that it could all probably be avoided. Rather than get involved in the fool’s errand of securing hardware against personal use (the determined will always find a way), manufacturers could open up their platform’s for such use in a reasonably controlled manner.

Hardware hackers wouldn’t need to resort to cryptographic attacks with bad side-effects, if the platform owner let them play with it to their heart’s content. Sony actually did this for a while with the OtherOs feature but cut it in a firmware revision — which ultimately caused these issues.

This is important. Sony are essentially arguing that we cannot change the things we buy; that features that we pay for can be removed and we can’t reinstate them to one degree or another; that computing commodities are rented and not bought; and that changes others make and misuse could potentially be our fault. None of this has been true in the past, and we mustn’t let it be true in the future.

A free culture allows modification, remixing and derivation; particularly when we’re not infringing copyright. We should not lose sight of this as we enter an age of EULAs and commodities that we buy but, bizarrely, do not own.

People tend to build up systems for organising their data only after it’s really needed: we’ll gather related objects together haphazardly until it’s too late and we end up with a clutter. Nowhere is this seen more frequently than in people’s digital music collections.

Invariably, people just shove all of their music into a folder and hope for the best, neither organising or normalising the data. The result is that it’s difficult to find specific files, many files are missing vital metadata (like the artist name), and doing anything takes far longer than it should.

This need not be the case.

I’ve shown a few people who have been interested in organising their music collections the strategy I’ve built-up for keeping clutter free, and I’m going to share it with you. It’s not perfect, but it works well for me. (To be honest, I’m writing this so I can point anyone else who asks towards this guide.)

First of all, if all of your music is relatively popular and well known and you already use it as your main media player, just use iTunes. It has many shortcomings, but if you fit in that sweet spot then save yourself the hassle and just let iTunes take care of it all. That’s it, you lucky ones can go now. Lesson over.

Still here? Great. For anyone who has explored the world of music beyond iTunes, you’ll know that it won’t help fix your metadata or organise your music in a particularly useful way. My solution to that is built largely on top of the tools and music database provided by MusicBrainz, a collaborative way of discovering music metadata.

A little background: MusicBrainz aims to be the definitive reference source for online music. Over the last few years, volunteers have gathered a tonne of music metadata onto the MusicBrainz website and set about organising it. There are artists, releases, albums, singles, release groups, collaborations, and every piece of music information that you could need; all of it tagged with unique IDs. I say “every piece” but that’s overstating it. There will always be gaps in what MusicBrainz knows. The good news is that if you spot a missing release from your favourite artist, you can add it to MusicBrainz yourself and then everyone else gets to benefit from it.

Back to the task at hand. You’ll need to grab Picard, the MusicBrainz tagger, from their website. It’s available for Windows, OS X and Linux; and it’s ugly as sin on all of them. Seriously, it’s a terrible looking tool, but it’s very useful.

Once you’ve got Picard, the rest is easy:

1. Create a Music folder – This should be empty at first, and represents the golden copy of your data. Absolutely nothing gets in here that hasn’t been properly tagged and vetted. It can be anywhere you like, but keep in mind that you’re going to want to back this up on occasion so keep it somewhere that makes that easy.
2. Set-up Picard – In the Picard preferences, there is a setting for moving tagged files to a specific directory. Pick your new Music folder. You may also want to change the filename format and tweak some of the other settings, but I leave that up to you. Personally, I use “artist/release/artist – track title.mp3” for filenames.
3. Add music to Picard – There are a few ways of doing this, but you can drag and drop music directly into the left-hand panel, or use the add files/folders buttons. If you’ve added music from several albums at once, you probably also want to hit the “Cluster” button. This will attempt to organise the files into groups of untagged releases.
4. Search for a matching release – Select the music you want to tag first, and hit lookup. Musicbrainz will try to use the file’s existing metadata to find a release that matches.
5. Save your matches – If the release it finds looks correct, then save it. Your files will be tagged with all the extra metadata MusicBrainz knows about and an ID so you never have to match it up again, and moved to your Music folder. Once saved you can them remove the release from Picard altogether.
6. Scan your misses – If MusicBrainz either couldn’t find a match or the match it finds isn’t correct, you can use the “Scan” button to try a different approach. This uses audio fingerprinting (like Shazam) to try and automatically match the music using the audio itself.
7. Search Manually – Use Picard’s manual search to try and find the right release. If you find it, a “Tag” button will appear in the top-right of the release information. Click that, and the release gets imported into Picard so you can drag the music onto it yourself.
8. Do It Yourself – Still no luck? Well, it’s time to get acquainted with the MusicBrainz website to add the artist and/or release yourself. This is pretty straight forward but there’s plenty of information on how to contribute. If you think your files already have some of the data you need to add a release, there is a Picard plug-in for creating a release from a Cluster too.

That’s it. Every time you get new music, follow from step 3 and you’ll keep your golden copy in good shape.

As a bonus, if you ever decide to reorganise your Music directory, you can import your tagged music into Picard and it’ll recognise all it. You can then make whatever changes you want (maybe change the filename format) and re-save.

If you happen to be on OS X then the Max CD ripper can automatically tag your files as it rips, as it has Musicbrainz integration. You set it up in the same way as Picard and query MusicBrainz before ripping to pull back all of the metadata.

Hopefully, this will be of some help to someone in organising their music and understanding MusicBrainz.

After months of using JPA/Hibernate almost exclusively, I got caught out on a relatively simple bug when using JDBC more directly (well, via Spring’s JdbcTemplate):

public List<SomeObject> fetchSomeObjects(RecordType recordType) {
  Map<String,Object> params = ...//Map creation;
  params.put("recordType", recordType);
  return namedParameterJdbcTemplate.query("select * from someObject where recordType =  :recordType",
    params,
    someRowMapper);
}

That was from memory, so it may be a little off, but it should give you the basics of what the code was doing. It looks okay to my eyes, but, of course, it wasn’t. When run an exception was being thrown from the bowels of the JDBC code saying that RecordType couldn’t be converted to a JAVA_OBJECT.

Odd, I thought. It had worked perfectly well with an in-memory database (HSQL) but now wasn’t working when deployed on a hosted database (SQL server).

I couldn’t spot it straight away, so a quick debugging session revealed the problem: JDBC doesn’t play nicely with enums. RecordType, an enum, was being passed to JDBC verbatim without any attempt for it to match up with the recordType column (a varchar column); and that just doesn’t work. You need to explicitly convert from an enum to a String.

Thankfully, it was a one-line fix:

params.put("recordType", recordType.toString());

It doesn’t read quite as neatly but it works. The fact that the original version reads quite well (the value for “recordType” is called recordType) actually makes the bug harder to spot. Now, back to JPA.