Defeated By Upgrades

I've waited and waited and then waited some more for a new MacBook Pro. I've not just been waiting for an upgrade but for a whole new machine, something as refreshingly different as the MacBook Air while retaining serious performance under the hood.

My current MacBook Pro is two years old. While it's worked well, the fact that it's not 64-bit has started to be an issue (ex: sharing virtual machines with coworkers). So when Apple announced upgraded (but not new) MacBook Pros today, I bit the bullet. My new decked-out 15" MacBook Pro (with a glossy screen, after much debate on Twitter) should arrive next week.

While I'm sure the new MacBook Pro will be superb, it's still a bit disappointing to wait for ages and still be purchasing a machine that's an incremental variation on a seven year old design. But then, if I cared more about design than performance, I would've gone for an Air.

Obligatory MacWorld Keynote Reaction, 2008 Edition

I'm excited about the iPhone firmware update. Good features and fixes there. Still waitin' on that SDK announcement.

Don't care about Apple TV, movie rentals, or any of the "Apple as media company" announcements. Still not gonna pay for DRM-restricted content, nor build a home theater around it.

Don't care about the Time Capsule since I have a great NAS at home, although I wouldn't return it if I got one as a gift. It would be nice if Apple allowed other network-attached storage devices to have more fine-grained control of how Time Machine backups consume disk space.

If the MacBook Air was faster than my first-generation MacBook Pro and had better battery life, I'd order one today. It doesn't, though, so now I'm stuck waiting for Apple to backport the Air's multi-touch trackpad and other enhancements to the MacBook Pro line. The Air looks lovely -- perfect for business travelers -- but just not hardcore enough for my needs. Well-positioned at the mid-point between the MacBook and MacBook Pro lines, then.

All in all a fairly disappointing keynote for me personally, but hopefully one that moves a lot of units for Apple. Even the prospect of more devices having multi-touch input is basically enough to satiate me this year.

Mac Software I Own Licenses For

Even after years of using and contributing to open source software, I think good software is worth paying for. To inspire gift ideas this holiday season, here's a list of the Mac software I own licenses for:

• 1Password - the best password manager ever.


• BluePhoneElite - when I had a phone this was compatible with, it was awesome. Control your phone from your desktop, pause music when you get calls, all kinds of future-is-now stuff.


• growliChat - long since rendered obsolete, but was worth paying for at the time. Hooks up the Growl notification system to iChat.


• Hazel - moves around files for me. I mostly use it to file away downloads and clean up after deleting applications.


• MailPlane - A lovely Cocoa wrapper around Gmail. The best of the web and the desktop. This is how I survive email.


• MarsEdit - I'm writing this blog post in it.


• NetNewsWire - if I could tear myself away from Google Reader, I'd probably read my feeds with this. I used to live in it.


• PandoraJam - another web/desktop fusion, this time making the Pandora streaming music service a joy to use on your Mac.


• PodWorks - it gets music off your iPhone or iPod. Essential.


• SuperDuper - the only backup utility I have total and complete faith in.


• TextMate - the ur-editor. All the power and flexibility of arcane editors like Vim and Emacs with a beautiful Mac face.


• Twitterific - how I interact with Twitter more often than not.


• Videobox - a simple, cute way to get videos off of sites like YouTube and Google Video and onto your iPhone or hard drive.


• Visual Hub - a simple, fast way to get other kinds of videos onto your iPhone or iPod.


• Xtorrent - My preferred Torent client. Subscribe to feeds of torrents (great for shows) or search right from the application. Speedy and stable.


• Yep - they say "like iPhoto for your PDFs", I say it's more like iTunes. Regardless, I can't live/work without it.

I've also been given licenses for the following applications by their generous, attractive developers:

• Acorn - a superb, lightweight image editor that completely obviates the need for me to keep Photoshop on my system.


• Pukka - a pleasant way to save bookmarks to del.icio.us on your Mac.


• VoodooPad Pro - a desktop wiki notebook thing that I use from time to time.

Good software is good. Buy some!

Things I Like Lately

There are some things that I like. Software and other things. Roundup:

Yep

Yep is iTunes for PDFs. If you don't collect PDFs like you collect music, this won't be appealing to you. Personally, I'm grabbing presentations, papers, tutorials, and books every day, all the time. This wouldn't be half as much fun without Yep's tagging and browsing. I also make heavy use of the "YepShot" bookmarklet that takes the web page you're looking at and pops it in your PDF library. Yep doesn't try to be an outboard brain like DevonThink. It just stores and organizes collections of PDFs like nobody's business.

Whisky

I went to Whiskey Fest SF with several of my coworkers. Favorites included Jura's Superstition blended Scotch, Old Pogue bourbon, and Macallen's Amber maple Scotch whisky liqueur. I also recommend having a quality Manhattan if you haven't ordered one in a while. You'll be happy you did.

Gmail IMAP

I can now use Gmail on my iPhone. It works awesome.



I can't say the same for the Mail.app in Leopard, though I give it a try every couple days. I've been using Mailplane on my MacBook Pro with great success. Just enough value added to the in-browser Gmail interface without getting in the way.

Music

DJ A-Trak's Kanye's Soul Mix Show has got so much soul. The newest Jens Lekman record, Night Falls on Kortedala has also been in heavy rotation. I'm seeing him tonight at Bimbo's, the best live music venue in San Francisco.

My Etymotics headphones died and I replaced them with a pair of Vibe Duos. While the Vibe's certainly aren't as accurate, their bouncy bass and handy iPhone-compatible mic makes them a pretty solid choice. Plus, they're exactly the price of an iPhone rebate, if you have one on hand.

Twitter Things

Spaz and Snitter are impressive examples of what Adobe AIR can do. Both are desktop Twitter clients that make extensive use of the API I maintain, and both authors have been excellent contributors to the Twitter development community. Also a big nod to Twitteriffic 3, definitely worth the asking price for all the work that Craig has put into it.



Foamee just launched. It's a way to keep track of people you owe beers to. It's one of the best-designed Twitter projects I've seen.

