Anti-pattern

Use Bundler.setup Instead of Bundler.require

2013-03-12

About two years ago I recommended using Bundler.require instead of Bundler.setup to automatically require and load gem dependencies. And in the spirit of changing my mind often I’m completely reversing my stance; using Bundler.setup is significantly better than Bundler.require.

The original reason I thought using Bundler.require was better was just a variety of bad habits leftover from Rails. Over the years Rails has changed a lot in how it handles dependencies. Gems used to be manually required, then were automatically required via Bundler. Code in the app folder has always been automatically required, and up until relatively recently so was code in the lib folder. The general message was and still is pretty clear; Rails implicitly—if not explicitly—discourages manual requiring. Over time this led me to the erroneous conclusion that manually requiring dependencies was repetitious and unnecessary. Why do something manually that can be done automatically?

But as I’ve gotten better my opinion has shifted the other way. There are some huge benefits to using Bundler.setup to set up load paths for gems, adding application directories to the load paths, and then manually requiring dependencies wherever they are used in an application.

It provides amazing design feedback and documentation

Manually requiring dependencies at the top of every file very explicitly tells you and anyone else exactly what dependencies that file has. This makes code easier to read, understand, test, and refactor. It also makes it painfully obvious when a class is too complicated. If a class needs more than five require statements to work there’s probably too much going on in that class.

It forces you to think about your dependencies and the cost associated with using them

Dependencies aren’t free. Every dependency you have adds complexity and increases coupling. Automatically loading all dependencies makes them seem like they’re free and can be used whenever and wherever in your application. Having to manually require a dependency to use it forces you to justify its use and keeps your dependency list lean.

It makes removing dependencies easier

If you automatically load all your dependencies when you load your environment, you have no way of knowing what parts of your application are using any given dependency. You’d have to manually search for class names, method names, and other ways of identifying a dependency in order to update it or remove it, which is tedious and error-prone. If you manually require dependencies, you can just search for the require statement and remove or replace the dependency.

The big question at the heart of this all is what is your application? Is it one monolithic, tightly-coupled mess? Or is it a structured collection of small, loosely-coupled objects? Using Bundler.require will lead you towards the former, but using Bundler.setup will help ensure you make the latter.

Ship Now, Not Later

2013-03-04

A few days ago I shipped a small project I’ve been working on called Arrival. It estimates arrival times for Apple products based on previous release cycles. Embarrassingly, this is something I’d been thinking about for the better part of two years, but it took until a few days ago for me to make it happen.

I first had the idea a few years back after I stumbled onto the MacRumors Buyer’s Guide and was shocked at how poorly it was designed and how terribly it visualized the data. I was sure I could do much better. So I spent a few days cranking out a rough version that was functional but lacked an amazing visual design. And that’s where I hit a wall. I think great design is imperative and there was no way I was going to ship a product that didn’t look amazing.

I spent the next two years sitting on it while I emailed designers to try and find someone to create the perfect design. Many expressed interest but most were ultimately too busy. Twice someone said yes and started working on it but dropped off as other things came up. Eventually I just gave up and shelved it, figuring I’d just meet the right person to work on it with eventually.

A month or two ago my friend Andy Keil reached out to me with an idea for an event called FinishUp Weekend. It’s the antithesis of Startup Weekend, the premise being that starting is easy, finishing is hard, so instead of starting something new let’s finish up the projects we already have. He asked if I’d be interested in going and I told him absolutely, and that I knew just what I was going to work on.

Two months later I flew down to Austin, met Andre Jurgensen (co-founder of Handsome) at the event and jammed it out over the next two days. I would love to say that the moment I told Andy I was going I had an epiphany and realized waiting for the perfect design was ridiculous, but the truth is, all through the weeks leading up to the event and even for a little bit while I was down there I debated whether or not I should ship it. It wasn’t until I met Josh Long, who came down to participate in the event and gave a small talk about Execute, a book he wrote—in three fucking days—that I realized how asinine I had truly been. If I’d waited to ship it until it was as perfect as I wanted it to be, I would never have shipped it at all.

The moment after I shipped Arrival was the best I’ve felt in a long time, and I already usually feel pretty good. The high I got from shipping it is better than any food I’ve ever eaten, any drink I’ve ever tasted, or any drug I’ve ever done. The first day Arrival received 30,000 hits, three days later it has received over 60,000 hits, and the feedback has been nothing but positive. If you have an unfinished project that hasn’t shipped yet because you’re still perfecting it and it doesn’t quite meet your expectations, remember that you’re the only thing standing in your own way. Stop fucking around and ship it.

