Tim Riley

A Manageable Multi-Database Redis Development Setup

Tim Riley — Tue, 16 Apr 2013 01:32:39 +0000

Redis has quickly become the companion to Postgres in most of our Rails apps. This creates a problem for development, since a Redis server only uses numbered databases. That's 1-16 by default. Hardly memorable, unless your app is called "5", in which case you're golden. On a single machine alone, it's easy enough to lose track of them once you have a few apps connecting to redis for both development and testing databases. Once you have multiple developers and designers working on an app, it's even worse. The solution I've found is to run a separate Redis server for each app, listening via a named socket.

This is easy to set up. First, take your standard Redis config file (mine is /usr/local/etc/redis.conf, thanks to Homebrew) and copy it to redis-common.conf. Edit this new file and change its port to port 0, ensuring it doesn't listen over TCP.

Then, create a separate config file for each app you want to use Redis. I call them /usr/local/etc/redis-server-<app_name>.conf. These files are nice and short:

include /usr/local/etc/redis-common.conf
pidfile /usr/local/var/run/redis-app_name.pid
unixsocket /tmp/redis-app_name.sock
dbfilename dump-app_name.rdb
vm-swap-file /tmp/redis-app_name.swap

These per-app config files are enough to run an entire Redis instance: they load the common config, followed by the app-specific paths that allow the server to run in isolation from other apps.

You can then start the Redis server like this:

redis-server /usr/local/etc/redis-server-app_name.conf

Currently, I have 5 different app-specific configs like this. This makes bringing Redis up and down a bit of a chore. I simplified the process with a couple of shell functions:

function redstart {
  redstop
  for file in `ls /usr/local/etc/redis-server-*.conf`; do
    redis-server $file
  done
}

function redstop {
  for file in `ls /usr/local/etc/redis-server-*.conf`; do
    pidfile=`grep pidfile $file | awk '{print $2}'`
    if [ -f $pidfile ]; then
      kill `cat $pidfile`
    fi
  done
}

Easy. Redis up and Redis down in one hit.

There's another benefit to running Redis like this: loading production data onto your development machine. Most cloud-hosted Redis providers give you backups in Redis' .rdb format, which is the data file for the whole server. You can't load this for a single numbered database. Splitting your local Redis servers by app means you can just replace the file specified in dbfilename with this backup file and now your app has the latest production data without interfering with any other app's Redis data.

Bonus: Redis config management functions

Want an easier way to build and manage those per-app config files? Here you go:

function redls {
  ls /usr/local/etc/redis-server-*.conf
}

function redgen {
  if [ -z "$1" ]; then
    echo "You need to specify an app name, eg. redgen decafsucks"
    return 1
  fi

  app=$1
  config="/usr/local/etc/redis-server-${app}.conf"

  redstop

  echo "include /usr/local/etc/redis-common.conf"     > $config
  echo "pidfile /usr/local/var/run/redis-${app}.pid"  >> $config
  echo "unixsocket /tmp/redis-${app}.sock"            >> $config
  echo "dbfilename dump-${app}.rdb"                   >> $config
  echo "vm-swap-file /tmp/redis-${app}.swap"          >> $config

  redstart
}

function redrm {
  if [ -z "$1" ]; then
    echo "You need to specify an app name, eg. redrm decafsucks"
    return 1
  fi

  redstop
  rm -f "/usr/local/etc/redis-server-${app}.conf"
  redstart
}

Bonus: Rails redis initializer

Here is the do-it-all Redis initializer I use in my Rails apps:

require "redis"

if (redis_url = ENV["REDIS_URL"] || ENV["REDISTOGO_URL"]).present?
  uri = URI.parse(redis_url)
  REDIS = Redis.new(
    host: uri.host,
    port: uri.port,
    password: uri.password)
else
  redis_socket = "/tmp/redis-myappname.sock"
  if File.exist?(redis_socket)
    REDIS = Redis.new(
      path: redis_socket,
      db: !Rails.env.test? ? 0 : 1)
  else
    REDIS = Redis.new(
      host: "localhost",
      port: 6379,
      db: !Rails.env.test? ? 0 : 1)
  end
end

This looks for Redis URL ENV vars first, which are used on Heroku to specify the Redis location. If they're not found, we must be in development, so it looks for the named Redis socket for the app (change redis_socket to make it your own). If that's there, it uses database 0 for Rails development and production modes, and database 1 for test. Finally, we don't want to fail completely if someone hasn't yet starting using the named redis sockets, so we fall back to the standard Redis TCP port.

