ejdraper.com

Unboxing the HTC Hero, and a mini review

El Draper — Sat, 12 Sep 2009 23:58:58 GMT

This week I took delivery of my new phone, the HTC Hero. After getting bored and frustrated with the iPhone, both from a user perspective, and very much so from a developer perspective, I looked into the Android platform in greater detail. After playing around with the emulator and writing some code, I was sold. The HTC Hero is one of the newer Android devices on the market, and seemed to do everything I wanted and more, so I decided to switch.

Unboxing the device was a joy, as HTC have obviously decided to start paying attention to the Apple school of thought regarding packaging, and it was all very well done. The phone itself was well protected, and the accessories were well packaged too. In the box, besides the phone, you get a mini USB cable, a charger that uses the USB cable to connect from the plug to the phone, a 2GB mini SD memory card (the internal storage on the Hero is tiny, so this is welcome), a set of headphones, ear buds, and a mic clip, and quick start guide for getting up and running with the phone.

Getting the phone setup is a breeze - you simply need to remove the back, remove the battery so as to be able to insert your SIM card, and at the same time you’ll need to remove the protective plastic from around the battery. Insert the mini SD card, replace the battery, and replace the back cover of the phone. Then plug in to the charger and wait for it to charge up. Mine took around 90 minutes to reach full charge - I’m sure you can probably boot it up and play with it after a few minutes, but I like to give it one full uninterrupted charge to begin with.

Once the phone was charged, initially turning it on will run you through a setup wizard. As with all Android phones, it gives you the option of connecting it to your Google account for mail, calendar and contacts, which is brilliant - give it your credentials, and it’ll start syncing all of that stuff for you immediately, really handy. The Hero also gives you the option of syncing with Facebook, Twitter and Flickr for the various social networking apps and plugins that the phone has. The Facebook integration goes to a deep level, integrating with your address book of contacts, and might actually make Facebook more useful. Clicking a contact will let you see at a glance their details, text messages, e-mails, and if linked with a Facebook profile, their recent FB updates. The Twitter client is really good, and also has notifications so that you know when there are new tweets - it would be cool however to customize that to only notify for mentions, DMs, or perhaps specific searches. This device runs HTC’s Sense user interface over the top of the normal Android OS, meaning you get a very swish widget based UI, with seven different home screens to customize, for maximum personalization.

The onscreen keyboard is really intelligent, especially word lookups, giving you suggestions (but not forcing them on you), and allowing you to easily add new things to the dictionary for future reference. On the physical inputs, the trackball is really useful, as are the physical buttons on the phone - call, home, menu and end call buttons are complemented with a back button, and a shortcut button for searching.

As for the Android OS itself, it’s fantastic. So much more customizable and freeing than the iPhone, the possibilities are truly endless. The marketplace has a lot of applications and games on there already, with many more to come I’m sure as the potential audience increases. The very fact that you can have applications that run in the background opens up the possibilities on the device for all sorts of very cool ideas, and so it’s a very exciting development platform. Myself and my buddy Mike are working on a few different ideas, and the SDK is a joy to develop against.

While I’ve only had the phone for less than a week, I can already tell that it’s an incredibly useful and well thought out device. It’s a similar experience in a way to when I got my first iPhone, only this time around the potential seems that much greater, and that’s very exciting.

If anyone has any comments about the phone, or Android in general, feel free to shoot me a mail or leave a comment. You can see all the photos from the unboxing on Flickr.

Announcing Appsta

El Draper — Mon, 13 Jul 2009 01:00:09 GMT

I’ve just released a new gem called Appsta. Put simply, Appsta makes bootstrapping Rails applications much easier. But really it just builds upon an awesome new feature in Rails 2.3, templates. Templates are like build scripts for new applications - after the skeleton of the application is created, you can use a template to customize it to how you like it, removing unnecessary files, adding in libraries and gems you use regularly etc.

Appsta has two components - the helper library, and the command line tool. The helper library has a few simple commands that can help you when writing a template, by giving you functionality to setup your application on Heroku, creating your project repository on GitHub, and bundling up the creation of a local Git repository into a single command. This means that you can automatically provision source control and web hosting for your application as soon as the application is created, instantly giving you a stable and reliable platform for development.