Litany Against Distraction

2012-11-02

I must not get distracted.
Distraction is the mind-killer.
Distraction is the little-death that brings total obliteration.
I will face my distraction.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the distraction has gone there will be nothing.
Only I will remain.

Upgrading from PostgreSQL 9.1.x to 9.2.x with Homebrew

2012-10-13

I use Homebrew to manage my packages on OS X. It makes installing them dead-simple and keeping them up-to-date dead-easy. But the one package which I always try to upgrade and always winds up breaking my setup is PostgreSQL. It seems like every single minor version (according to Semantic Versioning) upgrades fine, but then fails to start, and because I start the processes on login and run them in the background using launch agents, it’s never immediately obvious that the upgrade didn’t work, why it didn’t work, or what I need to do next to get it to work.

This most recently bit me again when upgrading from 9.1.x to 9.2.x because apparently the database format changed and needed to be upgraded. I know how to do it and have done it several times in the past, but I still forget every time. So I’m documenting it here for myself and everyone else who forgets.

NB: The exact commands differ depending on which patch level of 9.1.x you’re upgrading from and which patch level of 9.2.x you’re upgrading to. So make sure to change the x’s to the proper patch level in the commands.

brew update
brew upgrade postgresql
launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
mv /usr/local/var/postgres /usr/local/var/postgres91
initdb /usr/local/var/postgres -E utf8
pg_upgrade \
  -b /usr/local/Cellar/postgresql/9.1.x/bin \
  -B /usr/local/Cellar/postgresql/9.2.x/bin \
  -d /usr/local/var/postgres91 \
  -D /usr/local/var/postgres
cp /usr/local/Cellar/postgresql/9.2.x/homebrew.mxcl.postgresql.plist ~/Library/LaunchAgents/
launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

This will upgrade to the latest version of postgres, stop the process, move your database to a new location, initialize a new database, port your data from the old database to the new database, create a new launch agent, and start the process.

After you’ve confirmed that postgres has started, everything is working properly, and your old data has been properly converted you can remove the original database.

rm -rf /usr/local/var/postgres91

The Repository Pattern and Proper HTTP Status Codes

2012-10-12

Suppose you are building an API and you need one of the resources to be upsertable—that is, you need to be able to either insert or update data from the same endpoint. Assuming you’re using Rails, it might look something like this.

def upsert
  @pickle = Pickle.new params[:pickle]

  if existing_pickle = Pickle.find_by_id(@pickle.id)
    @pickle = existing_pickle.assign_attributes = params[:pickle]
  end

  @pickle.save

  render :pickle
end

This isn’t bad, but all the cool kids are using the Repository pattern (which is really just a Facade for persistence layers) to abstract ActiveRecord away from the domain as much as possible. So something like this might be better.

def upsert
  @pickle = PickleRepository.create_or_update(params[:pickle])

  render :pickle
end

Now that is a delicious PicklesController. But it’s not quite finished. If the @pickle has any errors and can’t be created or updated, we’re still going to be returning a 200 OK response. That’s bad form. We can check if it has any errors and change the status accordingly.

def upsert
  @pickle     = PickleRepository.create_or_update(params[:pickle])
  http_status = @pickle.errors.any? ? :unprocessable_entity : :ok

  render :pickle, status: http_status
end

Excellent. Now we’re returning a 422 Unprocessable Entity if the @pickle has validation errors. But it’s still not quite finished. We’re returning a 200 OK if the resource is created. Although technically incorrect, that’s probably fine for most cases. But what if the client needs to know whether the request resulted in a resource being created or a resource being updated? Well there’s actually a different HTTP status code for that, 201 Created. So let’s just implement that and… crap, in the process of isolating persistence we’ve also removed our ability to determine if the object was saved or updated. What to do?

After poring over the Rails docs for an hour or two I found that you can kind of introspect the state of an object after saving using ActiveModel::Dirty#previous_changes. If previous_changes includes a key named id, it’s (probably) a new object and should return a 201 Created, otherwise it’s an update and should return a 200 OK. All together now.

def upsert
  @pickle     = PickleRepository.create_or_update(params[:pickle])
  http_status = HTTPStatusCode.new(@pickle).from_model

  render :pickle, status: http_status
end

# lib/http_status_code.rb
class HTTPStatusCode

  attr_reader :model

  def initialize(model)
    @model = model
  end

  def from_model
    unprocessable_entity || created || ok
  end

private

  def unprocessable_entity
    :unprocessable_entity if model.errors.any?
  end

  def created
    :created if model.previous_changes.include?("id")
  end

  def ok
    :ok
  end

