Schneems

Cedar goes General Availability on Heroku

Thu, 24 May 2012 16:39:04 -0400

Cedar goes General Availability on Heroku

The HourSchool Blog: How can companies ask better questions?

Thu, 24 May 2012 13:00:30 -0400

The HourSchool Blog: How can companies ask better questions?:

One core pillar of human-centered design is the idea of seeing the world through other people’s eyes, gaining empathy for their worldview, and meeting them where they are. Many companies are getting on board with the idea of putting the user or customer at the center of their business and design…

Sextant: A Gem to Help you Find your Routes

Tue, 22 May 2012 09:46:50 -0400

News flash, writing a Rails app without knowing your routes is pretty much impossible, and this just in $ rake routes takes forever [1] to run. So how can we build a Rails site with a minimum of time and a maximum of awesome? You can use the recently released Sextant Gem [2] to generate routes in your Rails app.

As it turns out if you benchmark the code in $ rake routes it is reasonably fast, the slow part comes from having to initialize the app environment every time it’s run. So lets take some of that code and put it in your already initialized web app. What you get is a whole lot of awesome in a tiny package. Next time you want to see your routes, just visit /rails/routes in your browser if you’ve got sextant installed, and you’ll see your routes in no time.

To install add this to your Gemfile:

gem 'sextant'

Then run bundle install and you’re good to go. Start your server and visit /rails/routes

This in-browser information is local only. If you like Sextant tell your friends, and tell me @schneems

[1] Forever is measured in seconds
[2] Sextant is an old device for navigating. It can help you find your route on a long journey.

OAuth: A Tale of Two Servers

Wed, 16 May 2012 09:55:17 -0400

What exactly is OAuth, and how can you use it to access data on sites like Facebook? This introductory video explains the basic flow behind OAuth 2 and how OAuth Clients are implemented.

If you’re using OAuth, you’ll likely want to use a pre-built client library to help with the process. For Ruby you’ll likely want to use Omniauth or Koala, though understanding the process is still important.

This is being posted from Singapore, where I’m about to give a talk at Red Dot Ruby Conf. Have fun learning about OAuth, i’ll post slides from my talk as soon as they’re ready. Wish me luck!

Deploy & Edit a Facebook App in 5 Min

Thu, 10 May 2012 09:53:32 -0400

Ever want to write an App that uses the Facebook graph? You could be the next Zynga, Foursquare, or Causes; but first you need to create your app. This quick demo shows getting started by generating an app through Facebook and then editing it. If you’ve already got a working web app it’s simple to add Facebook functionality to it, though we’ll save that for another day. What are you waiting for, five minutes from now you could have your very own live Facebook App!

If you’re interested in more information on Facebook Apps let me know @schneems

Multiple Ruby Version Support on Heroku

Wed, 09 May 2012 11:39:42 -0400

Starting today Heroku will allow you to specify a version of Ruby in your production app. As one of the most requested features we have been asked for time and time again, we’re happy to announce that it’s now live. To get started you’ll want to update your version of Bundler locally to version 1.2.0, or above.

This is a re-post of an Article I wrote for the Heroku Blog

$ gem install bundler --pre

Then you’ll want to specify the version of Ruby you want to use in your application inside of your Gemfile. For example if we wanted to use Ruby 1.9.3 in our production application you would want to include ruby '1.9.3' inside of your Gemfile. In a rails Gemfile it might look something like this:

source 'http://rubygems.org'

ruby '1.9.3'
gem  'rails', '3.2.3'

Once you’ve added ruby to your Gemfile, commit it to git

$ git add Gemfile
$ git commit -m 'use Ruby 1.9.3 on Heroku'

Then you’ll want to deploy your app

$ git push heroku master

Once your application is done deploying you will be able see the version of Ruby you are using is 1.9.3.

$ heroku run bash
$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

It’s that simple!

With this new feature you can also use this process to call a specific version of Ruby other than 1.9.3, however, if it is not installed on the Heroku system you’ll receive an error.

Production and Development Parity

At Heroku, we strongly believe that there should always be a strong parity between development and production environments in order to minimize any surprises. When the tooling of your development environment most closely matches your production environment, there is far less room for error. Another good example of keeping parity between dev and production environments would be running PostgreSQL locally in the development environment instead of SQLite since you’re production system is running Postgres on Heroku.

While there are other reasons you may want to use different versions of Ruby in certain scenarios including performance issues or to access version-specific Ruby features, developers should overall strive to use the same tools and versions of software for development as are used for production.

