Dr Nic

Trialing RedCar instead of TextMate – replacing my aliases

I’m interested to trial RedCar in my life, instead of TextMate. So I need RedCar
to appear on my screen whenever I think “give me an editor”.

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

Packaging TextMate bundles in OS X DMGs

Last week Engine Yard released a CLI for their Engine Yard AppCloud. Delights such as:

ey deploy
ey rebuild
ey logs
ey ssh

Engine Yard.tmbundle

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!

Ruby on Rails.tmbundle

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.

Validate and Save your Ruby in TextMate – with secret Rubinus superpowers

In some TextMate bundles, if you save a file it will also validate the file and show any syntax errors in a tooltip. This is awesome. (e.g. JavaScript and CoffeeScript)

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

Validate and Save - No Rubinius

Rubinius superpowers

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

Validate and Save - Rubinius installed

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'

Showcase of CoffeeScript – 2.5 mins for your next Dev Group meeting

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!

How to make a good home-made Open Source

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!

rails2010_header_bg