The Napkin ~ A Blog By Highgroove Studios

MerbCamp Registration Open

Tue, 9 Sep 2008 14:15:00 EST

MerbCamp is the first official gathering for the Merb community.

Our own Matt Todd is speaking on “Going Beyond Web Sites with Merb”—where he’ll talk about using Merb to do things other than just your run-of-the-mill web-sites—things like APIs, Web Services, lightweight protocols, and making your grass greener. Well, maybe not that last one.

You can Register at:

http://merbcamp.com/

Looking for insight? Skip the coffee

Mon, 11 Aug 2008 23:35:00 EST

It hurts – it feels like giving up. You’re stuck on a problem and do the last thing that makes sense – stop thinking about it. And the minute you forgot about the problem the solution comes into focus. Sometimes it’s a shower, for others it’s a long walk or playing a video game.

The Eureka Hunt – Why do good ideas come to us when they do?, an article by Jonah Lehrer published in the the July 28th issue of the New Yorker, covered scientific research on moments of insight. There were a couple nuggets on provoking insights:

Simmer down the focus. Avoid things that help you focus (like caffeine).

If you’re in an environment that forces you to produce and produce, and you feel very stressed, then you’re not going to have any insights…Concentration, it seems, comes with the hidden cost of diminished creativity.

John Kounious, Cognitive Neuroscientist, Drexel University

Set the alarm clock a few minutes early

The drowsy brain is unwound and disorganized, open to all sorts of unconvential ideas. The right hemisphere is unusally active.

Get in a good mood

Jung-Beeman’s latest paper investigates why people who are in a good mood are so much better at solving insight puzzels (On average, they solve nearly twenty per cent more C.R.A. problems.)

Matt Todd to speak at RubyFringe

Fri, 11 Jul 2008 10:51:00 EST

We’ve had the pleasure of working with Matt Todd recently on several Highgroove projects.

Matt’s going to be speaking at RubyFringe, “an avant-garde conference for developers that are excited about emerging Ruby projects and technologies” on July 18-20, 2008 in Toronto, Canada.

And while there is a very clever joke I could insinuate about Matt’s talk entitled Being Dumb And Using It To Your Advantage, on Matt being “the expert on dumb,” I can’t quite come up with it—and then there’s the fact that he is actually really frickin’ smart.

If you’ve ever thought of an idea, only to convince yourself “eh, that’ll never work, that’s a dumb idea”—his talk will make you think otherwise.

Say hello at RailsConf

Wed, 28 May 2008 21:32:00 EST

Andre, Charles, and myself leave for RailsConf Thursday.

If you want to discuss Rails monitoring, Javascript, the business of Rails, biking, camping, or dogs, talk to us!

I’m the tall, skinny scarecrow-like figure with the big head. Charles looks like he might belong to a hipster boy band. Andre…well he looks completely normal. Just look for the scarecrow and the hipster – Andre will be the other one in our group.

Development with Rails + Passenger (AKA mod_rails) on Mac

Tue, 27 May 2008 08:18:00 EST

Passenger, AKA mod_rails

There are a number of posts (one, two) out there on getting Phusion's Passenger up and running on OSX (Leopard). I decided to give it a go, and was pleased to discover several things:

Despite reports to the contrary, Passenger installed just fine with Leopard's built-in Apache (I'm running Apache 2.2.8).
Setup is very easy, as advertised.
My default doc root(~/Sites) is works exactly as it did before. I do some HTML and PHP work there, so it was key that it continue to work properly.

Since the install process itself is quite easy, I wanted to offer a few tips for utilizing Passenger in a typical dev environment -- i.e., what you need after you get your first Passenger-powered Rails app up and running.

Your Brain on Passenger

As you know, script/server starts your Rails app on a specific port. If you bounce around between a number of applications at any one time, you're probably used to either starting them on different ports, or control-c'ing your current mongrel, cd'ing to another app's directory, and script/server'ing again. This familiar pattern changes when you're running passenger. All your apps are available at any one time, as long as you have your vhosts configured.

