Tag Archives: dreamhost

Brent on baked blogs

My post on free apps “was linked from Daring Fireball”:http://daringfireball.net/linked/2011/03/18/manton-app-store a few days ago. Tons of new traffic, but my site didn’t go down. Why? An ancient but reliable version of Movable Type spitting out static files, with just a tiny bit of PHP for “Mint stats”:http://haveamint.com/.

“Brent Simmons talks about this lost art”:http://inessential.com/2011/03/16/a_plea_for_baked_weblogs of publishing to static files instead of serving from a database:

“It’s an old technique, actually, but too rarely practiced. (Lots of weblogs in the ’90s were rendered as files-on-disk. They were built from a database plus templates and scripts and uploaded to a server. We did a bunch of this when I worked with Dave Winer at UserLand Software.)”

I couldn’t agree more with Brent’s advice, and in fact I ran this blog on Radio Userland for its first couple of years. In addition to performance, static files are portable. I can pick up this site and move it anywhere. The old web is fragile, and as web sites age, being able to permanently host them somewhere cheap and stable is going to become a big deal.

I hope a modern equivalent to Movable Type emerges eventually. For now, I’m thankful that the only time I have to worry about a web site outage is when a Dreamhost sysadmin trips over a power cord.

Dreamhost scale

I get a lot of funny looks when I tell people I host everything on Dreamhost. It’s not a great fit for everything — I have some ideas for projects that would be better suited to Amazon EC2, and who knows, maybe I’ve just been on a lucky server — but it has generally been more reliable than any previous hosting company I’ve used, including when I used to run my own server.

Dreamhost succeeds because of scale. They have so many servers, and such low prices, that they are forced to automate everything. This means they can more quickly deploy new software, rebuild servers, or restore a broken installation, and that their panel interface has to provide access to every feature a customer might want.

“This post from their status blog”:http://www.dreamhoststatus.com/2009/07/18/network-problems-due-to-distribution-switch/ is revealing. There are over 600 machines on that list, but it must be only some fraction of their customer base, because my server name isn’t on there. “According to WebHosting.Info”:http://www.webhosting.info/webhosts/reports/total_domains/DREAMHOST.COM, Dreamhost hosts about 875,000 domains.

I strongly believe that “being small is a competitive advantage”:http://www.manton.org/2007/02/customer.html, but anyone who’s played the role of sys admin knows that automation means everything, and that’s what Dreamhost seems to get right.

Rails on shared hosts

“David Heinemeier Hansson writes in detail”:http://www.loudthinking.com/posts/21-the-deal-with-shared-hosts on the problems with Rails in shared hosts:

“Most Rails contributors are not big users of shared hosting and they tend to work on problems or enhancements that’ll benefit their own usage of the framework. You don’t have to have a degree in formal logic to deduce that work to improve life on shared hosting is not exactly a top priority for these people, myself included.”

Although I’ve been building Rails apps for a couple years, and will continue to do so, I made the choice with “Riverfold”:http://www.riverfold.com/ to go PHP-only so that I could deploy on inexpensive shared hosts and easily move my sites. Fact is, you need to dedicate a significant portion of your time to being a system administrator if you run a Rails site.

I find the general “we don’t owe you anything” attitude in the Rails community off-putting. What it means is quite simple: Rails is not a product, despite what it might look like when you “visit the web site”:http://www.rubyonrails.com/. This is fine and consistent with the opinionated nature of Rails (which from a design perspective is what makes Rails excellent), but it also means that features like backwards compatibility are not just ignored but actively discouraged. The message this sends is that the core team values their own personal productivity over the productivity of the general Rails userbase.

Also, make no mistake, the performance questions surrounding Rails are directly related to the web shared host issue. Rails can’t be hosted in the same way that PHP is hosted because it takes so long for a Rails application to be initialized, requiring dedicated long-running app instances and an ever-changing array of “best practice” solutions starting with mod_ruby to FCGI to Mongrel to “Thin”:http://code.macournoyer.com/thin/.

My friends and “co-workers”:http://www.vitalsource.com/ are no doubt sick of me bashing Rails (see “this post on the priorities of the community”:http://www.manton.org/2007/09/rails_and_mac_dev.html), but I still admire Rails and do want to see these problems solved. I would love to use “PotionStore”:http://www.potionfactory.com/potionstore to power the Riverfold site, or to base my registration database and sales tracking in Rails.