Permalink

There is No Lab

Tim Riley — Tue, 12 Mar 2013 21:30:00 +0000

Much has been said about remote work lately. Yahoo! brought it to the fore when CEO Marissa Mayer completely cancelled their remote work policy a few weeks ago. It made mainstream press and quickly raised the ire of David Heinemeier Hansson, whose beliefs about remote work have shaped his life: half of his 37signals co-workers are remote and he too spends half his year working abroad.

At Icelab we don't have so much a formal policy about remote work (or about anything, really), but instead some simple guiding principles: work with good people to make good things, and as long as we can keep the business running, do whatever we can to help those people lead the lives they want.

I try to embody these principles: I spent the bulk of last year working from the Philippines and Hong Kong — and just this afternoon, I’ll fly off to Tokyo, the first leg in a trip that will see me working from five countries across three continents over the course of this year. It's allowing me to see the world in a way never before possible. Hugh's done some of this too, also checking in from Tokyo for a month at the start of last year. And in a couple of weeks, David's heading to Europe for a holiday and can extend it a little while by doing some work over there too.

Having people work from overseas has been no problem at all. In fact, 2012 was our biggest, most productive year yet.

Remote work isn't all about extending a holiday or seeing the world. It can also be about finding the right space for productivity in everyday life. Even Yahoo! recognised that you can't be chained to the office, that "occasionally [you] have to stay home for the cable guy," but this is more a sign of their failure to recognise the intrinsic value in a change of environment. As The Economist argued:

Plenty of evidence suggests that letting employees work from home is good for productivity. It allows them to use their time more efficiently and to spend more time with their families and less fuming in traffic jams or squashed on trains… You can shackle a Yahoo to his desk, but you can't make him feel the buzz.

We make our offices as comfortable and conducive to productivity as possible, but good work doesn't always happen from the same place. Good people, on the other hand, are good people everyday, regardless of their location.

Permalink

Click to Edit with AngularJS

Tim Riley — Fri, 11 Jan 2013 02:30:00 +0000

Every time I use AngularJS I love it a little more. One of my favourite things about it is how greatly it reduces ceremony and separation. When I'm writing front-end interactions, the last thing I want to be doing is jumping between files and maintaining state in two different places, especially for simple things like "click to edit" behaviour. That's what I'll show you now, done powerfully and directly in Angular:

<div ng-app>
  <div ng-controller="ClickToEditCtrl">
    <div ng-hide="editorEnabled">
      {{title}}
      <a href="#" ng-click="editorEnabled=!editorEnabled">Edit title</a>
    </div>
    <div ng-show="editorEnabled">
      <input ng-model="title">
      <a href="#" ng-click="editorEnabled=!editorEnabled">Done editing?</a>
    </div>
  </div>
</div>

Try this jsfiddle to see it in action. What we're doing is showing some text (an article's title in this example) and then revealing a field to edit it upon clicking an "Edit" link.

To achieve this, we use an Angular editorEnabled model (really just a flag here) that we check with ng-show and ng-hide directives to hide and show the various parts of the interface. We change this value using an ng-click directive on the hide and show links. Angular's data binding keeps everything in sync. As soon as editorEnabled flips between true and false, the interface reacts accordingly. And the best thing? Everything you need can be written directly in the markup.

The only bit of JavaScript is just the most basic setup for the Angular controller, providing an initial value for the title:

function ClickToEditCtrl($scope) {
  $scope.title = "Welcome to this demo!";
}

For some more sophisticated behaviour, you can put some more code in the controller. Let's change the interface to show "save" and "cancel" links when editing the title, and only update the title if the "save" link is pressed:

<div ng-app>
  <div ng-controller="ClickToEditCtrl">
    <div ng-hide="editorEnabled">
      {{title}}
      <a href="#" ng-click="enableEditor()">Edit title</a>
    </div>
    <div ng-show="editorEnabled">
      <input ng-model="editableTitle" ng-show="editorEnabled">
      <a href="#" ng-click="save()">Save</a>
      or
      <a href="#" ng-click="disableEditor()">cancel</a>.
    </div>
  </div>
</div>

See it in this jsfiddle.

The code in the corresponding controller doesn't need to worry about the interface at all, it just operates on the scope, and the interface updates itself accordingly.

