Development Blog: Viget Labs

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.

Patrick Reagan, Development Director, May 20, 2007 6

Things have been pretty fast-paced at RailsConf, so I’m just now getting around to talking about DHH’s keynote.  After talking a bit about the popularity of Rails since last year’s conference in Chicago, he gave a quick run-down of the top 9 new features that will be part of Rails 2.0.  Some of this will look pretty familiar if you’ve been following development on edge:

1. Breakpoints – After a Ruby bugfix, the breakpointer in Rails stopped working.  Rails 2.0 adds this back in with the ‘debugger’ keyword added to your controller action (previously, you could use ‘breakpoint’).  Similar to the old breakpoint functionality, the debugger will drop you into an IRb console so that you can inspect local variables.  In addition to inspection, you can now traverse the stack, print backtraces, and go back and forth between an IRb session.


2. HTTP Performance – The performance of a web application suffers as included JavaScript and stylesheets increase in number since they too must be downloaded.  Rails solves this problem by modifying the helpers so that these files are compressed for transfer and cached on the client:
   

   <%= javascript_include_tag :all, :cache => true %>
   
   
   <%= stylesheet_link_tag :all, :cache => true %>
   
   
   

   Due to the way that browsers operate, they will only make a limited number of connections to a single host when downloading assets referenced on a page.  The new use of dynamic asset servers will allow browsers to make more simultaneous downloads from the same host.  This is accomplished with a simple configuration change:

   config.action_controller.asset_host = 'assets%d.example.com'

   The sweet spot is cycling between 4 hosts to serve up all your assets; you’ll have to add the approprate CNAME records to match the configuration.

3. Query Cache – Rails is now smart enough to re-use data that it has previously retrieved from the database.  When ActiveRecord sees a query for data that it has already loaded, it will hit the cache instead of re-querying the database.  Since this happens at the application layer, you don’t have to worry about the byte sensitivity of the MySQL query cache.  You also don’t have to worry about expiring the cache since it gets invalidated each time a change is made to the database (e.g. on insert, update, or delete)
4. ActionTemplate Renderer – There are new conventions for templates that give greater detail about what each template will render.  Views now use the new .erb suffix and indicate their type as part of the template name (e.g. index.html.erb).  The same applies with XML files that are created with Builder (e.g. index.rss.builder).
5. Environment Configuration – As your environment configuration gets complicated, it becomes more useful to break up the configuration into separate files. Rails will now make this easier and allow you to share your more generalized configurations with your other applications.
6. Sexy Migrations – The migration DSL is getting a facelift and things are getting swapped around.  Where we used to have this:

   create_table :users do |t|
   t.column :first_name, :string, :null => false
   t.column :last_name, :string, :null => false
   t.column :account_id, :integer
   t.column :description, :text
   t.column :created_at, :datetime
   t.column :updated_at, :datetime
   end
   

   
   We now have this:

   create_table :users do |t|
   
   
   t.integer :account_id
   
   
   t.string :first_name, :last_name, :null => false
   
   
   t.text :description
   
   
   t.timestamps
   
   
   end
   
   
   

7. HTTP Authentication – While HTTP authentication isn’t attractive in HTML-based applications, it’s very useful for services that consume data.  This works great for authentication-aware applications like feed-readers.
8. The MIT Assumption – Due to licensing confusion for people using plugins, the new plugin generator now creates a license file by default.  The assumption is that you are distributing under the MIT license otherwise you have to modify the file to meet your needs.
9. Spring Cleaning – In addition to deprecating some features, non-core components like the in-place editing macros have been pulled out into plugins. This is also where you can find useful tools like resource_feeder and open_id_authentication.

If you want to check out some of these features (not everything is out there right now), grab the latest code from SVN or use piston to freeze your application against edge.

Patrick Reagan, Development Director, May 10, 2007 4

As Mark mentioned in his latest post, most of our previous applications have been built with PHP (including Squidoo).  Despite all our years of collective PHP experience, we made the decision to switch new development to Rails less than a year ago.  In that time, we’ve hosted a training session, attended a conference, connected with other developers in the community, and even had one of our top developers selected to speak at this year’s RailsConf. 

Admittedly, the switch wasn’t altogether painless; but, as I look back on the past 7 months and how far we’ve come, I’ve made notes about everything that Rails provides that has made our lives easier.  This isn’t an exhaustive list (what did you expect?); but, it does cover the top 5 from across the Development Lab here at Viget:

1. ActiveRecord – Obviously a critical component of the Rails framework and something that the PHP world still seems to be lacking.  It’s clear which ORM library you’ll use when developing in Rails; but, there isn’t a clear choice when developing in PHP.  While the myriad PHP frameworks provide a multitude of choices, nothing is as developer-friendly as ActiveRecord.
2. Test::Unit – Though we were new to Rails, we had been using Test-driven development practices even in our PHP applications.  The framework that we developed in house pulled in SimpleTest to handle all our model and controller tests; but, the integration wasn’t as nice as we would have liked.  With Test::Unit and its integration into Rails, writing and running tests became both easier and faster.  Through the use of fixtures and database transactions, we no longer felt the pain of writing mundane (and sometimes complex) set up and teardown methods for managing our test data.
3. Mocking Libraries – When working in PHP, we found ourselves changing the behavior of our classes just to make them easier to test.  Though SimpleTest did provide mocking capabilities, libraries like Mocha and FlexMock, combined with the power of Ruby, let us mock out method calls deep inside our code – something that just wasn’t possible for us before the switch.
4. Filters – I recently found myself maintaining an existing PHP application where I needed to add some complex permissions checking.  While the task took quite a while, it would have been easily solved in Rails through the use of filters.  The ability to remove duplication with before filters and clean up exception handling with around filters has been a huge productivity boost for us.
5. Ruby – Last on the list – but it’s truly the cornerstone of the framework.  We did have some of the hurdles involved with learning a new language; but, the time we spent ramping up has been well worth it.  The syntax of Ruby is much more elegant and consistent – something that PHP has been sorely lacking for a long time (I hear it’s coming in PHP 6).

As we continue to push for using Rails for web application development, I feel confident that we’re giving our clients the best solution possible while decreasing the time it takes to bring their products to market.

Mark Cornick, Web Developer, May 09, 2007 0

One of the biggest selling points about Ruby on Rails is that it favors “convention over configuration.” By following certain well-documented conventions in development, you can eliminate the need for all but the most fundamental configuration in your application. This appeals to developers who tire of the endless, often repetitive configuration tasks required by other languages and frameworks.

Not surprisingly, this is also one of the most controversial features of Rails, especially among people who are used to doing things differently. It’s possible to use Rails without sticking to its conventions; but, it’s neither easy, nor fun. For those developers who have mastered the endless, repetitive configuration style, Rails’ approach is limiting at best, and completely incompatible at worst.

This reflects one of the key struggles in modern society:  how to simultaneously leverage and break free of convention. Everyone’s heard admonishments against re-inventing the wheel; at the same time, we are encouraged to transcend the status quo. If you stick entirely to convention, you don’t evolve; if you consistently ignore convention, you may find yourself extinct. Balance can be hard to find.

At Viget Labs, we’re embracing Ruby on Rails. In doing so, we’re having to find our own balance. Collectively, we have decades of development experience, but most of it is not with Rails given its short history. Much of our previous work was done in PHP, a language without much in the way of convention compared to Rails. Like many other organizations that work in PHP, Java, or other platforms, Viget created its own conventions—an application framework, numerous libraries, and other specific solutions.

Viget Labs is growing. We’re hiring all types of talented people, including developers. We need to expand our staff to maintain our growth; more importantly, we need people who are ready to go now. We’ve got work to do, and we want our people to get a smooth, quick start. We don’t want them bogged down having to learn proprietary methods that they’ll have never seen before.

This is where Ruby on Rails is a big win. As we continue to let go of our old ideas and do things “the Rails way,” we make it much easier for a new developer to join our team and jump right onto a project. There’s no need for a new developer to spend days or weeks learning our proprietary framework. Our new developers will already know Rails, so they’ll just need to be oriented to our environment and to the few things we do differently (because there will always be things that are unique about Viget).

This is, in fact, exactly how things worked when I joined Viget earlier this year. After about a day and a half of orientation, paperwork, and other overhead, I jumped into my first project. When that project launched, I moved smoothly to my next project, and so on. I didn’t have to spend a week or two reading up on Viget’s proprietary libraries or frameworks; just a few pair sessions with my fellow developers were enough to give me the lay of the land. My prior knowledge of Rails got me going quickly.

At Viget Labs, we don’t want you to think of us as “conventional.” Conventional web shops are a dime a dozen: we’re better than that. But that doesn’t mean we can’t use convention to our advantage. By choosing to work within the conventions of Ruby on Rails instead of going our own way, we’re eliminating barriers to growth and quality. And that means more satisfaction all around, from our team members to our customers.

Brian Wynne Williams, CEO & Co-Founder, March 06, 2007 0

ComputerWorld listed The Top Five Technologies You Need to Know About in ‘07 last Friday and Ruby on Rails topped the list (congrats, 37Signals).  As they put it:

Equal parts design philosophy and development environment, Rails offers developers a few key code-level advantages when constructing database-backed Web applications. One of the central tenets emphasizes using less code for application development by avoiding redundancy and following Rails conventions. This means increased performance and, ideally, decreased development times.

We agree.  We evaluated Rails for awhile (with some prodding from Ben); ramped up the whole team through training, events, hiring, and internal work; and now focus most of our new development projects on the Rails framework.  In addition to working on some large sites, we’ve recently launched a couple of smaller ones (example: funside.com) and found that even though Rails was designed more for web apps than mostly-static-content sites, it still offers advantages over a traditional LAMP (as in PHP) solution.  Hence Ben‘s talk coming up at RailsConf this year: Building and Working with Static Sites in Ruby on Rails.

With Rails, we’re able to provide better solutions to our clients faster.  We also create a more enjoyable work environment for us.  As ComputerWorld notes:

Chances are you’ve heard the term Ruby on Rails—probably from someone on your Web development team lobbying heavily to use it for some or all of your company’s Web development.

Developers love Rails because it lets them focus less on the repetitive mindless grunt work of web development and more on the elegant problem-solving part of it.  But, that’s another blog post altogether ...