If you are working with Merlin API data inside a Ruby or Rails application, be sure to try the library.

If you are building a Ruby or Rails application and need to work with IDology data, have a look at the ruby-idology library.

In late December 2007, a project I've been working on for the past few months was released to the public. The company I've been working with, ID Watchdog (IDW), needed a better way to process signups for their identity theft prevention service.

Enter the new signup system.

Working with IDW's design team, I built the new signup system and added several handy features. As signup systems go, this one was pretty complex. Most signup systems take care of the basics - gather the customer information, collect a payment, and send the customer on to the application. IDW needed something a bit more complex.

When it comes to people's identity, security has to be the top priority. So when asking for a potential customer's information in order to monitor their identity, the application must make sure the customer is indeed who they say they are. If you were to signup for an IDW service, you would be asked questions to verify your identity. Questions that someone who is trying to impersonate you would not know.

This screening system is part of what I developed for this project. There are also a few other behind-the-scenes extras that were developed to keep customer information secure. I should note that I worked with a great team of Rails developers on this project, though most of what I am describing here is specific to my direct involvement with the project.

The other members of the team developed several internal applications for IDW to use along with the new signup system. These applications interface with an existing CRM system and also give IDW control over the identity monitoring process for each customer.

So what about the Rails-specific parts of this project? There were actually several problems that were a fun challenge.

First, we wanted to encrypt all customer information in the database (we used PostgreSQL on this project). This was important for PCI compliance and I would argue it's common sense when it comes to storing identity information. Using the Sentry plugin and OpenSSL I generated a very secure public / private keypair that is used to encrypt all data in the database. If you ever need to encrypt data with Rails, not just hash data (which is not nearly as secure), Sentry is the best tool out there.

There were also several third party APIs that had to be integrated with this project. IDology and Merlin are two services that deal with personal information. Unfortunately, neither service had a Ruby library available to interface with their API. We needed a solid interface for these two services, so I spent some time with the documentation for each. I made use of rspec and hpricot and developed two great libraries for communicating with IDology and Merlin. I'm working on getting each released as a gem or plugin. Get in touch with me if you are interested.

I was also in charge of the infrastructure for this project. Without revealing too much sensitive information, I worked with a hosting company and setup a multiple machine platform for secure deployments via VPN. I made heavy use of Capistrano, and the site runs on Apache, Mongrel, and PostgreSQL.

It was great to launch this project in December. IDW actually wanted to hold off until we had a few more features implemented, but our team was able to convince them that releasing early and often with short iterations is a better approach. If we had waited until everything was finished, the project would be well into March before anything was released. Needless to say, there is much to do, and I am looking forward to working with IDW for the next few months as we add features and make their service even better.

NationwideSpeakers.com contacted me about maintenance for their existing site. It had been developed using Rails way back when Rails was in version 0.9 or so. My immediate task was to add some new features, but not long after getting access to the code, I realized the site needed a major upgrade.

With Rails 2.0 just around the corner, it was time to upgrade the application from pre-1.0 Rails coding standards.

After talking with Nationwide and explaining that an upgrade was badly needed, I brought another developer to the team and we started digging through the Rails application line-by-line looking for old, broken, or deprecated code. It took us about a week to get everything converted.

One major issue we discovered during the upgrade was that the older Rails code was using file-based storage for session data. That had caused over 3 million files to build up on the server, and needless to say, it was starting to impact performance. We moved session storage to the database and added some housekeeping scripts to cleanup old sessions.

During the conversion, while prepping the server for deployment with Capistrano, I realized that Nationwidespeakers.com was not running any backups on the production data or source code. I used the upgrade opportunity to ensure that production databases are backed up nightly to a secure off-site server. I also moved the Subversion source code repository to a secure hosted service, separate from the main application server. When it comes to backups, my rule is not to put all the important data on one server.

After a few weeks of work, the upgraded NationwideSpeakers.com site was deployed successfully.

So while most of what I do involves creating new applications, I will occasionally take on projects that are more maintenance-related. NationwideSpeakers.com is a perfect example of what my team and I can do for your existing Rails application.

Give me a call at 719.966.4313 if you would like to talk about your existing Rails application.

No doubt half the people in the audience are spacing out and dreaming about the iPhone release tomorrow...

Here are the slides.

I told my former client that they need to find someone passionate about what they do. Right now, if you are involved in the Rails community, you are more than likely passionate about what you do. And if you do freelance work like I do, that passion matters.

I would much rather hire someone who is passionate about design or development than a "scripter" or "coder" who punches the clock and is content using what Microsoft or Sun give them. When I hire other developers to work on projects with me, I look for passion. The same goes for designers.

My former client was posting their Rails development jobs on Monster and a few other mainstream job sites, and was surprised that all they got in response were form letters from code sweat-shops in India or Romania. I told my client to look at sites like jobs.rubynow.com, the 37signals job boards, and other sites that attract the readership of passionate developers.

