ne•o•phil•i•ac

Merb provides some useful helpers when developing a web application (not them all though, man I miss the date helper…) and some can be used to help your site align with the best practices for speeding up your website from Yahoo!.

The helpers provide a way to collect the CSS files, Javascript files and blocks of content required specifically for a page. This functionality can be used to easily ensure that all CSS and Javascript in any page of your application are in accordance with the following guidelines:

• 1: Make fewer http requests
• 5: Put CSS at the top
• 6: Put Javascript at the bottom
• 12: Remove duplicate scripts

Below is a stripped down example of a layout (in HAML) of how this can be achieved.

!!!
%html
  %head
  %title My Javascript Best Practice Website
  / 5
  = css_include_tag 'reset', 'screen'
  /1,5
  = include_required_css
  %body
    #content
      = catch_content :for_layout
    #footer
      link_to "About us", "about_us.html"

    / 6
    = js_include_tag 'jquery-1.2.6.min', 'site.js'
    / 1,6,12
    = include_required_js
    - if thrown_content? :javascript
      %script
        == $(document).ready(function() { #{catch_content :javascript} });

The ‘include required’ helpers allows your templates and partials to specify which javascript and CSS files they require. Ensuring that they are always correctly placed (with the CSS at the top and javascript at the bottom) and also removes any duplicates.

The last section of the layout catches any blocks that you throw called ‘javascript’, it is assumed we are using jQuery, so the output is rendered in the document ready function. Again this can be used from any template or partial but when adding content to this you should always favor the append_content method (as throw_content will always replaced what is in the named store).

So with all this in place you can now do things like this:

- require_css '/facebox/facebox.css'
- require_js '/facebox/facebox.js'

= link_to("A facebox", "/content.html", :rel => "facebox")

- append_content :javascript do
  $('a[rel*=facebox]').facebox();

and each of the elements is output in “best” position on the page.

I really like this approach as, other than the benefits of performance, it leads you away from creating or using helpers that spurt out javascript in the middle of the page. I also think it encourages you to think about progressive enhancement early on and jQuery with the throw/catch content helpers provides an easy way to achieve it.

Check out scramble.com!

Built using sinatra, sphinx and sequel

I recently decided to spice up the interface of my side project by adding a “carousel” effect to the calendar using the jcarousel plugin. It seemed quite promising at first but ended up being difficult to coerce to fit my specific requirements and its big feature set made it a little on the large size.

A few minutes playing around in TextMate encouraged me to roll my own, which ended up being quite successful. So I decided to tidy up the code, pull it out into its own plugin, and share it on GitHub.

You can get the source and examples by using this clone url:

git clone git://github.com/mikejones/carousel.git

It was written with an emphasis on simplicity and customization. It has a small feature set out of the box (just enough for my needs) but it provides hooks and callbacks making its behavior easily customisable (see the examples). Also the source has *hopefully* been kept readable so its easily hackable if you reach its limitations.

Whilst I was putting together rubybroker-ec2 Merb 0.9.5 was released, as my side project was running 0.9.4 I fixed to use that version. This afternoon on my train journey home I finally upgraded, when it came to deploy it turned out different configuration is required for 0.9.5.

This release addresses the issues around this and also allows you to specify the version of Merb your application is using so the appropriate dependencies are installed.

You can grab the new version from GitHub:

  $ gem sources -a http://gems.github.com
  $ sudo gem install mikejones-rubybroker-ec2

The deployment process in the same as before but now when you now bootstrap your instance Merb 0.9.5 will be installed. This can be overridden in you deploy.rb e.g.:

  set :merb_version, "0.9.3"

rubybroker-ec2 is a collection of Capistrano recipes geared towards getting Merb applications live on the internet with minutes. It utilizes Amazon’s Elastic Compute Cloud (EC2) and the Apache module Phusion Passenger to give you a straightforward, automated, and repeatable deployment process.

It builds on work started by George Malamidis and developed further whist deploying my side project.

Using rubybroker-ec2 you will bootstrap a Debian instance (ami-bded09d4) with the following stack; Ruby 1.8.7, Rubygems 1.2.0, Apache2, Passenger, Mysql and Git. Your application will be stored in the ephemeral storage (/mnt) and Apache will be configured correctly to serve it with Phusion Passenger.

Prerequisites

To use rubybroker-ec2 you will need the following:

1. An EC2 account setup and configured to manage EC2 instances (described in detail here).
2. A Merb application versioned in a Git repository with all dependancies stored in its “gems” directory.
3. The Capistrano gem installed, capify . run on the application and the basic configuration of your application name and Git scm details completed.

Once you have this you can follow the next few steps to very quickly get you application live.

Configuration

The first step is to download and install the gem:

  $ sudo gem install ruby-broker-ec2-0.0.1.gem

Add it as a requirement at the bottom of your Capfile:

 load 'deploy' if respond_to?(:namespace) # cap2 differentiator
 Dir['vendor/plugins/*/recipes/*.rb'].each { |plugin| load(plugin) }
 load 'config/deploy'
 require "rubybroker-ec2"

now copy the following configuration into your deploy.rb file and complete the first section with your AWS credentials:

 # Replace the examples with your AWS credentials
 set :account_id, "your account id here"
 set :access_key_id, "your access key id here"
 set :secret_access_key, "you secret access key here"
 set :pk, "your pk here"
 set :cert, "your cert here"
 set :keypair, "your keypair here" 

 # Complete this section in when instance started
 set :instance_id, "your instance id from cap instance:start here"
 set :instance_url, "your instance id from cap instance:describe here" 

 role :app, instance_url
 role :web, instance_url
 role :db,  instance_url, :primary => true

Up and Running

The next few steps bootstrap an instance for you, configure Capistrano so it can access it and install the final pieces of software which are not part of the AMI.

Get the instance started an instance with:

  $ cap instance:start

The output of this command will contain the instance id, this should be entered in the :instance_id field of you deploy.rb. When this is completed invoke:

  $ cap instance:describe

In the description of the instance should be the instance url (its looks something like ec2-75-111-111-111.compute-1.amazonaws.com) which is required for your deploy.rb. Note: it may take a few attempts to get the instance url while the instance starts up.

Thats Capistrano configured which allows us to install and configure the final pieces of software using:

  $ cap instance:bootstrap

The instance will now have the full stack on but mysql will require some configuration specific to your application. The easiest was to do this is to connect to the instance using:

  $ cap instance:ssh

You can set mysql root password and create the production database:

  $ mysqladmin -u root password [password]
  $ mysqladmin -u root -p create [databasename]

Application Specific Configuration

This is also the time to configure the instance for any requirements specific to your project.

For my side project I had to ensure that the instance could access my git repository which is hosted at GitHub. This is as easy as creating a authentication key with:

  $ ssh-keygen -t rsa

then coping the contents of ~/.ssh/id_rsa.pub to the “Deploy Keys” of the admin section of the GitHub repository.

I also required RMagick and ImageMagick which I installed using the following command:

  $ apt-get install imagemagick librmagick-ruby1.8 libfreetype6-dev xml-core

When you have finished your own customisation you are ready to deploy.

Deployment

Phusion Passenger supports Merb applications through the Rack interface. So before your first deployment you need ensure you have a file named config.ru to the root your application containing the following:

 # config.ru
 require 'rubygems'
 require 'merb-core' 

 Merb::Config.setup(:merb_root   => ".",
                   :environment => ENV['RACK_ENV'])
 Merb.environment = Merb::Config[:environment]
 Merb.root = Merb::Config[:merb_root]
 Merb::BootLoader.run 

 run Merb::Rack::Application.new

The actual deployment steps are the same as the standard Capistrano deployment but the implementation has been customised for this stack.

Set up the directories on the server:

  $ cap deploy:setup

Deploy the code, migrate the database and start Apache with:

  $ cap deploy:cold

And… Thats it! Hitting your instance url you should now see you app.

Other Commands

rubybroker-ec2 also includes helpers for a few other common commands.

Tell Passenger to restart your application with:

  $ cap deploy:restart

Analyze Phusion Passenger’s and Apache’s real memory usage with:

  $ cap passenger:memory_stats

Inspect Phusion Passenger’s internal status with:

  $ cap passenger:status

Problems?

If you don’t see your application you will need to dig around the in Apache error logs and most of the time you can get a pretty good idea of what went wrong. These can be found /var/log/apache2/error.log and /mnt/apps/{application}/current/logs/error.log.

The first time I deployed the couple of problems I had were:

• Wrong permissions on the cache directories
• Sass not generating CSS when running under Apache

TODO’s

There are a few feature still which include:

• Add the domain name to the configuration
• Configure caching to work correctly with Apache / passenger
• Configure MYSQL to work from the ephemeral storage

References and Links

• Phusion Passenger on Amazon EC2
• EC2 Gettings started Guide
• Phusion Passenger Users Guide
• Merb Wiki
• Passenger Screencast

I spent the last day helping to upgrade an application to Merb 0.9.5. There were a few problems with the select helper and we created this quick and dirty monkey patch to fix. Patch and tests to come.

module Merb::Helpers::Form::Builder
  class Base
    def update_bound_select(method, attrs)
      attrs[:value_method] ||= :to_s
      attrs[:text_method] ||= :to_s
      attrs[:selected] ||= @obj.send(attrs[:value_method])
    end

    def options(col, text_meth, value_meth, sel, b = nil)
      ([b] + col.map do |item|
        if item.is_a?(Hash) || item.is_a?(Array)
          text = item.last
          value = item.first
        elsif item.is_a?(String)
          text = text_meth ? item.send(text_meth) : item
          value = text_meth ? item.send(value_meth) : item
        else
          text = item.send(text_meth)
          value = item.send(value_meth)
        end

        option_attrs = {:value => value}
        option_attrs.merge!(:selected => "selected") if value == sel
        tag(:option, text, option_attrs)
      end).join
    end
  end
end

Recently a couple of bits of debug have cropped up in the tests on my project and it’s been irritating me a little more each time I run my tests. Today it became too much and it was time to track them down. I knew they were is a spec somewhere, so in the spec_helper I added the following to print out the description of the test instead of the actual debug.

def new_puts(test)
  $stdout.puts(self.description)
end

alias :p :new_puts
alias :puts :new_puts

Debug free test output. Conditions are perfect.

Its been over a year, so I cleared out all the old posts, installed the latest version of workpress and started work on a new theme. All I need now is to find something to say… *sigh*