RubyConf 2007, Day 2: Mac OS X Loves Ruby

Apple's latest release of Mac OS X brings with it a number of improvements to and integrations with Ruby. Speaker Laurent Sansonetti - "Ruby Ninja" on his introductory slide - is the man behind much of this work. I'm amped for this talk.

Fundamentally, the distribution of Ruby in Leopard is much improved. It allows for multiple versions of Ruby to be present on the system, each with its own suite of gems. The version of Ruby shipped has support for DTrace, and Ruby has been integrated into Xcode and Interface Builder.

RubyCocoa, a bridge to Cocoa and C APIs, is included and supported by Apple in Leopard. Two RubyCocoa applications, PackRat and LimeChat, are offered as examples of robust applications taking advantage of the bridge. Leopard Server's own Podcast Producer makes use of Rails and RubyCocoa.

RubyCocoa works by creating proxies that forward messages from the Ruby runtime to its target Cocoa/C runtime. RubyCocoa can forward exceptions, convert types, and maintains Objective-C objects for the programmer. The bridge will also manage garbage collection. The messaging convention is to substitute every "." with an underscore in the method name (selector), while optionally omitting the final underscore.

Laurent then demos the creation of a simple RubyCocoa application. He creates a simple window in Interface Builder, containing a text input box and a button labeled "Speech!". Over in Xcode, he whips up some Ruby (complete with decent syntax highlighting). Interface Builder is aware of Ruby classes, outlets, and actions in the file he's editing back in Xcode. Predictably, the application reads aloud whatever in typed into the input box after hitting the button. It works! Applause.

Laurent then demos CocoaRepl, which allows for real-time evaluation of Ruby code. Window creation, Quartz Composer loading, and Ruby threads. The audience groans with geek lust as a window containing a Quartz composition is scaled while its opacity is modified, all code being executed from CocoaRepl.

A final demo: inject.rb, which allows a Ruby interpreter to be injected into the process context of a running Cocoa application. Laurent messes around with an instance of TextEdit from irb, grabbing properties about the window, changing the window's title and contents. More applause. Then, an instance of TextEdit whose input area is, itself, turned into an instance of irb. Fun.

Objective-C's APIs are described as "introspectible", while standard C APIs are a bit more difficult to interact with. Apple's new BridgeSupport provides XML metadata that covers static APIs, as well as a metadata generator so developers can allow bridges to take advantage of their own APIs. BridgeSupport is being used in both Ruby and PyObjC, as well as in Xcode, which is using it for auto-completion. Laurent demos BridgeSupport by generating metadata for libpcap and then using the resulting bridge output to write a basic sniffer in Ruby.

Running low on time, Laurent runs through an overview of the DTrace support in Leopard's Ruby. Probes in Ruby are available for function entry and return, exceptions, garbage collection, object creation and destruction, and more. A simple script is shown that will print function entries and returns, and said script is demoed. Leopard provides a graphical interface to DTrace's programmable probes called Instruments, and this is demoed tracing through an instance of LimeChat.

Wrapping up, Laurent talks about some of the limitations of bridging, including caching of instances, maintaining the object model twice, and converting objects and exceptions. Presently, RubyCocoa can't use Objective-C 2.0's garbage collection. Ruby 1.8 is also not thread safe, which presents some problems (this will be alleviated in Ruby 1.9). Laurent suggests that his team's future goal is to write the Ruby class model on top of the Objective-C runtime, which would solve many of the problems listed above.

Questions:

Can you distribute RubyCocoa apps on OS X versions earlier than Leopard? Yes, apparently there's a script for that.

Possible to see this on the iPhone? Next question. Big laughs.

Is the downloadable version the same as what's in Leopard? Not quite, but it's coming soon.

Building with a Rakefile rather than Xcode? You lose support, but you can try rucola as an alternative.

Do you lose Objective-C semantics in the conversion process? It's a work in progress.

Gem packaging? standaloneify is a work in progress.

Will the GC in Objective-C be committed to GCC? It's a different piece...

Keeping things up to date? You can do a gem update, but only big bugs and security problems will be addressed in Ruby itself. Not going to overwrite 1.8 with 1.9. Shooting for compatibility.

Why RubyCocoa over RubyObjC (my question)? RubyObjC was too small a project, wrong license, not the right features, etc.

My Leopard Thoughts

Having reviewed the Leopard reviews, it only seems fair to share a few of my own thoughts about Apple's latest OS release.

First, some context. I've been mulling over a switch away from the Mac for the last month or so. Ubuntu has taken Linux into the realm of early-2000s standards of usability. Meanwhile, my day-to-day computing needs look less and less like the traditional patterns of desktop interaction encouraged by Windows and Mac OS. I'm more interested in a developer-friendly operating system than a user-friendly one. So, a large part of my decision to stay with the Mac depends on Leopard's developer stance.

As it turns out, Apple has done so good by developers in 10.5 that it basically trumps all my other concerns. They've brought a bevy of goodness on the Cocoa front, superb Dtrace integration across the system, a tricked-out version of Ruby with real support in Interface Builder, and so much more. Unless you're a Java developer (sorry), a Mac running Leopard is a pretty great place to be coding. Even my enthusiasm for learning some Objective-C has been renewed with the features of the language that Leopard brings. Starting a ground-up, first-time Cocoa project in Leopard is far more hospitable.

Of course, all this goodness comes after Apple left third-party developers out in the cold with the GM release of Leopard, but it's arguably enough to balance out in the wash. Apple has also committed to an open iPhone platform, and is generally being an eventual good citizen, once they're confident that potential externalities have been ironed out. Keep the faith, be rewarded. It's the Apple way.

The other big sell with Leopard is that the things that matter aren't worse. The Mac is the only platform out there that gets reliably faster and more stable with every passing release. It's easy to forget about that after nearly two years on the same release, but feeling like you have a whole new machine after an OS X upgrade is, well, a great feeling. It feels like progress.