I'm not sure they liked what I had to say, but it needed to be said. I also told them that having a good developer - someone who understands Rails - interview prospective developers is key. Interviews are always difficult, interviewing a prospective developer is even more difficult, and having a non-technial person - who does not understand Rails - interview someone for a very technical position is a recipe for disaster.

Also, if you are hiring a Rails developer and they are using Windows, you had better start looking elsewhere soon. It all comes back to passion. Passion for the tools used to develop web applications. Ruby on Rails is a tool. The Mac and OS X are tools. They happen to be the best tools out there right now to develop web applications. If you are hiring a Rails developer, you need to find someone who has passion for their tools, who lives and breathes their work. That is the type of person you want to hire.

I'll stop before I descend into much more of a rant. Hopefully you understand at least part of my passion. I'm available for work. Get in touch with me - give me a call at 719.966.4313 - if you are looking for someone who is passionate about Rails and their work.

RailsConf 2007 was great. It was bigger than last year's event, by about 1000 attendees. The event felt bigger, and seemed to have less of a community feel to it. Last year, when all the attendees were in the same hotel, everyone gathered at the bar and discussed Rails-related issues, hacked away on projects, or played 8-way Mario Kart on the DS Lite. This year was missing some of that, but it was still good.

By far the best event at RailsConf 2007 was the RejectConf - held at the Portland Free Geek building. Free Geek is a pretty cool service to the community. I would like to see more of them around the country. RejectConf was a gong-show style event, where anyone could present their idea, as long as you agreed to leave if you were booed off the stage. I don't think anyone got booed this year (the Microsoft representative did last year), and I got to see some amazing presentations. People presented their plugins, gems, projects, and ideas to a packed room. The most interesting project I saw presented was Rubinius. I had heard about it at last year's RubyConf, but did not know how far it had progressed since then.

In addition to RejectConf, there were a few presentations during the conference tracks that are worth mentioning. Tom Preston did a great job talking about his FixtureScenarios plugin. I love test driven development, so fixtures are important to my development process. They have some issues in the current version of Rails, and Tom's plugin does a great job of making them more flexible. Another presentation worth attending was the Twitter guys talking about scaling their Rails application. Twitter is arguably the biggest Rails app out there right now, and they are having some issues scaling. What I found interesting is that Rails allows Twitter to focus on the 'real' scaling issues, not the mundane stuff. In other words, Rails does scale by taking care of the mundane, and lets Twitter deal with real problems of scaling - issues that any technology would have on a site as big as Twitter.

The issue of Twitter and scaling ties into the third great presentation I attended - Jason Hoffman of Joyent. Jason presented all of the concrete numbers and costs associated with building a large-scale Rails appclication. I get a lot of prospective clients who like to ask "will my app scale?" To me, this question is a "shark-attack" question. Sure, you could get attacked by a shark if you go swimming in the ocean, but you should probably worry about other things first, like rip-tides, water temperature, etc. If you ask me this question, I will usually respond with numbers. It's hard to argue with concrete numbers, and that's what the Joyent presentation did a good job with. If Twitter is getting 11,000 requests per second at peak, they need roughly 32 cores to handle the traffic. Is your app going to be getting 11,000 requests per second? How about 1000?

All told, RailsConf 2007 was great. Portland was great, especially Stumptown Coffee. I wish I could attend RailsConf Europe in Berlin, but it looks like I will have to pass this year. It was great to meet a bunch of new people, pretty much all of whom were doing some type of Rails freelance work. The Rails market is strong, and is only going to get better. I have a feeling that RailsConf 2008 will be upwards of 2500 people.

There's not much I can say about SportRPM in terms of the business, and unfortunately, most of the best work is behind the wall of NDAs and passwords.

What I can say is that working with a small team of Rails experts - including Toby Sterrett at 120db.com - we were able to build a killer Rails application using the latest features in Rails. I was inspired by David's talk at RailsConf 2006, and decided that building the new SportRPM application using REST principals would be the best way to approach the project.

It worked out great. We developed using Edge Rails and were able to launch the application right around the time Rails 1.2 was delivered. The timing was great. We were ahead of the curve and able to take advantage of some of the new Rails 1.2 features such as 'map.resources' from day one. I am convinced that by using REST we were able to keep a very complex project manageable. By sticking with conventions, we were able to keep the code simple and easy to manage. The best part of using REST principals was that SportRPM got a free API with their application, something they can use in the future to monitor and interact with their application.

We also decided to use Engine Yard for hosting and in the process discovered a great service. A site like SportRPM.com, which frequently experiences a large number of transactions in a short period of time, cannot have any downtime. The guys at Engine Yard helped us setup several slices to keep the app constantly available.

All told, it was a great project and I look forward to using what I learned about REST principals in future applications.

My topic for the evening was two Amazon web services - Simple Storage Service (S3) and Elastic Compute Cloud (EC2).

