So after a couple of weeks, I’ve managed to remain mostly clean. A couple of observations:

• It’s crucially important to keep the Downloads folder clean. This means finding a more permanent home for downloaded files quickly or throwing them into the trash. The “broken window” impact of having a anything-but-empty Downloads directory is higher than I expected.
• Similarly, a strictly controlled Documents directory is crucial. I have “Presentations”, “Virtual Machines”, and “jQuery Doc Files” (for my book).
• Applications has turned out to be more difficult than I expected. There’s a fine balance between keeping commonly used things at the top-level and keeping the top-level relatively small. Obviously, this is mostly obviated by LaunchBar, but part of this project is about making it a lot easier for me to understand what is on my system, so having a global trash bin isn’t really acceptable, even if it’s easy to rummage in it.
• It’s very hard to control what gets installed in the system. I’ve tried to install as much as possible via MacPorts, just because I know I’ll be able to uninstall it later.
• I’ve been using Adium for IRC, AIM, GTalk, and Twitter. Even though it’s not as good as the special-purpose tools for IRC or Twitter, there’s a lot of value in keeping everything in a single app, and being able to combine IRC users with their GTalk counterparts is a nice side-effect that has started to pay off over time. I definitely don’t expect everyone to do this (especially for Twitter), but I’d recommend playing with it and see if having all of your contacts in a single place is a win for you :)
• Incidentally, part of what makes Adium for Twitter doable for me is Cotweet, which sends me a batched email every so often of the @wycats mentions on Twitter.

What about my code directory?

• I divided the top-level into two directories: active and vendor. The active directory is for the projects I’m actively working on and have commit (or a fork).
• That includes: rails, merb, rubygems, gem_resolver, and evented_jquery (private for now).
• My vendor directory includes git or hg repos I’m watching and use frequently. Under vendor, I have a java directory, which includes the davinci project, jruby, jvmscript, ruby2java, and Rhino.
• Right under vendor, I have adium, bespin, jquery, macports, matzruby, and rubymacros.

This may or may not scale over time, but again, it has the pleasing property of being able to determine, at a glance, what’s going on in my code directory for some aspect of my work. So far, organizing things reasonably well has helped me a lot to find what I need when I need it in the appropriate context.

My last machine finally died a slow, painful death, so I have the opportunity to start with a new, fresh machine. As usual, I begin with high hopes of keeping things clean and easy to navigate, but I anticipate failure. In an effort to stave off that failure, I’ll be blogging specific techniques (successful and failed) that I use to try and keep things organized.

My steps so far:

• Update the system to the latest OSX. Repeat until there are no updates left.
• Install XCode. As an iPhone developer, I downloaded and installed the latest XCode with iPhone support. Failing that, I would have just downloaded the latest from Apple.
• I then went into the Help menu in XCode, opened Help, and subscribed to Core Library, Java 5 API Reference, Apple XCode 3.1, iPhone OS, and iPhone OS 3.0.
• Install MacPorts.
• Install AppZapper. This is the first thing I haven’t done before. AppZapper will remove other traces of an application, in addition to the application icon itself from /Applications.
• Install LaunchBar. This is equivalent to QuickSilver, but I prefer LaunchBar. After installing LaunchBar, go into the Advanced Tab in Help and select “Hide Dock Icon”. This activates a hack that hides LaunchBar from the dock, while keeping it running.
• Install Google Chrome. This isn’t strictly necessary, but I’ve been playing with Chrome for the past few days and the fact that it avoids long-term memory leaks has helped reduce the long-term degradation of a machine that eventually needs a restart.
• Install and setup Adium.
• Install bash-completion via ports. sudo port install bash-completion. After completing, add . /opt/local/etc/bash_completion to ~/.profile. Also, add +bash_completion to /opt/local/etc/macports/variants.conf. This will cause all future ports to also install their bash completion, if available.
• Install git-core via ports. This will include bash_completion, because we added it to the default variants above.
• Update Rubygems. gem update --system. Wait for it to bulk update your gems. This should be the last time you ever have to do this (thanks Eric!)
• Use Calaboration to sync my Google Calendars with iCal.
• Transfer music from backup to iTunes and setup iTunes to be using the correct user.
• Resync my iPhone with iTunes.
• Remove System Preferences and Time Machine from my dock.
• Trash downloaded files from my ~/Downloads.

