The Tech Behind Site Week

In his blog post, Greg wrote:

We will step outside of comfort zones and experiment with smaller teams and agile processes. We will make quick decisions. This process will be as much about experimenting with how we work together as it will be about creating something. And most importantly, we hope to emerge with new ideas we can use on our client projects.

My role for Site Week was focused only on the development (back-end coding). On the technology side, we are very familiar with looming deadlines, extra effort, and short turnarounds for last-minute project needs, but nothing quite as fast as what we were up against when we walked into the office on Monday morning. We had to have some type of software to power the new site by Friday afternoon.

Gulp.

Our previous site was made up of static files except for the news section, which was powered by WordPress. The entire site was in a Git repository on Beanstalk and any changes and updates were done manually and then deployed out to the server. This worked well because our site could be easily moved to a new server without a lot of fuss, anyone could work on the site locally without a lot of setup, and the site was very efficient in terms of performance because it was almost completely static. On the downside, it also meant that someone had to wade into the template code for every little change.

Before Site Week even got started, I began discussing the technology side with my Philadelphia cohort Mark Huot. Mark and I discussed how we could use this opportunity to push ourselves a little and try something new. We are both very familiar with the technologies we use for nearly every client project and, honestly, it wouldn’t have been much of challenge to build a basic company website in a week’s time. We agreed that we should branch out and build this new site on a technology we both haven’t used in client work.

I wanted to make sure we had buy-in from both presidents of Happy Cog, Greg Hoy and Greg Storey. At this point I was feeling very passionate about what we needed to do. I sat down and drafted an email to both of them to make the case.

My approach to the technology choice is in keeping with the idea behind the entire exercise: let’s take a risk, do something new and a little crazy, let’s have fun and learn a ton in the process.

I went on to argue that the technologies we currently use for client projects should be off the table completely.

We are already experts in both and building the new site on them would certainly be a safe bet but it wouldn’t mean we’d come out of it having learned something new or expanded our expertise.

Over the course of the long-winded email I laid out the pros and cons of different platforms and CMSes. I had a few requirements:

• The choice had to challenge us and make us feel a little uncomfortable going into Site Week.
• We had to ensure that a CMS or technology we chose would allow us to perfectly deliver our well-structured HTML templates. No inserting junk or extraneous markup allowed. Yes, in 2012, this is still a problem with some systems out there.
• Whatever we built had to be maintainable by us as we continue to iterate on the site after Site Week was over.

What did we decide? We chose Ruby on Rails as the framework on which to build our own custom CMS for the happycog.com website.

We chose Rails because it was an exciting and different type of challenge for us and because Ruby is an elegant and expressive langauge. It fits right in with the Happy Cog approach to design and front-end code. We were very excited about getting to work on a Rails application.

On Tuesday morning of Site Week, after the entire team spent the previous day on a project kick-off workshop full of brainstorming, discussions, sketching, and whiteboarding, Mark and I (the two developers on the project) began to tackle the CMS build. First up was to take the site structure established the day before and start laying out how the app would be structured.

On large easel paper, we listed out the models we’d need for both immediate and future functionality. We discussed the features that we knew we could build before Friday and those that we had to push off to a later time. We even discussed data models for future features just in case they impacted the development work we were doing during Site Week.

We ended up with four or five large pieces of paper stuck to the conference room wall to which we referred throughout the site build as a reminder of what we needed to do. In the busyness and chaos of Site Week, it was nice to look up at the wall and get a reminder of what you’re working towards. After the intial planning, we jumped into Rails and started coding.

(Okay, we actually spent a little time getting our development envioronments set up, reading a bit of documentation, figuring things out, and reading a bit more documentation.

Then we jumped into coding. Oh, look, it’s Wednesday.)

We did experience a few bumps along the way, mostly getting set up for development. Our application uses PostgresSQL for the database and since we hadn’t used it before, it took a little time to get installed and working properly on OS X. Adding to the headaches, we were all running different versions of OS X so once we got it running on Lion, we had to repeat on Snow Leopard.

We also needed to make sure we were all running the same version of Ruby. RVM (Ruby Version Manager) makes it easy to set up multiple versions of Ruby (as virtual environments), ensuring we are all developing on the same version. It also allowed us to match our Ruby version with our host, Heroku. Unfortunately, we’ve been messing around with Ruby since long before RVM gained popularity so we had to uninstall our patched together Ruby to make way for RVM. If you’re nervous about getting up and running on Rails, my best suggestion is to start fresh. It really is easy to do provided you haven’t crippled your system with 10 years of experiments.

If you followed along with Site Week, you already know that we met our one week deadline and successfully launched the new Happy Cog site. Mark and I were able to put together a CMS to power most of the site’s content. We didn’t get everything done we had planned and had to leave some parts of the site as static content in templates. We ran out of time.

Was it a failure? Not at all. All week we discussed and planned different scenarios, flagging features and functionality that we could push until a later time. We didn’t need to make the CMS perfect, we just needed to make it work by Friday. And we did.

Each discipline area had its own challenges and experiences during Site Week, but this is how the development team planned and survived a week hunkered over laptops around a crowded conference room table, coding our first Rails app as a team. We have a lot of work left to do still (there are many outstanding issue tickets filed for bug fixes and feature requests) but we are very happy with what we accomplished. Even more so, we’re glad that we took the chance to try something new with a tight deadline on a much publicized project.

Technology List (for the nerds)

A list of the technology, software, and services we used during Site Week development work:

• Ruby on Rails 3.2.1
• ActiveAdmin gem for the initial admin interface.
• Sublime Text 2
• Heroku for deployment and hosting
• Beanstalk for version control
• RVM for local development environments
• Meet Rails 3 screencasts by PeepCode to get up-to-speed on the changes in Rails 3.

Back to Top