MetaSkills.net - Home

RESTful AJAX with Forgery Protection

2008-06-18T02:41:00Z

Writing the new HomeMarks has been a great exercise. I've learned that the AJAX Head <strike>Design Pattern</strike> Implementation is more akin to developing a service-oriented application (SOA) since I have moved all client-side coupling from the controllers, like RJS, and only respond with HEAD or JSON data. Today I learned about Halcyon which is self described as a JSON web application framework built on Rack. If you take a look at their example, it looks a lot like HomeMarks v2, pretty cool!

Getting To The Point

Last week I finally got around to doing the controller CRUD for the user's column objects. The core homemarks/app.js JavaScript class contains the one (and only one) AJAX dispatcher/handler for the entire application. One problem that I ran into was how to continue to use forgery protection in rails to protect from CSRF attacks while relying solely on ad-hoc JavaScript requests to a RESTful back-end. I could have turned off protect_from_forgery but that did not feel right. I wanted RESTful AJAX with forgery protection.

My Solution

Since the HomeMarks v2 app has one AJAX dispatcher/handler for the entire app, all I had to do was to get the authenticity token into each and every request. It took a bit of digging in the rails source to find the methods I wanted but here both the ERB snippet I am using in my layout and the helper method found in my application_helper.rb file.

1234	<script type="text/javascript"> <%= auth_params_js_var %></script>


