1
2
3
4

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  force_ssl
end

However…when you deploy this to Amazon EC2 behind an ELB (Elastic Load Balancer), you can run into problems.

Problem: ELB Health Check vs Rails force_ssl

Even if you have your ELB configured with your SSL certificate and you have it proxying port 443 to port 80 on your Rails app, you may still have trouble getting the ELB to accept your instance as an upstream server if it cannot get an HTTP 200 OK from the health check action.

Once you have your Rails app using a global force_ssl, the ELB HealthCheck will hit your server over HTTP (because you don’t actually have your Rails server setup as an SSL endpoint), and your server will return it a 301 redirect. This causes the ELB to think your instance is unhealthy and won’t proxy any requests to it.

Solution: Custom HTTP-able Health Check Action

I’ve found the easiest way to deal with this is to create a special action that you use for the health check, and override the force_ssl for that action. Unfortunately, the stock implementation of ActionController::Base.force_ssl, when applied globally in the ApplicationController, does not allow other controllers to override that setting. That means we have to tackle this in two steps.

First, re-implement the force_ssl method to allow controllers to override it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  def self.force_ssl(options = {})
    host = options.delete(:host)
    before_filter(options) do
      if !request.ssl? && !Rails.env.development? && !(respond_to?(:allow_http?) && allow_http?)
        redirect_options = {:protocol => 'https://', :status => :moved_permanently}
        redirect_options.merge!(:host => host) if host
        redirect_options.merge!(:params => request.query_parameters)
        redirect_to redirect_options
      end
    end
  end

  force_ssl
end

The above is a direct copy of this method from Rails 3.2, with the additional clause: && !(respond_to?(:allow_http?) && allow_http?). That clause allows any controller to implement an allow_http? method, which is executed in the context of a request’s before_filter. If this method exists and returns true for a given request, then it will be allowed to continue over HTTP without being redirected to HTTPS.

For the second part, we need to create an unprotected action that can be used for the health check. The easiest way to do this is with a new controller (and matching route, if necessary):

1
2
3
4
5
6
7
8
9
10
11

# app/controllers/heath_check_controller.rb
class HealthCheckController < ApplicationController
  def index
    render :text => "I am alive!\n"
  end

  protected
  def allow_http?
    true
  end
end

1
2
3
4
5

# config/routes.rb
MyApp::Application.routes.draw do
  get "health_check" => "health_check#index"
  # ...
end

Now, all you need to do is change your ELB Health Check to use /health_check instead of /index.html. This way the ELB will check that your Rails app is responding using HTTP (since that is the appropriate protocol between the ELB and Rails if you are using the ELB as your SSL endpoint). Your instance will register as healthy as long as your Rails app is up, and Rails will redirect all other HTTP traffic to HTTPS.

You can read a nice explanation of this attack, and how HSTS helps to prevent it here.

The wikipedia page on HSTS provides some examples on how to enable this in your web server (apache, nginx, etc). However, when running behind an ELB in Amazon Web Services, where you cannot configure this at the reverse proxy, you may wish to do this in your application.

Here is how to achieve that in Ruby on Rails, using a before_filter in your base ApplicationController:

1
2
3
4
5
6
7
8

class ApplicationController < ActionController::Base
  before_filter :strict_transport_security
  def strict_transport_security
    if request.ssl?
      response.headers['Strict-Transport-Security'] = "max-age=31536000; includeSubDomains"
    end
  end
end

This is, of course, great news for the company, but it also sparks some interesting discussions about metrics. After a few conversations with some colleagues of mine about statistics, metrics, and analytics, I thought I’d dig up some good articles to summarize some of the key Lean Startup principles surrounding metrics and data-driven decision-making for those who haven’t had the pleasure of reading Eric Reis’s book Lean Startup. That turned into a writeup about what metrics we are reporting internally, and why we focus on Actionable Metrics over Vanity Metrics. I figured I’d share some of that as a blog post here as well.

My goal is to provide a little background on Actionable Metrics and how they differ from Vanity Metrics. Understanding this is a central theme of the book Lean Startup, by Eric Reis, and the writings and teachings of a number of other prominent startup/entrepreneur/lean proponents such as Steve Blank, Dave McClure, and Ash Maurya. Fred Wilson of Union Square Ventures, has been quoted saying, “one of our firm’s favorite measurements is the cohort analysis”.

Three Links You Should Read

1. 3 Rules To Actionable Metrics - Ash Maurya

In this post, Ash Maurya, author of Running Lean and creator of Lean Canvas starts right out with the definitions of Actionable Metrics and Vanity Metrics. The key summary being:

Actionable Metric: ties specific and repeatable actions to observed results

Vanity Metric: only serves to document the current state of the product but offers no insight into how we got here or what to do next.

In the Tracking Long LifeCycle Events section of this post, where Maurya talks about cohort analysis, his recommendation is that the first report you implement – the canary in the coal mine – is exactly the kind of reporting we put first on our internal statistics console:

The first report I recommend implementing is a “Weekly Cohort Report by Join Date”. This report functions like a canary in the coal mine and is a great alerting tool for picking up on actions that had overall positive or negative impact.