If you're like me, you usually hit your currently running Rails app on http://localhost:3000. That also changes when you're running Passenger. Instead, you'll hit a unique URL for each app, which you've configured in /etc/hosts to just go to 127.0.0.1

Setting up a new app

I set up a lot of Rails apps in my dev environment. With Passenger, in exchange for the on-demand convenience of accessing any of your apps any time, there are a few additional setup steps to take whenever you introduce a new app into your dev environment.

create your rails project as usual
add a new vhost. I configure mine in /private/etc/apache2/extra/http-vhosts.conf
add the host in /etc/hosts
restart apache: sudo apachectl restart

Here's a vhosts example with two apps I'm running locally. You can set up as many apps as you want this way:

  <VirtualHost *:80>
    DocumentRoot "/Users/andre/projects/rails/hotspotr/public"
    ServerName dev.hotspotr.com
    ErrorLog "/Users/andre/projects/rails/hotspotr/log/error.log"
  </VirtualHost>

  <VirtualHost *:80>
    DocumentRoot "/Users/andre/projects/rails/shapewiki/public"
    ServerName dev.shapewiki.com
    ErrorLog "/Users/andre/projects/rails/shapewiki/log/error.log"
  </VirtualHost>

Two things to note here:

The ErrorLog line is optional. If you don't include it, the error output for this app will go to /private/var/log/apache2/error.log. Not that that's bad, but you're probably not used to looking for Rails logs there.
I decided to go with the convention of dev.[PRODUCTION_URL].com. You can use anything here, as long as it matches up with an entry in /etc/hosts (see below)

And here's an example /etc/hosts addition to match the two virtual hosts above:

  127.0.0.1       dev.hotspotr.com
  127.0.0.1       dev.shapewiki.com

That's it! Go to (for example) http://dev.hotspotr.com, and you're hitting you local development app. There is nothing to start and stop. The first request for any app you hit will take a moment. Subsequent requests will feel quite snappy.

Let's Set up some Aliases to Make it all Flow

Here are the aliases I added to my .bashrc file to give me quick access to everything I needed for a new, Passenger-centric workflow in my development environment:

# Use this in any RAILS_ROOT dir. That restart.txt file tells mod_rails to restart this app.
# You'll want to do this when (for example) you install a new plugin.
alias restart_rails='touch tmp/restart.txt'

# By default, your app's error log now goes here. Unless you configure your apps otherwise, 
# it's helpful to have an alias to take you to your error log quickly.
alias apache_logs='cd /private/var/log/apache2/'

# You'll be adding to your vhosts configuration everytime you introduce a new Rails app. 
# Might as well make it a shortcut
alias vhosts='sudo vi /private/etc/apache2/extra/httpd-vhosts.conf'

# Dito with hosts
alias hosts='sudo vi /etc/hosts'

# You'll need to restart apache whenever you make a change to vhosts. 
# You can also click System Preference->Sharing->Web Sharing, but this is quicker.
alias apache_restart='sudo apachectl restart'

Running Background Jobs in Ruby on Rails Revisited

Wed, 21 May 2008 20:42:00 EST

A while back, we wrote an article on Running Background Jobs in Ruby on Rails.

The Ruby on Rails framework has a number of tools for running your code outside of the web-request, including the venerable script/runner for one-off tasks, but using them can be a little heavy on your server. If you want to run a task on the minute, or on demand, script/runner will load your entire Rails environment, which can be from 20-50 MB, depending on how many libraries and how much code you’re pulling in.

There are also a few other good guides, recipes, and libraries that we’ve mentioned before, including:

A chapter I helped write in Obie Fernandez’s The Rails Way on Background Processing
A Rails Recipe in the Advanced Rails Recipes Book on background processing with Rails by Jon Dahl
BackgrounDRb a library used to divorce long-running tasks from the web-cycle of a Rails application
A great article by Luke Francl explaining Stress-free Incoming E-Mail Processing with Rails which helped inspire this solution

We’ve found that it’s not terribly hard to build your own job server that runs continuously in the background and can handle all kinds of jobs, including those that should run on a specified interval. Here’s how we did it.

We’re going to make use of the Daemons gem, so install it first:


sudo gem install daemons

Let’s go ahead and build in two types of jobs:

those that Run Once (immediately) and
those that Run on an interval (every x seconds or minutes or days)

We’ll use ActiveRecord’s Single Table Inheritance (STI) to handle both types of jobs and dictate their differing behaviors.

Create a PeriodicJob model:


script/generate model PeriodicJob type:string \
 job:text interval:integer last_run_at:datetime

And migrate up. Now, fill in the PeriodicJob#run! method:


# app/models/periodic_job.rb
class PeriodicJob < ActiveRecord::Base

  # Runs a job and updates the +last_run_at+ field.
  def run!
    begin
      eval(self.job)
    rescue Exception
      logger.error "'#{self.job}' could not run: #{$!.message}\n#{$!.backtrace}" 
    end
    self.last_run_at = Time.now.utc
    self.save  
  end

end

Note that we’re using Time.now.utc so as not to cause confusion—our AR is configured to use UTC by default.

Now, let’s create the subclass for Run Once jobs and let it inherit from our PeriodicJob model. We’ll add two more class methods to it, including a finder and a cleanup method:


# app/models/run_once_periodic_job.rb
class RunOncePeriodicJob < PeriodicJob

  # RunOncePeriodicJobs run if they have no PeriodicJob#last_run_at time.
  def self.find_all_need_to_run
    self.find(:all, :conditions => ["last_run_at IS NULL"])
  end

  # Cleans up all jobs older than a day.
  def self.cleanup
    self.destroy_all ['last_run_at < ?', 1.day.ago]
  end

end

Now let’s define the Run on an Interval Job and add the interval specific finder:


# app/models/run_interval_periodic_job.rb
class RunIntervalPeriodicJob < PeriodicJob

# RunIntervalPeriodicJobs run if PeriodicJob#last_run_at time plus 
# PeriodicJob#interval (in seconds) is past the current time (Time.now).
  def self.find_all_need_to_run
    self.find(:all).select {|job| job.last_run_at.nil? || 
      (job.last_run_at + job.interval <= Time.now.utc)}
  end

end

Now, let’s write some tests, to make it clear how it should work:


# test/unit/periodic_job_test.rb
require File.dirname(__FILE__) + '/../test_helper'

class PeriodicJobTest < Test::Unit::TestCase
  fixtures :periodic_jobs

  def test_should_run_job
    assert_nothing_thrown { periodic_jobs(:run_once_job).run! }
  end

  def test_should_find_run_once_job
    assert RunOncePeriodicJob.find_all_need_to_run.include?(periodic_jobs(:run_once_job))
  end

  def test_should_not_find_run_job_already_run
    assert !RunOncePeriodicJob.find_all_need_to_run.include?(periodic_jobs(:run_once_job_to_be_deleted))
  end

  def test_should_find_run_interval_job
    assert RunIntervalPeriodicJob.find_all_need_to_run.include?(periodic_jobs(:run_interval_job_needs_run))        
  end

  def test_should_not_find_run_interval_job_not_within_interval
    assert !RunIntervalPeriodicJob.find_all_need_to_run.include?(periodic_jobs(:run_interval_job_does_not_need_run))
  end

  def test_should_cleanup_old_jobs
    jobs_count = RunOncePeriodicJob.count

    assert periodic_jobs(:run_once_job_to_be_deleted).last_run_at
    RunOncePeriodicJob.cleanup

    assert jobs_count - 1, RunOncePeriodicJob.count
  end

end

Here are our fixtures that setup the scenarios:


# test/fixtures/periodic_jobs.yml
run_once_job:
  id: 1
  type: RunOncePeriodicJob
  job: 'what = "w00t once!"'
run_interval_job_needs_run:
  id: 2
  type: RunIntervalPeriodicJob
  interval: 60
  job: 'what = "w00t on the minute dood!"'
  last_run_at: <%= (Time.now.utc - 5.minutes).to_s(:db) %>
run_interval_job_does_not_need_run:
  id: 3
  type: RunIntervalPeriodicJob
  interval: 60
  job: 'what = "w00t on the minute dood!"'
  last_run_at: <%= (Time.now.utc - 5).to_s(:db) %>