Patch Versions

While you can now specify the version of Ruby you would like your web application to use, at this time we do not support that ability to request a specific patch version to be called, such as Ruby 1.9.2-p290. Ruby patches often include important bug and security fixes and are extremely compatible. While you can specify the version of Ruby you wish to use, Heroku will provide the most secure patch level of that version.

Debugging

If you’ve followed all the steps above and you’re still seeing a different version of Ruby than you need, please recheck your path.

$ heroku config
PATH     => vendor/bundle/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin:bin
RACK_ENV => production
# ...

You need to ensure that bin is in front of your path so you could change the above to

$ heroku config:add PATH=bin:vendor/bundle/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin

As a tip, It is a good idea to use the free releases feature whenever you are modifying your ‘config’ in case you need to roll back to a previous version of Ruby.

Thanks

Thanks to Terence Lee Heroku Ruby team member and bundler maintainer for the additional support of ruby versions to the Heroku Ruby Buildpack and orchestrated the release of Bundler 1.2.0. Also thanks to Yehuda Katz and the entire Bundler team for helping get this release out the door.

Give this feature a try and let me know what you think @schneems!

Wicked Gem Featured on Railscasts

Sat, 05 May 2012 12:24:34 -0400

Wicked Gem Featured on Railscasts:

Wicked was featured by Ryan Bates on Railscasts this past week. I’ve learned quite a bit over the years from Railscasts, so it’s a great honor to have my work featured there.

Legacy Concerns in Rails

Tue, 01 May 2012 10:01:00 -0400

The cats out of the bag, Ruby isn’t immune to legacy code problems. Just because your app is written in a hip, fun, and dynamic language doesn’t mean that your codebase can’t stagnate, bloat, and quickly turn into an unmaintainable ball of mud. Before Gowalla was purchased by Facebook, the Rails code base stood at close to seven thousand files, with the largest model clocking in at around 3,500 lines of code. While we were somewhat unique, being originally written in Merb and then ported to Rails, applications of this size aren’t all that uncommon. If you’ve got a large app there are a number of things you can do make your situation better, one of the simplest with the greatest impact is splitting up models into concerns.

If you’re not familiar with concerns, you can read up about them at Concerned about Code Reuse?. Go ahead, we’ll wait.

Rails has long advocated a thin controller, fat model approach to development, which works great early but can lead to a model obesity epidemic. If we split out our models into different concerns we can group related code, and even make re-using code between projects easier. Best of all, if you start early on it’s a pretty painless process.

The User Model

There’s only two businesses that refer to their customers as ‘users’ and software is one of them. It’s also bound to be one of the largest models in your app since so much will likely need to be connected to a user. It’s a good place to start splitting up a model into a concern. Lets say that we want to add some methods on our user object so they can access Facebook information we can start by creating a new file app/models/user/facebook_methods.rb (you’ll need to create the user folder).

This file is where we’ll group all of our methods related to Facebook. For this example i’ll be using the Koala Facebook gem, and we assume our user model has a facebook_token attribute persisted to the database.

module User::FacebookMethods
  extend ActiveSupport::Concern

  def facebook_graph
    @facebook_graph ||= Koala::Facebook::API.new(facebook_token)
  end
end

Not a bad start, now we want to add this ability to our user model, open up app/models/user.rb and add our concern.

class User < ActiveRecord::Base
  include User::FacebookMethods
end

Great! Now we can construct our Facebook graph object straight from our user.

user = User.where("facebook_token is not null").first
user.facebook_graph
# => <# Koala #...

user.facebook_graph.get_connections("me", "friends")
# => {52930 => 'Terence Lee',  12345 => "Ruby Ku" #...

That Was Easy, but…

What did that buy us? First we’ve got an obvious place to store our code. Want to write a method that pulls out all of a user’s Facebook friends? Put it in the facebook_methods.rb file. If you forget the name of that method, check out your Facebook methods. If you need the facebook_graph method, bet you money it’s in that concern. If all related code is in one place its a lot easier to scan visually and to search for keywords.

Won’t This add More Code to the Codebase?

In the example above, we added 4 extra lines of code to save us 3 measly lines in our user.rb file. While this isn’t ideal for such a small concern, as it grows in size its much easier to keep track of the components, which in turn helps keep your code small and manageable. It also nudges developers to create unit tests for those specific concerns. This sounds minor, but when you get to a file with 3500 lines of code, you start duplicating functionality that you didn’t know existed. Either it was added by another developer, or you forgot you added it months ago. Keeping everything in its place helps keep your code sane.

