Something I hadn’t expected, but makes sense in retrospect, is the correlation between prior experience and willingness to learn new things. The class represented a huge cross section of prior-experience from student to student. Overall, those who knew the least starting out were the ones most willing to embrace new ideas and technologies. The eagerness with which the “beginners” jumped into their ideas was truly inspiring.

Soapbox: Pro’s and Con’s

I spent a decent amount of time in and outside of class evangelizing Rails since it was so appropriate for a lot of the project ideas out there. This had different effects on different people. One group actually ran with it and built their entire project with it. A few people were probably bored to tears by my rambling. The majority of the class now knows me as the “Ruby on Rails guy”. I’m glad that I was able to expose more people to the framework, but I don’t think I was effective in conveying the core concept that I work by:

If you’re going to tackle a problem, use the best tools available.

Rails is a great tool for a wide variety of web apps. It is not the be-all end-all solution to life’s endless problems. I think I came across more as “Rails is the answer to everything” instead of what I was shooting for “Use new tools, not just what you already know.” A large part of this problem stems from our own group using Rails for the backend; something I was actually trying to avoid.

The aim of the class is for each person to learn new technologies and develop something with them. Our project, due to the nature of its complexity, was going to require a lot of coding. Once it became clear that we were going to need our own backend DB, I wanted to avoid using PHP. Not because it wouldn’t work just fine. There’s nothing wrong with it, especially for a project this small. The problem, as I saw it, was that 4 out of 5 people in our group had a medium to high level of experience with it. That doesn’t allow for a lot of “new” learning.

My motivation for using Rails in our group was to introduce already-skilled programmers to something new, even if it meant limiting my own exposure to “new” things. For my own learning, I made sure to take time outside of our group meetings to teach myself other pieces that I haven’t seen or used before. The most visually interesting result of that is the drag-n-drop ordering of Categories. Working out the SQL queries needed to find stores that are open at a given time definitely stretched my boundaries. Obviously not as major as learning a whole new language, but it was a great way to push myself beyond what I already knew coming in.

If You Could Go Back…

Were I to do it all over again, I would have spent more time trying to preach the core philosophy of “use the best tool” instead of keeping the focus on Rails. For example, I only realized last week that we, it appears, are the only group using any kind of version control. Giving a talk on basic SVN usage, I think, would have been valuable to the class as a whole.

I had a lot of fun working on Open Past Midnight for this class. After all, I’m a programmer. But the neatest part of this class was getting to see what other people came up with, especially when they had to work with limited experience. That constraint can be incredibly discouraging, but they pulled through beautifully.

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.

That said, we’re transitioning the Open Past Midnight project to Rails since we’ll need to be dealing with our own database.  I’ve already got Evan set up with the dev environment.  Then again, he’s running Leopard, so it took all of 5 minutes.  The other teammates all use Winblows, so it might take some extra time.  Either way, I am eternally grateful that Rails 2.0 now uses SQLite as the default DB.  No longer will I need to take time to explain MySQL privilege tables to my classmates when all they want to do is some basic development.

More to come in later posts, but we’re still going to try and deploy this project on Dreamhost.  Since it’s hardly a commercial endeavor, I’m not as worried about DH’s poor Rails support.  It will be interesting though to see how far they have (or have not) come.

I’ve also been working a lot on the server-side systems we need to make this project run smoothly, both in development and production. Just as with Rails, Capistrano is my friend.  I’ve almost got it working for this project, even though we’re likely to do any back-end code in PHP.

Also, it turns out that Google will pay you to submit verified listings of local businesses.  They call it their Business Referral Representative program.  If we’re lucky, we can get into the program and get paid for doing all the data gathering we would anyway.  More to come.

By Thursday (1/31/08) we will have mapped out the data for the following locations.  This means we need to go to those areas and grab all of the data about the various stores (name, phone, address, hours) and submit it to Google’s database (or verify that they already have it.)

• Chris: Costa Verde shopping center
• Evan: Ralph’s shopping center
• Rodolphe: Whole Foods shopping center
• Marc: Einstein’s Bros shopping center
• Vivien: Vons shopping center

Our in-progress feature list:

Must-Have Feature Set

• Default time should approximate the user’s local time
• An interface to allow the user to change the time displayed
• Search for locations based on name and/or time

Would-Be-Nice Feature Set

• Mobile-access compatible (iPhone, etc)
• Heatmap of neighborhoods to display density of locations open at the given time

1. Building a completely image-free site by hand.  Something I haven’t done in a while, considering all of my recent work with point-of-sale and e-commerce.  The verdict: I’m in love with Rails, not HTML.
2. I wanted to really get a feel for the differences using SciTE on my laptop versus Textmate on my desktop for the same, small project.  The verdict: my next laptop will be a Mac, purely because I love using Textmate.  If you’ve got a mac, but haven’t tried it out, I sincerely urge you to.

The thing I’m really looking forward to playing around with is OpenLaszlo.  It looks very powerful, and I’ve got a few ideas for projects where I could implement it.  The most interesting would be to use Laszlo’s DHTML output to create an interface to a Rails app.  Muhahaha.

This should also motivate me to continue my regular postings. For those readers that have been patiently waiting for the printer driver I talked about here, it will be posted this week.