I like jQuery Mobile’s page loading spinner. When you transition between pages it displays a nice subtle spinner while the page loads, only if the page load takes more than a configured number of milliseconds.

So, I wanted to use their page-loading spinner for in-page wait times in my app. The user clicks something, I do some AJAX stuff and show them a nice spinner with a message telling them what’s going on until the results come back. jQuery Mobile has javascript functions for this called $.mobile.showPageLoadingMsg and $.hidePageLoadingMsg. The problem is, you can either show a spinner only, or a text-message only. You can’t show both a spinner and a text message, even though they clearly support it. Well, you can do that if you have the global setting $.mobile.loadingMessageTextVisible = true, but then you get a text with your normal page-load spinners.

Using Rails 3.2 (or 3.1 for that matter), you typically have CoffeeScript (and a javascript engine like therubyracer/V8) installed as gems - probably via Bundler from your Gemfile, possibly in a per-project RVM gemset.

It doesn’t seem that this type of setup includes direct access to the coffee command-line compiler. Instead the coffee-script gem uses calls directly to the compiler. Sometimes I’d just like to compile one of the CoffeeScript files in my Rails app just to look at the javascript, or maybe to export it somewhere that I’m not using CoffeeScript.

To do this, I’ve made a simple Rake task. Just drop this into lib/tasks/coffee.rake in your Rails project:

1
2
3
4
5
6

namespace :coffee do
  task :compile, :filename do |t, args|
    filename = args.filename
    puts CoffeeScript.compile(File.open(filename))
  end
end

Then, you can compile a single file from like this:

1

$ rake coffee:compile[app/assets/javascripts/mystuff.js.coffee]

This will output it to stdout so you can redirect that to a file, or the gist command, or whatever.

When using jQuery Mobile, if you try to reload the current page from javascript using the usual tactics of assigning window.location.href, you might notice some unsightly artifacts and page blinking. This is particularly noticeable on iOS Mobile Safari (mainly on iPhone), because the reload also causes the address bar to slide down and back up.

Below is function I made to refresh the current page successfully with no visible artifacts: no blinking, no address bar showing, transitions:

1
2
3
4
5
6
7
8
9
10
11

function refreshPage() {
  $.mobile.changePage(
    window.location.href,
    {
      allowSamePageTransition : true,
      transition              : 'none',
      showLoadMsg             : false,
      reloadPage              : true
    }
  );
}

This was done on jQuery Mobile 1.1.0.

Starting with verison 1.1.0RC1, jQuery Mobile changes the href of any link to be # when it is clicked, but only on iOS Mobile Safari. If you try to make a click handler that reads the href attribute, you will be surprised to find that it does not get the href you intended. For example:

1
2
3

$('a').click(function() {
  console.log($(this).attr('href'));
});

When using jQuery Mobile, this code will print out the href you expect on every browser except Mobile Safari on iOS (both real devices and simulators, but not with other browsers faking their User-Agent). On Mobile Safari, this will print out that the href is “#”.

The Problem

Obviously this is a problem if you have code that operates in a click handler that reads the clicked element’s href attribute. jQuery Mobile changes that href before you get a chance to read it.

One common place this is used is with the link_to helper in Ruby on Rails, for links that need to use other HTTP methods. For example, the standard RESTful way to delete a resource will be with a link that sets :method to :delete. Rails handles this with a library called jQuery UJS that needs to read the href from the link when it is clicked.

Unfortunately for Rails users, this means that Rails method links don’t work with jQuery Mobile on iOS Mobile Safari.

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

SSH_USER = 'root'
SSH_HOST = 'www.example.com'
SSH_DIR  = '/var/www/html/www.example.com'

desc "Build the website from source"
task :build do
  puts "## Building website"
  status = system("middleman build --clean")
  puts status ? "OK" : "FAILED"
end

desc "Run the preview server at http://localhost:4567"
task :preview do
  system("middleman server")
end

desc "Deploy website via rsync"
task :deploy do
  puts "## Deploying website via rsync to #{SSH_HOST}"
  status = system("rsync -avze 'ssh' --delete build/ #{SSH_USER}@#{SSH_HOST}:#{SSH_DIR}")
  puts status ? "OK" : "FAILED"
end

desc "Build and deploy website"
task :gen_deploy => [:build, :deploy] do
end

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.