I’ll try to keep on top of comments and such coming in here, but it will eventually start to decay (hopefully gracefully).

-Rob

How does it look?

More examples are on the GitHub project page linked below, but here is a small overview.

require 'lib/apple_remote'

play do
  puts "I'm playing... (Playing? #{playing?})"
end

pause do
  puts "I'm paused... (Playing? #{playing?})"
end

menu do
  if playing?
    puts "Do something with the menu while we're in 'play' state"
  else
    puts "Do something with the menu while we're not in the 'play' state"
  end
end

Tons of fun

Code

Ruby Apple Remote DSL project on GitHub

So. Here is the theme, should I ever do that again, or if you aren’t a big fan of the default themes.

Adding a new theme to SyntaxHighlighter

If you are use version 2.2.0 of the plugin you can run this patch against it (Add GitHub theme patch). To use the patch just run:

$>patch syntaxhighlighter.php add_github_theme.patch

Or you can simply open it up and duplicate how the default themes are in there.

Grab the GitHub SyntaxHighlighter Theme

GitHub SyntaxHighlighter theme (Gist) (It isn’t 100%, but it looks pretty nice for Ruby code)

Heres how it looks

GitHub Theme

The Theme Files

First things first. We need to create a themes folder. I chose RAILS_ROOT/public/stylesheets/themes but anywhere public would work. Inside there I threw the following stylesheet:

I made the theme support a minimum of 3 meta fields:

1. theme — The name of the theme
2. begin — What date to start using the theme
3. end — What date to stop using the theme
4. *enabled — Optional: If you want to enable this theme

You can hack on this and include as many as you want — they follow the same basic format as URLs:

theme.csstheme=My Themes Name&begin=March 17&end=March 18

/*
RAILS_ROOT/public/stylesheets/themes/st_patricks_day.css
{{
	theme=st patricks day
	&begin=March 17
	&end=March 18
	&enabled=1
}}
*/

#header{
	background:#C2DDCA url(theme_images/shamrock.png) no-repeat 25px 20px;
	padding-left:50px;
	}

The Metal

And, now into the neat part. Generate a rails metal file to handle theme switching on the fly, according to the current date.

$>./script/generate metal theme

Which should give you a nice app/metal/theme.rb file which you can play with.

I hacked together this code — and I’m not sure how stable it is, but should probably used in production with caution. It uses Rails.cache so make sure in your environment.rb file you have a cache store set.

class Theme
  # this is where the theme index is stored
  CacheKey = 'themes'
  # this is what we will look for in the layout
  ThemeEnvKey = 'rails.theme'
  # this is the path to your themes folder
  ThemesPath = File.join(RAILS_ROOT, 'public', 'stylesheets', 'themes')

  def self.call(env)
    # Build our theme index
    themes = Rails.cache.fetch(CacheKey) do
      data = {}
      Dir[File.join(ThemesPath, '*.css')].each do |theme|
        # looks for {{ url_type_string_here }} comment meta data and parses
        # it out into a hash for the theme's file name
        #
        # within your theme file, you would have:
        #   {{theme=my name&begin=DATE&end=DATE}}
        # becomes
        #   {'theme.css' => {:theme => 'my mane', :begin => 'START_DATE', :end => 'FINISH_DATE'}}
        #
        # DATE is parsed so it can be any type of
        # date-ish string see ActiveSupport::TimeZone#parse
        begin
          data[File.basename(theme)] = \
            $1.split('&').inject({}) do |h, v|
              s = v.split('=').map(&:strip)
              h[s.first.to_sym] = s.last
              h
            end if File.read(theme) =~ /\{\{(.+)\}\}/m
        rescue Exception => e
          data[theme] = {:error => e.to_s}
        end
      end
      data
    end

    # Set the appropriate theme
    now = Time.zone.now.beginning_of_day
    themes.each_pair do |file, data|
      next if data.keys.include?(:enabled) and data[:enabled].to_i.zero?
      next unless data.keys.include?(:begin) and data.keys.include?(:end)

      if Time.zone.parse(data[:begin]) <= now and Time.zone.parse(data[:end]) > now
        env[ThemeEnvKey] = file
        break
      end
    end

    # pass
    Rails::Rack::Metal::NotFoundResponse
  end
end

What this basically does is:

1. Check within the ThemesPath for any .css files
2. Reads them and parses out the metadata within the stylesheet
3. Caches that
4. Checks the date to see if any theme files should be turned on
5. Sets an env key to let the rest of Rails know we want a theme

The Rails Layout

Well, now Metal has set our env['rails.theme'] key so we know a theme is in order it is time to put that theme to use.

# your applications main layout file (app/views/layouts/application.html.erb?)
# I put this after the normal stylesheet call, so our theme can override what we want instead of the entire stylesheet

<% if theme = request.env['rails.theme'] %>
  <%= stylesheet_link_tag "themes/#{theme}", :media => :all %>
<% end %>

Once all these steps are combined, and March 17th hits, we should now have a stylish header image that shows the shamrock.png! I can almost hear the users clinging glasses

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.