def auth_params_js_var
  unless RAILS_ENV == 'test'
    %|var authParams = $H({#{request_forgery_protection_token}:#{form_authenticity_token.inspect}});|
  end
end

What does this do? It creates a JS variable called authParams at the window level (right term?) that all other functions can use. That variable returns a JavaScript hash that will have a single key/value pair for the rails authenticity token, see below. Basically at this point all you have to do is merge this hash with your parameters option for your AJAX object. You can reference the HomeMarks app.js file in the resources section if you want to see how I did this on my app, code snippet below too.


  doAjaxRequest: function(elmnt,finishMethod) {
    // ...
    var method = elmnt.method || 'post';
    new Ajax.Request(elmnt.action,{
      onComplete: function(request){
        this.completeAjaxRequest(request);
        if (finishMethod) { finishMethod.call(this,request) };
      }.bind(this),
      parameters: parameters.merge(authParams),
      method: method
    });
  }

Resources

The Latest HomeMarks app.js Class. See doAjaxRequest() function.

Coulda Shoulda Woulda

2008-05-30T03:21:00Z

It has been about 6 months now since I started using the Shoulda testing plugin as my BDD/TDD tool of choice. Unlike a lot of other people, I did not flock to the RSpec bandwaggon. Personally I think RSpec is horribly bloated a sledgehammer for a simple issue, the need to have test code organized with nested setups and context blocks.

If you are new to Shoulda, I highly urge you to take a look at the Thoughbot project page for it. If you have the time take a look at some of their other projects, like Paperclip. These guys are really smart. If you really want to see how shoulda can sing, check out Tammer Saleh's presentation of it at the MountainWest RubyConf 2008. In that presentation he covers how you can extend Shoulda and write your own macros that generate additional tests. This is what my blog post is about.

Sample Shoulda Macro For Functional Require Login

Here is a simple module that you might find for any restful authentication system. This would be included in your main test_helper.rb file where it would add the normal login_as(user) method. The good part I want to point out is the should_require_login(*actions) macro method that shows off a neat example of how you could use Shoulda in your functional tests at the class level.


module AuthSystem
  module TestHelper
    
    def self.included(receiver)
      receiver.extend ClassMethods
      receiver.send :include, InstanceMethods
    end
    
    module ClassMethods
      
      def should_require_login(*actions)
        actions.each do |action|
          should "Require login for '#{action}' action" do
            get(action)
            assert_redirected_to(login_url)
          end
        end
      end
      
    end
    
    module InstanceMethods
      
      def login_as(user)
        if u = users(user)
          @request.session[:user_id] = u.id
        end
      end
      
    end
    
  end
end

Here is how it would look in the controller functional test. These are all contrived examples, but I think it illustrates how Shoulda can be used and in general how you can make your own macros that test at a higher level.


class UsersControllerTest < ActionController::TestCase
  
  should_require_login :edit, :update, :etc
  
end

The "AJAX Head" Design Pattern

2008-05-24T20:00:00Z

This is the first of a few articles covering the total rewrite of the HomeMarks.com code base as I upgrade it to Rails 2.1. The "AJAX Head" pattern is the moniker I have assigned to methodology that has come about during said rewrite and the design decisions I choose early on. The rules were simple...

Total Unobtrusive JavaScript (No Tag Soup)
No RJS Controller Responses

Rails makes it very easy to generate JavaScript with Ruby. The generator methods are extensive and cover both the Prototype and Scriptaculous libraries. The first version of HomeMarks used the generators exclusively to augment both the views and controller responses. In fact, I used a technique that is covered in the latest Advanced Rails Recipes (way before it came out) under the "Replace In-View Raw JavaScript" chapter. Basically I created helper methods that generated JavaScript shared by both the views and controllers. It was a great technique but things got messy quick. So life was good back then, I had a lot of Ruby code and a very dynamic site, but something did not seem right...

What Is The AJAX Head Pattern?

It is an experiment into a vision to see what happens when you make the decision to totally go unobtrusive. Not just in your views but the controllers too! Imagine it this way — your controllers are slim APIs. They should do nothing but render a page on a GET request and when it comes to a POST/PUT/DELETE they should do nothing more than just say YES or NO (with errors).

Now lets think about that. What does that mean for an application that uses exclusive AJAX calls for dynamic page updates? It means that your visual client (the browser) will need to know ALOT less from the controller about what to do. It's great, the browser knows what is on the page, from the GET request, and what it needs to do with it. The client only needs to tell the remote resource store what it did. In this pattern the controller is relegated to nothing more than acting on model data and letting the client know if it succeeded or failed. So in short.

The AJAX head design pattern forces the view and controller to work in isolation with the most minimal coupling possible. Kind of like a web service.

Tools and Code Needed

A application that does just about everything with AJAX.
Fluency with ActionController::Base#head method and HTTP status codes.
Site-wide exception rescues for ActiveRecord::RecordInvalid.
Global client-side AJAX request and response handlers.
Global client-side error handlers.

This may seem like a daunting list, but its pretty simple when you break it down. Let's do each one at at time with some of the current code from HomeMarks. The HomeMarks app is my first check on the list. When I did this app just about EVERYTHING was done via an AJAX call to update the page. Now on to the others.

2) Head And Status Codes

The ActionController::Base#head method and HTTP status codes are the second item on the list. The head method is very useful when you just want to respond with HTTP headers and no body content. This is typical behavior when an app responds to external web services requests. This is important to note, I chose to rely on head responses as a way to meet my design decision of not using any RJS responses from the controller.

The basic usage of the head method is simple, you just pass a symbol to the head method that is the lowercase underscore equivalent to an HTTP status code. For instance, if you wanted to respond with success, choose a status code from the 200 range, the easiest being 'OK', which would look like head(:ok). If you wanted to respond to bad authentication, you might use the 401 code like so, head(:unauthorized). Here is an example from HomeMarks restful user signup action.


class UsersController < ApplicationController
  # ...
  def create
    User.create!(params[:user])
    head :ok
  end
  # ...
end

There is actually a number of things going on in those 2 lines of code above. If the user is created, the AJAX request will get a simple 'OK' message via the head method. Obviously the client will need to know what to do on its own. But if errors happen what to do? This brings us to...

3) Invalid Object Handling

When Rails 2 came out, it gave us a very useful tool for our controllers, the ActionController#rescue_from method. It allows you to delegate exception handling to a method either per controller or site wide for a specific exception class. So enter the RenderInvalidRecord module, show below.


module RenderInvalidRecord
  
  def self.included(base)
    base.rescue_from(ActiveRecord::RecordInvalid, :with => :render_invalid_record)
  end
  
  protected
  
  def render_invalid_record(exception)
    record = exception.record
    respond_to do |format|
      format.html { render :action => (record.new_record? ? 'new' : 'edit') }
      format.js   { render :json => record.errors.full_messages, :status => :unprocessable_entity, :content_type => 'application/json' }
      format.xml  { render :xml => record.errors.full_messages,  :status => :unprocessable_entity }
      format.json { render :json => record.errors.full_messages, :status => :unprocessable_entity }
    end
  end
  