2. Track What Matters With Cohort Analysis - Martin Thomas

This is a nice short blog post, by Martin Thomas, founder of Purlem, about using cohort analysis with a simple real-world example. Importantly, he calls out the definition of a cohort:

A cohort is a group of people who share a common characteristic or experience within a defined period

Note the focus on measuring “within a defined period”. As with Maurya’s post, his example is to group cohorts by signup date (exactly what we’re doing), and then track what those cohorts have as their initial experience (his is over a month, ours is currently over a 24-hour period – we really want to measure that “Day One Aha!” experience). He quotes Eric Reis on the issue of using vanity metrics:

Before using cohort analysis, I was tracking the cumulative number of paying users. Eric Reis calls this vanity metrics as they give the “rosiest possible picture” of a startup’s progress, but does not track how people are actually interacting with the application.

At the end of the day, using cohort analysis helps you to track the numbers that matter to the progress of your company.

3. Lean Startup Metrics & Analytics - Nocola Junior Vitto

This is a great slide deck about metrics and analytics in a startup. It’s a bit long but I think it is worth looking at the slides and understanding them. If you don’t go through them all, at least check out what I consider to be the highlights:

• Slides 4-8: The perfect picture of vanity metrics. I love that Slide 7 calls Google Analytics Realtime Overview a “drug that can kill you”. So true.

• Slides 14-15: Good definitions of actionable metrics

• Slide 28: Nice visualization of the conversion funnel

• Slide 33: Good progression of online marketing. We need to work toward getting solidly into the 3rd Generation territory.

• Slides 49-56: Good summary of metrics surrounding user acquisition. This is exactly why I’ve been so adamant about getting the people sharing links to use tracking codes properly: “Use unique urls (tracking parameters) on every url you create/give-out/pay for”

• Slides 71-77: Good overview of the “Viral Coefficient”. In our app we track this using AddThis analytics (which is one of the reasons we chose to use AddThis instead of custom Facebook integration)

• Slides 78-81: Good overview of the “Net Promoter Score” (NPS). We intend to measure this using Qualaroo (formerly KISSinsights), but we are not doing that yet.

• Slide 98: I love this slide – it applies the “OODA Loop” to the Lean Startup. The OODA Loop is a term uses in martial arts, combatics, military, and law-enforcement. It stands for Observe, Orient, Decide, Act. Then repeat. Eric Reis talks about the “Build-Measure-Learn” cycle. They really are the same thing. I love the idea of applying the OODA Loop to startups because it imbues a sense of urgency. This slide has a nice picture merging the two.

• Slides 99-100: Innovation Accounting. I’d call it a wake-up-call. “Everything you do should attempt to change a metric”. I.e.: anything we are not doing that is not specifically aimed at changing an actionable metric is something we need to stop doing.

• Slide 106: Kanban board. Looks like our Trello board!

• has a basic working knowledge of Opscode Chef
• is using Hosted Chef
• already has a working chef-repo workstation with knife configured
• already has (or can figure out) knife-ec2 installed and configured with AWS API credentials
• is on their own for creating actual cookbooks and roles to configure their Windows instances

This is fairly easy to do with Linux instances. Using knife ec2 server create and a bunch of parameters, a single command provisions a new Linux instance in EC2, waits for it to come up, connects to it over SSH using the specified key pair, installs chef-client, and bootstraps the node using the specified run_list. Done.

However, things are not so simple for Windows Server instances.

Working with Windows instances in EC2 using Chef presents a few hurdles:

• Windows doesn’t natively support SSH.
• The knife ec2 server create command waits for the instance to accept SSH connections. There is no option to circumvent this.
• Windows takes forever to provision.
• Windows instances typically get a random Administrator password generated for them that takes over 15 minutes to retrieve.
• The knife-windows gem provides a knife bootstrap windows winrm command that can bootstrap an existing Windows instance with Chef, but cannot provision a new instance.
• The knife bootstrap windows winrm command requires WinRM to be configured on the instance (which it isn’t be default), requires the Administrator password of the instnace (which defaults to a random value), and requires the public IP address of the instance (which we don’t know until the instance is up).

Below I’ll provide a simplified example script that demonstrates how we can hack together a few techniques to create an all-in-one solution for bringing up new Windows Server nodes in the Amazon cloud. Other than knife and all the other pre-requisites mentioned above, you’ll need to make sure you have the following Ruby gems installed:

1
2

% gem install knife-ec2
% gem install knife-windows

The Tricks

The Ruby script below uses a few nasty tricks to make this all work:

First, we write a temporary “user data” file to pass to the EC2 API. This gets executed by the new instance when it is first provisioned. There are two tricks we need to stick into the user data file:

• A BAT <script> that configures WinRM (Windows Remote Management), which is what we’ll use to connect to and bootstrap the instance.
• A <powershell> script that sets the Administrator password to a value we define. This makes it so we don’t have to wait 15+ minutes for EC2 to generate a password for us, and retrieve it manually through the GUI.

