So What Is The Problem?

Guard::Jasmine allows you to continuously test your JavaScript right from the terminal window just like your Ruby code. The only drawback is that the console debugging is less than helpful. Guard::Jasmine will not allow you do view a string version of every object nor see line numbers of calling files. Both of these are invaluable when your stuck in a testing hole and just need to inspect a few objects. So if you are tired of seeing [object Object] in your Guard::Jasmine output, let's fix it right away.

The first place we need to patch things up is Guard::Jasmine itself. In my last article I covered how to monkey patch Jasminerice in a config/initializers/jasminerice.rb file. My Guard::Jasmine freedom patch will be placed in that same file. Pasted below, this does two things vs the original. First it changes the report_specdoc_logs method to not pass true to the format_log_message method. Second, the format_log_message method itself now has the message regular expression changed to a multi-line scan. It will also look out for a custom prefix tag and allow it to pass through. This is for our pretty objects. Anything else now outputs the message with the file and line number, something previously stripped by Guard::Jasmine.

# coding: utf-8
if defined?(Jasminerice) && Jasminerice.environments.include?(Rails.env)

  # Other Jasminerice patches from:
  # http://metaskills.net/2012/01/17/rails-and-spine-js-jasmine-testing-part-2/
  # ...
  
  # Patch Guard::Jasmine to use a custom formatter for log messages that
  # allows multi-line objects to be printed with the line numbers.
  module Guard
    class Jasmine
      module Runner
        class << self
        
          def report_specdoc_logs(spec, options, level)
            if spec['logs'] && (options[:console] == :always || (options[:console] == :failure && !spec['passed']))
              spec['logs'].each do |log|
                Formatter.info(indent("    • #{ format_log_message(log) }", level))
              end
            end
          end
          
          def format_log_message(message)
            if message =~ /(.*?) in http.+?assets\/(.*)\?body=\d+\s\((line\s\d+)/m
              pp_prefix = '[myLog]'
              msg, file, line = $1, $2, $3
              if msg.starts_with? pp_prefix
                msg.sub pp_prefix, ''
              else
                "#{msg} in #{file} on #{line}"
              end
            else
              message
            end
          end
          
        end
      end
    end
  end
  
end

A JavaScript Pretty Print Library

So now that we have Guard::Jasmine not stripping multi-line console messages to one line and printing file and line numbers, we are ready to hook into it. But first we need a JavaScript library that pretty prints objects for us and wrap this all up behind our own interface to console.log. During my research I found a library called jsDump and decided to use a fork of the project on github. So go download that file and place it in vendor/assets/javascripts/jsDump.js of your Rails project. Next you will want to add it to your spec/javascripts/spec.js manifest like so. My below example is pulled right from my previous article and I have placed jsDump right after my jasmine files.

#= require jasminerice
#= require mock-ajax
#= require jsDump
#= require application
#= require jasmine-myapp
#= require_tree ./lib/
#= require_tree ./models/
#= require_tree ./controllers/
#= require_tree ./views/

Logging Helpers - Using BlackCoffee

In my last article I mentioned how I would talk more about the jasmine-myapp file in the manifest above. Now is the time. I recommend that this file is place to write all your top level helpers and functions for Jasmine or any other testing libraries in your JavaScript stack. Think of this file as your Ruby test_helper.rb or your own extensions to ActiveSupport::TestCase. My advice is that these functions all be written to pollute the time level namespace as other Jasmine helpers do, like the beforeEach and clearAjaxRequests. This makes things easier but be conscious of that decision and write functions keeping that in mind.

The only thing working against is is Sprockets/Tilt rendering CoffeeScript files in their own closure. Which is something you should really not fight! But in this case I think it is fine to have this particular file avoid that. Which allows us to (a) write our helper code in CoffeeScript and (b) use these functions as helpers in the global space like other Jasmine helpers. So enter my Sprockets BlackCoffee gem. This is a simple gem that exposes a CoffeeScript template that uses the --bare option to keep your file from being wrapped in a closure. All you have to do is give the file a .js.black_coffee extension and it will just work. So let's assume you have a spec/javascripts/jasmine-myapp.js.black_coffee created and the gem installed like so.

group :assets do
  # ...
  gem 'sprockets-blackcoffee'
end

Finally, here are examples of my logging helpers in the jasmine-myapp file. The myLogParser uses jsDump to get back a pretty formatted string of any object if that object is not already a string. The primary logging helper myLog will prefix your message with [myLog] so the Guard::Jasmine recognizes the message and outputs only the object. The last helper myLogLine will do just like the other, but will allow the file and line number tobe printed too.

myLog = (obj) ->
  console.log "[myLog]#{myLogParser(obj)}"

myLogLine = (obj) ->
  hmLogParser(obj)

myLogParser = (obj) ->
  if typeof obj is 'string' then obj else jsDump.parse obj

In Practice

Here is an example of a Jasmine spec where I was using console.log before the patches above and what it would output to the terminal.

#= include spec_helper

describe 'User', ->

  it 'has been configured with proper attributes', ->
    @user = new User id: 2, email: 'bob@test.com'
    console.log @user.attributes()
    expect(@user.email).toEqual 'bob@test.com'

User
  ✘ has been configured with proper attributes
    ➤ Expected 'foo@bar.com' to equal 'bob@test.com'.
    • [object Object]
ERROR: 1 specs, 1 failures
in 0.653 seconds  

There is the totally helpful [object Object]. But if we now change our code to leverage out patches and change console.log to hmLog @user.attributes() to use our helper. We will get this. If you need a pretty object with line numbers. Just use hmLogLine.

User
  ✘ has been configured with proper attributes
    ➤ Expected 'foo@bar.com' to equal 'bob@test.com'.
    • {
       "email": "foo@bar.com",
       "id": 2
    }
ERROR: 1 specs, 1 failures
in 0.653 seconds

I hope this is helpful to anyone using Guard::Jasmine with a desire to see better output. If you continue to follow my series, my next post will be a deeper dive into Jasmine testing of Spine.JS applications.

Related

• Rails & Spine.JS - Using The CoffeeScript Source
• Rails & Spine.JS - Jasmine Testing Part 1
• Rails & Spine.JS - Jasmine Testing Part 2
• Pretty Console Logging With Guard::Jasmine & BlackCoffee

Resources

• Sprockets BlackCoffee Gem
• Guard::Jasmine - Automatically tests your Jasmine specs on Rails.
• Jasminerice - Pain free CoffeeScript testing under Rails 3.1.

That Engine Is Gonna Need An Overhaul

So did I mention that Jasminerice is a Rails engine and that you can run your tests by accessing the /jasmine URL in your development environment's browser? Good. As uncool as browser testing is, sometimes that it useful. For instance console.log statements will not show up in your Guard's test output. But hopefully that is an edge case and you are really using guard-jasmine and watching your specs run in the terminal window. The question now becomes how can I leverage Jasminerice and its associated engine to really test my Spine.JS application with a full-fledged DOM? The answer is simple, let's hack the Jasminerice engine to load up our application while running the Jasmine specs.

A Review Of Jasmine And HTML Fixtures

This might be a bit contraversial (or maybe just wrong) but I would like to examine why we might hack the Jasminerice engine for a few minutes. Jasmine bills itself as behavior-driven development for JavaScript, to which I disagree. I think Jasmine first and foremost is an all-purpose testing framework. Depending on how you use it determines what it becomes. In my case, I have been doing a lot of unit testing of my Spine.JS models and supporting libs as I learn the framework and build my system. So my usage now could be called TDD at both a unit and functional level. Later on, I plan on doing higher level integration testing with Jasmine, at this time it will be my BDD tool. Normally I do not get caught up in symantics but I think it is important to understand a few lexical terms before I start showing off how I use Jasmine to test my Spine.JS application.

Now that I have set my higher order bit for Jasmine as my unit, functional and itegration testing framework for Spine.JS – I would like to show how my solution below might differ from other practices. Experienced Jasmine users rave about extensions that allow you to load HTML fixtures to functionally test units of code. In fact, the Jasminerice gem includes a custom version of the jasmine-jquery library which among other things allows you to do just that. Let me be clear on this, there is nothing wrong with that! As with all things software, proper solutions depends on what you are doing and need. In my case, I believe that testing your Spine.JS application with Rails only needs to hook into your existing application without the need for fixtures and excessive mocking and stubbing.

My basis for this argument is founded on a few principas that I believe all rich client side JavaScript applications should follow. Most important, the application is a single page load and all other calls to the server happen from that one page via AJAX. Every other part of your Rails application then becomes an API client to the JavaScript application. All views are client side only, most likely in a JST namespace.

Hacking Jasminerice

Turns out this is really easy since Jasminerice is just a simple Rails engine with few moving parts. It has a SpecController that renders a basic layout which requires your application's JavaScript assets along with Jasmine. The goal is to tell it to render your single application page that loads up your Spine.JS app with a few additional hacks. When done, we are going to have Jasminerice in your full control. This means we get the same CSS and JavaScript as our real application along with a solid foundation to extend Jasminerice at our whim. This leaves us with a clean canvas suitable for Jasmine unit, functional and integraiton testing all wrapped up into one.

# In: config/initializers/jasminerice.rb

module Jasminerice
  
  module MyApplication
    extend ActiveSupport::Concern
    included do
      delegate :foo_path, to: ::Rails.application.routes_url_helpers
    end
    def jasminerice?
      true
    end
    def current_user
      @current_user ||= User.find(1)
    end
  end
  
  ApplicationHelper.send :include, MyApplication
  
  class SpecController < Jasminerice::ApplicationController
    def index
      render template: 'users/home', layout: 'application'
    end
  end
  
end if defined?(Jasminerice) && Jasminerice.environments.include?(Rails.env)

There we go, a simple example pulled from my current project. What we are doing here is freedom-patching that spec controller's index action to render both a template and layout from your application. I also have a MyApplication module which I include in the Jasminerice::ApplicationHelper for a few methods that my application view code would expect. In this case a current_user method and some delegation of URL helpers to the root Rails application. Do not get hung up on what user is returned there too. It is mostly moot as all AJAX calls will be stubbed. Lastly, I made a jasminerice? view helper and a matching one that I have in my own ApplicationHelper which returns false. I will show why and how this all fits together later on.

Now that we have full control and some reflection for Jasminerice, let's reviw our appliation's main layout. Here is an example of my app/views/layouts/application.html.haml file.

!!! 5
%html{:lang => 'en'}
  %head
    %meta{:charset => 'utf-8'}
    = csrf_meta_tags
    %title My Application
    - if jasminerice?
      = stylesheet_link_tag 'spec'
      = javascript_include_tag 'spec'
    - else
      = stylesheet_link_tag 'application'
      = javascript_include_tag 'application'
      %script jQuery(function(){ MyApp.App.Home.init(); });
  %body
    %section{id: 'app', data: {id: current_user.id}}

It is really that simple! It has a single condition that says if Jasminerice is loading this page, use the top level spec CSS and JavaScript asset manifest. If not, render my main application's CSS and JavaScript manifests. You will also notice that I decouple my Spine's application initialization from the main JS files and only initialize the app on page load when not running in Jasminerce. This allows us to stub AJAX calls in specs then initialization the Spine.JS app when we are fully ready. So now, let us take a look at what both the spec/javascripts/spec.css and spec/javascripts/spec.js manifests may look like.

/*
 *= require jasmine
 *= require application
 */
.jasmine_reporter { display: none; }

#= require jasminerice
#= require mock-ajax
#= require application
#= require jasmine-myapp
#= require_tree ./lib/
#= require_tree ./models/
#= require_tree ./controllers/
#= require_tree ./views/

These should be self explanatory. The spec.css manifest requires the jasmine styles, then our application's styles. It then hides the Jasmine reporter element. The spec.js manifest does something similiar, It first requires the jasminerice manifest, a Jasmine helper called jasmine-ajax but poorly named mock-ajax, then your application's JavaScript followed by a personal Jasmine helper that we will discuss later. The last lines include all the spec files in each of the lib, models, controller and views directories located in the parent spec/javascripts directory.

Congratulations! You are now in full control of both Spine.JS and Jasmine(rice) and how your specs are executed. You have a fully styled DOM that you can happily ignore as you test your unit code. And when the time comes, you can leverage that and you full Spine.JS application from a high level integration perspective. Tune in for my last part which will give some working examples of how to test your Spine.JS application with Jasmine.

Related

• Rails & Spine.JS - Using The CoffeeScript Source
• Rails & Spine.JS - Jasmine Testing Part 1
• Rails & Spine.JS - Jasmine Testing Part 2
• Pretty Console Logging With Guard::Jasmine & BlackCoffee

Resources

• Spine.JS - Build Awesome JavaScript MVC Applications
• Jasminerice - Pain free CoffeeScript testing under Rails 3.1
• Jasmine AJAX - A library for faking Ajax responses in your Jasmine suite.

Testing JavaScript

OK, so like any good programmer, you want to test your JavaScript web application, but how? Like most, I kept finding that Jasmine was the de facto testing framework that most Rails developers were using. For the newly aquatinted, Jasmine describes itself as behavior-driven and sports a clean spec style using describe and it blocks similar to RSpec or MiniTest::Spec. But maybe you, like me, quickly dismissed Jasmine since you sure as hell were not going to hit refresh or F5 in your browser every time you wanted to run your damn specs. After all, this is 2012 and Rails developers do not test with a browser! So why should I start now?

Luckily I am a big fan of Ruby's Guard gem, a simple library that responds to file system events. The guard project literally has TONS of other guard gems that automate everything from running test files to restarting your development server. Thankfully my search for JavaScript testing with Guard in mind brought me right back to Jasmine. Enter the guard-jasmine gem and the wonderful world of a headless JavaScript testing piped right down to your terminal window!

Guard, Jasmine & Jasminerice

So this is our holy trinity and to be honest, there are a lot of moving parts under the stack. Things will seem to get complicated quick, but don't worry. I will give you a brief overview of the moving parts and then get right down to the basics of how you can start using Guard and Jasmine to test your Sine.JS application.

First, let's cover Guard. It is a simple gem that uses a Guardfile at the root of your project to control how other guards are triggered. I'll give you an example Guardfile later. But for starters, read the documentation on what special libraries may be needed for file system events or notifications on your specific platform. In my case, I us Mac OS X and purchased the latest Growl 1.3. So my example Gemfile below will have the ruby_gntp gem included in the spec.

Next up is the guard-jasmine gem. My instructions assume you are running a Rails 3.1 or 3.2 app and that you are taking full advantage of the asset pipeline and CoffeeScript. Many of these details can be found on the guard-jamine's Rails 3.1 setup section of their readme page. The underlying components of guard-jasmine are two a libs named Jasminerice and PhantomJS. Jasminerice is a simple Rails engine that brings in the Jasmine source files to the asset pipeline while running a rack app mounted to /jasmine to run your specs from your current application. PhantomJS is yet another headless WebKit based on Qt that has a rich JavaScript API which guard-jasmine delegates to. Is your head spinning? Mine was too.

Put It All Together

Here is the bullet train to getting this stack up and running. First, you will need to get PhantomJS installed. If Homebrew is your thing, just do $ brew install phantomjs. Or you can download one of their precompiled binaries for your specific platform. This is what I opted to do and I just placed the phantomjs in my PATH somewhere.

Next, we need to get the gems in our Gemfile. Here is how mine are setup. I have them in both the :develpment and :test groups since Jasminerice runs in both of those Rails environments. I also have that ruby_gntp dependency since I am using Growl on Mac OS X, YMMV.

group :development, :test do
  gem 'jasminerice'
  gem 'guard-jasmine'
  gem 'ruby_gntp'
end

So that was easy, now on to our Guardfile. Here is mine below. Notice how I put my JavaScript related guards into a js group? This is a seldom used feature of Guard and it means I can monitor only my jasmine specs by starting guard off using $ guard -g js and my other guards in my ruby group, like minitest, will be ignored.

group 'js' do

  guard 'jasmine' do
    watch(%r{app/assets/javascripts/myapp/index\.js\.coffee$})  { "spec/javascripts" }
    watch(%r{app/assets/javascripts/myapp/(.+)\.js\.coffee$})   { |m| "spec/javascripts/#{m[1]}_spec.js.coffee" }
    watch(%r{spec/javascripts/(.+)_spec\.js\.coffee$})          { |m| "spec/javascripts/#{m[1]}_spec.js.coffee" }
    watch(%r{spec/javascripts/spec\.js$})                       { "spec/javascripts" }
    watch(%r{spec/javascripts/spec_helper\.js$})                { "spec/javascripts" }
    watch(%r{spec/javascripts/jasmine-myapp.*})                 { "spec/javascripts" }
  end

end

This setup assumes a few things. First that you are only testing your Spine.JS application and that those files are in the app/assets/javascripts/myapp directory. That myapp directory could just be app in your case if you used the spine-rails gem without the --app option. In my case, that folder is named homemarks. This Guardfile also assumes that your JavaScript app and specs are CoffeeScript files and that specs are in the spec/javascripts folder specified by Jasminerice. You are going to want to follow some file naming convention now too. For example if you have a Spine.JS app file in app/assets/javascripts/myapp/models/post.js.coffee, then you are going to want the matching spec in spec/javascripts/models/post_spec.js.coffee. So saving each of those files will trigger that specific spec to run. There are also so some watchers on important root files like your spec.js sprockets manifest and your Spine.JS app index. Changing any of those files will result in your entire spec suite running again.

To Be Continued...

I will go into more details on the spec_helper.js and jasmine-myapp files above in the second part of this article. For now you should be set to start writing specs like the one below and seeing them run by either visiting the /jasmine URL of your running Rails application or by using Guard in your terminal window.

describe 'App', ->
  
  it 'sets el', ->
    expect(MyApp.Application.el).toEqual $('#app')

  it 'sets the userId as a property on itself', ->
    expect(MyApp.Application.userId).toEqual @bob.id

Continue to part two...

Related

• Rails & Spine.JS - Using The CoffeeScript Source
• Rails & Spine.JS - Jasmine Testing Part 1
• Rails & Spine.JS - Jasmine Testing Part 2
• Pretty Console Logging With Guard::Jasmine & BlackCoffee

Resources

• Spine.JS - Build Awesome JavaScript MVC Applications
• Jasmine - BDD for JavaScript. (I disagree, TDD too!)
• Guard Jasmine - Automated Jasmine tests to your console.
• Jasminerice - Pain free CoffeeScript testing under Rails 3.1
• PhantomJS - Headless WebKit with JavaScript API.

Why Spine.JS?

Spine.JS is is authored in CoffeeScript and that is a big deal for me. I will never write raw JavaScript again, which I consider, the deprecated syntax. So a JavaScript MVC framework that is written in CoffeeScript means I can read the source, learn from it and even debug it if necessary. Sure, I can read raw JavaScript or just rely on documentation. But nothing beats reading source code. A practice I think good developers follow. So here is an example of the Backbone.js model source compared to reading Spine.JS model source and I think you will see the difference.

Source code legibilty is not the only reason to use Spine.JS. It is also very lightweight and requires no other JavaScript dependencies. Take for example Backbone.js which requies the use of Underscore.js and think for a moment why. Underscore.js makes mundane tasks in JavaScript like itterators and event binding much more friendly. But this is all moot when you are using CoffeeScipt's loops and comprehensions. And take my advice, CoffeeScript has so much more to offer. One of my personal favorites is the existential operator!

Coffee Time!

So, are you with me and want to try out Spine? Great! But do not rush in and use the spine-rails gem. Sure it gives you a nice way to require the Spine JavaScript files in the asset pipeline and some fancy generators. But when you break it down, there are better ways to get Spine's source files and who the hell uses generators? I mean, the only useful one is the initial rails g spine:new generator. Past the initial project setup, the spine-rails gem really does nothing but lock you down to an explicit version of Spine tied to that gem release.

I highly advise that new-comers to Spine start off with the spine-rails gem and its new project generator. Then quickly switch to just including the spine source using a git submodule. This will give you the benefit of using the source CoffeeScript files and tracking Spine's git repo which is getting good active development. So let's live on the edge and read some source. First uninstall the spine-rails gem if you have it and add the Spine project as a git submodule to your git repo.

$ mkdir -p vendor/assets/javascripts
$ git submodule add git://github.com/maccman/spine.git vendor/assets/javascripts/spine

This adds the Spine project to your vendor/assets/javascripts/spine directory. Which means it can now be leveraged by Rails asset pipeline using Sprockets. So if you had used the spine-rails generator above and had your spine requires in app/assets/javascripts/app/index.js.coffee, you would now be able to change what should have looked like this:

#= require spine
#= require spine/manager
#= require spine/ajax
#= require spine/route

To something like the following. Since the spine/lib directory is where the source CoffeeScript files from our submodule above and Sprockets will render these just fine, it all just works!

#= require spine/lib/spine
#= require spine/lib/manager
#= require spine/lib/ajax
#= require spine/lib/route

So now you can easily update your Spine dependency using a simple git workflow with the added benefit that you can open up any of the source CoffeeScript files and learn Spine from the inside out. You can even change the source or put in console debugging to see what is happening and your application files will recompile via Sprockets on the next request.

Related

• Rails & Spine.JS - Using The CoffeeScript Source
• Rails & Spine.JS - Jasmine Testing Part 1
• Rails & Spine.JS - Jasmine Testing Part 2
• Pretty Console Logging With Guard::Jasmine & BlackCoffee

Resources

• Spine.JS - Build Awesome JavaScript MVC Applications
• CoffeeScript - A little language that compiles into JavaScript.
• The Spine Rails Gem

So the tilt gem already supported LESS templates and that means that Sprockets and the asset pipeline rendering technically did too. But there was no official less-rails gem that setup a standard configuration for other gems to hook into. This meant that libraries that distributed the Twitter Bootstrap assets were often hard to use or had inconsistent results. For example, it was not possible to load the Bootstrap's assets in such as way that let you build on top of the LESS mixins they had build. Nor were those assets namespaced in such a way that would allow you to have a modal.less asset as it would have conflicted with Bootstrap's version. So since I apparently have a bunch of free time and I hate building on top of a bad foundation, I set out to learn both Rails::Railtie and Rails::Engine to build the proper tools for LESS and Bootstrap in the Rails 3.1 asset pipeline.

New LESS Gems

I introduce you to both the new less-rails and less-rails-bootstrap gems. Take a look at the source code if you ever wanted to learn how to implement a simple Rails::Railtie or Engine. But assuming you want to use Twitter's Bootstrap, here are a few examples to get you started. First just bundle up to less-rails-bootstrap, it will automatically pull in less-rails and less.rb via their dependencies. BTW, I am going to keep the semantic versioning of the less-rails-bootstrap gem in sync with the major and minor versions of the Bootstrap project.

gem 'less-rails-bootstrap', '~> 1.3.0'

From here, the easiest way to use Bootstrap is to require it in your application.css file. Doing so will compile the complete LESS libraries files for Bootstrap. Note how we namespace the files using a simple directory structure.

/*
 *= require twitter/bootstrap
*/

#foo {
  /* Your styles... */
}

