While computing moves more and more to the cloud, it’s interesting that Ruby web development best practices tend to go in the opposite direction, toward the workstation right in front of you. Running a local web server via ‘script/server’ (or my preferred method of ‘thin start’), hosting gem documentation locally, and using local git branches are all win/win practices because they’re far more efficient, and frankly, let you do some bonehead moves without your co-workers ever having to know.

So maybe deployments should be practiced locally as well. Ezra Z. has announced Engine Yard Express, a VMware image that’s essentially an Engine Yard production slice. The idea is that you run the image via virtualization software on your workstation, so that you can get all the benefits of a virtual server without having to actually connect to one through the Tubes.

Yes, this really rocks. You’ll be able practice deployments on the plane!

So first, you’ll need to buy VMware Fusion for your Mac. I first purchased Parallels over a year ago, but VMware clearly kicks its ass. Clearly. It actually runs Windows without making the rest of your system unusable.

Next, download the image and double-click on it. Before you even realize what happened, you’ll be presented with a ready, fully-functional slice just waiting for you like an obedient dog:

You’ve been pleasantly provided with randomly generated passwords for the root and express users, and you’re even given the IP address it’s chosen.

Let’s create an alias for that address so we don’t have to memorize it. Open up /etc/hosts in your favorite text editor (requires sudo permission) and stick something like this in there:

192.168.233.128 express.local

Now, you should probably just leave your VMware window alone. Instead you’ll want to SSH into the slice as if you were logging into a remote server:

$ ssh express@express.local

Nice! A quick visit to http://express.local:81 gives you your Merb start page.

Now, in your Capistrano scripts, you can use ‘express.local’ as the domain of your servers, and you’ll be able to practice deployments without ever connecting to a remote server. Bom chicka wa waa!

When I first started playing around with Ruby on Rails, one of the things that struck me was how development was done completely locally. Instead of uploading or synchronizing your source code to a remote web server, you simply fired up a Ruby web server process on your local machine, and the development process seemed to flow more smoothly.

In that same vein, documentation for Ruby gems can be annoying to hunt down. You have to go to the gem’s web site, and hope that RDoc exists somewhere. Or, you can navigate to your gem’s local install directory and poke around in there. Too much work, and it could break your flow. Not anymore:

$ gem server

Now, just visit http://localhost:8808, and you’re good to go. That easy!

Also, you may find yourself missing RDoc on updated gems, so make sure to do this when it bothers you:

$ sudo gem rdoc [--all|gem_name]

Now, it would be great if the server just started automatically on boot up, with no need for a command line directive. In Mac OS X Leopard, the preferred way is to use launchd/launchctl, which is about as obvious to the uninitiated as the rules of Cricket. Luckily, there’s Lingon, which wraps all that ugly XML in a nice GUI. Make a new entry that looks like this:

Note the full path to the gem command, which I needed for the launch command to work. And that’s it. Full documentation to all your locally installed gems, available whenever you need them.

Special thanks to Daniel Fischer for the ‘gem server’ tip, and Brandon Beacher for the tip on Lingon.

Here’s a problem: you need to look at a gem’s source code to figure out something, but you need to figure out the path to your gems directory, find the gem in question, and then open it from there. What a pain. Luckily, Dr. Nic has saved the day:

$ sudo gem install find_gem
$ find_gem activerecord

This also comes with the wonderful command ‘edit_gem’. Make sure you have your environment EDITOR variable set in your .bash_login|.bash_profile|.bashrc:

export EDITOR="mate"

$ source .bash_login (or .bash_profile or .bashrc)

Now, “edit_gem activerecord” does what you think it should do. Nice little pieces of functionality like these really make the term “gem” so appropriate. Hat-tip to Graham Ashton for sparking my interest to find a solution.

Tonight, I’ll be doing a Lightning Talk for the Atlanta Ruby Users Group on Thin, a Ruby web server. Below are my slides, accompanied by several resources:

| View | Upload your own

• Thin on GitHub
• Rails Development with Thin
• Using Capistrano with Thin
• Using god with Thin
• Thin and Mongrel Performance Test

Thin is in!

Over on the High Scalability Blog, a writeup on top 10 Facebook App Friends for Sale details that two full-time Rails developers and one full-time DBA have, in three months, built an application that serves 200 requests per second. Yowsers.

Much of the criticism of Ruby/Rails performance woes will simply go away this year, what with Ruby 1.9, JRuby, it’s companion Glassfish, and Thin popping up. Also, Merb, a framework by Rails deployment genius Ezra Z., will likely inspire some performance enhancements to Rails itself.

I’ve always thought that not adopting a development framework just because it doesn’t scale is rather odd. Humans tend to always hold out that irrational hope that yes, some day they’ll be like those famous people on top, even though they’re completely screwing themselves in the present.

Well, lucky you! You’ve stumbled upon this weird, strange corner of the Tubes. A place where the idealism of an elegant open source project meets the stone-cold reality of delivering quality software within tight deadlines to those who line your pockets. No, this is not just another Rails blog. This is a blog about building web software really fast, under ridiculous constraints, with a multitude of crap hurled your way, and finding joy in it. I don’t profess to have found that joy yet, but hopefully, in what should be a long, fulfilling journey, you and I, my dear reader, will. And I won’t ever use that many commas in a single sentence again. Promise.

Luckily, we have some excellent tools at our disposal. You’ve heard of Ruby on Rails, the high-flying web framework that everyone’s been writing about since 2005. It’s got that guy DHH who drops the F-bomb a lot and has a funny Danish accent.

The hippest nerds flock to it, because it’s a damn good way to built web applications. Ruby is, hands down, the nicest language to code in. Rails (and now Merb), were designed from the ground up to make the lives of web developers better. To make us happier. That’s an amazingly progressive goal, hippy-ish really, and it would have been laughed at by those IBM engineers of yore who wore thick-rimmed glasses out of utility and not out of fashion. But I’ll be damned if I ever code in PHP or Java again.

You may have heard of Salesforce.com, the enterprise CRM system used by Fortune 500s to Mom and Pop shops to everyone in between. In the past few years (as Rails has been gaining in popularity), Salesforce has become more than just a CRM (customer relationship management). Dubbed Force.com, it’s become a nearly full-blown web application framework, but not in the same sense as Rails. Using Rails, we build web applications by firing up a text editor and coding in Ruby, HTML, CSS, and some Javascript. Using Force.com, we don’t build applications as much as customize the hell out of an existing one. Much is already built for us, but we then need to use a gaggle of technologies to tweak it just right to fit with our users’ needs.

Ruby on Rails and Force.com have a lot of differences. Rails is open-source, licensed under the MIT License. It’s free as in beer and free as in speech. Force.com is completely proprietary. Your users will have to subscribe in a per seat/per month arrangement. You host (or pay to someone to host) your own Rails apps, while Force.com apps are completely managed by Salesforce.com (the company). Philosophically, Force.com is a true enterprise framework, while the Rails Core team could care less about making it enterprise (and with good reason).

But the two have one striking similarity: they both help web developers build solid applications in ridiculous time. And let me make a bold claim: Force.com completely destroys Rails in development time. It’s not even close. A tool that takes me a day to build using Force.com would take at least a week (and probably two) if I were to use Rails.

I’ll let that sit with you, as I’ve said enough for now. In the coming days and weeks, I’ll be evaluating the pros and cons of each web framework, and sharing what I learn along the way. Neither is perfect, but both are pretty great. While there are many great Rails blogs out there, there is (to my knowledge), only one regularly updated Salesforce development blog, with another newer one. So, I hope to help fill that void. If this all tickles your pickle, consider subscribing to the feed.