How Should I Break up My Code

Often times I like breaking out my concerns based on knowledge of third party services. For example I broke out a concern for all the Facebook methods above. I use websolr and I like having a separate concern for all the search related methods. Recently I played around with the Ice Cube gem which is a library for creating an iCal formatted recurring date syntax. I split that code out into a concern, not because it was touching another service, but because I might want to re-use that code in another model some day, and it’s easier to break out the code now. There are no hard and fast rules, just don’t go overboard and have 100 concerns for every model with 3 lines of code in each of them, and on the flip side don’t have one concern with everything.

Just think of the different areas of ‘concern’, that your code covers. Get it?

Legacy Code

While building out the final version of the Gowalla service we managed to promote Redis and Cassandra to first class data storage citizens, completely re-write all web controllers, and split out a brand new api into a separate set of controllers (more on this in a later date). It was a ton of work, we were completely changing the way our service worked and creating new paradigms such as a “Stories” where multiple users could check each other in and at the same time, we still had to support a ton of 3rd party client applications using the old API.

So, how did concerns help? We used concerns to isolate new code and new services. It also helped us to add more & better unit testing by focusing different spec files on different areas so models/users/following_methods.rb would be tested by spec/models/users/following_methods_spec.rb. Most of the developers used some form of automatic test runner such as Guard Rspec, and it is nice being able to run only the unit tests associated with the concern you’re writing without having to run all the unit tests for that model.

Bonus! Ever find a method that you were pretty sure wasn’t being called by anything. Maybe it’s in a model that wasn’t exactly 100% tested. You could try making a concern for methods of questionable value. In a month if it’s still there, delete the sucker, deploy to staging, validate and commit to master.

Shared Concerns

If you have code that needs to be shared by multiple models in your project, you can keep this in your lib folder. I actually like to have a concerns folder like lib/concerns/models/duplicate_code.rb. When we added Cassandra to the Gowalla project we needed a way to get our Postgres models to play nice. Thats when Adam Keys and Bill Doughty pulled out common logic and put it into a concern using another library called Chronologic. lib/concerns/models/chronologify.rb

Then any time you wanted this shared code into your model, you just had to include it.

# models/checkin.rb
class Checkin < ActiveRecord::Base
  include Concerns::Models::Chronologify
end

Don’t forget to add the concern folder in your lib to your search path.

Wrap it Up

There have been tomes written about dealing with legacy code in software, I’ve been recently recommended Working Effectively with Legacy Code . Using concerns won’t be a magic bullet, but it will help keep your code nicely organized. Even if you’re dealing with a pristine new app, concerns are one way to help it stay that way. Give concerns a try and let me know if you have a good or bad experience @schneems.

Building an iOS Photo-sharing and Geolocation Mobile Client and API with Rails and Heroku

Fri, 20 Apr 2012 18:52:08 -0400

Building an iOS Photo-sharing and Geolocation Mobile Client and API with Rails and Heroku:

My good friend @mattt just released this great tutorial for creating an iOS Photo-Sharing app on Rails. You should hop, skip, or jump on over to the article now. What are you waiting for?

Concerned about Code Reuse?

Thu, 19 Apr 2012 09:59:00 -0400

Right out of the gate, Ruby gives us some powerful ways to re-use instance and class methods without relying on inheritance. Modules in Ruby can be used to mixin methods to classes fairly easily. For example, we can add new instance methods using include.

module DogFort
  def call_dog
    puts "this is dog!"
  end
end

class Dog
  include DogFort
end

Now we’re able to call any methods defined in our DogFort Module as if they were simply slipped into (included) into our Dog class.

dog_instance = Dog.new
dog_instance.call_dog
# => "this is dog!"

Using Modules a fairly easy way to re-use methods, if you want you can extend a Module to add methods to a class directly.

module DogFort
  def board_the_doors
    puts "no catz allowed"
  end
end

class Dog
  extend DogFort
end

Now if we were to call Dog.new.board_the_doors we would get an error, since we’ve added it as a class method instead.

Dog.board_the_doors
# => "no catz allowed"

Dog.class
# => Class

Sweet! Though what if you wanted to add an instance method and a class method to a class. We could have two Modules, one to be included and one to be extended, wouldn’t be to hard but it would be nice if we only had to use one include statement, especially if the two Modules are related. So is it possible to add instance and class methods with only one include statement? Of course…

Enter Concerns

