Development Blog: Post

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)

This past Wednesday (Jan 23rd), Patrick and I headed down to Durham, NC to attend and take part in the January meeting of Refresh the Triangle. This month’s “Refresh” was hosted at Bronto’s beautiful office space in downtown Durham.

This Refresh we wanted to try out a new and different form of presentation known as “Lightning Talks,” brief ten-minute talks in quick succession. Wayne Sutton kicked things off with his talk about using Twitter to drive traffic to your site, as well as some creative ideas on how to have fun within the growing Twitter community.

Our own Patrick Reagan showed us how we can clean up HTML mark-up within our Ruby/Rails projects using Haml. The crowd was all “oohs and ahhs” as Pat used his Keynote wizardry to transform messy mark-up into beautiful Haml code right before our very eyes!

Josh Vickery took us through the often intimidating world of the Gimp, with the unique perspective of a hacker in need of the occasional web graphic. This was especially appreciated by us developers who lack the expertise of our designer brothers and sisters, but who still require the occasional simple image for our projects.

Another Viget original, Peyton Crump, gave us a designer’s perspective on using and implementing the Google Maps API. Additionally, Peyton provided everyone with a large array of resources and links for everything concerning Google Maps API, making his presentation an invaluable resource in and of itself for both designers and developers interested in creating Google Maps mash-ups, maplets, and so forth.

Finally, Julia Kulla-Mader shared her enthusiasm and vast knowledge of the open-source PHP-based CMS Drupal. Julia is a contributor to the Drupal project and was very keen on expressing some of the reasons that make Drupal such a popular CMS in both personal and professional web markets.

All this information and knowledge-sharing took place over the span of 90 minutes. The meeting was followed by a few beers and friendly conversation down at Tyler’s bar, which shares the same magnificent red-brick building as Bronto’s office.

The January Refresh saw a mix of designers and developers coming together and sharing some of the technologies that we’re really passionate about. While we’re still settling into the rapid cadence of our lightning talks, we’re also really coming into our own at the Refresh the Triangle meetings. If you are a developer, designer, or just simply interested in technology and its rapidly-shifting trends, I encourage you to check out a Refresh meeting. You’ll get an opportunity to expand your knowledge on design and development topics, as well as get to know the cream-of-the-crop talent in your local area.

Over the past few months, I’ve been talking here and there about a project I’ve been working on - Sandstone. The general idea is that, while Rails makes it easy to build an application quickly, it’s unreasonably difficult to integrate two distinct Rails projects - but if you have an e-commerce site, you may have a need for static content that doesn’t justify the effort of running an entirely distinct Rails application like Radiant CMS. Sandstone meets this need by providing a drop-in, customizable CMS as a plugin, ready to be installed on any given Rails application.

There are a couple of really interesting things about this project. The first is that it’s an instance of what we at Viget are calling “resourceful plugins” - that is, plugins that provide a complete set of resources and functionality around them in a specific domain. These plugins are intended to be easy to integrate into any existing Rails application, and to allow for extensive modification and customization without losing the ability to upgrade the core plugin code.

That last bit is especially important, since that’s where a lot of alternatives fall down - sure, there are plugins out there that add CMS functionality, but once you invest the time in customizing them to your particular project you’re wed to the particular version you installed. If a new version comes out with some compelling features, you have to do a lot of work to upgrade. With a resourceful plugin, upgrades are relatively painless. When you install Sandstone, for instance, it copies a series of controllers, models, and views into your app folder so you can tweak them to your heart’s desire. The bulk of the core functionality, however, resides in modules defined in the plugin (which are included in the copied files). To upgrade, then, you just update the plugin and leave the copied files alone. The only problems you’ll run into are ones where the new version of the plugin adds some significant new functionality (with new controllers, models, and views), but we have a strategy for dealing with that easily, too.

The other aspect of the Sandstone project (and our other resourceful plugins) that excites me is the fact that we’re open sourcing it. If you’re interested, you can grab the current version of Sandstone (so new it doesn’t even have a version number!) from http://svn.extendviget.com/lab/trunk/plugins/sandstone/. If you’d like to contribute, we have Trac set up, so you can open bugs and feature requests and otherwise participate in the process. We’re hoping that Sandstone can help meet the needs of a lot of developers, so we welcome your feedback.