Alternatively, in a file with the .css.less extension, you can import the entire Bootstrap LESS framework. This will allow you to use Bootstrap's variables and mixins in your CSS that follows. Remember, unlike other CSS frameworks, requiring or importing Bootstrap will include all the CSS for building a bootstrapped website. If you only want variables or mixins, you will have to import those discreet files, see next section.

@import "twitter/bootstrap";

#foo {
  .border-radius(4px);
}

Maybe all you want to use are the variables and mixins that come with Twitter Bootstrap. No problem, just import them individually from you own .css.less file. In this case only the #foo selector is output.

@import "twitter/bootstrap/variables";
@import "twitter/bootstrap/mixins";

.myButton(@radius: 5px) {
  .border-radius(@radius);
}

#foo {
  .myButton(10px);
}

Using the Bootstrap JavaScript files is just as easy. Again, you can include all them with a single directive from your application.js file. Optionally, you can require only the files you need like require twitter/bootstrap/modal.

//= require twitter/bootstrap

$(document).ready(function(){
  //...
});

The less-rails project has already started getting some good feedback. Soon we hope to implement all the features that you may have used in the sass-rails project, like asset pipeline helpers. One last thing, I wanted to say thanks to Nicolas Mérouze for opening up the old less-rails gem space on rubygems.org for the new gem!

