Running Thin in a Thread to serve static files (or how to seed carrierwave images)

Published by Rob on March 27th, 2014 – in Ruby

I recently wanted to have a short-term local webserver. Specifically to be able to seed some images with carrierwave, using the handy external_image_url functionality. The project Gemfile has Thin in it, so it made a bunch of sense to use it. Another important property is that I want to be able to run this simple server from within a rails process. There are three bits of information that I learnt and particulary want to highlight

  • starting a thin server to serve a directory
  • running thin in a thread
  • the CarrierWave remote_#{attribute_name}_url (where attribute name is the name of the attribute you have CarrierWave uploadified – used as remote_image_url throughout the rest of this post)

Here is the code that I ended up with for the thin server:

For the carrierwave I ended up with:

Then at the end I clean up with:

So all in one spot the code is:

The above code is a nice little script for programatically uploading images to your carrierwave models in rails code.

Things to think about when building a new web project

I’ve been thinking and talking with people about building webapps. Every project has it’s own set of contexts to consider, and questions to work through. As such each will have things to consider. Here are some questions to work through.

  • Single page vs multi-page
  • JSON HTTP API for data and resources vs generating server side html
  • Big framework vs roll your own
  • Angular/Ember/Knockout
    • testing/learning/state today vs tomorrow
  • javascript module system
    • requirejs/browserify/framework based
  • What server-side frameworks/technologies do you want to use
  • What do you want to learn?
  • CSS Framework for getting started
    • foundation/bootstrap/pure css
  • mobile strategy (responsive design)

For many of the questions and options above, I think that I have strong opinions about the answer (as I’m sure many people do). Thinking through the questions above is an important thing to be doing on any project.

What questions do you think about?

How to use any JavaScript library with RequireJS 2.1

I’ve been using Require JS for a while, having cut my teeth on 0.27.0, and gotten quite familiar with the order plugin that was a part of life when using non require-js libraries.

RequireJS 2.1 provides a different tool for including third party libraries, providing a “shim” object that forms a part of the requirejs config.