The command line tool is basically a default Rails template that uses the commands in the helper library to setup your project on GitHub, and host your application on Heroku with two environments (production and staging). It also sets your application up with some default gems, and switches to using jQuery as the JavaScript library.

To install it, simply install the gem:

sudo gem install appsta

The idea is that some of you may like the Appsta defaults, and after installing the gem, will be able to simply run:

appsta <app_name>

to get up and running with your new application. However everyone seems to have their own preferences about frameworks and gems to use when building out a new application, and so more useful will probably be the helper library itself, allowing you to build out your own Rails template, but still make use of simple commands to setup your app on Heroku and GitHub. To do this, load Appsta in your Rails template:

require "appsta"
Appsta.load

and then make use of some of the commands

# sets up the local Git repository - initializing,
# adding all files, and making an initial commit
git_setup

# setup your application on Heroku as a
# production environment (http://app.heroku.com)
heroku
# setup your application on Heroku as a
# staging environment (http://app-staging.heroku.com)
heroku(:staging)

# setup your application on GitHub
github

The Heroku and GitHub commands ask the user for their credentials while running, and the commands themselves return useful information about the remote service so that if you want that can be captured and used later in your template (which is what Appsta does to produce the README file that is generated with a new application).

For more information on the usage of these commands, check out the default template bundled with Appsta. And if you have any questions or comments, please let me know! Likewise if you have improvements, please feel free to fork the project on GitHub, and let me know if you have a contribution you’d like me to look at rolling back into the main tree. This is just version 1.0, so there is plenty of additional functionality that could be built into this helper library.

Lastly, quick shout out to my boy Mike for writing a ton of code on the original version of Appsta before I rewrote the whole thing to take advantage more of Rails templates, and also for chatting over some of the ideas that you see in Appsta today.

RailsConf 2009

El Draper — Thu, 28 May 2009 22:27:25 GMT

Better late than never eh? Three weeks after the end of RailsConf, I thought I’d write a wrap-up post. Me and my wife turned the trip over to Vegas into a much needed holiday - we were out there four days before the conference began, and had a few more days left in Vegas after it ended too. Overall we had a great time, although I can’t say that it was a particularly relaxing break - Vegas tends to leave you more tired than when you arrived! In this post though I’ll focus on my thoughts of the conference itself.

Day 0: The Tutorials

I only attended the morning tutorial on the Monday sessions, as I was meeting with Mike in the afternoon. However, the jQuery on Rails session I attended in the morning was very good. It was a nice mix of things I knew (but good to run through again to reaffirm that knowledge), as well as some cool bits I hadn’t yet come across. It was very technical which was great, and while it was more of a jQuery focused session, rather than specific jQuery on Rails, that was fine by me as I was hoping for a real focus on the framework and it’s great features. This session didn’t disappoint, and Yehuda and Andy did very well given it was the first session, and there were a few technical challenges to overcome (namely, lack of power strips and issues with the wifi).

Day 1

Keynote: I enjoyed the keynote, but was also left a little disappointed by it in the end. It was well delivered, and had a good message, however some of the Rails 3 concepts touched on didn’t have very much detail with them (understandable, given the state of a lot of the Rails 3 features) - but in a few cases it may have been better to have left them out, rather than bringing them up and creating more questions than the keynote answered. Specifically, how some of the newer features would deal with legacy compatibility, and things like supporting HTML5 data attributes and how older browsers like IE6 might deal with that, or what could be done to support those browsers when they don’t support more modern features. I get that I could just stick with earlier versions of Rails, but it’d be a shame if the fancy new version (with plenty of other new features that would be useful regardless of which browsers you’re targeting) doesn’t work at all because of a few things that just won’t work on browsers older than three or four years old.

On the whole though, it was at least a thought provoking opening to the conference.

GitHub Panel: this session was excellent. The GitHub guys gave off a great vibe the entire time - it was fun, informative, and enjoyable. It’s obvious they are really doing something they enjoy, and they’ve built it all themselves from the ground up. Was great to see them answer a lot of questions about GitHub, and about starting up a business like GitHub; it was really very interesting.

