RewriteRule ^.*/myskin.swf$ /pathto/myskin.swf

Any request ending in myskin.swf will be redirected to /pathto/myskin.swf under the public folder.

1. Rails, a few precompiled gems (like RMagick), and a test app are automatically installed for you. Most of the tutorials walk you through installing Rails and the skeleton app from SSH. That’s no longer necessary.
2. For Capistrano, you need to set the syspath option (“System” in the control panel) to /home/[xxxxx]/containers/rails/[app_path]/current where [xxxxx] is your GridContainer number and [app_path] is where you want your app located. I kept the app path and app name the same.
3. You can’t edit application options from the web control panel. You have to do this from a SSH session using mtr set_option. You may need to do this to change the syspath or to set the environment. For example, to set the environment to “staging” you use the following command: mtr set_option [app_name] environment=staging.
4. If you change the syspath make sure to update the symbolic link to the app’s public folder under your app’s domain, otherwise you’ll get an app not found error. In other words, ~/domains/example.com/html should point to /home/[xxxxx]/containers/rails/[app_path]/current/public.
5. When an application fails to start, you get no feedback about the cause. Check log/mongrel.log for details as to why your application fails to start.
6. After changing the syspath, the app may not restart. You may get an Address already in use - bind(2) (Errno::EADDRINUSE). To resolve this, I ended up having to reboot the container.
7. For some reason, rake gems:install didn’t work. I had to manually install each gem.

I definitely had a lot more control over the installation when I had the application running on the (dv) using Passenger Phusion, especially having the ability to compile software. However, the GridContainer runs a lot faster.

RSpec is the current black when it comes to testing. Seeing how it’s adopted by merb by default and I’m targetting merb for an old app I shelved because Rails just didn’t have the high performance yet to pull it off, I figured it would be the test method I should learn. It also helps that RSpec is just more readable than Test::Unit. Installation is more or less trivial and is covered succinctly in the RSpec documentation. Just remember to install RSpec as a plugin and not as a gem. Autotest will puke otherwise. You can also use the -x option if you want to install it as an svn external. (Another option would be piston another gem I need to look at.)

ruby script/plugin install http://rspec.rubyforge.org/svn/tags/CURRENT/rspec
ruby script/plugin install http://rspec.rubyforge.org/svn/tags/CURRENT/rspec_on_rails

Then you bootstrap the plugin which installs the generators and rake tasks.

ruby script/generate rspec
ruby script/generate rspec_model foo
rake db:migrate
rake spec

If all goes well, rspec should run and you should get a result similar to this:

.
Finished in 0.313 seconds
1 example, 0 failures

Now that RSpec is running properly, we want it to run automatically. That’s where ZenTest comes in. (The capitalization is intentional.)

sudo gem install ZenTest

ZenTest contains autotest. You start autotest from the root of your Rails application.

autotest

Autotest will then sit there continually checking your app folders for any file changes. When one is detected that requires RSpec to run, autotest will fire off the rake task to do so. Go ahead and edit ./app/models/foo.rb by adding a blank line and then save it. When you return to the terminal window you should see that the test ran and you got the same result as before.

There is a prettier and more informative alternative than the results provided in the terminal. RSpec can produce HTML output as well. Create a folder ./doc/spec/ for the output folder. Now open up ./spec/spec.opts in your editor and add the following lines.

--format 
html:doc/spec/report.html

This will cause an HTML report to be generated every time a test is run, in addition to the terminal output. The HTML report not only tells you what tests failed and passed but also where the failures occurred. The HTML format is much easier to navigate than the terminal output.

Mac OS X users have a notification program called Growl that autotest hooks into. On Windows there’s Snarl. For Linux, there’s libnotify. libnotify is not a standalone application like Growl or Snarl, but a library around which an application, or in this case, an applet must be written. There’s a handful of how-tos that walk you thru hooking autotest to libnotify, but the one I considered the best was this blog post, Gnome autotest Notifications. If you follow those instructions, you should get a working notifier, but I would recommend replacing his .autotest file with my .autotest file:

require 'rnotify'
require 'gtk2'
require 'launchy'