Then, we use knife ec2 server create to provision the Windows instance to specification, passing in that user data file. This works great for provisioning the instance, but since it was not really designed for Windows and WinRM, there are two tricks we have to employ here:

• Execute the knife command in a sub-process and read its STDOUT until we see it output the new instances public IP address. We’ll grab that and save that for the next step.
• This is also our cue to bail out of knife ec2 server create. If you were doing this manually, you’d hit CTRL-C here, which knife is saying “Waiting for sshd” (which is never going to come up). We do that by sending the sub-process a SIGTERM signal.

Now, we can’t just move on to bootstrapping the node, because it is still booting up, and WinRM may not be configured yet. The trick here is to create a TCP socket to the WinRM port, using the IP address we aquired in the previous step, and wait for it to connect. If it fails to connect, try again until it does. By the time this succeeds, we know WinRM is up and accepting connections. However, we don’t know if the rest of the system is ready. Moving on to the next bootstrapping step immediately will run into intermittent errors. I’ve seen this manifest as an authentication erorr, presumably because we tried to bootstrap over WinRM before the PowerShell script set the password. There may be other mysteries of the Windows universe lurking here as well. My solution: sleep for two minutes. Lame, I know…but so far it is the only thing that has reliably worked.

Finally, we can bootstrap the new running Windows instance with the knife bootstrap windows winrm command, using the IP address we acquired, the password we specified in the user data, and the other knife params we want to use such as the run_list and environment.

The Script

Here is a stripped down version of this script demonstrating all these tricks. As you can see, all the custom configuration is hard-coded in constants at the top of the script. You would obviously fill in your own information however you like – via command-line params, interactive prompts, config files, etc.

Big thanks to my colleauge Jeremy Groh who paired through this with me and did the bulk of the heavy lifting on the Windows side, especially with the WinRM and password-reset parts.

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117

#!/usr/bin/env/ruby

require 'socket'

# AWS API Credentials
AWS_ACCESS_KEY_ID     = "your-aws-access-key-id"
AWS_SECRET_ACCESS_KEY = "your-aws-secret-access-key"

# Node details
NODE_NAME         = "webserver-01.example.com"
CHEF_ENVIRONMENT  = "production"
INSTANCE_SIZE     = "m1.large"
EBS_ROOT_VOL_SIZE = 70   # in GB
REGION            = "us-west-2"
AVAILABILITY_ZONE = "us-west-2b"
AMI_NAME          = "ami-46c54c76"
SECURITY_GROUP    = "Web Servers"
RUN_LIST          = "role[base],role[iis]"
USER_DATA_FILE    = "/tmp/userdata.txt"
USERNAME          = "Administrator"
PASSWORD          = "YourAdminPassword"

# Write user data file that sets up WinRM and sets the Administrator password.
File.open(USER_DATA_FILE, "w") do |f|
  f.write <<EOT
<script>
winrm quickconfig -q & winrm set winrm/config/winrs @{MaxMemoryPerShellMB="300"} & winrm set winrm/config @{MaxTimeoutms="1800000"} & winrm set winrm/config/service @{AllowUnencrypted="true"} & winrm set winrm/config/service/auth @{Basic="true"}
</script>
<powershell>
$admin = [adsi]("WinNT://./administrator, user")
$admin.psbase.invoke("SetPassword", "#{PASSWORD}")
</powershell>
EOT
end

# Define the command to provision the instance
provision_cmd = [
  "knife ec2 server create",
  "--aws-access-key-id #{AWS_ACCESS_KEY_ID}",
  "--aws-secret-access-key #{AWS_SECRET_ACCESS_KEY}",
  "--tags 'Name=#{NODE_NAME}'",
  "--environment '#{CHEF_ENVIRONMENT}'",
  "--flavor #{INSTANCE_SIZE}",
  "--ebs-size #{EBS_ROOT_VOL_SIZE}",
  "--region #{REGION}",
  "--availability_zone #{AVAILABILITY_ZONE}",
  "--image #{AMI_NAME}",
  "--groups '#{SECURITY_GROUP}'",
  "--user-data #{USER_DATA_FILE}",
  "--verbose"
].join(" ")

# Run `knife ec2 server create` to provision the new instance and
# read the output until we know it's public IP address. At that point,
# knife is going to wait until the instance responds on the SSH port. Of
# course, being Windows, this will never happen, so we need to go ahead and
# kill knife and then proceed with the rest of this script to wait until
# WinRM is up and we can bootstrap the node with Chef over WinRM.
ip_addr = nil
IO.popen(provision_cmd) do |pipe|
  begin
    while line = pipe.readline
      puts line
      if line =~ /^Public IP Address: (.*)$/
        ip_addr = $1.strip
        Process.kill("TERM", pipe.pid)
        break
      end
    end
  rescue EOFError
    # done
  end
end
if id_addr.nil?
  puts "ERROR: Unable to get new instance's IP address"
  exit -1
end

