Practicalmadness

Years ago — and I don’t recall exactly how this came up in conversation recently, but it did — I was talking to my mom about replacing our refridgerator. I’ve always been a gadget nut, so naturally I wanted one of those fridges that an ice and water dispenser in the front. But my mother explained that while an ice dispenser was certainly a cool feature, she had to think about what would happen if the thing ever broke, and as she saw it the ice dispenser was little more than an extraneous moving part that brought chaos to an otherwise orderly system. These are my words, by the way; her phrasing was about as sophisticated as the fridge we ended up with.

This story more or less sums up how I feel about all-in-one IDEs (integrated development environments) for web development. Sure, it’s convenient to have all your tools in one window, just as it’s nice to be able to get your ice from outside the refridgerator door. But in my experience, there’s always something that makes them more hassle than they’re worth.

That being said, I’m a huge fan of Panic, the awesomely cool Mac software company that makes Transmit, so yesterday when they launched their latest product — Coda, an all-in-one IDE for building web sites — I immediately took notice.

True to form, I’ve already been through at least four versions of this post, each attempting to cover all my thoughts about the product, which until about ten minutes ago could be summed up as follows: “Not as good as TextMate or CSSEdit. Not suitable for Rails projects. Lame.”

What happened ten minutes ago is that I actually started trying to use Coda on a Rails project rather than just staring and getting angry at it for not being TextMate, and I started thinking that using Coda to develop for Rails may not suck as much as I thought it would.

Before I go any further, I feel I should offer a disclaimer: I am not saying that Coda is necessarily well-suited to Rails development, or that the Panic dudes should be at all focused on serving my particular picky development needs.

Based on an admittedly brief experience with the product, while it does appear to be a lot more versatile than you might think, Coda’s killer app is definitely building simple websites (think HTML and single PHP scripts, not so much app frameworks like Rails, Friendly or Django) that get served from a normal document root on a normal webserver. It’s simply amazing for that, and it might be the first web development product to strike a perfect balance between übernerd code editors like BBEdit or TextMate and dumbed-down shite like iWeb or (shudder) Dreamweaver. In particular, all you Dreamweaver users who wish Adobe would just get all the extraneous crap the hell out of your way so you can work will love Coda. (Unless you’re on Windows, in which case yours will be a distant, unrequited love. Just buy a damned Mac already, will ya?)

C’eci N’est Pas Une Website

If there is one thing about Coda that would seem to be at odds with the Rails way of doing things, it’s the site management features. Coda’s workflow, like that of older-school tools like Dreamweaver, is built on the assumption that websites are “published” (i.e., uploaded) to a given folder on your webserver.

For a lot of web projects, that’s not a bad assumption to make. In fact, Coda was able to save me a bunch of time this morning while handling a support call from one of my clients, allowing me to pull up their mostly-PHP site and make a small bug fix live on the server in about half the time my usual TextMate-Transmit setup would have required. And one of Coda’s most interesting features is its ability to track changes to your project as you make them, then publish those changes (i.e., upload the changed files and nothing else) to the server with one click.

I’m sure there are Rails developers out there who (at least sometimes) use (S)FTP rather than Subversion to move code around. But most of my projects are deployed using Capistrano and Subversion, so maintaining a relationship between my local working copy and a remote folder isn’t all that useful for me. Fortunately, unlike Dreamweaver which raises ten kinds of ruckus if you fail to provide valid local and remote site info, Coda doesn’t force you to use its publishing features if you don’t want to, so I’m finding that just leaving the remote root and server information blank when setting up my project in the Sites screen to be the path of least resistance.

Even if you’re not planning to use Coda to deploy your Rails app to the server, the Sites feature can still be extremely useful for one simple reason: Sites are how Coda keeps track of your workspace. For example, you can set up a series of tabs — say, a web browser pointed to your local dev URL, a multi-pane Terminal tab and your routes.rb file — and that tab/split layout will be remembered across sessions, making it quick and easy to get to work.

