If you give a speech to 200 people for 30 minutes you are consuming 100 hours of human life.

Giving an hour-long talk to a thousand people? That’s six weeks of human life devoted to your talk.

*gulp*!

Let’s assume 6 weeks of human life is at stake. It is not a loan and you cannot give it back. One hour after you finish speaking, you’ve used up 6 weeks of human life.

If you’re bad enough for long enough you kill a whole person.

Mathematically, if 1000 people witness your speech and 0 of them change any aspect of their life then you should not have given the talk. You used up 6 weeks of human life and achieved nothing.

Let’s all pledge together:

• I am valuable
• I will continue to share my ideas and my work in public
• I will continue to improve the craft of sharing publicly (for example, speech craft and blogging)
• I will respect the time of other people as a gift
• I will change lives

This pledge needs a name; anyone?

You are an incredible individual. You have done things, seen things, diagnosed things, solved things that no one else has done. No one else has the accumulated knowledge and reasoning that you have. You were the one who conclusively deduced that all solutions to World Peace involved chocolate biscuits.

You are also unique in your methods of communication. You have different stories, different mental models, and different approaches to communication. You do that thing with your voice and your posture. As a child you were beaten up for being different. As an adult it makes you extremely valuable.

There are human beings who need to have their lives changed by you. Your value is when other people behave differently because of you.

What to do next?

There is no check box, pass or fail, “crossing the finish line” in public speaking. I’d rather watch you play Guitar Hero. Aim higher. Take responsibility for your communication. Look at the human beings in front of you and rock their world.

How?

Like the craft of software development, there is the craft of communication.

Practise the craft of communication. Limit the minutes/hours/days/weeks that you use of other people’s lives. Write your speeches and then practise them to increasingly larger audiences.

“I’m not very good at speeches”

Write small speeches for small audiences. As you improve, increase the size of the audience. If it’s necessary to achieve your goal, increase the duration of your talk. Though how often can you communicate 80% of your message in just 5 to 15 minutes?

If you are given 45 minutes at a conference to speak, you are permitted by me to speak for 15 minutes only. If you know you only have 15 minutes, perhaps invite one or two other people to share during the remaining time. Or give back the remaining time to the audience. Ask them to use it to think about or explore the idea you’ve shared with them.

“Where can I find small audiences?” If you’re practising a large audience speech, then pull a handful of people into a room and they can alpha test your talk. As a small group they’ll probably do something annoying like give feedback. You’re probably self-conscious enough that your brain is full of negative self-feedback, so you may or may not want their feedback. But let them give it to you. “Thanks, that’s a good idea” is the reward you give them back.

Next, find another small audience. The jokes won’t be as funny in small audiences. Large audiences laugh louder and stronger. Do the talk again.

Follow up with the first group – did they do anything different in their lives after your talk? Did they talk about your ideas or thoughts during the week? If your speech is good then some small nugget will carry with them, regardless that they are a friend/peer/family member.

Don’t worry too much if you don’t rock their world: friends and peers tend to not learn as much from you. “You can’t be a guru in your home town.” That’s not the job of a friend. Friends are there to laugh at you and put you in embarrassing situations for their own amusement. Nonetheless, it’s interesting to see if your small friendly audiences thought about your talk in the days afterwards.

Even in a small room with friends, unload on them with energy and passion. Practise your communication as much as you practise your content.

“Where can I learn speech craft?”

Toastmasters.

You learnt to drive with your parents and a driving instructor. You learnt software development by writing small demo apps and pair programming. And yet some people have the audacity to stand on stage in front of 100s of people and be terrible. Those people are not you. You will not suck. You are going to learn the craft of speaking because you want to use people’s time well and you want to change their life.

Toastmasters is a club format. There is no “school” concept. Rather a group of 20 people meet twice a month and each time they all suck less. They stop stuttering. They tell interesting stories. Everyone learns something fascinating from other members who have different backgrounds and professions.

The practise format is interesting and successful. You give three types of speeches: 5-7 minute prepared talks, 1-3 minute impromptu talks, and 2-3 minute improptu evaluation talks about the previous speakers. That’s right, you get immediate evaluation from another club member!