# Now the new instance is provisioned, but we have no idea when it will
# be ready to go. The first thing we'll do is wait until the WinRM port
# responds to connections.
puts "Waiting for WinRM..."
start_time = Time.now
begin
  s = TCPSocket.new ip_addr, 5985
rescue Errno:ETIMEOUT => e
  puts "Still waiting..."
  retry
end
s.close

# You'd think we'd be good to go now...but NOPE! There is still more Windows
# bootstrap crap going on, and we have no idea what we need to wait on. So,
# in a last-ditch effort to make this all work, we've seen that 120 seconds
# ought to be enough...
wait_time = 120
while wait_time > 0
  puts "Better wait #{wait_time} more seconds..."
  sleep 1
  wait_time -= 1
end
puts "Finally ready to try bootstrapping instance..."

# Define the command to bootstrap the already-provisioned instance with Chef
bootstrap_cmd = [
  "knife bootstrap windows winrm #{ip_addr}",
  "-x #{USERNAME}",
  "-P '#{PASSWORD}'",
  "--environment #{CHEF_ENVIRONMENT}",
  "--node-name #{NODE_NAME}",
  "--run-list #{RUN_LIST}",
  "--verbose"
].join(' ')

# Now we can bootstrap the instance with Chef and the configured run list.
status = system(bootstrap_cmd) ? 0 : -1
exit status

I work in a team that is distributed around the country, where everyone works from their home offices. Sounds great, doesn’t it? Well, it’s not for everyone. First, you have to be seriously self-motivated. Personally, I get more done at home than I ever have at an office, because I get to choose when to be distracted and I’m good at staying focused. For some people, choosing when to be distracted is a curse. They choose to be distracted all the time. Facebook, twitter, bathroom, kitchen, twitter, kids, etc.

Still, some of those home distractions can plague even the most focused of us. One of the keys I’ve found to succesfully working from home is to have a dedicated work space. I am lucky enough to have an extra room to use as an office, and the family knows that when I’m in there, “Daddy’s at work”.

But sometimes that’s not enough…

Get Out

Even when the house is empty, no co-workers are interrupting you, and you have a clear path ahead of you, the familiarity of the home office can be a distraction in itself. Who’s that driving down my street? I should really fix that door. I wonder if there’s anything in the fridge. What time are the wife and kids coming home?

In times like these, I like to just get out and go work from somewhere else.

Everyone has wifi. Go to a coffee shop. Go to a pub. Go to the beach (hurray for MiFi!). Even though there is more noise and more movement, I find that sometimes just varying my surroundings can actually help me to focus. I block out the unfamiliar sounds. I expect the noise so I don’t key in on every little movement. I’ve done some of my best out-of-the-box thinking in these kinds of environemnts.

This actually turns into a great perk of the distrbuted team environment. I can go work from the coffee-shop-with-a-view and it makes no difference to my co-workers. I’m still on Skype and email. I’m still checking in code and answering questions.

Far Far Away

So, if I can work from a coffee shop overlooking Lake Washington…what’s the difference if I make it Lake Chelan? Or Miami Beach for that matter?

In July, I worked for 4 days from a remote part of the Olympic Peninsula. In March, to get away from the terrible Seattle weather, I worked for almost a month from South Florida. Add to that the fact that my team likes to travel to get together, and “work from home” actually becomes “work from everywhere”.

I rather enjoy that lifestyle. The bulk of my time I’m cranking away in my home office where I am extremely productive. But every now and then, at just the right intervals, I go somewhere else to mix it up. I’ve even started collecting photos of all these places. It makes for a fun reminder of one of the reasons why I like this job and working in a distributed team.

Join Me, Won’t You?

And now for the shameless plug. My team at Validas is ready to grow. The beauty of this is that we can recruit from anywhere - no moving expenses. Just a generous budget to deck out your home/mobile setup with the latest tech goodies, paid internet and mobile communications, and away we go.

So, if you’re a seasoned architect/engineer, who fits our job description and wants to thrive in this work/life style, send us your résumé today. We’d love to talk to you!

Here is my scenario: I have two repositories. I want to make a new empty repository and move the other two into it as subdirectories. I also want to preserve all the commit history of the original repositories.

Here are the steps involved for the first repository:

1. Clone the first source repository
2. Remove its origin ref so you dont’ accidentally push any screwups
3. Make a subdir in that source repo named the same as the repo
4. Move all the top-level files into that directory
5. Commit that move.
6. Create (or clone) your desination repository.
7. Add a remote ref to it that points to the file location of your source repo clone.
8. Pull from that ref
9. Remove that remote ref.

You can now delete the clone of the source repository you, so you don’t really keep those file moves around in the original source if you don’t want to.

Here’s what those steps might look like:

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
27
28
29
30
31
32
33

# Step 1
$ git clone SOURCE_REPO_URL
$ cd source_repo_name

# Step 2
$ git remote rm origin

# Step 3
$ mkdir source_repo_name

# Step 4
#
# NOTE: You can't actually do this command verbatim. You need to
#       git mv each top-level file/dir individually and don't forget
#       .* files like .gitignore, but DO NOT copy the .git directory.
$ git mv * source_repo_name/.