Behind Call of Duty: World at War: this talk was a little disappointing. I expected a lot more technical detail, and was actually hoping for a focus on how they handled stuff like stats tracking, aggregating stats from millions of consoles into their community portal. Instead the talk seemed a little bit underwhelming.

Writing Modular Applications: I know this talk was a stand-in replacement at the last minute for something else, but it was an inspired choice. Fairly high level, but extremely thought provoking, it was a great 40 minutes. Jim himself said the title was a bit inaccurate, but it was interesting to see the topics he spoke about presented in the specific way he did - an almost out of context look at decoupling of code. Hard to explain, but it’s well worth trying to find video or slides for this one.

Smacking Git Around: I think on reflection, this was my favourite talk of the entire conference. Scott’s energy and enthusiasm for Git is incredible, and his talk was well delivered, had a decent dose of humour, but above all, was incredibly useful. I think it was actually about three or four hours worth of Git tips and tricks delivered in just 40 minutes, and it was brilliant. The slides are online, and for someone that’s got the Git basics down, but wants a run down of some of the more interesting tricks for Git, it’s very useful.

Scaling Rails: lastly on the first day, this talk from the guys at Phusion was a funny end to the day. A bit light on technical details, it was still entertaining, and it was a must see if only for the great demo of Rubystein 3D, a basic game they wrote in Ruby, borrowing heavily from Wolfenstein, and with a lot of “cameos” from members of the community. Funny stuff.

Day 2

Rails Metal, Rack and Sinatra: really interesting session from Adam Wiggins of Heroku, touching on a few of the more interesting aspects of Rack, and specifically what Rack allows us to do - from Rails Metal, through to the embedding of Sinatra apps within Rails apps. Very cool stuff, interesting from start to finish.

Rails 3: Step Off of the Golden Path: another interesting one, delving into some of the Rails 3 stuff in more detail than the keynote did. It’s still a little tricky to get into too much detail simply because so much stuff within Rails 3 is open to change, or not yet finished, but Matt did a good job here of bringing together some of the more interesting bits, specifically in and around the options you will have for alternatives to the norm when building a Rails app (testing, JavaScript libraries etc) and how Rails 3 makes using these alternatives easier.

What Makes Ruby Go: An Implementation Primer: this I think was my second favourite talk after the Git one - two guys who really know the topic (Charles Nutter and Evan Phoenix, who work on JRuby and Rubinius respectively) chatting over some technical Ruby stuff, including specific sneaky performance issues. Very interesting, shame it was only 50 minutes really.

Heroku Q&A: I was interested in Heroku already before this talk, so was pleased to get the opportunity to watch the guys behind it demo the service, and take questions. They started with the basics, getting started with Heroku and hosting basic apps, before answering some questions on more advanced stuff and demoing a few other bits. Was good to watch to get a better idea of how Heroku works, and how to use it.

Day 3

Building A Video Portal In Rails: this was a solid talk, if a little disappointing. I expected a talk on the more interesting technical challenges facing a video portal, specifically transcoding. Unfortunately, the particular solution being presented outsourced the video storage, transcoding and distribution to a third party platform, meaning that the talk was relegated to simply speaking about the integration. I was definitely hoping for more information on the technical side of running a site like that.

Skipped the next session and instead me and Mike went to LarkConf. To quote the always awesome Jon Larkowski who arranged it, LarkConf is “the premiere ad hoc coffee shop networking un-conference opportunity”. And it was awesome. Was cool to meet Jon, as well as a couple of the guys behind Exceptional, and the owner/founder of CafeCourses. Great stuff, and the most fun I had networking all week.

Russian Doll Pattern: Mountable Apps in Rails 3: this talk was a little underwhelming. Like the opening keynote, it left me with more questions than it answered, and while it went into a lot more detail than the keynote did, there was definitely some mixed messages coming across. It was unfortunate, but Drupal was mentioned rather a lot, and I think that confused a lot of the participants - it wasn’t entirely clear on the purpose of mountable apps, and it probably would have been better to make clear the relation this work obviously has to merb-slices. However, there were still some interesting tidbits of information in the talk, and it was obvious a lot of the confusion was down to most of these things still being up in the air, as Rails 3 is still a long way away.