image taken by Ozyman; from http://www.flickr.com/photos/ozyman/211749949/

In 2007, we took a big risk on technology – after 6+ years of honing our PHP skills, we officially began switching all our new custom development efforts to Ruby on Rails.  Now that the new year is upon us, I can safely say that we’ve reaped rewards from the switch.  Though ramping up the development team (myself included) on a new technology was difficult at times, we were definitely ahead of the curve.  We had already standardized on a custom-developed MVC framework for all new client projects (we used an early version to help power one of the larger applications we’ve built) and had been doing doing Test-Driven Development for almost a year prior to the switch. 

Though we had a good basis from which to start, we didn’t go it alone.  Between formal training for the development team and our involvement with various Ruby communities, we’ve made tremendous strides in the past year.  For us, last year was our chance to both hone our technical skills and showcase our talents to a larger audience.

New Technology and Tools

Our choice of technology in 2007 gave us the ability to use a more advanced suite of tools to manage our client applications.  These are some of the highlights:

• The switch to Rails – The framework that Rails provides has made our lives as developers much easier, and has given us the opportunity to work with Ruby every day.  We are now able to concentrate more on the business logic of our applications and no longer have to write framework code (except in those rare cases when we need to patch Rails)


• Repeatable deployment process – Consistent, repeatable deployments had always eluded us when we were launching our PHP applications.  We were able to automate parts of it and even took a stab at creating an internal tool to get our applications out to production, but we never quite found an acceptable solution.  With the introduction of Capistrano and some custom deployment recipes, we’re now able to quickly deploy critical updates to our clients’ sites.


• Continuous Integration – While having a well-written suite of automated unit tests allows us to quickly discover when we’ve introduced defects in the code, running CruiseControl.rb tightens the feedback loop and allows us to get back on track quickly.  We receive immediate notifications in Campfire when the build is broken or if we dip below 98% code coverage (with help from this plugin).

Community Involvement

While we had always focused on technology, it had never been a priority of ours to engage with the wider development community.  In our interactions with other Ruby developers, we were pleasantly surprised to find an intelligent, vibrant group centered around Ruby and Rails, something that we had missed out on in the past. 

We found ourselves both learning from the community and contributing our experience wherever we could:

• Commitment to Open-source – Our initial release of Tyrant paved the way for other code assets (plugins and gems) that we have released to the public.  In addition to our own projects, we’ve also submitted patches to other open-source projects including Rails, GeoKit, and Tinder.


• Attending major industry conferences – The DC PHP Conference in late 2006 marked our first attendance at an industry-related conference.  Since then, we’ve realized the importance of attending conferences to stay informed on current technology trends and to network with other developers.  Out of the 7 conferences we attended last year, our experiences at The Rails Edge, RailsConf, RailsConf Europe (thanks, FiveRuns!), and RubyConf stand out as being the best.


• Presenting at events – Rather than just ease into our involvement in the community, we decided to get out there and share our experience and expertise as well.  Last year, we presented at RailsConf, CVREG, NoVaRUG, Ruby Hoedown, TriPUG, LoneStar Ruby Conference, Rails to Italy, Raleigh.rb, RubyConf, and Refresh the Triangle.  We plan to continue doing speaking engagements again in 2008 – introduce yourself if you see us out and about.
• Writing – Outside of our normal blogging activities, we found time to write and contribute to 2 technical books that are due for publication in 2008.

The Result?

Our strategy for 2007 represents a huge shift in the technology we use, and the impression that we’re making on the web community as a whole.  Because of this strategy, we’ve been able to attract top talent, build bigger, better applications, and generate more interest in what we’re doing here at Viget.  In just a year, we’ve gone from being a development shop that no one has heard about, to getting name recognition at many of the events that we attend – local, national, and even international. 

I’d like to thank both the development team (Ben, Clinton, Kyle, Mark, and Megan) and everyone at Viget for making 2007 a great year.  As we continue to focus efforts on recruiting, I am confident that we’re building a great team of talented developers for this year (Justin will be joining us this month) and beyond – I’m already looking forward to what else the Viget team will accomplish together in 2008.

• Search
• Category
• Month
• RSS