A concern is a Module that adds instance methods (like Dog.new.call_dog) and class methods (like Dog.board_the_doars) to a class. If you’ve poked around the Rails source code you’ll see this everywhere. It’s so common that Active Support added a helper Module to create concerns. To use it require ActiveSupport and then extend ActiveSupport::Concern

require 'active_support/concern'

module DogFort
  extend ActiveSupport::Concern
  # ...
end

Now any methods you put into this Module will be instance methods (methods on a new instance of a class Dog.new) and any methods that you put into a Module named ClassMethods will be added on to the class directly (such as Dog).

require 'active_support/concern'

module YoDawgFort
  extend ActiveSupport::Concern

  def call_dawg
    puts "yo dawg, this is dawg!"
  end


  # Anything in ClassMethods becomes a class method
  module ClassMethods
    def board_the_doors
      puts "yo dawg, no catz allowed"
    end
  end
end

So now when we add this new Module to a class, we’ll get instance and class methods

class YoDawg
  include YoDawgFort
end

YoDawg.board_the_doars
# => "yo dawg, no catz allowed"

yodawg_instance = YoDawg.new
yodawg_instance.call_dawg
# => "yo dawg, this is dawg!"

Pretty cool huh?

Included

That’s not all, Active Support also gives us a special method called included that we can use to call methods during include time. If you add included to your ActiveSupport::Concern any code in there will be called when it is included

module DogCatcher
  extend ActiveSupport::Concern

  included do
    if self.is_a? Dog
      puts "gotcha!!"
    else
      puts "you may go"
    end
  end
end

So when we include DogCatcher in a class it’s included block will be called immediately.

class Dog
  include DogCatcher
end
# => "gotcha!!"

class Cat
  include DogCatcher
end
# => "you may go"

While this is a contrived example, you can imagine wanting to maybe make a concern for Rails controllers and wanting to add before_filter’s to our code. We can do this easily adding the included block.

Is this magic?

Nope, under the hood we’re just using good old fashioned Ruby. If you want to learn more about all the fun things you can do with Modules I recommend checking out one of my favorite Ruby books Metaprogramming Ruby and Dave Thomas also has a fantastic screencast series.

Gotcha

When you’re writing Modules I guarantee that you’ll slip up and accidentally try to create a class method using self or class << self but it won’t work because it’s now a method on the Module.

module DogFort
  def self.call_dog
    puts "this is dog!"
  end
ene

In the example above the context of self is actually the Module object DogFort so when we include it into another class we won’t see the method.

class Wolf
  include DogFort
end

Wolf.call_dog
# NameError: undefined local variable or method `call_dog'

wolf_instance = Wolf.new
wolf_instance.call_dog
# NameError: undefined local variable or method `call_dog'

If you want to use that method in this context you will need to call the Module directly

DogFort.call_dog
# => "this is dog!"
puts DogFort.class
# => Module

Fin

That’s all for today, in my next post I’m going to show you how to clean up your legacy code base with concerns. Let me know if you have any questions @schneems!

You may also be interested in Concerning Yourself with ActiveSupport::Concern, Concerns in ActiveRecord and Better Ruby Idioms.

Partial Validation of Active Record Objects in Wicked

Tue, 17 Apr 2012 09:34:00 -0400

This question comes up a lot, people want to have an object, lets call it a Product that they want to create in several different steps. Let’s say our product has a few fields name, price, and category and to have a valid product all these fields must be present.

This is a re-post of a wiki I wrote for Wicked. While it was written to be used with a wizard, the pattern can be used without it. Enjoy!

The Problem

We want to build an object in several different steps but we can’t because that object needs validations. Lets take a look at our Product model.

class Product < ActiveRecord::Base
  validates :name, :price, :category, :presence => true

end

So we have a product that relies on name, price, and category to all be there. Lets take a look at a simple Wizard controller for ProductController.

class ProductController < ApplicationController
  include Wicked::Wizard

  steps :add_name, :add_price, :add_category

  def show
    @product = Product.find(params[:product_id])
    render_wizard
  end


  def update
    @product = Product.find(params[:product_id])
    @product.update_attributes(params[:product])
    render_wizard @product
  end


  def create
    @product = Product.create
    redirect_to wizard_path(steps.first, :product_id => @product.id)
  end
end

Here the create action won’t work because our product didn’t save. OhNo!

The Solution

The best way to build an object incrementally with validations is to save the state of our product in the database and use conditional validation. To do this we’re going to add a status field to our Product class.

class ProductStatus < ActiveRecord::Migration
  def up
    add_column :products, :status, :string
  end

  def down
    remove_column :product, :status
  end
