The basic process is this:

1) In order to create some modularity, each controller in my system has it’s own JS file. The controller file contains the code required for the views in that controller. I still have some higher level files for common and application-wide JS code.

2) Each of the controller files is scoped to a namespace:

//File: javascripts/controllers/dashboard.js
var dashboard = {
  init: function() {
    //kick-off code for the "dashboard" controller
  }
}

3) I have a view helper that appends a load command to the layout. Loading is a matter of calling the namespaced init method: $(document).ready(dashboard.init);

The helper looks like this:

def load_controller_script(script = controller.controller_name)
  content_for :javascript do
    "<script type=\"text/javascript\">$(document).ready(#{script}.init);</script>".html_safe
  end
end

And is included in my layout using: <%= raw(yield :javascript) -%>

Using “raw” because I am in Rails 3 land.

4) At deploy time I use the awesome asset_packager plugin to join all of the controller files into a single file, meaning I only have a single request for JS in my production system. The namespacing ensures that there are no conflicts across the many small files.

That’s it!

I am still investigating the most robust way to setup the namespaces. The above is simple, but not necessarily the best way to go about it.

It would be quite a simple matter to have the files be more granular – you could actually tie them to specific actions in your system. Controller is fine for my use-case as this particular app is very JS-centric and builds actions and views using AJAX and JS in the browser (so a lot of my actions return JSON rather than HTML).

Lucky for me one of the sites was 10 Tips to Stress Less, full of useful advice on how to reduce stress.

The Stress Less campaign is coordinated by the Mental Health Association NSW (MHA) and has the aim of increasing community awareness of the risks of stress and providing tips and ideas on how we can all go about reducing the impact of stress in our lives.

The site is running on my own social “platform” thingy.

Stay tuned for more on this in the very near future.

The Techology

• Ruby On Rails
• Gems & Plugins:
  • asset_packager
  • acts_as_list
  • clearance
  • declarative_authorization
  • facebooker
  • formtastic
  • hoptoad_notifier
  • paperclip
  • sanitize
  • will_paginate
  • vote_fu
• rSpec, Cucumber, Selenium
• PostgreSQL
• jQuery and a range of plugins
• Facebook Connect, XFBML, FBJS
• Heroku with the RPM add-on

Things I learned:

• Facebook Connect is awesome
• Ruby on Rails continues to be awesome
• Heroku is awesome times infinity

Reach Out – http://au.reachout.com/

Reach Out is a web-based service that inspires young people to help themselves through tough times, and find ways to boost their own mental health and wellbeing.
Our aim is to improve young people’s mental health and well being by building skills and providing information, support and referrals in ways we know work for young people.
Reach Out is run by the Inspire Foundation (www.inspire.org.au). Inspire’s mission is to help millions of young people lead happier lives.

All built using an agile methodology on Ruby on Rails, the framework of champions, of course.

I hate it.

I hate the actual concept of the Rails Maturity Model.

I hate it so much it’s making me think it’s time to start moving on from Rails and Ruby. Which is probably a slight over-reaction on my part, but anyway.

At best I think RMM is a marketing exercise for certain Rails consultancies.

At worst it fosters a myopic vision of Best Practice founded in the worst kind of Group Think.

As Yehuda Katz posted:

It makes perfect sense to create a forum for sharing and aggregating the practices that people are finding useful at the moment. What makes less sense is creating a ranked list of “popular” practices, with no obvious mechanism for mediating differences except pure popularity. And even worse is ranking firms by their aggregate level of conformance.
(see Incentivizing Innovation for more).

This is really the at the heart of the  problem. It’s not that we’re against a forum for sharing practice and process, but the moment we start rating and ranking organisations we are engaging in the worst kind of group think that many of us are trying desperately to avoid.

If I wanted this sort of Best Practice, I would have stayed in the Java world …

What happens when you disagree with a number of the current  practices that are make up the RMM?

What happens in the case where you have a different development philosophy?

There is no capacity for dissent in the current vision of RMM.

Full disclosure – I really saw red when I saw one of the RMM practices is “Haml for templates”. Genshi is beautiful. ERB is adequate. Haml is clumsy, brutal, ugly, wrong and demonstrably fucked.

