Rails 4.1: Database URLs

Tuesday, 29 April 2014

DHH mentioned in the Rails 4.1 announcement blog post that it now supports configuration of database connetions through URLs. I couldn’t find any documentation for the feature so here’s how it works.

Your config/database.yml can now go from something like this:

  adapter: postgresql
  database: app_development
  host: localhost

To this:

development: "postgresql://localhost/app_development"

You can also specifiy the database URL as an environment variable when running your app, for example:

DATABASE_URL=postgresql://localhost/app_development bundle exec rails s

Unfortunately you can only override an existing config with an env var if you use the original (non url based) syntax in your database.yml file.

Configuration via env var is very useful in production environments where service discovery is used and saves having to rewriting the database.yml each time just to point at a different database.

Heroku: Your account vavramuk@gmail.com does not have access to appname

Tuesday, 29 April 2014

Encountered this error while trying to deploy an app to Heroku today.

!  Your account vavramuk@gmail.com does not have access to appname.
 !  SSH Key Fingerprint: aa:bb:aa:bb:aa:bb:aa:bb:aa:bb:aa:bb:aa:bb:aa:bb

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I thought I had been hacked but “vavramuk@gmail.com” is actually the default public key for Vagrant, which I had been using earlier. To solve the problem run:

ssh-add -D

And try to push again.

Via @dmathieu

Running Faye on Port 80 via Nginx

Tuesday, 18 February 2014

I have found on restricted networks it’s tricky to get faye running using it’s default settings. Faye normally runs on port 9292 which is blocked on many firewalls. To get around this I configured an Nginx proxy to sit in front of the main web app and the faye process and route all requests to the correct service. This means all traffic can be served over port 80 or 443 if you’re using SSL.

This is an example of the configuration I used.

