Whenever I hear (It’s a poor workman who blames his tools) used as a blanket statement it bugs me. You know, some tools really are better than others. And you know, sometimes a (workman) chooses or must make do with poor ones. Again, I’m not talking about Ruby here—I’m talking about that saying.

A quick search yielded some fascinating history on the origins of that saying. It looks like the saying started off rather differently:

Mauves ovriers ne trovera ja bon hostill. [A bad workman will never find a good tool.] (French proverb, late 13th C. )

And that usage prevailed for about six centuries or so until this:

Good workmen never quarrel with their tools. (Byron, _Don Juan_, 1818)

which is pretty close to the prevalent version I hear all the time in the software community.

The earliest version says (a poor workman can’t do good work, no matter how good the tools are). Now I can get behind that one. No controversy there.

The latest version says a good workman can do good work no matter how poor the tools are. That presumes that the workman cannot choose his tools. For if he could choose his tools then he would be evaluated on his ability to choose them, and choosing bad ones would reflect poorly on his ability. Or perhaps the workman wouldn’t even bother choosing tools at all since all tools are equally usable (to the good workman.) And that just seems absurd on its face.

Tools do matter, and the ability to pick good ones often sets the very best workmen apart from their peers.

Well that’s not exactly true. It’s hard to find, but you can get the developer build of Chrome for the Mac. It’s prebuilt on the Chromium Buildbot Snapshots for Mac Page. Scroll to the bottom and download the latest Zip archive. It contains the app (Chromium) which you just drag to your Applications folder.

After it’s in place, use it to browse to the Official Google Chrome Extensions site. Then check out the Google Quick Scroll Extension, which continues your Google search beyond the results page, right on the third-party pages you jump to.

First off, apparently Software Update does not automatically update the JDK. You have to manually download and run the updates. There are four updates to “Java for Mac OS X 1.5″. Since I couldn’t tell whether they were cumulative or not, I just downloaded and installed each one in sequence:

update 1

update 2

update 3

update 4

Now you’d think you’d be done, but those updates only install JDK 1.6—they don’t make it the default. The way I did that was to change a link in the Framework:

cd /System/Library/Frameworks/JavaVM.framework/Versions
sudo rm -fr CurrentJDK
sudo ln -s 1.6 CurrentJDK

Now I see:

$ java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)

Stubbornella you have captivated me. I am now watching Nicole Sullivan‘s Object Oriented CSS talk for the second time. The OOCSS framework is a terse but ambitious thing in the tradition of YUI Grids CSS and Blueprint but with opinions that reach beyond grids, resets and typography.

While I have certainly not mastered the OOCSS concepts I do have some early observations I’d like to share nevertheless. This of course is dangerous territory since I risk having to eat my words later. So be it. Feel free to feed ’em to me as appropriate…

It strikes me from looking at the UML diagram for OOCSS that something is missing, or more accurately, some things are being conflated which shouldn’t be. If we’re thinking about objects and classes here the first question should be: what are we modeling? Well the semantic HTML folks might say we need to model things like paragraphs and headings, or at another level contacts and phone numbers, or at another level sidebars and navigation. These are all semantics.

When we think about modeling these things in HTML in such as way that CSS can be profitably applied, we use HTML element types to directly model semantics where we can (p element for paragraph, h1 element for top-level heading) and we use class attributes to express the rest (‘top-nav’, ‘address’, ‘phone’). If you have a look at the OOCSS UML diagram you will see in the “page layout” section a set of classes that fall into the former category ( ‘doc’, ‘hd’ for header, ‘bd’ for body, ‘ft’ for footer).

So far so good. But now how do we actually extend a class? The approach suggested in OOCSS is to change the (HTML) markup. One example from the talk is to specialize the media block class ‘media’ so that the fixed-size media is on the right instead of on the left. The suggestion is to define a new class ‘media_ext’ along with a new set of CSS rules. Then the idea is to change our HTML so that the element of interest carries two classes: ‘media’ and ‘media_ext’. And then we define some CSS for the new media_ext module, something like this:

.media_ext .fixedMedia { float:right }

This is the fundamental approach in OOCSS, so fundamental that it is on the short list of 10 Best Practices from slide 19 of the talk:

9. Extend objects by applying multiple classes to an element

The library defines a small set of base classes and a few core extensions to those. Users are invited to extend these further and we change our HTML to carry the full set of classes expressing semantics, layout and skinning too, all as separate classes.

The value in this approach is it certainly brings order to chaos. The downside is twofold: first we must pollute our HTML with layout and skinning choices and second, we must rely solely on coding conventions to ensure that each HTML element carries a self-consistent and complete set of classes.

aside: To me this feels much more akin to structured programming or maybe at best “abstract data types” than it does OO. I don’t really see language-level inheritance here, nor do I see polymorphism. But that’s just a terminological nit.

The first problem we need to solve is to get rid of the superfluous classes (on our elements). How could we make a media block (“fixed-width media object on the left with an open editable zone on the right”) into a right-handed media block without changing our HTML? Well the classic way in CSS is to use context to distinguish this situation. So let’s imagine that every odd media block ought to be right-handed. A classic approach is to have an ‘odd’ class on the element (or to use nth-child pseudo class). Perhaps something like this:

.media.odd .fixedMedia { float:right }

Where target is the fixed-width object we’d like to be on the right-hand side instead of the left. You get the idea. The problem with this approach is that we’ve just coded up some potentially reusable stuff (the {float:right} part) and we’ve got no way to reuse it in other circumstances. Also we are now guilty of committing pitfall #1 from the talk:

1. Location dependent styles

So you can see that we are definitely violating a key tennet of OOCSS. If you’re already an OOCSS dogmatist you may want to stop reading now. Still with me? OK, what if we want a right-hand media block for even rows next time? We’d have to edit that last CSS rule to look something like this:

.media.even .fixedMedia { float:right }

Yuck. What’s going on here? The problem is that CSS has no named/reusable/callable construct. No macro. No function. No Class. OOCSS does the best it can with plain old CSS by requiring us to define a new HTML class name. That lets us define a reusable set of CSS rules for it, but at the cost of polluting our HTML at each use.

I think a good way out of this is to break out of plain old CSS into a higher realm. Both SASS and CSS-SSC have a macro concept. SASS has its mixins and CSS-SSC has its base and based-on. What these actually add to CSS is named abstractions and reuse. So I could define a SASS mixin like this:

=right-hand-media
  .fixedMedia
    float: right

Now that is a reusable module. In my application I can apply that module to an element:

.media.odd
  +right-hand-media

Yay. Now I have the best of both worlds. If we have another app that wants even media items to be right-handed then we just define this:

.media.even
  +right-hand-media

The value of this is that I didn’t have to change my HTML markup in order to change the layout. There are examples of using the same approach to define a clearfix module. To those who say this approach is going to generate a lot of CSS I say, “well maybe, but I think our first priority needs to be making our source code manageable and this approach may just help us do that.”

As I already pointed out, this proposal (using SASS mix-ins or CSS-SSC macros to implement reusable modules, and then using contextual CSS Rules to apply those modules) violates a core principle of OOCSS. On the upside it solves one of the wish list items from the talk (on slide 60):

1. Extending objects—possible to make “sale module” inherit from “module”

.module{}
.saleModule{extends: module}

Now that approach is a bit different from the one I described for right-hand-media. But it is clear that mix-ins or macros could easily be used to reuse .module in .saleModule right? SASS mix-ins, for instance can be used (as in my first example) as straight-up mix-ins, or to implement inheritance. The choice is yours.

To close, I highly recommend watching the Stubbornella’s presentation. Twice. There is just a ton of gold in there. Meanwhile, I’ll go experiment with SASS mix-ins and let you know how it works in practice and how it can be combined with some of the other principles highlighted in the talk.

I’m tired of creating HTML attribution markup and style by hand every time I drop a Flickr photo into a post. I noticed the Yahoo Shortcut Plugin purports to address this issue. So I ended my procrastination and upgraded to WordPress 2.3.2 and installed the plugin. And here we are (see the image to the left)

Convincing the Yahoo Shortcuts Plugin to fetch the actual image of interest wasn’t as easy as I’d like but it’s clearly doable. I found the image using colrpickr, then navigated to the image and then entered the title of the image in the Yahoo Shortcut Plugin’s “Review This Post” view. The plugin found the image and allowed me to then add the image to my post.

Now wouldn’t it be the bomb if krazydad could integrate his colrpickr directly with the Yahoo thingie and save us all the steps?

You’ve heard of a “to do” list, well Joyomi manages your “to get” list. Joyomi highlights overdue stuff and helps you get it back. If you’ve lent a book to a friend, create a Book Omi and you’ll remember to ask for the book back next month.

Same idea for CDs and DVDs and money too. There’s a whole set of starter Omis. If you don’t find one that fits your purpose you can create a generic one.

Joyomi doesn’t just track your stuff it tracks your online conversations too. Use the Joyomi Bookmarklet to create Omi’s for important emails, blog comments and forum posts as well. With Joyomi you don’t have to remember to visit a bunch of sites—all the conversations are consolidated in one clean dashboard.

Once you’ve created an Omi it’s easy to share it with a friend. Nothing like those gentle reminders!

When I saw the S3Fox Firefox extension a while back I was encouraged.  Unfortunately, S3Fox has some critical bugs on the Mac. In particular, folder downloads don’t work — apparently because S3Fox is using backslashes in destination paths a la Windows. You end up with empty folders on your Mac.

I was rescued from a serious bout of the crankies by Nolobe’s Interarchy. This Mac-only file transfer application apparently supports lots of protocol standards and lots of interesting automation features blah-blah-blah but what’s important to me is — it has S3 support!  Woo hoo!  So I downloaded the free 14 day trial and used it to browse my S3 buckets. In a nonce I had downloaded a couple hundred megabytes of precious machine images and subversion snapshots. Now they sit on my disk, ready for their final DVD resting place. I can sleep tonight.