Closing Keynote: This was a Q&A session with some of the Rails Core guys, and ranged from being interesting, to a little bit boring. It was a good way to end the conference, but obviously the content relied entirely on the quality of the questions. There was some great questions (things like the process for having patches dealt with by the Core team, with Koz pointing out that they are humans too, and sometimes make mistakes), to more boring questions. There was also the odd funny one (such as Obie asking “are you guys letting Yehuda turn Rails 3 into Drupal?”, which coming right after the Russian Doll talk, was forefront on a lot of peoples minds still). Overall, there were some interesting things to take away from the session, and it was a solid way to finish up.

Overall

On the whole, I immensely enjoyed RailsConf 2009. It was my first conference, and it was a good mixture of some fun networking, good sessions, and thanks to the location, made for a great break away too. My only real complaints about the conference itself is that there were a few weak sessions in there, and I definitely would have liked to have seen more technical content. While I understand that given the timeslots, there isn’t always time to do too much low level content, I do wonder whether a separate track on a slightly different schedule (one session to every two on other tracks, for example) could have held some more engaging talks on lower level ideas and concepts. Kind of a mix between the 40 minute talks, and the tutorial sessions held on the Monday. However, the Git talk and the Ruby implementation session were absolutely brilliant, and contained a great deal of useful information and content, packed into one session.

I’ll be interested to see where RailsConf takes place next year, but either way I definitely enjoyed the conference atmosphere, and meeting people, and will be thinking of attending a few other upcoming conferences, especially ones that have a more technical focus.

Freebird

El Draper — Sat, 11 Apr 2009 14:11:51 GMT

I meant to write this article four weeks ago, as I had just finished in my full time position with Touch Local, and was about to start working freelance full-time. Since then, my freelance work has kept me plenty busy, and I never got chance to write this post. So today I figured I’d take some time out to write it, with the added bonus that I now have a month worth of working for myself to reflect upon.

The last month has been incredibly exciting. I’ve updated this site to make it more professional, and to give potential clients more information about me and what it is I do. I’ve had a lot of work on which has been great, but I’ve also had a lot of business admin to do, which has taken some getting used to. Working on business accounts, raising invoices, writing proposals and contracts has all taken some time, but I’ve now got everything setup in a way which makes admin tasks a lot quicker. I’m going to write in more detail soon about the tools that can help freelancers with a lot of day to day tasks.

Not having to commute has definitely had a positive impact, and I get that time back now to put back into working, or into relaxing. Being more flexible is also great - I work in the evenings and the weekends, but can take time out in the week, or have the occasional late rise. Sometimes it can be hard to switch off from the work that needs doing, but at least in that regard I really enjoy what I do, so it isn’t so bad.

And that’s really what makes working for myself as a freelancer and running my own business so enjoyable. I’m working on things that I enjoy doing, from home, working hours that suit me. I also have the time to work on some of my own ideas now too, which is very exciting indeed.

So if anyone reading this needs Ruby on Rails development doing, please get in touch. You can also browse the rest of this site to find out more about me, and what it is I offer. And if anyone else reading this is considering becoming a freelancer, then don’t hesitate to drop me a line if you’d like to hear more about my experiences so far!

Foot Locker Unlocked

El Draper — Tue, 24 Feb 2009 22:16:18 GMT

So me and my buddy Mike have recently put together and launched a new site, Foot Locker Unlocked. This was a rewrite and redesign of an existing version of the site in Ruby on Rails. It’s main focus is the sneaker gallery, where you can read about all sorts of different sneakers, as well as see some great images of them, and rate them. It has a fair few social features, with more to follow. The site also integrates nicely with the similarly redesigned Wordpress blog. It was good fun putting it together, and there are more features and improvements planned for the future which is very exciting.

Setup Feather to run as a slice within a Merb app

El Draper — Fri, 30 Jan 2009 01:47:37 GMT

