I sniffed around and noticed that abstract stores aren’t getting loaded as of this version (RC1).

# action_controller/session/abstract_store.rb
def get_session(env, sid)
  raise '#get_session needs to be implemented.'
end

def set_session(env, sid, session_data)
  raise '#set_session needs to be implemented.'
end

So, to work around that, I grabbed the actual get_session code from actioncontroller’s SqlBypass class and got it working within metal:

def self.call(env)
  if env["PATH_INFO"] =~ /^\/test/

    request = Rack::Request.new(env)
    session_options = env['rack.session.options']
    sid = request.cookies[session_options[:key]]
    session = ActiveRecord::SessionStore::Session.find_by_session_id(sid)
    session ||= ActiveRecord::SessionStore::Session.new(:session_id => sid, :data => {})

    [200, {"Content-Type" => "text/html"}, session.data.inspect]
  else
    [404, {"Content-Type" => "text/html"}, ["Not Found"]]
  end
end

This has worked so far as I can get the user_id necessary. I’m not sure there is a “just works” way of doing this — but I couldn’t find it and Google didn’t help much.

Hopefully someone out there can make use of this, I scratched me head for a while before just loading the session by hand.

Using Middleware

I just hacked this together and it seems to work (for my testing at least):

# lib/force_active_record_session.rb
module Rack
  class ForceActiveRecordSession
    def initialize(app, options = {})
      @app = app
    end
    def call(env)
      request = Rack::Request.new(env)
      sid = request.cookies[env['rack.session.options'][:key]]
      env['rack.session.record'] = \
        ActiveRecord::SessionStore::Session.find_by_session_id(sid) || \
          ActiveRecord::SessionStore::Session.new(:session_id => sid, :data => {})
      @app.call(env)
    end
  end
end

# environment.rb
require 'lib/force_active_record_session.rb'

# environment.rb -- inside Initializer block
config.middleware.insert 5, Rack::ForceActiveRecordSession

# in your metal action
session = env['rack.session.record'].data rescue {}
[200, {"Content-Type" => "text/html"}, session.inspect]

The features are:

1. You can use it in the controller: fragment_exist?(...)
2. You can use it in views: cache(...) {}
3. Very lightweight
4. Behaves like the regular file store caching
5. Can expire caches automatically

Timed file store code

# lib/timed_file_store.rb
class TimedFileStore < ActiveSupport::Cache::FileStore
  def exist?(name, options = {})
    delete_if_expired(name, options[:time_to_live]) unless options.blank? or options[:time_to_live].blank?
    super
  end
  def read(name, options = {})
    delete_if_expired(name, options[:time_to_live]) unless options.blank? or options[:time_to_live].blank?
    super
  end
protected
  def delete_if_expired(name, time_to_live = 0)
    delete(name) if expired?(name, time_to_live) rescue nil
  end
  def expired?(name, time_to_live = 0)
    return false unless time_to_live > 0
    (Time.now - File.mtime(real_file_path(name))) >= time_to_live
  end
end

Setup & Usage

# environment.rb
# same as :file_store -- just add timed_
config.cache_store = :timed_file_store, File.join(RAILS_ROOT, 'tmp', 'cache')

Time based expiration from the controller

Having the controller control the expiration of the cache is good if you are passing along any objects to the views since it will not re-run the code if it is already cached. I’m using this for a long running report currently.

# YourController.rb
# don't run the report if we are cached
@report = Report.find(params[:id])
unless fragment_exists?("report_#{@report.id}", :time_to_live => 1.week)
  @report.run!
end

# views/reports/show.html.erb -- or whatever view file
<% cache("report_#{@report.id}") do -%>
  <!-- output the report HTML and such -->
<% end -%>

This will expire the fragment and re-run the report after the cache’s File.mtime is older than a week. The view doesn’t have anything to do with it so it acts like the normal FileStore.

Time based expiration in the view