end

GitHub Is Your Resume Now

2012-06-17

If you’re a programmer, the days of sending a CV when you apply for a job are quickly coming to an end, if they haven’t already. No one really wants to see your poorly formatted, badly designed Microsoft Word template filled with irrelevant information you’ve carefully curated to make you look like the best programmer ever, least of all me. I just want to see what you’ve built and how you built it, and the best way to see that is by looking at your GitHub account.

The problem is that while most programmers seem to understand and even embrace GitHub as the new resume, few if any seem to have actually put any thought or time into making their GitHub accounts look and work well as such.

GitHub is more than just your social backup storage, it’s your portfolio and it’s public. You can’t just dump everything there willy-nilly or your account is going to look like shit, which it probably does.

So here are some really obvious things that most people do wrong with their GitHub accounts. Hopefully it’ll help.

Too many forked repositories

There’s nothing more annoying than looking at someone’s GitHub account and seeing a bunch of forked repositories. If you have to maintain a fork for some reason then fine, sometimes that’s necessary. But most of the time you just make a fork to fix something, and then the changes get accepted upstream and you’re done. If that happens delete the repo! Why are you holding on to it? You can always re-fork it the next time you want to work on it. As a rule, if you have a forked repository its commit graph better have a ton of blue in it, otherwise it’s just noise in your account.

GitHub is your portfolio. A common mistake designers and artists make is adding anything and everything they’ve ever done to their portfolios, and then never getting rid of anything. They could do an entire spin-off of Hoarders based around creative peoples’ portfolios—it’s that bad. Don’t make the same mistake with your GitHub account. Be judicious about what you add; you have to curate your work, otherwise your signal-to-noise ratio drops.

Missing or unclear descriptions

Every project needs a clear, concise description. I don’t want to have to read all your code in order to divine what your project does. If you can’t tell me in one sentence what your project does, then you probably don’t even understand the problem well-enough to be solving it.

Old repositories

The work you did a year or more ago couldn’t possibly still be relevant today. If it is, you aren’t working hard enough or learning fast enough. Get rid of anything you haven’t worked on in over a year.

Mediocre code

Quantity never trumps quality. If I see a few projects with mediocre code I just extrapolate and assume all the projects are mediocre and stop looking. I’d rather see two really good projects and nothing else than eight mediocre ones mixed in with three good ones. Only add projects to your account if you truly think it’s great or useful work.

Like it or not, GitHub is your resume now, and the projects you choose to show tell everything about you, especially where you are spending your time and how wisely. Don’t waste your time building unimportant things. Identify a serious problem and write some really good, well-tested code that makes it better. Then put it on GitHub so the world can see, keeping in mind the issues I just outlined. Take good care of your GitHub account and it will take good care of you.

Static Sites on Heroku

2012-06-02

I’ve been using Heroku to host my Ruby applications pretty much since day one. Not having to waste countless hours managing servers or dealing with crappy shared hosting control panels is fantastic and I can’t recommend it highly enough. But I’ve always had a number of static HTML sites, and I didn’t really know what to do with those, so I just kept them on old-school shared hosting. Then about a year ago I finally got fed up with having to FTP into my shared server to make changes—managing my static sites should be as easy as managing my web apps.

My first thought was to use Sinatra, an awesome, lightweight Ruby application framework. But that’s way overkill to just serve some static HTML files. However, Sinatra is built on top of Rack, a common interface for building Ruby applications. Ruby on Rails, Sinatra, and all other Ruby web frameworks use it. I realized I could just write a really simple Rack app to serve my various static sites.

At its simplest, a Rack app is just an object that responds to a call method, and returns an Array of three things. A status code, a Hash of HTTP headers, and an Array of Strings that make up the body. The Rack app that runs my personal site looks like this:

# Gemfile
source "http://rubygems.org"

gem "rack"

# config.ru
require "rubygems"
require "bundler"
Bundler.require(:default)

map "/" do
  use Rack::Static, urls: ["/assets"], root: Dir.pwd

  run lambda { |env|
    headers = {
      "Content-Type"  => "text/html",
      "Cache-Control" => "public, max-age=86400"
    }
    body = File.open("#{Dir.pwd}/index.html", File::RDONLY).read

    [200, headers, [body]]
  }
end

I put my images, stylesheets, and javascripts in the assets folder, toss an index.html file in the root and that’s it.

The Fountain of Youth

2012-03-15

I, and many smarter people before me have noted that time is the only truly limited resource. Everything else we can get more of, but time we can never get back. We’re using it literally all the time, and one day we’ve used it all up and we’re gone. As someone with a never-ending list of things to do that will surely extend beyond my alotted time, I find this rather unfortunate.