end

Once included in your application.rb file, every ActiveRecord::RecordInvalid exception will be handled by the render_invalid_record method. I use this pattern often and it is the primary reason I always use the bang methods that end with an exclamation point, such as create! or save!. This module above was inspired by Joshua Peek's own module of the same name but has been edited here to fit my needs. Both the "xml" and "html" response formats are not used by HomeMarks but are included here to show how this module can work for any request type.

Now, how this fits into the AJAX Head pattern. The design decision of not having RJS responses means one of two things needs to come from the response. First, if the response is a success, meaning in the 200 range, then it is assumed that the client only needs to know that all is 'OK'. Second, if the request has errors, then the response needs to communicate them. I choose JSON for the format of these errors since all AJAX request objects from Prototype automatically include a application/json accept header. So that is why I changed both the "js" and the "json" response type in the RenderInvalidRecord module to both serialize the objects full error messages into a JSON array with an HTTP status code of 422 "Unprocessable Entity" which seemed to make the most sense to me. This pretty much wraps up the server side part of the pattern. Now onto the client side. Everything from here on is personal taste on how your client will react to an "good" or "bad" response object.

4) Client-Side AJAX Handlers

I can not stress enough how much you have to bake your own functions to handle the client side reaction to both good and bad AJAX responses. The client's ability to know what to do with errors will be tightly coupled to AJAX handlers and the design choices of your site. In the examples below I have broken up methods in the same JavaScript classes to show you the parts for a specific behavior in a more concise manner. Also please note that I am using Prototype module and class organization heavily in HomeMarks. This allows me to build a Base JavaScript module and classes that mimic Rails models which inherit/mixin Base methods. I also use the Scriptaculous Builder class for creating DOM fragments too. Now back to business.

The first part of the AJAX head pattern was to use unobtrusive JavaScript. Because of this design choice, there are no remote_form_for methods in the HomeMarks view code. All forms are simple form_for methods. Below is a sample of the HomeMarksSite JavaScript class that creates AJAX handlers for all site forms. The below example is slimmed down to only show the initialization of this behavior for the signup form. But no matter which form is given this behavior the process is the same.

The form's submit event is handled by startAjaxForm(). It does the following:

Stops the normal submit behavior.
Adds a loading spinner in the #form_loading span.
Creates a new AJAX.Request using the forms own action. It also binds a function to delegate the logic of completing the form when the request is finished. More on that later in #2 below.
Finally it disables the form.

Once a response comes back from the server, the delegateCompleteAjaxForm() function will be called with both the form object and the AJAX request object. The logic of this function includes:

Figuring out the "mood" of the request using getRequestMood() function which is part of my base module.
Sends the form and mood to the completeAjaxForm() function. This function will replace the loading spinner with an image that reflects a good or bad response.
If the mood is good, meaning the response status code was within a 200 range, then the function will delegate to a function specific for that forms success using a simple case statement.
If this mood is bad, meaning the response status code not within a 200 range, the form will be enabled and the response JSON errors will be displayed. Currently I am using a modal class for this. Again more on that later. You may also note that my base module has a function called messagesToList() that process the response into a DOM <ul> list.


