to learn how to find, one must first learn how to hide

i've also been using my time to work on a project to write a contact/project management system, which is a rewrite from the ground-up of a similar project i wrote a while back for a company using php (that is still being used to manage tens of thousands of people and companies). for this rewrite i wanted to use ruby, which i've been reading about and playing with for a short while now.

that is ruby, not ruby on rails. i was so tired of hearing all the buzz over ruby on rails that it made me not want to use it for some reason. i don't know why. i wanted to write it from scratch using ruby and a simple templating system (eruby) as i did with my php application. i was used to this type of environment and felt i could write it quicker than trying to learn the nooks and crannies of some specific development framework.

as i started development, i quickly ran into problems with eruby as a cgi application, not being able to work with cookies properly and do other things that i didn't have to fuss over in php. i tried mod_ruby instead of using a cgi interface, but it wasn't much better (and was actually worse since my ruby files were being stored in memory and not re-read every time).

and so, this actually prompted me to look at rails again. if nothing else, i could use it the same as i was doing with regular ruby but take advantage of its development "environment" if you will, to get back to writing code instead of messing around with apache and trying to make basic things work like they're supposed to.

i had watched the videos and read the tutorials long ago on rails showing how easy it was to make a weblog, but none of that made any positive impact on me. (why has making a weblog become the new "hello world" of web development frameworks?) i wasn't making a little weblog, i was making a large and complex system that would have a very large and detailed database backend. i didn't need an interface composed of a collection of my-first-web-form-ever-written-with-notepad-esque html pages that "./script/generate MyEntireApplication" could spit out in nanoseconds because i would be redesigning every one of them anyway. i'm not a beginning developer and i don't need to be wowed by something showing me i can develop my own very first application in 30 seconds, mainly because as a developer i look at it and ask "ok, it's made, but how do i change it and extend it and deploy it and how useful is it once i've deviated from what the automated scripts spit out?" i am wowed by reading the list of functions available and seeing ones that make me think, "damn, that sounds useful." i am wowed by seeing the source code to a large, in-production application written with it.

so i gave rails the benefit of the doubt and ordered the agile web development with rails book (in pdf and paperback) and began reading the pdf version. as i read the first many chapters, i began seeing what rails added to an already impressive ruby language. and it wasn't the ability to generate a list-view-edit-save interface in seconds with scaffold that all of the tutorials highlight.

activerecord has proved to be the most useful part of the framework to me. being able to access fields and joined tables without any manual mapping is very cool. i think one of the fears that i had initially with rails was that i would be confined to a specific database structure, but as the book explained:

so i could deviate from the standard if i had to and use oddly named classes, tables, and columns, but if i used the logical defaults, a lot of things just work automatically.

and so, after a few days of reading and development, a lot of things are working automatically and i have a big chunk of the rewrite done, and without much code. there's still a lot to go, but it's coming along quickly with the help of ruby and rails. i think i am more excited about having to extend it in the future than what i have to write now, since i know it will be so easy to add fields and reports later.