Many would argue that this is the natural order of things and the way it should be. That it is time’s limited nature that makes life so great, and that death is a necessary, natural change agent. I’m inclined to agree, but still, no one wants to die, and given the option, most would surely stave it off for as long as possible. Hence humanity’s nearly-eternal search for the fountain of youth—in whatever form it might take—in order to gain more time.

Personally I consider it a noble endeavor, and I’d like to join in the pursuit, but I’m no Spanish Conquistador, and despite being a programmer my science aptitude is tenuous at best, so those avenues are kind of out. But there is another way that seems to be largely unexplored, or at least I’ve never heard anyone else mention it. And that is using time’s relative nature to alter your own perception of it. It’s something we do every day, albeit unintentionally. The speed at which we perceive time ebbs and flows, and we notice it—we even point it out to other people after it’s happened—but we never really seem to pinpoint why it happens. In order to do that, we have to look at when.

The most obvious example is childhood. When you look back on it, you remember growing up seeming to take eons, but as you get older time seems to accelerate exponentially. This could of course just be something about the way children perceive time, which I think is the common wisdom. But there are times when adults perceive time the same way, most notably when on vacation. You can even just go away for the weekend and it can seem like you’ve been gone for two weeks. The only real common denominator between the two is new, or varied experiences. For children, everything is new all the time. As they get older, things become more familiar and repetetive, until finally they’re just doing the same thing day in and day out until they die. Which is why time seems to accelerate as you get older. The longer you do the same thing over and over again, the quicker time will fly by. Vacations are little pockets of varied experiences that interrupt the normal pattern of your life, which is why they seem to last way longer than they actually do.

So what that means is that in order to slow down time, all you have to do is mix it up every single day; have lots of different experiences as often as you can. New restaurants, new clothes, new friends, new cities, new jobs. You don’t have to give up the old, but make sure you get a healthy dose of new. People will probably think you’re weird, but if they ask you about it, just tell them you’re trying to live forever.

Require Sprockets When Not Using ActiveRecord

2011-08-15

If you use MongoMapper or Mongoid (or anything other than ActiveRecord) and recently upgraded to Rails 3.1.0.rc5, you may have noticed that the asset pipeline stopped working even thought it was working fine in 3.1.0.rc4. That’s because in rc5 the sprockets/railtie require is now explicit.

Just add require 'sprockets/railtie' to your config/application.rb file and you should be golden. Like this:

# config/application.rb
# require 'rails/all'
require 'action_controller/railtie'
require 'action_mailer/railtie'
require 'active_resource/railtie'
require 'sprockets/railtie'

Suppressing Notice Messages with PostgreSQL on Rails

2011-08-04

If you’re using SQL, then you’re probably using PostgreSQL. And if you’re using PostgreSQL, then you probably get those annoying as hell notice messages outputted everywhere when you do anything that alters the database schema. They look something like this:

NOTICE:  CREATE TABLE will create implicit sequence "groups_id_seq" for serial column "groups.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "groups_pkey" for table "groups"
NOTICE:  CREATE TABLE will create implicit sequence "projects_id_seq" for serial column "projects.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "projects_pkey" for table "projects"

So annoying. And the more tables your project has the more annoying it gets. I first noticed it a year or so ago and have been half-assedly trying to fix it ever since. Google suggests putting various combinations of SET client_min_messages TO WARNING; in a .psqlrc file, but no matter what I tried I could never get it to work, so I always gave up.

Until today, when I finally got so fed up with it that I decided I wouldn’t do anything else until I figured it out. Three hours later I got it, kind of.

What eventually worked was setting min_messages in the database.yml.

# config/database.yml
defaults: &defaults
  adapter: postgresql
  encoding: unicode
  min_messages: warning

development:
  <<: *defaults
  database: something_development
  username:
  password:
  pool: 5

It’s not ideal, I would have rather it been something global that I could put in my dotfiles than have it per project, but this will do for now.

Sinatra Gotcha

2011-06-19

You know how they always say to not forget to include a favicon and robots.txt and whatnot in your website or app so browsers and bots don’t fill up your error logs with 404’s? Yeah, well, don’t forget that if you have a catch-all route in your app and those resources don’t exist they’re not going to 404, they’re going to mysteriously throw a 500 on nearly every request.

I know you wouldn’t make a stupid, obvious mistake like that and spend twenty minutes staring at your error logs trying to figure out what the hell is going on. But I figured I should mention it anyways. You know, just in case.