In response to a few queries and comments on my post about the ejdraper.com blog running as a Feather slice underneath a parent Merb application, I decided to put together a sample app demonstrating just how you’d configure such a beast.

Introducing Feather Sample Slice Host… this is an up-to-date Merb application (Merb 1.0.8.1) that hosts Feather as a slice. It comes with a few common plugins installed, and an ultra basic theme override to demonstrate the themes working. It shows how you can easily integrate Feather into a Merb application, and you should be able to use it as a base for any application that you’d like to build with Feather integrated. You need to install Feather as a gem first - for now, simply “git clone” the Feather code, and then run “sudo rake install” in the root of the Feather codebase. A configured development sqlite3 database is included with the sample app so that you should then just be able to “git clone” the host app code and fire it up!

For those that are interested, integrating Feather as a slice boils down to the following steps:

if you haven’t already, grab Feather as a gem (same as above, clone the code, and then “sudo rake install” in the project root; this will change when the first gem version of Feather, 0.5, is officially released shortly)
create a brand new Merb app
add Feather, and a few of it’s dependencies to “config/dependencies.rb”
add the appropriate Feather slice commands to the host apps router, to mount Feather at /blog (or wherever you would like)
run “rake slices:feather:install” and “rake slices:merb-auth-slice-password:install” from the root of the host app to copy static resources over
setup the database, using the “Feather::Database.initial_setup” method from the Merb console (“merb -i”)
implement a login form under the “app/views/exceptions/unauthenticated.html.erb” view
install any plugins required
setup any themes needed (if using the themes plugin)
implement the rest of the functionality you want in your host application!

For any of the steps above that aren’t all too clear, you should be able to refer to the sample application now to see exactly what is required. It isn’t currently as straightforward as I’d like, and as a part of the aforementioned 0.5 gem release, I’d like to provide an easy command to add Feather to a Merb application, or create a new Merb host app with Feather already installed as a slice. For now though, the above checklist alongside the sample app should have most of you up and running in no time!

As always, any questions, please feel free to contact me or leave a comment.

ReCover

El Draper — Sun, 18 Jan 2009 14:43:28 GMT

I’ve just pushed out the second version of Cover-Up, and so it should be available via gem within a few hours.

Version 0.2 includes the following:

fixed a couple of bugs
added the option to provide your own logger to the code coverage run (see README)
few improvements to try and speed the code coverage execution up a bit

The speed improvements will be fairly useful as the initial version was a bit sluggish, although I still have more work I’d like to do in this area to try and speed up the code coverage even further.

The logger is useful for those that want to run their own traces over the code during the code coverage run, or simply for tracking down a problem that isn’t obvious in the results that Cover-Up returns already. Obviously any code you add in as a logger will potentially slow the code coverage run down further though.

So if anyone is interested, please take a look, and any questions, comments, or suggestions, please let me know! It’s still a work in progress but it is getting better all the time!

Cover-Up

El Draper — Wed, 14 Jan 2009 00:16:27 GMT

I started writing a new tool on Monday, a flexible, dynamic code coverage gem written in Ruby, for Ruby code. rcov is useful, but I needed the ability to easily wrap any Ruby code in coverage, dynamically at runtime, and I wanted more flexibility in the results that come back. There are probably ways to achieve both of these with rcov given the right options, but I wanted something that offered this out of the box, in an easy to use manner. I also thought it’d be fun to write something that’d work out the coverage of any Ruby code you give it.

Introducing… Cover-Up! Hosted over at GitHub It’s a really straightforward code coverage tool, and once installed, you simply need to do the following:

# load the gem
gem "cover-up"
require "cover-up"

# initiate the coverage, specifying a pattern for the files to be covered
results = coverage(:include => "app/*/**.rb") do
    # execute the code to be covered
    run_my_tests
end

results # this will contain the code coverage results

In the above example, the coverage would execute the “run_my_tests” method, and would match the code executed against the files specified with the input pattern, in this case, any Ruby files within a subfolder of “app”. It would then produce the statistics to say how many of the lines within those files were hit, how many weren’t, and how many were excluded (such as comments and whitespace etc).