As for the stuff that matters less: I'm getting over the UI. I would've loved to see a smarter Dock, integrated buddy lists in iChat, a more attractive unified theme, and fewer rogue interface elements. Leopard just doesn't feel right, out of the box. It's a vision of computing that's in transition, and we're all guinea pigs. But it's still more attractive than anything else out there.

I've found myself throwing out a lot of small applications and hacks because Leopard works right. No need for iTerm because Terminal doesn't suck now. No need for Chax because iChat does tabs and such. You could even survive without Quicksilver or LaunchBar, what with Spotlight not working on glacial time nowadays. An out-of-the-box Leopard install is basically one copy of TextMate away from being ready to work for me. That's neat.

All told, Leopard is pacifyingly good. It's enough new that I'm engaged, and enough good that I can still get things done and be happy while doing them. It makes a switch to Linux seem frivolous.

An Aside About Hardware

While considering Linux, I researched the state of PC laptops, long since ignored by me since the advent of Apple's current portable lineup several years ago. My findings did not impress.

You can get a dirt-cheap PC laptop from just about anyone. Pay a smidge more and you can get a durable, reliable, ugly, underpowered thing from Lenovo; it'll run Ubuntu like a rock and embarrass you in front of coworkers and passers-by. A few more dollars and you can get a Dell with the slightest sense of design and nearly passable specs, but dude: you just got a Dell. Shell out the big bucks and you can have an absurdly slim Sony that's chock-full of crapwire and proprietary hardware. Or maybe you'd prefer a $4000, 9 pound gaming machine covered in tacky tribal "tattoos"?

Essentially, PC laptops are a joke. You used to be able to depend on PCs at least being faster, but no longer. Says PC World: "The fastest Windows Vista notebook we've tested this year--or for that matter, ever--is a Mac."

There's simply not a logical alternative to Apple hardware in the consumer space right now.

Reviewing the Leopard Reviews

By now, everybody and their mother has an opinion about Leopard. I can say that my own mother went through Apple's list of 300+ new features and tried out the ones that applied to her after upgrading. She likes the Mail templates. Anyway. Opinions are a dime a dozen, but actually taking the time to do a proper review is something else entirely.

I'm a big fan of software reviews. Unlike, say, music, there's something eminently measurable about software. You can graph its performance. You can compare its price. You can gauge a user's understanding and productivity. Yet, there's a quality to software reviewing that still comes down to pure aesthetics. That intersection of precision and emotion makes for interesting reading. And read I did.

If You Only Read One Leopard Review

...make it John Siracusa's over at Ars Technica. It's got everything: internals, externals, upsides, downsides, and multimedia asides throughout. It's an achievement of technical reviewing. It's also dead-on.

The Bad

The main complaints about Leopard are with its appearance and UI conventions. You'll find particularly dead-on criticism in ThinkMac Blog's roundup of Leopard stupidity. TidBITS' Six Things I Hate about Leopard isn't entirely concerned with looks, but UI gripes make up four of the article's six points.

Probably the best response to the UI gripes is Scott Stevenson's assertion that satisfying UI design is often illogical. It's also pretty much the only in-depth defense of the Leopard UI I've seen.

The Good

Even PC World likes Leopard. So does John Gruber, but liking/defending Apple's output is the very essence of his being. He spends a lot of time talking about Time Machine. I don't particularly care about Time Machine, but I understand that's it's full of meaty reviewable goodness.

Engadget compares Leopard to Vista in chart form. Leopard comes out on top by just a few points. Paul Thurrott doesn't think Leopard is compelling enough to warrant a switch from Vista. I couldn't say. Nobody I know uses Vista.

In terms of less textual reviews: CNET has a short video review that's extremely positive. They seem to like the various visual improvements.

The Geeky

Apple has a Leopard Dev Center that you can browse if you have an ADC account; most everything but fancy videos is accessible with a free membership. The Cocoa Application Framework release notes are probably also of interest.

Less officially, Matt Gemmell's guide on how to get rid of your code with Leopard describes all the libraries and widgets that Apple has opened up in response to indie developers rolling their own solutions. Scott Stevenson (again!) has a nice lil' quick Objective-C 2.0 tutorial.

There's been some noise about Leopard not shipping with Java 6. Gruber points out that this basically doesn't matter for the majority of Mac users. The next version of Java is likely coming soon anyway. Yawn.

Lastly on the geeky front, just so everyone knows: Leopard ships with a version of ssh-agent that works with Keychain. That's right: no more custom scripts, no more memory-devouring SSHKeychain. Joy.

Getting Ruby's Groove Back on Leopard

Apple has done good with the version of Ruby that ships with Leopard. It's got readline, it's got DTrace probes, it's got gem, it's got a sane default collection of gems, and by god, they actually seem to have integrated it with Xcode and Interface Builder. Oh, and it's cross-platform for 32- and 64-bit. Yeah. What.

With all that in mind, I clearly want to use Apple's pimped out Ruby even though my MacPorts version (installed while in Tiger) seems to work fine. So, some experiments.

1) If you install the very latest MySQL (the fancy Mac installer one), you can actually bulid the mysql gem with only a minor incantation. Much improved from Tiger, on which I had basically given up hope of ever having a working MySQL gem.

2) Just for shits, let's ditch MacPorts entirely because it sucks and I use it for less and less as time goes on. Take /opt/local/bin out of your shell's PATH. Now let's install everything I need for daily Ruby coding. Whoa. That basically all works. Everything except... rmagick. Oh. Crap.

3) Attempt to install the necessary dependency libraries for ImageMagick by hand. FAIL. Some crazy Freetype/Ghostscript font issue, not to mention that you get bizarre errors if you make clean install and re-configure in the ImageMagick source directory. Life's too short for this bull.

4) Throw out old, crap-landen MacPorts install with a sudo rm -rf /opt. Reinstall MacPorts, selfupdate.

5) Follow these instructions to get a working rmagick gem. Note the comments. Basically, all MacPorts is doing is taking care of the miserable chain of suffering that ImageMagick necessitates. I don't trust it with much else. (Well, save sudo port install git +svn, but it stings just a little. Ow, my pride.)