Next, I’ll talk about how I’m organizing my Code directory :)

I had forgotten how much I missed optimistic Science Fiction. When we look back at the history of science fiction, the first decade of the 21st century will be remembered for an adventure into grittiness, pessimism, and exploration of the devils, rather than angels of our nature. Perhaps it was a needed excursion, but it has been an exhausting decade.

Perhaps science fiction simply reflects its era, and the last decade has certainly been an exhausting look at the devils of our nature in reality as well as fiction. Just as I am glad to see the pessimism and grittiness of the last decade give way to the hope and optimism of an Obama administration, I was glad to leave the movie theater from the new Star Trek movie feeling like the shadow of the last decade has lifted.

To be fair, television series like Battlestar Galactica were excellently produced, directed, and acted. The genre is better off for its existence; indeed, the darkening of Stargate SG-1, and the darker themes in Stargate Atlantis relative to its parent series made for compelling, interesting science fiction.

But I lost sight of the fact that optimistic stories, those that did not rely on racism, prejudice and other human failings had all but vanished from television. Even Star Trek, which always showcased the elimination of racism hundreds of years in our future, trotted our a grittier, conflict-ridden series in Enterprise, in which the ongoing conflict between the humans and vulcans was a thinly veiled metaphor for modern-day racism and hatred.
The thematic changes are even reflected in the lighting. Even shows from the 90s like Babylon 5, which tried to paint a more realistic, gritty face on science fiction, featured relatively bright settings and an overall optimistic theme. After several seasons in which the heroes battled relatively evil (but sometimes ambiguous) villains, they emerged victorious, and the victory was soaring and uplifting. In contrast, virtually all shows in the last decade have involved morally ambiguous heroes and dark, gritty sets.

Again, there is certainly a place for that sort of thing, but the utter lack of optimistic, bright, unambiguous science fiction over the past decade has fatigued me in a way I hadn’t realized at all until I stepped out of the theater from Star Trek this weekend. Having gotten past the unpleasant future of the Enterprise world, Star Trek (the new movie) features a racism-free future, flawed but uplifting heroes, and bright, large sets that evoke feelings of optimism. I have to say: it felt good.

I had a really great time at RailsConf. I met a ton of really cool people bursting with enthusiasm for great projects. I sort of knew this already, but now I know it viscerally: the diversity of things that people are doing with Rails far outstrips the ability of those most deeply involved in building it day-to-day to anticipate. What was also really great was that so many of the ideas people asked me about could be answered by pointing at new extension points or modular APIs that we’re adding to Rails.

About my talks: let’s just say some of them could have been better. I’ll post the slides inline below with my personal wrap-up of each.

The jQuery Tutorial

The slides for the tutorial are available on this blog; the code is at Github. I had high hopes for this tutorial initially, but a few things (mostly my fault) made it worse than I expected.

First of all, I lost my co-presenter around a week before the tutorial. Thanks to Andy Delcambre, this did not catastrophically destroy the tutorial, but it did add additional challenges. Had I been better-prepared, it would not have been such a problem, and Andy performed very well under pressure, getting into the flow in a week in which he was also preparing the Flex demo for RailsConf.

Second of all, I didn’t specify the required skill level for the tutorial, which led to a wide disparity in the skill level of the attendees. I expected an intermediate group, so the focus that should have been on the introductory section and the labs was spread out to parts of the tutorial that we never really got to (e.g. evented programming). As a result, almost all of the feedback was either “that was wayyyy too introductory” or “that was wayyyy too advanced.” Again, this is something I should have prepared for, so definitely a mea culpa on my part.

All that said, I thought the content and labs were really good for the portion of the audience in the sweet spot (knew some JavaScript and CSS, but still needed more training in jQuery).

Technical Deep Dive