Every club is different so visit a few of them to find a club that you like. Some a filled with old farts who value meeting protocol over having a good time. Some clubs like doing competitions. Some clubs meet weekly. Some clubs meet for breakfast or lunch or in the evening.

It’s relatively cheap.

You will learn the craft of speaking and leadership. And conversely, though not explicitly promised in any Toastmasters literature, you’ll stop killing people.

Is it really that important?

Personally, I think its a bit unfair of a presenter to be bad in front of a large audience for a long duration and say “I’m sorry if I was bad. I’m trying to get better.”

But! It is far far worse is the competent presenter who does no preparation, does a terrible job, and merely hopes it goes better next time. There are human lives at stake. One of them might be mine.

As a public speaker you have a gift – human lives. You have their time and their open minds. Aim high. Change lives. You are special. I hope to experience you speaking awesomely at a conference near me soon!

Thanks

Thanks to Zach Holman for our chat on the plane back from Ruby MidWest and for proof reading and fixing the post. He is a great speaker and will definitely convince you of whatever snake oil he’s selling rock your world. Just look at these slides!

Fear no more. A pastie is at hand.

Here’s how to install it:

In your `.bash_profile` add the following:

Thanks

@dwaite and others for `$@` instead of `$0 $1 …`.

Related posts:

1. Pastie paradise Summary: click to select Ever tried emailing someone a chunk...
2. Remote Shell with Ruby I wrote Composite Primary Keys and Dr Nic’s Magic Models...

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...

It irked me a little that I could develop on one stack (OS X, Rubinius, Sqlite3), run continuous integration (CI) on another stack (Ubuntu, Ruby 1.8.7, Postgresql), and deploy into another stack (Gentoo, Ruby 1.9.2, MySQL). I think what irks and worries me is that there are three sets of differences to be aware of. A bug in production? Was it a missing test scenario or one of the many differences between production and CI environments?

So I think I have two solutions.

First, use a VM that matches the production environment. Each different production environment would mean another VM. If you are managing your own production environment, then all you need is the tools (described in this article) to recreate your production environment in a VM.

Second, use a clone of your production environment. That is, if you deploy to Engine Yard AppCloud then run CI in Engine Yard AppCloud; if you deploy to a single Ubuntu instance on Slicehost, the have another matching Ubuntu instance on Slicehost.

I’ll write about the first solution – using VMs – here, and I’ll write on the Engine Yard Blog about the solution for Engine Yard AppCloud customers. For AppCloud users life will be even easier because there are zero setup steps to ensure you have consistent environments. It’s been one of my favorite projects in the two months since I arrived at Engine Yard.

I’ll also introduce a CLI for talking to Hudson – one that assumes you are working on Ruby/Rails projects – and makes it really easy to get up and running with a server, your Rails/Ruby projects, and any VMs you need (optional for Hudson, but they are the point of my line of thinking).

And I’ll introduce Vagrant, a CLI for creating/managing/destroying VMs.

Oh, and I’ll introduce Hudson CI.

Ok, let’s fix all our CI problems in one go…

Hudson CI

I needed a CI tool to allow tests to run inside VMs or on remote servers/VMs. Back in May I found and fell in love with Hudson CI. Fortunately it had support for “slaves”, and a way for CI jobs (your applications or rubygems) to select which slaves can be used. Hudson is also great because it is easy to try out (one click to install and launch), easy to configure, and has 350+ plugins.

What is Hudson?

CLI for Hudson

Charles Lowell’s hudson.rb project is a CLI for launching Hudson (it’s bundled inside the gem), and a set of CLI tasks to add/remove projects (jobs), add slaves, trigger builds and more.

gem install hudson

You can launch Hudson via:

hudson server  # Default: --port 3001
open http://localhost:3001

It currently assumes you are working on Ruby projects, using bundler, and attempts to create a useful set of default steps for your CI jobs.

cd /some/rails3/app
hudson create . --host localhost --port 3001 --template rails3

Hudson CI will automatically start running steps to install your application’s gems, database, and run your tests. When it does it on your local machine it’s not that impressive. When it happens on a fresh VM or slave node and you didn’t have to do anything to set it up, it’s awesome.

