Here in Orlando I've been doing my part to put together our own BarCamp event. Jason Hawkins and I threw this video together to let people know what BarCamp is:

View on YouTube

BarCamp's are happening all over the world these days, and I highly recommend attending one if you get a chance. To find one in your area, check out the official BarCamp website.

If you're going to be anywhere near Orlando September 23rd, come on out -- It will be a great (and educational) time. Both Jason and I will be there (more than likely speaking) and Rails Envy will be one of the sponsors of the event. "But Gregg," you may be saying to yourself, "Why would a blog sponsor an event? Isn't that something that a company would do?" Right you are! That brings me to the news: Rails Envy will be incorporating very soon and we'll be available for hire for your Rails projects. Stay tuned.

After I posted my "Why Ruby on Rails?" presentation last March, I had several people email me asking how I do business in an "Agile" format. I still eventually want to create my own formula for successful business relationships in an Agile world, but until then I thought I would post a project story (and still dispense some advice). This will walk you through one of Rails Envy's projects from start to finish.

First Contact - 7 - Rails Envy Information and

First Contact - 7 - Rails Envy Information and

Two months ago I was contacted by John Bennett, who runs Free Layouts.com. He sent me an email simply asking if we had availability to work with him to redo Free Layouts.com in Ruby on Rails, from PHP. I let him know that we are always open to new projects, told him our hourly rate, and asked to schedule a conference call with him.

The Conference Call

We talked over the phone and took good notes as he gave me a brief overview of his project. I then told him more about my company and gave him a brief overview of how we run our projects (see below). I ended the call asking him to send me any and all documentation/notes he has on the website, and let him know I'd get him a proposal by the next day.

The Proposal

I love Writeboard for putting together project proposals.

Writeboards allow both the client and I to make changes to a document until we're both happy with it. The proposals I put together have four parts:

1. Functionality - A list in plain english which describes all features of a system and how it works. This can obviously get long, but I try to keep things organized. Even if the client sends me a list of what they want, I always end up rewriting it in better english, so that the descriptions would be crystal clear to any programmer.
2. Hour Estimates - What I believe each of these features should take to get finished. In this section I always state: "Please keep in mind that these are all estimates, which mean we only charge you for the time that we actually end up using on the task. They include time to fully test the system, and work with you to add any small tweaks you want."
3. Total Cost - The total cost based on the estimated hourly rate, with a reminder that we only will charge for the hours we use.
4. Getting Started - Here I give the client a pathway to get started with our company. I believe in doing things in phases, so here I pick 2 or 3 of the main features and call it Phase 1. To get started with Phase 1 (and their project), I ask for half the estimated cost of all the tasks in phase 1. I usually try to keep this to between 80-100 hours (2 weeks of work).

Asking for a small cost to get started lowers the risk for both the client and me, and it gives us both a trial session to gain trust.

Getting Started

John was ready to move forward with Free Layouts.com, so I let him know we could get started as soon as we received his first payment. I can't emphasize this next sentence enough: Never start work on a project until you receive some sort of payment.

John promptly sent payment and once received I emailed him a receipt and started coding his project. The key to successful projects (for several reasons) is communication, so here is we ran his project (and how I try to run most products):

1. Monday Conference Call - Once a week John and I talked on the phone about the project. We went over what happened the previous week, any comments/tweaks he had, and I set some goals for the current week. No long term goals, just "here is what I think we can accomplish this week".
2. Wednesday / Friday Status Emails - Twice a week I would send out status emails to John. These would include a detailed list of all the work done on his project (which he could immediately try on the dev server), as well as how many hours were used on the project (Member System X / 40 hours).
3. Constant Request for Feedback - I always encourage my clients to give as much feedback as possible. If requests for changes were small enough to fit in the initial contract I just did them. If the request for change was bigger, I would email John back letting him know it would take X hours to do the work, and ask for the green light.

I don't feel comfortable ever spending more hours on a project then the client has pre-approved. Thus, even small tweaks need to get approved if they lie outside the scope of the initial project estimates.

Leading up to Deployment

Recently I got smart and started putting down hours in my project proposals for "Server setup, configuration, and optimization". For John's project this was 24 hours, and I used all of this time. What did this consist of?

1. Server Setup - Setting up Subversion (with svn_dav), Trac, and Apache/Mongrel on RailsMachine. I cannot count the ways I love RailsMachine for my clients websites. They may cost a little extra, but they're worth every penny.
   
   
2. Caching / Optimization - One of John's concerns was the speed of Rails since his website gets over 20,000 unique visitors a day. I planned on doing some caching, but before diving in I decided to run some Benchmarks. I downloaded the Benchmarking with Httperf Peepcode, learned how to do benchmarking, and jumped right in.
   
   I ran httperf on a few of the main pages, and averaged about 28 requests / second (that's 2.4 million hits a day). For comparison, I ran httperf on his old PHP server, and I got about 26 requests / second. w00t, my rails version was faster! I realized that the website was already fast enough for what John needed without much caching, but I still decided to page cache the front page just to be safe. With Page Caching in place the front page went from 28 requests / second to 1100 requests / second or 95 million hits a day (that's 1/3 the population of the United States). Page caching rocks!
3. Pushing the site live - Last Wednesday we disabled the logins on the old PHP site, migrated the data/files, and then pointed the DNS at the new rails server (this way the average user didn't see any downtime). There were a few small errors as people came over to use the new site, but since I was using Exception Notifier plugin, I was emailed the errors as they occurred on the live server and fixed them within minutes.

Migrating the data from the old site probably took the most dev time here. I put together a rake task that would automatically load the legacy data into the new database schema, transfer all the old file uploads, unzip all the file uploads for the live previews, transfer images locally and generate thumbnails, and finally upload user files to Amazon s3.

The site has been running smoothly since last Wednesday, and John's pretty happy with the work we've done on the project. His site is probably the highest traffic rails website I've ever created from scratch. If you like the look of it, do me a favor and Digg It.