Adjusting Your Privates in Public

2011-05-29

The title is a stretch—I know—but I couldn’t resist.

Like most programmers I have a fairly strong opinion about how code should be indented and formatted. And while much of formatting is subjective and comes down to personal preference, there are many times when one could probably make a solid, logical argument as to why one particular method is better than the others.

I think one such instance would be the handling of private and protected declarations in classes and modules. Here are the methods I’ve seen:

Method 1

class Stuff

  def something_public
    #
  end

  private

    def something_private
      #
    end

end

This is, in my opinion, the most awful. It’s easy to see where the private methods start, but something just feels very off. Having some methods indented once and others indented twice feels more inconsistent than helpful. And in a long file if nothing is currently visible except twice-indented methods, with no other points of reference it might not be evident that the methods are in fact twice-indented, in which case they may as well not be.

Method 2

class Stuff

  def something_public
    #
  end

  private

  def something_private
    #
  end

end

This is by far the most consistent. Everything is only indented once, which makes it fairly easy to parse. But when scrolling through a long file the private declaration blends right in.

Method 3

class Stuff

  def something_public
    #
  end

private

  def something_private
    #
  end

end

This is the one I use. I believe it combines the best of both other methods. Everything is indented once for easy visual parsing, but the private declaration is left flush with the edge of the document to provide a nice visual break when scrolling through a long file.

If you’re of a different mind than I on the method to use and/or the reasoning behind it I’d love to hear from you.

Case-insensitive Keys with Devise

2011-05-16

If you use Devise for authentication and deploy on Heroku, or really just use any database that is case-sensitive by default (like PostgreSQL), you’ve probably run into the problem that some users like to type certain letters in their logins (email and/or username) in uppercase, but expect it to be case-insensitive when they try to sign in. A not unreasonable request considering that’s pretty much the universally default behavior that most applications exhibit, but that’s not the default with Devise.

Unfortunately, if you google the problem, the most common solution given is to downcase the login in a before_save callback so that it’s always lowercase in the database, and then overriding like eight different methods on several different controllers to downcase the login in the params. Thus always comparing a lowercase submitted login to a lowercase login in the database. Besides being annoyingly overcomplicated, it strips users of their ability to capitalize their login as they so choose, which is the whole reason this problem exists in the first place.

Devise should really have a way to do this automatically, and it does as of a few months ago in version 1.2 and later, although the way their wiki is set up makes it difficult to find. Here it is in all its one-line glory.

# config/initializers/devise.rb
Devise.setup do |config|
  config.case_insensitive_keys = [:email, :username]
end

Maybe this will push the old/incorrect answers out of the search results.

Adding a New Strategy to OmniAuth

2011-04-24

Recently I had to authenticate with a service (Rdio) that OmniAuth didn’t support yet. I’d never created an authentication strategy before, so I looked up how to do it in the wiki. The supposed Strategy Contribution Guide was rather… sparse, so I had to roll up my sleeves and figure it out.

First, you need to set up an environment to work on the gem. So fork the official repo and then clone your fork. If you don’t have bundler, install it, then bundle install from inside your cloned repo.¹ Run the tests with bundle exec rake spec and you should see all green.

OmniAuth supports multiple different authentication schemes, but Rdio thankfully uses OAuth. Each authentication scheme has a separate gem/directory, so I looked in oa-oauth/lib/omniauth/strategies to see how other OAuth strategies had been implemented. OAuth has a few different versions now, so make sure you’re looking at examples that use the same OAuth version as the API you’re trying to connect to supports. Rdio uses OAuth 1.0, so those are the strategies I looked at.

I started by copying the module/class structure from another strategy into a new file and renaming the class where appropriate.

# oa-oauth/lib/omniauth/strategies/rdio.rb
require 'omniauth/oauth'
require 'multi_json'

module OmniAuth
  module Strategies
    #
    # Authenticate to Rdio via OAuth and retrieve basic user information.
    # Usage:
    #    use OmniAuth::Strategies::Rdio, 'consumerkey', 'consumersecret'
    #
    class Rdio < OmniAuth::Strategies::OAuth

    end
  end
end

Then I started looking for other similarities among the various strategies. There’s a fair bit of variance in which methods are implemented and the naming of variables, but the first method that all strategies had in common was initialize.

# oa-oauth/lib/omniauth/strategies/rdio.rb
def initialize(app, consumer_key = nil, consumer_secret = nil, options = {}, &block)
  opts = {
    :site               => "http://api.rdio.com",
    :request_token_path => "/oauth/request_token",
    :access_token_path  => "/oauth/access_token",
    :authorize_url      => "https://www.rdio.com/oauth/authorize"
  }
  super(app, :rdio, consumer_key, consumer_secret, opts, options, &block)