V is for Vagrant, VirtualBox and all things VM

If you can script it, then you can automate it. Fortunately, as a virtual machine VirtualBox is both scriptable and FREE! Secondly, if you have a VM, you’ll need to script its setup/provisioning; so fortunately there exists chef and puppet, amongst others.

Thirdly, if you are really really really lazy, like me, you will want Vagrant. Created by Mitchell Hashimoto and John Bender, Vagrant is a tool for building and distributing virtualized development environments. Everyone in your team have their own OS/configuration? Got Windows users on your team? Use Vagrant.

Once you have VirtualBox installed, getting any of your projects live within a VM is trival:

gem install vagrant
vagrant box add base http://files.vagrantup.com/lucid32.box
vagrant init
vagrant up
vagrant ssh
$ cd /vagrant/
$ ls -al

You will now see the contents of your project folder, but from within the VM instance! They are linked – a change to either is automatically reflected inside and outside of the VM.

In this example, the Guest OS being downloaded and installed into VirtualBox (note: without any GUI) is Ubuntu Lucid, but you could use any VirtualBox packaged unix system.

For wonderful guided tour of Vagrant see the Getting Started video.

Vagrant – Getting Started from Mitchell Hashimoto on Vimeo.

Hudson CI + Vagrant = Perfect CI

Whether you choose to use VMs for a production-like development environment (a good idea for anyone, a wonderful idea for Windows developers who are very far removed from their production experience), it is a very good idea to have a CI environment as similar to your production environment as possible. Here, we want a VM instance with all the components/utilities/rubies set up that you have in production.

I have created an example Rails application that is setup to use Vagrant for a CI slave VM.

See the README for complete instructions. See the Vagrantfile and the cookbooks folder for the configuration and provisioning recipes.

Once you have the VM instantiated, you add it to your Hudson CI master (either the localhost one above or your remotely hosted server) with the CLI:

hudson add_node localhost --name "VM" --label railsapp-vagrant ...

(See the example Rails application for the other flags I used to get this working). It is now available to all Hudson jobs; but has a label “railsapp-vagrant” to allow jobs (Hudson’s name for a project) to specify that slave node specifically.

To add the Rails application to Hudson CI, and force it to run the tests in this VM:

hudson create . --template rails3 --assigned-node railsapp-vagrant

