I thought you might be interested to see the fruits of my new hobby: stand up comedy.
It should be running in “HD” for 20% more laughs. Video taken by Greg Fairbrother, my awesome Mocra Off Railers co-driver.
I discovered a local Stand Up Comedy Course which started 6 weeks ago. The final “night” of the course was for the 8 of us to do a show for family and friends. I don’t remember reading about that on the sales brochure.
Nonetheless, knowing you had a 5 minute set to perform in front of your family and friends sets the expectation in your mind from day one that you don’t want to be shit. So we listened up, wrote as many jokes as we could think of, and hoped desperately we wouldn’t be a blubbering mess on the night.
It’s not all left to chance. Each week, the funny woman who ran the course, Fiona McGary, made us use the microphone on the stage. Either talk about our week, or list all the funny things you can think of about frogs. Or any other European people.
Each week we boldly attempted to make our other classmates laugh. At the start, they don’t. So I quickly learned to edit and then how to present comedy on stage. I tried to learn it fast because it’s weird telling a punch line, waiting for the laughs, and only being rewarded with a uncomfortable shared silence.
All my jokes started out crappy. So I attempted to edit them into “setup-punchline format”. Another phrase for “edit” is “delete half”. I’m a verbose writer. This turns out to suck awfully for stand up comedy. Or perhaps I should be a concise writer too. Oh the novelty of the idea.
Another way to edit a joke so it is ready for an audience is to delete all of it. Turns out, just because I thought of something funny doesn’t mean anyone else thinks it’s funny. Ewwww, that was an uncomfortable life lesson.
I don’t know anything else and the above is probably wrong too. The last six weeks have been a blur. Lots of practise, lots of editing, lots of writing, lots of testing ideas on Mocra staff when they aren’t expecting it, and weekly doses of disturbing reality at the Tuesday workshops when I realise I still have 10 years of more practise to go before David Letterman might ask me to come on his show. He’ll only be 112 years old by then, so fingers crossed.
I’m very appreciative of the 20+ family and friends who came along for the show. All the comedians were very appreciative of especially Lucas and Chendo who sat at the front and giggled like little girls all night.
Spending the last six weeks with the other noob comedians has been wonderful. It will be fun seeing everyone around the Open Mic rooms in Brisbane.
Finally, and most importantly, thanks to Fiona for running the course, and bumping us forward each week with the subtle phrase “that’s good; though it will need more editing.”
I’m getting close to releasing a new Cocoa application, CommitChat, a sexy interface to having conversations for each commit in each watched project in GitHub. It was time to start thinking about packaging and distribution.
The result is a new project for all Cocoa developers, called ChocTop, and a 30-minute tutorial screencast on how to use it. ChocTop is to Cocoa apps what Hoe is to RubyGems; except prettier.
Packaging Cocoa apps
You can package and release Cocoa apps in a number of ways. Each app is actually a folder, so they need some packaging. Zip files are easy and the bonus is they auto-open when people download them. But for me, without a doubt, is the DMG packaging with a custom background image and the embedded symlink to the Applications folder, like the one for CommitChat below.
I’ve always loved it. It made me as a user feel that this piece of software was special. A custom DMG is like a piece of magic.
Now like most magic, its really only magical when you don’t know how its done.
But there in lies a problem. You want to release your own Cocoa software with a beautiful custom DMG but you don’t want to know how to do it. You want the magic, even as a developer, but that means you can’t know how to do it.
And trust me you do NOT want to know how to do it. Ever.
Everything to love about Ruby: the concise, powerful language; the sexy testing frameworks; and finally, the people.
Everything to love about Objective-C: hmmm; well…; and finally, its the only high-level language you can use to write iPhone apps.
On iPhone 2.0, to arrive on the 11th of July, you cannot run RubyCocoa. But you can run it on your Mac, so let’s use it to unit test your Objective-C classes. This tutorial shows you how to get started using a new project rbiphonetest [GitHub | Lighthouse | Google Group]
If you followed some of my recent tweets, this project was previously called “iphoneruby”. And alas, the screencast also calls it “iphoneruby” but that was a crap name. People thought it was a way to run Ruby on the iphone. I can’t do that yet. So, a far better name is ‘rbiphonetest’. [track on summize]
Even if you’ve never touched Objective-C, Cocoa, the iPhone SDK, nor RubyCocoa I recommend watching the video anyway. It should give you hope that if you make the transition to iPhone development you don’t have to go alone without Ruby: your trusty swiss army knife of language/libraries/tools.
The screencast is also available in high-def video (55Mb QuickTime)
To summarize the video, but change ‘iphoneruby’ to ‘rbiphonetest’, you install the framework via RubyGems:
sudo gem install rbiphonetest
Then change to your project’s folder and install the test framework:
rbiphonetest .
Finally, for each generic, non-UIKit-framework-using class you want to test:
script/generate model WidgetModel
Then write your tests in test/test_widget_model.rb
Supported Cocoa & iPhone frameworks
The mysterious, magical premise upon which rbiphonetest depends is possibly erroneous: that your Objective-C class can be compiled and tested against your OS X/Intel frameworks, and if your tests pass you assume you can then compile and include your class with the the iPhone/ARM frameworks.
I’m willing to go with this assumption until its proven dangerously flawed by some angry 20-year veteran of NextStep/Cocoa/iPhone. But really, how different could NSString be on the iPhone versus your Mac?
Fortunately there is one way to check for significant differences between your available Mac-based frameworks, such as Cocoa, and the iPhone-based frameworks, such as UIKit. We need to compare the framework names, header files and method signatures.
So for example, you cannot currently unit test any class that depends on/includes the UIKit framework. Why? It doesn’t exist on your Mac, so the Mac/Intel compiler cannot link it in. We’re compiling and running our tests with RubyCocoa, which itself is built against the Mac/Intel frameworks, not the iPhone frameworks. Hell, Laurent doesn’t even own an iPhone [Laurent is the Apple-employee maintainer of RubyCocoa and the newer MacRuby]
Similarly, its no use including/linking the Cocoa framework into your Objective-C class. Why? It doesn’t exist on the iPhone. It has its own UI frameworks, collectively called ‘UIKit’.
So for the moment we cannot test UI-related, iPhone-API-specific code. But we can test generic Objective-C. That’s better than a kick in the teeth. Surely. I mean, in the teeth… that’d friggin’ hurt.
“Fair enough Dr Nic, so which frameworks can my code use and yet still unit test it with your oh-so-special test library thingy?” Keep your pants on, I’m getting there. [ref]
To the best of my ability, I’ve compared the two sets of frameworks and listed the available Frameworks that are available on both the iPhone and your Mac. There are about a dozen. The most important is called ‘Foundation’. It holds gold nuggets like ‘NSString’.
Note, this list doesn’t guarantee that any two framework classes – the iPhone and matching Mac framework – will behave the same. This list is compiled by finding the set of Frameworks with the same name on both platforms, e.g. Foundation.
Then it compares the set of public header files (Foundation.framework/Headers/*.h files) This comparison is by method signature. It pulls all lines from each header that start with + or – (+ is a class method and – is an instance method in Objective-C) and compares the two lists. If there is a single difference in the method signatures of the header files in the two platforms it is marked on the wiki page. You’ll need to look at the two header files yourself to see the differences. Some header files are ugly. C-based anything starts ugly and goes down from there, I think.
Python testing of iPhone Objective-C?
In the Python world there is PyObjC, a bridge-based twin to RubyCocoa. If you are a Python developer you could easily port this project to use PyObjC I would think. Ping me if you are attempting this and need any help.
Summary
I think this project can give Ruby developers a happy place to work from as they write their Objective-C/iPhone code. You still need to wire up your UI views and controller classes manually, but if you push all the “oooh that code really needs some tests” classes away from the UI-dependent frameworks then you can hook it up to rbiphonetest and write your tests in Ruby.
Currently the generator creates test/unit test stubs. I personally then add the Shoulda gem into my test_helper.rb for my apps. If an rspec and/or test/spec developer can help with adding support to the generators I’m certain the large rspec user-base would be happy campers.
Similarly, someone might like to investigate using MacRuby to run the tests instead of RubyCocoa. Fast tests vs slow tests. You choose.
What the?
Sometimes I re-read what I’ve written and notice things that don’t seem to make sense, but are in my vocabulary nonetheless. Yep, the things you learn living in Australia.
“Keep your pants on” – this seems to imply that until I mentioned otherwise you were about to take your pants off. Hardly relevant at any stage during this article, we’d both agree. Most code-based blog articles are “pants on”. This phrase means “don’t get upset”. You can try to figure out how you go from “don’t get upset” to “keep your pants on”. I have no idea.
I didn’t know you could run Ruby within TextMate snippets. As a consequence, a lot of the TextMate bundles I work on either have simplistic Snippets or the advanced code is run via Commands with code pushed into explicit Ruby files in the Support folder.
But sometimes I just want a clever snippet. For example, I want the ‘cla’ snippet to use the current filename to create the default class name instead of the current ‘ClassName’ default. I want default foreign key names to be meaningful.
I’ve now figured this out (thanks to Ciaran Walsh), and …
Um, lost already? Ok, let me show you via screencast on Snippets and Commands with Ruby (QuickTime (11Mb)):
In addition, there is the latest TextMate for Rails 2 Peepcode written by myself and spoken by Geoffrey Grosenbach. Its cheap at $9, good value at $15.50, and perhaps overpriced in the $20-$30 range. Lucky its only $9.
The snippets used throughout the video
The current Ruby.tmbundle snippet (activated via ‘cla’):
class ${1:ClassName}
$0
end
An attempt to use regular expressions to convert the filename to a classname:
class ${1:${TM_FILENAME/[[:alpha:]]+|(_)/(?1::\u$0)/g}}
$0
end
The final snippet, with embedded Ruby to do the heavy lifting (note: added ’singluarize’ to the snippet):
class ${1:`#!/usr/bin/env ruby
require 'rubygems'
require "active_support"
puts ENV['TM_FILENAME'].gsub(/\.rb$/, '').camelize.singularize
`}
$0
end
Add this to your own Ruby.tmbundle, or clone mine (which is a clone of the original subversion repo).
Sometimes when you are perusing code you ask the question: why the hell is that there? or why does this even work?
Now you can instantly navigate from that erroneous line to the git commit where it was added, and then using github’s commenting system add a full-flavoured remark about that person’s code. I’m not sure if profanity is against the GitHub Terms of Service, but I’d rather ask forgiveness than permission.
There is an editor for Windows – E-TextEditor – that was designed to support TextMate bundles. So far, the GitHub bundle doesn’t use any special features of TextMate’s latest-and-greatest UI libraries, so it should be usable on E-TextEditor.
Also, a VIM project has been created to port the GitHub bundle, by Christoph Blank. Cristoph can be found hanging around #hobo on irc as ’solars’, if you want more goodies in the VIM bundle.
[Laurent is the Apple-employee maintainer of