end

I was lucky and the paths were very clearly listed in the API docs. All I did here was switch out the paths and change the second argument passed to super to :rdio.

The next common method was auth_hash. The auth_hash is the data that is returned after you successfully authenticate with a service. It has info like the provider, the provider-specific id, name, username, etc.

# oa-oauth/lib/omniauth/strategies/rdio.rb
def auth_hash
  OmniAuth::Utils.deep_merge(super, {
    'uid'       => user_hash['key'],
    'user_info' => user_info,
    'extra'     => { 'user_hash' => user_hash }
  })
end

def user_info
  user = user_hash
  {
    'nickname'   => user['username'],
    'first_name' => user['firstName'],
    'last_name'  => user['lastName'],
    'name'       => "#{user['firstName']} #{user['lastName']}"
  }
end

def user_hash
  @user_hash ||= MultiJson.decode(@access_token.post("http://api.rdio.com/1/", {
    :method => 'currentUser',
    :extras => 'username'
  }).body)['result']
end

This part required a bit of trial and error, because although the docs indicate what fields are required, they don’t say which are returned automatically and which have to be retrieved from the provider’s API. Eventually I figured out that provider and credentials are automatically set, everything else has to be retrieved from the API. Look in the API docs for the specific request that will return information about the current user. Hopefully the docs are good and/or they have an API explorer so you can play around with it and see exactly what data is returned and in what format it’s in.

Once you’ve got that figured out, map the fields returned to their appropriate values in the auth_hash. A fairly common pattern is to also just stick the whole hash returned under extra, in case there were some extra fields that couldn’t be mapped.

There are several other methods that some strategies implement, but after more trial and error it seems like the only two methods that absolutely have to be implemented are initialize and auth_hash.

Now make sure your new strategy is loaded.

# oa-oauth/lib/omniauth/oauth.rb
require 'omniauth/core'

module OmniAuth
  module Strategies
    ...

    autoload :Rdio, 'omniauth/strategies/rdio'
  end
end

Create a test for it.

# oa-oauth/spec/omniauth/strategies/rdio_spec.rb
require File.expand_path('../../../spec_helper', __FILE__)

describe OmniAuth::Strategies::Rdio do
  it_should_behave_like "an oauth strategy"
end

Update the readme.

