I am pleased to announce that I have found my new home. As of next week, I’ll be starting my new position as the VP of Engineering at Validas.

Over the last two months, I’ve networked with a lot of great people and have considered opportunties at many great companies. There are so many exciting things going on in our industry, that this was not an easy decision. After taking some time to reflect, the opportunity at Validas stood out above the rest for a number of reasons.

Express Resource adds RESTful resource routing on top of the Express framework for Node.js. It includes a nice feature called “Auto-Loading” that allows you to define a single load method that will automatically be used to load your resource object from a URL id parameter and set it in the request object to be accessed by your conventional RESTful methods that need it. Another great feature of Express Resource is what they call “Content-Negotiation”. URLs with format extensions like .xml or .json automatically set an indicator of the format in the request so your actions can respond accordingly.

However, a problem arises when you use the recommended method for handling and reporting errors from within your load method: You get no control over how the errors are handled, and the default mechanism is ignorant of the requested format. This makes it tough to return nice JSON errors, for example, from a REST API that uses this technique.

Last week I resigned my position as CTO at Balassanian Enterprises.

Those of you who know me know that this is huge. I’ve been working closely with the founder, Edward Balassanian, for a long time. It’s been spread over multiple companies and an array of varying products, but it’s always been a shared ethos with the same core group of people that has defined that period of my career. Leaving that behind feels a bit like an emotional breakup. Such a big part of my professional and personal identity was wrapped up in how we worked together, what we built, where we’ve been, and our vision of the future. We put everything into it.

It’s also a bit like leaving home to explore new worlds.

I started tinkering with Middleman the other day to build a small static website.

In the past, I’ve used StaticMatic, Jekyll, or Octopress for this sort of thing. Jekyll and Octopress are great for blogs. StaticMatic is great for prototyping a static site with Haml and Sass that you can easily migrate to your Rails app.

I’ve been using Middleman for less than 24 hours at this point, but so far it seems great. One of the things I like about it is that it’s actually serving your site dynamically with Sinatra, and comes out of the box with Haml, Sass, Compass, view helpers, lorem ipsum generators, CSS and Javascript minification, and more. Plus, you can throw in any other Rack middleware you like, for example, the Google Analytics middleware. While you’re developing the site, you run the preview server and your changes are immediately visible without restarting it. The cool part is that when you deploy, it actually generates all the static pages by executing the Rack server and running requests through it. This means any custom middleware you add to the stack gets invoked for all the pages it generates.

Middleman imposes very little structure. This is refreshing if you’re just making a one- or two-page site. It lets you get started right away and build whatever organization you want for yourself. It doesn’t tell you how to deploy your site. That’s I’m here to do. :)

I took a little inspiration from Octopress’s Rakefile and put together a simple Rakefile for use with Middleman that helps you deploy your static site via rsync. It also adds a few little wrapper tasks for things like remembering to add the --clean flag, and an Octopress-like rake gen_deploy task that regenerates and deploys in one step.

1
2
3
4
5

$ rake -T
rake build       # Build the website from source
rake deploy      # Deploy website via rsync
rake gen_deploy  # Build and deploy website
rake preview     # Run the preview server at http://localhost:4567

Simply drop this Rakefile into the root of your Middleman project and edit the SSH variables at the top.

Having a mobile version of your website is a pretty common thing these days. Doing it with Ruby on Rails seems pretty common as well. Yet there seems to be a lot of misguidance on the web when you search google for advice on making mobile sites in Rails. There are two prevailing suggestions for accomplishing this that I think are undesirable. I’ve come up with another variation on this that I think is more maintainable and better for the end user.

But first…some background…

TL;DR: Don’t use custom MIME formats or domain redirects. Use custom view paths. Skip to “The Final Solution” at the bottom, if you don’t care why.

IE9 doesn’t support the placeholder attribute on input elements. Why does this matter for a jQuery Mobile site? If you want to build a single mobile-first page with jQuery Mobile, and use resposive design techiniques to display the same page on desktop browsers, you might appreciate the ability to use the HTML5 placeholder in your design, and still need to support at least IE9.