var HomeMarksBase = {
  getRequestMood: function(request) {
    return (request.status >= 200 && request.status < 300) ? 'good' : 'bad';
  },
  messagesToList: function(request) {
    var messages = request.responseJSON;
    var messageList = UL();
    messages.each(function(message){ 
      messageList.appendChild( LI(message.escapeHTML()) );
    });
    return messageList;
  }
};
var HomeMarksSite = Class.create(HomeMarksBase,{ 
  initialize: function() {
    this.signupForm = $('signup_form');
    this.initEvents();
  },
  startAjaxForm: function(event) {
    event.stop();
    var form = event.findElement('form');
    var options = Object.extend({imgSrc:'loading_invert.gif'}, arguments[1] || {});
    var loadArea = form.down('#form_loading');
    var imgTag = IMG({src:('/images/'+options.imgSrc)});
    $(loadArea).update(imgTag);
    new Ajax.Request(form.action,{
      onComplete: function(request){ this.delegateCompleteAjaxForm(form,request) }.bind(this),
      parameters: form.serialize(true)
    });
    form.disable();
  },
  delegateCompleteAjaxForm: function(form,request) {
    var mood = this.getRequestMood(request);
    this.completeAjaxForm(form,{mood:mood});
    if (mood == 'good') { 
      switch (form) { 
        case this.supportForm : this.completeSupportForm(request); break;
      }
    }
    else { 
      form.enable();
      if (!request.responseText.blank()) {
        var flashHTML = DIV([H2('Errors On Form!'),this.messagesToList(request)]);
        this.flashModal('bad',flashHTML);
      };
    };
  },
  completeAjaxForm: function(form) {
    var options = Object.extend({mood:'good'}, arguments[1] || {});
    var loadArea = form.down('#form_loading');
    var completeId = 'complete_ajax_form_' + form.id;
    var imgSrc = '/images/'+options.mood+'.png';
    var moodHtml = SPAN({id:completeId,className:'m0 p0'}, [IMG({src:imgSrc})]);
    $(loadArea).update(moodHtml);
    setTimeout(function() { $(completeId).fade(); },3000);
  },
  completeSignupForm: function(request) {
    var message = "Thank your for signing up for your own HomeMarks page. An email has been sent to " +
      "your address along with a link to activate your account. If you have not done so already, please " +
      "take a moment to read the HomeMarks documentation.";
    var flashHTML = DIV([H2('Signup Complete:'),P(message)]);
    this.flash('good',flashHTML);
  },
  initEvents: function() {
    if (this.signupForm) { this.signupForm.observe('submit', this.startAjaxForm.bindAsEventListener(this)); };
  }
});

5) Client-Side Error Handling

Currently I have 3 client-side options that I can use to present errors back to the user from the JSON array in AJAX response. The first I started out with was using the alert() function. That got boring real quick, but I left my implementation below which is part of the base class, called messagesToAlert().

The second slightly more interesting way was to create a flash message that used the same XHTML/CSS already present in my layout file. This was real easy to implement. Basically using the ERB fragment below in my layout, I guaranteed that I had 3 unique DOM elements for each of my flash message styles, good/bad/indif. Now all I had to do was to create an accessor in my HomeMarksSite class. I choose this.flashes. I then created a clearFlashes() function and then a flash() function that would take the mood and the HTML to embed, viola – I can now call this.flash.('good',someHTML) and I get the same type of flash one would have seen if I set it in the controller and rendered. Note, this is what I used on the the signup form success above.


<% [:good,:bad,:indif].each do |key| %>
  <div id="flash_<%= key %>" class="flash_message" style="display:<%= flash[key].blank? ? 'none' : 'block' %>;">
    <span><%= flash[key] %></span>
  </div>
<% end %>


var HomeMarksBase = {
  messagesToAlert: function(request) {
    var messages = request.responseJSON;
    var alertText = messages.join(".\n");
    if (alertText.endsWith('.')) { alert(alertText); } else { alert(alertText+'.'); };
  },
  messagesToList: function(request) {
    var messages = request.responseJSON;
    var messageList = UL();
    messages.each(function(message){ 
      messageList.appendChild( LI(message.escapeHTML()) );
    });
    return messageList;
  }
};
var HomeMarksSite = Class.create(HomeMarksBase,{ 
  initialize: function() {
    this.flashes = $$('div.flash_message');
  },
  clearFlashes: function() {
    this.flashes.invoke('hide');
    this.flashes.invoke('update','');
  },
  flash: function(mood,html) {
    this.clearFlashes();
    var moodFlash = this.flashes.find(function(e){ if (e.id == 'flash_'+mood) {return true}; });
    moodFlash.update(html);
    moodFlash.show();
    $('site_wrapper').scrollTo();
  }
});