# README.markdown
* Rdio (via [brandonweiss](http://github.com/brandonweiss))

And you’re done. Now you’ll probably want to try it out to make sure it works. The easiest way is to just open up the project that’s going to use the new strategy and edit the Gemfile to look for omniauth locally.

# Gemfile
gem 'omniauth', :path => '~/Code/omniauth'

bundle install then start the server and you should be good to go. If you messed something up, fix it, then restart the server to pick up the changes.

OmniAuth is a really amazing gem. Hopefully this will make it easier for people to add more strategies.

Make sure you have the latest version of Bundler; I was on 1.0.7 and ran into gem version conflict errors. The fix was to upgrade to 1.0.12.↩

rack-pagespeed on Heroku

2011-04-16

TL;DR Use memcached, not disk storage

A few weeks ago I heard about rack-pagespeed and decided to use it on this blog. A week later I was randomly checking out the site and found it completely unstyled. The CSS file that rack-pagespeed had generated was throwing a 404. I scratched my head a bit, asked on GitHub and realized that I’d stupidly been using the tmp directory for storage. It’s called a temp directory for a reason, and Heroku was flushing it out periodically, hence why it looked fine after a deploy but broke a little while later.

The solution is to use a persistent cache like memcached. Depending on the size of your site and the amount of CSS/JS you have, this might not really be worth it, but assuming it is, here’s how you do it.

First install memcached locally using Homebrew¹:

$ brew install memcached

Then just specify the store as memcached. Heroku can sometimes be finicky about relative paths, so I like to be really explicit and set the root of the app to the current directory, then build off that. settings is just a class method on the rack app, so you can access it from outside the app²:

# minimalog.rb
class Minimalog < Sinatra::Base
  set :root, File.dirname(__FILE__)

  ...
end

# config.ru
use Rack::PageSpeed, :public => "#{Minimalog.settings.root}/public" do
  store :memcached
  combine_css
end

Redeploy to Heroku and everything should be good.

If you don’t use Homebrew I feel bad for you son, I’ve got 99 problems but manually building packages myself isn’t one.↩
This specific example is for Sinatra, but it’s very similar for Rails.↩

Maintaining Complex Systems

2011-04-04

I’ll never understand why more nerds don’t go to the gym and exercise regularly. It’s all about keeping the ultimate system performant. Isn’t that the nerdiest possible endeavor?

Dirty Associations with ActiveRecord

2011-03-22

Imagine you have a system in which it’s advantageous to know when an object was last updated. Perhaps it’s just useful for users to know how fresh the data is, or maybe some operations need to run only on recently updated objects.

With ActiveRecord this is really simple, because it automatically looks for DateTime fields called created_at and updated_at, and if they exist will update them when an object is created and updated, respectively. But what about associations?

For example, if a lolrus has and belongs to many buckets, and you add a new bucket to that lolrus, has that lolrus then been updated? From a framework perspective, no. The lolrus object never changed, nor did the bucket object, just a new relation was created between them. No objects were updated. But from a user’s perspective, yes, they updated information on the lolrus, so the updated_at field on the lolrus should reflect the current data and time. But it won’t.

When you update fields on a model, those changes are tracked in a hash. And when a model is saved, it calls a method called changed?, which checks to see whether or not the hash is empty. If it’s empty, ostensibly nothing changed, and so the updated_at timestamp is left alone. If it’s not empty, then one or more attributes changed and the updated_at is set to the current time. But associations are not tracked in this hash, so modifying them will not flag a model as being dirty, and thus the timestamp will never be updated. This isn’t a bug—it’s working as intended—but in certain situations that behavior is not going to be what the user expects.

So if you want to update the timestamp of an object when the associations change as well, here’s how you do it:

# app/models/dirty_associations.rb
module DirtyAssociations
  attr_accessor :dirty

  def make_dirty(record)
    self.dirty = true
  end

  def changed?
    dirty || super
  end
end

# app/models/lolrus.rb
class Lolrus
  include DirtyAssociations

  has_and_belongs_to_many :buckets,
                          :after_add    => :make_dirty,
                          :after_remove => :make_dirty
end

This works because callbacks can be defined on ActiveRecord associations. When an object is added or removed from the collection, the make_dirty callback will be triggered and a virtual attribute representing whether or not the object is dirty will get set to true. Then when changed? is called to check whether an object is dirty, it will check the virtual attribute first before deferring to super.

Mad props to Tim Galeckas for helping me sort this one out. You don’t even want to know the janky shit I had half-written to solve this.

You Had Better Be Able to Answer These Questions in an Interview

2011-01-21

Interviewing isn’t something I have to do often, but I’ve had to do it enough times that I’ve been able to formulate a good set of questions to ask a potential candidate. The questions are not particularly crazy or complex—they’re actually a lot simpler than most of the questions I’ve been asked in interviews—but together they easily weed out people who aren’t amazing. A truly skilled person should have no problem answering them, but they’ll be impossible for anyone else.

The reason these questions work is there’s no way to study for them. They can’t be memorized or planned for because they don’t really have ‘right’ answers. You either have a cogent answer or you don’t. And the only way you could come up with a good answer that makes sense is if you are the right type of person with the right type of knowledge to begin with. It’s almost always immediately evident whether I’m talking to the right person or not.

If you’re looking to hire someone, try asking candidates these questions and see what they say. Even if you aren’t necessarily knowledgeable about the position you’re hiring for, you should be able to tell if they’re a good fit by how much they have to say about each one. If the person is worth their salt you won’t be able to get them to shut up.

And if you’re a person looking to be hired, this is an excellent way of finding out if you’re in the right field or not. If you can’t answer all of these questions and answer them well, you either need to step up your game or find something else to do, because I may have written these up but they aren’t just my questions. Any good person or company will probably ask some variant of these when interviewing you, and if you can’t answer them it’s going to be dead obvious that you’re either not passionate about your field or just don’t have what it takes to compete in it.

So without further ado, the questions¹:

Who are your heroes?: Everyone has someone they look up to in their field. Leaders, luminaries, people who are pushing their craft forward. If you can’t name at least five people and be able to talk at length about what you’re learning from them then that tells me that you’re not really in your field. It would be like an electrical engineer in the 19th century not knowing who Nikola Tesla was.
Who do you follow? What do you read?: This is somewhat related to the last question, but it’s not enough to just know of some famous people in your field. You need to be constantly reading and learning from them, but also others, too. If you tell me you read the top five blogs in your field, that’s great, but that tells me you only know exactly what everyone else knows, when everyone else knows it. Someone who is really entrenched in their field will have spent the time to find good, obscure sources that most people don’t know about.
Who have you collaborated with?: This demonstrates three things. One, that you’re part of the community and know your peers. Two, that you’re skilled enough for your peers to recognize it and want to work with you. And three, that you’re passionate enough about your field to want to do it outside of work.
What are you working on personally?: This is commonly a taboo topic. It’s considered a big faux pas to speak of plans beyond a company, lest you be perceived as disinterested or uncommitted. But a good employer will want employees that have dreams and aspirations beyond working for them. Logically you would think a company would want to hire people that will stay forever, but usually the qualities these people possess are the exact opposite of what a good employer should want. People who have the drive to be something more than just another employee will inevitably leave, but during their stay they will probably do better work and be better for the company than your average lifer. Having one or more side projects underway is a good sign you’re that type of person.
What are you currently learning?: You should always, always, always be learning. Both in your field and outside of it. You should be perpetually overwhelmed with the amount of stuff you still have yet to learn. There should never be a time in which you’ve learned everything there is to learn about anything. If you’ve stopped learning things in your field and are content to keep doing the same things you’ve been doing, then you’ve already been left behind and just aren’t aware of it yet.
What do you do outside of work?: This is basically a gimme; everyone does something outside of work. But what they answer tells me how interesting the person is, whether or not I’d get along with them and most importantly whether or not they challenge themselves, as that’s going to be a good indicator of if they’re going to challenge themselves at work. So if you collect stamps or scrapbook that’s cool, but I’m looking for someone who’s learning to arc weld and trying to become a master surfer.

I’m a web developer, so I came up with these questions with my field in mind, but none of them are really field-specific. They’re all agnostic enough that they should apply to any job in any field that requires creative thought.↩

Bundler.setup vs. Bundler.require

2010-12-20

Update: I’ve changed my opinion. Use Bundler.setup instead of Bundler.require.

TL;DR Use Bundler.require instead of Bundler.setup

I think pretty much everyone knows that when you use Bundler with Rails 3, you don’t have to require your gems manually; it’s just all taken care of when you define them in the Gemfile. But I think a lot of people don’t understand exactly how this works, because when I see Bundler used outside of Rails, I consistently see gems being defined in the Gemfile and then manually required in the app.

I’m guessing this is because in the Bundler docs the most prominent example tells you to use Bundler.setup, and so people assume the auto-requiring is part of Rails and do this:

# Gemfile
source 'http://rubygems.org'

gem 'sinatra'
gem 'haml'

# config.ru
require 'rubygems'
require 'bundler'
Bundler.setup(:default)

require 'sinatra'
require 'sinatra/base'
require 'haml'

But actually it’s all Bundler. Instead of Bundler.setup you can call Bundler.require, which will not only set up the load paths but also require the gems as well. This is how Rails automatically requires the gems you specify. So the best way to do it (in most situations) is like this:

# Gemfile
source 'http://rubygems.org'

gem 'sinatra', :require => 'sinatra/base'
gem 'haml'

# config.ru
require 'rubygems'
require 'bundler'
Bundler.require(:default)

Note that you can specify a different name to require a gem by if the file name happens to be different from the gem name. And, as an added bonus, you can pass in multiple groups to Bundler.require, so you could also include gems specific to the current environment like this:

Bundler.require(:default, ENV['RACK_ENV'].to_sym)

Being a Good Jedi

2010-12-15

A few weeks ago I read a blog post by Rob Conery called Be a Good Jedi: Build Your Own Blog. If you’ve been trying and failing to start blogging I suggest you read it. I’d been trying to get a blog up and running for the past several years, but I hadn’t been able to do it because I’ve never been happy with any of the blogging engines I’ve tried. And it wasn’t for lack of options; I’ve tried WordPress, Drupal, Mephisto, Typo, Symphony, Enki, Jekyll and toto. But every single one of those fell short in some way. There was a steady progression towards minimalism, eventually moving away from database-backed engines altogether with Jekyll and toto, but even the most minimalist engines didn’t quite work how I wanted, or weren’t extensible in the way I needed. Eventually I realized I’d just need to build my own, but my time was in extra short supply those days and the whole thing got shelved.

Until reading Rob Conery’s blog post jump-started it again. And so after a couple nights of hacking I have this. I’m calling it minimalog (the engine, not the blog itself). It’s a git-based Sinatra app that parses markdown files. That’s it. It’s a lot like toto, except it does all the things that I couldn’t get toto to do, and it’s a lot less complex. It’s not open-source currently, but at some point I plan to abstract it into a gem, at which point I’ll release it.

First Post!!!1

2010-12-14

Have to start somewhere.