Now I've got Apple's tricked-out Ruby ready to do my day-to-day work. Sweet. Next experiments: seeing how well they've really integrated Ruby into the Cocoa development process, and messing with DTrace instruments.

Yet More on Cocoa Development with Ruby

Just after the Mac development love fest that was C4[1], my interest in writing a Cocoa application was piqued. Not being an Objective-C developer (nor having any real incentive to become one), I looked around at the alternatives and saw two different options for Cocoa development with Ruby: RubyCocoa and RubyObjC. After picking the brain of Tim Burks, documenter of RubyCocoa and author of RubyObjC, I was more confused than ever about how to proceed.

Tim has since released a language called Nu, designed exclusively to build on and bridge with Objective-C. As part of his rationale for the new language Tim outlined the problems inherent in bridging Ruby and Objective-C. Phrases like "overlapping", "inconsistent", and "incompatible" litter the document. 'Nuff said.

Nu looks neat. I built it up from source, ran the demos, and poked at the shell. It's got a good vibe to it. But the problem for me arises in the FAQ, in response to the hypothetical, "Can I use Nu without knowing Objective-C?":

"No, at least not if you intend to use it to write Cocoa applications. In my experience, it is a mistake to think that you can use Cocoa from any higher-level language if you don’t understand what’s happening at the Objective-C level."

So in order to really use Nu I need to learn Objective-C, Lisp, and Nu itself. All things I'd like to know... except, uh, Objective-C, which I was looking for an alternative to in the first place.

I understand the challenges in using a language bridge without understanding the languages on each side of that bridge. I suppose that redefines what I'm looking for: not a bridge that lets me interact with a toolkit like Cocoa, but a toolkit that supports multiple languages without having to build them from the ground up.

If I Didn't Use a Mac

I've been evangelizing Macs to friends, family, and basically anyone who will listen for over a decade now. Some days, though, I just don't like Apple all that much. Those days have come a bit more frequently of late, brought on largely by Apple's mishandling of the iPhone and disappointing showings in hardware and operating system revisions.

The release of the iTunes Wi-fi Store on the iPhone coupled with the revocation of third-party software on the device underscored for me that Apple's values are changing. I understand not wanting to support potentially damaging unlocking procedures, but waging war on a thriving software development community that exists in spite of Apple's total lack assistance is mind-boggling. Without third-party applications, the iPhone is little more than an iterative step towards a less repugnant mobile experience. With the addition of the Wi-fi Store, the iPhone moves one step closer to to its tacky companions in the mobile space shilling overpriced, crippled content. In short, the iPhone is lucky it's pretty, because it seems to be getting dumber every day.

Apple's advances in hardware are barely worth commenting on from where I'm sitting. Two years ago, I was excited to be able to tell prospective Mac buyers that they had affordable, market-beating options like the Mac mini or iBook. Today, those options seem overpriced and underpowered, though there still aren't clear competitors I could recommend. Of course, most of Apple's hardware line is irrelevant to me, and the one product that isn't - the MacBook Pro - has evolved only incrementally since its 2001 inception as the titanium PowerBook G4.

Most of what's coming in Leopard is either unexciting or outright unappealing. The GUI, usually Apple's mainstay aesthetic defense against competition, has gone gaudy; screenshots remind me of latter-day OS 9. Grumbles from the Mac development community about the overall quality of Leopard builds this close to the release window are troubling. From a development perspective, there's still no assurance of sane package management or first-class support for dynamic languages anywhere on the horizon.

All told, I feel a bit like Mark Pilgrim and Tim Bray circa last summer. There's nothing so egregiously wrong with my day-to-day Mac experience, but there's nothing particularly right either.

Both Tim and Mark compiled run-downs of the open-source equivalents of their Mac tools, and as an exercise, I'm doing the same here. Needless to say, Ubuntu would be my OS of choice.

Web

Firefox. I already can't develop for the web without Firefox and Firebug, and I can't reliably view a fair portion of the web in Safari 2, 3, or WebKit nightly builds. Safari isn't functional for me without plugins like Inquisitor, and those plugins are likely going away in Leopard.

Giving up 1Passwd would break my heart. I adore 1Passwd, and I know of nothing of its quality on Linux.

Text

I enjoy TextMate, but honestly, I don't use a lot of the completion and code generation features, as they tend to lag behind Edge Rails and other tools I work with. My fingers still remember Vim, and it's got tabs now.

Thankfully, I almost never have to edit office documents, and Google's Docs suite more than meets my needs. Keynote, Pages, and Numbers are lovely, to be sure, but I can usually load a document faster on Google's servers, where it's then a click away from getting where it needs to go (that is, out of my hair).

Chat

Much like Safari, I can't use iChat without Chax, a bunch of fixes and improvements to Apple's chat application that are forcibly shimmed in by SIMBL. Adium has never appealed to me; it always seems one more theme or icon set away from looking right, but it never does, and I always go back to iChat. Pidgin ain't sexy, but neither is chat.

I only ever IRC in dire emergency circumstances. XChat used to be fine for that and probably still is.

Mail

There is only Gmail. I tried to get back into Mail.app for the super happy iPhone Mac native app integration lovefest but it bit me in the ass with instability, terrible search, and no iPhone integration to speak of. There is only Gmail.

Media

Hrm. Erm. Erk. Songbird for music, I guess? I always kinda just liked mpg123, honestly. You can bg that mother or script a lil' wrapper around it. I kinda like Peel for slurping down podcasts, but if Songbird can't do that, Ruby + curl can.

There's VLC for video, which is already a go-to on the Mac. I don't edit movies. I put my scant few photos on Flickr. I actually like using The GIMP, and am pretty proficient at it for simple web-related image editing tasks. I would miss Skitch and Acorn, but I don't have occasion to use either app more than once a week.

I have no idea if there's anything like Yep for the Mac, but I'd sure miss my favorite PDF librarian.

Odds and Ends

