I’ve had m bound to TextMate for years. I also have it set to my $EDITOR variable, so it is launched by git commands, etc.

To change the default to RedCar, and to allow me to toggle between RedCar and TextMate, AND to allow me to use Edge RedCar (from source instead from a RubyGem).

This file comes from my editor.sh file which is loaded into all shell terminals.

I can change to TextMate with:

use_textmate

Back to RedCar (via gem) or RedCar (from source):

use_redcar_gem
use_redcar_dev

Related posts:

1. Packaging TextMate bundles in OS X DMGs Last week Engine Yard released a CLI for their Engine...
2. Validate and Save your Ruby in TextMate – with secret Rubinus superpowers In some TextMate bundles, if you save a file it...

ey deploy
ey rebuild
ey logs
ey ssh

They simultaneously released a TextMate bundle to deploy, rebuild, view logs, etc using Ctrl+Alt+Cmd+E. Like all TextMate bundles, you can install it in one of two ways: via git (see the README), or via a beautiful DMG. Download it here!

Yes indeed, TextMate bundles can now be packaged up and distributed via DMGs using ChocTop!

For example, the Ruby on Rails.tmbundle using a simple purple theme.

First, the Engine Yard tmbundle

To use the Engine Yard tmbundle, you first need to install and use the CLI once. Instructions at the bottom of the information page.

How to package a TextMate bundle into a DMG

ChocTop is a packaging and distribution tool originally designed only for Cocoa applications, but can now package any assets, URL links, or even the whole project folder itself. This makes it ideal for packaging TextMate bundles which have no compiled/built output to distribute (like a Cocoa application), rather the project folder itself is the distributed item (the Engine Yard.tmbundle folder in this case).

Getting started

Everything is added into your TextMate bundle project. For example, with the EngineYard bundle:

gem install choctop
cd Library/Application\ Support/TextMate/Bundles/Engine\ Yard.tmbundle
install_choctop . --tmbundle

If your tmbundle already has a Rakefile, then don’t overwrite it. Instead, inside the Rakefile, add the ChocTop configuration:

require "choctop"

ChocTop::Configuration.new do |s|
  s.add_root :position => [290, 200], :exclude => %w[appcast build .bundle .git]
  s.add_link 'http://github.com/engineyard/engineyard.tmbundle', 'GitHub', :position => [520, 200]
  s.defaults :textmate
end

For TextMate bundles the DMG magic is from the s.add_root line. The resulting DMG will include the entire project as a folder/bundle. For example, you’ll want to exclude appcast, build, .bundle (if you’re using Bundler), and .git folders.

The s.defaults :textmate provides a generic background and volume icon for a TextMate bundle DMG. See below for customising the background and volume icons. The :position coordinates above are for the generic background.

Building your DMG

To build your DMG and then view it in Finder:

rake dmg
open appcast/build/*.dmg
# or together
rake dmg[automount]

You can now share the DMG file. See below for how to upload it to a server.

Versioning

In future, it would be great to use Sparkle’s auto-update mechanism (as seen in nearly every Cocoa application). ChocTop will automatically generate the required XML feed; TextMate nor the bundle has a way to ask Sparkle to poll for it nor update itself, yet.

But, you can start versioning your DMGs today:

$ rake version:current
0.0.0
$ rake version:bump:major
$ rake version:current
1.0.0
$ rake dmg

The DMG will now have a version number.

Uploading new DMG versions

The original ChocTop was designed for Cocoa applications and included Sparkle support so your Cocoa applications automatically updated themselves when you built and uploaded a new version. I haven’t got a solution for this for TextMate bundles yet; but it seems like a good idea for the future.

Nonetheless, ChocTop still includes a rake upload task to ship new versions of your DMG to a server somewhere.

In your Rakefile, add the following config lines to the ChocTop block:

s.base_url   = 'http://some.host.com/upload/folder'
s.remote_dir = '/path/to/upload/folder'
s.host       = 'some.host.com'
s.user       = 'remote-user'

The s.base_url is the URL from where the DMG file will be found by users. Later, when I figure out how to do auto-updating of the TextMate bundles, it will also use this URL. This URL is also used to determine the host for uploading the file.

The s.remote_dir is a path on the target server that maps to the base_url. This folder must already exist; rsync cannot create it as far as I can tell. So ssh into the machine and mkdir -p /path/to/upload/folder

The latter two are optional: s.host is derived from s.base_url and s.user defaults to your current local user.

To upload the latest DMG, run:

rake upload

You can now share the URL http://some.host.com/upload/folder for people to download the DMG. A small PHP script redirects from the folder path to the DMG filename.

Customising

ChocTop allows you to customise nearly everything.

The s.defaults :textmate line is similar to the following configuration:

s.background_file = "...choctop/assets/textmate_background.jpg"
s.volume_icon     = "...choctop/assets/textmate_volume.icns"
s.icon_size       = 104
s.icon_text_size  = 12

For TextMate bundles, perhaps put customised assets into a Support/dmg folder.

A background image should include blank space for the large YourBundle.tmbundle icon and webloc URL file to your GitHub project (or other target URLs). There are no size constraints on the background image. Design something beautiful.

The volume icon is an icns file. You create this using OS X’s Icon Composer application. Start with a transparent png file and drop it into the box with the corresponding size.

For the Engine Yard tmbundle, the following configuration is used:

s.background_file = 'Support/dmg/engineyard.tmbundle.dmg.png'
s.volume_icon     = 'Support/dmg/engineyard.dmg.icns'

Additional files

If there are other files you explicitly want bundled in the DMG, say a pretty README.html or a folder of documentation, then you can specify them:

s.add_file 'README.html', :position => [50, 100]
s.add_file 'docs', :position => [100, 100], :name => 'Documentation'

Summary

ChocTop is pretty cool for bundling any set of files into a custom DMG, especially Cocoa applications and now TextMate bundles.

Hopefully one day we can have Sparkle auto-updates for TextMate bundles too.

Related posts:

1. Trialing RedCar instead of TextMate – replacing my aliases I’m interested to trial RedCar in my life, instead of...
2. Validate and Save your Ruby in TextMate – with secret Rubinus superpowers In some TextMate bundles, if you save a file it...
3. TextMate easter egg: find bundle commands by key combo I’ve dreamed of the ability to ask TextMate “what frigging...

So I added the same thing to my Ruby.tmbundle. Install this, save a dodgy Ruby file and you’ll now see something like:

Rubinius superpowers

Do you think the following syntax error tooltip is more useful?

Yes it lovely, and the new Ruby.tmbundle will automatically do this if it can find rbx in your TextMate’s $PATH. Yeah yeah.

If you have Homebrew installed:

brew install rubinius

Then in TextMate, add your homebrew bin folder to the $PATH.

• Go to TextMate’s Preferences (Cmd+,)
• Go to “Advanced”, then “Shell Variables”
• Edit the PATH variable, and add “:/path/to/homebrew/bin”

For example, if you have homebrew installed in ~/.homebrew then you might add :/Users/drnic/.homebrew/bin

. My complete $PATH in TextMate is:

/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/usr/local/bin/:/Users/drnic/.homebrew/bin

Save a dodgy Ruby file and see the beautifully helpful syntax message.

Install Ruby.tmbundle

To install via Git:

mkdir -p ~/Library/Application\ Support/TextMate/Bundles
cd ~/Library/Application\ Support/TextMate/Bundles
git clone git://github.com/drnic/ruby-tmbundle.git "Ruby.tmbundle"
osascript -e 'tell app "TextMate" to reload bundles'

Related posts:

1. Trialing RedCar instead of TextMate – replacing my aliases I’m interested to trial RedCar in my life, instead of...
2. Packaging TextMate bundles in OS X DMGs Last week Engine Yard released a CLI for their Engine...
3. Future proofing your Ruby code. Ruby 1.9.1 is coming. Bugger. I’m a Ruby monogamist. I use the Ruby...

If you are giving an “Introduction to CoffeeScript” talk at your local developer group in the future, I have a 2:30min video you might find exciting to show. CoffeeScript is so cool that I thought it really needed to be put to music. Hard rock music. AC/DC.

I finished my session at NordicRuby with this video and I think it helped get lots of people excited about CoffeeScript.

Because of it’s heavy dependence of the backing song – the screencast is boring without it – I’m kind of screwed as to how to distribute it to other presenters. The licensing rules of including music and it’s 600Mb size are prohibitive.

What the hell. I’ve included an inline sample above; and the links to the 600Mb version is below. All self-promotional “Dr Nic made this shiny video” bits have been removed. Go for gold. Share the CoffeeScript excitement.

NordicRuby

NordicRuby finished 5 days ago, but many of the attendees and speakers are only finally winding down. Executed with the style, excitement and pizazz of Unspace’s RubyFringe and FutureRuby conferences, I had a brilliant time in Gothenburg. If NordicRuby’s organiser’s Elabs host the event again in 2011 I highly recommend attending. Carefully selected and sequenced speakers from around the world, 30 minute talks with 30 minute breaks over two days, an hour of lightning talks each day, and parties every night. Phew.

To CJ and Lilly, the organisers, the other speakers and all the attendees, thanks for an awesome experience in Sweden. Looking forward to coming back next year.

Why CoffeeScript?

JavaScript has a wonderful feature or two: it’s everywhere and it’s getting really fast. Unfortunately, its syntax was heavily influenced by Java/C++ and other popular goliaths of the time. But the JavaScript runtime is sweet. JavaScript syntax, not so sweet.

Like .NET and it’s selection of languages, the JVM and it’s growing smorgasbord of languages, I think the JavaScript runtime could benefit from more experimentation with alternate languages and/or syntaxes. Objective-J was one attempt. CoffeeScript is another.

Of the two, I like CoffeeScript. A lot.

Demonstrating CoffeeScript at Dev meetups

The video flies through core ideas pretty quickly, so I ran through syntax examples on a slide first, and then said “You know, I think this would go better to music,” and played the video.

Download and Demo

The purpose of offering the 600Mb video version is for the growing number of people doing CoffeeScript talks at their local software dev groups. The music in it is not licensed, not mine, but sounds awesome.

Please play the video with speakers. AC/DC on mute is a cruel act. Also watching the text jump around without the music is probably weird to watch. AC/DC and CoffeeScript. Perfect match, I think.

Formats: Torrent | Download (600Mb)

Tack så mycket

Swedish for “Thank you very much,” pronounced like “tuck sa-meekeh” or thereabouts.

If you use the video at all, I’d really appreciate it if you left a comment below!

Related posts:

1. Using CoffeeScript in Rails and even on Heroku I’m pretty excited about CoffeeScript as a clean-syntax replacement for...

Want to be the funniest person at the next hacker’s picnic? Point at a bottle of red ketchup with its lid next to it on the table and pronounce “Hey look, Open Source.”

Be ready with follow-ups like “Can you pass me the Haml?”

If you’ve used Ruby on Rails, Apache, Emacs, or Linux then you would have been impressed by the awesome quality of these free bits of software which are so important to us. They are free, they are important, and they are awesome.

Paying money for poor commercial software makes awesome, important free software appear even more awesome and important.

The facts seem gloomy. You are a humble developer. Awesome, important free software is a Herculean achievement.

Conclusion? You implicitly believe you will never write awesome, important free software.

But “never” is an awfully long time. And is the only goal “awesome, important free software”?

Reasons to write?

Personally, I don’t think I’ve ever created an open source project that is either important or awesome. I think my motivations for open source — my own projects or stuff added to other’s projects — is either:

“Wouldn’t it be cool if you could do XYZ?” or “Seriously. Why can’t I do XYZ?”

I was either amused or annoyed. Dr Nic’s Magic Models was a joke. ChocTop was vented frustration.

Perhaps there are different reasons. I find the following examples inspiring.

I think the late Why the Lucky Stiff created entertaining free software.

Tim Lucas created artistic free software (‘View Source’ to see the header comment)

Christian Neukirchen created liberating free software.

Ryan Davis created free tools.

Chris Wanstrath ports free software.

Is there a muse that you can choose?

What other reasons are there for writing examples? Perhaps leave comments below and I’ll add them to the list above.

Who? Me?

And “awesome” sounds awfully challenging to aim for. Surely, “Awesome” is just one end of a scale with “Worthless” at the other end. “Moderately Good”, “Average”, “Below Average”, and “Where are the test cases?!” are in the middle.

Have you ever visited a friend who you find putting on the finishing touches to a 6’ by 4’ canvas painting of their entire family from their last Christmas dinner together, and they say “want to help?” Unlikely. Fortunately open source software “paintings” are a free-for-all.

You can write Libraries, Adaptors, Applications, Frameworks, Tools, Extensions and Services.

You don’t even need to create new free software. Fix something that someone else broke. Add a feature that was missing. Write documentation after you eventually figured out what to do.

Mid-Year’s Resolution

It’s now April. If you’re still looking for a 2010 New Year’s Resolution, borrow this one: “Write some open source software.”

If you’re going to RailsConf, perhaps come along to my tutorial The 8 Steps to Contributing to OSS or let’s catch up in the corridors. It’s going to be a great RailsConf!

Related posts:

1. Home ...
2. FutureRuby talk: Living With 1000 Open Source Projects The FutureRuby conference has been (and still is, as of...

What is CoffeeScript?

Imagine all the syntactical delights of Ruby and Haml for your JavaScript. You write in a nice language, but get normal JavaScript at runtime. All whilst having full access to 3rd-party JavaScript libraries (jQuery, PrototypeJS), debugging support (it becomes pure, readable JavaScript), existing support from test suites (it’s normal JavaScript) and growing support from various text editors (TextMate, Vim, Emacs).

What simple delights?

No trailing semi-colons. No { some_code() } function/closure brackets. String interpolation. Multi-line strings. Explicit class syntax. Array slicing. An existential ? operator.

Scroll down the home page for awesome example after example.

These aren’t library extensions. This is clean, purposeful syntax.

You can play with the joyful syntax of CoffeeScript on the website. After reading the basic examples on the CoffeeScript home page, press “TRY COFFEESCRIPT” in the header menu.

As you play with the syntax, the equivalent JavaScript is printed on the right hand side (see image above).

How nice is that syntax? Very.

Installing CoffeeScript

1. Install NodeJS
2. Install CoffeeScript

For NodeJS (get latest release URL; using 0.1.31 as 0.1.32 doesn’t unpack for me):

cd /usr/local/src
wget http://nodejs.org/dist/node-v0.1.31.tar.gz
tar xfv node-v0.1.31.tar.gz
cd node-v0.1.31
./configure
make
sudo make install

For CoffeeScript (get latest release URL):

cd /usr/local/src
wget http://github.com/jashkenas/coffee-script/tarball/0.5.5
tar xfv jashkenas-coffee-script-bcf7b3f.tar.gz
cd jashkenas-coffee-script-bcf7b3f
sudo bin/cake install

Now test that everything is in place:

$ coffee --version
CoffeeScript version 0.5.5
$ coffee -e "sys: require 'sys'; sys.puts 'hello world\n'"
hello world

Phew!

Note, in the command-line/on the server, you are using the NodeJS JavaScript environment. It supports the CommonJS API for loading modules (normal JavaScript: var sys = require('sys')).

Um, but how do I use it in my web app?

Your application source code will have *.coffee files containing your sexy, short CoffeeScript. But at runtime, the browser needs the generated JavaScript.

I’ve been using the Jonas Nicklas’ bistro_car gem:

gem install bistro_car
mkdir -p app/scripts

In your Rails config/environment.rb file, add:

config.gem 'bistro_car'

And in your layouts, such as app/views/layouts/application.html.erb add to the <head> or the bottom:

<%= coffee_script_bundle %>

Now you’re good to go. Add your CoffeeScript files in app/scripts/*.coffee and they will be automatically available as JavaScript.

WARNING: Check your version of CoffeeScript

Check that this hasn’t happened:

$ coffee --version
CoffeeScript version 0.3.2
$ which coffee
/usr/bin/coffee

Arrgh, we should be using /usr/local/bin/coffee. bistro_car currently installs the old rubygem-based version of coffee-script; and you might be unlucky to have your $PATH find the wrong one first.

Either delete it (sudo rm /usr/bin/coffee and restart your shell) or make sure /usr/local/bin is earlier in your $PATH than /usr/bin, where RubyGems installed the old, unnecessary version of coffee command.

Let’s drink the CoffeeScript

Create a file app/scripts/application.coffee with contents:

powers: [1,2,3,4].map (i) -> i * i
alert powers

Load up a view in a browser and see [1,4,9,16]. You win! Throw in some jQuery/PrototypeJS/whatever. Beautiful.

View the source of the page, navigate to public/javascripts/bundle/default.js and you’ll see the generated source:

(function(){
  var powers;
  powers = [1, 2, 3, 4].map(function(i) {
    return i * i;
  });
  alert(powers);
})();

The problem: Heroku doesn’t have CoffeeScript installed

Heroku is a great place to host apps. Though it doesn’t have CoffeeScript installed so it cannot dynamically convert the *.coffee files into JavaScript.

If you want to use Heroku I guess we need to perform the conversion locally and deploy it.

But. In development and integration testing I want bistro_car’s dynamically generated default.js. In production, I need a cached version.

In application.html.haml I use (I can’t keep pretending I use erb):

- if Rails.env.production?
  = javascript_include_tag "coffeescripts"
- else
  = coffee_script_bundle

Now we’re just left with the hassle of automatically generating public/javascripts/coffeescripts.js.

First, a rake task. Second, a git pre-commit hook.

Create lib/tasks/bistro_car.rake:

desc "Generate the cached bundle/default.js file from app/scripts/*.coffee files"
task :bistro_car => :environment do
  path = "public/javascripts/coffeescripts.js"
  puts "Building *.coffee -> #{path}"
  File.open(path, "w") { |file| file << BistroCar::Bundle.new('default').to_javascript }
end

file "public/javascripts/coffeescripts.js" => Dir[File.join(Rails.root, 'app/scripts/*.coffee')] do |t|
  Rake::Task["bistro_car"].invoke
end

Now you can create coffeescripts.js and add it to the repo with:

rake public/javascripts/coffeescripts.js
git add public/javascripts/coffeescripts.js
git commit -m "Initial bundled coffeescripts file"

Now create .git/hooks/pre-commit:

#!/bin/sh

exec rake public/javascripts/coffeescripts.js

And make it executable (and git commit will invoke it automatically):

chmod +x .git/hooks/pre-commit

Phew.

Now, whenever you change a *.coffee script and you are about to commit it, the cached-production-only coffeescripts.js is automatically updated and included in the same commit.

Seems like a clean hack.

Summary

Why not make a library to do this? Well I’m hoping there is a better, cleaner way. Perhaps bistro_car can include a rails generator to package these bits and pieces itself, if my approach happens to be the best way.

Nonetheless, let history record that CoffeeScript is very cool though in the world of Heroku living with it is non-trivial at the moment.

Related posts:

1. Validate and Save your Ruby in TextMate – with secret Rubinus superpowers In some TextMate bundles, if you save a file it...
2. Showcase of CoffeeScript – 2.5 mins for your next Dev Group meeting If you are giving an “Introduction to CoffeeScript” talk...
3. Dead simple JavaScript Unit Testing in Rails Formats: Video/Screencast (410 Mb, torrent) | Video only (vimeo)...

Google Forms are a great, free way to collect information from anyone, stored directly into a Google Spreadsheet, and then have Google notify you each time a form is submitted (optionally). The downside is that you can only use one of their pre-packaged themes. You can’t have your company logo and corporate “look”.

Pooey to Google, we say. So we wrote custom_google_forms.

Want to truly customized Google Forms? Fork this repository, customize the CSS, DOM and images, and deploy to Heroku. You can then host/customize any number of Google Forms.

For example, here is an original bare Google Form and here is a fully customized version, including form validation and thank you page.

It’s fully a dynamic, thin layer on top of Google Forms. If you change your Google Form, your custom form application automatically changes.

How to use Google Forms?

Perhaps read this docco? Essentially if you can access Google Spreadsheets, you can create a Google Form (which automatically creates and updates a Google Spreadsheet based on the fields and form submissions).

Fork and Customize

It’s really simple to play with and customize Google Forms. Clone the GitHub project and fire up the Rails server:

gem install github
cd ~/Sites
gh clone mocra/custom-google-forms yourdomain-google-forms
cd yourdomain-google-forms
script/server

Go to http://localhost:3000/google_forms/new and add a Google Form:

The “Slug” is the URL path people will follow. That is, a slug “railsdev” maps to http://forms.mocra.com/railsdev.

The “Form Key” field takes either the Form URL or just the formkey parameter (e.g. dFo0LXQyYmlEV2dXcVJ6WjRweW9vRnc6MA) from when you view the live form.

Press “Create” and follow the slug url to view your Google Form through your own customized style.

Well, initially you’ll see the Mocra style. Let’s fix that.

Default Theme

First, fork the github repository so that you can push your style changes to your own repo.

gh fork
mate public/stylesheets/style.css

Now, edit public/stylesheets/style.css to your tastes.

Please don’t reuse our style. Aside from you looking a bit silly having the :mocra logo at the top, it would be weird if your forms looked like our forms. I guess you might as well have used the default Google Form themes?

Heroku Deployment

Let’s not get fancy, let’s just deploy your fork to Heroku. It’s free. It’s simple. You’ll be done in two minutes.

To get your copy of the application deployed to heroku:

gem install heroku
heroku create yourdomain-google-forms
git push heroku master
heroku rake db:migrate

Two optional environment variables:

heroku config:add GOOGLE_ANALYTICS='YOURCODE'

If specified, Google Analytics will be included on all pages (including the custom Google Forms page).

heroku config:add EXPECTED_DOMAIN='some.yourdomain.com'

If specified, ‘yourdomain-google-forms.heroku.com/someform’ automatically redirects to ‘some.domain.com/someform’.

For example, for http://forms.mocra.com we used:

heroku config:add GOOGLE_ANALYTICS='UA-5370510-4'
heroku config:add EXPECTED_DOMAIN='forms.mocra.com'

Getting Started

Once deployed, go to the /google_forms/new URL and add your first form. Once it is validated and added, you can start using it using the links shown.

Summary

Yay for free, customized Google Forms! Yay for free Heroku hosting!

Bonus: you can configure your Google Forms/Spreadsheet to notify you when new forms are submitted. That’s handy.

Thanks to Odin Dutton, our resident designer at Mocra, who did a great job applying our new theme to the Google Forms DOM structure. It’s wonderful having him on the team!

Related posts:

1. Closing in on The Dream: “one-click-to-deploy Rails apps” Got a simple app you want to build? Allocate...

Here’s the problem: I install OS X Firefox 3.6b2 along side Firefox 3.5. They are both in my dock. Their icons are the same. Um, which is which?

How about a sexy Firefox Beta icon to separate what’s-what in the dock, Quicksilver, Spotlight etc?

This post shows how to create a “beta Firefox” icon, install it into the Firefox 3.6b2 OS X application, and live long and prosperously.

Installing Firefox 3.6b2 along side Firefox 3.5

I think these are the instructions for having two Firefoxes:

Download the Beta DMG. Open it. Don’t just drag the Firefox icon into the provided Application symlink folder.

Create in your Applications folder, create “beta” folder for all things beta (your you could rename the Firefox beta application or whatever). From the DMG window, drag the Firefox application icon into your “beta” folder.

To run it, close down Firefox if it’s running, and launch the new one. Done.

Creating new Application icons

iConMerge is a nice OS X tool to create composite application icons and install them. It is freeware from Mocra.

You drag images or existing Applications into the two left slots and it automatically creates a composite icon. Press the <--> arrow to switch them.

See the project home page for instructions.

The “beta” sub-icon I used is below. Download it OR try dragging it directly from the browser into iConMerge.

Applying new icon to Firefox Beta

Click “Export” and select the Firefox beta Application. Done.

When you restart Firefox beta, you’ll see it’s Dock icon has changed.

Right click on the Dock icon, select “Keep in Dock” and them drag the icon next to your existing Firefox 3.5 application. Two Firefoxes, two different icons, happy times.

Related posts:

1. Easy scheduling by location, tasks and people – a case study of a client application from Mocra UPDATE: Orchestrate was reported in TechCrunch Several years ago...

Formats: Video/Screencast (410 Mb, torrent) | Video only (vimeo)

Writing tests are great for helping you design and think out your code, and the bonus is you end up with a test suite to aide in fighting against regressions. Why? It’s embarrassing when your JavaScript doesn’t work in production.

But how do you get started with testing JavaScript? How do you make it easy? I mean, so easy that you’d feel stupid to not write tests?

And how do you know if your designer/HTML-chopper has broken your JavaScript? How do you find out if JavaScript is broken in CI builds? And what is the appropriate punishment for designers who break JavaScript?

Finally, it is now uber easy to get started: the blue-ridge plugin for Rails. (I previously discussed it near the bottom)

To spread the word, I travelled to London, England for the Rails Underground conference a few months ago. The presentation is now online (recorded and published by SkillsMatter).

I was also recording the screen during the presentation and we’ve composited the two together (a la confreaks) and it’s available via BitTorrent. If you can seed for the next few days, that would be greatly appreciated too.

The talk is 45 minutes and questions are 6 mins. (I sadly don’t repeat into the microphone some of the questions because the room acoustics were good and everyone could hear everyone else’s questions. Sorry.)

Go get it now.

Why Blue Ridge?

This recording was done in July 2009, a few months ago. Is Blue Ridge still the bees-knees? I think so. It has issues, edge cases and bugs, but I don’t think there is a similar nor better Rails extension that includes (out of the box) a headless test runner, a bundle of test libraries (Screw.Unit, Smoke, etc), Rails generators, and automated discovery of “the designer broke our JavaScript!” lynch-mobbing (see my branch below).

These are the things I want. If there’s a better testing environment (say on HTMLUnit instead of env.js), then I think the killer packaging is to bundle it all up, with the features above, so it is drop-in, dead simple to use.

My history with JavaScript testing

In the introduction I talk about my life with JavaScript and testing. Here is the extended summary if it’s interesting to you at all:

• 2005:
  • ASP.NET + Ajax == “crapola”
  • Rails promo: “easier to do Ajax than not to”
  • Inline JavaScript helpers
• 2006:
  • RJS to generate JavaScript
• 2007:
  • JavaScript only in its own files
  • Unobtrusive JavaScript
  • Got myself into terrible mess with MyConfPlan
  • How to test JavaScript?
• 2008:
  • Figured out how to test it
  • Write a PeepCode but never published it
  • Wrote newjs and jsunittest
• 2009:
  • Found BlueRidge plugin for Rails
  • Headless test runner
  • BDD tests via Screw.Unit
  • Generators

Miscellaneous

I mention a couple of miscellaneous things. Here’s a summary.

My fork of blue-ridge has the feature to render sample HTML from your templates. It wasn’t accepted into the primary blue-ridge library because it was rspec only. Perhaps someone can make it work for test/unit etc.

I alias the script/generate command:

alias gen="script/generate"

I’m extending TextMate with Ciarán Walsh’s ProjectPlus plug-in (source). It’s sweet.

Thanks

Thanks to Mark Coleman for organising Rails Underground, inviting me over, and having the sessions recorded. And to SkillsMatter for recording and publishing the raw footage.

Thanks to Bo Jeanes for helping to get Final Cut Pro to mash the screencast and the SkillsMatter video into one video.

Thanks to Jack Chen for hacking some code to push the video up to s3 (when Transmit and BaconDrop were failing me)

Related posts:

1. Using CoffeeScript in Rails and even on Heroku I’m pretty excited about CoffeeScript as a clean-syntax replacement for...
2. Presentations RailsConf 2010: Contributing to Open Source Not sure how...
3. First look at rails 3.0.pre This article is out of date in some aspects....

Ever used a rubygem, found a bug, and just wanted to quickly bust out the big guns and fix it quickly?

The gem command doesn’t come packed with a way to find the original source repository for a gem. At best, most gems at least come bundled with the complete source, tests and documentation. Some gems don’t. Fair enough, since having access to the complete source via the gem still doesn’t allow you to fix a bug and share it with the world.

For that you access to the repo, a quick way to fork it, and a post-github way to share a gem version from yours truly.

The github gem and gemcutter are the modern day tools of master hackermanship.

Instant forking fun

Let’s say you find a bug in a gem, say rails, and you want to go to town on its source.

You know the gem is called rails but you’ve no idea what the github repo is called. Never fear.

$ gem sources -a http://gemcutter.org
$ sudo gem install github
$ gh clone --search rails
Select a repository to clone:
1.  rails/rails                         # Ruby on Rails
2.  technoweenie/restful-authentication # Generates common user ...
3.  justinfrench/formtastic             # A Rails form builder plugin ...
?

Press 1 and you’ll get a clone of rails/rails.

Alternately, if you want a fork or you know the exact user/repo already:

$ gh clone rails/rails

Now, fork your own version:

$ cd rails
$ gh fork

You now have your own fork. The origin remote also now points to your fork rather than the rails/rails repository:

$ git remote show origin
* remote origin
  Fetch URL: git@github.com:drnic/rails.git
  Push  URL: git@github.com:drnic/rails.git

So, make your changes, push them. Send a pull request or github issue or lighthouse ticket or what have you.

Want to get to the github project home page for your fork?

$ gh home

Instant gem sharing

Let’s say you patched the rails gem itself but you want to share your changes via your own gem.

In the olden days, github did this for you. Now you use gemcutter, and a little manual effort to do your own renaming.

First, install the gems locally, use them, and make sure all is good.

For rails, you install the edge gems (3.0.pre) with:

$ rake install

You can’t see ‘rake install’ in the rake -T list (hence my patch), but I think the following expression displays all tasks regardless if they have a description or not:

$ rake -P | grep "^r"

Rails is composed of several gems, unlike most projects that are distributed as a single gem. Here we want to share our commit within a new drnic-rails gem, but not touch the others.

Edit the railties/rails.gemspec file from:

Gem::Specification.new do |s|
  s.platform = Gem::Platform::RUBY
  s.name = 'rails'
  s.version = '3.0.pre'
...

and give your personal gem a new name:

Gem::Specification.new do |s|
  s.platform = Gem::Platform::RUBY
  s.name = 'drnic-rails'
  s.version = '3.0.pre'

To build and distribute the new gem:

$ gem build railties/rails.gemspec
$ sudo gem install gemcutter
$ gem push drnic-rails-3.0.pre.gem
  Pushing gem to Gemcutter...
  Successfully registered gem: drnic-rails (3.0.pre)

Follow any first-time gemcutter instructions and SUCCESS! Now I have my own drnic-rails gem.

Summary

To find, clone, and fork any rubygem that is hosted on github:

$ sudo gem install drnic-github
$ gh clone --search rails
$ gh fork

To personalise the gem and share it on gemcutter:

> edit the project.gemspec to have a unique name, e.g. yourname-project
$ gem build project.gemspec
$ sudo gem install gemcutter
$ gem push yourname-project-1.0.0.gem

I think this makes it much easier, faster and more fun to hack other people’s stuff.

Related posts:

1. Migrating project websites to github pages with sake tasks, new websites with jekyll_generator Its almost Christmas time and that means presents. It...
2. newgem 1.0.0 all thanks to Cucumber The New Gem Generator (newgem) was exciting, moderately revolutionary, and...