# Step 5
$ git commit -m "Prepare source_repo_name to merge into dest_repo_name"
$ cd ..

# Step 6
$ git clone DST_REPO_URL
$ cd dest_repo_name

# Step 7
$ git remote add source_repo_name SRC_REPO_FILEPATH

# Step 8
$ git pull source_repo_name master

# Step 9
$ git remote rm source_repo_name

Now you’re done and can delete the source repository clone, and push the destination repository clone upstream. Check the git log to be sure.

A Concrete Example

Say I have two repositories on github named homer and bart and I want to combine them into a new repository called simpsons. Here is how that looks:

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
27
28
29
30
31
32
33
34
35
36
37

# ...First create a new empty repository on github named 'simpsons'...

# Clone all the repos to work with
$ cd ~/src
$ git clone git@github.com:scottwb/homer.git
$ git clone git@github.com:scottwb/bart.git
$ git clone git@github.com:scottwb/simpsons.git

# Copy over homer to simpsons
$ cd homer
$ git remote rm origin
$ mkdir homer
$ git mv *.* homer/.
$ git commit -m "Prepare homer to merge into simpsons"
$ cd ../simpsons
$ git remote add homer ~/src/homer
$ git pull homer master
$ git remote rm homer
$ cd ..
$ rm -rf homer

# Copy over bart to simpsons
$ cd bart
$ git remote rm origin
$ mkdir bart
$ git mv *.* bart/.
$ git commit -m "Prepare bart to merge into simpsons"
$ cd ../simpsons
$ git remote add bart ~/src/bart
$ git pull bart master
$ git remote rm bart
$ cd ..
$ rm -rf bart

# Push simpsons back upstream to github
$ cd simpsons
$ git push

Bonus Points: Only Moving a Sub-Directory

What if you only want to move a subdirectory of the original source repository into the destination repository? All you need to do is filter out what you copy into that new sub-directory you create in step 4, and make sure everything else gets removed from that source repository. (Don’t worry - remember, you’re just working with a local working copy of that source repo, that you’re going top discard after this operation. You won’t harm anything irreversibly here.)

One way to peform that filtering is by using the git filter-branch command. For example, to only copy the pranks subdir from the bart repo, just before step 4, you would do something like this:

1

$ git filter-branch --subdirectory-filter pranks -- --all

That dumps all the contents of the pranks dir into top-level dir where you can proceed to move them into your new subdir that you created in step 3.

For example, when using ActiveRecord for your Rails models, you can provide custom attribute accessors, say to serialize a Hash to JSON, using the read_attribute and write_attribute methods like this:

1
2
3
4
5
6
7
8
9
10

# Assume a text column named 'stuff'
class User < ActiveRecord::Base
  def stuff
    JSON.parse(read_attribute(:stuff))
  end

  def stuff=(new_val)
    write_attribute(:stuff, new_val.json)
  end
end

With this, you can assign a Hash to the stuff attribute of User, and when you access it via User#stuff, you get a Hash back. All the while, it’s read and written to and from the database as a JSON string.

Doing it with Ripple on top of Riak

Ripple is the Ruby modeling layer for the distributed NoSQL store, Riak. It tries very hard to provide a lot of the same interfaces as ActiveRecord. However, this is one of the areas it diverges: Ripple::Document objects do not support the read_attribute and write_attribute methods.

Instead, they implement the [] and []= methods. Translating the code above to work with Ripple is pretty easy:

1
2
3
4
5
6
7
8
9
10
11
12
13

class User
  include Ripple::Document

  property :stuff, Hash

  def stuff
    JSON.parse(self[:stuff])
  end

  def stuff=(new_val)
    self[:stuff] = new_val.to_json
  end
end

Bonus Points

Using this tactic, you can easily add some memoization so that your getter doesn’t need to parse the JSON text on every access. To do this, we’ll use an instance variable as a cache that we’ll invalidate in the setter, like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class User
  include Ripple::Document

  property :stuff, Hash

  def stuff
    @cached_stuff ||= JSON.parse(self[:stuff])
  end

  def stuff=(new_val)
    @cached_stuff = nil
    self[:stuff] = new_val.to_json
  end
end

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.

I’ve created a workaround for this and included it in my jquery.mobile.utils library. Using this you can call:

1
2
3
4

// Params: jqm theme swatch, and message text
$.mobile.utils.showWaitBox("a", "Hang on while I do work...");
// ... some time later...
$.mobile.utils.hideWaitBox();

That will let you leave the standard textless page-loading spinenrs alone, but be able to show a nice themed wait box with a spinner while your app is doing something the user needs to wait for, that looks like this:

To use these methods, download the JavaScript or CoffeeScript version of the jquery.mobile.utils library from the project’s github page and include it in your jQuery Mobile page after jquery.mobile-1.1.0.js is loaded.

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.

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.

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.

The Reason

The jQuery Mobile team is doing this on purpose, to make it so the address bar on iPhone does not drop down when changing pages (and we all love that feature!). In this discussion and this discussion, they seem to understand that this makes custom click handlers get the wrong href, but decide to go ahead with it anyway.

