Rails (apparently) Rules!
Whew! I just finished my first pass through Agile Development with Rails, a fine book on developing dynamic (interactive) web sites using Ruby on Rails. My background is in Visual Basic (pre .NET). I've helped write some pretty complex object-oriented VB (I know, you naysayers say it isn't so, but you can take up your issues with Rockford Lhotka, whose VB business objects books show how it's done.)
I've done a little web programming in ASP and PHP, but nothing like the work done by my friends at Digital Intelligence Group, or the ever-excellent-and-busy Aaron Jones. I had this crazy(!) idea recently to develop a class-based framework using PHP, nothing incredible, just a way to make it easier to create web user interfaces. My inspiration came from the very good architecture of Microsoft Solomon. The original Solomon development team clearly wanted to make creating data screens easy. Though sometimes buggy and irritating, the focus on letting the framework take care of common tasks is the right one.
There I was, in the bookstore, and I picked up the Ruby on Rails book, leafed through it, thought "This looks good," then went on to the PHP books. I had done a little reading about Rails, but had tentatively decided to focus on PHP and Python. First things first. PHP.
Isn't it surprising how, when you have a specific task in mind, it brings focus to your choices? Surprising or not, I discovered that the PHP books had at most a small chapter on class-based development, when they had information at all. This was not what I wanted. I don't mind a little project that helps me learn, but I'm less entranced with development feeling like an Indiana Jones archeological expedition.
Besides, I really did have a business goal for my PHP project. I wanted to be able to build reasonably good web applications for clients. Build them fairly quickly. Have them somewhat easy to maintain.
Perhaps someone had done the heavy lifting for me? I found myself back at the Rails book. It struck me like a seven-year-old's rubber band. This book was part of the Pragmatic Programmers series. I had read and applied The Pragmatic Programmer a couple of years ago. I prefer "agile" development methods such as Extreme Programming and Scrum. (confession of a programmer: I like these methods, but I don't get to use them often enough, and I'm sometimes lazy when I do)
I decided to put my time into learning a development framework rather than creating one. I blithely presumed it would be fairly easy to install, and that the book would be a good guide. I wanted a rewarding challenge, and had time on my hands. It "felt" right.
Now, the proof of the pudding is in the eating. For my next trick, I'll create a Rails web application, and maybe even make it public. It will be a simple issue tracking system, since no one has ever created one of those before. . . .
If I succeed at that, I can justify telling potential clients that I'll create their web sites. There are pros and cons, of course, but I can always point to 37signals and their Basecamp application. One of its developers was David Heinemeier Hansson, who created Ruby on Rails in order to better develop Basecamp. Mr. Hansson is also one of the contributors to the Agile Web Development with Rails book.
Thus, the circle is complete.
More Rails news as events warrant.