Shared Hosting is a Ghetto

I haven't said much in defense of Rails in the past few months, but a recent post on Dreamhost's blog left me irked. Now that I see that the post is still making the rounds, it seems time to respond.

The most popular sound bite from the post:

"The feeling I get from the Rails community is that Rails is being pushed as some sort of high-end application system and that makes it OK to ignore the vast majority of user web environments. You simply cannot ignore the shared hosting users."

Huh. Well, the Java community ignored shared hosting users. The Python community ignored shared hosting users. Basically every development community save Perl and PHP have stayed the hell away from shared hosting. Why? Because shared hosting is a ghetto (please forgive the topical reference).

As a web developer, dealing with shared hosts is a nightmare. Sure, setting up a server from the ground up has historically been a nightmare too, but I'll take that over shared hosting any day. The constraints, the instability, and the unpredictability of a shared hosting environment are a big part of the reason why the web hosting business is moving towards virtualization everywhere you look. Big kids need their own sandboxes to play in.

As a programmer who wants to get paid for my work, making an application that I sell to people who then install it on a shared hosting account doesn't sound like a great way to make a living. If you'll excuse a callous generalization, it's a support nightmare for a down-market customer base. Plus, nobody but nerds (who don't pay for software anyway) install their own web applications anymore. People use hosted services.

Is it any surprise that even big PHP and Perl applications like WordPress and Moveable Type now offer hosted services (WordPress.com and TypePad, respectively)? Hosted services are a better way to make money in the web development business, and Rails is a better fit for such projects. Case in point: everyone bitches that the various Rails blogging applications don't work well on shared hosting accounts, but scores of bloggers are moving over to Rails-based hosted tumblelogging service Tumblr. Update: Commenters have clarified that Tumblr is built in PHP. Hopefully my point remains intact.

My guess is that the Rails community hasn't invested time in supporting shared hosts because it's simply not worth it. Extra work for users, extra work for developers, and where's the value? It sounds like Dreamhost is overselling this problem (much like they oversell capacity).

Positive Security Strides in Rails

At last year's RailsConf Europe in London, I argued that security is a framework-level concern, and a great place for Rails to offer developers sensible, responsible conventions. Reading over the Rails changelog just now, I was thrilled to see some positive momentum in the security arena.

First of all, Rick Olsen's csrf_killer plugin now comes standard in Rails (you can see more work being done on the merge here). Edge Rails users can now decorate their controllers with a call to protect_from_forgery. Forms built "the Rails way" will then be secured with a hidden token. We use a similar pattern for critical actions in Twitter and it's worked out well.

Secondly, the sanitize, strip_tags, and strip_links helper methods are now far more robust. While Rails's previous string sanitization was better than nothing, it let many non-trivial XSS attacks sneak by. This change should ensure that all but the most determined attackers can't pollute your Rails-powered site with sneaky scripts.

Improvements like these go a long way towards improving the default security stance of Rails applications. It's also an example of the rewards of framework usage: you get good stuff for free.

Scaling the Scaling Debate

If you read my blog for web geeky Railsy sorts of things, you might be interested in the post I put up earlier today on the Twitter blog.

A lot of internet time has passed since the oft-referenced interview I did with Josh Kenzer back in March. We've learned a lot since then, but the most important lesson was that we're not building a web application, we're building a communications service for which the web is just another endpoint. Ruby has turned out to be a great language for building a communications service. With some work and coaxing, Rails has scaled up to keep pace with the demands on that service.

It's humbling that enough eyes are on us that bloggers fire up their text editors when I start bookmarking different technologies. Everyone at Twitter has done research, both at work and in their free time, towards the best technologies for our application. Ruby and Rails is the solution we've come back to for all kinds of reasons.

The Rails community is still young, and we've already seen amazing work done on the scaling front. As more Rails sites start pushing heavy traffic, the solutions available are only going to get better. If the community can stay friendly, smart, and agile, the only place to go is up.

My RailsConf Schedule

I'm flying from San Francisco to Portland at 0640 in the bloody morning on Friday, with the aim of being checked in to my hotel and at the conference by sometime during the opening keynote.

Thenceforth, you'll find the schedule of talks I'm attending at MyConfPlan. Supposedly, my colleague from Twitter and I are giving a talk on Sunday at 10:45AM, but as of yet we're not on the schedule. There's no shortage of good sessions, though.

If you'd like to take the pulse of RailsConf via Twitter, check out the visualizer we put together. Most of the photos in the background were taken by Timoni on our trip to Portland earlier this year. It's pretty hypnotic, so use with caution.

We've got dinner plans on Friday night, but nothing set for Saturday. As much as I'd like to stay and hit the breweries, I'm flying back on Sunday evening.