With the shim it is easy to add dependencies on non-require js pieces of code. Take a look a the documentation on the shim config( for some details or see some examples below:

Using Twitter Typeahead with Require.js

shim: {
“typeahead”: ["jquery"]

Typeahead depends on jquery being loaded first. Because the API is done via jquery, we don’t need to worry about exporting anything.

Using Twitter Hogan with Require.js
shim: {
“hogan”: {exports: “Hogan”},

hogan doesn’t depend on anything being loaded before it. It exposes itself on the global namespace as Hogan.

Using Twitter Bootstrap with Require.js

shim: {
“bootstrap”: ["jquery"],

Twitter bootstrap depends on jquery being loaded first. Because the API is done via jquery, we don’t need to worry about exporting anything.

URI with Require.js

shim: {
“URI”: ["jquery"],

pushing in a jquery dependency to uri. It has magic in it to detect if amd is being used, and will define itself as an amd module.

SerializeJSON jQuery plugin with Require.js

shim: {
“jquery.serializeJSON”: ["jquery"],

serializeJSON depends on jquery being loaded first. Because the API is done via jquery, we don’t need to worry about exporting anything.

D3 with Require.js

shim: {
“d3″: {exports:”d3″},

D3 doesn’t have any dependencies and exports itself with the d3 global object.

Rickshaw with Require.js

shim: {
“d3″: {exports:”d3″},
“rickshaw”: { exports: “Rickshaw”, deps: ['d3']}

rickshaw depends on d3, and exposes itself with the Rickshaw global namespace.

Getting Started with D3 By Mike Dewar

I picked up a review copy of this book quite a while ago, being intrigued by D3, but not really knowing what it was. It was only more recently that I have been working on a codebase that uses D3, and so had a need to read the book. I’d been tinkering around the edges, but then had a strong need to do some d3 codeing, so picked up my copy of “Getting Started with D3″.

It’s a good thin little book that does a really good of introducing D3 and how to work and think in the D3 way. I found it a really useful tool for learning D3 and it gave me enough to do what I wanted. It’s a good entry point, and helps give an idea of how to work with the D3 APIs. The book shows good examples of consuimg JSON data, and how to render the data into the DOM with D3.  It additionally goes through some SVG and charting examples. It is worth noting that the book is a short read. If you are expecting a detailed reference to D3, this isn’t the book for you.

I’d recommend the book to any developer who wants to know more about D3. I’d strongly recommend it to someone who wants or needs to get started writing D3 code quickly.

[This book was reviewed as a part of the O'Reilly Blogger Review Program]

Notes From Yehuda Katz’s visit to Brisbane

Yehuda Katz( had a brief visit to Brisbane Australia, doing a public presentation, and a more private breakfast meeting. In this blog post I’m going over some of the things that struck me as particularly interesting or worth thinking about.

For those of you who don’t know Yehuda, he is an opinionated and very active developer. Yehuda is a member of the JQuery and Ruby on Rails core teams, and he is also one of the founders of Ember.js (a framework for building rich MVC JavaScript applications –

In the public talk Yehuda went through ember.js, talking through what the paradigm of the framework is, and walking through a demo of some of the key features of the framework. It looks like an interesting option for JavaScript applications. It’s on the brink of going 1.0, but already has some high profile applications using the framework. Apart from seeing the interesting elements of ember and how it’s used, it was very interesting to see the way people are using Ember.js with D3:

I’m definitely going to keep my on the framework as it moves forward.

In his spare time Yehuda is working to push the future of the web in ways that help facilitate rich applications. He has got a couple of ways that he is doing this:

  1. he is a member of the W3C TAG
  2. he is working to influence members of the chrome team to build things well.


The Technical Architecture Group works to specify and guide the architecture of the web moving forward. It has the feel of a good internal architecture group in an organisation, filled with smart people trying to make the web better (it’s membership includes Tim Berners-Lee and representatives of the community, large organisations and browser vendors).

Chrome Team

Through some of the work Yehuda has done, he has had opportunity to spend time with some of the people building new versions of Chrome, and helping to guide some of the thinking towards making apis and decisions that work well for web developers.

So I should have convinced you that Yehuda has some stuff worth listening to. Over the period of time he was I had some good opportunities to listen to both his public conversations and hear some of the more informal conversations. Here are some of the things that I found particularly interesting around where he sees the web heading.

Web RTC looks like a cool technology for real time communications ( The support for peer connections looks particularly interesting.

The new world being demonstrated by google polymer ( looks to be very exciting. Definitely well worth a look for web developers who want to get an idea of the way they will be writing applications in the future. Model Driven Views (, and custom elements ( are extremely exciting, and the shadow dom ( looks like a good tool for helping to support and customise the new features brought in. The HTML + CSS workflow currently is the language of the web, with many people speaking it, and with these tools, I think the language is moving in good directions.

The mechanisms for doing asynchronous JavaScript have been moving on from the straight callback approach that has been familiar to people, particularly through the use of node. There has been much discussion around the web around promises and futures, with things heading towards promises. Martin Fowler has an article describing JavaScript promises (, which is where the W3C TAG is currently headed ( I look forward to having this come into play, and having a standard option that doesn’t involve the deep nesting that can come from callback nesting.

It was interesting hearing Yehuda’s perspective on computer science and functional topics like Monads and functional reactive programming. The binding approach used in Ember.js takes inspiration from FRP, and Promises allow a transformation to a monadic approach.

One of the interesting new things coming to javascript in browsers is object.observe, a feature which will make it possible to observe any object for modifications on it or its attributes.

All in all there is a bunch of interesting stuff in the web future. It’s a great time to be doing web development, and I look forward to what the future holds.

Comparision of 4 approaches to playing audio in iOS

There are at least four different ways of playing audio in iOS.  Each has their own wrinkles and advantages. In this article I briefly compare and contrast some of the differences between the options.  For the TL;DR version skip to the table at the end which compares the approaches. (actually, to be honest, I’ve had this post in my drafts for a very long time, and just wanted to get it published. The body of the article isn’t as good as the table — skim the article and go to the table :))

  • MPMusicPlayerController(using the iPodMusicPlayer)
  • MPMusicPlayerController(using the applicationMusicPlayer)
  • AVAudioPlayer
  • AVPlayer


The MPMusicPlayerController using the iPodMusicPlayer is the highest level player, and matches closely to the iPod.  The actual iPod music player can be accessed and used with the factory method:

+[MPMusicPlayerController iPodMusicPlayer];

The nowPlaying item property will expose the current playing item in the iPod when using the iPodMusicPlayer. Changes to the current item in your application will also update the main iPod music player.

To load your own music player with the same API, use:

+[MPMusicPlayerController applicationMusicPlayer];

In iOS 5.1 and below it is not easily possible to use the AVAudioPlayer to play items from the iTunes library.  While it is possible to retrieve the url for the object, it doesn’t really do what you want. When trying this you will see a somewhat unhelpful error:

Domain = NSOSStatusErrorDomain
Code = -43
Description = Error Domain=NSOSStatusErrorDomain Code=-43 “The operation couldn’t be completed. (OSStatus error -43.)”

The AVPlayer however, allows access to the  iTunes library, playing in the background, custom background behaviour, and playing non-Library audio.

Of the accesible API’s this is the most functionality.  For the hard-core/determined developer, there are lower levels to dig down into, but these 4 options provide a decent set of options to play audio in iOS.  The table below outlines the highlights.

iosMediaPlayer applicationMusicPlayer AVAudioPlayer AVPlayer
play library Y Y N Y
access iPod play location Y N N N
Play in Background Y N ? Y
Custom Background behaviour N N/A ? Y
Play non-Library Audio N N Y Y

Options for getting JRuby 1.6 to use Ruby 1.9 Syntax

In 2012 and beyond you really want to be using Ruby 1.9 syntax (as per the standard ruby implementation KRI). JRuby 1.6 uses Ruby 1.8 syntax by default, but this can be changed to be 1.9. There are a bevy of different ways to do this. I’ll outline these here, and give you my recommendation on what to do.

Command Line parameter

The first way to set the ruby syntax version is to call ruby with a –1.9 parameter thusly:

This I don’t like at all because it doesn’t work with irb, and you have to type different things when using KRI and JRuby.

RUBYOPT Environment variable

A second option is to set the RUBYOPT environment variable to –1.9

This works for irb, but will actually prevent KRI from starting up as KRI doesn’t support the –1.9 parameter (KRI is Ruby 1.9 so the parameter doesn’t make sense).

JRUBY_OPTS Environment variable

Another option is to set the JRUBY_OPTS environment variable.

This works great for JRuby , irb in JRuby, and KRI.

.jrubyrc file

The next useful option is in a user specific .jrubyrc file. This gets called before JRuby starts up. Keep it in ~/.jrubyrc

This works well if you are working in an environment where you will always be running 1.9 compatible code. It’s what I currently do.


If you are using rvm there are a number of ways to do things.

First you can use a .rvmrc and set the JRUBY_OPTS variable, or a PROJECT_JRUBY_OPTS environment variable.

The second option is to enable rvm jruby hooks.

hooks live in $rvm_path/hooks.

In rvm 1.14.3 there are a series of after_use hooks, including some after_use_jruby hooks. Inspect these to see what they do (after_use runs all the other after_use hooks, and the after_use_jruby scripts will get some JRuby magic happening). You could put one of the earlier options here to help make JRuby work.


In conclusion my recommendations for getting JRuby 1.6 to use Ruby 1.9 syntax are:

  1. use a .jrubyrc file wherever possible
  2. use a .rvmrc for situations where you need different versions of JRuby.

Writing Beautiful RSpec Matchers

thoughtbot have created a really nice set of custom matchers for RSpec.  The Shoulda matchers make writing tests for rails models beautiful and clean.

Shoulda matchers make it possible to write specs of the form:

It’s easy to do this for yourself using the friendly matcher DSL that ships with RSpec. Let’s take a look at how.

In the simplest form, all you need to do is to call the define method, passing a name, and a block which in turn calls out to match. The simple case might be:

We’ve just defined a matcher :be_less_than which allows us to do the following:

If we use the describe auto subject feature of RSpec we can also write:


With that example we can see that we are getting close to the shoulda matcher syntax.  There’s still an extra level that helps make the shoulda matchers nice, chaining. Happily this is easy to do as well. The dsl provides a chain method.  The chain methods are called before the match, so you can use the chain calls to collect up additional information to validate.  Using our example above, we might want to add in an :and_greater_than chain.

This now will give us the ability to write:

Unfortunately the default descriptions don’t quite work as nice when there are chains in place. You’ll find that you’ll want to write a description in the matcher definition.

Unfortunately the description doesn’t automatically get used in the error messages when the matcher fails, so you’ll want to specify a failure_message_for_should. Basing it off the description is an ok starting point.

Happily RSpec does the right thing with the should not description, so with the details above the matcher will be good. There might be a case where you want a different failure_message_for_should_not, which can also be specified.

That covers how to write simple reusable RSpec matchers to make your test code look as beautiful as your production code. Go ahead and try it yourself.  I’d love to see comments or questions you might have on this.

REST API Design Rulebook By Mark Masse

I’ve been building web based APIs of various forms for a number of years now, interacting with SOAP and RESTful services, and building some myself. It was with some interest that I picked up the book REST API Design Rulebook, getting it from the O’Reilly blogger review program.

The book provides a decent set of information around REST, and had me either nodding my head or thinking at various stages. Its description and thoughts around REST were pretty good, but there is one area to be wary of. The book seems to do two things.

  1. Describe ways of doing REST well.
  2. Sell WRML, the authors own framework to help model REST

I found the first helpful and useful, but wasn’t as excited aboutthe second. While I understand the authors passion and desire to share what they’ve created, it ends up detracting significantly from the book, to the extent where I’d downgrade it from a must read to something that I’d hesitate to recommend.

The problem boils down to this. There are a number of challenges and interesting things to solve with REST APIs. The author has created a framework to help deal with these. Naturally then the author recommends using their framework to solve the problems. Which mean the book becomes Rest API design Rulebook with WRML. I’m not convinced that WRML is the answer, so I’d hesitate to recommend this book.

[This book was reviewed as a part of the O'Reilly Blogger Review Program]