Development Blog: Post

Mark Cornick, Web Developer, April 21, 2008 4

Rails application deployment has gotten a pretty bad rep. Legitimate Rails developers and blog trolls alike have bemoaned the lack of something equivalent to mod_php, which would make Rails applications "just work" when uploaded to a web server, as we got used to doing in the PHP days.

So Passenger made a big splash when it was released this month. It promises to make deployment "a breeze" and says "No Ruby on Rails-specific server configuration [will be] required!" Furthermore, the developers' own benchmarks show it being a little faster than Mongrel.

After a decade-plus in IT, I'm skeptical of hype and twice as skeptical of benchmarks. But even though I've mastered the sometimes-confusing realm of Apache and Mongrel, I'm curious to see just how easy it is to use, and just how fast.

Continue reading "Passenger: Let It Ride?"

Clinton R. Nixon, Senior Developer, April 16, 2008 3

I was incredibly excited to see the announcement of Google App Engine (GAE) recently. I can run web applications on Google’s grid, and have access to their authentication and back-end data store? Sign me right up!

Since it was announced, GAE has taken a lot of heat from pundits. For the most part, they are right, once you cut past the hyperbole. It is exceptionally limited: you cannot run spun-off processes on the server, there are no cron jobs, and the data store, BigTable, is not a relational database. It does threaten to lock in your application: if you use Google authentication, good luck migrating your users, and moving from BigTable to a relational database elsewhere would possibly be tough.

However, limitations can provoke creativity, and enhance applications built for that space. There are a lot of applications you can build without background processes, and if the end-game for your application is not to be bought, having Google’s authentication in place could vastly increase your user registration rate, as most users will not have to sign up for a new account. If you want to make a web application that does an interesting, simple task, GAE may be the best platform around once it gets out of beta.

From a development perspective, the fact that GAE only runs the Python programming language is definitely limiting. It is obvious why it was chosen: Guido van Rossum, the inventor of Python, works at Google, and they needed to limit the Python virtual machine to disable writing to the filesystem or other machine-specific tasks. Google’s announcement that they plan to support other languages, however, excites me. One of Google’s main languages is Java. The Java virtual machine (JVM) is a great piece of software; many languages have been ported to it including Ruby, our favorite here at Viget, and new languages have been written for it, such as Scala, one of my personal favorites. It is fairly trivial to use the JVM to sandbox these languages and limit their abilities to manipulate the machine as Google has done with Python. I expect to see JRuby supported soon, and a flood of languages thereafter. What this means for Rubyists is Google putting resources into developing JRuby, or even Rubinius, if they choose that route for a sandboxed Ruby.

The other exciting part about GAE to me is that they have a software development kit (SDK) to run GAE apps locally. This has already been ported to Amazon’s EC2, allowing you to run GAE apps there. BigTable, Google’s data store, is an interesting concept, and the development community has expressed interest lately in document databases, like CouchDB. With this SDK, we have been given a specification for the interface for BigTable. This is interesting: we may well see competing implementations of this non-relational database come out, allowing GAE apps to use any of them on non-Google machines. This can only result in innovation in database design, something which I have not seen a lot of in the last few years.

Clinton R. Nixon, Senior Developer, March 31, 2008 1

Ruby users are really lucky to have Rubygems. Outside of Perl’s CPAN, I can’t think of an easier distribution system for language-specific libraries. Creating gems for distribution, though, takes a little more knowledge. Creating them by hand is workable, but quickly becomes a chore.

Luckily, there are several tools to help you build your own gems. hoe and newgem are the best-known, and have a lot of good qualities. However, hoe adds itself as a dependency to your gem, and newgem has become a very large tool, one that I find unwieldy when I want to create and deploy a gem quickly.

My favorite tool is Mr Bones by Tim Pease. It’s lightweight, featureful, and does not add dependencies to your project. To create a project with it, you just run bones <my_project_name> on the command line, and a skeleton is built for you, complete with a lib directory for your code, a bin directory for your tools, and a test directory. The configuration is in a Rakefile, and it’s clear and concise. Here’s the configuration for my recent project, a Ruby client for the FriendFeed API:

load 'tasks/setup.rb'

ensure_in_path 'lib'
require 'friend-feed'

task :default => 'test'

PROJ.name = 'friend-feed'
PROJ.authors = 'Clinton R. Nixon'
PROJ.email = 'crnixon@gmail.com'
PROJ.url = 'friend-feed.rubyforge.org'
PROJ.rubyforge_name = 'friend-feed'
PROJ.dependencies = ['json']
PROJ.version = FriendFeed::VERSION
PROJ.exclude = %w(.git pkg)

Mr Bones has the standard set of features you’d expect: you can use it to package up gems and tarfiles of your library, as well as release it on RubyForge and deploy your documentation there. Its killer feature, though, is its ability to freeze its skeleton in your home directory. When you run bones --freeze, a directory named .mrbones is copied into your home directory. You can edit the files in there to make a skeleton for your gems that works the way you work, and from then on, when you run bones to create a new gem, it will use your personal gem skeleton. You can unfreeze Mr Bones by running bones --unfreeze and your skeleton will be backed up, and the default skeleton will be used again.

