Rails on Maui

Programming in Paradise

Upgrading Octopress

One of the criticisms of Octopress is how there’s no clear separation of the static generation engine and the content of one’s website, and thus upgrading Octopress is difficult. I delayed upgrading due to this. However, my concerns were unfounded, as it was very painless to upgrade Octopress.

The instructions boil down to this short help page on Updating Octopress: 

1
2
3
4

git pull octopress master     # Get the latest Octopress
bundle install                # Keep gems updated
rake update_source            # update the template's source
rake update_style             # update the template's style

The first step resulted in a few merge conflicts. I find RubyMine’s git conflict resolution tools helpful, so I used those. Here’s a short screencast (embedded below) showing you how these tools helped with this process. Besides some minor issues dealing with a few merge conflicts, there was nothing very interesting or eventful about the upgrade, which means that the current process is really quite OK.

Migrating From Capybara-Webkit to Poltergeist-PhantomJs

Motivation

Today I migrated a medium size test suite from capybara-webkit to Poltergeist with PhantomJS. I had two main motivations for switching:

  1. PhantomJS is more sensitive to avoiding false positives. For example, in the past, one could click on non-visible DOM elements with capybara-webkit. While this may not currently be true with the latest Capybara, I’ve had good luck with PhantomJS in the past.
  2. Speed. When I last checked, PhantomJS was faster. Speed is critical for slow feature tests.

Here’s one reason that Poltergeist is more accurate and sensitive to failure:

When Poltergeist clicks on an element, rather than generating a DOM click event, it actually generates a “proper” click. This is much closer to what happens when a real user clicks on the page - but it means that Poltergeist must scroll the page to where the element is, and work out the correct co-ordinates to click. If the element is covered up by another element, the click will fail (this is a good thing - because your user won’t be able to click a covered up element either).

Ember.js Tutorial With Rails 4

The first post in this series, Ember.js Hello World, shows Ember working without a persistence backend. This post covers setting up Rails4 as the persistence engine behind that example, plus adding and deleting records. The amount of Ember and Rails code to make this example is almost completely included in this article. It’s that tiny!

The source code for the completed example can be found on GitHub: justin808/ember-js-guides-railsonmaui-rails4. I carefully crafted the commits to explain the steps.

You can try out the application on Heroku at: http://railsonmaui-emberjs-rails4.herokuapp.com/

I put many more details in this comprehensive screencast of how to go from a brand new Rails 4 app to an Ember.js app deployed on Heroku.

Key Tips

  1. Be sure to update the ember and ember-data javascript files with the command from the ember-rails gem (see below). Keeping these files at appropriate versions is key while the API is changing, especially for ember-data.
  2. If you specify the Router property for both model and setupController, you can have some very confusing results (details below).
  3. Get comfortable with Ember’s naming conventions. Ember does a ton with default naming. It’s basically got the same philosophy of “Convention over Configuration” of Rails. So it’s especially important to try to grok when the Ember examples are doing something implicitly versus explicitly. This is a bit like Rails. At first it seems like magic, like “How the heck is that happening”, and then one gets accustomed to the naming conventions and appreciates how much code it saves.
  4. Be mindful that some Ember.js commands run asynchronously, such as commit.

CoffeeScript Chrome Extensions

Here’s 3 useful tools for using CoffeeScript for web development, possibly with Rails and EmberJs. All 3 tools are useful for different purposes.

CoffeeScript Source Maps: Debugging CoffeeScript Directly

With Source Maps, you don’t have to mentally convert your CoffeeScript code into JavaScript code in the debugger. Instead, you can now see your CoffeeScript code, even with correct line numbers. This rails gem, coffee-rails-source-maps, makes it easy to include CoffeeScript source maps as part of your rails application. Note, the Rails.env.development? is hard coded, so this only works when you use that specific environment. You can also do it manually, by using the -m flag with the coffee command.