module Autotest::RNotify
  class Notification
    attr_accessor :verbose, :image_root, :tray_icon, :notification, 
                  :image_pass, :image_pending, :image_fail,
                  :image_file_pass, :image_file_pending, :image_file_fail,
                  :status_image_pass, :status_image_pending, :status_image_fail
    
    def initialize(timeout = 5000, 
                   image_root = "#{ENV['HOME']}/.autotest_images" , 
                   report_url = "doc/spec/report.html",
                   verbose = false)
      self.verbose = verbose
      self.image_root = image_root
      self.image_file_pass = "#{image_root}/pass.png"
      self.image_file_pending = "#{image_root}/pending.png"
      self.image_file_fail = "#{image_root}/fail.png"

      raise("#{image_file_pass} not found") unless File.exists?(image_file_pass)
      raise("#{image_file_pending} not found") unless File.exists?(image_file_pending)
      raise("#{image_file_fail} not found") unless File.exists?(image_file_fail)
      
      puts 'Autotest Hook: loading Notify' if verbose
      Notify.init('Autotest') || raise('Failed to initialize Notify')

      puts 'Autotest Hook: initializing tray icon' if verbose
      self.tray_icon = Gtk::StatusIcon.new
      tray_icon.pixbuf = Gdk::Pixbuf.new(image_file_pending,22,22)
      tray_icon.tooltip = 'RSpec Autotest'

      puts 'Autotest Hook: Creating Notifier' if verbose
      self.notification = Notify::Notification.new('X', nil, nil, tray_icon)

      notification.timeout = timeout

      puts 'Autotest Hook: Connecting mouse click event' if verbose
      tray_icon.signal_connect("activate") do
        Launchy::Browser.new.visit(report_url)
      end
      
      Thread.new { Gtk.main }
      sleep 1
      tray_icon.embedded? || raise('Failed to set up tray icon')
    end
    
    def notify(icon, tray, title, message)
      notification.update(title, message, nil)
      notification.pixbuf_icon = icon
      tray_icon.tooltip = "Last Result: #{message}"
      tray_icon.pixbuf = tray
      notification.show
    end
    
    def passed(title, message)
      self.image_pass ||= Gdk::Pixbuf.new(image_file_pass, 48, 48)
      self.status_image_pass ||= Gdk::Pixbuf.new(image_file_pass, 22, 22)
      notify(image_pass, status_image_pass, title, message)
    end
    
    def pending(title, message)
      self.image_pending ||= Gdk::Pixbuf.new(image_file_pending, 48, 48)
      self.status_image_pending ||= Gdk::Pixbuf.new(image_file_pending, 22, 22)
      notify(image_pending, status_image_pending, title, message)
    end
    
    def failed(title, message) 
      self.image_fail ||= Gdk::Pixbuf.new(image_file_fail, 48, 48)
      self.status_image_fail ||= Gdk::Pixbuf.new(image_file_fail, 22, 22)
      notify(image_fail, status_image_fail, title, message)
    end
    
    def quit
      puts 'Autotest Hook: Shutting Down...' if verbose
      #Notify.uninit
      Gtk.main_quit
    end
  end

  Autotest.add_hook :initialize do |at|
    @notify = Notification.new
  end

  Autotest.add_hook :ran_command do |at|
    results = at.results.last

    unless results.nil?
      output = results[/(\d+)\s+examples?,\s*(\d+)\s+failures?(,\s*(\d+)\s+pending)?/]
      if output
        failures = $~[2].to_i
        pending = $~[4].to_i
      end
      
      if failures > 0
        @notify.failed("Tests Failed", output)
      elsif pending > 0
        @notify.pending("Tests Pending", output)
      else
        unless at.tainted
          @notify.passed("All Tests Passed", output)
        else
          @notify.passed("Tests Passed", output)
        end
      end
    end
  end

  Autotest.add_hook :quit do |at|
    @notify.quit
  end
end

The improvements I made are to (a) forego using themeable icons and stick strictly with the Autotest Growl Fail/Pass Smilies (b) run a check to make sure the images exist otherwise raise an error, and © load the RSpec HTML report when you click the icon in the system tray. In order for the onclick event to work, you need to install the launchy gem.

sudo gem install launchy

After all that is up and running, you should have a fully functioning test environment that will automatically run (after starting autotest in a terminal) with a notification applet running in your system tray that you can click to load a well-formatted HTML report in your browser.

@echo off

if "%1"=="" goto :NOAPPNAME
if "%2"=="" goto :NOUSERNAME
if "%3"=="" goto :NOSVNREPO