Anything would be better than the terminal options on the Mac. I've given up Quicksilver for LaunchBar, and even then I only use a fraction of what it can do; any auto-completing launcher would work for me. VMware is still there on Linux, not that I need virtualization half as much as I think I do. Hmm, a good BitTorrent app? There's gotta be a dozen.

Oh. And. I hate window managers/desktop environments. I hate GNOME, KDE, XFCE, Window Maker, et al. I've tolerated the Mac OS window manager, Fluxbox, and Enlightenment. I do, however, like the Vim-for-windows that is wmii and Ion and that ilk. I've run them before and they're just dandy. You'd be amazed what your machine can do when it's not spending cycles painting windows with pixel-perfect shadows.

Hardware

Software-wise, a switch from the Mac wouldn't be that painful for me. The hardware is where it all breaks down.

As I said above, Apple's line is basically irrelevant to me save their top-end portables, so that's what I'd be trying to match in power and style. Aesthetically, one of those slim silver Panasonic ToughBooks would do, but Ubuntu on one still looks a bit sketch; no reliable external display support is a killer.

I know that Thinkpads and System76 machines are supposed to work great with Ubuntu, but I just wouldn't want to look at one every day. I'm vain about my technology. They wouldn't match my glasses. Nuh-uh.

The real issue, though: anything less than total support for your hardware is hugely frustrating. Little incompatibilities are what sent me back to the Mac after my last stint with Linux, an impossibly lithe and sexy but largely unusable Fujitsu. Little things like non-functional volume controls or wi-fi that requires command line incantations are deal-breakers.

If there's an attractive, powerful machine that isn't crippled under Ubuntu, do tell. I'm all ears. It's just that over years of doing literally hundreds of Linux installs for Installfests and the like, I haven't seen one come out as seamlessly integrated as a Mac yet. Not even close.

So What Now, Mister Doesn't-Need-the-Mac?

Well, if you need me, I'll be on my MacBook Pro. Apple may be pulling dick moves left and right, but they've still got the best thing going. I'll give Leopard a spin (whenever it ships) and maybe it'll wow me - or at least placate me.

I can't shake the hunch, though, that Leopard is going to be the tipping point back into Linux for me, and maybe more than a few other ex-pat Mac geeks who crossed back over from Linux to Apple's territory in the Jaguar days. That was 2002, and nothing stays rosy that long in computers.

Tim Burks on the State of Ruby + Cocoa

Not content to let a rhetorical question end my exploration into the state of Ruby and Cocoa, I went in search of expert guidance. Tim Burks was kind enough to answer a barrage of questions from me about Ruby and Cocoa over on his blog. His answers are informative and cover a lot of ground.

When faced with two competing ways of solving a problem, programmers are often forced to make unpleasant choices. It's clear from Tim's answers that while RubyObjC is the more elegant of the two Ruby-to-Cocoa bridges out there, RubyCocoa has Apple's weight behind it and may end up being the default solution for pure Ruby Cocoa development.

It'll be interesting to see what's available on Leopard for Ruby programmers, doubtless.

Projects, and What Does Ruby Development Support on the Mac Really Mean?

Work keeps me busy. Not sleeping-under-my-desk busy, but busy enough that I'm drained at the end of the day. The thought of writing yet more code once I've come home is usually unappealing. This is frustrating, because I've had two side projects that I've been trying to get out the door for some time. The eldest is Peeramour, which I still intend to deliver despite having long since missed my Valentine's Day launch date. Really, I do.

A more recent project is something I call Quotidian, a tagged database application for the Mac in which to store quotations. I'm not one to litter my writing, speech, and presentations with other people's wisdom, but I like referring to relevant quotes when I'm thinking. The multi-purpose information capture applications out there like Yojimbo or DEVONthink don't do it for me in this regard.

My secret motivation for writing Quotidian is that I've wanted an excuse to learn Cocoa programming for some time. Initially, I was thinking that I'd learn Objective-C in the process. I've since rethought this because:

1. None of the experienced Mac programmers I've talked to are particularly enthused about the language, even with the upcoming improvements in Objective-C 2.0. The consensus: "it's fine... yeah."


2. There's no long-term value to me in learning Objective-C; I'm not about to become a full-time Mac developer, nor am I eager to maintain legacy NeXT systems. There's nothing else one really does with Obj-C, is my impression.


3. There are languages I could learn that would have more value to me, or at least interest me more conceptually, and I can only fit so much in my head.


4. I know Ruby, and there's RubyCocoa and RubyObjC.

So last night I ran through Erik Kastner's super handy "Your first few days on RubyCocoa" tutorial, which is more like your first fifteen minutes if you have a working Ruby install. I wired up a simple interface to a Ruby controller, smiled when it all worked, and was then ready to start building something that looked like a real Mac application.