If you visit the Hudson master (at http://localhost:3010 in the example) you will see the job automatically running (“building”) within your VM. It will use bundler to install the gems, and run all the tests.

That’s it?

I know, CI is historically a pain in the arse. When CruiseControl was the only CI kid-on-the-block, it was standard for people to respond “4 days” to the question “How long does it take to get set up?”

It can now be really easy.

More importantly than being easy, you are running an application’s tests within an isolated VM that you can design to match your production environment.

I think there can be a good future for CI and Rails applications. Thoughts on this solution?

Thanks

Some of the technology in this article is old, other bits are very new, but for all of it I thank all the creators and contributors. Hudson CI was created by Kohsuke Kawaguchi during his days at Sun. He is now offering Hudson support services via his company InfraDNA.

The Hudson.rb project was created by Charles Lowell to bundle the Hudson CI and some common useful plugins for Ruby/Rails projects. He came all the way to Gothenburg, Sweden for NordicRuby conference (great conference by the way!) I fell in love with Hudson and started helping Charles on Hudson.rb.

Thanks also to both Kohsuke and Charles for starting work on a JRuby plugin for Hudson CI, and writing up a progress report.

Thanks to everyone who agrees that Hudson CI is awesome.

Thanks to Mitchell Hashimoto and John Bender for creating Vagrant. It is an incredible tool for developing within a VM (on OS X or Windows).

Finally, thanks to Bo Jeanes who helped on the Engine Yard AppCloud version of this project. Coming soon!

RubyConf & RubyBayou

If you’re in New Orleans this week for RubyConf, I’ll be at the local Ruby group RubyBayou talking about Hudson CI, Vagrant, and AppCloud on Thursday night. There’s a happy hour from 5pm till the 7pm start.

Location: LaunchPad NOLA, 643 Magazine St, New Orleans, LA 70130

Come and let me convince you about the wonders of Hudson CI and having a CI test environment that matches your production env. You know you want to be convinced. It’s good for you, like fruit.

Don’t forget Chuck Norris

Always remember to install the Chuck Norris plugin for Hudson, and enable it for each job. Don’t forget Chuck Norris.

My biological time piece has a full set of inscriptions: go to university, chase girls, get a post-graduate qualification, catch a girl, get a professional job, marry the girl, change into contracting, change into consulting (and ponder what the difference is), work overseas (and marvel at the differences), make a baby, change into training, move back to Australia, buy a home, start a consultancy (Mocra), make another baby, grow the consultancy, and …

Really, I’m not sure what comes next in the script of normal life. Retire in 30 years? Create more little open source projects? Just keep growing the consultancy? Until what?

A few weeks ago, John Dillon, the CEO of Engine Yard, drew some pictures on a whiteboard for me and asked, “Do you want to help change the world?” Sure, a classic Steve Jobs one-liner from the history books of Apple. I said, “Yes”.

On the 1st of September I will start work at 500 3rd Street, San Francisco as Engine Yard
’s VP, Technology. Job description: help web application developers win.

The daily commute

Google Maps suggests my daily commute to work will be 22,300km. Some of that will be heavy morning traffic, so at say 30km/hr, that is almost 750 hours. Each way.

So instead, my family will pack its bags and move overseas again. Though for the first time, we’re coming to America!

How to move your family to America

It hasn’t been all smooth sailing on the home front since I broached the idea with my wife. Personally, have you ever turned to your wife and said, “Honey, I think we are going to move to America!”

Try it at home for a laugh. Perhaps your wife will say something witty or clever like mine. Something like, “No.”

“No, baby, really. I have something important to do for a few years. It’s in America. San Francisco. Apparently it’s lovely!”

“Is the weather nice?” she might ask looking for any reason to want to leave beautiful, sunny Brisbane.

“No. I think it’s kind of cold there. And foggy. There was even a taxi with ‘Fog City Taxi’ on its side. But there are wonderful schools and the people are fabulous and are from all over the world!”

“So our young kids won’t get an American accent?” she might ask pleadingly.

“Well, they won’t get all of the accents, no.”

“…”

“I love you!”

And so eventually your wife will say yes.

How do we get to win as web developers?

Choose to use Rails. Improve Rails. Improve the ecosystem above/below/around Rails. Improve our daily lives. Expand the sweet spot of Rails to solve problems.

In the future, can we look back at the work we did, the fun we had, the problems we solved, the time we spent working, and feel that it was worth the effort? Will we remember when we first discovered Ruby and Rails and remember the joy?

This is a world-changing set of issues to care about. I’ve always cared about them before now, but never had resources or reach to work on them beyond my own little projects or cunningly worded, suggestive emails/tweets/chat with other open source developers.

Though from now onwards I will get to work with one of the greatest concentrations of Rails talent and one of the largest open source programs in the our community. I’m more than just a little bit excited. Imagine working with full-time contributors to Rails, JRuby and Rubinius as well as the dozens of developers, devops and more.

As Engine Yard continues to grow and win then its capacity to fund and resource more contributions will grow. And then we all win faster.

Can you imagine what else should be funded, promoted or prioritised? I have a dozen solid ideas but I would love suggestions.

Mocra

I will miss my guys at Mocra, a wonderful Rails consultancy with clients around the world whilst based out of Brisbane, Australia. I founded and ran Mocra for the last two wonderful years. It will be slightly annoying – I won’t get to take any credit for all the success the Mocra team will have in the years to come.

Definitely, if you need an awesome Rails team for your project, contact Mocra. If you need a personal introduction, let me know. I know some people there.

San Francisco

I am very excited to move to SF and to hang out on a regular basis all the people I have only been able to see at conferences.

I’d also love suggestions of where a family of four (including a 4yo and 2yo; oh, plus another one due in February) could live. I’ve briefly seen parts of SF and many of the surrounding towns in the bay area. Thanks to Randall, Tammer and Marcy for their turns as tour guides during my visit a few weeks ago.

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)...