Development Blog: Viget Labs

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)

Brian Wynne Williams, CEO & Co-Founder, October 17, 2007 1

Alex Iskold has a great post on Read/WriteWeb about The Future of Software Development. He does a good job of quickly summarizing the evolution of software development, and why older methods don’t work. In my view, his post title is misleading—he’s really describing the current state of software development for web applications.

Our work with start-ups over the years has pushed us to apply agile methods because requirements change constantly in an evolving business. As we meet new clients, we often go through a similar description of the way software development practices have improved over the years. Some key points from Alex:

The Old: Waterfall Model

“The idea was to construct systems by first gathering requirements, then doing the design, then implementing it, then testing, and finally getting it out the door in one linear sequence.”

“We have come a long way since then and learned a lot about making software. The Waterfall Model is now considered a flawed method because it is so rigid and unrealistic. In the real world, software projects have ill-defined and constantly evolving requirements, making it impossible to think everything through at once. Instead, the best software today is created and evolved using agile methods. These techniques allow engineers to continuously re-align software with business and customer needs.”

The New: Agile

“First, software has to embrace change. Today’s assumptions and requirements may change tomorrow, and software needs to respond to changes quickly. To meet the challenge, agile approaches advocate focusing on simplicity. Make the simplest possible system that satisfies today’s requirements and when tomorrow comes, be ready to adapt.

“The software systems created using agile methods are much more successful because they are evolved and adapted to the problem. Like living organisms, these systems are continuously reshaped to fit the dynamic landscape of changing requirements.”

Small Teams

“With a bit of discipline and a ton of passion, high quality engineers are able to put together systems of great complexity on their own ... ust a handful of great engineers can now successfully build systems of great complexity. Craftsmanship has finally come to software engineering!”

Alex also explains refactoring and testing, practices we apply here at Viget.

Agile isn’t perfect, particularly in a consulting environment, and I would stress lean teams over small team (though they’re often both). The future of software as Alex describes it is here now, and the best web products being built today apply these methods effectively.

Patrick Reagan, Development Director, September 22, 2007 0

On Friday, Ben and I returned to Falls Church after a week-long trip to Berlin for the 2nd annual European Rails Conference.  Berlin was a lot of fun and the conference was a blast – again, the folks from both Ruby Central and O’Reilly Media organized another great event.  Thanks to FiveRuns and their Try and Fly contest, we were fortunate enough to attend.

After experiencing a packed schedule in Portland, we knew that this time around we had to get out and enjoy some local German culture (and beer).  We started our adventure off with the excellent Bratwurst on Rails event held at Kalkscheune and hosted by the Berlin Ruby User Group with support from ELC Technologies and O’Reilly.  It was great to see some familiar faces and connect with new people from around Europe at the event.  In the following days we visited some chilling historical spots, checked out some local cuisine, and tried our best at becoming Berliners – all while being painfully aware of how bad our German was.

Despite all our extracurricular activities, I was able to catch up on some aspects of Rails development at the conference:

• RSpec – Dan, David, and Aslak did a great job providing a history of Behaviour-Driven Development and demonstrating how to use the RSpec framework to exercise BDD in Ruby.  I had seen David give a live demo of RSpec at LSRC the week before, but the 4-hour tutorial format at RailsConf really helped fill in some of the missing pieces.


• Rails 2.0 – Though I missed David’s keynote (it wasn’t me, it was the Pilsner!), he announced the upcoming release of Rails 2.0 in the coming months in addition to some new features since 1.2.3.  While it was good to finally hear that 2.0 is on the horizon, we’ve actually been ahead of the curve now that we’re building our greenfield apps against the current “edge” release.


• Capistrano – Though our deployments have made use of Capistrano 2.0 for quite some time (thanks, Mark), I was able to pick up some new tips from the useful recipes that Ferdinand discussed.  Selfishly, the highlight for me was when he mentioned his affinity for Mark’s RSync deployment strategy that he’s been using for a majority of his deployments – it’s always great to see people in the community benefiting from our open-source efforts.


• Metaprogramming – Fresh off his RejectConf performance in Portland, Dr. Nic discussed some great metaprogramming techniques in Ruby and demo’ed his Magic Model Generator plugin as well as some controversial uses of metaprogramming.


• Amazon Web Services – Johnathan’s talk again reminded me that I need to start looking more into the EC2 and S3 platforms that Amazon offers to anyone who needs quick access to additional computing or storage needs.  The availability of AWS along with the RightScale platform promises to make multi-server scaling less painful.


• Selenium – Till Vollmer (of MindMeister) got me thinking about using Selenium (on Rails) again for automated UI testing.  The MindMeister application has some pretty complicated AJAX functionality, and he was able to clearly demonstrate the benefit of using Selenium on an application with such a complex user interface.


• (A) Presenter Pattern – I had never heard Jay Fields speak at a conference before, but I do follow his blog and thought this would be a good talk to attend.  I had seen Marcel discuss his presenter pattern in January at the Rails Edge conference and I was interested in seeing how Jay’s implementation differed.  After his 15 minute talk, and at his own urging, Jay’s “solution” is not something that we will pursue.

Due to a scheduling issue, one of the sessions was transformed in to an hour-long lightning talk session.  At Chad’s request, Ben was able to give a quick demonstration of Sandstone, his new CMS plugin, to a responsive crowd.  This format is always a big hit with the attendees, so it was nice to see it happen again at the European conference.

From what I can remember, my experience in Berlin was a great one.  Thanks again to the guys from AutoScout, Rails for All, and FiveRuns for the beers, food, and good times.

Patrick Reagan, Development Director, July 19, 2007 0

As promised, here are the slides from last night’s talk:

Since the code in the presentation is taken somewhat out of context, I’m including the full code sample as well.

Even though it ended in a tie, it may not be as bad as “kissing your sister”. Both are great libraries that provide functionality that was never possible for us when writing PHP code.  Choosing the right one is a matter of personal preference – right now, our preference is Mocha.

Kevin McFadden, Former Staffer, June 18, 2007 1

Switch from PHP to Ruby on Rails? Check!
Switch from Windows to OS X? Check!
Switch from Vim to TextMate? Check! Well, most of the time.

Vim is useful in many situations, particularly for quick edits (especially as root), and editing files on a remote server. One annoyance I've had during my nine months with a Mac Book Pro is cursor keys in Vim ringing the bell in both insert or command mode instead of changing lines. Upgrading to version 7 via MacPorts yielded the same results. The cursor keys worked after switching my TERM to VT220 from rxvt! The downside was syntax highlighting stopped working.

Luckily, adding VT220 to my Google search parameters turned up a reference to vt100-cursor-keys in the Vim documentation. Add the following code to your .vimrc file to fix the problem:

:set notimeout          " don't timeout on mappings
:set ttimeout           " do timeout on terminal key codes
:set timeoutlen=100     " timeout after 100 msec

But, this only works on your computer since the settings do not propagate when you ssh to another server. A better solution is to change the default value for TERM to either linux or dtterm since the TERM value will be picked up on the remote server. In this day and age, I would bet most servers support both these terminal types.

The easiest way to set this value across all terminal instances is to update /etc/bashrc and restart the terminal session. OS X already has the framework for you to support this change, just add the export line as listed below.

case "$TERM" in
xterm*|rxvt*)
    export TERM=linux # ADD THIS LINE!
    PROMPT_COMMAND='echo -ne "�33]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}�07"'
    ;;
*)
    ;;
esac

This will cause terminal instances reporting itself as rxvt or xterm to use linux instead.

Let me know if you find instances where this does not work or know why Apple decided to default to a TERM that restricts normal functionality.