Monday, November 21, 2005

Ruby on Rails : Yet Another Getting Started Tutorial

When something as big and buzzy as Ruby on Rails comes out, it's very hard to evaluate. Are you saying you love it just because everybody else does? Or do you hate it because everybody loves it and therefore it is so obviously just the next big buzzword? What if it is the next big thing, are you doing yourself and your career (and projects) a disservice by dismissing it out of hand?

I'm a Java coder by trade, have been since Java existed, pretty much. But lately I've been in need of some small, one-off tools that I just can't motivate myself to write because of Java's overhead. Say that I want a simple system to create new press releases and put them in a database. I want to publish them as individual HTML files, but also with a table of contents file and an RSS feed. Should be easy, but I have enough work on my plate already with other projects, so unless I can make it happen in a matter of hours instead of days, it's never going to see the light of day. So I decided to give Ruby on Rails a shot.

Quick terminology check. "Ruby" is a language. Been around for about 10 years now, so I'm told. Started in Japan. "Rails" is a sort of code generating framework for Ruby. For instance you might start down the road to a web application called "blog" by going into your Rails directory and running "script/generate controller Blog". Hit the web server and you're good to go - you have a web application you can start playing with.

Over the last few days I worked on getting Ruby on Rails up and running on my Powerbook. That's always the hard part, getting it up and running in the first place. Here are some tips I came across that made it easier for me:

* Start by grabbing the tutorial video. Don't just stream it - download it. That way you can play it back at will, pausing and rewinding. You're going to want to do this as you fire up your own copy of Rails and do the same thing the speaker does.

* The editor he's using, by the way, is TextMate. It is shareware, not free, in case you were curious.

* If you are on a Mac OS X machine, like I am, then skip the whole connecting to the database part and go get yourself Locomotive, which packages up everything you need to deploy Ruby on Rails in one nice application. If all you're doing is evaluating the technology, this gives you an easy way to trash it when you're done. But seriously -- integrating database support into Ruby on the Mac seems to be a royal pain in the neck according to my googling, and I spent way too much time on it. I prefer to use Postgres over MySql (since that's why my company uses and I have the installations all ready to go) which only made it that much harder. Locomotive also contains its own HTTP server.

* Locomotive will not necessarily help you get your database configured. RadRails will, however. It is an IDE based on Eclipse that does a number of things via GUI instead of code, including the database configuration. However, because I could not get Ruby compiled with database support, I never actually got the server to come up. So what I did was to take the code that RadRails had made for me and "Add Existing" to Locomotive. Once I ran my project under the Locomotive application everything worked fine.

The "scaffold" trick is cool. That's where you just say one word, like "scaffold post", and then magically you get a web interface that provides you the ability to create/list/edit/delete objects of type "post" based entirely on the database schema. In other words, you don't write any Ruby code at all, you just go into the database and create a table called "Posts" that has id, title, date, body and presto, you have your interface. It's even dynamic, so that you can muck with the schema and without even rebooting your server watch your interface change. Now that's highly cool as far as rapid prototyping goes.

BUT, that's what it is - a rapid prototyping trick. Once you say "I want to modify the actual HTML code that the interface produces", now you have to switch over to a static version of the scaffold (by "/script/generate scaffold Post") and after you do that it's not going to be dynamically pinging the database anymore. So you have to work back and forth -- suffer with a generic user interface until you get your schema right, and then generate the files so that you can muck with them.

At the end of the day, don't forget that this is a Ruby tool that will produce Ruby code. I had at least one person agree with me that the Rails concept is very cool until I pointed that out - he thought the language was pluggable. Eventually you will have to write some Ruby code. So if you weren't planning on learning a new language (and maintaining the code you write in it!) you might want to think twice. Projects like this that promise huge gains on the front end are often appealing to folks who didn't want to write much code in the first place. So there's an interesting tradeoff there -- you're going to write less code, absolutely, but it's going to be in a new language to you, so those lines you do write are going to take you more time. For example when working on the view you can say things like "link_to post.title" but how are you supposed to know that link_to existed in the first place? Sure you can read books on the language but now you're taking the fun out of the rapid prototyping - you can do that with any language. Of course, this only applies to your first app. Once you know the language and the library, you can crank out the code.

Thus far I can say that Rails does what it claims to do - I can build myself a database schema and have the interface dynamically keep up. That alone is outstanding, and saves a great deal of work. Whether or not I write something meaningful in it, I'm not sure. At least I can say that I got it up and running and now I have the option of exploring more. I really did want to write what I said above, a press release manager. I'll try to followup with updates on whether I made it happen and whether I get my company to use it.

Technorati Tags: , , ,

Tuesday, November 15, 2005

Coupons by RSS

This weekend I was up in North Conway with the family and inlaws doing our yearly tradition of getting a jump on the Christmas shopping at all the outlet malls. Without fail, I watched every cashier at every register ask "Would you like to recieve coupons via email?" I did not see anyone give out an email address. It really demonstrates the performance of the whole email marketing model -- sure, if you ask 100 people and get 2 to sign up, hey, you got 2 people you didn't have before...but you lost 98 people!

Imagine instead of these cashiers didn't ask anything, they simply flashed you a little card and said, "And if you're interested, here's some information on how you can use a computer to subscribe to our coupons. There's a web site address and directions on it, what happens is you just add that to your internet browser and then whenever we have new coupons they show up on your browser." I can only use the metric that I'm most familiar with -- myself. I would sign up for such a service. Why not? What does it cost me? Nothing.

The technology business opportunity comes in hosting coupon feeds for a bunch of companies, who otherwise are going to have no clue how to do it. They want to track this information as best they can and get an idea of who is using the coupons. At the end of the day the answer is easy -- you put some sort of identifying mark on the coupons and then you track which coupons come back into the store. But maybe you could experiment with regional feeds if you are a national chain. Or allowing users to sign up to personalize the feed to get coupons that are relevant just to them.

The real hurdle here is not technology, it is faith. When a marketer comes back with 2 email addresses, he knows for a fact that he can send out 2 emails. They may not be read, or converted, or heck, even opened. But at least it's something that can be reported upon. It's an implied "one valid email address per person". With RSS you have to rebuild all of this. What constitutes a set of eyeballs? If somebody has their reader set to ping your feed every 15 minutes, how do you determine whether the user is actually reading it? But all that will come with time. None of that is a reason not to give it a try. I find it hard to believe that getting that 2% of response on "Can I have your email address?" is really more valuable than at least attempting something a little new and different in the coupon biz.


Technorati Tags: , , ,