Resources

• LESS - The Dynamic Stylesheet Language
• LESS-Rails - Official Support For LESS In Rails
• LESS-Rails-Bootstrap - CSS toolkit from Twitter For Rails 3.1 Asset Pipeline
• LESS.rb - LESS CSS Rendering From Ruby
• Sass - Syntactically Awesome Stylesheets
• Sass-Rails - Official Support For Sass In Rails
• Compass - An Open-Source CSS Authoring Framework
• Bootstrap - A Toolkit From Twitter Designed To Kickstart Development

class Object
  def try_keypath(methods, *args, &block)
    methods.to_s.split('.').inject(self) { |result, method| result.try(method) }
  end
end

class NilClass
  def try_keypath(*args)
    nil
  end
end

Yup, it is that simple. Let's see how this would work. Here are a few basic classes that randomly return nested objects. So staring with the Foo object, we have the possibility to get to some deeply nested info.

class Foo
  def bar
    rand(2) == 1 ? Bar.new : nil
  end
end

class Bar
  def batz
    'wohoo'
  end
  def deep
    Deep.new
  end
end

class Deep
  def info
    {:winning => true}
  end
end

Finally, here is how it would look and return different results. Man I love Ruby!

Foo.new.try :bar # => #<Bar:0x108d7dfd0>
Foo.new.try :bar # => #<Bar:0x108d7ddf0>
Foo.new.try :bar # => nil
Foo.new.try :bar # => nil
Foo.new.try :bar # => #<Bar:0x108d7d4b8>
Foo.new.try :bar # => nil

