The design team here at Viget Labs has been using Adobe Labs’ kuler since shortly after its release as a technology preview/beta in 2006, and we frequently reference it for color inspiration. Two features that distinguish it from other color tools are:

1.) It’s web-hosted and available through a free stand-alone app or Adobe’s CS3 software. According to the Adobe Labs Web site, “kuler is the first web-hosted application from Adobe Labs designed both to stand alone and to complement Adobe® Creative Suite® software. Built using Adobe® Flash® and ActionScript 3.0, kuler is all about color: color for exploration, inspiration, experimentation, and sharing.”

2.) The kuler community. Having a great tool doesn’t guarantee you’ll create that perfect combo with it. It’s satisfying and extremely useful to see what other users are creating, plug in to what’s most popular, and save your own custom library of color combinations.

Designers and non-designers alike will find kuler to be helpful, inspiring, and engaging. If you haven’t already, be sure to check it out.

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.

A few of us are heading down to the TECH cocktail event in DC tomorrow evening, and I thought I’d spread the word about it to encourage others to join us.  What is TECH cocktail?

TECH cocktail is a series of mixer events opened to bloggers, technology enthusiasts, entrepreneurs and other business professionals interested in the technology arena in underserved technology communities.  

It’s free, goes from 6:30 - 9:00 pm, and will be held at MCCXXII on Connecticut Ave.

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.

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.

Doug Fuller and the Art Directors Club of Metropolitan Washington did a nice job pulling off the WorldWideWebWashington (WWWW) Conference yesterday down at the Omni Hotel in DC. It was a packed schedule so I won’t attempt to provide a complete recap; but, here are a few things I found interesting:

Caroline Litte, CEO of Washingtonpost.Newsweek Interactive, described three objectives for washingtonpost.com:

1. Foster conversation on the site. Example: they now have 75+ blogs and allow comments on every article on the site.
2. Foster conversation off the site. She likened the web site to a big party and pointed out that, while they want lots of activity there, they aren’t building a walled garden.
3. Utilize multimedia effectively. She noted that many Post reporters have low-end video cameras now, and they use them to enhance their stories when published online. She believes that Gene Weingarten’s recent story about world-renowned violinist Josh Bell being ignored by morning commuters would never have been so huge had the 35-second video clip not been on the site, noting that actually seeing people walk by while hearing the music made the story that much more powerful.

Read the rest of this entry »

In two weeks, Pat and I will be in scenic Portland for Railsconf, where we’re looking forward to meeting really smart people doing cool things with Ruby on Rails. From the schedule, there’re going to be a lot of good ideas being talked about, and we’re excited to have the opportunity to add to that with my talk about some of the work we’ve been doing here at Viget with static sites.

To help make sure that people get something useful from the talk, we’re informally opening up the Q&A (or at least the Q part) a little early. If you have any questions about using Rails to build or maintain a mostly static site, feel free to ask them in the comments here, and I’ll try to address them during the session.

Just as a reminder, the talk will cover a range of topics around Rails and static sites - reasons both for and against using Rails, several iterations of the mini-framework we’re using at Viget for static sites, and ways to make that mini-framework more useful in various contexts.

So, fire away!

PS If you’re interested in chatting with Pat or me (we’re nice guys, and we’re hiring Rails developers…), you can check out our anticipated schedules at MyConfPlan: Pat, Ben

Thanny and I will be checking out the Art Directors Club of Metropolitan Washington’s  WorldWideWebWashington Conference in DC on Monday.  If you’ll be there and want to track us down, email me at blog [at] viget [dot] com … or just come say hello.