See you in Portland tomorrow!

Where Did That Code Go?

If you were using acts_as_sanitized for (rudimentary) scrubbing of your Rails application's data, you'll now find it at http://actsassanitized.devjavu.com. If you previously had issues or patches with the plugin, please share them there.

If you're looking for the twitter_monitor.rb script that displays your Twitter updates via Growl you'll now find it at http://static.al3x.net/twitter_monitor.rb. Now that Twitterrific does Growl, though, I don't know why you'd use it.

I'm also sharing the code I used to migrate my blog from a custom Rails application to Blogger. You'll find that at http://static.al3x.net/blogger_import.py. It requires SQL Alchemy and some other libraries. Much of the code is ganked from the Blogger API Python developer's guide, but it's got a few tricks that someone might find useful.

Lastly, you'll find my old TextPattern export scripts at http://static.al3x.net/export_moveabletype.php and http://static.al3x.net/txp_update_comment_count.php. I hope you don't need them, though.

If You're Here About Rails Scaling Controversy...

...you might be disappointed. I’ve posted a comment on DHH’s blog post that sums up what I have to say about the matter. That’s all.

My Gems

My participation in the “show us your gems” meme, which I first spotted on Robby on Rails.

abstract (1.0.0)
actionmailer (1.3.1)
actionpack (1.13.1)
actionwebservice (1.2.1)
activerecord (1.15.1)
activesupport (1.4.0)
aws-s3 (0.3.0)
bishop (0.3.0)
builder (2.0.0)
camping (1.5)
capistrano (1.3.1)
captcha (0.1.2)
cgi_multipart_eof_fix (2.0.2)
cheat (1.2.1)
chronic (0.1.6)
daemons (1.0.4)
erubis (2.1.0)
ezcrypto (0.7)
fastri (0.2.1.1)
fastthread (0.6.2)
ferret (0.10.14)
flickr (1.0.0)
gem_plugin (0.2.2)
hoe (1.1.7)
hpricot (0.4.76)
image_science (1.1.0)
json (0.4.2)
libxml-ruby (0.3.8.4)
markaby (0.5)
memcache-client (1.2.0)
merb (0.1.0)
metaid (1.0)
mime-types (1.15)
mocha (0.3.3)
mongrel (1.0)
mongrel_cluster (0.2.1)
mysql (2.7)
needle (1.3.0)
net-sftp (1.1.0)
net-ssh (1.0.10)
postgres (0.7.1)
rails (1.2.1)
railsbench (0.9.1)
rake (0.7.1)
rcov (0.7.0.1)
RedCloth (3.0.4)
redgreen (1.2)
rspec (0.7.5.1)
ruby-debug (0.5.3)
ruby-growl (1.0.1)
ruby-openid (1.1.4)
ruby-yadis (0.3.4)
rubyforge (0.4.0)
RubyInline (3.6.2)
sendfile (0.9.2)
sources (0.0.1)
sqlite (2.0.1)
sqlite3-ruby (1.2.0)
tattle (1.0.1)
termios (0.9.4)
trestle_generator (1.1.7.3)
twitter (0.0.4)
tzinfo (0.3.3)
what_methods (1.0.1)
wirble (0.1.2)
xml-simple (1.0.10)
xmpp4r (0.3)
xmpp4r-simple (0.8.4)
ZenTest (3.4.3)

Attending: RailsConf 2007 in Portland

I just registered for RailsConf 2007 after some internal debate about whether or not to attend.

Ultimately, my decision was, as with SXSWi, a social one. There are tons of interesting people in the Rails community attending that I’ve corresponded with, or read, or used code from. The opportunity to chat, kick around ideas, and buy much-deserved drinks is just too good to pass up.

If you’d like to meet up, please email me, or ping me on the RailsConf 2007 Conference Meetup registry.

I’ll be flying in later in the day on Thursday, attending the sessions from Friday through Sunday, and flying out Monday morning. I’m staying in the nearby DoubleTree, in what I’m told is a fabulous smoking room if you just spray a little air freshener about (yuck).

See you in Portland! (We’re also going to check out Portland next week, so I might see you then, too!)

Updates to Acts As Sanitized Coming

It’s been nice to see that there’s some interest in Acts As Sanitized.

John Nunemaker referred me to the White List plugin by Rick Olsen, which seeks to solve a similar problem but for views, not models. Rick himself then mentioned that the sanitize method passes only a fraction of the test cases that he’s adapted from Rsnake’s XSS Cheat Sheet, something I’m well aware of.

Over the next couple days I’ll be expanding my test cases to encompass the XSS Cheat Sheet. Beyond that, I’ll be providing an enhanced filter along the lines of Rick’s solution. Rick has clearly done the difficult legwork here; the rest is just a matter of approach and implementation details.