You can see it happen in this excerpt from the jQuery Mobile 1.1.0 source (reformatted for blog-friendlyness):

1
2
3
4
5
6

// By caching the href value to data and switching the href to a #,
// we can avoid address bar showing in iOS. The click handler resets
// the href during its initial steps if this data is present
$( link )
  .jqmData( "href", $( link  ).attr( "href" )  )
  .attr( "href", "#" );

The Solution

Here’s the part that seems to be undocumented other than in that comment: they store the href in a data attribute! This makes this problem easy to workaround. Simply change your click handler to check for the data attribute first and fall back to the href:

1
2
3

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

That would be easy enough to encapsulate in a nice helper function…

Applying This To Rails jQuery UJS

If you use the Rails link_to helper with the :method option set to anything other than :get, links are handled by the jquery_ujs library that comes with Rails (often referred to as Rails UJS, jQuery UJS, rails.js). You’ll notice, for example that none of your :delete links work with jQuery Mobile when you are on iOS Mobile Safari. You might see this as a missing route for your show or edit method depending on where you are linking from.

It turns out the fix is easy. The jquery_ujs code already has a method to encapsulate getting the href from an element, complete with a comment telling you how you can override it. All it does out of the box is read element.attr('href'). All we have to do is override it and make it try the data attribute first.

Somewhere after jquery_ujs.js is loaded, define this:

1
2
3

$.rails.href = function(element) {
  return element.data('href') || element.attr('href');
}

Now your Rails link_to calls with custom :method options such as :delete will work just fine with jQuery Mobile 1.1.0 on iOS Mobile Safari, and you don’t have to lose that clever bit that keeps the address bar hidden.

UPDATED Jan. 3, 2013: I have confirmed that this problem has been solved in jQuery Mobile 1.2.0, and this work-around is no longer required. I did try to upgrade one of my jQuery Mobile 1.1.0 apps to 1.1.1 (but rolled back for other reasons), and in that process I believe that the above solution was still required.

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.

The biggest differentiating factors were the company culture and lifestyle, and the comaraderie and ethos of the team. Earlier this month, I spent 3 days in NYC with the core members of the team. This happened to be during a big crunch time for them, with an important ship date coming just around the corner. I got to see first-hand how the team works and plays together, and how they deal with last-minute hiccups and schedule pressure. I had the opportunity to be a fly on the wall while they worked and to be included in some very interesting architecture discussions where it was clear my expertise was immediately impactful. I even got to take part in some fun PR and marketing operations with the team. I like how this team carries itself and, of all the places I’ve searched, I believe this is where I will feel the most at home.

Our team is distributed around the country, and we collaborate using all the modern online tools. Even though it’s still before my official start date, I’ve had a chance to get my feet wet this week just for fun (and because I am too excited to hold back). I am looking forward to enjoying the work-at-home lifestyle where I already have plenty of experience and know that I can be super-productive while still being able to hit the gym and have lunch with my kids.

Another big attraction to Validas is that it presents the greatest opportunity to work with cutting-edge technologies to solve the kinds of problems I find interesting. The volume of data we handle at Validas is enormous and growing rapidly. The huge success of our enterprise product, VERA, shows that we’re already the premier provider of big-data solutions in the mobile space ⎯ not to mention our forthcoming consumer-facing offerings. I see this as a great opportunity to lead the development of innovative solutions in big-data intelligence, to push the envelope in exicting areas such as machine learning and predictive analytics, and to build the next generation of consumer-facing products. The vision of this company and its founding team is big, hairy, and audacious - just the way I like it!

After being on the sideline for two months, I am chomping at the bit to get back into the game. I’m already ramping up. My first level of impact will involve applying my fresh perspective to existing systems to help find architectural solutions to the next wave of challenges. I’ll also be heavily involved in building and launching some new products that have yet to be announced, so stay tuned…

Many thanks go out to everyone that supported me while I found my next path - especially my wife, Laurie. I rely on your support and your faith in me.

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 didn’t leave because of some falling out or because of “creative differences”. I think Edward and the team at Balasannian Enterprises have brilliant ideas and an exciting work environment. Some of the best minds in software development, product design, intellectual property, and creative strategy work there.

I left because it is time for me to do something different. My motiviation has always been driven by the pursuit of autonomy, mastery, and purpose. That hasn’t changed. It’s the way I’ve been going about it that needs to change. I feel the need for fresh inspiration, new relationships, and a different variety of opportunity.

How will I achieve that? I have no idea.

There are so many options; it’s a bit daunting. I have some ideas that I might like to pursue on my own. I have some great contacts in the industry that are working on some really cool and BIG problems. It would be awesome to align with them. There are some exciting companies in my own backyard working on building the future and there is a vibrant, growing community of tech startups here in the Seattle area. I have a skill set that is in high demand on the contracting/consulting scene, and there’s always the allure of contributing on a large scale to a meaningful open source project. That kind of networking can be fun and door-opening.

