I built it using the latest and greatest version of Rails available at the time, which was 3.2. It has since fell to various security issues and has been superseded by newest version, and is currently unsupported.

I’ve been aware of these limitations and decided not to carry on hosting on such an old version, so I just stopped the nginx instance that was powering it and left it aside.

Until now! I had some time to spare recently, so I decided to upgrade.

Updating to Rails 3.2

The railsguide documentation about upgrading suggests not to update straight to the latest version of Rails, but to do it by steps instead. The first one for me was to update from 3.1 to 3.2.

First up, let’s update our Gemfile to pick up on the new Rails version, and let’s dive in!

The first issue I ran into was that the :timestamps model field definition are now marked as NON NULL. I wasn’t actively using these, so I decided to remove them from the DB rather than fixing DB import code.

My next issue was that some gems would not install properly – I decided to use the newest version of Ruby available on the system, 2.2, and it was not happy at my Gemfile requiring ruby-debug19. Fair enough, let’s remove it.

My next problem didn’t come from Rails itself, but rather from the gem I used to generate Google Maps, Gmaps4Rails. It underwent a serious rewrite in the past 4 years and now needed very different code under the hood – no problem. It also allowed me to clean some of the .coffee files and make better use of the assets pipeline.

An lo, the website was running under Rails 3.2!

Upgrading to Rails 4.0

The next step was to upgrade to Rails 4.0. This was very straightforward, a quick change in the Gemfile and a change to route handling (match was retired in favour of using the actual HTTP verbs of the route being handled, e.g. get) made it work, and a couple of new config options silenced the deprecation warnings.

Upgrading to Rails 4.2

And finally, the upgrade from Rails 4.0 to Rails 4.2 was made through the Gemfile only, no update was needed on the code itself.

And here we are! Antipodes is now up to date with its dependencies, and waiting for a new nginx+passenger to run again (more on that soon!).

Tunalysis is a small(ish) Ruby script that will read your iTunes library, crunch numbers, and gives you a few interesting facts about it, such as:

• Total number of songs
• Total number of playlists
• Average song length
• Average bitrate
• Average play count
• Average skip count
• Total time spent listening to music

Some of these statistics are already available in iTunes, but Tunalysis ultimate goal is to expand iTunes (limited) stats and to give you hindsight on your musical habits and tastes.

Tech

Tunalysis is written in Ruby and uses Bleything’s plist to parse iTunes’ XML library.

At the time being, Tunalysis only works on OS X. I’m not planning to do a Windows port, but will gladly accept a patch if you do. :)

Tunalysis is licensed under the GPLv3.

Features to come

• You don’t like that: suggest music to delete based on the skip count, the play count, and the last played date
• Preferred artists (by number of songs)

I’m open to suggestions. If you’re interested in a particular piece of data, leave a comment or send me an email and I’ll add it.

Get Tunalysis on GitHub!