Development Blog: Viget Labs

Patrick Reagan, Development Director, June 27, 2007 3

By now you’ve heard the news that we’re growing our team and branching out into the Durham, NC area.  This is potentially a big challenge for us as we strive to maintain constant communication within our project teams and between staff across our two locations.  While we’re still deciding on whether to use iChat or Skype for our daily Scrum meetings, we’ve settled on Campfire to stay in contact while we’re cranking out functionality for our latest app.

Our initial solution was to use an internal IRC server to keep the development team up-to-date and provide a forum for questions.  We had mixed success with this approach and knew that it wouldn’t work if we tried to roll it out to the rest of the company for a few reasons:

• Geek factor – Sure, we cut our teeth on IRC back in our college dorms, but that’s no reason to force our non-technical employees to /navigate the sea of commands.  If we wanted company-wide adoption, we needed a more user-friendly solution.


• Some assembly required – Since we hosted the IRC server internally, it was firewalled off from anyone outside the office.  This required everyone in the Durham office to connect to the VPN to chat with the rest of us in DC - not fun!


• History – There are ways to log history in IRC and provide a searchable interface, but we’re too busy to bother with setting that up.  We needed something that worked “out of the box” to give joining users insight into what happened throughout the day.

We were skeptical at first, but after a month of constant use Campfire has proven to be a better tool than we initially anticipated:

• Communication has improved – Instead of just the core development team, we now have everyone involved in discussions throughout the day.  Project Managers can alert us of new issues that crop up in production (that we don’t see in our exception notifications) and Developers can get clarification on a proposed feature.


• Cool bots – When they’re not hanging out in the VL “Bot Tub,” our Capistrano and Subversion bots send messages to the team whenever a deployment or commit happens.


• Context included – When people sign in, they can see what has been happening throughout the morning.  This means that a Project Manager can see what features have been implemented and are ready for review on our autobuild site.

I’m increasingly optimistic about our ability to maintain our “offline” culture in this on-line meeting space.  We always strive to keep a good sense of humor even in stressful situations and Campfire has allowed us to maintain the same levity in our daily communication.  Sure, sometimes we have to force some conversations back on track, but we’re able to have fun and get work done at the same time.

Brian Wynne Williams, CEO & Co-Founder, June 22, 2007 2

“Can Ruby on Rails scale when my web traffic takes off like a rocket ship?”

This is a common question we get (or some variation).  I have a simple answer:

“Yes, it can.”

As with any technology or framework, it’s easy to build something that won’t scale.  Furthermore, there are applications where Ruby/Rails isn’t the right solution.  However, we believe that Rails will scale fine if you make smart architecture decisions.  Heavily-used apps like Basecamp and large-scale sites like Revolution Health show this; but, lately people like to talk about Twitter‘s problems.

Silicon Valley-based Powerset just announced that they’re building their front-end in Ruby (though not necessarily Rails).  They addressed the question of scaling and Twitter’s situation with some first-hand insight:

We’re not worried about scaling.
So, inevitably, whenever we talk about Ruby or Rails scaling these days, someone brings up Twitter and its scaling problems in the past. Twitter is right down the block from our offices and I know several of the devs personally, so before we made a final decision I arranged a sit down with Twitter’s lead developer, Blaine Cook, to talk about the situation. Blaine was kind enough to let me bring along our Search Architect (and former search architect at Yahoo!) Chad Walters, our Head of Product Scott Prevost, and our COO Steve Newcomb, to poke and prod and get their questions answered. The simple fact is that Ruby wasn’t the source of Twitter’s woes. As it often happens with rapidly-growing sites, they ran into architectural problems. Some design decisions don’t hurt until they reach a massive scale and, at that point, you have to rethink your approach. In an email he writes:

For us, it’s really about scaling horizontally - to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement; but, thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10,000% faster than it was in January.

---

Twitter’s explosion of growth in March certainly created pain points for them (gotta love slide 7 here) and a lot of lessons learned; but, it’s not an indication that the framework inherently won’t scale.

Our belief is that when building a web app, agility is more important that built-in scalability.  “Premature optimization” causes more problems than it prevents.  Focus on building a site that people will really use, then refactor and optimize over time as your audience grows.  Rails is made for agility.  You always hear about development speed, but test-driven development is easier and faster in Rails as well.  Both factors mean that making architecture improvements to an already-deployed site is more practical.

Regardless of technology, build with scaling in mind, not necessarily built-in.  Friendster didn’t scale, but that seemed to be a management decision.  Had Twitter obsessed about trying to build for the number of users it’s supporting today, they probably never would have made it out of the gates.  And then how would I possibly know that Darth Vader just ate a burrito?

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.

Patrick Reagan, Development Director, June 05, 2007 1

We had a great time at RailsConf this year. Ben’s presentation went well and got a great response from the crowd that attended. I had a chance to chat with some people (both from our local group and elsewhere) about the content of the presentation, and the responses were pretty consistent.

For the developers who had faced the same issue of building a dynamic site with a large amount of static content, the solution met their needs. I ran into a lot of people who had just been creating a single controller (e.g. GeneralController) to handle all the static content for their sites. This approach works for a while, but as the static content grows – which was the case when we built the ACVA site – things quickly become cumbersome.

I also talked with others who were misled by the title and wondered “why would you use Rails to build a static site?” The answer to that is… “you don’t.” If you’re building a truly static site, Apache, Lighttpd, or Tux are your friends and will serve up static files faster than Rails can. In fact, Ben’s solution relies on a front-end web server to serve up the cached pages generated from the static site framework.

So for those that missed out, here’s what the framework allows you to do (implemented as a plugin-app):

• Upload or create content files – In typical CMS CRUD fashion you can add content directly to the ‘pages’ table through a web front-end either using a textarea or a standard file upload control. From there, the content is then immediately available in your application.


• Generate site maps – Because the page content is stored in the database and the Page model uses acts_as_tree, we’re able to traverse from the root and generate a site map for display. This design decision, along with providing modification timestamps, also helps when you need to generate the XML for use with Google Webmaster Tools and other search engines that use this site map standard.


• Provide customized page-specific variables – Again, because of acts_as_tree in the Page model, we can provide a hierarchical inheritance model for page-specific variables. Setting a variable at the parent level makes it available to all the children with the ability for each child to override the parent’s default setting.


• Search for terms in your “static” content – The framework plays well with your current search solution. If you’re using Ferret, Solr, or Hyper Estraier you can search both your existing CRUDified content and your new static content.

If you want to test it out, you can download the plugin and view the slides from the Viget site. In the near future, we’ll be pulling the code into a public SVN repository – stay tuned.