• 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!

To learn more about what is important to us, check out our Core Values. If you think having a set of Core Values is cheesy, please don’t apply. If you think you might be a good fit for our team, email me with some stuff you’ve done. You get a bonus for open source, videos of your presentations, and anything else you can send over (aside from a resume).

In the video I said that we organize the “weekly barcamp”, yes I meant “yearly”.. thank god.

Here’s a brief rundown on how we designed and built 3 For 5:

Theme

One of the key brand elements of Code School is that each course we produce has a unique theme. For our HTML5 / CSS3 course, we wanted to take a functional approach — meaning we wanted the course to be extremely practical and provide real-world tips and tricks that our users could take and begin implementing immediately. I’m somewhat of an architecture nut, and the balance between form and function (something just as important in architecture as in web design) seemed to fit as a theme.

I was able to track down a collection of vintage Photochrom prints in the public domain as well as several old photographs of well-known buildings. These formed the foundation of the theme particularly for the course slides.

We carried more of the “building” theme through the course UI, and if you know me you are aware that I’m a bit of a craft-beer snob, so of course I had to include this in the course. We decided to incorporate this particular theme into the “Border & Radius Brewhouse” website which serves as the demo site we use to teach a lot of the concepts in the course (and you also get to download all of the source code once you’ve completed 3 For 5).

UI

We made some key structural changes to our UI for the jQuery Air course, and we decided to carry these through to 3 for 5. Because you literally “learn by doing”, it was important for us to make sure that each challenge objective was clear and easy to find. Additionally, the code editor has to be prominent because this is, after all, where all the magic happens. We have a lot of other “stuff” that exists in the UI, and we spent a lot of time discussing what was the most important and where all of those elements needed to live — such things like points, navigation, level selection, resources, etc.

Because in 3 For 5 you are working in both HTML and CSS, we had to include a variety of different code and resource elements — things like base code, images, fonts, etc —  and we decided to include these as a second panel next to the code editor. What we found during testing though was that in smaller browser sizes things got pretty cramped and it just wasn’t an optimal user experience.

To combat this, our lead front-end developer Nick Walsh came up with a pretty slick solution to  ”responsive-ize” the tabbed area a bit, which you can see below (click on the image to view larger):

The goal was to avoid using JS listeners/events to handle splitting the panels and tabs, and using two active states solved that problem. Because the class changing is handled in the combined and split states, the user’s latest selected tab conveniently will carry over if their browser is resized. There’s also some consideration for JS-less environments in this version.

The result is a fairly fluid UI that is optimized for multiple browser sizes and user environments. The design is built on the architecture theme we mentioned before and utilizes a number of CSS3 properties that we cover in the course. We should also note two pretty cool features — the first is the protractor that shows how many points you can receive for each challenge. If you use a hint, the protractor animates to a lower point value. The second feature is the total points section in the right sidebar — Nick was able to create some custom javascript to allow the numbers to “drop” in which really enhances the overall look and feel of the UI.

Live Updating

One of our favorite features of the course design is the live updating functionality built by Eric Allam, the lead developer on this course. We had this in jQuery Air as well, but because we deal with so much design in 3 For 5, this functionality really shines. You can see in the screencast below how this works — you type your code into the code editor to the left and you can see what happens in real time in the panel to the right. Not only does this allow you to confirm the right answer to the challenge, but it encourages you to play around with different values and properties…it’s like your own little CSS playground.

A lot of thought goes into the design for each Code School course, but we have a lot of fun doing it. With each course we try to build on the positives of previous courses and learn from things we could have done better. Design is about balancing form and function and about crafting an optimal user experience — we’ll never get it perfect but we’re pretty pleased with what we’ve accomplished in 3 For 5.

Thanks for reading.

We are stoked to be able to offer some great prizes when you finish the course.  The first prize gives you half off your first month of Think Vitamin Membership, which contains an incredible library of educational videos covering topics from Django to Rails, jQuery to IOS Development, and most importantly some great HTML5 & CSS3 tutorials.

We’re also excited to offer a discount of 20% on books from A Book Apart which offers key design books such as CSS3 for Web Designers and HTML5 for Web Designers.

Aside from the new prizes, this course comes with two new items we’ve never offered in any code school course:

• Three cheat sheets which contain all of the HTML5 and CSS3 covered in the course.
• A demo website you download after the course which serves as a killer example of what is possible with effective design and HTML5 & CSS3.

I believe the combination of the topic, prizes, cheat sheets, and demo website make this the most valuable course we’ve made at Code School.  It also makes the price of $45 a steal.