server {
  listen      80;
  server_name app;
  root        /srv/app/current/public;

  location ^~ /faye {
    proxy_redirect     off;
    proxy_set_header   Upgrade    $http_upgrade;
    proxy_set_header   Connection "upgrade";
    proxy_http_version 1.1;
    proxy_buffering    off;
    proxy_cache_bypass $http_pragma $http_authorization;
    proxy_no_cache     $http_pragma $http_authorization;

Guardian Filtered Feed

Sunday, 17 February 2013

UPDATE This stopped working because the feed format changed several times. I also no longer subscribe to the feed.

I forgot to make this project public when I created it for myself and started using it a couple of years ago.

I put together a filtered version of the Guardian’s RSS feed which is more to my tastes. It removes sports news, podcasts and other non news items that appear in the feed. It also inserts images seen at the top of stories on the website, which for some reason are removed from the official feed. It’s also in atom format but that’s more a side effect of atom being simpler to generate in rails.

It has been working fine with Google Reader for a number of years now, maybe someone else will find it useful too.

Far Cry 3 on MacBook Pro with Retina Fix

Tuesday, 04 December 2012

This works for me when booting into Windows 7.

  • Navigate to your Far Cry 3 installation folder, usually c:\Program Files (x86)\Ubisoft\FarCry3 (or wherever Steam is installed).
  • Go into the bin folder.
  • Right click on farcry3_d3d11.
  • Click Compatibiliy
  • Check “Disable display scaling on high DPI settings”
  • Apply
  • Play the game.

Fixes the flickering black screen problem when first loading and allows the game to run in fullscreen mode.

Gibdo - My HTML5 Game Engine In CoffeeScript

Monday, 05 March 2012

Recently, inspired by the work of Notch and Bret Victor, I have been doing a little more game programming in my spare time. The only game development I had done previously was in C/C++ and I found it just didn’t have the tight feedback loop that both Notch and Bret demonstrate so well when they code. As I didn’t feel like firing up Eclipse and going down the Java rabbit hole with Notch I decided to take Bret’s approach and work on an HTML5 Canvas game.

What I have been able to put together so far is called Gibdo - a top-down 2D game starting point featuring,

  • A scrolling view window that tracks the player across the game world.
  • View limit detection to allow the player to move off the centre of the screen as the edges of the game world are reached.
  • Sprite collision detection.
  • Keyboard input.
  • Sprite animation and sprite swapping based on the player’s direction.

Screenshot right

It’s all written in CoffeeScript which has been a great fit for working on a game due to it’s clean handling of JavaScript’s prototypal inheritance. You need only compare it to the compiled JavaScript to realise how much easier it is to reason about the CoffeeScript code.

I have also take then time to fully document the code using Docco. You can find the annotated source here which I highly recommend checking out to see how it works.

It’s obviously not a full game but I feel it’s a good starting point to build off. In the future I would like to add,

  • Multiplayer support (maybe using pusher).
  • Tile based world generation.
  • Game mechanics such as combat, levels, etc.
  • Sound effects.
  • Massively Improved sprites (a pixel artist I am not).

You can try it out in your browser right here. Feel free to submit pull requests on GitHub if you would like to add any new features.

Backbone.js vs Ember.js

Wednesday, 11 January 2012

In the last few years a trend in web development has been gathering pace. It used to be the case that we could write all of our views and templates on the server side to rendered by a web framework. Now if you want to build a modern web app you need to be comfortable putting the bulk of that logic on the client side.


Up until very recently I had been using Backbone.js to do that. Backbone is a great way to provide structure to your client side Javascript and provides MVC tools including routing and data syncing. Due to it’s stellar documentation and wealth of examples it was the obvious choice for many developers and gained a ton of traction.

But there was always a key problem with Backbone. I felt like I was writing lots and lots of code just to do very standard interfaces. This is mainly because Backbone gives a lot of freedom in how you choose to render templates and handle events. As I got more familiar with it I realised there was scope for a meta framework that could sit on top of Backbone and perform a lot of the heavy lifting for the developer. Of course this never happened, but Ember.js did appear!


Ember.js is a new framework that specifically addresses the problems I encountered with Backbone development. Instead of manually wiring everything together you can, for example, point a view at an array and it will automatically rerendered as the array is manipulated. This is because of Ember’s brilliant binding system and tight integration with the Handlebars.js templating language.

It was such a smart move for the Ember team to rebrand the framework (it used to be called SproutCore 2.0) as it grabbed my attention and I understood the angle they were coming from immediately.

The biggest problem facing Ember right now is documentation. I found it very difficult to discover the best practices and techniques so that I wasn’t fighting against the framework. I found the most success by reading through the Ember source, the unit tests and hanging out in the IRC channel. If more example applications were available to read through this problem could be solved.

I have also found other areas of the framework slightly lacking - specifically routing and persistence where I feel Backbone is more mature. The good news is that since I started using Ember last month a ton of work has gone in to both areas resulting in ember-states and Ember Data which are great steps towards addressing these holes.

Am I Sticking With Ember?

Yes, although it’s a little rough around the edges the core idea is solid and Ember is getting better on a daily basis. It’s probably not a good fit if you need to both learn client side MVC and release an app pretty soon but it’s just a matter of time before documentation and more example apps are released. If you are familiar with Backbone or another framework give it a try and see if it cuts down the amount of boilerplate you need.

Confident Code

Saturday, 17 September 2011

This talk from Avdi Grimm is essential viewing for Rubyists or just OO programmers in general. He has some very clever techniques for avoiding nil at all costs which can be easily added to your own development arsenal.

Warning - if you watch this you will find it even more frustrating to read through poorly written libraries.

Bored People Quit

Monday, 18 July 2011

I was going to write a post on this topic but Rands summarised it so perfectly in this must read article. I’ve picked out some quotes that really hit home to me.

On the warning signs,

A decrease in productivity is a great early sign that something’s up, but what you are looking for is any change in their routine. Increased snark? Unexpected vacations? Later arrivals? Earlier departures? Anything that strikes you as out of the ordinary for someone whose day you are familiar with is worth considering.

On “urgent” tasks,

Get this urgent, unplanned task done or make progress on the unmeasurable? The only thing this decision teaches your team is how little you value the cultivation of your people.

On developer flow,

…it’s your job to remember that productivity costs surrounding these micro-tasks aren’t just the 30 minutes necessary to get them done, it’s the context-switching tax involved in stopping their work, preparing for the task, doing the task, and then rebuilding the context regarding the work that floats their boat … progress is not measured in interrupt-driven minutes, it’s blocks of delicious, uninterrupted hours.

Right on the money.

Splitstate 2.0 - MongoDB, DelayedJob Edition

Saturday, 07 May 2011

Splitstate.com is the gaming news service that I launched in 2009 and announced here a few weeks later. By using a combination of Ruby and CouchDB I was able to provide a stable and reliable service for over a year with very few tweaks needed. Just looking back at the git log and the server uptime I can see there was a period last year where no work was done on the site for 8 months while I and others were happily using the service everyday.

But all good things must come to an end - a few months ago requests started encountering long slow downs and the application would crash several time a day. It was due to a number of reasons but the main issue affecting performance was the database growing to 3GB and the app not being designed to handle such a large dataset. Partially my fault and partially a fault of the tools I was using I decided to rebuild splitstate once more - harder, better, faster, stronger!

The Database

I love CouchDB, I think it’s a fantastic database and it’s a great way to build web services and self contained data driven applications. What hasn’t been so great about using CouchDB is the driver and ODM support. The best way I found to work with it was to write map reduce functions right on the database - not the Rails way at all.

In my day to day work and on other projects I have been using MongoDB a lot more where the ODM support is just stellar. You really can’t go wrong with either MongoMapper or Mongoid as they both have active communities around them and continue to be updated to work with the latest versions of MongoDB and Rails. I went with Mongoid because I’m more familiar with it.

Background Processing

Last time I chose ruby daemons for processing all the feeds and links that need to be sifted through which has turned out to be a very primitive and non-scalable option. Luckily job queues and background processing options have come a long way since then! I chose DelayedJob because it integrates well with Mongoid and Heroku supports it with no configuration needed.

The Code

I took a much more modular approach when writing the code this time and was able to learn from the mistakes I made last time. Lots of small methods and anything that needed to hit a remote server I encapsulated as a delayed job. Switching to Mongo allowed me to keep more of the story selection logic in Ruby where it should be so I could throughly test it. I’m much happier with the code now - it’s cleaner, leaner and more maintainable than before.


I did rant about Heroku in my last post but it really is the easiest way to host a rails application. Splitstate 1.0 was running on Linode who are an excellent VPS provider but these days I need something a little more managed so I can just focus on the code. I don’t want to worry about installing packages on the server and heroku’s git based deployment makes it hard to use anything else.

This Is Not The End

The hard work is done, it’s running on production and finding loads of interesting news stories. Of course I would like to do more with splitstate and now it’s running nicely I can build on this a deliver new features and potentially even new sites!