I'm pleased to announce that one of my long-term side projects has launched a new service today.

Quiltivate.com is a community for quilters. You can browse hundreds of quilt block patterns and see what other quilters have built.

Today, Quiltivate launches a new service called the Quilt Builder.

What do I know about quilting? A lot more than I used to. My wife Kacie is the real expert though. I've been working with her over the past year or so to build a service for quilters to make their life easier. When it comes to planning a quilt, graph paper and colored pencils still rule the day. And if you are unlucky enough to spend money on the software available to 'help' you plan a quilt, you'll be ready to gouge your eyes out with those colored pencils after you try to figure out the software. The leading software available for quilters today costs well over $100 and you have to take a class to learn how to use it. And it requires Windows.

So we decided to create something simple and easy for quilters. Give it a try. I'm willing to bet if you are reading this, like me, you don't know much about quilting. But I'm willing to be you can figure out the Quilt Builder.

Quiltivate is built on Rails, of course. The Quilt Builder is a Flex application, talking to Rails behind the scenes. I had quite a bit of help building the Flex app from Daniel Wanja over at OnRails.org.

I've invested a lot of time, energy, and money in this project, and I'm really excited to see it launch. Kacie and I have built this service by continually reminding ourselves that good design matters and that 'less is more' - we are definitely trying to under-do the competition. We think the Quilt Builder does one thing extremely well. If you know any quilters out there, be sure to let them know about Quiltivate.com!

Categories: Portfolio
Posted by Phil on July 15, 2009 | Permalink

If you've ever been lucky enough to go through the process of setting up a merchant account and payment gateway, you know it can be a long and tricky process. The terminology, the fees, the forms to fill out...it's not fun. But it's a necessary evil. The alternative is PayPal, so let's not even go there.

Once you have a merchant account setup, it tends to run fairly smoothly. You pay the monthly fee and money shows up in your account, minus the occasional chargeback.

But what happens when you need a second merchant account? Why would you even need a second merchant account, or a third or fourth for that matter?

If I told you I can bring $250,000 in revenue to your business every month, you would probably do whatever it takes to work with me. But it's not that way with merchant account providers. Surprisingly, merchant accounts have a monthly cap on the total amount of transactions. So if your business is doing $75,000 per month in transactions and your growth shows that you will be at $100,000 next month, and your merchant account is capped at $80,000 per month, you had better find a second merchant account soon.

You would think that the more money you send to a company the better, but not with merchant account providers. It turns out they do not like chargebacks. The more transactions you send their way, the more likely they are to have to process and pay chargebacks - which eventually get billed to you, but not immediately.

So if your business is processing a high dollar amount in transactions each month, you will end up with multiple merchant accounts. This causes some interesting problems in whatever application or billing system you are running. First, refunds must go through the same merchant account as the original transaction. Merchant account providers will scream if you charge a customer $20 on a separate merchant account and refund the customer on their system - and for good reason. It's easy to commit fraud when you can't trace the flow of money through a system. Second, if you 'use up' the monthly limit on one account half way through the month, you must send all new transactions to a different system. You will end up creating what amounts to a 'load balancer' for merchant accounts to ensure that you do not reach the limit on one merchant account too soon.

The client I am working for processes a large amount of transactions each month and we have done what I've outlined above. Our team has essentially learned on-the-fly and built a system that can handle refunds and charges correctly. A load balancer for merchant accounts. Along the way, we've added a half dozen merchant accounts to the system and more are on the way. Once again, the ActiveMerchant library has been great. Some of the new merchant accounts were supported already, and with others, we've had to add support. Here are two that we are using that will someday make it into the ActiveMerchant library -

ActiveMerchant Support for the JetPay Gateway

ActiveMerchant Support for the FirstPay Gateway

An interesting side note on this issue. Many companies deal with this multiple merchant account issue and it can be very tricky. In particular, the chargebacks can really cause problems. A few years ago, the Denver-based airline Frontier had to file for bankruptcy. The cause, in simple terms, had to do with merchant accounts and chargebacks. So many flyers were telling their card company not to pay for already purchased tickets (for weather delays, cancellations, etc) that Frontier ended up having cashflow issues with their merchant providers. The only solution was to file for bankruptcy and fix system.

Categories: Portfolio
Posted by Phil on July 10, 2009 | Permalink

It's been over a year since I last updated this area of the blog. I've been extremely busy, with both work and life. My wife and I had our first baby in early December 2008. These past few months have been amazing, but most of my time in 2008 was spent working hard for one client.

So what have I been doing? Simply put, I've been building a large system using both Ruby and Rails. Remember that small project for ID Watchdog (IDW) I built? Well, it turned into something much larger.

After launching the new signup system, the team I'm working with continued to iterate, build, and maintain applications for IDW. Legacy systems needed to be migrated to the new system we had built. New processes had to be designed and implemented. Then the real fun began: IDW had an IPO in August 2008, and since then IDW's growth has been off-the-charts. All of the systems we built in the first half of 2008 needed to be modified to handle this tremendous growth. New third party APIs needed to be added. Databases had to be optimized. Servers were added. More developers were hired. In short, the project grew very fast.

Some of the highlights while working with IDW in 2008:

I designed and built the core functionality for IDW's monitoring process using Ruby and BackgrounDRb. I designed and built a distributed billing system in BackgrounDRb. I wrote code to interface with a handful of third party APIs. Some of the code is set to become open source patches to the ActiveMerchant library. Our team made the migration from Subversion to Git, and never looked back. We built an API for the IDW system, which is now in use by hundreds of companies every day. We added servers as needed to handle the load. Finally, as the system began to push the limits of BackgrounDRb, I moved the background processing components to the delayed_job queue system.

In a nutshell, this is what I do. I build applications and systems for companies. Often I will start with a small piece of the puzzle, and work with the company over time to make sure the system will grow and scale as the company grows. Both Ruby and Rails are perfect for companies like IDW, where flexibility and short iterations are necessary to keep pace with the company's growth.

I've been doing this for over 10 years now, and it's what I love to do. I'm passionate about building applications and systems. I'm fortunate that I can work on projects that are interesting, using tools I love, with a great team of developers.

Categories: Portfolio
Posted by Phil on April 5, 2009 | Permalink

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.

Categories: Code | News | Portfolio
Posted by Phil on January 11, 2008 | Permalink

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.

Categories: Code | News | Portfolio
Posted by Phil on January 11, 2008 | Permalink

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.

Categories: News | Portfolio | Rails
Posted by Phil on January 3, 2008 | Permalink

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.

Categories: News | Portfolio | Rails
Posted by Phil on September 26, 2007 | Permalink

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.

Categories: Portfolio | Rails
Posted by Phil on April 4, 2007 | Permalink

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.

Categories: News | Portfolio | Rails
Posted by Phil on August 18, 2006 | Permalink