end

Now we want to add an active state to our Product model.

def active?
  status == 'active'
end

And we can add a conditional validation to our model.

class Product < ActiveRecord::Base
  validates :name, :price, :category, :presence => true, :if => :active?

  def active?
    status == 'active'
  end
end

Now we can create our Product and we won’t have any validation errors, when the time comes that we want to release the product into the wild you’ll want to remember to change the status of our Product on the last step.

class ProductController < ApplicationController
  include Wicked::Wizard

  steps :add_name, :add_price, :add_category

  def update
    @product = Product.find(params[:product_id])
    params[:product][:status] = 'active' if step == steps.last
    @product.update_attributes(params[:product])
    render_wizard @product
  end

Great, but…

So that works well, but what if we want to disallow a user to go to the next step unless they’ve properly set the value before it. We’ll need to split up or validations to support multiple conditional validations.

class Product < ActiveRecord::Base
  validates :name,      :presence => true, :if => :active_or_name?
  validates :price,     :presence => true, :if => :active_or_price?
  validates :category,  :presence => true, :if => :active_or_category?

  def active?
    status == 'active'
  end

  def active_or_name?
    status.include?('name') || active?
  end

  def active_or_price?
    status.include?('price') || active?
  end

  def active_or_category?
    status.include?('category') || active?
  end

end

Then in our ProductController Wizard we can set the status to the current step name in in our update.

  def update
    @product = Product.find(params[:product_id])
    params[:product][:status] = step
    params[:product][:status] = 'active' if step == steps.last
    @product.update_attributes(params[:product])
    render_wizard @product
  end

So on the :add_name step status.include?('name') will be true and our product will not save if it isn’t present. So in the update action of our controller if @product.save returns false then the render_wizard @product will direct the user back to the same step :add_name. We still set our status to active on the last step since we want all of our validations to run.

Wow that’s cool, but seems like a bunch of work

What you’re trying to do is fairly complicated, we’re essentially turning our Product model into a state machine, and we’re building it inside of our wizard which is a state machine. Yo dawg, i heard you like state machines… This is a very manual process which gives you, the programmer, as much control as you like.

Cleaning up

If you have conditional validation it can be easy to have incomplete Product’s laying around in your database, you should set up a sweeper task using something like Cron, or Heroku’s scheduler to clean up Product’s that are not complete.

lib/tasks/cleanup.rake

namespace :cleanup do
  desc "removes stale and inactive products from the database"
  task :products => :environment do
    # Find all the products older than yesterday, that are not active yet
    stale_products = Product.where("DATE(created_at) < DATE(?)", Date.yesterday).where("status is not 'active'")

    # delete them
    stale_products.map(&:destroy)
  end
end

When cleaning up stale data, be very very sure that your query is correct before running the code. You should also be backing up your whole database periodically using a tool such as Heroku’s PGBackups incase you accidentally delete incorrect data.

Wrap it up

Hope this helps, I’ll try to do a screencast on this pattern. It will really help if you’ve had problems implementing this, to let me know what they were. Also if you have another method of doing partial model validation with a wizard, I’m interested in that too. As always you can find me on the internet @schneems. Thanks for using Wicked!

Performance Testing Rails with BlitzIO

Fri, 13 Apr 2012 11:57:23 -0400

Haven’t you always wanted to make some changes to your server and then absolutely slam it with traffic to see the result? Thats pretty much what I did last week while writing how to Super Charge your Rails App with Rack Cache, using the BlitzIO tool.

If you’re interested in trying out Blitz watch a demo in the screencast below.

For a walkthrough on how to add Rack::Cache and Memcache to your server read my performance article on the Heroku Dev Center.

Mama Schneems Deploys A Web App When my Mother asked me what I...

Thu, 05 Apr 2012 09:38:00 -0400

Mama Schneems Deploys A Web App

When my Mother asked me what I do at my new job at Heroku, I decided to grab a camera and show her. With a little help she deployed a Rails app that I made in around 30 minutes. How fast can your mom deploy your web app? Hi Def Video

Super Charge your Rails App with Rack Cache and Memcache

Wed, 04 Apr 2012 12:59:00 -0400

Slow is sweeping the nation: slow food, slow living, and slow reading. Unfortunately your app called, it said it wants to be fast. Web apps that respond quickly are more enjoyable to work with and Google even gives them a small SEO bump. Recently basecamp next got quite a bit of customer love based on how quickly it responds. The fact of the matter is if it’s on the web, fast matters.

