Ruby IDE time

Today I’m getting some practice in with RubyMine - an IDE for Ruby & Rails development.

My initial reaction is it’s bit sluggish on a new-ish machine, especially in comparison to simpler, lightweight text-editors like Sublime Text. Plus there’s the inevitable pain of not knowing the keyboard shortcuts (well, CMD+S still works).

On the plus side I like what I’ve seen so far with test running, version control & terminal access all baked into the app.

The demo screenshots also promise some fancy file difference comparison views and model dependency diagrams. Swish.

Checking out Backbone.js

For my final WDI project I made a cheat sheet editor, using Ember.js for the editor itself. The original intention was to use Ember across the entire site. I was using the Ember data DS.RESTAdapter to sync with my Rails app but ran into trouble trying to adjust the API endpoint for particular queries… cue the pain.

Reading through the RESTAdapter documentation was fruitless - it appears this use case isn’t covered yet (to be fair, the RESTAdapter is currently described as alpha-quality on GitHub). I was faced with writing a custom adapter, but felt too short on time to embark on a rewrite of the rest of the project.

<grumble data-about=’ember’>

Here lies my grumble with Ember. There’s too much magic and there are lot’s of features still under development. Behind the magic lies a world of pain as soon as you need to alter something - if you’re still learning the ropes of Ember.

Ember’s magic lets you skip learning to crawl and walk in the world of JavaScript MV*, graduating straight to running instead. But as a beginner, still on the steepest part of Ember’s lengthy learning curve, you can stray from the well trodden tutorial-ed path and become very lost.

I have learnt more about Ember during the project, but I want to investigate Backbone.js because it looks like you need to build more of your app from the ground up. The ground-up approach should make it less likely that you outcode your current understanding of the framework. 

At least you get to build the forest that you end up getting lost in and might recognise a few trees.

On to Backbone.js…

I’m working through Addy Osmani’s book on Developing Backbone.js Applications (it’s free to read online) so I’m looking forward to understanding how the frameworks differ.


CNAME record for an Amazon S3 bucket

To serve static assets for a project I setup a CNAME record pointing to an S3 bucket. After the changes propagated I kept on running into this error:

NoSuchBucket The specified bucket does not exist

NoSuchBucket error? Odd. The bucket was accessible directly at but didn’t work via subdomain I setup.

After Googling around is turns out the bucket name itself needs to match the URL that the content will be requested on:

So to serve assets from you’d need an S3 bucket with that name and then point the CNAME record to You’ll need to vary the endpoint depending the region of your S3 bucket.


24 hour Hackathon. Rules: Make a gem. The gem has to wrap a new API, combine existing gems for a couple of APIs or scrape a website.

I decided to make a gem leveraging the Twitter API and YouTube search API. Here’s what the gem does:

  • Searches for music-related tweets containing short URLs to music services
  • Determines the music track & artist with regexes
  • Finds the music video on YouTube based on the track & artist name

The gem’s main method returns an array of hashes containing the tweet text, twitter username, profile picture and the YouTube video id. I made use of the excellent Hashie gem to provide the output with pseudo-object functionality.

The final step was to implement the newly forged gem in a demo app.

The Result


Check out the demo app here - MmmTweeVee. It make take a moment to spin up if Heroku wound down the dyno.

Don’t slow me down

Because the API calls take a little while to run (5-10 seconds) I decided to make the index view a loading screen and load the tweet & video content with AJAX so the user isn’t left staring at a white page.

Here’s the loading screen:


I asked Jon about quicky & dirty caching options and discovered Rails action caching is pretty handy to speed up the experience with just 1 line of config in the controller (plays nice with Heroku too):

caches_action :content, expires_in: 3.minutes

This seems like a pretty decent stop gap for a demo app - if the content has been loaded recently subsequent views are noticeably faster.

WDI week 9: Ember.js

Week 9 has been back to full-on lessons (after the group projects last week) with a focus on Ember.js, plus a sprinkling of how to create Ruby gems.


I’ve been itching to learn a front-end MVC-esque framework like Backbone or Angular for while. Why? Because I want to make snappy web apps (see Performance is a Feature on Coding Horror).

Although I hadn’t heard of Ember.js before I can see why it’s a logical choice to teach on WDI: The REST Adapter makes integration with a Rails app relatively straightforward.

Um, where?

I found the hardest part of getting started with Ember.js was building up a picture of what code goes where. There isn’t a 1-1 link to Rails concepts (such as the equivalent of routes.rb is simply edit X.js). It was never going to be that easy, right?

Fortunately I discovered a handy screencast on YouTube - Much Very Confused: Ember for the inappropriately experienced - that does a good job of linking Rails concepts with Ember concepts through each task you’re looking to achieve.

And then… a surprise.

On Wednesday it was announced we had a 24hr hackathon starting at 1pm Thursday. The challenge: Make a gem mashing-up a couple of APIs or scraping a website. Details to follow…