Ruby Heroes was created to show some gratitude and give recognition to the people in the Ruby/Rails world who contribute to the community and rarely receive any recognition or repayment. Thanks for continuing to make our community stronger.

The Making of the Anatomy of Backbone.js

Here’s the run down on what’s happened at Code School in the past few months.

• jQuery Air: Captains Log was released, the sequel to jQuery Air: First Flight (which is now free)
• We took a A Sip of CoffeeScript, teaching this new language which compiles into JavaScript.
• Then there was CSS Cross-Country, teaching CSS best practices.
• Last month we had more Zombies with Rails Testing for Zombies, teaching the basics of testing Rails.
• Today we released the Anatomy of Backbone.js, teaching the client-side MVC framework.
• Along the way we’ve released a TON of CodeTV screencasts on topics from beginning Rails to Shell Productivity.

Feel free to take a look around the Code School site if you haven’t in a while.  You’ll find many of our newer courses allow you to play the first level free.  Also if you want to keep updated we’ve been blogging more on the Code School Blog these days.  You can also follow code school on twitter.

• Already knows his/her way around Rails.  We’re going to want to see that you’ve built a Rails app or two.  You don’t need to have written any tests, but you do need to know the basics.
• Can come work with us at Envy Labs in Orlando at least 2 days a week (if not more).  In other words,we can be flexible if you’re currently a student.
• Is a good writer and communicator.
• has their own laptop.
• Knows their way around HTML/CSS/Databases.
• Has a passion for creating web apps.

Just yesterday Code School released Rails for Zombies 2, the sequel to the first Intro to Rails Zombie course.  This new course picks up right where the last one left off with 5 more vidoes, and 52 more coding challenges.  Topics include:

• Rails command line and database migrations
• More ActiveRecord relationships and named scopes
• Undertstanding REST, nested resources, forms, and partials.
• The Rails 3.1 Asset Pipeline
• Sending Email from our Rails app
• Custom routes and dynamic pages with AJAX

By the end of the course you’ll be much better prepared to create your own Rails applications.  Here’s the intro video to learn more:

With Zombies 2 we also released our Code School Open Enrollment program, which allows you to get access to all our course for one low monthly price.  Head over to Code School Enrollment to learn more about that.

There are many times when just modifying the Rails gem version in your Gemfile and then running bundle update seems to work: your tests still pass, application runs like normal, etc. So, you never think twice and go about continuing to develop your application. But, were there other changes that could/should have been made as well? Perhaps Rails has changed the default value for some configuration setting; perhaps release candidates did not deal with assets in the same way the final release did. If you are using prerelease versions, more things tend to change as newer versions come out.

What the Rails application generator creates is specific to the version of Rails it was generated for. So, as new versions are released, what the application generator creates changes; and, comparing the output of different versions can give you some understanding of the changes going on in Rails.

So, to that end, I generated applications for the following versions: 3.1.1, 3.1.1.rc3, 3.1.1.rc2, 3.1.1.rc1, 3.1.0, 3.1.0.rc8, 3.1.0.rc6, 3.1.0.rc5, 3.1.0.rc4, 3.1.0.rc3, 3.1.0.rc2, 3.1.0.rc1, 3.1.0.beta1 (3.1.0.rc7 has been yanked from RubyGems); then compared all of them to version 3.1.1. I’ve made a gist for each of the comparisons:

• Differences between Rails 3.1.0.beta1 & Rails 3.1.1
• Differences between Rails 3.1.0.rc1 & Rails 3.1.1
• Differences between Rails 3.1.0.rc2 & Rails 3.1.1
• Differences between Rails 3.1.0.rc3 & Rails 3.1.1
• Differences between Rails 3.1.0.rc4 & Rails 3.1.1
• Differences between Rails 3.1.0.rc5 & Rails 3.1.1
• Differences between Rails 3.1.0.rc6 & Rails 3.1.1
• Differences between Rails 3.1.0.rc8 & Rails 3.1.1
• Differences between Rails 3.1.0 & Rails 3.1.1
• Differences between Rails 3.1.1.rc1 & Rails 3.1.1
• Differences between Rails 3.1.1.rc2 & Rails 3.1.1
• There is no difference between 3.1.1.rc3 & 3.1.1