This is based on an article I wrote for the Heroku Dev Center Using Rack::Cache with Memcached for Static Asset Caching in Rails 3.1+. If you have any questions ping me @schneems.

One of the quickest ways we can speed up your whole application is to add on HTTP caching. Not only does this mean we return static files quickly, we also reduce the overall load of your application. The easy answer to this hard problem is to configure your application to use Rack::Cache with Memcache.

Performance Testing

I did some load testing of the example app with the trial version of the BlitzIO addon. BlitzIO will hit whatever url you specify with as many simulated users as you want and graph the result for you. This is a run from 1 to 250 concurrent users over the course of 60 seconds with four dynos. Compare the default production settings to using Memcache with Rack::Cache.

Rails Default Settings

(Left is response time [peaks around 500ms] right is number of concurrent users represented by straight line, bottom is time of test )

Memcache & Rack Cache

(Left is response time [peaks around 100ms] right is number of concurrent users represented by straight line, bottom is time of test )

Here the Memcache & Rack::Cache combo smokes the default rails settings. If you want to run your own tests, you should know that each time you run BlitzIO, your performance graph will be different. I recommend running a few tests to make sure you’re not seeing a fluke. I also highly recommend doing any type of load testing on a staging server instead of production, or it could take down your site and your users wouldn’t be too happy.

Settings

So how can you, the speedfreak you are, get these types of results in your app? Long story short, you want to add this to your config/production.rb file:

config.action_dispatch.rack_cache = {
                        :metastore    => Dalli::Client.new,
                        :entitystore  => 'file:tmp/cache/rack/body',
                        :allow_reload => false }
config.static_cache_control = "public, max-age=2592000"

For more details on how to implement add this to your Rails app and why we chose these settings, please read the devcenter article or browse source on my demo app. Good luck, and enjoy the speed!

You got NoSQL in my Postgres! Using Hstore in Rails

Wed, 14 Mar 2012 14:40:00 -0400

Heroku just announced their support of hstore in their dedicated Postgres 9.1 instances. Hstore is a schema less key value store inside of PostgreSQL that allows us to store data like hashes directly inside of a column. It’s great for when you don’t know exactly what types of attributes you need to store on a model, or if you need to support many different attributes for the same model.

Update: You can now use Hstore with development databases on Heroku

A good example is storing attributes for a Product model. We might start out only selling books, which have an author, number of pages, but then transition over to selling laptops which have cpu speed and display resolution. Using Hstore allows us to easily store all these values without having to make a bunch mostly blank columns.

To get started with Rails and hstore you can watch the screencast below or visit the hstore example app running on Heroku.

More on Hstore

Hstore in Rails functions much like serializing hashes, except that we can query our data much faster since hstore is a native data type. It is supported natively in Rails 4, but until then we’ll need to use the activerecord-postgres-hstore gem.

Getting Started

You will need a version of PostgreSQL locally that supports the hstore extension. I recommend installing postgres using homebrew on OS X. Once you’ve done that you can enable hstore usage by running this in Postgres

CREATE EXTENSION hstore;

You can put this in a migration if you prefer

class SetupHstore < ActiveRecord::Migration
  def self.up
    execute "CREATE EXTENSION hstore"
  end

  def self.down
    execute "DROP EXTENSION hstore"
  end
end

Once that is done you will need to create a column with a type of hstore, here we are giving our Product model a column called data with hstore type.

class CreateProducts < ActiveRecord::Migration
  def change
    create_table :products do |t|
      t.string  :name
      t.hstore  :data
      t.timestamps
    end
  end
end

Once we’ve done that we can now store any type of attributes in the data column.

Product.create(:name => "Geek Love: A Novel", :data => {'author' => 'Katherine Dunn', 'pages' => 368, 'category' => 'fiction'})
Product.last.data['category']  # => 'fiction'

Querying