I started by looking for a way to put a toolbar in my application. That's when I realized that you basically have to know everything about Cocoa programming in order to use something like RubyCocoa. RubyCocoa is for Cocoa programmers who want to write some stuff in Ruby, not Ruby programmers who want to take advantage of Cocoa. I'm not even sure anyone has implemented an NSToolbar with RubyCocoa (I'll probably crib from this PyObjC tutorial).

I have much to learn. So this comparative review of several Cocoa books caught my eye today. I sympathize with the first comment:

"My basic test of a Cocoa book is a coherent explanation of why Interface Builder works the way it does: the Nextstep/Cocoa notion of 'outlets' and 'messages' and how IB works with them is the most confusingly counterintuitive concept I’ve encountered in 32 years of programming, and most books scarcely mention it."

Everybody's been chirping about Apple supporting development in dynamic languages like Ruby and Python, seemingly based solely on this page (see: "Picking Up the Pace of Cocoa Application Development"). It's unclear, however, what form that support will take. As of yet, there's nothing that illuminates the more oblique aspects of Cocoa development for us simple dynamic language folk. What's more, it's not immediately clear which of the Ruby bridges will be shipping with Leopard. While there are good community references like Tim Burks' RubyCocoa Resources, even accomplishing basic UI tasks like displaying a sheet in a window seems like much guesswork and fiddling.

Some official guidance is necessary. Does Apple really want developers building full-fledged applications in anything but Objective-C, or is its "embrace" of dynamic languages going to be as rocky an affair as its fling with Java?

C4[1]: Cabel Sasser on Coda

Cabel works for Panic, makers of fine Mac software like Transmit, Unison, and most recently, Coda. Cabel met his business partner, Steven Frank, through the Amiga community when they were high school students. After heading off to college and getting "terrible" jobs, they decided to start a Mac software company on the side during "the worst time in Apple's history" (the Gil Amelio era). After a stab at a software updating app that they never released, the pair decided to write a competitor to the then-standard Mac FTP client, Fetch. That product was Transit, later renamed Transmit.

The company's next incarnation was "four guys in an apartment," working on Audion and a never-released interactive chat environment called Ripcord. They made the conscious decision to scrap much of their pre-OS X code at this juncture. The current "version" of the company is nine people in an office in Portland. They've branched into shirts as well, which makes up "5%, but a fun 5%" of their business; Cabel claims the shirts are all they wear in the office. In the next year, Panic is looking is looking to grow, and is grappling with questions of how much to expand their staff, their stable of apps, their office space, and so forth.

Coda

At the start of their application design process, Cabel mocks up the whole application in Photoshop; each feature is a layer group. This Photoshop document is then passed on to the engineers.

Cabel describes the decision process behind picking the feature set for Coda's features. He shows an example of a user-friendly grep feature, the sort of subtle improvement to the text editor concept that they'd decided on for Coda. More complex, Cabel had mocked-up an alternate toolbar look which ultimately necessitated a totally new toolbar implementation. Apparently, this new toolbar look may make it into Leopard, as Apple has taken notice. Cabel suggests a pragmatic and judicious application of this sort of UI revisionism. Some UI work, like nested windows and file browsing, proved challenging, and Cabel remains unsatisfied with some of the decisions they've made (ex: moving single- vs double-click file browser behavior to a preference pane).

The topic now changes to resolution independence. The simplest UI elements in Coda are drawn programmatically, which solves the issue of scaling to higher resolutions. PDFs are used for flat color and basic shapes in controls, and multi-resolution TIFFs are used elsewhere. Cabel zooms in tightly to Coda's interface to demonstrate the effect of through-and-through resolution independence, and it's stunning. For designing resolution-independent textures, Cabel recommends working with Photoshop's vector-based shapes and applying effects thereupon.

The process of deciding on a name and icon for Coda was difficult. The application was originally named "Transmit Studio," but this was abandoned in the icon selection process. The Icon Factory worked up an icon of a forklift, but this was abandoned when Panic realized that an application called Forklift with an eponymous icon was on the market. They then went in a more organic direction, embracing the concept of developers "growing" the applications they'd develop in this application. A leaf was settled on, and after several revisions they settled on a design that's a balance of hyper-realistic and a more idealized form. There's apparently a hint of fuzz around the stem of the leaf, testament to Cabel's and icon designer David Lanham's attention to detail. Two sets of toolbar icons were developed, and they settled on the more literal collection.

On to the top of partnering. Panic courted the developer of CSSEdit, as they had no interest in competing with "a great CSS editor." The deal didn't work out, so Panic wrote their own. Panic wanted to use O'Reilly for the books section of Coda, but the publisher wanted too large a cut of every sale. They partnered with No Starch Press instead.

On the subject of anti-piracy, Cabel claims it's a losing battle. They attempted to block the trading of serial numbers with a "depressing message" and network serial number checking, but haven't seen any wide trading of serial numbers yet. They have seen one attempt at scripted serial number generation.

Cabel concludes by mentioning that Panic is hiring, and that they're open to developers who work on shareware on the side.

Questions

"Comment on the shaded look of Coda?" Cabel says that "we've seen Aqua become less Aqua over time," and remarks on the dramatic change between 10.2 and the present OS X look. He likes the look of Leopard, and his hopeful about some of the best aspects of the iPhone making it in to the OS's look.

"Why hire a designer when you're clearly good at it?" Cabel claims he's not a good artist (and that Steven Frank is a great artist but a bad designer). He describes himself as the bottleneck in Panic's development process because all UI elements have to be approved by him.

"How did you make the decision to migrate to Cocoa?" Cabel says it simply felt like the right thing to do at the time.

"Do you really rapidly prototype in Photoshop?" Cabel claims he does, with occasional Interface Builder mockups to grab controls from.

"Any feedback on your blog post about resolution independent stuff from Apple?" Yup!

"What about the design philosophy a small, disparate Unix tools like grep?" Cabel describes the challenge as determining the scope of the "pieces of the web design puzzle" that they put together.

"How do you prototype interactivity beyond Photoshop?" Thinking about storyboarding.

"Opening up the books feature?" It's a very popular request. Not sure how it's going to look yet.

(I missed a couple questions at the end.)

C4[1]: Tim Burks on "Bridges and Beyond"

Tim Burks previously worked on very low-level chip software. In the process of delving deep into computer technology and learning the gritty details he claims to have "lost a lot of heros."

But Brad Cox, author of Objective-C, remains a hero of his, particularly for his paper "Planning the Software Industrial Revolution". Cox saw dynamic binding as essential for progress in the software industry, and Tim sees the need for a glue language beyond Objective-C. His requirements for a glue are reflection, interactivity, and expressiveness, all of which he found in Ruby.

To bridge ObjC and Ruby you can wedge libFFI between the two languages to bridge their respective method tables. Tim spent the first half of 2006 working with and documenting RubyCocoa, but ended up frustrated. He started working on RubyObjC, and overcame seven challenges in the process:

1. Message syntax is far different in ObjC than in most other languages.


2. Types have to be translated between the two languages.


3. Libraries have to be bridged (ex: NSDate to Ruby's Date).


4. Object storage: each language has its own way of constructing and storing objects.


5. Memory management: GC can kick in when you don't expect it.


6. Threading.


7. Namespace conflicts.

Tim goes on to demo a visual chip design application that was mocked up in Ruby with an interface in Cocoa. While parts of it have since migrated to ObjC, a Ruby console is available at all times. As he moves around a chip and traces paths between wires there are oohs and aahs. It's really impressive stuff.

At this point, the talk veers to Tim's latest project: Nu, an interpreted dialect of Lisp "written on, with, and for Objective-C." He demos a simple blog editing app with an embedded Nu console, including language functionality that mirrors Ruby's method_missing. More oohs and aahs. Colin Barret posted to the Twitter backchannel: "As a language nerd, this is getting kind of pornographic."

As a further demo, we find out that the blog server that the blog editor is talking to is all written in Nu with CoreData behind the scenes. A choice quote: "[the server code] is not as bureaucratic and dictatorial as Rails." Templates are written in an Erb-like syntax.

All told, probably the most brilliant talk so far this weekend.

C4[1]: Bob Ippolito on Exploring Erlang

Speaker works for Mochi Media, which builds analytics tools for Flash developers, ad targeting systems, etc. Their applications have high concurrency needs.

Introduction

Erlang is a functional language that revolves around a "process" abstraction. The language has no mutable data structures; which apparently necessitates lots of linked lists. State exists solely in the stack, so backtraces are comprehensive. A common pattern is to use accumulators that make use of tail calls (calls to another function at the end of a function). Another language feature is pattern matching, which binds variables when patterns are matched.

Types

Two collection types are available: lists and tuples. Basic types include atoms (effectively a constant string, apparently quite fast to work with), binary (a contiguous chunk of bytes), integer (unbounded), float (64-bit), and ref (a unique reference across a cluster of nodes). Other data types include fun (anonymous functions, which are serialized and close over variables), pid (reference to a process, which can be on another node), port (reference to a driver, socket, pipe, and so on, much like a pid). There are no boolean, character, or string types; the above types meet these needs in various configurations.

Syntax

Variable start with a capital letter, and can only be assigned once ("single assignment"). Equivalency (=) is a simple form of pattern matching. Case statements can take advantage of pattern matching in more complex ways; an example of matching particular dates in given. Pattern matching is also ideal for working with file formats and a bits-and-bytes level; an example of checking for Flash files is shown. Expressions end in commas (delimit expressions), semicolons (delimits clauses), and periods (which end expressions or trigger evaluation in the shell). Anything that starts with a question mark is a compiler macro. Exclamation points mean "send a message to the left".

Modules

Modules exist in a flat namespace, and explicitly export "public" functions. Modules are referenced by name (which is an atom) and compiled to a .beam file. Erlang boasts hot code reloading, and modules take advantage of this. When declaring functions, arity (the number of variables the function takes) is noted. To compile all the modules in your project just do make:all([load]).

Processes

Bob notes that Erlang processes are lightweight and fast, being neither native threads nor pthreads, but rather lightweight green threads. Processes communicate only with asynchronous messages, which they may selectively receive. Because there are no mutable variables, processes are where program state lives. Server processes are written in tail-recursive loops. Matching and logging unexpected messages is considered best practice; unhandled messages will pile up, which is effectively a memory leak.

Distributed

There's little security between nodes; a shared secret cookie is standard. Language semantics are such that communication between nodes works just like local communication. Nodes may connect transitively. It's fairly simple to start multiple nodes and add process monitoring. Erlang is designed around the idea that nodes will fail, and as such it's easy to trap errors and restart nodes.

OTP

Originally designed for high-availability telephony, OTP is now a way of designing fault-tolerant applications in Erlang. An OTP is a tree of supervisor processes which start, monitor, and restart child processes. Also available in OTP are behaviors, which are a kind of enforced inheritance. The example of gen_server and its conventions is shown.

Demo

The presentation was being given from a simple Erlang-based web server, which Bob then load tests to varying degrees, demonstrating excellent performance. Bob mentions that the networking core of Erlang is multiplexed and takes advantage of the OS-level polling features (kqueue, etc.). Performance for their app has been excellent: millions of hits per day per server.

Questions

The "Programming Erlang" book is "an extremely good resource," says Bob.

C4[1]: Alan Odgaard on TextMate

Alan Odgaard is the Danish developer behind TextMate, an elegant and hugely customizable editor favored by programmers on the Mac. I spend most of my day in TextMate, so it's great to take a peek behind the scenes.

TextMate was born out of Alan's dissatisfaction with Xcode; he had several other projects in the works, but none of them really grabbed his attention. Early versions of TextMate got spillover buzz from the original Rails screencast, which pushed him to get to 1.0 quickly. His priorities didn't necessarily match the community's; for example, print support was missing in 1.0. Features like snippets, tab triggers, folding, and columnar editing are some of TextMate's big sells. More generally, the editor's overall embrace of customization has been a huge sell.

The customization model starts with input (key strokes, dropped files, tab triggers) and context (file type, project type, location in file, SCM, editor state). Actions like inserting text and running commands can then be performed. The more context available, the more the available actions can be tailored to the task at hand.

Alan thinks his model can be generalized to other applications. Breaking out contexts into declarative semantic abstractions, in Alan's estimation, makes working easier and more foolproof for users. He claims to not work particularly hard on TextMate's community aspect; its bundles feature makes sharing customizations easy. In the near future, bundles will be moved to a distributed version control system (they currently live in a central Subversion repository). Bundles will be visible to the user as a set of features to be flipped on and off.

C4[1]: Shawn Morel on VMware Fusion

Rougher notes on this one, sorry. It's dense stuff!

Some things can't be virtualized: optical drives, graphics cards, etc. This talk mostly about CPU-level stuff.

Hypervisor idea originated at IBM, was formalized by Popek & Goldberg in 1974. Properties of a VMM (virtual machine monitor): equivalence (identical operation to host environment), resource control, efficiency. Formalized set of attributes for a virtualizable processor.

"We don't call it HijackOSX.kext because Apple wouldn't like that." Switching each direction [between host and VM] is 7 microseconds.

VT: Intel's set of instructions for virtualization; can tell it "trap this instruction for me." Works fine without it for 32-bit. VMware lives in high memory and protects the VM with segfault protection, which Intel clobbers in 64-bit, necessitating VT.

A lot of the code is cross-platform C and C++. The crux of the code is the Virtual Machine Monitor, which is hard to port to PPC. Porting doesn't buy you much, since you could only run PPC guest VMs.

3D: working on drivers that will get Aero Glass going. Some Direct X games working without shaders internally. GL coming after that.

"Host doesn't have to know anything about 64-bit."

OSx86 + VMware = virtual Mac on Mac right now. VMware would have to implement EFI and Apple's proprietary ROM.

Snapshot trees? "Want to make things simple for consumers ... We can do it, but ought we do it? Do we want Fusion and Workstation on the Mac?"

C4[1]: Daniel Jalkut on "Application Acquisition"

Daniel has recently taken over MarsEdit from Brent Simmons, developer of NetNewsWire. In that vein, he's speaking about how software acquisition pertains to indie developers. Meeting Brent at last year's C4 conference put him on the path to acquiring MarsEdit.

Daniel argues that developers already operate in a culture of acquisition, and that there's no shame in starting from someone else's code base; revision is easier than creation. An acquiring developer has to balance the PR gains in taking on an established product with the risks of being perceived as a "software flipping house."

Risks in acquiring include the up-front costs, supporting a big user base, and taking on a potential volatile set of technologies and requirements. Daniel suggests having a "minimum success plan", a balance between your investment of time and money in the acquired application and the potential returns. The total cost of acquisition is more than just the base price; factor in renovation, support, icons, hosting, bandwidth, design, and so forth.

Finding an asset is easiest when you ask for what you want; blogging about it worked for Daniel. Once you've found an application you want to acquire, evaluate the seller, the code, the cost and potential risks. Discern the seller's motivation for offloading their app. A principal point that Daniel emphasizes: are you passionate about the product you're acquiring?

Many factors go into to sealing the deal. You may consider getting a lawyer and/or an accountant. Determine exactly what's being sold in term of code and marketing assets, and what the acquisition schedule is. Figure out pricing and how to transition existing users into your customer relations setup. Definitely set up version control to stage and release. Make announcements and do PR.

Choice quotes

• "You think about acqusition and you think about people on golf courses, dressed like Rentzsch."
• "I'll take a drink of water now... [amplified sound of drinking] Huh, that's cool!"
• "If you refuse to start a blog or don't believe in blogs, you should give up."

C4[1]: Friday

I'm spending the weekend in sultry Chicago, cooped up in the City Center hotel with a couple hundred of the Mac development's community's best and brightest at the second year of Wolf Rentzsch's C4 conference.

Friday evening started with registration and dinner at the hotel, and a chance for attendees to catch up. Once dinner wrapped up, everyone migrated to the conference room next door for Wolf's introductory talk. After a few housekeeping notes, Wolf dived into an analysis of the nature of indie development as it relates to APIs and tools.

Wolf on indie development

Wolf believes that the barrier to entry for developers has been radically lowered in the last ten years. A new independent developer in the '90s had to shell out for development tools, a developer network membership, and book/magazines to keep up with the latest techniques. Today, developer tools are free and the best educational resources are peer-to-peer in the form of blog posts and forums. If you want to "go indie" on the Mac, all you need is a Mac.

Additionally, Wolf argues that the important APIs are moving to the web. For web services, a lack of an API can be a deal-killer when trying to build buzz and community. For developers, it means you're more in control of both providing and consuming market-making APIs. Big companies no longer hold the API keys.

The talk was kind of all over the map (in a good way), and included the assertion that JavaScript is the best newbie language out there, amongst other juicy tidbits. Bold assertions set the stage for Wil Shipley's uproarious talk.

Wil Shipley on hype

Wil Shipley is no stranger to hype. The developer of Delicious Library most recently and many of Omni's best apps previously, he's a huge personality in the Mac community and a notable figure in the broader tech community. A superb technical mind, he's outspoken on the topic of his own success. Who better to talk about hype?

Essentially, Wil's talk was a tutorial on the mechanics and particulars of homebrew PR for independent Mac developers. While this could have been a dry, business school affair, Wil managed to crank out a routine that suggests he's got a solid backup career in standup. To attempt to replicate the talk's humor in blog form would no doubt fall flat, which elucidates one of Wil's best points: everyone remembers a character.

In short, Wil suggested the following to get noticed: build something great, take advantage of online PR, be generous with licenses for beta testers and reviewers, talk to Apple and get your app in front of everyone you can there, and make sure you keep the public's appetite for your work whetted at all times. While most of this is solid and intuitive advice, it's clear that it helps to be Wil Shipley to have it all work out for you.

A standout: for all his success, Wil claims the most successful app he ever shipped reached a fraction of a percent of all worldwide Mac seats, which is in turn ~5% of the overall computer market. On the hand, it's motivational that one you can make a good living off such a small market. On the other, it's sad that such great work is reaching so few people.

The evening concluded with drinks on the hotel's rooftop pool. Classy!

Pimp Your Google Reader

If you’d like to use John Hicks’s lovely Mac-like Google Reader theme in Safari, he suggests you use Safari Stand. I, personally, am not a Stand fan, as it’s not been so much with the working. My ideal Safari is served with Saft, Inquisitor, and PithHelmet. The latter option can theme Reader just dandy. Here’s how:

1. Install PithHelmet if necessary.


2. Download the theme.


3. In Safari, hop over to Reader.


4. In the PithHelmet sub-menu, click Show Site Preferences.


5. In the “Matching Pattern” box enter http://www.google.com/reader/* and choose “Wildcard Match” from the menu below.


6. In the “Style” tab, open up the “Custom style sheet” drop-down and choose the Safari/Opera version of Hicks’s theme.


7. Double-check your settings and hit “Apply”.

Refresh and you should be golden, barring any problems with the theme itself. I’ve been spending increasingly more time in Firefox, where the theme seems a bit more stable.

If you’d like to follow my shared items in Google Reader, here you go.