Unfortunately, while the ability to create and maintain project-specific workspaces is super-nice, less awesome is Coda’s inability to reorder tabs after they’ve been created. It’s hardly the only app one can fault for not offering draggable tabs (neither Safari nor Panic’s own Transmit have them), but it’s one of those things you miss if you’ve grown accustomed to having it. (Of course, there’s always Coda 1.1.)

That being said, people who like to push away all distractions while they’re working may find Coda useful in that department. It may not be half as powerful as TextMate for writing Ruby code, or half as nice as CSSEdit for visually mucking around with stylesheets. But there’s something to be said for having minimal versions of all the tools you need inside a single window you can maximize.

From The Wrong Side of the Tracks

Let’s just get one thing out of the way quick: TextMate users are going to find Coda irritating in a number of ways, and if you (like me) are one of those people who uses TextMate for everything from Ruby to blog posts to julienne fries, it’s entirely possible that you and Coda are just not gonna make it as a couple.

At this point, hitting Cmd-T to find and open a given file within a project is muscle memory for me, and while it’s not exactly hard to (for example) just pop open the config folder in Coda’s file browser and click on environment.rb, it’s still slower than being able to jump directly to the file I need with a few keystrokes.

When you get right down to it, what makes TextMate unique among Mac apps (but not at all unique among text editors) is its abject love and respect for the keyboard. Whereas Coda gives you a pretty iLife-like HUD for inserting “Clips” into a document, TextMate’s “Snippets” are best accessed with a shortcut combo or — even better — a tab trigger. Coda’s UI is far more conventional and Mac-like, which can be maddening for people who don’t want to take a hand off the keyboard just to insert a bit of code.

Coda does at least offer a graphical symbol browser, and in the interest of giving credit where it’s due, I must say Coda’s is way prettier and more intuitive than TextMate’s teeny, text-only drop-down menu.

But unlike TextMate, Coda has no way of jumping to a particular symbol using the keyboard (as you can in TextMate by hitting Cmd-Shift-T). A symbol browser is fine if you have a relatively small set of succinctly-named items, like methods in a RESTful controller. But it’s practically useless when you’ve got dozens (or hundreds) of arcane, repetitive CSS selector names, and I’m way more apt to need some form of symbol navigation there than anywhere else.

At least when it comes to the basic editing features, like completion and tab triggers, we TextMate users do have one escape hatch: Coda’s editing views work just fine with the “Edit in TextMate” command. Of course, your code will come in as a .coda file, requiring you to specify a syntax grammar before you can do anything else, but that (thank god) can be done from the keyboard.

Opening your code up in another app for editing may seem to defeat the purpose of using Coda at all. But as I’ve said, Coda’s value is that it’s more than just an editor, and until TextMate’s project window magically sprouts a web browser, terminal and CSS builder, it’s not a bad compromise.

Speaking of editing, you may already have heard somewhere that Coda’s editing engine is a licensed, slightly modified version of SubEthaEdit, perhaps better known as “that crazy editor with the network sharing feature.” That crazy Bonjour sharing was brought over to Coda, by the way, and I daresay I like the feature even more here than I did in the original.

More to the point, though, it means that Coda supports all the same language grammars SubEthaEdit does, as well as custom language grammars by way of “mode files.” And if you take a peek in ~/Library/Application Support/Coda you’ll find an empty folder called Modes into which (I presume) you can install new modes with just a drag-drop-and-relaunch.

Unfortunately, custom language grammars are just about the only hardcore hacking you’re allowed to do in Coda 1.0. There’s no plugin API, or even AppleScript support. What you see is pretty much what you get, so anyone whose workflow depends on being able to pop open the Bundle Editor or write a Text Factory should go back home to their regular editor, at least for day-to-day stuff.

Terminal Velocity

OMG — multipane terminals. Click here for a full screenshot.

