But first a quick recap of the idea for those in the dark:

To answer the question “what do you listen to?” I created an app that analyses your recent listening history and awards Artist, Genre, Guilty Pleasure and Hipster badges based on certain criteria.

With that out of the way…

The Tech
While the idea itself is hardly revolutionary, and the website itself is not quite all there (it would have looked a lot less pretty if Ben hadn’t made those beautiful badges for me. Thanks again, Ben!), I tried something new on the back-end. The application is built in Rails, and contains 2 models – the User model and the Badge model – which run to 18 and 5 lines respectively. As I haven’t hooked up all the moving parts (you’ll notice I triggered everything from the command line in my presentation), there are no real controllers. The traditional Rails code is so minimal because I made a real effort to pull “business logic” out into lib classes. This is the first time that I’ve really tried to do this, and I really tried to push the concept as far as I could. My ./lib folder looks something like this:


lib
…
├── badge_calculator.rb
├── echonest.rb
├── emo_badge.rb
├── fan_badge.rb
├── fetcher.rb
├── genre_badge.rb
├── guilty_pleasure.rb
├── hipster_badge.rb
├── listens.rb
…


I’ve omitted standard Rails boilerplate stuff, but you can see that there is a lot of logic in here. `badge_calculator.rb` kicks off the calculation process, and calls the calculate method defined in the classes of each badge, each of which is held in the appropriately named file. `fetcher.rb` does the fetching of the Last.fm data and Listens is a class that allows me to load that data in a nice Ruby format.

The result is highly modular code that was easy to test. I still need to push it further – all the badges should inherit from some kind of base badge class, and each badge duplicates pretty much the same awarding logic, which should be pulled out into a new class.

All in all I learned a hell of a lot in how to design a system like this. I’m sure it won’t be suitable in every situation, but it’s certainly something I will be doing more of in my work at Mint.

I also created a small Ruby gem to wrap the Gracenote Web API. It only does what I need it to right now, but I’ve stuck it up on GitHub so if you want to extend it, please do!

What next?
I still plan to work on this, make those changes mentioned above and hook everything up. When that’s done, I’ll push the app live and you can give it a go. I’m really interested in trying out the Facebook listens stuff too.

I’d love to hear any feedback. Do you love it? Hate it? Have an idea for a badge? Let me know.

Thanks again to Martyn Davies, the MIDEM crew, SoundCloud all the participants and anyone that asked us questions, stopped by to say hello, or were confused about what the hell we were doing. You all made it a really, really great event!

Getting started:
The first thing to do was to get `rails new` to generate a new app. After a little googling, it seems like the easiest way to do this is as follows:

* git clone git://github.com/rails/rails.git
* cd rails
* bundle install
* railties/bin/rails new ../path/to/your_new_app –dev

So essentially, we get the latest in the rails repo, install its dependencies, and then run `rails new` from the binary in the repo. It’s important we pass the `–dev` flag so as to get the Gemfile pointing some Rails’ dependencies at you local copy of Rails. More info on this can be found in this ticket.

Routing concerns:
This is cool. While I didn’t really need to use it for what I was doing I figured little could go wrong with gratuitous use of beta features, so I went right ahead. Essentially, we are able to define a resource that can then become a “concern” of another resource. Something like this:

concern :hookable do
resources :hooks
end
resources :app, concerns: :hookable


Running `rake routes` shows us something like what can be seen in this gist (damn you wordpress.com): https://gist.github.com/3886049

As you can see, adding the “concern” to another resource, adding hookable to app in this case, creates all the correct routes for the nested resource. Any resource can be “hookable”! The routing concerns Readme uses the example of adding comments to a few different resources. I’m sure you can see how this coud be really useful in keeping your routes sane in certain situations.

Turbolinks:
Turbolinks are an extension of the same idea as pjax, but this time applied to the whole page. When following a link, rails will update the body tag of the current page with the HTML for the new page, leaving everything else intact in an effort to reduce page load times. Turbolinks are enabled by default, and I did notice them doing their thing while developing my app. I don’t really have much to say on them right now. I think they made the page load feel snappier, but with such a basic page it’s hard to say. I didn’t do any benchmarking, and I’d imagine the performance benefits will vary depending on your situation.

Testing:
I found this interesting. Gone are unit tests. Gone are functional tests. These have been replaced by model and controller tests. I think that makes much more sense.

Our new test directory looks a little like this after generating a couple of resources:

test/
├── controllers
│ ├── apps_controller_test.rb
│ └── hooks_controller_test.rb
├── fixtures
│ ├── apps.yml
│ └── hooks.yml
├── helpers
│ ├── apps_helper_test.rb
│ └── hooks_helper_test.rb
├── integration
├── mailers
├── models
│ ├── app_test.rb
│ └── hook_test.rb
├── performance
│ └── browsing_test.rb
└── test_helper.rb

Strong Parameters / Mass-assignment
Previously, there have been a number of ways to deal with mass-assignment. Rails 4 standardises this (rightly or wrongly) with Strong Parameters, which has been merged into rails core. Now, defining attr_accessable in our model will lead to an error a bit like this one: RuntimeError (`attr_accessible` is extracted out of Rails into a gem. Please use new recommended protection model for params or add `protected_attributes` to your Gemfile to use old one.). Strong parameters are the recommended way, so let’s have a go:

# controllers/apps_controller.rb
def create
@app = App.new(app_params)
if @app.save
redirect_to app_path(@app), notice: 'Created'
else
render :new, alert: 'Failed'
end
end

def app_params
params.require(:app).permit(:title, :password)
end


The assignment logic is encapsulated in a private method in the controller, and we use this to permit certain values in the params hash for the object we’re interested in. You can read more in the project’s Readme, but note this is now part of Rails core.

Queueing
Rails 4 ships with a simple queuing module. I think this is a greatly anticipated feature, and may folks have written more eloquently on the feature that I have. The gist of it is a job is a class that responds to run, and we push this onto the queue like this:

Rails.queue.push(SomeClassThatRespondsToRun.new)

I couldn’t find a generator for creating a job class, so I’m not overly sure of the convention that we’re supposed to follow, but I created a jobs directory under app and popped a MyJob class in there. Here’s a simplified example:

class MyJob
def initialize(id)
@id = id
end

def run
Thing.find(@id).heavy_lifting!
end
end

And we call it with:

Rails.queue.push(MyJob.new(@thing.id))

Rails will spawn a worker process and process our queue in the background from there. For an interesting look into how Rails.queue is implemented, this is a good article and the source is enlightening too.

Conclusion
I’m liking Rails 4! On balance I think things are moving in the right direction. We’re getting built-in support for stuff that happens in almost every project i.e. queuing, the new test directory structure makes more sense, to me at least, and anything to help make routing easier is something I’ll always appreciate.

I’m looking forward to dipping in to the source a little more, and following the development to the 4.0 release. I can’t wait!

To set the scene here, this is a native iOS app, which speaks to a Rails based API. Initially we thought that this might be related to the reported ‘iOS 6 breaks POST requests’ issue, but after some investigation it became apparent that form fields from any POST reqs were getting the param should_group_accessibility_children (or shouldGroupAccessibilityChildren) injected into them.

When this extra param hits the API and we call something such as:

@user = User.new(params[:user])
@user.save


Rails will throw an exception as the User model is not aware of the should_group_accessibility_children attribute. This will in turn return a 500 to the iOS client, which will display an error to the user.

For a quick fix, we monkey-patched AR::Base to add this attribute and subsequently ignore it. This worked fine, but just didn’t feel right. We then decided to see if it was possible to parse out these params using middleware, which indeed it is.

We have since released rack-remove-param, which can be used to solve exactly this. It’s actually a little more general however, you can use it to filter out any params you might not want hitting your application.

To use, simply add the gem to your Gemfile and then the following to your application.rb:

config.middleware.insert 'Rack::RemoveParam', 'should_group_accessibility_children'


There doesn’t seem to be much info out there on what this param is (why you would add unknown form fields to reqs is another question!), but it seems to be related to some new accessibility features. If anyone has more info, then please comment.

Update

Ok, so thanks to some comments and further discussion internally we can offer some answers to this.

iOS6 does not inject this param to POST requests. iOS has for some time added properties related to accessibility to base objects. The problem here is how we serialise them to JSON, which currently maintains a blacklist of attributes we don’t want. Obviously when iOS adds a new accessibility attribute it will get added to the JSON. A much better approach (and the one we would always prefer), is to maintain a whitelist of attributes to serialise.

There have also been comments on HN relating to the fact that there is no need for this middleware if you are properly protecting against mass-assignment. Whilst this is true in part, a fairly normal behaviour when you receive a param you don’t want to mass-assign is to raise an error, which would result in the same behaviour in the client (i.e broken). Therefore it can be useful to filter the param via middleware whilst clients are updated.

