Rails 3.1 has a serialize function that can take a custom column coder. A custom coder needs to have dump and load methods set, or else it will be recognized as a required type for the built-in YAML coder called YAMLColumn.

While the JSON class has the two required methods, it doesn’t allow specifying a default. So I created a custom coder. I don’t know where the best file and module locations to put the class in are, so I won’t include them here. This is the class, though:

class JSONColumn
  def initialize(default={})
    @default = default
  end

  # this might be the database default and we should plan for empty strings or nils
  def load(s)
    s.present? ? JSON.load(s) : @default.clone
  end

  # this should only be nil or an object that serializes to JSON (like a hash or array)
  def dump(o)
    JSON.dump(o || @default)
  end
end

Since load and dump are instance methods, an instance of JSONColumn needs to be passed rather than the class. Here’s an example that works for me inside of the rails console:

class Person < ActiveRecord::Base
  validate :name, :pets, :presence => true
  serialize :pets, JSONColumn.new([])
end

Update: Added .clone to the load method. HT @miyagawa.

I just googled something I’ve always wanted to know how to do in vim, and was surprised how quickly I found the answer.

In vim, there are separate modes for searching and commands. This generally works well as they have separate completion buffers and since I do them a lot, it keeps my command history from cluttering up my search history and vice versa. The area where I’ve wished that they were unified is when I want to convert from a search to a substitution expression. Normally in vim you do search expressions in search mode and command expressions in command mode. For example, if I wanted to search for trailing whitespace I might type:

/\s\s*

If I want to replace it with an empty string through the whole file I might type:

:%s/\s\s*//g

I can’t remove the / at the front of the command line with a backspace and replace it with a colon, so until I learned the tip I’m about to reveal I had to retype it. No longer.

The StackOverflow answer I found for the query, Convert vim / search to search and replace without retyping regular expression, suggests this remarkably simple technique:

You can type

/search_term

and then

:%s/<ctrl-r>// etc

where you actually press ctrl+r and then / to insert the search term.

It works! No longer do I desire for search and command modes to be unified.

There’s nothing new about expressing XML in a significant-indentation format. Here’s Slim next to one from 2001.

Simple Outline XML (2001)

html>
    head>
        title> My Home Page
    body>
        h1> Contact Details
        p>  I can be contacted at
            a>  href=mailto:me@myplace.net 
                this address
            except when on vacation.

Wikipedia Article

Slim (2010)

html
  head
    title My Home Page
  body
    h1 Contact Details
    p I can be contacted at
      a href="mailto:me@myplace.net" this address
      except when on vacation.

They’re quite similar. I find Slim a bit more comfortable in a ruby environment because it’s a bit more terse and uses two spaces like Ruby code does. It also is a templating language too. (In fact, I’m not sure there are converters going in both directions between XML/HTML and non-templated Slim. It could make a nice addition.)

I find vim’s :lcd command to be quite useful. For a long time I didn’t use it, mainly because I didn’t understand how it works.

First, using it is simple. It works just like :cd. You type :lcd path/to/directory in command mode. The path is relative to the current directory, so :lcd .., :lcd ~/Desktop, and :lcd /etc/apache2 all work.

The :lcd command changes the path of the current window. The current window is the current frame within the current tab. Now, what’s really neat, is that a new window (created from commands such as :sp and :tabedit) gets the local directory of the window it’s created from.

Most plugins respect it. Both Command-T and ack.vim search within the local current directory. Another plugin, fugitive, bases its commands on the git repository of the current file so it works smoothly with different local directories as well.

Bang commands (like :!cp README.md ~/Desktop) also use the local current directory.

Finally, after using it for a while it gets easy to tell which directory I’m in. The status line displays the path of the current file based on the local current directory, so if I know where the current file is I can quickly figure out where the local current directory is.

I used it the other day with bundle show to dig through the source of two dependencies of my Rails project to better understand them.

If you use vim and haven’t got in the habit of using :lcd I highly recommend it. If you use another editor and wish it handled working in multiple directories gracefully, consider giving vim a shot!

…and I like the new .on() and .off() API for setting up events.

I wrote some code that uses it, just for practice.

$.fn.tree = function(data) {
  var $el = $(this),
      html = [];
  
  function renderNode(node) {
    if (typeof node === "object") {
      html.push("<ul>");
      for (var key in node) {
        if (node.hasOwnProperty(key)) {
          html.push("<li><strong>" + key + ": </strong>");
          html.push(typeof node[key] == "object" ? renderNode(node[key]) : node[key]);
          html.push("</li>");
        }
      }
      html.push("</ul>");
    }
  }
  
  renderNode(data);
  $el.html(html.join(""));
  
  $el.on('click', 'strong', function() {
    $(this).closest('li').find('ul').toggle(200);
  });
};

$("<div>").appendTo("body").tree({
  name: {
    first: "Benjamin",
    last: "Atkin"
  },
  location: {
    city: "Boulder",
    state: "CO"
  },
  accounts: {
    social: {
      twitter: "http://twitter.com/benatkin",
      facebook: "http://facebook.com/atkin",
      gplus: "http://gplus.to/benatkin",
      identica: "http://identi.ca/benatkin",
      rstatus: "http://rstat.us/bat"
    },
    creative: {
      github: "http://github.com/benatkin",
      blog: "http://benatkin.com/"
    }
  }
});

Nothing too fancy.

Repositoryjquery
Ownerjquery

I knew this was coming before the Mac App Store was announced. Few believed it back then. When Apple first announced its Mac App Store, more believed it. Now that Apple has set a deadline for sandboxing, some people still don’t believe it.