These two services are very popular in the Rails community, and it showed this evening. I answered close to two-dozen questions about EC2 and S3.

I used Rick Olson's 'beast' application to demonstrate deploying a Rails application to an EC2 server via Capistrano. It actually worked as planned (the WiFi is a bit flaky at our meeting location).

I am convinced that S3 and EC2 are a glimpse into the future of web application development. I highly recommend checking out EC2 and S3 if you have not already.

Here are the slides.

"mime_type.rb:48: warning: already initialized constant CSV"

Here's why. CSV was added as a pre-defined mime type to Rails 1.2, but a very minor bug causes the mime type to not be available for use. So you have to define it yourself using the code below (usually in environment.rb):

Mime::Type.register 'text/csv', :csv, %w('text/comma-separated-values')

This code then causes the above warning to appear.

I did some digging and found the error in mime_type.rb. I considered submitting a ticket / patch, but right now the Rails Trac is down and I can't do much with it. I was able to look at the trunk source and see that mime_type.rb has been re-written, so this problem will go away in future versions of Rails (or if you are using Edge Rails).

Here's a quick fix that I am using in one of my production application's (which is frozen to Rails 1.2.2) environment.rb -

Mime::SET << Mime::CSV unless Mime::SET.include?(Mime::CSV)

The above line will fix the issue for Rails 1.2.2, and will be ignored if the specific bug is ever fixed in the current structure of mime_type.rb.

I just received my copy of the Rails Cookbook. The author chose to pull the book and revise it, against the wishes of O'Reilly, and was rewarded for his hard work with a release date that coincided perfectly with the release of Rails 1.2. Not an easy task for a fast-changing technology like Rails!

I think the Rails Cookbook should be in every Rails developer's library. If you are trying to solve a problem with Rails, there is probably a starting point somewhere in this book.

Here's a list of the Ruby / Rails books I have on my desk. I have the PDF version for most of these books as well, which is great for when I need to look up something when I am away from my desk.

-Agile Web Development with Rails - the Rails Bible

-Programming Ruby - the "Pickaxe"

-Ruby for Rails - the most helpful book when learning Rails aside from AWDwR

-Ruby Cookbook - a great companion to the Pickaxe

-Rails Cookbook - as mentioned above

-Rails Recipes - another great resource

Rails Machine is more of a do-it-yourself host with a focus on Rails. They have some great Capistrano scripts to help get your app up and running quickly. Then they get out of your way and let you do what you want with your server. On one project I am currently working on, we use Rails Machine for hosting our Subversion repositories as well as our private staging and demo sites. I also did some integration with Subversion and Marshmallow to provide updates to our development group's Campfire room. In short, I've had no problems with Rails Machine and recommend them to anyone considering.

Engine Yard is another great service I've been using recently. Their model is based on reliability and scalability. They sell "slices" of resources - similar to a VPS but slightly different. Need to make sure your application running on a single server (slice) does not go down? Just add another slice. Engine Yard makes sure this second slice resides on a separate physical server, so any issues that may arise on the first slice's host do not affect your site. Need to handle a sudden spike in traffic? Just add another slice or two. I recently had an issue with a project and its slice that I was not even aware of - the site would disappear from the Internet for a few minutes and then come back like nothing had happened. Engine Yard offered to fix the problem and "loan" us a slice for redundancy until the problem was resolved. That's what I call service!

I know my way around a server, but my area of expertise is development. I think that when it comes time to deploy an application to production, it's best to let the pros handle the real server-side issues. I recommend both of these services for just that.

A project I have been working on for the past few months launched last night - QVWines.com.

This project has been one of the best I've ever worked on. I was mostly in charge of the code, server, and database work, while a third-party designer came up with the UI. I was free to use the latest and greatest Rails had to offer, and during the course of the project, we made several big changes that went smoothly thanks to Rails' flexibility.

The server runs Apache / Mongrel - which is far better than what we started with - FastCGI and Lighttpd. We made heavy use of migrations, unit, functional, and integration tests. We used Authorize.net for the payment processing, and we also added gift card support that is made possible by Ruby's great XML-RPC libraries. To top it off, we built a POS system for the physical store so all inventory and orders are kept in one database.

Here are the slides.

What a great conference! Easily the best I have attended. So many interesting people and interesting projects. I met Rails enthusiasts from all over the world, and several people I met flew 20+ hours to be there!

Some of the highlights for me:

-Paul Graham's keynote (now an essay on his site). It was as always inspiring and thought-provoking.

-Martin Fowler's keynote about ThoughtWorks and his opinion of Rails.

-Nathaniel Talbott's presentation. Maybe the most inspiring talk of the whole conference.

-DHH's keynote about the future of Rails and RESTful controllers. Looks like I might need to re-work some of my projects =)

Of course, the best part of a conference like this is meeting new people and just hanging out talking about Rails and general geek stuff. And maybe playing some 8-way Mario Kart.