Recently in my travels I found the awesome CloudKit.

CloudKit provides schema-free, auto-versioned, RESTful JSON storage with optional OpenID and OAuth support, including OAuth Discovery.

Cloudkit is similar in some respects to CouchDB – date is stored in JSON, access via REST.

I looked at CouchDB in some detail for a project I have in the works and was very impressed with it’s capabilities, particularly the ability to query the datastore using JavaScript and a Map/Reduce algorithm.

In the end, I have decided that the benefits of persisting* with MySQL (or PostgreSQL) are too great to abandon relational technology just yet – the Rails ecosystem has such good support for these technologies in Active Record.

* And yes, pun intended.

When discussing performance no opinion should be accepted without a metric

One of the great things about Rails is there is a plugin for just about everything and collecting performance metrics is no exception. Most of this is because of Ruby and it’s incredible meta-programming flexibility (but that’s another story). Rails has built-in support for some basic performance monitoring on the request stack (although in recent versions this has been extracted into a plugin), but there are some excellent alternatives.

RPM by NewRelic:

New Relic RPM is a Ruby on Rails performance monitoring application that lets you see and understand application performance metrics in real time so you can fix Rails problems fast. RPM is intuitive. It’s granular. And, it’s a 10-second Rails plug-in install.

metric_fu on GitHub:

metric_fu is a set of rake tasks that make it easy to generate metrics reports.  It uses Saikuro, Flog, Rcov, and Rails’ built-in stats task to create a series of reports.  It’s designed to integrate easily with CruiseControl.rb by placing files in the Custom Build Artifacts folder.

There are some great screencasts on Scaling Rails available from New Relic’s Rails Lab. And yes, scale is orthogonal to performance, but some of the discovery techniques are the same.

Updated:

A commenter has correctly pointed out that metric_fu is not a performance anaysis tool as such. I guess the subtext of what I am saying is that tools like these help track complexity – and complexity is often one of the underlying causes of performance issues.

Named Scopes provide a clean way of adding finders to your Active Record Models – collecting complex finder logic into granular methods that can then be chained together to perform complex combinations of queries. Named scopes are eminently testable as each defined scope can be tested individually, as well as the actual combinations of scope-chains.

Take the following example from some recent production code:

named_scope :by_author, lambda { |*args| {:conditions =>; ["author_id = ?", args.first] }}

named_scope :by_date, lambda { |*args| {:conditions => ["published_at BETWEEN ? AND ? OR updated_at BETWEEN ? AND ?", args.first[0], args.first[1] || Time.now, args.first[0], args.first[1] || Time.now]
}}


As you can see, some quite complex logic can be wrapped into the named scopes, including parameters.

The scopes can be chained, which wraps everything into a single query:


Model.by_author(author_id).by_state("published").by_date(10.days.ago)


Once you have your named scopes set up, you can add some magic to dynamically chain them for user-based filtering.

What follows is from Caboose’s: The awesomest filter and sort ever

In the controller I set up some code to grab incoming parameters and pass them to the Model (in this case called BlogPost).


filter_opts = {}
filter_opts[:page] = params[:page] || 1
filter_opts[:author] = params[:user]
filter_opts[:state] = params[:state]
filter_opts[:date] = [start_date, end_date]

@blog_posts = BlogPost.find_by_filter(filter_opts)


I have removed some of the processing logic here, but the idea is that the user selects from a range of filtering options in the User Interface (selecting a date range, for example) and the controller grabs, cleans and validates these as appropriate and passes it through to the model.

The find_by_filter method is where all of the magic happens. We add the valid scopes to an array, and then chain them all together using inject.


def self.find_by_filter(opts = {})
scopes = []

scopes.inject(BlogPost) {|model,scope|
model.scopes[scope[0]].call(model, scope[1])
}.paginate(:all, rder => order, :page => page)
end


The final line is the magic. Using inject with the model as the accumulator, basically emulates the chained call we saw earlier (by_author.by_state.by_date), but with the added advantage in this instance that only the scopes with the relevant options (defined in opts) are called by the find_by_filter.

As you can see, not only are the named scopes chained together, but I am adding paginate for good measure. Records are cleanly paginated

For more information on named scopes see
Ruby on Rails Active Record Guide.