Lastly, and probably the coolest, is the HomeMarksModal JavaScript class I created. This is my new default way of errors to a user. It can be seen in all my video examples on this page. To the right is another example of the login form that uses the same handlers described above. The HomeMarksModal JavaScript class is a bit large to paste inline in this article, but if you want to see the latest version, you can always get it from the master branch of the homemarks_core project on Github.com. When you bind an instance of this object to the window/document, it will automatically crate the modal HTML using Builder. If you want to use it, make sure to get the CSS and images the project too. Below is a function that I put in my site class that allows me to call this.flashModal('good',someHTML)).


var HomeMarksSite = Class.create(HomeMarksBase,{ 
  flashModal: function(mood,html) {
    var moodColor = this.flashMoodColors.get(mood);
    HmModal.show(html,{color:moodColor});
  }
});

Wrapping It Up

This article turned out a lot longer than I had wanted. The AJAX head pattern is pretty simple and it is really fun to see a two line user signup action yield such interactive results. Something also feels good about not putting view code in the controller, yes you can look at inline RJS as view code. Sure it requires that you do a lot more JS work, but there are benefits.

Image you have team of programmers, one person can stay in model/controller land while the other stays on the view/javascript. The model/controller person would write their own tests (PLEASE TAKE A LOOK AT MINE), while the view/javascript person might even take the initiative to use selenium to test the JavaScript. At the time of this writing, I have not done any selenium tests since the plugin for rails is not compatible for 2.0. That last benefit I could think of for this design pattern is that you could easily update view code without restarting your rails app. Just update the JavaScripts and your good to go.

In closing, please let me know what you think. Perhaps you have a better name for the design pattern? Perhaps someone else has a name for it already?

Resources

Original application_helper.rb from HomeMarks v1. An overboard example of shared view/controller tagsoup/rjs.
The latest Advanced Rails Recipes book. See the chapter on "Replace In-View Raw JavaScript". I discourage this technique used in mass.
Rails API for the ActionController::Base#head method.
Rails API for the HTTP status codes.
Rails API for the ActionController#rescue_from method.
The latest RenderInvalidRecord module from the HomeMarks core.
The latest HomeMarksModal JavaScript class from the HomeMarks core.

Using RubyAMP TextMate Bundle With /opt Ruby

2008-04-25T14:34:00Z

I've been a TextMate user for a long time now and I'm still finding new things to do with it. Here recently I wanted to use the RubyAMP TextMate Bundle and was a little miffed to find that it was pointing to my OS X system ruby. The error message looked something like this when it went looking for my ruby/gems.

No such file to load -- appscript (LoadError) from 
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require’
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require’
...

No such file to load -- appscript (LoadError) from 
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require’
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require’
...

My problem is that I use ruby installed from MacPorts (yes I have Leopard). I do this because I put a lot of crap and extra dependencies into my opt direcotry and I do not trust Apple to NOT blow away the crazy dependencey hell I would have ended up creating in the standard bin directories if I chose not to use MacPorts. I would have thought that my TM_RUBY environment variable being set correctly to /opt/local/bin/ruby in my TextMate preferences would have given RubyAMP enough info to find my correct gem environment. Obviously not... and it took me quite a bit of digging around to learn what else I needed to do. For starters, here is more than you ever wanted to know about how TextMate gets the $PATH information. You can skip reading that and do these simple steps.

Open /Developer/Applications/Utilities/Property List Editor.app
Click on "New Root", now expand that node in the list view below.
Click on "New Child", name it PATH
The child row for PATH should be a String type
Enter your PATH info here, should mimic your .bash_profile, without $PATH
Save this file to your Desktop as environment.plist

Now do this in the console, we need to move that file to an invisible .MacOSX folder in your home directory. In all likelyhood this folder does not exists, nor does the environment.plist file inside of it, if so, please do your own work to make sure that you do not overwrite existing information. Now:

mkdir ~/.MacOSX
mv ~/Desktop/environment.plist ~/.MacOSX

With the file in place, you now have to log out and back in. To be on the safe side, just reboot. Now your OSX apps, including TextMate and it's bundles will have the correct PATH information to get to your binaries. See below for an example of what my environment.plist file looks like. Note too that my full PATH info in that file is this string /opt/local/bin:/opt/local/sbin:/opt/local/lib/mysql5/bin:/opt/local/apache2/bin. Notice that path info after the apache2 path? This is where you should add the default path info for a Mac. Unlike the .bash_profile, you can not specify $PATH and have it expanded from within a plist file. So to be on the safe side, when I added this, I put the standard mac path info at the end of my own additions. That standard path info is /usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin

How to use Passenger (mod_rails) with rails edge 2.1

2008-04-22T03:12:00Z

If you are like me and have been using passenger, then you may have run into an issue when working with rails edge. I mean the REAL rails edge on Git, not that fancy rake task which I think is still pointing to a subversion snapshot. Let me take an aside on how to freeze rails edge to a project that you are managing in Git. This method is akin to using svn:externals. As a cop out, here are 3 links that you should read to learn how.

UPDATE: This issue has now been resolved in the official release.

OK... now that you know how to freeze the real rails edge to your git project, and if you have been using passenger, you may now have seen this error below. The basic problem is that passenger bypasses the work that the rails boot.rb does and in doing so, it only accounts for setting RAILS_ROOT during the ApplicationSpawner process and not the FrameworkSpawner process. In the latest rails, ActionPack is now relying on RAILS_ROOT to be set by calling Rails.root (shortcut method to that constant) when loading. So my fix was to add the RAILS_ROOT to the FrameworkSpawner class.

Framework that failed to load: Vendor directory: /Users/foo/project/vendor/rails 
Error message: Anonymous modules have no name to be referenced by 
Exception class: ArgumentError

Resources

Now on Passenger (mod_rails)

2008-04-13T18:15:00Z

Well this is working out well so far. I'm really liking the Passenger (mod_rails for Apache) extension. Right now I have this Mephisto site running it and it seems to be doing really well. Also, most people do not do this, but I run a full development stack Apache/MongrelCluster to mimic production boxes the best way I can. Now I am running mod_rails on all my development hosts.

Some Things I Like

I do not have to fuss with OS X launchd startup scripts for my mongrels, just Apache.
Typically in a high volume site that runs mongrel behind an Apache proxy balancer, will get a large timeout and proxy error even if the mongrels are immediately available. Passenger has a nice way to restart the app, just touch the tmp/restart.txt file.

Some Things I'm Waiting For

The RailsEnv can not be set per virtual host. You have to set RAILS_ENV = 'development' in each app if you want to run mixed virtual hosts with different environments.
Normally I would pass environment variables to the console when issuing mongrel cluster starts. I would really love to see Passenger support apache environment variables.

Autotest Playlist For Red/Green Feedback

2008-04-06T19:11:00Z

Here is how to get a playlist of sounds that will be hooked to both your autotest :red and :green callbacks. Basically this gives you a folder of sounds that are played one after another, in a loop, as your tests pass or fail. See this move below for a quick example.

Step 1: Install QTPlay from MacPorts

sudo port install qtplay

Step 2: Download My Autotest Playlist Files

cd ~
curl -O http://www.metaskills.net/files/autotest_playlist.tar
tar -xf autotest_playlist.tar
mv autotest_playlist .autotest_playlist && rm autotest_playlist.tar

Step 3: Modify Your .autotest File

User your favorite editor to open your ~/.autotest file. And add this code below to it. Now you should be setup to have your own playlist of sounds that play using the qtplay binary installed above. If you want to play around with the sounds, then open ~/.autotest_playlist/sounds and start swapping out sounds. By the way, I made the :initialize and :quit sounds using the new Alex voice in Leopard. I hijacked some text to speech and then ran an audio tool called WavePad to speed change, flange, and chorus the voice a little bit.

12	require '~/.autotest_playlist/playlist'

Credits:

The idea for this came from FoxWorks. Shouts out "Thank You".

Autotest Infinite Loop On Failure & Error

2008-04-06T17:52:00Z

I just had an issue pop up today that seemed to be an issue for a few others. It seemed that all of a sudden that my autotest was stuck in an infinite loop after a failure or error. At first I thought it was related to some additions to my ~/.autotest file but after commenting out the whole lot of additions there, I realized it was something else. Here was my fix. Basically I think these errors are always related to a file that has changed during your test run. Now we just have to find out what that files are. Here are the steps I took to find out.