Its maybe worth mentioning that the API already did filter out harmful params (i.e. things that could exploit the rails mass-assignment), and would raise errors on unexpected ones. Therefore a new parameter coming from a client would stop the client from successfully creating an object.

class User < ActiveRecord::Base
  
  after_save :queue_welcome_email, :on => :create
  private
  def queue_welcome_email
    Resque.enqueue(WelcomeEmailJob, self.id)
  end
end

class WelcomeEmailJob
  @queue = :normal

  def self.perform(user_id)
    user = User.find(user_id)
    UserMailer.welcome_email(user).deliver
  end
end

Straightforward, right? You’d think so, but if you implemented this and ran it in a live system, you would find a small number of ActiveRecord::RecordNotFound errors cropping up in Resque.

What’s going on?

This has bitten me on more than one occasion, which is why I’m taking the time to write it down now. The problem is that your eager worker has snatched the job off the queue and tried to process it before your database transaction has completed. So when it calls to the database to find your new record, it won’t actually be there, even though you said “after save”!

So how do we sort this out? Well, since Rails 3 there has been one last callback beyond after_save: after_commit.

Problem solved, new problems introduced

So, all we need to do is replace any after_save that places jobs on a queue with after_commit? Sort of, this does actually raise some other problems for us. Firstly, if you are using transactional fixtures, your tests, like the one below, will now fail.

class UserTest < ActiveSupport::TestCase

  def test_should_queue_email_job
    flexmock(Resque).should_receive(:enqueue).once
    User.create(:email => 'test@test.com')
  end

end

Transactional fixtures stop us having to teardown and recreate our database every test by just running every test within a transaction and rolling back at the end. This presents a problem; if the after_commit callback only runs once the transaction is complete, then it will never run in our test.

To deal with this, you can either give up on transactional fixtures, which will likely make your tests slow down, or, my preference, create tests that avoid transactions purely for this use case.

class UserAfterCommitTest < ActiveSupport::TestCase

  self.use_transactional_fixtures = false

  def test_should_queue_email_job
    flexmock(Resque).should_receive(:enqueue).once
    User.create(:email => 'test@test.com')
  end

end

Dirty Attributes

Our initial example is now solved, we no longer have an issue with the database and the workers racing against each other to save or retrieve our record. There is one other scenario I want to mention here though. Imagine you are using a 3rd party email newsletter service and you need to keep your users’ emails up to date with the service. You might have something like this:

class User < ActiveRecord::Base

  after_save :update_external_email, :if => :email_changed?

  private

  def update_external_email
    Resque.enqueue(ExternalEmailJob, self.id)
  end
end

We are suffering with the problem we first discussed here. But, if you just change after_save to after_commit you will never update those emails externally. Why? Because by the time the after_commit callback is triggered, the record’s dirty state has been reset and email_changed? will return false.

Thankfully, the Rails team had thought of this too. Available on every object is a method called previous_changes which contains a hash of attributes that changed the last time the object was saved. Sadly, with this we don’t get all our convenience methods like #{attribute}_changed? (although we could write them ourselves) this still tells us what happened to the attributes, so we can use after_commit conditionally.

So, to update our example, we can now write:

class User < ActiveRecord::Base

  after_commit :update_external_email, :if => :email_previously_changed?

  private

  def update_external_email
    Resque.enqueue(ExternalEmailJob, self.id)
  end

  def email_previously_changed?
    previous_changes[:keys].include?('email')
  end
end

after_commit and previous_changes save the day

The race condition between database and workers can be hard to spot and it has caught me on more than one occasion. Thankfully, once you realise you are heading for this sort of issue, or once you catch it, these quick changes will sort you out.

So we’ve released rack-access-control-headers to make things a whole lot easier! This is a simple bit of rack middleware that can be used in any rack app to set the appropriate headers. Getting started is easy:

1, Add the gem to your Gemfile (if using bundler):

gem 'rack-access-control-headers'

2, Install:

bundle

3, Insert middleware, in config/application.rb (or specific environment file – example from rails):

config.middleware.insert_before 'ActionDispatch::Static', 'Rack::AccessControlHeaders', /assets/

Where /assets/ is a regex of the path you want to inject the headers.

N.b. including ahead of ActionDispatch::Static is important if you’re running rails.

By default the the allowed origin is set to “*”, if you want to lock this down, you can simply supply a second argument:

config.middleware.insert_before 'ActionDispatch::Static', 'Rack::AccessControlHeaders', /assets/, 'http://myawesomesite.com'

Simple as that!