Oh, and Interarchy is a lickable OS X app too. I have no idea yet if I’ll prefer it to Transmit (tall order) but for S3 work from the Mac it looks like a must-have.

Well, a nice person at Transmit support answered my question. Interestingly, while perhaps a little non-obvious to the SSH-non-initiate, the solution is actually elegant — do nothing. That’s right, Transmit works directly with the ssh command-line infrastructure. This means if you’ve got your identities (keys and certificates) stored in the ~/.ssh directory you’re good to go. Further, if you’re using an SSH Agent (like SSHKeychain) you’ll never even be prompted for a passphrase by Transmit.
While I like Cyberduck a lot, the edge goes to Transmit — even at a cost of $29.95. Here goes:

1. Transmit is snappier. I haven’t measured file transfer speeds, but directory listing and navigation is definitely snappier than Fugu or Cyberduck. I spend a lot of time navigating around remote filesystems and I don’t move a lot of great big files so reponse time for listings is crucial.
2. Transmit can be configured to edit a file on double click. In Cyberduck you have to select the file and hit command-j to edit it — annoying. Of course in any case, the file must be downloaded — but it’s downloaded to some mystery location where you don’t have to worry about cleaning it up.
3. Transmit supports column view (browser view) just like Finder. Cyberduck does offer a contextual view but it’s more of a Windows-style-double-click-a-folder-to-expand-subfolders affair. Not that there’s anything wrong with that.

There are couple shortcomings worth mentioning too:

1. While Transmit offers tab support — innovative among the file transfer clients I’ve looked at — the workflow is a bit clumsy. If you have a configuration saved as a favorite there is no way to quickly and directly open it in a new tab. Instead you must go through four steps. How about an “open favorite in new tab” option in Preferences? Currently you must:
   1. open a new tab (command-t or via File menu)
   2. select the “favorites” tab within that new tab
   3. select the “Favorites” folder
   4. double-click the favorite you want

   On the upside — once you’ve done this once, Transmit remembers that you want the Location tab and the Favorites folder so the middle two steps drop out. Still, one step would be better than two steps.

2. When configuring a new connection for password authentication, Transmit won’t allow paste into password field — you have to type the password from the keyboard. I keep all my credentials in Keychain Access so it’s real easy to get ‘em on the clipboard. Minor one-time annoyance.

All in all I’m enjoying Transmit. It’s been reliable and comfortable. I’m off to pay my $29.95 now…

Unless you use ssh on the command line a lot.

Unfortunately, on OS X, the ssh command line tools are not integrated with Keychain Access. This is unfortunate for a couple reasons. First, it means that you have the choice (with the ssh command line tools) to either passphrase protect each key or not. If you decide not to then you expose that key to attack (if someone gets access to your disk).

Now if you do decide to passphrase-protect an ssh key a dilemma arises. You will be prompted for that passphrase each time the key is required for an ssh operation. Every time you ssh to a remote machine, or run scp or sftp, you’ll be prompted. And if you use Subversion over ssh you’ll be prompted (for a passphrase) for each of your remote subversion commands. Ugh.

Until Apple adds direct integration between the ssh command line tools and Keychain Access we have to make due with one of the “ssh agents”. There is a command-line one that ships with OS-X called ssh-agent if you like that sort of thing. I was hoping for a mouse-driven one and went on a little expedition.

The first one I looked at, SSH Agent, is a nice enough Cocoa app but it’s got a fatal flaw. The whole point of this thing is to enable me to avoid entering passphrases. To do that, the app needs to access a passphrase stored in Keychain Access. Well SSH Agent looks like it intends to support that — but unfortunately, the “add to keychain” control is disabled. As a result you have to go to Keychain Access and manually get your passphrase and then paste it into SSH Agent each time you you want to activate an ssh key.

The second Cocoa app I looked at, SSHKeychain fared better in this regard. It integrates nicely with Keychain Access. The interface is a bit quirky but if you follow the directions you should be up in no time. Note that with each of the ssh agents I tested, there were situations where I had to log out (of OS X) and back in to get the ssh command line tools to notice the agent.

Any chance of integrated SSH key management making it into Keychain Access in time for Leopard?

Well I’ve been thinking of switching to Panic Transmit for a while.  The Panic apps are just beautiful and Cocoa-licious. While there is no explicit mention of SSH in the text of the Transmit page, I did notice a picture that showed SFTP configuration, so I decided to give Transmit a try.  Unfortunately there appears to be no way to induce Transmit to do certificate-based authentication.  Apparently only username/password is supported.

Enter Cyberduck.   It’s a Cocoa app like the other two.  Unlike Fugu, this one remembers settings across restarts.  Cyberduck even has a nice little tray that pops out with your site “bookmarks”. And unlike Transmit, this one does a great job with certificate-based authentication — going beyond Fugu’s cryptic command-line escapes and letting me pick the certificate file from a nice file finder.  The other nice thing is that like Transmit, this one supports multiple editors.  Very nice.  Cyberduck: it takes a few more seconds to download (from TLD .ch = Switzerland) — but it’s definitely worth the wait.