Any other feature requests while I’m at it?

Announcing Acts As Sanitized

When I was doing my talk on Rails security at RailsConf Europe I joked about delivering a magical plugin, acts_as_impenetrable, that solved all of your security needs. There’s still no magic bullet for security, but I’d like to contribute a smidge of code that brings us a step closer.

Rails has the ability to mitigate cross-site scripting attacks in the form of its ActionView::Helpers::TextHelpers#sanitize method. This method won’t catch every clever XSS out there, but it sure helps. Sadly, sanitize is unavailable by default from your models and controllers; the expected usage pattern is that you’ll handle sanitization in your view, ex: <%= sanitize(@story.title) %> or <%=h @story.body %>.

I don’t think that’s especially, uh, agile (or whatever). Neither is importing those TextHelpers into your controller and reassigning your models’ various attributes to sanitized versions of themselves before saving. It’s tedious, it’s repetitive, and it opens the door to careless errors. Are you sure that you know every field that gets displayed in your views, even after all those revisions and migrations?

My solution to this is a plugin: acts_as_sanitized. You use it like so:

  class Comment < ActiveRecord::Base
    acts_as_sanitized
  end

That’s it. The plugin figures out which fields in your model are able to be sanitized at application runtime. If you’re not comfortable with that for some strange reason, you can also specify which fields you’d like sanitized. You can even tell it to strip all tags, not just the ones that the sanitize method in Rails handles (script and form). Plus no more monkeying around in your controllers, no more wasteful filtering in your views.

Install like so from the root directory of your Rails app:

  script/plugin install http://code.al3x.net/svn/acts_as_sanitized/

Documentation is included in the README file, and there’s a decent suite of tests included.

There isn’t much to this plugin as it stands, but as XSS attacks become ever-more complicated, I’m hoping that this plugin evolves to detect and combat them. If you see attacks that are sneaking by sanitize and strip_tags, let me know! Bugs and patches are more than welcome.

Rails Deployments For Profit and Fun

I’ve been living, sleeping, eating, and breathing Rails deployment the past couple of weeks. It’s to the point that, once I had a breather from my professional Rails obligations, I found myself building a quick-n-dirty blog engine and doing the whole Nginx + mongrel_cluster + Capistrano deployment on my Slicehost VPS just for fun. Sick.

If I’ve been unavailable previous to this week I assure you that it was with good cause. My clients were running our web application product through focus groups, which was exciting, informative, trying, and totally frustrating all at once. At least I didn’t have to worry about was the stability of our app thanks to the swell guys at Engine Yard. I always arch a skeptical eyebrow at video testimonials and similar pimping, but after working with them over a weekend to make sure we were rock solid, I’d shill for them. There’s hosting in the “put your bits on our machines and we’ll move ‘em” sense, and then there’s the cushy red carpet that Engine Yard rolls out. Worth every penny.

Once that was settled late last week I turned my attentions to my ailing domain. Some of you may have noticed some URL breakage since I moved servers, thankyouverymuch TextPattern/PHP/Apache. Since there aren’t any good hosted blogging services I took this as an opportunity to move my blog to a homebrew Rails application, in the process improving the odds that I’ll never have to look at PHP ever again.

This site is now a minor example of the latest and greatest features of Edge Rails (soon to be Rails 1.2, mostly). If there were any brilliant tricks I’d release the source, but honestly it looks a great deal like restolog thanks to strict adherence to Rails conventions. I’m using a sessionless design and cookie-based authentication to keep things speedy, and the blog is its own admin interface once I’m logged in. I think I’ve spent maybe six hours on it, including development, migration from TextPattern, design, and deployment.

If you’re reading this in a browser, you may have noticed that the site’s design has changed a touch. Same colors, different typography, even more minimal. No offense to Hemingway but that look is everywhere now. I had a good run with it, though, lots of compliments. Hopefully nobody will be too put off by this new design. Or, rather, hopefully there’s not enough to it to put anyone off.

The other thing that desperately needed correcting is my lack of a public code repository. This has been remedied with code.al3x.net, presently running a bleeding-edge version of Collaboa. I’ll be sorting out public svn access once I have anything there that requires pulling more than one or two files, but this should meet the needs of anyone looking for my modified TextPattern -> MT export script or my TextPattern comment count fixer-upper.

The moral of all this is that Rails deployment is addictive. Use it for your work development and everything else will feel kludgey. You’ll be up all hours, wishing you could make a quick change and rake remote:deploy, all hallucinating that James Duncan Davidson is crawling around your ceiling, Trainspotting-style. Don’t let this happen to you.