Foo.new.try_keypath 'bar.batz' # => "wohoo"
Foo.new.try_keypath 'bar.batz' # => "wohoo"
Foo.new.try_keypath 'bar.batz' # => nil
Foo.new.try_keypath 'bar.batz' # => nil
Foo.new.try_keypath 'bar.batz' # => nil
Foo.new.try_keypath 'bar.batz' # => "wohoo"

Foo.new.try_keypath 'bar.deep.info' # => nil
Foo.new.try_keypath 'bar.deep.info' # => {:winning=>true}
Foo.new.try_keypath 'bar.deep.info' # => nil
Foo.new.try_keypath 'bar.deep.info' # => nil
Foo.new.try_keypath 'bar.deep.info' # => {:winning=>true}
Foo.new.try_keypath 'bar.deep.info' # => nil

Beer Labels

Every good starving artist needs a watering hole. Mine used to be the Tap House Grill At Ghent. Doing menu and beer tap design was a great way to pay for the basic staples of life, food and beer! Most of my friends worked there as well. Even after all these years, The Taphouse Grill still seems to be going strong in the same location. So here are a few of those beer tap designs. The "Sex Ina Canoe" tap was a joke against Yuengling Lager and referenced the joke, What does American beer and sex in canoe have in common?

Logos

On top of doing tons of 4-color brochure and package design, I used to love doing logo work. The one for the Virginia Stage Company was never used and the middle was a logo for my old online moniker before MetaSkills. The last logo was for a friend's Mother's clothing company with heavy art direction.

