Development Blog: Viget Labs

If you’re a developer paying attention to recent trends, it’s hard to ignore the recent surge of interest in distributed software configuration management (SCM). Many of us are familiar with “client-server” SCM systems like Subversion or CVS. Distributed SCM systems work more like peer-to-peer networks. Each developer maintains a separate, full-fledged repository. Revisions can be shared with other developers by pushing them to, or pulling them from, other repositories. You can work independently of any centralized repository (especially nice if you’re not connected to a network.) If a public repository is available for your favorite open-source project, but you haven’t gained commit rights, you can still make your own changes, track them in your own repository, and contribute patches back to the project.

Git is a distributed SCM system that has attracted a lot of attention recently. Git was written by Linus Torvalds for revision control on the Linux kernel source code, and has since been adopted by a number of projects. Several of us here at Viget Labs have tried Git recently and had much success. It’s not the only distributed SCM out there, but it’s one that we like enough to adopt for some of our work.

If you’re using an up-to-date Linux/BSD distribution or an OS X packaging system such as MacPorts, you likely have a Git package available to install - look for a package called “git” or “git-core”. If not, the Git source compiles and installs easily (unless you’re on Windows, which requires some effort we won’t get into here). From there, the Git tutorial and Everyday GIT will help get you started. For those of us who are used to Subversion, there is a Crash Course which helps you learn the Git commands corresponding to your familiar Subversion operations. (There’s even a git-svn conduit to allow you to keep a Git repository in sync with a Subversion repository, effectively allowing you to use Git as a frontend for Subversion.)

Since each developer’s working copy is a bona fide Git repository, there are multiple possibilities for working with Git. In a larger team setting, you might actually prefer an approach similar to client-server systems, where you maintain one “master” repository which each developer pulls from and pushes to. For a small team (say, two or three developers) it may be effective to have each developer pull changes from, and push changes to, each of the others directly. And if you’re a solo developer, then one Git repository on your development machine is likely all you need.

Git works well with other tools you may have in your toolbox. Git support in Rails’ code generators was recently added to edge. A Git bundle for TextMate is under way. Capistrano supports Git starting with the most recent release (2.1.0.) And if you’re using Viget’s rsync strategy for Capistrano, we’ve just updated it to work with Git. You can expect to see more support for Git in other tools as it gains popularity.

If distributed SCM interests you, give Git a try. It’s easy to get started, and quite powerful once you get the hang of it.

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)