Working on the Rails Road
Well, I lost a little momentum last week as I got swamped with work, so I haven’t made as much progress into the Rails book as I would have liked. I guess that’s life. Nevertheless, I’m a bit more than 100 pages in and have a couple thoughts on the book and on Rails.
I’m very impressed with the ease of use of Rails so far. It does a lot of the grunt work for you but still seems to give you pretty deep exposure to the guts when you need it. This is something I really appreciate, too many times with frameworks and the like, they do a lot for you, but they also prevent you from doing anything they haven’t thought of. This is an intolerable situation for me - invariably I want to do something different or differently from the package I’m using and almost every time it’s a horrid nightmare to do what I need to do. That’s why I’m a builder more than an integrator/customizer. So I am glad that, in general, Rails doesn’t seem to confine you to doing things it’s way.
An annoyance of the book though is that it spends a whole chapter building this piece of an application using sessions. The whole time I’m reading this, I’m shaking and sweating and wondering if I’m going to have to put the book down because I am allergic to sessions in web applications. Fortunately at the end of the chapter they point out all the problems that are inherent to the way they were building it - but they could have simply presented those problems at the beginning of the chapter and not worried about all that coding and bad habit forming instruction.
The other problem is that it still seems to love sessions. They go the extra mile and say that the best fix for sesions is to store them in the database. This solves some problems but widespread use of session information is going to be a real performance problem if you try to scale. Some basic usage is not going to be a problem, but there’s never a word of caution or anything in this book about it. That’s a general complaint of mine as well - there’s a lot of ease of use features in Ruby and Rails, but I’m sure there’s a cost to them and neither book ever addresses that concern. I think it will be easy to start using them freely only to find at an inopportune moment that they’re costing you valuable cycles.
Nevertheless, I maintain a high degree of respect for the developers and excitement to get started working in this framework. There’s just so much to appreciate about it that if it actually lives up to it’s promise, which I suspect it will, it will be a real pleasure to work with. Hopefully I’ll get some more time in the coming weeks to wrap up this book and start diving into it.
March 12th, 2007 at 10:14 am
You crack me up, man.
I like this blog generally, but I think you really upshift when you’re reviewing tech books.
March 12th, 2007 at 10:32 am
What would you use in place of sessions? Not ruby-specific but in general?
March 12th, 2007 at 11:28 am
No general rule, but as an example. In the ruby book, session information is keyed off a cookie (which is how I understand most reasonably places do it now - url mungeing is so late 90’s). So to get your cart information you first lookup your cart id in the session, which equates to looking up the session key in a table to get the cart id and then look that up. I would simply put the session id directly into the cart - this saves you a database hit and gives you some flexibility to play around with session key - convert that into a longer term key that doesn’t expire over the sesion, etc.
Also, storing some info in cookies. This is a more than reasonable way to store a small amount of information, it also helps make you frugal in your attempts to impart state to this wonderfully stateless protocol. Now that I think about it, I like my web url’s to kind of be Functional in the sense of Functional Programming. Some state is ok, but keep it minimal and use cookies and direct links in the database to handle those needs.