I’ve committed to taking at least a month off to let it all sink in. With an open mind, I am going to explore all avenues and opportunities before crafting the path into the next phase of my career. I’m open to all ideas! Please feel free to comment below or connect with me privately. I’d love to hear your feedback.

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

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.

Adding a Custom Format Sucks

I don’t like everyone’s suggestion of adding a :mobile or :iphone MIME type like this:

1

Mime::Type.register_alias "text/html", :mobile

These solutions detect the User-Agent in a before_filter and set the request format like this:

1

request.format = :mobile

This sucks if you want to use any of your partials for both mobile and desktop pages, because they are considered to be different formats. Say you have a template show.html.haml for the desktop version of the page, and a show.mobile.haml template for the mobile version. You can’t have them both render the same partial. Now imagine you have a common footer you want to use in both version. You’d like to just render :partial => 'footer' and have it work. But it doesn’t. If your partial is named _footer.html.haml, rendering the mobile template will complain that it can’t find _footer.mobile.haml. You’re stuck maintaining two identical copies of this partial. This really sucks if you have a lot of these kinds of partials.

Some people suggest removing the format in the filename, so you’d have _footer.haml. I am not fond of this solution.

Adding a Custom Domain Sucks

Don’t you hate it when you see a link to an article on Twitter and click it on your desktop, only to be taken to http://m.whatever.com/ because someone shared this link from their mobile device? Now you’re reading a mobile version of this article full screen on your desktop and it looks ridiculous. Or you hit a full version URL from your mobile device and have to suffer yet another redirect. As a user, I would prefer to see one page that looks mobile-friendly on a mobile device, and looks like a full version on a desktop. As a developer, redirecting seems like a cop-out. It also feels like it violates a good RESTful design. There should be one URL for this resource and its view should be tailored to the device on which I am viewing it.

There Is A Better Way

I like to leverage the same before_filter concept of the custom format solution to detect whether or not you are on a mobile device. You can even add a check for a query param that allows a request to set a flag in the session that overrides the mobile-or-not setting. The first step to this is to build some filters and helpers into your ApplicationController:

1
2
3
4
5
6
7
8
9
10
11
12
13

def check_for_mobile
  session[:mobile_override] = params[:mobile] if params[:mobile]
end

def mobile_device?
  if session[:mobile_override]
    session[:mobile_override] == "1"
  else
    # Season this regexp to taste. I prefer to treat iPad as non-mobile.
    (request.user_agent =~ /Mobile|webOS) && (request.user_agent !~ /iPad/)
  end
end
helper_method :mobile_device?

With these in your ApplicationControlelr, you can add before_filter :check_for_mobile to any controller/action and have it detect whether or not a request is mobile, or is forced to be mobile (or not) with a query parameter mobile=1 (or mobile=0). You also have a mobile_device? method that you can call from any controller or view to see if you are currently rendering a mobile-formatted page. (This is rarely needed, but can be handy in certain situations.)

The next step is to tell Rails to render mobile versions of the templates if the request is deemed to be from a mobile device. Rather than using a custom format, use a custom view path. This is the trick used by Rails engines and plugins to extend the app with its own view templates, while still allowing them to be overridden by the app. To make this work, you need to create a separate directory structure for mobile view templates and add it to the front of the view load path. This way, you can still use the :html format, and can still share templates between mobile and desktop templates. As an added bonus, you can still serve full versions of pages to mobile devices if you haven’t implemented the mobile version yet. This is huge if you’re trying to incrementally add mobile-friendly pages to an existing desktop-oriented site.

For purposes of this example, I’ll call this parallel mobile views directory views_mobile. The way you prepend that to the view load path is with the prepend_view_path method. I prefer to put this in a method in ApplicationController that I can call from the check_for_mobile filter if a mobile device is detected, or that I can use directly as it’s own filter:

1
2
3

def prepare_for_mobile
  prepend_view_path Rails.root + 'app' + 'views_mobile'
end

Now, if you use before_filter :prepare_for_mobile on any action, it will always be treated as mobile, rendering templates from your app/views_mobile directory tree if they exist, falling back to those in your app/views directory tree if they don’t. This is great if you have a mobile-first responsive design for your page that you want to always serve to mobile and desktop devices, but still have other pages (and layouts) that are fully designed for the desktop that you don’t want to mix with.

The last step is to augment the check_for_mobile filter method to call prepare_for_mobile if it detects a mobile device. That way you can use before_filter :check_for_mobile on methods that have two versions. Those actions will render the mobile version from app/views_mobile for mobile devices and from app/views for non-mobile devices – and they can both render the same shared partials living in app/views.

The Final Solution

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
27
28
29
30

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  def check_for_mobile
    session[:mobile_override] = params[:mobile] if params[:mobile]
    prepare_for_mobile if mobile_device?
  end

  def prepare_for_mobile
    prepend_view_path Rails.root + 'app' + 'views_mobile'
  end

  def mobile_device?
    if session[:mobile_override]
      session[:mobile_override] == "1"
    else
      # Season this regexp to taste. I prefer to treat iPad as non-mobile.
      (request.user_agent =~ /Mobile|webOS) && (request.user_agent !~ /iPad/)
    end
  end
  helper_method :mobile_device?
