One of the things we say in our manifesto is that anyone could do what we are doing. This post (below the fold) describes the technical nuts and bolts of how this site works so you can maybe do the same. In particular it describes the genesis of the software that runs this site – Ribcage. We get a fair bit of e-mail about it, which I am always very pleased to answer.
Myself and The Fabulous Mr Eric Lee are going to host the first annual ROR hackathon in January – the intention being twofold. First to expand Ribcage beyond its current parameters – to interface with Last.fm and Musicbrainz properly, to add details of gigs for our various artists, to allow users to be informed of updates more easily. Secondly and more vitally, it is also to make Ribcage a WordPress plugin that anyone can install and use. The implication is, we hope, obvious: anyone who can run a blog will be able to run a download label. With the new WordPress 2.7 allowing plugins to be installed direct from the repository without messing around with FTP and the like, this means that you could go from a standard blog to a label blog in less than five minutes – imagine the possibilities!
Photo by flickring.
So without further ado, lets start at the beginning.
Specifications and Shopping Around
Over coffee sitting outside Aldo’s bar in Panicale, myself and Jell trashed out a list of stuff the site should definitely do or be.
- Be unbelievably clear and simple to use from users perspective
- Allow releases to be downloaded
- Allow releases to be streamed so people can have a listen, with a Flash MP3 player
- Allow decent levels of logging for these things so artists know if they are popular or what releases are liked more than others
- Embrace Bittorrent to save on server load
- Interoperate with big music databases online, for example Musicbrainz and Last.fm, be gently Web 2.0
- Allow the artists some easy way to get the files they wanted to release to us, without using the post
- So degree of automation in spitting out all the different type of music files we would like to be avaliable
- Be easy enough on the backend for almost anyone with basic net skills to use
- Obviously have profiles of the artists and details of their releases
- Open Source, standards competent – given the nature of the project
After a good Google around, there seemed to be no free tools for managing a website for a record label. Sneaking around the sites of other small labels I strongly suspected that most relied on custom made and proprietary scripts cranked out by the site designers, or just done with static pages.
This at first seemed an opportunity to hack together a full blown web application for record label and to open source it for anyone to use. Not wanting to start entirely from scratch, and given the recent explosion in popularity of such things, I considered doing the site in a web application framework with full MVC attempting to be as DRY as humanly possible. I settled on the name Ribcage, coz it works with Records On Ribs, innit.
My first port of call was the ever popular Ruby On Rails – which also has the initials RoR. Setting it up on my Mac was a huge chore and when I got down to developing it seemed quite clunky and difficult, but perhaps I didn’t ‘get it’ or even try hard enough. I know other people rave about it, but it just didn’t capture my imagination.
Then I tried the new kid on the block Django. Django is absolutely amazing. Once you SQL database is configured, it automatically creates an administration interface for you, with security and everything, saving acres of precious time. A few lines in a file could create a whole complicated XHTML view of the data. Hacking together the whole database backend adding bit took an hour or so, with familarisation chucked in. Developing for it had an elegance to it that was very attractive indeed.
Both, however, required me to master a whole new language (Ruby and Python respectively) and handle numerous learning curve head aches. I’d have to program simple things, like a custom bit of full blog software. Although drop-ins existed (for example Mephisto for Ruby On Rails, whipping up a blog in Django takes minutes), I didn’t like them, maybe in part because I plain didn’t understand them. I knew PHP and could probably have a bash at Perl, but I don’t have the soul of a programmer. So I wanted something fairly easy, and not something that was overkill for what was going to be a relatively simple site. A full-stack application framework was probably overkill.
I’d been using WordPress for ages to create various websites and blogs. It had a wonderful combination of simplicity and power. It also has a very helpful Plugin API, is extremely well documented and has a very friendly development mailing list. If I developed a plugin for WordPress I would have a very good blog backend interface that was well known and proven, as well as access to hundreds of other plugins and themes to customise almost every detail of the site to being precisely the way I wanted. It also allowed us to write copy elsewhere on another WordPress install and import it into the live blog.
In a wider picture, WordPress also had a significant advantage of being almost ubiquitous in the blog world. Any person with the skill to get through a WordPress install could just drop in our plugin and have themselves a fully functioning record label website, something which was highly attractive considering our manifesto commitments. A WordPress plugin seemed to be very much in keeping with the whole idea of what ROR was trying to do: it was DIY and could be passed on. It seemed like the perfect choice. Most people could not handle setting up a complex web application, and many ISPs don’t provide the ability to do so cheaply even if they could – most people could handle WordPress and a plugin with little hassle.
Developing Ribcage
During the development Ribcage I was very much influenced by the concepts of Agile Web Development and in particular 37Signal‘s book Getting Real. Ribcage needed to do what it needed to do well, not be over cluttered with pointless features or overcomplicated with confusing bits. All stages of the software cycle needed to be parallel. We needed to add little features here and there as needs be and have them live on the site within hours (or minutes). We needed to be super flexible, like the best Web 2.0 stuff.
For learning WordPress I learnt loads from simply reading the source code of other plugins and obviously from the WordPress Codex and hook/action reference found there.
To type the code I used Textmate and it’s project management features. I set up a little development environment on my Mac using the built in web server in Mac OS X and installs of PHP and MySQL that allowed me to test code before it went online. Version control and all that jazz is done with Subversion. It allowed me to collaborate with other people who have added bits and pieces when I have got stuck.
The advantage of Subversion is huge. Make a minor change to Ribcage and I can just use svn update in my Dreamhost shell to update the site: no buggering around with FTP or getting my mitts dirty. And with the amount of minor changes, as well as stupid mistake, I made, this saved a hell of a lot of time.
What Ribcage Does
Ribcage pretty much does all the things we set out for it to do. It allows downloads. It spits out streams and information left, right and centre. It has pretty much everything front-end we need, whereas the back end and portability are severely lacking. So here are the goals ticked off we met:
- Be unbelievably clear and simple to use from users perspective
- Allow releases to be downloaded
- Allow releases to be streamed so people can have a listen, with a Flash MP3 player
- Allow decent levels of logging for these things so artists know if they are popular or what releases are liked more than others The wonderful Mint provides high levels of information about our site visitors more generally.
- Embrace Bittorrent to save on server load – In the end this I thought was overkill.
- Inter-operate with big music databases online, for example Musicbrainz and Last.fm, be gently Web 2.0 – this is partially done, our January hacking will hopefully sort this out.
- Allow the artists some easy way to get the files they wanted to release to us, without using the post We did this in a slightly different way.
- So degree of automation in spitting out all the different type of music files we would like to be avaliable Ditto.
- Be easy enough on the backend for almost anyone with basic net skills to use The back end is fairly ropey but it works well enough. This will be improved in the push for a public version.
- Obviously have profiles of the artists and details of their releases
- Open Source, standards competent – given the nature of the project
Conclusion
I hope this short explanation might serve to give others ideas about how to develop your own small scale project as well as wheting your appetite for Ribcage’s forth-coming release.