All of those statistics are within the results object that comes back, and can be accessed as a whole, or on a file-by-file basis. This makes it really easy not just to run coverage over tests, but over other ad-hoc Ruby code too, to see what code is being executed by a given action. It also makes it really easy to hook up to your app, and to format the results however you want.

It’s only a couple of days old at the minute, and so is unlikely to be perfect - but I think it’s a good start, and even has tests of it’s own, so feel free to grab the gem which should be available depending upon the gem server mirrors over the next few hours:

sudo gem install cover-up

Or grab it from GitHub. Feel free to fork and improve the source too, patches very much welcome! I’m going to keep improving it over the coming days, so keep an eye on the code!

Reboot

El Draper — Sat, 10 Jan 2009 21:46:58 GMT

I’ve designed and built a brand new personal site here at ejdraper.com, and have moved over this blog - all url’s from crazycool.co.uk now point to ejdraper.com/blog, and the blog integrates with the rest of my personal site, which also includes a bit about me, my portfolio of work, my code and a lifestream on the homepage aggregating content from this blog, GitHub, Flickr, Delicious and Twitter.

As part of the migration I’ve created a new feed with FeedBurner, at http://feeds.feedburner.com/ejdraper. I’ve left the old crazycool feed running too though, and pointed it at the new site, so those of you subscribed should continue to receive the latest articles, but if you get chance it may be worth switching your subscriptions to the new feed to ensure that it always works in future.

For those interested, this new site runs on Merb, and is hosted using Apache and Passenger. The blog portion still runs on Feather, however it runs as a slice inside the main ejdraper.com app. I’ve spent a fair bit of time recently on bringing the Feather codebase up to speed to make it work with the latest Merb/DM, to finish up slices support, fix some of the bigger bugs, and to make it more stable and reliable. Soon enough I’ll be wrapping up the latest code into a 0.5 gem release, so watch this space!

Any comments on the new site and design will be welcome, and I’m going to be more blogging a lot more regularly from here on out!

Can you hear me now?

El Draper — Wed, 29 Oct 2008 00:50:18 GMT

So this blog has been a little bit up and down recently, partly because the Feather installation is overdue an update, and partly because the server could do with being rebuilt, but I figured that rather than me finding out the site has been down for a day and then manually booting it, there must be an automated way of picking up these issues and restarting the site. Sure enough, there is!

God is a great gem that allows Ruby scripts to be written to describe the configuration, settings and scenarios required for monitoring a particular process, and to outline the steps to take when certain conditions are met. I was able to knock up a script to reboot the app server for this blog whenever it doesn’t get a 200 response back from the main index, and I think that’ll do the trick nicely!

So if you see this blog is down, just give it a minute or so - God is on the case and will fix the issue shortly :-) Thanks Mojombo!

Rename

El Draper — Thu, 23 Oct 2008 22:53:58 GMT

So I’ve decided to rename my GitHub account, from http://github.com/eldiablo to http://github.com/edraper. If you’re using or working against feather-plugins or merb-manage then you’ll need to reset your remote location for doing a git pull or whatever. Not sure if you’ve forked whether that’ll continue to work, probably best to check and rebase against the repo at the new url. Any questions let me know and I’ll try to help you out if it’s screwed something up.

And just for fun, here is a video of me scoring a great free kick with the brilliant Jimmy Bullard for Fulham against Arsenal.

Ready to Rumble

El Draper — Mon, 20 Oct 2008 01:19:48 GMT

Wow, so what a 48 hours it was doing the Rails Rumble! Really great to get something up and running in two days. Me and my boy Mike really got it hooked up and came up with something pretty cool we think.

Likis is a language wiki designed to encourage collaboration and contribution to build an extensive language resource, to help people learn languages. It allows wiki-style editing of language pages, phrases and words, and it also includes audio pronunciations, so you can upload a recording of a specific foreign language word or phrase to help others!

Check it out, and let us know what you think! Now I need to get some sleep…

Advent 4211 Netbook

El Draper — Wed, 30 Jul 2008 21:41:31 GMT