Hopefully, this will come in handy for anyone else — like me — that needs to update some applications that were generated with a Rails version prior to 3.1.1. And, as you can see, depending on what version you used to generate your application, the changes needed will vary.

Here at Envy Labs we’ve been inspired by _why’s work and you can see his influence with Rails for Zombies, where we teach people Rails by coding in the browser.  Rails for Zombies was such a huge success it led us to build Code School, where we build paid coding courses.

We’ve learned a great deal about how to do in-browser coding as we’ve built Code School, and a few months ago Eric Allam started to wonder if we should take our knowledge and contribute back to TryRuby.  After a call to Andrew McElroy who graciously maintained the project with David Miani (after _why disappeared), Eric dove in.

Flash forward two months later and today we’re happy to announce the release of TryRuby version 3!

This new version contains a bunch of new things we’re excited about:

1. New “Code School” Engine – Eric Allam worked many weekends to integrate Code School’s (Rails & Backbone.js) course engine and our code editor into the Try Ruby course.  With this integration you now have the ability to save your progress using your Code School account, so you can come back later and pickup where you left off.  Don’t worry, it’s completely optional.. you can still play through TryRuby without ever having a Code School account.
2. New Design – We enrolled Envy Labs designer Nick Walsh to do a new design as our own tribute to “_why”.  We’re really happy with the redesign which is not only more beautiful, but also has a better user experience (and it’s responsive!).
3. New Sandboxing – The big issue with running user written Ruby code server-side is it could be EVIL!  Yes, whatever you type in that Ruby console, we will run it on our precious little web server.. sounds dangerous right?  With the help of Dray Lacy, Eric has created a library we’ll be releasing shortly called RubyCop.  He’ll be doing a talk on Sandboxing this Saturday at Rubyconf if you happen to be here.
4. New Host – We are hosting TryRuby up on Heroku, which (in our minds) makes things even more secure.  Most of Code School is up on Heroku anyways, so it seemed like a great fit.

So… even if you’ve done it before or you’ve never programmed before in your life.. it may be time to dust off those chops and head over to TryRuby.org.  If you do choose to login to Code School as you’re doing the course, we’ll even give you a badge for completing the course.

If you really dig these in-browser coding courses I highly recommend you signup for the Code School Newsletter.  We have some additional free courses in the works (on top of the paid ones):

Warning – For those sensitive readers, the voicemail and remix does contain the N word, some racial humor, and a swear word or two, so you might not consider it safe for work (or children).

The Original Voicemail

Download – Original “We Ain’t Got No RSpec” Voicemail Mp3

The “We Ain’t Got No RSpec” Remix

Download – We Ain’t Got No RSpec MP3

Where are they now?

As you probably know the Rails Envy blog has been taken down since I initially posted this, and these days I’m doing the Ruby5 podcast. RSpec is still what many of us still use to test our Rails Applications, and last I heard R. Elliot Mason has made it out of the hood and quickly ran out of things to rap about.

On the plate?

What’s next? Well Eric Allam has been working hard something we’ll be releasing next week (at Rubyconf) which has a LOT to do with Cartoon Foxes. No, not rapping ghetto cartoon foxes (although I’d like to see that). Anyways, you may want to subscribe to our RSS or follow Code School on twitter to be notified about it.

Last week I wrote a post about using the Asset Pipeline outside of Rails because we needed to test answers for Code School’s upcoming Zombies 2 course. But we also need a way to test javascript (that uses jQuery) that manipulates a DOM, and all from inside of Ruby.

ExecJS to the rescue

ExecJS is a ruby gem that lets you run JavaScript code from Ruby. It does this by using the best javascript runtime available to evaluate Javascript and returning the result in Ruby! For example:

ExecJS.eval "'red yellow blue'.split(' ')"
# => ["red", "yellow", "blue"]

Rad! Or you can use it to compile a block of javascript and then call it later, like this:

context = ExecJS.compile "var run = function(foo) { return foo + foo }"
context.call 'run', 'bar'
# => 'barbar'

The Asset Pipeline uses ExecJS for it’s CoffeeScript compilation and Javascript minification. But we still needed to somehow programmatically setup a DOM, load the jQuery javascript library, and inject our student’s javascript.
Luckily, we’d already solved this problem for our jQuery Air and HTML5 & CSS3 Functional Design courses, using the JSDOM Javascript library. JSDOM makes it super easy to create a DOM and require external javascript libraries (like jQuery). You can supply your own HTML and then manipulate it in Javascript using the jsdom.env, method, like this:

html = '<h1>JSDOMs Homepage</h1>'
jquery = 'http://code.jquery.com/jquery-1.5.min.js'

jsdom.env(html, [jquery], function(errors, window) {
console.log("contents of a.the-link:", window.$("h1").text());
// logs: JSDOMs Homepage
});

So we went to work hooking all these pieces up together, but we hit a snag early on. We wanted to setup JSDOM with some fixture HTML data, require jQuery, then run the student’s Javascript and finally return the modified DOM, like this:

jsdom.env(html, [jquery], function(errors, window) {
var jQuery = window.jQuery;
var $ = jQuery;
var document = window.document;
eval(students_code);
return $('body').html();
});

But jsdom.env works asynchronously, returning before the function callback is run. And ExecJS does not work with asynchronous javascript:

context = ExecJS.compile <<-JAVASCRIPT
var run = function(html, code){
jsdom.env(html, [jquery], function(errors, window) {
var jQuery = window.jQuery;
var $ = jQuery;
var document = window.document;
eval(students_code);
return window.jQuery('body').html();
});
}
JAVASCRIPT

html = "<h1>Foo</h1>"
student_code = "$('h1').text('Bar')"
context.call 'run', html, student_code
# => ""

Digging into the ExecJS code (and then talking to the maintainers) it was clear that ExecJS would only ever work with synchronous javascript code because ExecJS’s goal is to provide a common interface against a number of different javascript runtimes, and the runtimes all have different ways (or none at all) of doing async callbacks. But since we’d always be running the Node.js runtime (since we use Heroku), we wrote a gem that adds async support to ExecJS for the Node runtime only, called execjs-async. Now this works:

context = ExecJS.compile_async <<-JAVASCRIPT
var run = function(html, code){
jsdom.env(html, [jquery], function(errors, window) {
var jQuery = window.jQuery;
var $ = jQuery;
var document = window.document;
eval(students_code);
callback(window.jQuery('body').html());
});
}
JAVASCRIPT

html = "<h1>Foo</h1>"
student_code = "$('h1').text('Bar')"
context.call 'run', html, student_code
# => "<h1>Bar</h1>"

Notice instead of returning, we are calling a function named callback and whatever we pass to that will be the result of calling context.call. ExecJS-Async provides this callback function to any javascript code compiled with ExecJS.compile_async.

This is a stripped down version of the code we are using for Zombies 2, but it’s pretty close. Zombies 2 is almost ready to go, you can signup here to be notified when it becomes available.

And so we wanted to teach people a little bit of CoffeeScript/SASS in Rails for Zombies 2. But that means we have to have a way to test CoffeeScript/SASS. We accomplished this by extracting the bits in Rails 3.1 that implement the pipeline and used them to serve and compile CoffeeScript into Javascript and SASS into CSS.

Serving CoffeeScript or SASS using a custom Sprockets Environment

The Asset Pipeline is powered by the sprockets gem by Sam Stephenson. It hooks into the Rails stack by inserting a Rack App at the very top of your routes collection. When a request for an asset hits your app it will be ‘routed’ to the sprockets environment. The relevant setup code in Rails is located here.

Creating a custom Sprockets Environment

First you need to require sprockets and supporting gems, just add this to your Gemfile:

<br /><br /><br />
gem 'sprockets', :git =>'git://github.com/sstephenson/sprockets.git'<br /><br /><br />
gem 'coffee-script'<br /><br /><br />
gem 'sass'<br /><br /><br />

After running bundle install, we can create a new Sprockets::Environment, setting the path to the root of your project and a logger:

<br /><br /><br />
require 'bundler/setup'<br /><br /><br />
Bundler.require # this will require all the gems in your Gemfile</p><br /><br />
<p>  assets = Sprockets::Environment.new(project_root) do |env|<br /><br /><br />
env.logger = Logger.new(STDOUT)<br /><br /><br />
end<br /><br /><br />

Next we need to tell the environment about the paths it should use to lookup assets from the filesystem. The simplest configuration would just be a single path to all your assets:

<br /><br /><br />
assets.append_path('/Full/Path/To/assets')<br /><br /><br />