No code or slides here; the entire session was Carl and I talking through the recent architectural changes. For an evening Birds of a Feather, we got excellent attendance, and almost exclusively positive feedback. I thought it went very well, and really enjoyed the opportunity to share the gory technical details with the folks who took a night off of Vegas to stay for a very low-level technical talk.

Russian Doll Pattern

Again, this didn’t go as well as I’d hoped, but I’m still relatively pleased with the outcome. It was the first talk given jointly by Carl and me, and our relentless focus on getting the Rails code we’re working on ready for RailsConf left us with less time to get our delivery anywhere near as smooth as the Ruby standard-bearers for joint talks, Joe O’Brien and Jim Weirich.

The talk is available from this blog as well.

We also focused heavily on the concept of mountable apps and addressed a lot of the concerns that people have made in the past, as well as focused on appropriate techniques for building applications that could be reusable. Unfortunately, we’re not yet at a point where we can show a final DSL for the specifics. What I find personally frustrating is that for a lot of the most interesting projects, the hard work is the first 98%, after which there’s nothing “cool” to show. The final 2%, which is usually a day or two of work, produces the whiz-bang demos. For a lot of what we’ve been doing in Rails, we’re at the 90% or so mark, which means that the underlying infrastructure for doing really cool stuff is in place, but we don’t have the whiz-bang demos yet.

Thankfully, there was a great complementary talk by James Adam at RailsConf which covered the state of the art of engines as of Rails 2.3, so I was happy focusing our presentation on the likely future. Still, the “unicorn”, ethereal focus definitely detracted from what was otherwise a good first showing for the pair of Carl and me.

If anyone attended any of the sessions and has questions or constructive feedback, I’d love to hear it. Please feel free to comment below or email me at wycats@gmail.com.

One of the things I love the most about the Ruby community is how easy it is to try out small mutations in practices, which leads to very rapid evolution in best practices. Rather than having the community look toward authority to design, plan, and implement “best practices” (a la the JSR model), members of the Ruby community try different things, and have rapidly made refinements to the practices over time.

It is natural to assume, looking from the outside, that the proliferation of practices is dangerous or fracturing. It is not. Instead, it functions more like biological evolution, where small mutations conspire over time to refine and improve the underlying organism. Consider the example of testing. There are a number of testing frameworks used by Rubyists, but they have largely converging feature-sets. As the feature-sets converge on superior solutions (e.g. Rails’ flavor of Test::Unit now comes with Rspec-style declarative tests), another round of differentiation occurs, allowing the community to zoom in on the now smaller differences and allow evolution to take its course.

The analogy isn’t perfect, but the basic idea is sound. It’s tempting to find consolidated practices on May 2, 2009, and find a way to shout them from the rooftops in more official form, so that those who haven’t caught up yet will have a way to immediately select the “winner” practice without having to do detailed investigation. Further, some have suggested that we should rank Ruby firms by how well they conform with the most popular practices of the moment. This will allow those who are looking for a firm to hire to determine whether or not their potential hirees conform with those practices.

Unfortunately, while that might work for a given slice in time, it provides unwelcome and artificial inertia for the practices of today. Now, in addition to having to contend with the normal inertial forces that resist changes until they are proven (wise forces), firms that want to try out new practices will need to contend with the artificial inertia imposed by being moved down on a list of firms conforming with other practices.

In effect, in creates a chilling effect on experimentation and innovation, and a drag on natural evolution.

It makes perfect sense to create a forum for sharing and aggregating the practices that people are finding useful at the moment. What makes less sense is creating a ranked list of “popular” practices, with no obvious mechanism for mediating differences except pure popularity. And even worse is ranking firms by their aggregate level of conformance.

As Rubyists, we need to discourage artificial attempts to encourage conformance and discourage innovation. Rails shops should find other ways to advertise the quality of their practices without falling back on appeals to the masses, and those in the market for Rails services should do their due dilligence. Measuring the popularity of a practice as a replacement for due diligence is frankly a recipe for failure, and once real investigations have been done, hollow measures of popularity won’t add much.