Using a placeholder on an input field is a nice way to save space on a mobile form. It lets you forgo the field labels while still telling the user what the fields are for. In many cases its utility goes beyond labeling; you might need it to express input requirements such as what unit of measurement to use in a “distance” field. This is just as useful in a desktop design as it is in a mobile design.

There is a growing movement of creating polyfills for this sort of thing - especially targeted at Internet Explorer. If you’re not already using something like Modernizr to fulfill all your HTML5 polyfill needs, and just want a solution for the placeholder attribute, you’re in luck. The Modernizr wiki has a list of polyfills. You’ll see that there are quite a few placeholder polyfills…but they are not all created equal.

Rails UJS and jQuery Mobile do not play nice together when it comes to combining Rails UJS’s handling of non-GET/POST links with jQuery Mobile’s data attributes such as data-ajax, data-direction, and data-transition. This post demonstrates a quick hack you can use to remedy this.

Imagine a series of pages with simple forms on each of them. With jQuery Mobile, you’ll usually end up transitioning between these pages using AJAX and nice slide transitions. Since all your forms will end up in the same document, you need to be careful to give them unique IDs if you want to access them from javascript.

One thing I like to do with forms, especially on mobile platforms, is to automatically highlight the first field in the form when it comes in to view. The trick with jQuery Mobile is that with AJAX loading, pre-loading, and BACK/FORWARD buttons, you need to figure out which form is currently in view, and when transitions between forms happen.

Fortunately jQuery Mobile provides us the two facilities we need:

• The ui-page-active CSS class gets applied to the .page element that is currently in view.
• The pageshow event gets triggered on the document when a page transition has completed to change which page is in view.

Combine these two, and you can do something like this in your main javascript once for the whole document:

1
2
3

$(document).bind('pageshow', function() {
    $($('.page.ui-page-active form :input:visible')[0]).focus();
});

Now, after every page transition, if there is a form on the newly-visible page, the first visible input element automatically receives focus. This works across AJAX, non-AJAX, and BACK/FORWARD page transitions.

Six months ago, I wrote a quick blog post about adding custom filters to stock Devise controllers without subclassing all the Devise controllers. At the end of the post I noted that the prescribed method only worked in the production environment, and not in development.

Today I come to you with a solution that works in development as well as production. The basic mechanics are the same, but we’ll factor it slightly differently.

First, we’ll create a module in config/initializers/devise_filters.rb where we’ll implement a method to add all the filters to Devise that we want. We also need to make sure this module calls this method upon initialization so that our filters get added upon startup (important for the production environment).

At this point, we’re in the same place we left off back in August: we can add filters to Devise controller actions, but in development mode the second request reloads all the Devise classes and all our filters are gone.

To address this, we need to add a bit of code to the end of the initializer block in config/environments/development.rb like so:

1
2
3
4
5
6
7
8

MyApp::Application.configure do
  # ...the usual stuff ...

  # Stuff to do on each request
  config.to_prepare do
    DeviseFilters.add_filters
  end
end

This tells Rails to call your DeviseFilters.add_filters method before each new request in development mode, after the classes have been reloaded.

There may come a time that you wish to programatically get a list of what before_filters, after_filters, and around_filters are set on a given controller class in Rails. In Rails 2, there was a filter_chain method on ActionController::Base that you could use to do this. That method is gone in Rails 3 in favor of something much more magical.

One reason for wanting to do this is simply for debugging. Sometimes you just need to sanity check that filters are being applied in the order you think they are. Especially when they’re being added dynamically by various plugins.

In Rails 3, I find it convenient to add a few utility methods to ApplicationController that list out the symbol names of all the filters on any given controller:

With that in hand, you can do something like this:

1
2
3
4
5
6
7
8
9
10
11

ree-1.8.7-2011.03 :002 > ap PostsController.before_filters
[
    [0] :verify_authenticity_token,
    [1] "_callback_before_1",
    [2] :set_geokit_domain,
    [3] :block_internet_explorer,
    [4] :add_authenticity_token,
    [5] :always_mobile,
    [6] :find_post,
    [7] :set_meta_tags
]