Not only does hstore allow us to store arbitrary keys and values it allows us to quickly query them.

  # Find all products that have a key of 'author' in data
  Product.where("data ? :key", :key => 'author')

  # Find all products that have a 'pages' and '368' key value pair in data
  Product.where("data @> (:key => :value)", :key => 'pages', :value => '368')

  # Find all products that don't have a key value pair 'pages' and '999' in data
  Product.where("not data @> (:key => :value)", :key => 'pages', :value => '999')

  # Find all products having key 'author' and value like 'ba' in data
  Product.where("data -> :key LIKE :value",     :key => 'author, :value => "%Kat%")

More information available in the Postgres hstore docs. Though like a normal column if you query it frequently, you can get even more speed by adding an index. You can do this using one of two indexes that also speed up full text searches. They’re GiST (Generalized Search Tree) or GIN (Generalized Inverted iNdex). Which sill speed up queries using the @> and ? postgres operators.

class Index < ActiveRecord::Migration
  def up
    execute "CREATE INDEX products_gin_data ON products USING GIN(data)"
  end

  def down
    execute "DROP INDEX products_gin_data"
  end
end

Use It

Try out the hstore example app, clone the Github repo, and let me know what cool things you build on twitter @schneems.

Thanks

Special thanks to Aaron Patterson and Joel Hoffman for their work with hstore & Rails4, to the team at Softa for writing this gem, & and the team at Heroku for their contributions to Postgres, and supporting this feature.

Get Down with Heroku at SXSW this year register now. It’s...

Wed, 07 Mar 2012 13:00:06 -0500

Get Down with Heroku at SXSW this year register now. It’s gonna be awesome.

I love doing screencasts, but hate the way my MBP mic sounds, so...

Wed, 07 Mar 2012 10:00:05 -0500

I love doing screencasts, but hate the way my MBP mic sounds, so I got a Rode Podcaster mic. You can see the difference in this quick video. All sound is raw and un-edited. I’m pretty happy with the purchase :)

Test Drive: Induction - The Everything Database Client for Mac

Tue, 06 Mar 2012 10:00:00 -0500

Join me for a quick demo of Induction, the latest project by @Mattt from Heroku. Induction will let you view your data-stores including: PostgreSQL, MySQL, SQLite, Redis, MongoDB, and so much more. The alpha product also lets you run queries, and visualize data.

Induction is completely free and open source, for more info visit the website or clone the repo.

Give Tumblr Some Code <3 with Prettify.js

Thu, 01 Mar 2012 10:00:06 -0500

Lets admit it, code and Tumblr don’t exactly get along right now. Sure you can write your posts in markdown, but there isn’t really an out of the box experience for syntax highlighting in code blocks.

In the past I’ve resorted to using Gists to store code in my blog, but this can be a hassle to manage, especially if you need to modify your code later. One day I noticed that one of my favorite blogs The Changelog has great code highlighting on their Tumblr blog. With a little view source-ing and a little googling I eventually found out that the best way to add code highlighting to your blog is through a javascript library called prettify.js. I followed these directions by blairvanderhoof, and came up with something not too bad. While his instructions are good, I made a few modifications. Lets take a look.

Link to the prettify.js CDN in your html, by customizing and putting this in right before the<body> tag:

<script type="text/javascript" src="http://cdnjs.cloudflare.com/ajax/libs/prettify/188.0.0/prettify.js"></script>

Add an the ‘prettyprint’ class to all <pre> tags that contain a <code> tag. Then initialize the prettyPrint() javascript method by adding this in your HTML:
```
$(document).ready( function(){
  $('code').parent('pre').addClass('prettyprint');
  prettyPrint();
});
```

Pick a prettify theme. I chose the Desert theme. Add that style to the Add Custom CSS under the advanced section, or directly to your HTML.

 /* desert scheme ported from vim to google prettify */
