monkinetic weblog | redmonk.net

Phusion, via Akita on rails:

Well, as you’ve stated, we believe that experienced Ruby on Rails developers don’t consider deployment to be a problem; probably annoying at most. They’ve automated/standardized the deployment process for a great deal with Capistrano scripts. Newcomers however see deployment as an insurmountable problem. Consequently, we end up having a situation in which the people who can solve the problem either don’t see a problem or aren’t motivated enough to fix the problem, while the people who do see the problem cannot solve it.

Furthermore, from our personal experiences, newcomers usually want to see immediate results. It’s very demotivating for those people to continue using Ruby on Rails if they have to manage tons of obscure configurations and clusters to ‘just successfully deploy an application’. This leads to very intelligent conclusions, such as that “Ruby on Rails sucks”.

This is exactly what killed my nascent interest in ruby-on-the-web. I continue to love ruby-as-intelligent-shell-script. I may have to give ruby-on-the-web another go.

Just wanted to follow up my post of the other day with a comment I just posted over on The B List.

Just as Dreamhost offers a one-click install of Wordpress, I could see it offering one-click installation of an application on a pre-installed/configured framework system. If the process of uploading/configuring a module or theme can be made easy for the end-user/developer, then I think there’s hope.

Tim Bray has a ongoing (ha) series of predictions for 2008, generated as a response to this request from Sun.

Recently, Tim posted Problems With PHP, which left me thinking and ambivalent, and found me composing this response in my head at midnight.

PHP - Easy but Ugly

Tim says:

Yes, … • It’s enabled huge numbers of people to create decent Web sites without having to learn too much or try too hard; a very good thing. Also, it runs pretty fast. Plus, it’s been used to build some of the most instructive and useful apps out there, like MediaWiki and WordPress.

PHP has huge adoption among ISPs and shared hosting providers for this very fact. People can create “dynamic” (remember when that meant “my site has a form!”) websites very easily with little work on the provider’s part.

This, in my opinion, has been the secret to WordPress’s success as well. Your average user, with just enough FTP experience to hang themselves and a helpful provider, can get WordPress up and running in about 15 minutes (10 to request the db and 5 to install WordPress). Adding plugins requires only a minute to download one and ftp it up to the site, and a minute to enable it in the admin.

… and No • On the other hand, speaking as an actual computer programmer, I really dislike PHP. I find it ugly and un-modular and there’s something about it that encourages people to write horrible code. We’re talking serious maintainability pain.

No argument from me. PHP ain’t pretty. And it’s isn’t particularly easy to write re-usable code, PEAR notwithstanding.

But, I keep coming back to the fact that PHP is so dang easy to work in. And reload-on-refresh (see below) means that changes get reflected immediately, making hacking really really fast. WordPress is pretty easy to extend, it has a ton of useful hooks for plugin developers to hang interesting stuff off on — and they have!

Meanwhile…

The other language I’ve really taken a shine to is Ruby. Not Rails so much, which I still find to be too full of magic for comfort. As an old-skool web guy I still prefer seeing some metal from time to time. But I really really enjoy Ruby for shell-scripting tasks - I’ve written several file validators at work and I can whip them out and re-iterate, adding features and such quite quickly. Ruby took just enough from Perl to make it fun (it had me at var =~ /re/). I’ve even branched out into small web apps using camping, but I confess to even a slight bit of unease at the behind-the-scenes shenanigans it plays.

Now, as great as Ruby-the-language is, I don’t see anyone writing an app like WordPress in Ruby, and I don’t see it getting the adoption that PHP has for a while, if ever. Why? Well, for the reasons I outlined above.

1) PHP’s greatest ugliness is also its greatest strength: You can mix PHP and HTML right in the same file, and most users do. It’s awful from visual and maintenance viewpoints. BUT you can point any recent Apache at that .php file and it will spit out pretty much whatever HTML you told it to. It’s stinkin’ simple.

With the possible exception of the ill-fated mod_ruby, I don’t know of a common way to do the same with Ruby. You have ERB for PHP/ASP-style code delimiters, but even ERB is typically used with an app framework of sorts (see the next point).

2) Reload-on-refresh: Hit reload on your browser window showing that aforementioned .php file, and it will re-run the script. Any changes you’ve made will be reflected in the page. Now this has all kinds of scalability issues, I know, and there are ways around it. But the default is reload-on-refresh, and many apps - including WordPress - work great this way.