Step 1: Gather Changed FIle Info

To find out what files are changing. To do this add the -v option when you start autotest. This will cause it to run in verbose mode. Now after you have failed a test and YOU KNOW YOU DID NOT SAVE ANYTHING watch what happens below your listing of test, assertions, failures, and errors. There will be an array dumped that will contain the files change that have caused autotest to start another test cycle. In my case here is what I saw.

1) Failure:
test_truth(BookmarkTest)
[test/unit/bookmark_test.rb:6
test/unit/bookmark_test.rb:5]:
<false> is not true.

1 tests, 1 assertions, 1 failures, 0 errors
[["config/uuid.state", Sun Apr 06 13:58:55 -0400 2008]]
Dunno! config/uuid.state

Ah ha... there it goes. I was using a UUID state file and it appears that file being written into the config directory is the culprit. By default autotest does not ignore that directory.

Step 2: Fix The Problem

We have two options here. You can either add an autotest exception in you ~/.autotest file or you can bail out. My option is to bail out because I should not be adding a file at run time to the config directory. It would seem a better place would be the tmp directory. However if you think that adding an exception to your ~/.autotest file would be more appropriate, here is the syntax

1234	Autotest.add_hook :initialize do \|autotest\| ['.svn','.hg','.git'].each { \|exception\| autotest.add_exception(exception) }end

Step 3

How To Stop Delivery Of An Email Within An ActionMailer Method

2008-04-03T23:29:00Z

OK, so you want to keep your code placement REALLY organized. You have read about my persnicketyness and now you want to practice the best in concern placement and keep those controllers of yours really slim. Like me, you may want to try and keep controller feature additions to very specific one liners of code. Organizing your controller code to do just that with ActiveRecord models or even your own custom classes is a pretty easy task, but how do you keep things simple when dealing with controller actions that have to send email AND you want that single email link of code to be responsible for everything in it's own encapsulated way.

The answer is to push the logic back to the model again. Your controllers should not be concerned with the logic that deals with your own business rules for sending email. The problem with ActionMailer is that most people just use the dynamic MyMailerClass.deliver_ methods that utilize method_missing to instantiate a mailer classs, and send an email in one fell swoop. I like this usage too, but the challenge is how to tell an instance of a the ActionMailer::Base class that it needs to stop delivery within a method definition that is all set to deliver? The answer is Ruby singleton method magic.


module ActionMailer
  class Base
    
    # A simple way to short circuit the delivery of an email from within
    # deliver_* methods defined in ActionMailer::Base subclases.
    def do_not_deliver!
      def self.deliver! ; false ; end
    end
    
  end
end

I suggest placing this code into your lib/core_ext/action_mailer.rb file. It will allow you to write mailer methods that can short circuit themselves to stop delivery. For instance:


class MyMailerClass < ActionMailer::Base
  def user_notification(user)
    # ... 
    do_not_deliver! if user.email.blank?
  end
end
# In your controller code.
MyMailerClass.deliver_user_notification(@user)

Now you do not have to worry about placing delivery concerns in the controller and even worse duplicate that code when you have to use the same mailer method in multiple places. This works by letting the instance of the ActionMailer::Base class define it's own deliver! method which trumps the delier! method called by that object normally defined in ActionMailer::Base.

Resources

MacBook With 4GB Of Memory

2008-04-03T22:45:00Z

My MacBook is about a year old now and I've read in quite a few places that they could be upgraded to around 3.3GB of memory for this specific model. Unlike the latest MacBook which can "as advertised" accommodate 4GB of memory, the theory was that the Santa Rosa chipset can address all 4GB. It could very well be that technically my MacBook is only using ~3.3GB of that memory but the performance has been significant for a very cheap stick of RAM. I highly recommend Crucial.

I think this upgrade will have to hold me for some time. In general it has really helped my uptime. Odd as that is I think working with only 2GB of memory caused a lot of IO swap and memory corruption. Especially when stopping and starting so many different mongrels for local Rails development. As of this writing I have not found an issue that I have had to reboot for... uptime 10 days and going strong.

