Knee Deep in Rails
So, I’ve been slowly making some more headway into Agile Development with Rails. I’ve put behind me the intro section that was a bunch of chapters devoted to step by step building a little app. It was cool and an interesting way to put everything into perspective. Now I’m into the meat of the book - the referency part. I’ve gotten through the Active Record and Controller sections.
Just like with the rest of my Ruby and Rails reading I’m impressed with the utility and thought-through-edness of these features. I feel validated in some of the similarities between Active Record and the object relational system I’ve built for my own uses - like making use of plural and singular nouns, alphabetizing for standard ordering of tables and auto generating sql from method names. Good times.
Active Record is clearly much more full featured than anything I’ve written - although, to some degree, what I’ve written is shy on features as its point. Like most full featured systems it provides easy routes to find related tables, in a very convenient and logical fashion you can establish foreign key relationships right in your model and using that it is very easy to pull this related data. I was pleasantly surprised that they provide some nice warnings of the dangers inherent in this easy access, in particular performance problems if you’re looping through a bunch of rows that all pull related info from a different table - you end up with a lot of sql connections. They provide you with some ways they skirt this problem and get on with things. Very good, very readable. That’s what I’m talking about.
The migrations system is really cool too, although - as they point out - it doesn’t give you one place to go and see the full system in one glance. They provide another way to use migrations which they suggest also works out well, but to me it seems to remove the power of the migrations. I’m not sure if there is a grand solution, but it’d be nice if part of the default migration system was creating a faux file that accumulated all the changes for you, now that’d be something.
The controllers are also really interesting. The thing I like the most about the controllers, perhaps oddly, is that cool routing system. I think it’s super smart and seems configurable enough that it should never get in the way of almost any crazy url scheme. They go into a bunch more session stuff, which, I am still not convinced about, but they love it so much I’ll probably investigate this further in the apps I plan to build.
Another thing I think they’re missing out on is that the organization of all this is very distributed, it would be worthwhile exploring some Gems like structure for Rails apps that allows you to install a chunk of code in one place and then update various paths to look in those areas. That would make distributing Rails modules super easy and keeping everything safe and in it’s own space. That would be really cool and would help with competition with the likes of PHP and their unbeatable untar and go ease of use.
It’s all really good stuff. One ongoing beef with the book is that they seem to put things in their example that they have not referenced before and make no mention that you shouldn’t worry about knowing it. On occasion they do point it out, but not always and maybe not even most times. I still feel good about Rails, it seems like it does do a lot of stuff for you, but mostly will get out of the way if you want to do something on your own. That’s the key for me, I have yet to have a good experience with a framework that tries to do everything for you and doesn’t let you easily do things that it doesn’t’ provide (which is most frameworks I’ve been in).