One last thing to check is that your web server passes through the headers and that your CDN honors them.

Feel free to submit pull requests with any updates or improvements and I’d love to hear if you are using this.

Because this was the Music/Tech meetup, we had to have music playing, and it had to be done in a needlessly complicated way. To that end, we decided to take a crack at making the playlist selection more egalitarian. Enter Collabify.

The idea
The idea was simple – one Spotify playlist, many people adding to it. Now, I appreciate this is already a solved problem – Spotify has had collaborative playlists for ages. However, we didn’t want everyone having to have their laptops open or go and mess with the laptop connected to the PA. Instead we made a mobile-optimized web interface that would allow you to search for and add songs, and a Spotify app to grab peoples requests and put them into a playlist.

How it works
Collabify consists of two main parts, the client and the server. I’ll talk about the server first.

The server is a super simple Sinatra app. It throws up a web page with a search field, accepts the query and uses the Spotify Metadata API to find a list of results. Once the user clicks “add” on a result, we save the Artist, Title and URI values into a Redis list as a JSON encoded string. It’s quick, it’s easy. It runs on Heroku.

The client is also super simple. Using the Spotify Apps API, we create a playlist in the main Spotify application (terminology here can get confusing). We then make an AJAX call to the server for the JSON stored in Redis. For each item in the list we get back, we instantiate a track and pop it in the playlist. After our initial setup, we run this fetch-instantiate-populate loop every 20 seconds or so, except on these subsequent runs, we trim the results so we only instantiate new additions.

How did it go?
Well! Aside from a little trouble with the venue WiFi, Collabify was a great success. People had fun adding songs to the playlist, Collabify itself proved to be an excellent conversation piece and most importantly nothing crashed!

We projected the client up on the wall so everyone could see what was in the queue. Here is a ropey picture of it in action:

Collabify on the big screen

For something conceived in the pub and built in a few snatched hours, I think that’s a pretty good result. Checkout the playlist we made.

Both the Collabify server and Collabify client are open source and available for you to have a play with. Be warned though it’s still held together with string and selotape and should not be considered production software in any way, shape or form!

Did you come to the meetup? Did you add tracks? What were your thoughts?

A brief background

Every year the folks of Mint Digital leave the office behind for a week of WAW; our product development competition.
The brief this year was to launch a business in 4 days. My team decided to make an affordable personalised present. We came up with Foldable.Me; a little customisable cardboard avatar.

As the picture above shows, the foldable avatar is 3D. However, when we started developing the customisation tool, the preview of the foldable was all in 2D. After drinking a few of the local ales, my colleague Phil came up with an utterly ridiculous plan. “Why don’t we create a 3D preview?”. He showed me a demo of a 3D box spinning around on his screen. “Nice” I thought, “but that’s just a box, and also, we only have 4 days!”.

Somehow though, he persuaded me to give it a try. I was quite surprised that I managed to set up a prototype of the 3D model in less than a day! Everyone was quite happy to see that with some nifty CSS we were able to improve the user experience of our application quite a bit. It was so much more than just a nice 3D visual effect. Our users would now be able to see a realistic preview of their final product! (See it in action)

The other nice thing about using this technique was that whilst we were using some cutting-edge technology, we wouldn’t exclude users with older browsers from our site. Just some extra lines of CSS and we had a nice 2D version of our 3D model.

Now this may all sound very nice, but we (inevitably) had to deal with some technical issues.

Faces pressing through

For example, I learned that the model renders a lot better in most browsers if you explicitly set the backface-visibility to none on every face of your 3D object. This prevents the backface of your cube to press-through the frontface during animations.

However, Chrome had still some render faults during the animations, but setting the z-index for all faces solved that problem. Even though they’re both webkit browsers, and using the same version of Webkit, the rendering was different in Chrome and Safari. Safari was handling it a lot better than Chrome.

Anti-alias

The worst issue I found was the aliasing in Firefox 11. 3D boxes are not anti-aliased at all in Firefox 11. To trigger anti-aliasing, you need to set a transparent outline on all the faces. That outline would, in this case, break the rendering in Webkit browsers. Because it’s a browser specific issue I had to put in some dirty old browser detection to fix this issue. It doesn’t feel good, but at least it works!

Use it!

As you would have noticed there are a lot of issues that will show up when you’re using such a new technique. We wanted to use this in a production site. This meant it had to be of a higher quality than we would aim for, when we would be creating a demo. We had to do some proper cross-browser testing. Using 3D Transforms currently means you have to expect the unexpected. Even the rendering in Chrome and Safari can differ a bit. It is some hassle, but please don’t let this stop you from using 3D Transforms in a production site! It’s simply too much fun to skip it…