Yesterday I picked up an Advent 4211 netbook. It’s exactly the same hardware as the MSI Wind, only it’s a re-branded, cheaper version. It’s a really cool piece of kit, and I thought I’d stick some unboxing pics up for all to see. You can check them out on Flickr here.

So I’m waiting on a few other bits to arrive (another stick of RAM, a replacement wifi card, and an external DVD reader), and then this weekend I’m going to attempt to switch out Windows XP on this bad boy and replace it with Mac OS X (using this guide). That’ll make it a really cheap, ultra portable Macbook, for coding on the go. Awesome!

Lesser Known Classics #2: Queens of the Stone Age - Songs for the Deaf

El Draper — Sat, 26 Jul 2008 14:39:31 GMT

This is the second post in my series on classic albums that perhaps don’t get the recognition they deserve. The first in the series was about Rufio’s masterpiece, MCMLXXXV.

This post is about the Queens of the Stone Age album, Songs for the Deaf. Now it’d be hard to argue that QotSA are “lesser known” – they are a huge, well recognized band within the rock world, and have been making great music for a little over ten years now. Songs for the Deaf itself got critical and commercial acclaim, and achieved gold status. However, it seems that truly classic albums rarely leave the rock and roll consciousness, and are used as a milestone to compare other albums too – and Songs for the Deaf, unfortunately, doesn’t appear to be held in that regard. I think it should be.

Unlike the Rufio album in the first post I made, I can’t honestly say I think each and every song on the album is a winner – the difference here is that there are a number of mind blowingly brilliant songs that just makes the entire album a classic, and all of the songs seamlessly flow into each other, making the whole thing an audio experience to behold.

The superb opening song (“You Think I Aint Worth A Dollar But I Feel Like A MIllionaire”) sets up the entire record. Beginning with sound effects of someone entering a car, and continuing with the car radio DJ introducing the album – “I need a saga – what’s the saga? It’s Songs for the Deaf. You can’t even hear it”. The album is indeed an epic saga, and “Songs for the Deaf” alludes to QotSA’s comical, zany nature that shows throughout all of their work.

Of course, this album is special as Dave Grohl did the guest drums, and immediately after the DJ introduction, a heavy drum beat sets up a hard rocking opening song that really buzzes. With a great rhythm, the song just feels right. The guitar work on this track is brilliant too, and it’s one of those songs that you can imagine must be an absolute riot to play live on stage.

Immediately following this breathtaking opening is the first single from the album, “No One Knows”. Again with a great drum beat laid down by the mastermind Mr Grohl, it’s very catchy, and very cool. Not too heavy, but it was a great vehicle for the album, and the kind of song that gets stuck in your head for days at a time. Another single, “First It Giveth” follows, a lot heavier than “No One Knows”, and while not as catchy, it’s another winner. More big drums, and this time with a more impressive bass line – it also incorporates acoustic elements for the bridges in the song, which gives the song a stop-start melody that’s more than a little interesting.

“A Song For The Dead” follows that track, and again revolves around an incredible drum beat, and some brilliant guitar work. While a lot of the tracks on this album follow the same pattern (and why not, when you have Josh Homme on the axe, and Dave Grohl on drums?), it never seems to be overly repetitive. This song builds up and builds up as it progresses, and reaches epic proportions towards the end of the fifth minute, as it slides into an epic guitar frenzy with the same guitar and drum melody that opened the track, this time on steroids. By the time the song is done (it’s almost six minutes long), you feel drained.

What follows almost feels like a bit of a rest and relaxation period for the album, after the frenetic opening. It’s not that the following songs are bad, they just simply couldn’t keep up with the album’s first four tracks. Luckily though, the album again switches it up a notch when we get to the best track on the album (and one of my favourite songs of all time) – “Go With The Flow”. Contrary to some of the other, mammoth tracks on the record, this weighs in at just over three minutes. However this is perhaps the only area that the track comes up short, as it delivers in every other department. Once again tying musical mischief together are the guitar and drums, setting the stage for a fairly heavy track, but one that still feels melodic. “I can go, with the flow” sings Homme, and it’s obvious by this point that he’s right. The entire album is about flow, and about the songs tying together to form something that is bigger than the sum of its parts. It is in fact this song that seems to define the album for me, being a reference point for all of the brilliant aspects that it incorporates. Special mention must also be made for the amazing video that was put out for this video as this song too was a single. The video is a dark, comic-like affair, that seems to take place on a hellish highway. It’s not particularly subtle in the end, but the video and song work together better than any I’ve ever seen.