mkdir svntemp
cd svntemp 
mkdir branches
mkdir tags
call rails %1
mv %1 trunk
cd trunk
mv config/database.yml config/database_example.yml
rm -r log/*
rm -r tmp/*
cd ..
call svn import --username %2 . %3 -m "initial import"
cd ..
rm -r svntemp
call svn co %3/trunk %1
cd %1
cp config/database_example.yml config/database.yml
call svn propset svn:ignore database.yml config/
call svn propset svn:ignore "*" log/
call svn propset svn:ignore "*" tmp/
svn commit -m "ignoring files"

goto :END

:NOAPPNAME
echo "ERROR: No application name provided."
goto :END

:NOSVNREPO
echo "ERROR: No subversion repository provided. svn://path/to/repo"
goto :END

:NOUSERNAME
echo "ERROR: No username provided."
goto :END

:END

It’s not bad for a first pass. It’d be good to have a shell script that does the same thing and it shouldn’t be too hard to port. If I were to rewrite it using Windows scripting, I’d be able to provide better error checking.

Cream makes Vim act like your standard, modern editor by cleverly mapping the UI from what you expect to what Vim expects. That said, you can also turn off Cream’s mapping temporarily or permanently and make it act more like Vim. Should you desire to use straight Vim or GVim, you can do that as well. Cream eases you into Vim better than GVim does. In fact, GVim is more a middleman between you and Vim whereas Cream acts more like a translator.

Vim 7 has built-in stuff like folds and diff mode. It ships with the vim-ruby scripts which enables things like autocomplete and syntax highlighting for Ruby. Cream adds tabbed documents (but I find them to be more cumbersome especially now that I can use Alt-W 1 thru 9). Cream is nice because you can use your mouse for selection and do cut and paste via Ctrl-X and Ctrl-V which one would expect. Then there’s the rails plugin that exposes many handy commands that hook into the fact you can call system commands so you can generate a model or run a rake task from within Vim.

For all the stuff you get out of the box, Cream has some annoyances. For example, choosing a color theme for your syntax highlighting is, for the most part, limited to the default ones provided by Cream. You can hack the scripts to add your own or you can load one via a configuration file, but that overrides the ability to use the color preferences. As for creating a custom color scheme, that is a programming task in and of itself. I do see the value of Vim’s all-keyboard methodology (a consequence of Vi being written before the mouse was invented). Once learned it’s very efficient. Though one thing that annoys the heck out of me is the choice for navigation keys, primarily for left and right. I can understand the point of maintaining the hand positions on the homebase keys, hence J being mapped to down, down being the most frequent navigation. However, coming from an arrow keys, numpad, and WSAD history, the key mappings for K, L, and H just aren’t that intuitive to me. It would’ve been nice for DF to be mapped to left-right and JK to down-up thereby giving each hand an axis to control, or maybe IJKL be mapped similar to WASD, but in either case, the one letter mnemonics for commands would be lost. Granted the arrow keys do function, but that removes a hand from the homebase keys which isn’t all that efficient and if you’re doing that then a mouse would be just as good to navigate. Yes, it’s possible to remap keys but then what happens when you move to another machine without your customizations?

Still despite it’s shortcomings, I think Cream will most likely replace jEdit as my editor of choice on Windows. The shortcomings are more than likely artificial due to my lack of experience and practice. There’s definitely a lot of features to go through and by far the worst annoyance is a lack of documentation showing proper workflow using Cream/Vim.

Update: I did find this Ruby on Rails, Vim, and rails.vim which is a remix of the RoR Creating a weblog in 15 minutes screencast.

Object.extend(Control.Slider.prototype, {
  setLength: function(length) {
    // resize the element
    if (this.isVertical()) {
      Element.setStyle(this.track, {height: length + "px"});
    } else {
      Element.setStyle(this.track, {width: length + "px"});
    }
    
    // update lengths
    this.trackLength = this.maximumOffset() - this.minimumOffset();

    this.handleLength = this.isVertical() ? 
      (this.handles[0].offsetHeight != 0 ? 
        this.handles[0].offsetHeight : this.handles[0].style.height.replace(/px$/,"")) : 
      (this.handles[0].offsetWidth != 0 ? this.handles[0].offsetWidth : 
        this.handles[0].style.width.replace(/px$/,""));
    
    // reposition handles
    this.handles.each( function(h,i) {
      h.style[this.isVertical() ? 'top' : 'left'] = 
        this.translateToPx(this.values[i]);
    }.bind(this));
  }
})

Just drop this code into your extensions.js file and you should be good to go. Then just call the instance method like so mySlider.setLength(newLength) where newLength is an integer value.

Patch: http://dev.rubyonrails.org/ticket/6398

Enable

So what can you do with it? The basic use is simply to capture mouse input in a defined area of a web page and then map that input to a specific range of values. Another use would be to hook the output of the Touchpad to the inputs of two Sliders. This way you have one controller that can control two controllers simultaneously. (Additionally, this preserves the last value of the Touchpad unless of course you move the Slider independent of the Touchpad.) Another slick use is one that I’ve seen requested on the forums. If you hide the overflow of the Touchpad and then nest a really wide div that contains thumbnails for products, you can then limit the output of the Touchpad to horizontal values—the vertical values are simply clamped to 0—and then use the callback to set the left coordinate of the child div. Now you can scroll through your products without an ugly scrollbar.

If this sounds like something you can use and you can’t wait til the developers choose to add it to the trunk, then go visit the URL above. Then simply download and run the attached diff file on your script.aculo.us installation using Subversion. I recommend you run the functional test included in the patch (tests/run_functional_test.html –> click on touchpad_test in the left frame) to see some examples of the touchpad in action.

script.aculo.us is at version 1.6.4 at the time of this writing.

<%= form_tag( {:controller => 'controller', :action => 'action', :id => 1}, {:id => 'test', :name => 'test'} )%>

This code then produces this HTML.

<form action="/controller/action/1" id="test" method="post" name="test">

Not using the punctuation results in the ID being gobbled up by the URL, or attributes being tacked on to the URL as query string values, or an oh so helpful compile error. Mmmm taste the sarcasm.

The only reference to this was found, not in the API, but buried in some Rails mailing list thread indexed by Google. I figured I’d preserve this tidbit for prosperity seeing how I couldn’t find it on another blog.

Note: Naming form_remote_tag is done differently. After deciphering the syntax by looking at the source code for the helper, it turns out the key is the :html option.

<%= form_remote_tag :url => {:controller => 'controller', :action => 'action', :id => 1}, :html => {:id => 'test', :name => 'test'} %>

So to get an object you do the following.

instance = Object.find(session[:object_id])

Session data tends to be temporary. Now if the session variable is nothing but a reference to an object that is persistent, say the current user, then deleting the session object is no big deal. However, if the intention is that the object the variable references is also temporary that could be a problem. Now using the above code to obtain an instance, you can always call

instance.destroy

then just set your session variable to a new value, or nullify it (and automagically remove it from the session object).

Now here’s where it get’s tricky. What if the user agent does not call the action to manually destroy the instance? Maybe the person behind the browser had to go get a cup of coffee. Maybe the coder behind your app—wink, wink, nudge, nudge—didn’t put in the action to manage temporary objects. In any case, the session will expire and your scheduled cron job will clear the sessions dutifully in the case of PStore or ActiveRecordStore, or will expire outright in the case of Memcached. Unfortunately, the object to which the session pointed will linger on (unless of course you add that code to the cron job as well, but that is arguably bad (see below)).

So, what’s the solution? Thanks to a tip from RubyPanther on #rubyonrails and a bit of Google searching, I managed to hack something together.

First, setup Rails to store sessions in an ActiveRecord store. With that you’ll get a sessions table. Most of what Rails does with the sessions table is hidden behind the scenes, and you want to keep it that way. This doesn’t mean we can’t stick our hand into the cookie jar. (OK that’s a bad pun.) So next let’s create a new model.

class Session < ActiveRecord::Base
  # borrowed from lib/action_controller/session/active_record_store.rb
  def marshal(data)   Base64.encode64(Marshal.dump(data)) if data end
  def unmarshal(data) Marshal.load(Base64.decode64(data)) if data end

  def before_destroy
  data = self.unmarshal(self.data)
    if data[:object] then
      object = Object.find(data[:object])
      object.destroy
    end
    true
  end
end

Because the sessions table is an ActiveRecord store, we can create an ActiveRecord model to get access to it. The marshalling functions are needed to access the session data which is nothing more than a hash. Then all we need to do is to define the before_destroy callback to destroy the object that matches the id stored in data[:object]. Now with the following call

s = Session.find(1)
s.destroy

The session object as well as the object referenced by session[:object] will be destroyed.

So why the trouble of doing this as opposed to just managing it in the script file called by the cron job? Well for one thing, your script becomes cleaner.

Sessions.find(:all, :conditions => ["updated_at <= ?", Time.now]).each { |session| 
  session.destroy 
}

Then there’s the argument that how an object is destroyed should be defined in a model definition. Plus if the code can be improved to use introspection to determine which object to delete based on the hash key, then all the better.

What would be cooler? How about making a session object associative? Wouldn’t it be cool to do something like

object.session.create # object.session_id belongs_to :sessions, :dependent => true