I started by trying to implement something through MT, but after I had over 400 lines of object oriented PHP in one MT “template,” I realized it wasn’t going to work (though it was a pretty cool snippet).
The new hotness is to build web apps fast with high level frameworks that abstract away most of the database layer. Even Six Apart is using Django to build their new microblogging platform Motion. Since I have no real interest in learning Perl to make MT jump through more hoops than it already is, I decided to use a framework for this new project— specifically Ruby on Rails.
I chose Rails because I really buy into the 37signals ideology (oh, I also have a huge crush on their officemates Coudal Partners, and, um Chicago in general), and love a lot of stuff built in it: Github, Slicehost, Basecamp, etc. The Ruby ethos also kind of clicked with me. It doesn’t take too much to see the difference between a language that could inspire a work like _why’s Poignant Guide to Ruby versus the PHP5 Bible (not to say the latter isn’t an excellent reference).
I think one of the reasons Rails has amassed a cult following is that the software itself has a certain personality. It speaks to you. I haven’t been using it that long, but it has seduced me. Just something like its system of pluralization gives it an opinion that you can’t wiggle out of. Ironically it is this restrictiveness that makes it empowering. It anticipates what you want to do before you do it. Yeah I know I’m late to the game on this, but I find it pretty awesome that Rails knows the baseline of functionality that all database-driven webapps will have without imposing a presentational metaphor on you. And makes it easy.
In this sense, the conceptual leap from working with a blogging platform like MT or WP to using Rails is much more compressed than it seems, while at the same time infinitely expanded.
Here’s what I mean by that: You may think that comparing MT to Rails is apples and oranges, but one is really just a more shielded version of the other. With MT, the database schema is decided for you, so in that sense, the ‘model’ is off limits (outside of very limited access through custom fields). The ‘controller’ is largely off limits too, though you can decide from a limited palette how to present your model. The views are your only playground, and even there, you have a predetermined, pre-anticipated way of accessing the model.
With something like Rails, you can duplicate the ‘blog’ concept easily (with the
scaffold command, absurdly so), but also organize your data however you choose, and access it very easily, almost as if there were (in MT parlance) “template tags” for everything. That’s why there is a certain feeling of liberation in its restrictions, because its restrictions guide you towards what you already want to do, rather than one metaphor of how information should be organized and presented. Because it doesn’t lock you to one presentation metaphor, Rails (though, more generally, the raw MVC idea) is infinitely more powerful than any blog software because there are an infinite number of possible “applications” you can build in it.
Now, I’m not knocking MT. It’s great for setting up a blog or even a network of blogs. But TPM is getting to a certain point where, while we love our blogs, and will continue to carry on blogging, having our primary model (in the database sense of the word) based on the blog metaphor is starting to feel too specialized. It’s one level up from where the base data should be. A “blog” should just be one form of where the data could go. Having the data itself be mixed up in one metaphor for its presentation is a hurdle that will keep getting more and more obstructive the larger an institution grows and the more malleable that data necessarily will need to be. NPR’s digital team came up with a great concept to illustrate this: COPE — Create Once Publish Everywhere.
Separating content from display is one of the key concepts supporting COPE. In the most basic form, this means that the presentation layer needs to be a series of templates that know how to pull in the content from the repository. This enables the presentation layer to care about how the content will look while the content can be display-agnostic, allowing it to appear on a web site, a mobile device, etc.
It’s an interesting exercise to try to envision a “news app” devoid of any presentation layer. At a site like TPM, your first logical step is to define the basic unit of “news” as a post. Though by doing this, you’re already jumping to presentation. Better to think like a version control system, say Git. Git defines a file’s innards as a “blob.” It doesn’t know what you’re storing, and it doesn’t care. This “news blob” could then be a post, an email, a breaking news alert text message, an article, an item in a feed reader, even a podcast. When you put an image or a piece of text into Git, they are both blobs.
Now Rails likes to be a little bit more semantically-kosher than ‘blob,’ but even if you call your basic unit a “story,” a controller can
respond_to any number of formats to view it in. And the database can be migrated at any time to add whatever metadata you’d like, without breaking what you have. If you decide to build a “news app” with MT, even before you open the box, you know you’re going to have to hack it out of its default state. Want a headlines section? Hack it. Email alerts? Hack, etc. etc. With Rails, a Story table could have a columns for
tweet, etc. The philosophy of DRY extends all the way through from the code methodology to the editorial workflow it engenders. When you build a “news app” in rails, you’re building a news app, not a blog that kinda-sorta works for real news distribution.
I’m only just starting this new Rails project, which will be a sort of subsite at TPM backed by an elaborate separate database. A kind of canary down the cave for this approach. At this point I’m kind of punch-drunk on it, but I’ll post some more once I actually know what I’m doing.