end

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  # Render mobile or desktop depending on User-Agent for these actions.
  before_filter :check_for_mobile, :only => [:new, :edit]

  # Always render mobile versions for these, regardless of User-Agent.
  before_filter :prepare_for_mobile, :only => :show
end

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.

I tried a few of these, and read through the code, and realized that a few of them have some problems. Problems like not supporting password fields, or incorrectly styling non-focused input placeholders. After reviewing these, I decided that the best one to go with was jquery-placeholder by Mathias Bynens. This one is easy to use, no-ops on browsers that natively support input placeholders, and nicely handles all the corner cases I tested for.

To use jquery-placeholder, simply download jquery.placeholder.js from the project page and make sure it gets included in your page after jQuery. Then you’ll need to apply it to every element you want with a jQuery statement like:

1

$(selector).placeholder();

If you want to use this with jQuery Mobile and its AJAX page-loading mode, you’ll need to make sure to execute this statement on every page that gets loaded. You can do that in your main javascript for the document with something like this:

1
2
3
4

$(document).bind('pageshow', function() {
  var activePage = $('.page.ui-page-active');
  activePage.find('input[placeholder], textarea[placeholder]').placeholder();
});

From there, you may notice that the placeholder looks different on all the different browsers. You can style this to be consistent with CSS. You’ll need to be a bit repetitive here, because of the way putting the placeholder selectors on the same line breaks some of the browsers. If you use a CSS preprocessor this gets a little easier. Here is an example using Sass’s SCSS syntax:

1
2
3
4
5
6
7
8
9
10
11

input, textarea {
  &.placeholder {
    color: #A9A9A9;
  }
  &:-moz-placeholder {
    color: #A9A9A9;
  }
  &::-webkit-input-placeholder {
    color: #A9A9A9;
  }
}

The rails.js file from rails/jquery-ujs does some very cool stuff to let you emulate HTTP methods other than GET and POST. It does this by looking for a data-method attribute on your links. When it finds one, e.g.: data-method='delete', it creates an invisible form to submit a POST with all your link details and a special _method=delete parameter that Rails handles in the backend as if it were a DELETE method. Using the link_to helper, that normally looks like this:

1

<%= link_to "Delete", @post, :confirm => "You sure?", :method => :delete %>

jQuery Mobile loads same-domain links and form submissions via AJAX and provide sexy page transitions. You control how these work by adding data attributes to the <a> or <form> element. One important one, that can affect the correct operation of your page, is the data-ajax='false' attribute. That makes disables the AJAX behavior, and loads the next page from your link or form as a new page. That normally looks like this:

1

<%= link_to "View", @post, "data-ajax" => "false" %>

One important time you may wish to exercise both tactics at the same time is in providing a delete link. You want to use a link to generate a DELETE request via Rails UJS, and you want to redirect to a new page without jQuery Mobile loading it via AJAX. This is how you would attempt that:

1
2

<%= link_to("Delete", @post, :confirm => "You sure?",
            :method => :delete, "data-ajax" => "false" %>

Sorry. That won’t work.

This is because Rails UJS does it’s magic by creating a new <form> to submit when the link is clicked. It doesn’t know or care about the data-ajax attribute, and the form it creates does not have that attribute. Then, when the form is submitted, jQuery Mobile handles it using AJAX by default because the form didn’t specify otherwise.

We need Rails UJS to copy the data-ajax attribute from the link to the form it creates. This is actually a pretty simple fix (hack) to the handleMethod funciton in rails.js. To just one-off this particular attribute, you can do somethign like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

diff --git a/src/rails.js b/src/rails.js
index 06b4e0b..49ff0b2 100644
--- a/src/rails.js
+++ b/src/rails.js
@@ -174,6 +174,11 @@

       if (target) { form.attr('target', target); }

+      var ajax = link.data('ajax');
+      if (ajax !== undefined) {
+        form.attr('data-ajax', ajax);
+      }
+
       form.hide().append(metadata_input).appendTo('body');
       form.submit();
     },

In fact, I’ve committed this patch in a branch on my fork of rails/jquery-ujs.

With this addition, the above combination of :method => :delete and "data-ajax" => "false" work beautifully together. You can imagine doing this for other data attributes you care about such as data-direction and data-transition.

There’s currently an outstanding issue to address this, with some discussion on how to go about this generically. If you would like to see this make it into the main distro, head over to that issue and voice your support.

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.

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).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# Put this somewhere it will get auto-loaded, like config/initializers
module DeviseFilters
  def self.add_filters
    # Example of adding a before_filter to all the Devise controller
    # actions we care about.
    [
      Devise::SessionsController,
      Devise::RegistrationsController,
      Devise::PasswordsController
    ].each do |controller|
      controller.before_filter :prepare_for_mobile
    end

    # Example of adding one selective before_filter.
    Devise::RegistrationsController.before_filter :check_invite_code, :only => :new
  end

  self.add_filters
end

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.