Open Source Ruby Library for the Merlin API
Along with the previous post, I would like to announce the ruby-merlin library.
If you are working with Merlin API data inside a Ruby or Rails application, be sure to try the library.
Back to Main - Articles tagged with the "Portfolio" category:
Open Source Ruby Library for the IDology API
While working on a recent project, I wrote a Ruby library for interfacing with the IDology API.
If you are building a Ruby or Rails application and need to work with IDology data, have a look at the ruby-idology library.
ID Watchdog Project Goes Live
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 Site Upgrade
Most of the projects I work on involve creating something from nothing with the help of Rails. Every so often though, I get a project that involves a different type of work.
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.
SportRPM.com Rails Application
I recently wrapped up my second major project in the past year - SportRPM.com.
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.
QVWines.com Launches
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.