function ClickToEditCtrl($scope) {
  $scope.title = "Welcome to this demo!";
  $scope.editorEnabled = false;

  $scope.enableEditor = function() {
    $scope.editorEnabled = true;
    $scope.editableTitle = $scope.title;
  };

  $scope.disableEditor = function() {
    $scope.editorEnabled = false;
  };

  $scope.save = function() {
    $scope.title = $scope.editableTitle;
    $scope.disableEditor();
  };
}

If you wanted to extend this even further and make it a reusable component for different parts of your interface, you would make it a custom directive.

One of the other great things about AngularJS is that you can use it as much or as little as you like. We've used it for the entirety of The Thousands' admin interface, so adding bits of behaviour like this is no problem. But even if you're not already using it, you can just as easily attach an ng-app to any one of your HTML elements and get started.

Permalink

Announcing Decaf Sucks 1.1

Tim Riley — Thu, 10 Jan 2013 08:00:00 +0000

It's been a while since we've talked about Decaf Sucks on the iPhone. Our first release has run smoothly for a year and a half, helping many thousands of iPhone owners find better coffee. Thanks to our well caffeinated contributors, nearly half of our reviews are now submitted from the app.

On this note, we're very excited to announce the release of Decaf Sucks version 1.1 in the App Store. This release makes it even easier to contribute reviews with the addition of Facebook login support (now available wherever Decaf Sucks exists).

We've also added support for the iOS 6 and the larger iPhone 5 display, as well as giving the app some extra polish all around. In particular, our overseas friends can rest easy, because the distance to your favourite cafes is now reported in miles or kilometres based on the device's region format setting.

Decaf Sucks 1.1 is still free and waiting for you in the App Store. Get it now and find some great coffee near you!

Read on for a full list of all the things we've changed.

New features:

Login with Facebook to write reviews
Support for the larger iPhone 5 display
Distance units are localised into miles or kilometres based on the device's settings
iOS 6 compatibility updates

Other improvements:

When setting a cafe's location, show a callout above the map pin to make it clear that it can be dragged around.
When setting a cafe's location, ensure that the pin is actually draggable on the first tap.
When setting a cafe's location, always show a proper full address after dragging the pin around.
Show a proper non-retina image for the back button's pressed state.
Fix a bug that sometimes caused the map view to start very zoomed out.
When a review is completely empty, make sure the "Post" button stays disabled.
Ensure the map for a single cafe encompasses the current location, if it is nearby.
Fix a bug that led to some reviews being set to Hyderabad, India. Yes, this was really weird.

Decaf Sucks 1.1 is available in the App Store now.

My Boring Adventure

Tim Riley — Sun, 06 Jan 2013 03:30:00 +0000

Austin Kleon's Steal Like An Artist, his manifesto for creativity in the digital age, is full of useful tips, with one that stands out for me:

Be boring. (It's the only way to get work done.)

While an inspired spark may be source of creative work, it's the drudgery of thorough execution that's necessary to bring it to completion. Even the smallest projects are an accumulation of many tiny details, each requiring time to get right. To do this, you need to show up and work, day after day. Being boring enables this.

But you can be boring and have adventure too. The way I've done this is to combine work and travel. Not the frenetic "I've got to squeeze as much as possible into my annual leave" kind of travel, but months at a time in a new place. This allows you the time to develop the routine needed for consistent, productive work, alongside many opportunities to explore your new home at a comfortable pace. Every lunch break affords you a chance to see something new, every outing for coffee the chance to become a regular in a new neighbourhood. Andy Warwick puts it excellently in this Quora thread: "the mundane becomes an adventure when you live in a foreign land."

And when you wrap up your work for the night or for the week, there are hours and days ahead of you for adventure and discovery, which can inform and fuel your otherwise perfectly boring working life.

Written from Adelaide, Australia, where I'm living for two months.

2012 in Review

Tim Riley — Tue, 01 Jan 2013 05:20:00 +0000

A life abroad

This was a year marked by two new worlds: Garmisch and I spent six months living in the Philippines and two in Hong Kong. We experienced the full stretch of the urban spectrum; from the wide blue skies, leisurely pace (and mild chaos) of a provincial tropical island, through to Hong Kong's unending bustle and its dense, concrete verticality.

It was our first considerable stretch of time overseas. Living in the relative isolation did bring some challenges, but we overcame them, and in doing so we became a closer couple and hardier humans. And we've left the experience with a new perspective on what's important, and on how we run our lives from here (Hint: there's still a little more exploring to do!).

This wasn't the year's only travel, either. The long stretches abroad were punctuated by visits elsewhere: Wellington in February for the magnificent Webstock, Australia in April for a group hug with my workmates, Singapore in May for RedDotRubyConf, and Tasmania in November for Railscamp 12. And outside all of this, with our own place rented out, we spent some quality time staying with our parents, firstly in Canberra and now in Adelaide.

A bigger, better Icelab

It was a big year for Icelab. In January, we had five people: our Canberra office and Max on his own in Melbourne. In March, we merged with Inventive Labs, welcomed Narinda, Toby and Ally to the team, and assumed their office space in The Ironmongers on Brunswick Street. In August, Melissa joined us in Melbourne as a project manager. In September, David joined us in Canberra as a developer. In December, we moved out of our (then very crowded) office in Canberra into a bigger, much more comfortable space just a few blocks away. We finished the year with nine amazing people and permanent offices in both Canberra and Melbourne. And all of this while I was mostly overseas. A distributed team can really work.

The larger team meant we put out more work than ever. Plenty to be proud of, and plenty I wish I could have been more involved in. That said, I did get to ship a few large projects this year:

PDF e-ticket support for Ticketscout
The Thousands, with Max Wheeler & Anthony Kolber
Youcamp, with Toby Allder and Michael Honey, along with contributions from almost everyone in the lab

Some other work endeavours

I had less time than usual this year to work on side-projects, but I did manage to ship gentlyremind.me in February. It sends you a daily email of your recently favourited tweets. I use it everyday and it's nice to see my friends do the same.

I also found a little time to take a look into RubyMotion for building iOS apps. I put together an introductory talk and presented at a Canberra Ruby meeting and at Railscamp 12, where I also ported the bulk of the Decaf Sucks iOS app to RubyMotion in just a day or so. I expect I'll spend a lot more time with this in the future.

Some new apps

A notable trend that emerged this year was my increased use of activity-tracking apps. Films I watched went in the lovely Letterboxd. My Decaf Sucks page continued to grow as I explored new cities café-by-café. In Hong Kong, I started using Foursquare so I could record the eateries and other interesting places I visited, and it's stuck with me since then. I tried to take note of my general activities using Day One on both the Mac and iOS. It hasn't quite become habitual yet, but anything I record there is a bonus. Finally, Rdio has become a daily source of musical wonder; my iTunes library is long since deleted.

Getting to the point

One of the freshest, foremost things in my mind about this year is a hard slog in the last six months; Icelab was growing, and there were was just a big backlog of work that had to be done. To help, I bore down and worked harder and longer than ever before. We got past it, but it came at some personal cost. I lost opportunities for spending time with my wife, for exercise, exploring my new locations, and my own creative work.

After all of that, though, I feel we've arrived in a good position to create a more sustainable workload in the future, and I haven't lost any of my passion for creating things. If I still feel like this now, I know it won't change, and I know that I'll continue to put lots of time into it. What I have learnt is how it feels to do it out of some kind of obligation, and I'll do my best to ensure I don't fall into that position again.

But the biggest story, and the story worth remembering, is that I could do all of this — the hard work included — while still sharing wildly new experiences and building a stronger relationship with Garmisch. I couldn't think of a better friend and travel companion, and I'm ever thankful for her company and support.

I've finished the year with a stronger sense than ever of empowerment and direction. 2013 will be big!

Out My Window

Tim Riley — Sun, 16 Sep 2012 00:30:00 +0000

The view out the window in my previous and current overseas offices: Talisay City (Negros Occidental, Philippines) and Sheung Wan (Hong Kong).

From a Good Idea and Persistence Came Sneakers

Tim Riley — Mon, 10 Sep 2012 21:30:00 +0000

Stephen Tobolowsky shares some behind the scenes memories of Sneakers, an all-time favourite film of mine, and finishes with his thoughts on scriptwriter Phil Alden Robinson:

Years later I ran into Phil at the symphony. I asked him I how he was able to come up with such a great script. He blushed and said he had worked on it for nine years. I know spending a long time writing something doesn’t guarantee success. But not giving up on a good idea almost always does.

Permalink

Lost Cities for iOS

Tim Riley — Tue, 28 Aug 2012 21:30:00 +0000

Lost Cities is one of my favourite card games, and over the weekend I was surprised to learn about the release of a version for iOS. The app was released by TheCodingMonkeys, who previously built the Carcassonne app. I'm happy to report that Lost Cities is adapted just as delightfully for the iPhone.

Lost Cities a two-player game, and while the mechanics don't allow for the pass-and-play experience that Carcassonne offers, it's still fun and responsive to play against friends, whether they're in the same room or across the internet. The move to iOS also enhances the core experience of the game: that the scorekeeping and card counting is done for you allows you to focus solely on your tactics and execution. The single player challenges also encourage you to try different techniques and gameplay styles. This is a digital adaptation done right.

The graphical polish on the app is amazing, and the music is exquisite. Together, they really do create a feeling of daring and adventure, which is quite remarkable for a game that otherwise consists of stacks of cards. You want to try this game, if only to see how a card or board game should be done on iOS.

I was also interested to learn that TheCodingMonkeys were also the developers behind SubEthaEdit, the comparatively nerdy and (and definitely less game-like) networked collaborative text editor. Nice to see a company take their experience from one area of software development and use it to find success with some completely different products.

Permalink

Fast Downscaling of Retina OS X Screenshots

Tim Riley — Wed, 22 Aug 2012 21:30:00 +0000

Screenshots from the retina MacBook Pro look comically large when I share them with my @1x teammates. This kind of fidelity is especially unnecessary when casually sharing annotated snapshots back and forth during the app development process.

Automator makes it easy to build an app that will halve the dimensions of the images. Open Automator, choose to build a new Application, then add these steps:

Save it to /Applications and you're done. Then, dragging an image onto the app's icon will immediately copy it to your desktop and rescale it. Put it in your Dock for even easy access, or if you use LaunchBar, you can do it even faster with InstantSend.

Saying Goodbye, Keeping Your Team

Tim Riley — Tue, 21 Aug 2012 12:30:00 +0000

Noah Stokes shares his decision to leave San Francisco, and demonstrates that you can both move and take your colleagues with you:

Bold now shares a virtual office. Garrett is still in San Francisco, while Sam has moved to Austin, Texas and Charlie remains in Raleigh, North Carolina. It’s bittersweet to be virtual, but at the same time we all work to live, not live to work. So why not love where you live.

I've spent 9 of the past 12 months working remotely with my team at Icelab, and in this time, my wife and I have experienced life and adventures together in some amazing and personally significant parts of the world. It's been a unique and precious period in our lives, and my work's been a critical enabler for it.

And when I am at work, we've been as productive as ever. The time collaborating remotely has actually strengthened my understanding of my teammates. It takes a certain degree of thoroughness to explain yourself in text and over Skype. You can't take shortcuts in your communication. It's true that this has led to frustration at times, but it's ultimately led to a more acute knowledge of their workings and motivations.

Anyone who builds things knows that worthwhile creations take time to mature. One of the most worthwhile things you can work on is your team. If you've found a good one, do your best to keep it, no matter where you live.

Permalink

Moved to Hong Kong

Tim Riley — Fri, 17 Aug 2012 08:15:00 +0000

As I write this, I look over Hollywood Road and watch the antique stores close down for the day. A stream of red-topped taxis buzz by. There's still a waft of incense in the air from the nearby Man Mo temple. In a sweep of the eye, I can see hundreds of tightly packed residences stacked above each other. That's right, I'm in Hong Kong!

Time has really flown by since my wife and I finished in the Philippines and came back to chilly Australia at the end of June. We spent a whirlwind seven weeks catching up with friends and work, and now we've already started the next chapter of our overseas adventures: two months in Hong Kong.

Why Hong Kong? We've visited a couple of times and have really enjoyed it here, and after eight months in the provincial Philippines, it would be fun to experience the opposite end of the urban spectrum. Working remotely for Icelab has been no trouble, so we can go where our fancies take us.

We're staying in Sheung Wan, a fantastic neighbourhood. It's an older area and still largely residential, so it's quiet and charming, but just 10 minutes by foot to the bustle of Central. There are antique shops, galleries, boutiques and a bunch of decent cafés. Monocle has a great video introduction to the neighbourhood.

Smarter the second time

Compared to the initial effort of preparing for the Philippines, moving here has been a breeze. All our affairs were already in order, so getting out again was merely a shuffling of what was in the suitcases. If you've made the effort to relocate for a significant period of time, you almost owe it to yourself to back it up with another trip.

We've learnt from our first experience and have done a few things differently this time. Firstly, we're staying in an apartment we found via Airbnb. The place is very comfortable and already well set up. Within a day of arriving, I was able to put in a productive day at work. For a shorter stay, it's great not to worry about finding and establishing a new place to live.

We also packed far lighter. Here's my packing list for 2 months:

Essentials

6 t-shirts
1 pair of shorts
1 pair of jeans
1 pair of shoes (My trusty New Balance 574's)
1 pair of thongs
Assorted underwear and socks (much less than the Philippines)
Toiletries

Gear

MacBook Pro
iPad (mostly for reading)
Jawbone Jambox
4 external HDDs (2 x backup, 2 x media)
Camera

All up, 13kg in one still quite empty suitcase.

Say hello

We've a little over 6 weeks left here in Hong Kong. I'm hoping to make it out to a couple of tech meet-ups, but would love to meet anyone for lunch of coffee. Say hello!

Icelab in Offscreen Magazine

Tim Riley — Fri, 13 Jul 2012 01:30:00 +0000

Have you seen Offscreen Magazine yet? It's an insightful, inspiring read about the work and motivations of digital creators all around the world. It's been months since the inaugural issue and I'm still thinking about some of the things I read there.

I was able to contribute to the second issue, with the view from my office in the Philippines.

It's nice to see that little slice of my life preserved in print, and a privilege to be in such good company. Kai Brach has done an excellent job putting together a beautiful, collectible magazine, something that will stand the test of time. You can buy the first two issues now.

Asset Pipeline Tips

Tim Riley — Fri, 22 Jun 2012 08:30:00 +0000

How we're handling the Rails asset pipeline at Icelab. For me, this is a great example of the benefits of working in a team: its collective capacity for learning is huge. I never had a chance to really grok the ins and outs of the asset pipeline, but here Hugh has done it and laid it all out for me.

Permalink

RubyMotion & Rails Responders at the Canberra Ruby Crew

Tim Riley — Wed, 20 Jun 2012 19:30:00 +0000

This week the Canberra Ruby Crew meetings kicked off again after a long hiatus. Both Hugh and I gave presentations. Hugh spoke about our use of Rails responders for tidily offering layout-less content intended for display in modal popup windows. You won't see his slides online just yet, but his use of Impress.js with the demos embedded in iframes was ingenious.

I gave an introduction to RubyMotion, the impressive new Ruby implementation for developing iOS apps:

I've played with all the other half-arsed attempts at bridging different languages or web tech with native iOS deployment, and none of them has left me convinced. RubyMotion is different. It feels first-class, and in its brief couple of months since release, so many libraries have sprung up that look to make iOS development much more pleasant. I'm convinced enough that I'll be porting Decaf Sucks across. I'll let you know how it goes.

If you're interested in learning RubyMotion, here are some resources worth checking out:

Free screencast from The Pragmatic Studio
The repository of example apps
The examples from iOS Programming Big Nerd Ranch 3rd ed, ported to RubyMotion
A long list of open source RubyMotion projects (and another here)

Many thanks to Hugh and Matthew for organising this month's meet. If you're interested in coming along next time, join the mailing list and follow @rubyaustralia on Twitter. See you then!

Keith Pitty's List of Ruby Resources

Tim Riley — Wed, 06 Jun 2012 00:30:00 +0000

Keith provides an excellent list of websites, books and podcasts that will help make you a better Ruby programmer. We'd all do well to put aside a couple of hours each week to spend some time with any of these.

Permalink

Icelab Singapore and RedDotRubyConf 2012

Tim Riley — Sun, 03 Jun 2012 22:30:00 +0000

In May, Hugh and I took off to Singapore for a week of work capped off by the second RedDotRubyConf.

I recommend that you take a break from your usual work patterns and environment and do your job somewhere else. It needn't be somewhere exotic, but if you can manage it, all the better! For me, the week in Singapore was especially rewarding because it was a great chance to compare notes with Hugh about what we've been building lately and some of the techniques we're employing (not to mention a great chance to sample some coffee too).

hello from Singapore, happy friday! #fridayhug at @reddotrubyconf during @schneems talk. twitter.com/hone02/status/…
— Terence Lee (@hone02) May 18, 2012

RedDotRubyConf took place over the Friday and Saturday, and it was a great event. For me, a lot of the value in attending a conference is how I feel when it ends, and how that translates into actions that change my life and work. After a conference like Webstock, which I attended earlier this year, I was compelled to think about the longevity of my work and how I wanted to help shape Icelab. After Red Dot, I was motivated simply to become a better Ruby developer. For something I do everyday, this is a useful thing.

This was the first single-track conference I've attended, and I liked the structure a lot: no difficult choices and a single shared experience for everyone.

Some of the standout talks for me were, from Day 1:

Ilya Grigorik's Building a faster web: This was jam-packed with useful suggestions, and building for speed is something we should always keep in mind. Incidentally, I'd seen his slides online earlier, but picked up so much more seeing him speak. A good reason to come to conferences.
Danish Khan's The Ruby Community: A nice reminder about being good project maintainers and open-source citizens.
Sau Sheong Chang's Ruby, Rock & Roll: I love just-for-the-sake-of-it out there tech talks like this. We were treated to a walkthrough of the process of building a Ruby music synthesizer and DSL.
Wei Lu's A Journey into Pair Programming: An intro to pairing from one of the {new context} engineers. I'm still not convinced that pair programming is necessarily the best option for small studios with many concurrent projects, but it's still important to critically consider your working methods.

And on Day 2:

Obie Fernandez's Redis on Ruby: I've used Redis before, but not as extensively as Obie. A great eye-opener, showing a huge number of potential uses for the database. I predict more of this in my future.
Carl Coryell-Martin's Computer Scientist, Developer, or Engineer?: A reminder that we should measure our work against real human needs.
Darcy Laycock's API Driven Development: Nearly everything I build these days has an API, and there's a lot of new tools about to help make them easier to build.
Koz's Lessons From the Other Side: Effectively Contributing to Open Source: An interesting and funny insight into Koz's life as a Rails maintainer, along with some advice about contributing effectively. In particular: your contributions to Rails (or OSS in general) should be a by-product of your work.

There's also a complete list of talks and slides available.

For just a couple of days, there's a lot of good learning and inspiration. Andy Croll has put together a remarkable event and deserves many thanks. I'm looking forward to heading back next year.

Permalink

Wrapping Rack Middleware to Exclude Certain URLs (For Rails Streaming Responses)

Tim Riley — Mon, 21 May 2012 02:35:00 +0000

Another one of the tweaks I had to make to accomodate Rails streaming responses was ensuring that the Rack::Deflater middleware didn't run on my app's streaming actions.

The Deflater middleware gzips your responses before delivering them to the client. This is useful to run on the Heroku Cedar stack because this facility is otherwise not provided. There's a big gotcha, though: the middleware breaks Rails HTTP streaming responses. There's a good explanation of this on StackOverflow, as well as a monkey patch to ActionController::Streaming that corrects the behaviour.

I took an alternative, simpler approach. I extended the middleware with support for excluding a URL pattern. This way, I can just disable it on the few actions where I know I am streaming responses. Here's how it looks:

module Rack
  class DeflaterWithExclusions < Deflater
    def initialize(app, options = {})
      @app = app

      @exclude = options[:exclude]
    end

    def call(env)
      if @exclude && @exclude.call(env)
        @app.call(env)
      else
        super(env)
      end
    end
  end
end

And here's how the extended middleware is included, in config.ru:

use Rack::DeflaterWithExclusions, :exclude => proc { |env|
  env['PATH_INFO'] == '/order/purchase'
}

Using an executable proc for the :exclude argument is useful because it then allows for far more sophisticated URL matching than simple string equality (in production, I actually check against a couple of regular expressions).

Wrapping the middleware in this way has worked well. We get to keep it for the bulk of the app, where it's useful, without it interfering with the parts that are more touchy. It would be nice to see this kind of :exclude option handling become more common among Rack middlewares.

Permalink

The Plight of Pinocchio: JavaScript's quest to become a real language

Tim Riley — Wed, 16 May 2012 22:30:00 +0000

Brandon Keepers at JSDay:

JavaScript is no longer a toy language. Many of our applications can’t function without it. If we are going to use JavaScript to do real things, we need to treat it like a real language, adopting the same practices we use with real languages.

I'll admit that I still write a lot of JavaScript in toy-like style. Brandon's presentation is both motivating and informative for anyone wanting to improve their use of JavaScript.

Permalink

Heroku's new $50 per month production database

Tim Riley — Tue, 08 May 2012 23:55:00 +0000

With a $150 per month reduction in the minimum dedicated database price, Heroku suddenly becomes viable for many more of our apps.

Permalink