pre { display: block; background-color: #333; overflow:scroll; font-size:12px;  }
pre .nocode { background-color: none; color: #000 }
pre .str { color: #ffa0a0 } /* string  - pink */
pre .kwd { color: #f0e68c; font-weight: bold }
pre .com { color: #87ceeb } /* comment - skyblue */
pre .typ { color: #98fb98 } /* type    - lightgreen */
pre .lit { color: #cd5c5c } /* literal - darkred */
pre .pun { color: #fff }    /* punctuation */
pre .pln { color: #fff }    /* plaintext */
pre .tag { color: #f0e68c; font-weight: bold } /* html/xml tag    - lightyellow */
pre .atn { color: #bdb76b; font-weight: bold } /* attribute name  - khaki */
pre .atv { color: #ffa0a0 } /* attribute value - pink */
pre .dec { color: #98fb98 } /* decimal         - lightgreen */

/* Specify class=linenums on a pre to get line numbering */
ol.linenums { margin-top: 0; margin-bottom: 0; color: #AEAEAE } /* IE indents via margin-left */
li.L0,li.L1,li.L2,li.L3,li.L5,li.L6,li.L7,li.L8 { list-style-type: none }
/* Alternate shading for lines */
li.L1,li.L3,li.L5,li.L7,li.L9 { }

@media print {
  pre { background-color: none }
  pre .str, code .str { color: #060 }
  pre .kwd, code .kwd { color: #006; font-weight: bold }
  pre .com, code .com { color: #600; font-style: italic }
  pre .typ, code .typ { color: #404; font-weight: bold }
  pre .lit, code .lit { color: #044 }
  pre .pun, code .pun { color: #440 }
  pre .pln, code .pln { color: #000 }
  pre .tag, code .tag { color: #006; font-weight: bold }
  pre .atn, code .atn { color: #404 }
  pre .atv, code .atv { color: #060 }
}
.content pre code {background-color:inherit; color:inherit}
.content pre      { padding:1em; margin: 0.5em 0px; }

Note: I changed some of the Desert theme to play nice with my existing styles.

If your blog includes code snippets, you owe it to your audience to have good looking and readable syntax highlighting.

If you’re interested in getting started and aren’t already locked into a blogging platform, I recommend trying out Jekyll on Heroku it’s easy to set up and a real hackers blog. You also get syntax highlighting out of the box. Hope this helped & happy blogging.

Wizard-ify Your Rails Controllers with Wicked

Tue, 28 Feb 2012 10:00:00 -0500

If insanity is doing the same thing and expecting different results, I was going crazy writing step-by-step wizards. I was never happy with the end result, they did what I wanted, but were messy and had too many moving parts. I wanted a simple & re-usable way to create restful-ish controllers. Thats when I decided to rip out all that scary controller logic and bake it into in a Gem I call Wicked.

Wizards can be used for a number of things, they appear frequently after signing up for a service. They typically ask for additional information, or they give the user a tour of a service. Before I started working for Heroku, I helped out a bit on the peer learning site, Hourschool. Since students are most interested in the courses that are close to them, Hourschool asks users for their zip code. When a student signs up via Facebook, the zipcode isn’t directly exposed via the API. So to get that extra input, we decided to add an after register wizard to ask for this information and more. If you want to add similar functionality to your Rails site, you can watch the screencast, download an example, browse the source, or check out the getting started guide below.

Get Started

First install the gem, then inherit from Wicked::WizardController and you can specify a set of steps. Here we have a controller called AfterRegisterController with existing routes.

class AfterRegisterController < Wicked::WizardController

  steps :add_zip, :add_twitter, :add_friends
  # ...

Create a Show and Update action, calling render_wizard at the end of each which allows us to show the appropriate view for the step.

class AfterRegisterController < Wicked::WizardController

  steps :add_zip, :add_twitter, :add_friends

  def show
    @user = current_user
    render_wizard
  end

  def update
    @user = current_user
    render_wizard
  end
end

By default the wizard will render a view with the same name as the step. So you need to create view files for each step, in this case views/after_register/add_zip.html.erb & views/after_register/add_twitter.html.erb. In those views we can use wizard helpers to create links to the next step.

<%= link_to 'skip', next_wizard_path %>

Or you can manually specify which wizard action you want to link to by using the wizard_path helper.

<%= link_to 'skip', wizard_path(:find_friends) %>

Our :add_zip action can have a form that uses the wizard path and calls the update action. To get to this update action, you simply need to submit a form that PUT’s (or PATCH’s) to the same url:

<p>Please Fill in your zip code!</p>
<%= form_for(@user, :url => wizard_path, :method => :put) do |f| %>
  <%= f.text_field :zip, :placeholder => "zip code" %>
  <%= f.submit 'Next', :class => 'btn btn-primary' %>
<% end %>

<%= link_to 'skip', next_wizard_path %>

We then need to make sure our Signup wizard’s update action updates the current_user’s attributes. After modifying the user we can pass it into render_wizard, which will show the next step if the object saves or re-render the previous view if the user has validation errors.

def update
  @user = current_user
  @user.update_attributes(params[:user])
  render_wizard @user
end

If you want to skip showing a step under certain conditions you can do it by using the step method which returns a symbol of the current step you’re on, and skip_step if you don’t want to render the current step. So if we wanted to skip asking our users to authenticate with twitter if they skipped the add_zip step, we can do it like this:

def show
  @user = current_user
  case step
  when :add_twitter    
    skip_step if @user.zip.blank?
  end
  render_wizard
end

Redirect the user here after they are created in your system, and you have a fully baked after registration wizard. Thats all there is to it, just create a new view file every time you add a new step and you’re good to go. Please give this a try and message me at @schneems if you find any other really killer ‘wizard’ applications