run_once_job_to_be_deleted:
  id: 4
  type: RunOncePeriodicJob
  job: 'what = "w00t once!"'
  last_run_at: <%= (Time.now.utc - 8.days).to_s(:db) %>
run_interval_job_needs_run_never_run_before:
  id: 5
  type: RunIntervalPeriodicJob
  interval: 60
  job: 'what = "w00t on the minute dood!"'

Now, we have a built in system for running Periodic Jobs. Note that all we have to do is create a new Periodic Job with the actual code we would normally toss to script/runner in the PeriodicJob#code field, and when we call the PeriodicJob#run! method, it will evaluate it.

We now need a way to always run a background task server to check these PeriodicJobs and run them.

Create a file called task_server.rb in your script directory.


# script/task_server.rb
#!/usr/bin/env ruby
#
# Background Task Server
#
# Relies on ActiveRecord PeriodicJob and STI table (periodic_jobs):
#
# type:         string    ("RunOncePeriodicJob", or "RunIntervalPeriodicJob")
# interval:     integer   (in seconds)
# job:          text      (actual ruby code to eval)
# last_run_at:  datetime  (stored time of last run)
#
# Main algorithm is daemon process runs every XX seconds, wakes up and
# looks for jobs. Jobs placed in the RunOncePeriodicJob queue are run 
# immediately (if no last_run_at time) and stored until they are cleaned up 
# (deleted). Jobs placed in the RunIntervalPeriodicJob queue are run if: 
# their last_run_at time + their interval (in seconds) is past the current 
# time (Time.now).
#

options = {}
ARGV.options do |opts|

  opts.on( "-e", "--environment ENVIRONMENT", String,
           "The Rails Environment to run under." ) do |environment|
    options[:environment] = environment
  end

  opts.parse!
end

RAILS_ENV = options[:environment] || 'development'  

require File.dirname(__FILE__) + '/../config/environment.rb'

if RAILS_ENV  "development" or RAILS_ENV  “test” 
  SLEEP_TIME = 10
else
  SLEEP_TIME = 60
end


loop do
  # Find all Run Once jobs, and run them
  RunOncePeriodicJob.find_all_need_to_run.each do |job|
    job.run!
  end

  # Find all Run on Interval jobs, and run them  
  RunIntervalPeriodicJob.find_all_need_to_run.each do |job|
    job.run!
  end

  # Cleans up periodic jobs, removes all RunOncePeriodicJobs over one
  # day old.
  RunOncePeriodicJob.cleanup

  sleep(SLEEP_TIME)
end

That’s it. Now, we create a control script using the daemons gem.


# script/task_server_control.rb
#!/usr/bin/env ruby
#
# Background Task Server Control - A daemon for running jobs
#

require 'rubygems'
require 'daemons'

options = {}

default_pid_dir = "/var/run/task_server" 

if File.exists?(default_pid_dir)
  options[:dir_mode] = :normal
  options[:dir] = default_pid_dir
end

Daemons.run(File.dirname(__FILE__) + '/../script/task_server.rb', options)

Create an optional /var/run/task_server dir if you’re running on a server (in production mode):


mkdir -p /var/run/task_server
chown deploy:deploy /var/run/task_server