If Coda has just one killer feature that should get any Rails developer excited to at least try it, it’s the built-in terminal. Coda’s terminal feature is ostensibly intended to let you SSH into your webserver to restart Apache or play around with the MySQL console (both examples mentioned on the app’s website). But you can, of course, just use your local command line instead. And whenever you start up a new local terminal while working in one of Coda’s “Sites”, it automatically cds you into your project’s working directory, so you can immediately type in script/console and start playing.

Following on the “no scripting” theme, as far as I can tell there’s no way to customize which shell commands get run right after a terminal tab is opened. So you couldn’t (for example) set it up so that your app starts up on a given port when you open the project, or have it always prelaunch a console instance. So while Coda will remember your tab and split layout across sessions, you’d still have to do a little bit of typing to get your workspace fully set up before you get to hacking.

Anyhow, while an automatic cd /path/to/project is definitely useful, it’s hardly a reason to drop $70+ for a Coda license. Nor is the ability to organize terminal sessions into tabs, something the open-source app iTerm gives you for free.

So where Coda’s terminal integration really gets interesting is its ability to open multiple terminal panes in the same tab via “splits.” You can create a new vertical or horizontal split in any of Coda’s various modes, and you can even mix and match different modes in a single tab. If you wanted, you could have a multipane tab with your Rails app open in a browser pane and the console in a terminal pane right beneath it. Or beside it.

The only restriction is that while you can have as many splits as you want, unfortunately splits can only go in one direction (horizontal or vertical) per tab. If you’ve got two horizontal panes and you go to create a new vertical one, it’ll let you do it, but it’ll turn all of your panes vertical in the process. (I’m hoping this is a quirk or bug that’ll get fixed in a future release.)

Obviously the possibilities are endless, but what I’ve been using splits for so far is to keep all my commonly used terminal stuff (usually one console instance and another that alternates between the MySQL console and a normal shell for running generators) together in one tab. They’re also useful for emulating CSSEdit’s “hybrid” view on my CSS files, with one pane showing the code and another one set to the visual style editor. Oh, and by the way: multiple panes showing the same content always update each other in real time, including web browser views pointed to local files. (Coda does have the ability to automatically refresh remote documents, but I think it only works on projects where the local pathnames and URIs match up — i.e., static/PHP sites, not Rails apps.)

End Of The Line

Ultimately, I know enough to know that any recommendation I give for or against Coda is going to be meaningless to at least some of you. Some people will find that it’s the web development app of their dreams, while others will spend the next few weeks flaming it for not being TextMate/BBEdit/RadRails/[your editor here].

So having taken you through the whole “Coda on Rails” question in exhaustive detail, I’ll just say this: I bought the damned thing. At the moment I’m not actively trying to use it for Rails work — I’m sorry, Panic, but TextMate is just too perfect a tool for that job — but I’ve already found myself coming back to it for stuff like editing a PHP site or a blog template, and I even used its CSS editor to do some color picking on a TextMate project earlier today. I can’t say I’m using it for anything I couldn’t do before Monday using TextMate, Transmit, CSSEdit or iTerm, but for certain tasks its seamless integration and one-window approach is genuinely saving me time.

I’ve resisted the temptation in the preceding paragraphs to make a clumsy sex joke — calling Coda my “girl on the side”, a pretty-but-dumb little starlet I use for cheap, easy PHP action, never really planning to leave my good long-term thing with TextMate.

But I think a more apt (and way less misogynistic) comparison might be between my cell phone and my iPod nano. Both of them play music, sure, and I’d be lying if I said my cell phone wasn’t a perfectly serviceable MP3 player in addition to being a pretty good cell phone. But my iPod is the best music player, so I find myself using it for music even though I’d have more pocket space if I left it at home.

Even if I never write a single line of Ruby code in Coda, I’m still finding it useful for other things. As an editor it’s just serviceable (at least in comparison to the iPod of coding environments), but it’s a pretty good IDE, with an excellent CSS editor and crazy good workspace features. I’m finding it valuable, even if it’s just once or twice a day when I need to do one of the things that it’s good at.

And really, what more could you want from a product?