It’s true that the rest of the album doesn’t feel as good from here on out – but I think that is almost certainly down to the quality of the songs that precede the final ones, the ending songs themselves are easy to listen to and do a great job of supporting the real star tracks on this record. It’s worth mentioning the closing “Mosquito Song” though, which is a fantastic way to end the record, favouring a slower, quieter acoustic sound over the heavy drums and guitar that laid to waste the first 50 minutes. It puts the excesses in perspective, and frames the entire album as a classic.

So what makes this a classic? It just seems to have it all – it sounds great, it feels great, and it has lasted the test of time – this album is now six years old, and still seems as fresh as the day I first popped it into my CD player. That surely is the true test of a classic – does it still sound as great as day one? The answer here is yes.

So what of QotSA now? They’ve had some interesting stuff happen over the last few years, with band members coming and going – but Josh Homme is still at the helm, and while the follow-up to “Songs for the Deaf”, “Lullabies to Paralyze” wasn’t up to the same standard, the more recent effort, “Era Vulgaris” comes a lot closer. It is unlikely to be a classic, but includes some really brilliant tracks, such as the first single “Sick Sick Sick”, and “3’s and 7’s”. I guess it’s a shame sometimes for a band to have such an amazing album as “Songs for the Deaf” in the middle of their career – it must make going back to the studio afterwards incredibly difficult.

If you don’t have “Songs for the Deaf”, pick it up immediately.

What's up Proc?

El Draper — Sun, 06 Jul 2008 17:48:33 GMT

So it’s awesome Ruby snippet time, and in particular I’m going to look at the ability to evaluate statements against a block, specifically to find out where the particular block came from.

The “eval” command not only takes in the command to be executed, but can also optionally take in a binding to run against. This means that instead of evaluating a command against the current, local binding, a specific binding can be used, and for our example, we are going to use the binding on a Proc object, to allow us to evaluate a statement as if it was running within the block itself.

Let’s setup a module that allows us simply to register a block to an array:


module TestApp
  class << self
    # Adds a block to our global array
    def add_block(&block)
      @@blocks ||= []
      @@blocks << block
    end

    # This just returns our block array so we can iterate through it
    def blocks
      @@blocks
    end
  end
end

Within this same file (let’s call it test1.rb), we can also register a test block. The execution of the block isn’t really important, so let’s just do:


TestApp::add_block { puts "test1" }

Now let’s setup a second script (called test2.rb) that’ll also register a block, and that will iterate through the blocks and use the “eval” command to show where each block originated from:


# Reference our first script
require File.join(File.dirname(__FILE__), "test1")

# Add a second block
TestApp::add_block { puts "test2" }

# For each block we have, run a statement that will return the "__FILE__"
# variable for each block, against the blocks own binding
TestApp::blocks.each do |blk|
  puts "Block from: #{eval('__FILE__', blk.binding)}" 
end

If we run the test2.rb script now, we should see output similar to the following:


Block from: ./test1.rb
Block from: test2.rb

So we can now differentiate between our blocks, by investigating the blocks own binding! Something to bear in mind is that obviously the paths shown are relative – if you were executing the test2.rb script using an absolute path (for example, “ruby /path/to/test2.rb”), you’d see that the absolute paths were shown instead. Either way, the information should be useful in determining the origin of a block.

Now you may be asking, what’s the use case for something like this? Our block registration code above does nothing useful, and in fact we don’t even execute the blocks themselves! Well, within Feather we use this code to find out which plugin registered a particular block – in this way, we can check at runtime (before executing the registered block) whether the plugin is active or not. If it isn’t, it won’t be executed, if it is, it will.

This is just one of those cool things you can do when you have a reference to a specific binding – there’d be nothing to stop you from interacting with the blocks bindings in other ways too.