If you aren’t running any intense code in the controller and just want to keep a certain view fragment cached for a while, this should work. (** I didn’t test this since I only needed the previous method, but it should work — maybe with some slight tweaks?

# views/wherever/whatever.html.erb
<% cache("whatever", :time_to_live => 1.hour) do -%>
  <!-- This is my HTML content and all that jazz -->
  <!-- After 1 hour this cache should be re-freshed -->
<% end -%>

Not sure how useful that would be when considering action and page caching… but its possible. The only thing I noticed is that in the log when the cache deletes itself it shows a “Cached fragment hit:” then a “Cached fragment miss:” — probably needs some attention if I ever get around to it.

Let me know if this works out, and/or any issues, bugs, etc.

Setting up the rescue_from methods were simple enough, but I noticed that when I was capturing my error 500s it wasn’t logging the exception. Here is a quick way to have it both display your custom 500 page and log the exception for later review:

  # application.rb
  include ExceptionLoggable

  unless ActionController::Base.consider_all_requests_local
    # yeah, its a long line
    rescue_from ActiveRecord::RecordNotFound, ActionController::RoutingError, ActionController::UnknownController, ActionController::UnknownAction, :with => :render_404
    rescue_from RuntimeError, :with => :render_500
  end

private

  def render_404
    render :template => "shared/error_404", :layout => 'application', :status => :not_found
  end

  def render_500
    # hacky, but works, this logs the exception in ExceptionLoggable
    log_exception $!
    render :template => "shared/error_500", :layout => 'application', :status => :internal_server_error
  end

To test this just change config.action_controller.consider_all_requests_local = true to config.action_controller.consider_all_requests_local = false in your config/environments/development.rb file.

Not the _best_ way or cleanest, but it gets the job done without too much trouble.

The installation went easily for both ruby gems and ruby, but I decided to take a ’short cut’ and copy all my gems from /Library/Ruby/Gems into my /usr/local/lib directory which started raising all kinds of errors — this one, in particular was obnoxious.

[BUG] cross-thread violation on rb_gc()

Luckily, all that means is that I copied over gems which were compiled against the standard OSX ruby version and not the new one. This was a little script I wrote which will show you which gems need to be re-compiled. Just cd over to your /usr/local/lib/ruby/gems/1.8/gems directory and run:

gems $>ls -1 **/**/*.bundle|ruby -pe '$_.gsub! /\-.*/, ""'|uniq

to get a list, or pipe that into $> sudo gem install and that should clear up those gc issues.

# RAILS_ROOT/config/app.yml

regions:
  - 'northeast'
  - 'southeast'
  - 'west'
  - 'central'
  - 'emerging east'
  - 'emerging west'
  - 'opportunity east'
  - 'opportunity west'
  - 'opportunity national east'
  - 'opportunity national west'

divisions:
  <%= (1..71).map{ |i| "Region #{i}" }.to_yaml %>

Loading it up using an initializer:

# RAILS_ROOT/config/initializers/load_app_config.rb

fdata =File.open(File.join(RAILS_ROOT, "config", "app.yml")).read
APP = YAML::load(ERB.new(fdata).result(binding)).symbolize_keys

Now we have our APP hash chock full o’ YAML goodness. My only problem with this is that I might want to eventually put this data set into a table and it is a pain to hunt and search for where the application references APP[:regions] and so on sooo: time to objectize.

I decided that since they are stupid simple objects they can all have the same parent: YamlArrayObject:

# RAILS_ROOT/app/models/yaml_array_object.rb
# or in lib

class YamlArrayObject
  attr_reader :name
  def id
    0
  end
  def initialize(name)
    @name = name
  end
  def to_s
    name
  end
  def display_name
    to_s.titleize
  end
  def <=>(b)
    name <=> b.name
  end
end

Simple enough. Now we just inherit and overload as appropriate.

# RAILS_ROOT/app/models/region.rb
class Region < YamlArrayObject
  def self.all
    APP[:regions].map{ |r| Region.new(r) }
  end
end

# RAILS_ROOT/app/models/division.rb
class Division < YamlArrayObject
  def <=>(b)
    name.to_i <=> b.name.to_i
  end
  def self.all
    APP[:divisions].map{ |d| Division.new(d) }
  end
end

This is all Jim Dandy right now since we can populate select boxes using cleaner code (bonus: won’t break if you decide to add Divisions to a database table)

# i like
<%= f.select :division, Division.all.sort.map{ |d| [d.display_name, d] } -%>
# better than
<%= f.select :division, APP[:divisions].sort{|a,b| a.to_i <=> b.to_i}.map{ |d| [d.titleize, d] } -%>

The only real issue is that calling Client.first.region still returns a string, which is bad since we want to keep our code as ambiguous as possible. The last step is to override the Client class’ methods for region and division (and whatever else we want to use):

# RAILS_ROOT/app/models/client.rb

def division
  Division.new(@attributes['division']) unless @attributes['division'].blank?
end
def region
  Region.new(@attributes['region']) unless @attributes['region'].blank?
end

Now in our views (client/show) we can simply call @client.region.display_name or whatever and not have to change the code when we finally get around to DBing those object.

(There might be better ways to do this that I’m missing, but this seems pretty okay for my needs right now.)

  def content_tag_each(items)
    items.inject(''){ |output, item| output << yield(item) }
  end

Usage

# urls = (string) semi-colon seperated URL list since this is
# from a legacy system and doesn't really need normalization
def display_urls(urls)
  link_options = {:target => :blank}
  urls = urls.split(';')

  # handle single url
  return link_to(urls.first, urls.first, link_options) unless urls.size > 1

  # handle multiple urls
  content_tag(:ul) do
    content_tag_each(urls) do |url|
      content_tag(:li){ link_to(url, url, link_options) }
    end
  end
end

Nothing special really, but can come in handy for certain cases.

  def default(object, default = 'n/a')
    return default if object.blank?
    block_given? ? yield(object) : object
  end

Usage

A very simple example:

#
# Simple Example
#

my_string = ''
puts default(my_string, 'String is empty')
# => 'String is empty'

my_string = 'hello world'
puts default(my_string, 'String is empty')
# => 'hello world'

my_string = 'hello world'
puts default(my_string, 'String is empty') { |str| str.titleize }
# => 'Hello World'

#
# Yielding example
#

puts default(current_user, 'Guest') { |user| user.name.titleize }

The default YAML output

This is what you will get if you simply throw the YAML.load result to an array or something. Nice, but I’m not a big fan of “Keys Like This” so…

irb(main):011:0> pp YAML.load(`svn info`)
{"Node Kind"=>"directory",
 "Last Changed Author"=>"rob",
 "URL"=>"http://example.com/share/lib",
 "Schedule"=>"normal",
 "Last Changed Rev"=>441,
 "Repository UUID"=>"0afc494f-e74d-0410-99f2-b94b27995134",
 "Repository Root"=>"http://example.com",
 "Last Changed Date"=>"2008-07-15 15:55:54 -0400 (Tue, 15 Jul 2008)",
 "Revision"=>446,
 "Path"=>"."}
=> nil

A nice class wrapper for the SVN Info

Heres what I ended up with. Nothing fancy, just a simple wrapper around the subversion info dump.

require 'yaml'
class SVNInfo
  def initialize
      YAML.load(`svn info`).each do |k,v|
          key = k.gsub(/\s/, '_').downcase
          instance_variable_set "@#{key}", v
          instance_eval %{ def #{key}; @#{key}; end }
      end
  end
end

Here is the end result:

irb(main):013:0> svn_info = SVNInfo.new
# ... snip ...
irb(main):014:0> pp svn_info
<SVNInfo:0x57f378
 @last_changed_author="rob",
 @last_changed_date="2008-07-15 15:55:54 -0400 (Tue, 15 Jul 2008)",
 @last_changed_rev=441,
 @node_kind="directory",
 @path=".",
 @repository_root="http://example.com",
 @repository_uuid="0afc494f-e74d-0410-99f2-b94b27995134",
 @revision=446,
 @schedule="normal",
 @url="http://example.com/share/lib">
=> nil
irb(main):015:0>

Messing Around

irb(main):018:0> pp svn_info.methods - Object.methods
["last_changed_author",
 "revision",
 "repository_root",
 "last_changed_rev",
 "path",
 "url",
 "node_kind",
 "last_changed_date",
 "repository_uuid",
 "schedule"]
=> nil
irb(main):019:0> svn_info.revision
=> 446
irb(main):020:0> svn_info.last_changed_author
=> "rob"
irb(main):021:0>

Hope that comes in handy

I was just goin around on the interblagosphere today and stumbled upon Erling Ellingsen’s smackbook pro. If you’ve never heard of this then you’re in for a shock. The basic idea behind what he has created is a way to switch virtual desktops simply by tapping the side of the laptop’s monitor.

I was immediately in love and wanted to play with it a bit but he was using DesktopManager to do the space switching. Since I’m running leopard on the laptop I figured that was a waste of time and I’d never actually use a 3′d party virtual desktop switching app… and so the journey began. I turned to my mortal enemy, applescript, to accomplish this. After some browsing and hacking I found that this simple code can send CONTROL-# keystrokes to get the job done:

tell application "System Events"
	tell process "Finder"
		keystroke "[SPACENUMBER]" using control down
	end tell
end tell

If you toss that into osascript from the command line we can finally start to get somewhere. So the next step was to grab that sudden motion sensor app. Erling was using AMSTracker by Amit Singh so that seemed a good place to start. After that a quick ruby script tied the SMS dump to the applescript and a fun new project was born. It is a lotta bit rough around the edges and needs some sensitivity tuning, but it _does_ get the job done… just be a little rough*

I am definitely not responsible for any damage caused by using this script — it was a proof of concept hack.

Based off “SmackBook Pro”

YouTube Video

This is not mine, but mine does essentially the same thing, only using native Leopard spaces… and ruby.

Where to get the script?

• shakebook project site

Running it is as simple as $>AMSTracker -S -u0.01 | shakebook.rb then tap away (or shake if you want to be careful)

Revisions will probably be made to sensitize it once I have time to mess around with it — if you come up with anything shoot me back a comment