Drawing Collaborations

One thing I really enjoyed doing was working with illustrations by my friend Jeff Stephenson. He sketched tons of different things while making his way thru the day. I believe some of his drawings were purely cathartic or helped him cope in one way or another. Most times I would rescue them from the trash bin and scan them in for artwork. The first below is a t-shirt design for the Taphouse Grill's Cindo De Micro event. I remember piecing different illustrations together with some heavily inspired artwork I gathered while shopping for frozen burritos to eat that night. The end result was awesome. Lastly, what can I about Superfly Bundt Cackes? I think the wings came out nicely.

Experimental

Even designers have to perform occupational maintenance. I was always reading design articles (before blogs were invented) and learning the different techniques and power of PhotoShop 4 and its numerous plug-ins. Below is a mixed bag of those results.

Design Is Important

I think it is critical that every designer or programmer have a basic skill in the other field. It adds tons of value and streamlines communication across the disciplines. For me however, I have made a career decision that I will never open a PSD file again or try to facilitate the design role. I can if I have to, but not doing it all the time means that the time I do spend designing is not as efficient as someone else in that role. My place is now spent pushing pixels via code!

I've been writing rich object oriented JavaScript for the better part of 4 years now using Prototype.js. That framework has always championed encapsulating your web application's behavior using a standard class and inheritance notation. Sam Stephenson, the author of Prototype.js, did a good job trying to educate what real JavaScript Object Notation (JSON) is about and how you can encapsulate behavior using Prototype's Class structure while paying homage to Dean Edward's Base.js to which it owes its origins.

So jQuery is the proper winner and choice for anyone wanting to use a JavaScript framework to make working with the DOM in web sites easier. It has awesome event handling and delegation. So many things that Prototype.js lacked. It even has great documentation. About the only bad thing about jQuery is the widely different interfaces to it's AJAX functions and the arguments passed to their callbacks. Oh, and they totally screwed new JavaScript developers by not sheperding them into learning some sort of way to encapsulate their object behavior. So this article is for those that are not using CoffeeScript's class system, Backbone.js's class system, or jQuery's deeply nested plugin class system that is hidden away. So lets get to fixing that. Here is 32 lines of dirt simple JavaScript inheritance.

/* Simple JavaScript Class
   By John Resig. MIT Licensed. <http://ejohn.org/blog/simple-javascript-inheritance/> */
(function(){
  var initializing = false, fnTest = /xyz/.test(function(){xyz;}) ? /\b_super\b/ : /.*/;
  this.JQClass = function(){};
  JQClass.extend = function(prop) {
    var _super = this.prototype;
    initializing = true;
    var prototype = new this();
    initializing = false;
    for (var name in prop) {
      prototype[name] = typeof prop[name] == "function" && 
        typeof _super[name] == "function" && fnTest.test(prop[name]) ?
        (function(name, fn){
          return function() {
            var tmp = this._super;
            this._super = _super[name];
            var ret = fn.apply(this, arguments);        
            this._super = tmp;
            return ret;
          };
        })(name, prop[name]) :
        prop[name];
    }
    function JQClass() {
      if ( !initializing && this.init )
        this.init.apply(this, arguments);
    }
    JQClass.prototype = prototype;
    JQClass.prototype.constructor = JQClass;
    JQClass.extend = arguments.callee;
    return JQClass;
  };
})();

