Anyway, Merb Camp had ~150 attendees at the CalIT2 building.  We were also joined by hundreds more that were watching the live webcast from all over the world and participating in the discussion via IRC.  When the Q&A sections after each talk happened, I volunteered to read out the questions that came in via IRC, so that our international guests got a chance to be a part of the fray.  Once we got to the Merb Team Panel discussion on Day 2, I was asked to moderate the panel.  The video has since been posted on the Merb Camp Video section of the site.  Here is the direct link to the panel video where you can see me in impromptu action.

All in all, it was a very fun conference, where I got to meet all kinds of developers from all over the world.  I can’t wait for the next one!

Hours of Operation

The primary quandary we faced was in how to represent a store’s hours of operation in the database. The obvious implementation is to have separate columns for each day’s open and close times. This gives us 14 columns added to the ’store’ table, named ‘monday_open’, ‘monday_close’, ‘tuesday_open’… and so on. Since we have a different column for each day, it would make sense to have the column be of type ‘time‘ right? No!

Especially because we’re dealing with locations that are open late, we need to deal with cases like “On Monday, we’re open from 10am – 2am”. If the columns only handle time, then we’ll have a store with monday_open = 10:00 and monday_close = 2:00. That means we need to do some serious condition checking to see if its open. Better yet, how do we query for all stores that are open at a specific time? Not very efficient.

So how did we deal with this? We want the columns to be able to know not just the time of day, but also the day of the week. For the example above, we want the columns to read more like monday_open = Mon 10:00 and monday_close = Tue 2:00. This would make queries a whole lot easier, as we can resort to a simple open < right_now < close test, without having to create extra logic. But SQL databases don’t have a type to represent time + day of week. The options are time (hours, minutes, seconds only) or fullblown datetime (year, month, day, hour, etc). Since we’ve concluded that time is not enough on its own, we’re forced into using a full datetime field.

But wait! That means monday_close will look more like March 4, 2008 2:00 -0800. How are you going to deal with the comparisons when it’s now June? The condition will always fail, thinking the store closed months ago! And that’s where our solution comes in. The solution is, to some degree, in the question. Our comparisons will involve the entire datetime, but we only care about day-of-week and time. Therefore, we just need to pick arbitrary values for the rest of the datetime fields and have the code enforce their usage. We ended up using the week of Jan 1, 2007 for our project, primarily because Jan 1 is a Monday, making it very easy to translate a number to day-of-week. Throw in a few helper functions to make the date translation seamless to the user, and we’re set!

Website Hosting

As I said in my previous post about web hosting companies, DreamHost is a great cheap shared-hosting solution, but its Rails support leaves a bit to be desired. I was pleased to see that they’ve cleaned up their documentation, and getting a Rails site running requires a lot fewer hacks now. But the speed issue is still a huge one. Big enough for me to still say that for a commercial Rails app, I would not use them. For a class project, they’re perfect.

Introducing the Team to Rails

We’ve transitioned the project to Rails completely, which has made, as usual, a lot of grunt work disappear into thin air. It’s working well for what we need from it, albeit a very simple site. The real issue with Rails is that, being so new, still very few people know about it, much less have used it before. Whenever introducing a group of people to a new technology, you’re going to have mixed results, and our team is no exception. Some have taken to it excitedly, some with reserve, and some are just not very interested. All this is fine, especially since there’s plenty of work to do outside of Rails. It’s interesting to have such a cross-section of reactions to it all working together.

Interfacing with Google

Since our project employs Google Maps to display store locations, we need to interface with their API. More importantly, we need to load latitude and longitude coordinates of the stores into our own database. Since we all quickly agreed that we didn’t want to do that by hand, we worked out an alternate solution.

The interface to add a new store to the database employs Google Local Search to find stores that are already in Google’s system, and therefore already have all of the information we need (except hours). From the search results we get back from Google, we can click a button that then pushes the data up to our own server. Then we go in and set the hours of operation and assign a category. It took a lot of tweaking to get it working right, but after a few hours of Rodolphe working on the client-side Javascript and me working on the server-side receiving end, we got it ironed out.

Since Capistrano 2.0 is relatively new to the scene, the documentation (as with most Rails-related projects) was lagging behind. The team changed a lot about how 2.0 works, making most of my old deployment recipes obsolete. The problem is, the info about how to write new ones is still very scattered and hard to navigate. OCS was suffering from much the same problem, with no detailed guide on getting a new Rails app ready and launched on their servers. Since I knew I’d need to repeat the process in the future, I decided to document the process as I went. Halfway through, I realized that I was likely not the only one who could benefit from such a guide.

The result of my efforts was posted later that day on the official OCS Support Wiki, as an article entitled “Step-by-step setup using Capistrano 2.0 and Mongrel” under their Ruby on Rails section. It even got a mention and some kind words on the OCS Blog.

#1: OCS Solutions

My uncontested favorite. If you’re setting up anything beyond a simple personal site, these are the folks to go to. Not only do they specialize in Rails hosting, but they actually answer the phone! No, wait, I’ll do you one better. Their CEO (Robert) is part of the 24/7 phone support shift and actually knows exactly what he’s talking about! I know of no other (legitimate) hosting companies that can make that claim.

I’ve already got a few client sites hosted with them, so the team there has seen my name in a good number of support requests already. They never fail to get back to me within 24 hours, but usually less than 3. When I have a truly urgent issue, they are always there on the phone. I have yet to ever leave a voicemail.

More than anything else, their Rails hosting is phenomenal. The first site I moved over to them was a relatively basic Rails app that had been having speed and uptime problems on Dreamhost, even with minimal load. Ever since the move (with zero changes to my code) the site has performed like an athlete on speed. From now on, all of my Rails apps are going on the OCS servers.

My only gripe with them is the occasional usability issues with their web panels, which is where I still use #2 for a few things.

#2: Dreamhost

Very strong in some areas. Very weak in others.

Dreamhost is the ideal “budget-hosting” solution. For a not-expensive price, an account with them will let you do a lot of things. You can register and host a virtually unlimited number of domains with one account. Their “One Click Installs” make basic sites (like this one) ridiculously easy to manage. Even their interface to Subversion, while lacking some more advanced functionality, is ideal for small projects.

On the other hand, their Rails support is not 100%. Google it and you’ll see what I mean. There are posts and discussions abound all over the net about how to get your app to work smoothly, with mixed results. I spent a long time tweaking the code on the Muir Surf & Sport site to get it to work. The best I could get it still had a 1-2% rate of 500 errors. Not acceptable.

To make things worse, their support is sub-par. Their target audience is a very broad client base, so they can’t afford to offer phone support. Ok, fine, I can email them when all hell breaks loose. But when one of my client’s e-commerce sites went offline, completely, it took Dreamhost over 8 hours to get back to me. And guess what? It was their fault it had gone down in the first place! That was the brick that broke the camel’s back for me. I will never again have a client ask me “Why is my site down?” and have to answer “Oh, I’m waiting on the host to get back to me.”

Concluding Thoughts

The basic summary is that Dreamhost works for most circumstances. If your needs are basic, and/or reliability is not mission-critical, then they are a fine host. But for critical projects, 99% uptime means that 10,000 out of every million hits will fail. If you need Rails hosting, and/or actually want good support, go with OCS. The cost is not much higher, but you’ll notice a huge difference.