To keep my uptime going strong, I just purchased an app called iFreeMem today after reading about it on TUAW. Because I use PhotoShop ever now and then it really helped having this utility free up some memory that it would not release. So far it is working great!

Don't Be A Plinko Programmer

2008-03-26T22:35:00Z

One of the things that I have really grown persnickety about is the placement of code. For example, I am a huge advocate that controllers in a rails project should read like a mini Domain Specific Language (DSL) and that as much logic as possible be delegated to the models. In my opinion the best way to do that in a Rails project is to learn the proper usage of ActiveRecord Association Extensions. You can check out the Rails API on this page and scroll down to the section called "Association Extensions" if you read the official docs. In short:

The proxy objects that control the access to associations can be extended through anonymous modules. This is especially beneficial for adding new finders, creators, and other factory-type methods that are only used as part of this association.

Now this brings me to the topic of my article, what is a Plinko Programmer. If you have no class and don't even know what Plinko is, Wikipedia has a great write up on it. A Plinko Programmer is someone that writes code which smells in a few ways. For instance they use excessive arguments in their methods and unnecessarily pass objects around as arguments. They like to bake their own Enumerable methods vs using the ones readily available. They even like to create large class level methods, or even worse controller actions, that really should be factory methods in 2 or more classes. The analogy is akin to much of the Java code I have rewritten in Rails. Plinko code is long and full of if/else conditions, it's just like the game. You drop an object in the top and just watch it "by chance" work it's way thru the method/function. It is a nasty way to write code and if for anything else it is illegible and hard to test.

What Is The Right Way?

Here is a short example of how to use Association Extensions. This is a simple example, but when you get used to really using association extensions you will begin to see just how much of your code really belongs there. Let's assume you have a simple invoice and items class.


class Invoice < ActiveRecord::Base
  has_many :items, :class_name => 'InvoiceItem', :foreign_key => 'invoice_id'
end
class InvoiceItem < ActiveRecord::Base
  belongs_to :invoice
  def total
    # Some complex stuff
  end
end

Now let's say that you want to have a clean little method for getting the total of the Invoice object. Resist the temptation to simple add an instance method to the Invoice class. Although it is logical to have @invoice.total it is better to add it too the association extension. Why? Well think about it, what are you doing? The answer is that you are working with a "collection" of InvoiceItems. It turns out that this is the first part of what the association extension is for, an easy way to work with a collection that has the benefits of knowing how to proxy to methods that can reflect back down to the original caller. It's hard to explain but I'll just leave you with my persnickety code example. Your general rule should be if you are working with the collection in part or in total, then the association extension is the place for it. Keep in mind that so far I have only talked about has_may association extensions, you can do these for one-to-on belongs_to and has_one associations as well.


class Invoice < ActiveRecord::Base
  has_many :items, :class_name => 'InvoiceItem', :foreign_key => 'invoice_id' do
    def total
      proxy_target.map(&:total).sum
    end
  end
end
class InvoiceItem < ActiveRecord::Base
  belongs_to :invoice
  def total
    # Some complex stuff
  end
end
# Would yeild code like:
@invoice.items.total

P.S. Here lately I've been creating an app/concerns directory where I put modules that encompass mixed in behavior in so many ways for top level models. Typically these modules/concerns shared instance and class methods with two or more primary classes. They have become an excellent home for association extensions since many large applications will define the same association from different models in the object. To keep the code from duplicating in those different models it is better to do something like this


# This file "invoice_item_concerns.rb" would reside in app/concerns
module InvoiceItemConcerns
  module AssociationExtensions
    def total
      proxy_target.map(&:total).sum
    end
  end
end

class Invoice < ActiveRecord::Base
  has_many :items, :class_name => 'InvoiceItem', :foreign_key => 'invoice_id', :extend => InvoiceItemConcerns::AssociationExtensions
end

class PackingSlip < ActiveRecord::Base
  has_many :shipments, :class_name => 'InvoiceItem', :foreign_key => 'packing_slip_id', :extend => InvoiceItemConcerns::AssociationExtensions
end

class InvoiceItem < ActiveRecord::Base
  belongs_to :invoice
  def total
    # Some complex stuff
  end
end

# Would yeild code like:
@invoice.items.total
@packing_slip.shipments.total