We need a way to call the sprockets rack app we just created. One easy way is to use rack/test.

<br /><br /><br />
# in Gemfile<br /><br /><br />
gem 'rack-test'</p><br /><br />
<p>  # in project<br /><br /><br />
session = Rack::Test::Session.new(Rack::MockSession.new(assets))<br /><br /><br />
session.get('application.js')<br /><br /><br />
# Served asset /application.js - 404 Not Found<br /><br /><br />

As you can see sprockets returned a 404 Not Found, because we haven’t actually created our file yet.

To fix this, create a application.js.coffee file in your assets directory, something like this:

<br /><br /><br />
$(document).ready -><br /><br /><br />
$('#foo').html("<p>bar</p>")<br /><br /><br />

And use session to request it again:

<br /><br /><br />
session.get('application.js')<br /><br /><br />
session.last_response.body<br /><br /><br />

That should return this beautifully transpiled javascript:

<br /><br /><br />
(function() {<br /><br /><br />
$(document).ready(function() {<br /><br /><br />
return $('#foo').html("<p>bar</p>");<br /><br /><br />
});<br /><br /><br />
}).call(this);<br /><br /><br />

It get’s cooler! You can stick a .erb on the end of the application.js.coffee and sprockets will run it through ERB before converting it to javascript. Try this:

<br /><br /><br />
# in application.js.coffee.erb<br /><br /><br />
$(document).ready -><br /><br /><br />
$('img').attr('src', "<%= asset_path('lolwut.png') %>")<br /><br /><br />

And request it again:

<br /><br /><br />
session.get('application.js')<br /><br /><br />
# NoMethodError: undefined method `asset_path'<br /><br /><br />

Unfortunately that asset_path method isn’t defined like it is in Rails. But we can easily define our own helpers that can be used in our assets served with erb preprocessing, like this:

<br /><br /><br />
module AssetHelpers<br /><br /><br />
def asset_path(name)<br /><br /><br />
"/assets/#{name}"<br /><br /><br />
end<br /><br /><br />
end</p><br /><br />
<p>  assets.context_class.instance_eval do<br /><br /><br />
include AssetHelpers<br /><br /><br />
end<br /><br /><br />

Now if you try the request again, you should get this result:

<br /><br /><br />
(function() {<br /><br /><br />
$(document).ready(function() {<br /><br /><br />
return $('img').attr('src', "/assets/lolwut.png");<br /><br /><br />
});<br /><br /><br />
}).call(this);<br /><br /><br />

We actually don’t have to change anything to serve SASS. Add a application.css.scss file to your assets directory and request it like before:

<br /><br /><br />
# application.css.scss<br /><br /><br />
h2 {<br /><br /><br />
font-size: 10em;<br /><br /><br />
a {<br /><br /><br />
height: 64px;<br /><br /><br />
width: 50px;<br /><br /><br />
display: block;<br /><br /><br />
}<br /><br /><br />
}<br /><br /><br />

<br /><br /><br />
session.get('application.css')<br /><br /><br />
session.last_response.body<br /><br /><br />
# h2 {<br /><br /><br />
#   font-size: 10em; }<br /><br /><br />
#   h2 a {<br /><br /><br />
#     height: 64px;<br /><br /><br />
#     width: 50px;<br /><br /><br />
#     display: block; }<br /><br /><br />

Sinatra

You can use this as a quick way to add the asset pipeline to Sinatra.
Add gem 'sinatra' to your Gemfile and then add this sinatra route:

<br /><br /><br />
get '/assets/*' do<br /><br /><br />
new_env = env.clone<br /><br /><br />
new_env["PATH_INFO"].gsub!("/assets", "")<br /><br /><br />
assets.call(new_env)<br /><br /><br />
end<br /><br /><br />

This will invoke the asset pipeline for all GET requests under /assets, so http://localhost/assets/application.css will serve the application.css.scss asset. (We had to modify the PATH_INFO otherwise sprockets would look for assets under /assets/assets/, which isn’t what we want.)

That’s it! For all the code in this blog post check out this gist.

In a future blog post, I’m going to show how to run that compiled javascript against a DOM using execjs-async and jsdom, all from the comfort of Ruby.

UPDATE: Sprockets 2.0.0 was just released and it’s got some great new documentation in the README, make sure to check it out!