I believe that I should be allowed control over my computers. This is not dependent on the distinction between client and server, or between web and native. I also don’t buy the argument that it’s different when talking about so-called appliances like the iPad, which are really just crippled general-purpose computers.

One of the first things I’m going to do about it is to switch to something other than Mac OS X or Windows for desktop computing.

With the Rails 3.1 Asset Pipeline, there’s the rake assets:precompile command which precompiles assets into public/assets along with a manifest.yml file which rails uses to put the paths to the assets in its templates. Precompiling generates a few files, which can clutter commit logs if they’re committed. For this reason I might add public/assets to my .gitignore and build them on the server, rather than committing them to git and uploading them. Or, if the server had trouble compiling them, I might precompile them locally, and scp them up rather than committing them to git, because they can make a lot of noise in my git logs.

On Heroku, though, git is the only way to deploy. So if I’m having trouble having heroku precompile them, I need to commit them and push them via git. This could clutter up my commit log.

There is a way around this, though: use a branch! If I create a branch just for heroku, and just commit them to the branch, I can keep my commit logs free of changes to public/assets.

Here is a sketch of this process:

  1. Add public/assets to my .gitignore and commit it
  2. Create a heroku branch with git checkout -b heroku
  3. remove public/assets from my .gitignore and commit it. This just affects my heroku branch.
  4. Run RAILS_ENV=production rake assets:precompile there.
  5. Run git add . and git commit -m 'precompile assets' to commit the files to my heroku branch
  6. Run git push heroku heroku:master to push my heroku branch to heroku as master (heroku only uses the master branch)
  7. Run git checkout master and continue development on my master branch.

A deploy rake script could be used to automate this.

The heroku branch wouldn’t need to be pushed to github, because it doesn’t contain any information that can’t be regenerated. The only reason the history would need to be preserved is so it can be cleanly pushed to the heroku app. Fortunately, if the local repo was lost, it’s possible to pull from the heroku repository. Heroku shouldn’t be used as a place to store git repositories because the lifecycle for a heroku app is often different than that of a repository. For this purpose, though, the usefulness of the old assets commits is tied to the life of the Heroku app so it works out well.

I believe that water is the only drink for a wise man.

— Henry David Thoreau (seen in the lobby of Hotel Palomar in San Francisco last week)

To believe your own thought, to believe that what is true for you in your private heart is true for all men,—that is genius.

— Ralph Waldo Emerson

I’m developing a Rails site that uses MySQL and runs on Heroku. I’m using Xeround for the database, which has a free trial. Xeround is a database PaaS (Platform as a Service) that runs on several places, including Amazon Web Services in their U. S. East region, which is where Heroku runs. Running it in the same place where Heroku runs gives it a low latency.

To set up Xeround, sign up for an account and set up a database instance in the AWS U. S. East region. Go to the page for the database instance, and you will see the username and the database URLs.

Rails reads its database configuration from config/database.yml. Heroku overwrites config/database.yml with a file it generates from the DATABASE_URL configuration variable. The configuration variable uses the database driver name as the network scheme (e. g. mysql://). There is more than one mysql driver for Rails; the one suggested in the Rails Guide is mysql2.

To use mysql2 as the database driver with Xeround, use the following for the DATABASE_URL configuration variable:

heroku config:add DATABASE_URL='mysql2://{{username}}:{{password}}@{{hostname}}:{{port}}/{{dbname}}'

The username, hostname, and port number can be seen on the DB Instance Manager page on Xeround. The hostname and port are under one of the three DNS Names; I picked the top one. The password is what was entered for the database password during signup. The database name is the name of the database to be added using PHPMyAdmin.

The driver also needs to be included in the Gemfile. To include it just for production, use:

group :production do
  gem 'mysql2'
end

After adding this, run bundle install, commit your changes, and push to Heroku.

The database still needs to be created. To create the database, click on one of the links under DNS Names on the DB Instance Manager. This brings up PHPMyAdmin. Enter the database password and log in. Then create the database, with the same name used for the DATABASE_URL configuration variable.

Now that the database has been created, the DATABASE_URL is set, and the Gemfile is updated and pushed, you should be able to migrate the database by running heroku run rake db:migrate.

I’m using the latest version of Rails (3.1.1) on Heroku’s cedar stack.

It will be interesting to see how well Xeround works for this project. There are other MySQL hosting options for EC2 if I need them, and migrating is fairly simple.

After setting up some Heroku addons I got used to using environment variables to specify add-on settings. I then started using them for non-addon settings, and now I’ve started using them outside of Heroku a bit too.

One area where they work well is for a Heroku-deployable open source app with OmniAuth GitHub OAuth integration. Here is an example initializer (config/initializers/omniauth.rb) from a RailsCast:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :github, 'CLIENT_KEY', 'CLIENT_SECRET'
end

I would replace CLIENT_KEY and CLIENT_SECRET with my own keys, but I can’t commit them to a public repository, or else another person could use them and I could be held responsible. Rather than leave out my client key and secret using a .gitignore and a sample config, I can use an environment variable:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :github, ENV['GITHUB_CLIENT_KEY'], ENV['GITHUB_CLIENT_SECRET']
end

With a note in the README about the environment variables used, this should be easy for developers to set this up on their own private apps.

So far I’ve been typing environment variables into the command line when running apps locally and on my VPS, but that’s about to change. I may specify them in my nginx config, which is backed up to a private git repo. I’m not sure yet. Also I’m going to dump out my Heroku environment variables and back them up too.

Repositoryomniauth