For a tool to create RubyGems that focuses on usability, I highly recommend Mr Bones. If you know of another tool we should check out, let us know in the comments!

Mark Cornick, Web Developer, March 21, 2008 2

Since I installed the Safari 3.1 update the other day, I repeatedly ran into a weird problem: the “Accept cookies” preference is being mysteriously reset to “Never.” This isn’t a tech support forum (and I’m sure “just use Firefox” would be a popular response if it were); rather, I’m here to talk about what happens when I try to use Safari after this bug crops up.

Just about every significant web application uses cookies. Despite the paranoia that accompanied their introduction over a decade ago, cookies are an essential part of the modern web application’s diet. One of the most common uses of a cookie is to persist an authentication state. For instance, when I log in to an application, it’ll send a cookie with a key like “user_authentication” and some value. As long as this cookie gets sent back with each subsequent HTTP request, we know the user’s authenticated. It’s a common pattern, and one that works very well 99% of the time.

That other 1%? That’s what’s happened to me since this Safari bug cropped up. If cookies aren’t enabled in a user’s browser, authentication doesn’t work. The application never gets the cookie it expects to receive, and so assumes the user isn’t logged in. So what does your application do in this case? How does it recover?

A well-behaved application would detect that it’s missing the desired cookie, and present some sort of helpful error message. Gmail, for instance, redirects you to a page stating that Gmail requires cookies, and the user should check the browser’s preferences to make sure cookies are enabled. You don’t get where you want to go, but at least you’re not in the dark.

Then there are the not-so-well-behaved applications. Twitter, for instance, doesn’t provide any useful feedback to indicate that it’s missing its authentication cookie. It just kicks you back to the same login page, without the courtesy of telling you what’s going on. (This is how I discovered there was something going on with my Safari. I tried logging in, which failed. I tried again. Still no dice. It wasn’t until I tried Gmail that I got the clue.)

So, fellow web developer… what does your application do in this case? Try authenticating with cookies turned off. Do you inform the user of the problem, or do you leave the user in the dark? I’m sorry to say that at least one of my applications left the user in the dark. (Consider my wrist slapped.)

It’s very easy for web developers to take cookies for granted. We rely on the built-in session persistence in frameworks like Rails, which invariably depend, in some way, on cookies. We expect that users will have cookies enabled; that expectation is probably valid in most cases. But when it’s not, we need to keep the users’ experience positive by helping them understand what’s going on. Otherwise, you’ve got frustrated users who can’t understand why they can’t get to their previously-favorite application—and it’s all downhill from there.

Ben Scofield, Development Director, February 06, 2008 3

A couple of years ago, DHH‘s fifteen-minute blog screencast introduced Rails to the world. This wonder was accomplished in no small part because of Rails’ scaffolding - code and markup generated by the framework to handle the most common tasks.

Since that debut, scaffolding in Rails has changed substantially. Dynamic scaffolding (where the generated code lived in memory instead of on the file system), for instance, was pulled out of the core framework a year ago, while static scaffolding (where actual files are created) was updated to reflect the RESTful principles that the community as a whole has been moving towards. Even while the core team made these changes, however, a tension over the goals of scaffolding has emerged.

Cross-Purposes

So what are these goals? Well, on one side, there’s the production-ready faction. These people want scaffolding to resemble Django‘s admin interface, where it’s ready to support a live site out of the box. When they are (inevitably) let down, they opt for or create alternatives like Streamlined and ActiveScaffold.

On the other side, you’ve got the educational faction. Proponents of this want scaffolding to teach new developers best practices for writing Rails code. They’re apt to be big fans of documentation and tutorials, as well, and to be the right people to turn to if you want to know the why of something - like why RESTful controllers have seven actions.

As it turns out, production-ready code, even when it follows best practices, is often not the best way to learn those practices. The problem is that the best practices the educational faction wants to instill underdetermine production code - any application capable of supporting a live site is likely to optimize things, move things around, and in general obscure much of its implementation of best practices behind structures that make it better at supporting a live site (and often easier to maintain).

A Modest Proposal

Given all that, here’s a suggestion: separate the two goals. Abandon the idea that scaffolding can or should be both useful and educational, and rip out everything that detracts from one or the other purpose. My suggestion (for what it’s worth) is to ensure that scaffolded code is in fact production-ready, and is solid for the basic case.

This doesn’t mean that we completely abandon the educational aspect, however. Instead, we should create a sample application expressly tailored to helping new Rails developers learn how best to write their code. It could be distributed via gem or plugin (with a generator or as a resourceful plugin), but it should be separate from Rails core, and easy to find and install.

In the end, clarifying a single purpose for scaffolding will better serve both factions, and the community as a whole.

(photo from joelogon on Flickr)