It is worth reading the comments John Resig's blog post for this piece of work as well as the full documentation. My code example above names this JQClass to avoid namespace collisions with other frameworks. Here is a simple example of its usage.

// Your namespace.

var MyApp = {
  models: {}
};

// Simple object example for page flash.

MyApp.models.flash = JQClass.extend({
  
  init: function(aPage) {
    this.page = $(aPage);
    this.alertDiv = this.page.find('div.flash.alert');
    this.noticeDiv = this.page.find('div.flash.notice');
  },
  
  alert:  function(content) { this._doFlashFor(this.alertDiv,content); },
  
  notice: function(content) { this._doFlashFor(this.noticeDiv,content); },
  
  clear: function() {
    # ...
  },
  
  _doFlashFor: function(flash, content) {
    $.mobile.silentScroll(0);
    this.clear();
    flash.html(content);
    flash.show();
  }
  
});

This code example is pulled from a jQuery mobile project I recently finished. The real usage of the flash objects would be numerous as there would be one per page and I have a top level delegate object that finds the active page and finds or create the flash DOM elements. But this should be a good enough example to show why you might choose a simple class and object inheritance system vs putting all your logic in $(document).ready({}) scopes. There are tons of ways to write good OO JavaScript and I hope some find this useful and explore some other ways.

A Mobile Layout

In my application, I decided to use use a route namespace of "mobile" vs a sub-domain for all controllers and views to reside in. Do what works for you, but I find that using namespaces both helps keep my code organized and simple to maintain. Either way, you should have a layout specific for your mobile application. Mine is in app/views/layout/mobile.html.haml. As you can see here, I use HAML, so all view examples will be using it vs ERB. Here is a general layout.

!!! 5
%html{:lang => 'en'}
  %head
    %meta{:charset => 'utf-8'}
    %meta{:name => 'viewport', :content => 'width=device-width, initial-scale=1'}
    %meta{:name => 'format-detection', :content => 'telephone=no'}
    %title= 'My Mobile App'
    %link{:rel => 'stylesheet', :href => 'http://code.jquery.com/mobile/1.0b2/jquery.mobile-1.0b2.min.css'}
    %script{:src => 'http://code.jquery.com/jquery-1.6.2.min.js'}
    %script{:src => 'http://code.jquery.com/mobile/1.0b2/jquery.mobile-1.0b2.min.js'}
  %body
    = yield(:layout)

A few key points here. First, the meta tag for the viewport is recommended as a good base. The other meta tag for format-detection is to disable automatic detection and linking of phone numbers. Phone number detection is way too aggressive and often just links random numbers with periods and hyphens. This means if you want a phone number to call when touched, you will have to use the tel: link format with the phone number afterward. I recommend the aid of something like the phony gem for validating and parsing phone number formats. Lastly, the title attribute in the head is really moot. The jQuery Mobile framework will dynamically change the page title as new page DOM elements are loaded in.

Mobile Page IDs

A typical jQuery Mobile app will have one full page load. All other pages thereafter are loaded via AJAX and inserted into the DOM. Their docs suggest that every page (and form) have a unique id attribute. These ids can be used to link to the DOM page element when navigating around preloaded pages. Simple apps can get by with a few ids like "#home", "#contact_us", "#etc". But if you have a large application, you need a better system to keep track of things.

Thankfully if you are building your Rails applications in a RESTful manner, it is easy to leverage the route link helpers to generate your page ids. In the example below, I created a method called mobile_page_id that I placed into a shared concerns module directory. From here I mix this into my test helper, and application's view helper. It is that damn useful! You are going to want to use this everywhere!