Again, with the exception of the defunct mod_ruby, the way to put Ruby on the web is via Rails, or to a much lesser extend, camping. Both make use of persistent applications, which means that to load new code the application has to be restarted, which also usually means killing a FastCGI process via a shell command or automated build/deploy process. [*Update #1]

While perfectly acceptable for applications with no user extensibility (BaseCamp, HighRise, Twitter, etc.), apps like WordPress are expected to be modified by non-highly-technical users via templates, plugins, etc. and they’re not all going to have shell access or the knowledge of the command-line necessary to keep a persistent app running, or reload it when needed.

3) Persistent apps are unloved by shared hosting providers: Dreamhost, my hosting provider, is an awesome host. They even provide Ruby and Rails pre-installed on their servers. But getting a persistent app up and running while avoiding the memory-and-process hunter killer bots is really frustrating.

Outro

Well, there’s more I could say that would not necessarily add any clarity to my points. Perhaps I can end with a request.

My Ruby knowledge is limited, I’ll confess. I’ve written some Rails code, but got frustrated trying to find a place to host it and gave up on the whole Rails thing. Some of what I’ve described in this post may be wrong, and I hope those of you who know better will set me straight gently. But what I want to know is:

Could an app like WordPress, easy for users of medium technical knowledge to run and customize, easy for developers to extend, and easy for hosts to provide, be written in Ruby? If so, how?

For the DiSo project, Chris and I decided to start with WordPress because it had all the attributes I’ve described. We want to branch our into Ruby at some point, and I consider this discussion to be extremely important to that process.

Update #1: Tim pinged to remind me - idiot! - that Rails will happily reload code while in dev mode. Sorry for the oversight.

Update #2: Weird, I wonder if the Dreamhost guys saw my post, or if they saw Tim’s post, or if it was just a massive coincidence.

Now that’s how it’s supposed too work.

I posted oh… (looks) 1 hour ago about my frustration with Buildr at giving us RDocs instead of documentation, and Assaf responds in Patience, Buildr docs coming up:

I agree. RDocs are not acceptable documentations.

RDocs are reference material, information you need after you know what you’re looking for, and just need to quickly find it.

Except an official Buildr announcement later this week that will include usable documentation. One you can actually learn from. Hopefully, one you’ll enjoy reading from.

I’m looking forward to it, Assaf, and thanks for the response!

This is pathetic.

Tim Bray pointed to a new build tool called Buildr. It’s written in Ruby, and provides an easy-to-write DSL for declaring rules. But the only documentation is the rdoc. There are no examples and no “Getting Started” info that I can find in the docs.

Aaah, a Google search finds the introductory blog post, which Tim did point to and which is slightly useful. At least the authors point to some rake files you can learn from. At the very least, the rdoc Readme (which the home page redirects to) should have pointed here.

I know, it’s a beta, it’s brand new and the developers could not wait to put it out there for their friends to oooh and aaah over. But if you really want us to try it out point us to something more than the rdocs (and this means you too, Tim, “Buildr” should link to something actually useful). This reminds me of the bad old days when all Java code just shipped with the JavaDocs and that was “enough”. The API is not the documentation, folks. It’s a useful part of the documentation, but it’s not enough.

It absolutely gets me hot under the collar when I go to read about some new code and all I get is the API doc. Treat us with respect, people. Take the time to give us a good introduction (this was a start at least), an FAQ, a variety of example apps or code samples, and THEN a pointer to the API docs.

Rdoc has its place, but that place is not your project’s home page.

GRUMBLE GRUMBLE

UPDATE: this plazes2kml.rb now has it’s own page

Chris Messina had a cool idea to map his plazes history onto Google Earth, but needed some programming help. So I whipped up a quick ruby script (GPL and MIT licensed) that can be run to grab the data and output it as KML. It runs from the command line, or from within TextMate with cmd-r.

Find it in my svn repo at: http://redmonk.net/websvn/listing.php?repname=plazes2kml

From the usage:

Usage: ruby plazes2kml.rb [options]
plazes2kml downloads your Plazes history and converts 
    it into a Google Earth KML file
    --username USERNAME          your developer key
    --dev-key DEVELOPER_KEY      your username
    --password PASSWORD          your password
    --user-key USER_KEY          your userkey
    --limit[=LIMIT]              How many results to return
    --from-date[=FROMDATE]       Start date for results
    --to-date[=TODATE]           End date for results
    --output[=OUTPUT]            Output to file
    --kill-dups[=y]              Kill duplicate plazes
-h, --help                       Show this help message.