We can start it up in the normal server mode, as a daemon (using the start/stop commands, or we can start it up in interactive mode (so we can see the results) using the run command:


ruby script/task_server_control.rb run

In another window, add some jobs:


ruby script/console
>> RunOncePeriodicJob.create(:job => 'puts "This job will only run once."')
=> #...
RunIntervalPeriodicJob.create(:job => 'puts "This job runs every 30 seconds, and it ran: #{Time.now.utc}"', :interval => 30)
=> #...

You should see the task_server_control.rb file running these jobs as the task server wakes up.

And now, it wouldn’t be complete without some Capistrano support to enable restarting after we make code changes to the model, and to allow start/stop/restart:


# config/deploy.rb

# In case you're running on multiple app servers,
# we define the task_server to make sure that 
# jobs only run on one server.
role :task_server, "app_server1.example.com" 

namespace :background_task_server do

  task :setup, :roles => :task_server do
    run "mkdir -p /var/run/task_server" 
    run "chown #{user}:#{group} /var/run/task_server" 
  end

  # start background task server
  task :start, :roles => :task_server do
    run "#{current_path}/script/task_server_control.rb start -- -e production" 
  end

  # stop background task server
  task :stop, :roles => :task_server do
    run "#{current_path}/script/task_server_control.rb stop -- -e production" 
  end

  # start background task server
  task :restart, :roles => :task_server do
    # TODO: since restart won't cold_start, we could read call to status, if 
    # it returns:
    #    task_server.rb: no instances running
    # we could simply issue the start command
    run "#{current_path}/script/task_server_control.rb restart -- -e production" 
  end

end

# optional:
# after "deploy", "background_task_server:restart"

Note the use of the task_server, so you can simply allow one app server to be your task server (if you’re running on multiple servers).

And now, because I’m feeling generous, let’s set monit up to monitor your task server, so that if it ever goes down for some strange reason, monit should boot it back up (this also ensures that restarts will boot your task server back up):


# /etc/monit.d/task_server.conf

check process task-server with pidfile /var/run/task_server/task_server.rb.pid
  group task-server
  start program = "/usr/bin/ruby /var/www/apps/example/current/script/task_server_control.rb start -- --environment=production" 
  stop program  = "/usr/bin/ruby /var/www/apps/example/current/script/task_server_control.rb stop -- --environment=production"

That’s it! If there’s any interest in forming a plugin around this with generators to create the migration and models, I’ll give it a go and stick it on github.

Feedback appreciated!

We're Presenting at StartupRiot

Wed, 14 May 2008 10:30:00 EST

Come see us talk about Scout Server Monitoring and Reporting at StartupRiot on May 19, 2008, and watch all the other startups present their wares. This looks to be a really great event.

See ya there!

Doing it your way

Wed, 23 Apr 2008 11:53:00 EST

You need to be in the Bay Area. You shouldn’t be in the Bay Area.

You need to work crazy hours. You shouldn’t work more than 4 days a week.

You need to raise as much money as you can. You shouldn’t raise money.

The topics above never seem to get old and I think it’s unfortunate.

Just run your business the way that feels right. The majority of your time during the week is spent working. Whether you’re working for yourself or for someone else, if you’re not working the way you want to, it won’t last.

Scout's Grand Opening

Tue, 15 Apr 2008 09:08:00 EST

Scout, our server monitoring and application, is now available for public consumption.

Scout is for the 95% of us that either gave up on installing & maintaining monitoring applications or used the old fashion monitoring method – an email from a customer when your web application is down. I’m not calling you out, it’s simply that monitoring used to be more painful than not monitoring. We think Scout changes that in a beautiful way.

Scout makes it easy to bring all of your data together – from the monitoring standbys (url monitoring, server load, memory usage, etc) to modern day analytics (the number of user accounts on your web application, unique visitors, inbound links, etc). It’s all done through an easy plugin system that you configure through our web interface – you never have to login to each of your servers and install or edit monitoring scripts. You’re not limited to the plugins we built – you can roll your own with a couple of elegant lines of Ruby code.

What's different in this picture?

Wed, 2 Apr 2008 08:00:00 EST

We’ve used Scout for several months internally. Along with Colloquy, Google Docs, Basecamp, and Skitch, it’s one of the few apps I use every day.

We think this makes Scout a better service – we’re not watching Scout from a third-person perspective. However, sometimes things sneak through – the type of things that don’t bother you after using an application for months but can be hurdle to others when getting started.

There were 2 nagging issues that stood out in the Scout user experience. I’ll cover how I addressed the first one here.

With Scout, you have a client that is installed on a server. The client has many plugins, which do things like monitor a URL or the load on the server.

Here’s the top of the client detail page:

...and the top of the plugin detail page:

The pages are so similar, it’s difficult to tell you changed views. Compare the previous image with the new plugin detail view:

It’s easy to blindly follow a site design blueprint and try to make every page fit the same style guidelines. I did a little too much of that in our initial release, but I think this makes the distinction between the two views much clearer without sacrificing a clean look-and-feel.