# File: app/concerns/mobile_concerns.rb
module MobileConcerns  
  module Helpers
    def mobile_page_id(path = request.path)
      path.sub(/\A\/mobile\//,'').gsub("/",'_')
    end
  end  
end

# Mix into your applications helper.
module ApplicationHelper
  include MobileConcerns::Helpers
end

# Mix into your test helper of choice.
class MobileStoriesTest < ActionController::IntegrationTest
  include MobileConcerns::Helpers
end

The mobile_page_id method is primarily for views. I will cover its usage in testing further down. When called without an argument, it will take the current request path and translate it to a string suitable for a page id. So if you were rendering a /mobile/users/10/avatar page, the id would be users_10_avatar. If your application follows RESTful resources in your routes, this can pay dividends. When needed, you can pass a *_path helper method to get the same id. In this example the same id would come back for mobile_page_id(mobile_user_avatar_path(@user)). Remember, I am using a "mobile" namespace in my examples and hence my method above strips that out, flavor this helper to your needs. Here is an example of what you might find in app/views/users/avatar.html.haml using the mobile_page_id. You can see here that I am also setting a title local that is used in the %h1 tag and the data-title page element attribute. Doing this will show the same title in the header bar as well as the page title.

- title = "User Profile"

%div{:id => mobile_page_id, :data => {:role => 'page', :title => title}}

  %div{:data => {:role => 'header'}}
    %h1= title
  %div{:data => {:role => 'content'}}
    edit your profile...
  %div{:data => {:role => 'footer'}}
    /...

Easy Data Attributes

The jQuery Mobile framework will have you typing a lot of data-* attributes into your elements. It uses these from basic page behavior to UI themes. They are literally needed everywhere. If your typing out raw HTML these data attributes get old pretty quick. Thankfully both HAML and the latest Rails 3.1 tag helpers can keep things clean. Both allow hashes to be passed to the data attribute. Keys are dasherized and values are JSON-encoded except for string and symbols.

# HAML Shorthand For:
# <div id="foo" data-role="page" data-title="Title" data-rel="dialog"></div>

%div{:id => 'foo', :data => {:role => 'page', :title => 'Title', :rel => 'dialog'}}

# Rails 3.1 Tag Helpers
# <div data-name="Stephen" data-city-state="[&quot;Chicago&quot;,&quot;IL&quot;]" />

tag("div", :data => {:name => 'Stephen', :city_state => %w(Chicago IL)})

Dynamically Setting Layout

Remember how jQuery Mobile only loads the entire page once and then inserts all following pages using AJAX? This means that views after the initial page load do not need the layout when rendered. Depending on the setup of your mobile application, it could become a chore telling each action to conditionally render the layout or not. Imagine a page refresh or a user bookmarking a deep resource node of your mobile app. Thankfully with a little Rails-fu, we can conditionally set the layout to false if the request is an HTTP GET from an AJAX request. Below is an example of my base mobile controller that all mobile controllers inherit from. Now every action is able to load the entire mobile layout or not.

class Mobile::BaseController < ApplicationController

  LAYOUT = 'mobile'.freeze
  layout LAYOUT
  around_filter :dynamically_assign_layout
  
  private
  
  def dynamically_assign_layout
    self.class.layout false if request.get? && request.xhr?
    yield
  ensure
    self.class.layout LAYOUT
  end
  
end

Integration Testing & Capybara-Webkit

Those that know me are familiar that I do not use RSpec or Test::Unit but instead opt for a simple testing framework built into Ruby 1.9, MiniTest::Spec. I also use the Capybara-WebKit driver for my acceptance testing in both Rails 2.3 and Rails 3.1's standard integration test layer. Reference the integration_test_helper.rb file in each link above to learn how to use Capybara-WebKit with your rails app. Thanks to Wyatt Greene for his original article on the matter.

So why the fuss? Well Capybara-WebKit is a headless WebKit browser that you can direct right from your test suite. What makes it so awesome is that it renders web pages with full JavaScript support and is much faster than selenium based Capybara drivers. Since jQuery Mobile is entirely based on JavaScript with HTML & CSS3 - Capybara-WebKit is a perfect candidate to acceptance test your mobile application. The only gotcha is scoping your Capybara actions to a certain page that is dynamically loaded into the DOM. No problem! This is easily solvable using the page ids from the mobile_page_id helper method I mentioned above. So whatever your testing framework, here are a few helpers that are critical. Assume these are mixed into your test helper.

private

include MobileConcerns::Helpers # Mentioned above.

def current_page_id(path=nil)
  path = path || current_path
  "div##{mobile_page_id(path)}.ui-page-active"
end

def current_page(path=nil)
  find(current_page_id(path))
end

def within_current_page(path=nil)
  within(current_page_id(path)) { yield }
end

So let's go over these. First is the current_page_id method. Most of the time you are going to pass a path argument to this method, since the Capybara's current_path will only work correctly on the first page load, not each following AJAX page load which would change the location hash. See how this is using the mobile_page_id helper mixed in and described above? Next is the current_page helper. It finds the passed path/id with Capybara's find method. The within_current_page leverages Capybara's within helper to scope your action to that particular DOM element. Here is a classic example using these.

should 'be able to navigate to logged in user page and change email' do
  login_as @user
  visit mobile_homepage_path
  click_on 'My Account'
  user_path = mobile_user_path(@user)
  assert current_page(user_path)
  # Change email
  new_email = Forgery(:email).address
  within_current_page(user_path) do
    fill_in 'email', :with => new_email
    click_button 'Save Changes'
  end
  @user.reload.email.must_equal new_email
end

Hopefully you can see how this simple page id foundation can help you better test your jQuery Mobile app with Capybara-WebKit. What an awesome tool! I sometimes find it hard to believe we are now at the point where we can easily test this much JavaScript in a headless browser directed by Ruby.

Resources

• jQuery Mobile
• Concerns Module Pattern
• Capybara-WebKit
• Rails 2.3 App w/Capybara-WebKit Integration
• Rails 3.1 App w/Capybara-WebKit Integration
• Wyatt Green's Using Capybara In Rails 3
• Using MiniTest::Spec With Rails

This is a simple update to my original article for using compass's .scss files with the asset pipeline. This assumes you had this setup working in Rails 3.1.0.rc4, but should be helpful to anybody. The good news is that most everything is wired up.

First, you are going to need to update your Gemfile. Follow the latest conventions and make sure you have a :assets group. Use the example below. With the exception of the compass addition to their "rails31" branch, this is what a Rails 3.1.0.rc5 project would generate. It is a good idea to put all your asset pipeline related gems in this group. As the comment says, these would not be required for production as the assumption is would precompile your static assets on deploys. Note, make sure your bundle for sass-rails installs the matching rc5 too.

# Gems used only for assets and not required
# in production environments by default.
group :assets do
  gem 'sass-rails', "~> 3.1.0.rc"
  gem 'coffee-rails', "~> 3.1.0.rc"
  gem 'uglifier'
  gem 'compass', :git => 'git://github.com/chriseppstein/compass.git', :branch => 'rails31'
end

Now here is a crazy gotcha. Rails 3.1.0.rc5 has changed the application.rb bundler line a little to account for this new :assets group. Find the bundler line and make sure it looks like this.

Bundler.require *Rails.groups(:assets) if defined?(Bundler)

Lastly, we need to get the compass files in the the load path. The sass-rails gem has set us up for this. I choose to hook into it using my config/initializers/sass.rb like so. I imagine that compass will be doing this on its own at some point in the future too. After this you should be all set!

Rails.configuration.sass.tap do |config|
  config.load_paths << "#{Gem.loaded_specs['compass'].full_gem_path}/frameworks/compass/stylesheets"
end

The first is general Open Source and what it can do for you as a software developer to increase your skills and general knowledge. Second, it covers some key open source projects I have been working on. Specifically for SQL Server and and ActiveRecord which includes projects like TinyTDS and the latest accomplishments the SQL Server adapter had done for prepared statement support in Rails 3.1.

Lastly, I go over what tools have recently been developed specifically for the Windows community to make using Ruby & Rails an easy experience. One is the great Rails Installer project by Wayne E. Sequin and Luis Lavena. Basically a one click installer for everything from Git, Ruby, Rails, MySQL, TinyTDS & the SQL Server adapter. I even did a new Rails 3.1 project called AdventureWorks.Ruby which shows you how to get up and running with your legacy SQL Server databases. Specifically the hardest point, cloning your legacy schema to a fresh test database via the standard Rails' rake tasks.

Since Rails announced both jQuery and CoffeeScript as the defaults in version 3.1, I decided it was high time I starting learning both. I had always known that jQuery bound the this keyword in event handlers to the DOM object. Something I found totally confusing and unacceptable to someone dealing with their own objects to encapsulate behavior. Today I found two ways of dealing with my problem, a jQuery way and a CoffeeScript way. First a code example.

class MyObject
  
  constructor: ->
    @myDomElement = $('#myDomElement')
    @._initBehavior

  handler: (event) ->
    console.log(this)
    false

  _initBehavior: ->
    $(window).resize @handler

jQuery ->
  window.myObject = new MyObject();

Here is a simple class using CoffeeScript's methods. It initializes itself with a static property this.myDomElement to some DOM element on the page with an id of "myDomElement". It then attaches an event handler to the window's resize event and logs this along the way. Simple stuff, the only problem will be that the object logged will not be an instance of MyObject, but the raw DOM element, in this case the window object. One way of fixing this is to use jQuery's proxy function like so

_initBehavior: ->
  $(window).resize jQuery.proxy(@handler,this)

This works, but seems a little verbose to me and can clutter up your event initialization code. The other way is to use CoffeeScript's fat arrow operator. An excerpt from their project page explains it well.

The fat arrow => can be used to both define a function, and to bind it to the current value of this, right on the spot. This is helpful when using callback-based libraries like Prototype or jQuery, for creating iterator functions to pass to each, or event-handler functions to use with bind. Functions created with the fat arrow are able to access properties of the this where they're defined.

So all we have to do is change -> to => for any of our callbacks or event handlers and now this is our own object and not the DOM element. Hot damn!

class MyObject
  
  constructor: ->
    @myDomElement = $('#myDomElement')
    @._initBehavior

  handler: (event) =>
    console.log(this)
    false

  _initBehavior: ->
    $(window).resize @handler

jQuery ->
  window.myObject = new MyObject();

The topic is one I have thought often about over the past 6 years. I started writing Rails applications before 1.0 was released and I have seen the changes and felt each one. Having written both web and native iOS apps for HomeMarks.com and retooling the whole application for each major Rails version, I think it gives me a good insight into the pain here. For instance when RJS in Rails first came out, HomeMarks took extreme advantage of it in very clever ways. Pushing rendered partials out and communicating to the browser's JavaScript environment was fun and rewarding at the time. It also felt really DRY at times.

As I started to learn more advanced JavaScript techniques for organizing my rich client code, I ended up rewriting HomeMarks again under the poorly named moniker "The AJAX Head Design Pattern". It even caught a little bit of attention by the Ajaxian and Chris Williams. Essentially what I ended up building was my own minimal backbone.js in that I had a rich MVC layer all written in JavaScript. This usage of Rails as an API foundation on top of a rich JavaScript application was in my opinion a few years ahead of the average curve. Though it was very rewarding from a JavaScript as a language first, DOM second development perspective & it yielded a very clean way to leverage the same RESTful controller actions used by JavaScript in the browser with a native iOS app that integrated with Core Data, it still felt like an over achievement or harder than it had to be.

So as I embark on my third complete rewrite of HomeMarks, I have to think about my tools and techniques again and what the end goal may look like. I have thrown away thousands of lines of OO-JavaScript written in Prototype.js and started rewriting them in CoffeeScript. Though there are still some tough decisions to be made on what my complete stack will look like and how HomeMarks v3 will hopefully again push the new web forward, I cant help but to agree with both Dave and DHH. I also share James A Rosen's opinion summed up in this tweet.

If I had known that RailsConf would be How-to-Use-Rails-as-a-Backend-for-Javascript-Conf, I would've gone!

The Sprockets 2 gem along with the Tilt gem make it really easy to write JavaScript or CSS using any templating language you desire. The rails defaults are CoffeeScript and Sass. About the best collection of Sass framework files for easy cross-browser CSS authoring are packaged in the compass framework. Compass even has great documentation for using their Sass framework. But what if you want to use those within the asset pipeline provided by Rails? Easy enough!

First, bundle up the compass, but do not require it. Add this to your Gemfile.

gem 'compass', :require => false

Next, add a Sass initializer in config/initializers/sass.rb and fill it in with the code below. This will add two more load paths to the Sass engine. The first is your default rails/sprockets asset path for stylesheets. It simply let's you build a deep folder structure in that directory and use relative paths from each file. The second will put the entire compass Sass framework files into the Sass load path.

Sass::Engine::DEFAULT_OPTIONS[:load_paths].tap do |load_paths|
  load_paths << "#{Rails.root}/app/assets/stylesheets"
  load_paths << "#{Gem.loaded_specs['compass'].full_gem_path}/frameworks/compass/stylesheets"
end

Now in your rails app/assets/stylesheets/foo.scss file you can use Sass' @import with paths to the compass framework.

@import "compass/css3/opacity";
#mylogo { @include opacity(0.5); }

That is an example loading up the opacity helpers. Your generated css file will look like this! CSS is never going to be the same again!

#mylogo {
  -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";
  filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50);
  opacity: 0.5; }

To go one step further in helping Ruby, I have decided to speak at a local conference called the Mid Atlantic Developer Expo or just MADExpo. The details for my talk are below and if you find any of the other talks interesting, I highly advise you to grab a ticket and help me bring the message of Ruby right to the belly of the beast!

Free The Enterprise With Ruby & Master Your Own Domain

On the heals of Luis Lavena's RailsConf talk "Infiltrating Ruby Onto The Enterprise Death Star Using Guerilla Tactics" comes a local and frank talk about the current state of Open Source Software (OSS) participation from Windows developers. Learn what OSS is, what motivates its contributors, and how OSS can make you a stronger developer. Be prepared to fall in love with writing software again!

We will start off with a 101 introduction to both the Ruby programming language and the Ruby on Rails web application framework. You will learn about ActiveRecord, a powerful ORM that maps rich objects to your databases, and the latest components to use it with SQL Server. As a Rails core contributor and author of the SQL Server stack, I will give you a modern insight into both that will allow you to leverage your legacy data with Ruby.

Lastly, I will review the bleeding edge tools being actively created for Windows developers to ease the transition to Ruby, Rails and OSS from a POSIX driven world. Many things have changed. It is time to learn and perform some occupational maintenance.