You’re building a site, everything is going well with the styling. Your custom font is looking good on your local version of the site, it’s been checked in staging and looks good there. You launch the site, it looks good everywhere… except Firefox. Your favourite development browser (well, mine at least, apparently some people like Chrome a lot these days) is no longer showing that lovely font. You can’t reproduce this on your own machine, everything seems lost.

CDNs and subdomains

When this has happened to us, it has always come down to one thing: for highly trafficked sites we use a CDN to serve static assets like CSS, JavaScript and fonts. These files not only come from a different server, they get served from different subdomains (normally “media#{n}.awesomenewsite.com” where n is between 0 and 3). The problem: Firefox allows you to request fonts from the same domain but requires access control headers to be set when requesting them across different domains.

Access Control

So, how do you set these headers? We use nginx as a web server so we use a block a bit like the following:

location ~* ^/assets/fonts/ {
  gzip_static on;
  expires max;
  add_header Cache-Control public;
  add_header Access-Control-Allow-Origin http://awesomenewsite.com;
}

If you use Apache, you could add an htaccess file in the folder where the font files live with the following in:

<FilesMatch "\.(ttf|otf|eot|woff)$">
  <IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
  </IfModulegt;
</FilesMatch>

(That snippet thanks to this StackOverflow answer.)

Rather than setting the requesting domain, you can also set the origin to * to allow any domain to request the resource. It is probably best practice to define the URLs yourself, but as it is only Firefox that respects this header in reality it doesn’t matter too much.

Fonts for everyone

It’s easy to add the access control headers for these fonts, but also very easy to forget! I hope this can serve as a reminder to all of us, so we can all get fonts right on the web.

My favourite part of the game was the insult sword-fighting, where, instead of strength, a sharp wit was the only way to overcome your opponent. The insults range from derogatory (“You fight like a dairy farmer!”) to egotistical (“I got this scar on my face during a mighty struggle!”) and you take the lead character, Guybrush Threepwood, through a number of fights to learn them all.

Fast forward to today and with the power of Twitter and a few lines of Ruby we can recreate insult sword fighting for the modern world!

Inspiration

I was inspired to create a Twitter bot by a lightning talk from Corey Haines at RubyConf 2011. He described creating a happiness bot that responds to people saying “good morning” (currently in 21 languages!). He created a gem called Tweetbot (no relation to the iOS app) based on top of the Twitter streaming API to make this easy for anyone. You don’t even need to host it anywhere as it works on Heroku.

With both the tools and the inspiration, all it took was finding a bit of time to implement my bot. Eventually, one Friday night, after an evening in the pub, when all ideas seem like good ones, I wrote Guybot. You can see the code on Github, just to show how easy it is to set up. The bot listens for any insult from the game and responds correctly to it.

Down to battle

Since writing the code and setting the bot free, the most fun has been watching people interact with it! From adulation to ongoing battles. It’s also quite funny just to see how often the phrase “You fight like a dairy farmer” is tweeted!

It’s fun creating Twitter bots, and easy with the Tweetbot gem, so if you want to spread happiness like Corey’s bot, do battle like mine or anything else you can think of, get involved!

From Scott’s piece:

Vendor prefixes like -webkit and -moz were designed to help web developers by allowing browser makers to implement CSS features before the official standard was published.

I propose that the need for vendor prefixes masks the real problem. What are now known as the CSS3 specs, documents still under revision, was first presented to the W3C in 1999. That’s thirteen years ago. Thirteen. A child could have been born and started secondary school. You could rob a bank, be convicted and be out on the street in that time [citation needed]. There are over fifty CSS3 specs, of which only three have become recommendations [ibid].

That vendor prefixes are so widely used is a symptom of the spec being run by an organisation seemingly more interested in talk than in making decisions. Vendor prefixes are supposed to be for experimental features, not features common to modern browsers.

It’s simple market forces really – supply and demand. Webkit has supplied an implementation of several features that are in such demand other browser vendors are considering implementing the -webkit prefix themselves. Therefore, I propose these implementations become recomendations, and we drop all vendor prefixes for it. By tightening the loop between experimentation, adoption and acceptance, we fix the web.

For the web to succeed, difficult decisions have to be made. These are decisions about standards and best practices. They cannot be made lightly. But perhaps they can be made more quickly.

—

Like this post? Vote it up on Hacker News.