Checking the water by diving right in

Like many people, I learn by doing, so rather than reading on, I decided to install Rails and see how it goes.

The environment is a virtualized Kubuntu installation with 768MB RAM. Probably not enough for serious work, but good to play with. And if when I manage to *seriously* hoark things up (not an unknown occurrence for me), I can start over with little impact on my actual dev environment.

So I installed RubyGems, Rails, Mongrel and a couple other little things (OpenSSL, LibC, etc). Long and the short of it is that it just worked. In very little time, I got Rails installed, created an app, started Mongrel and brought up the start page.

Just to compare- because lets face it, that's what I'm doing here- the first time I installed ColdFusion was a nightmare. Now, that's not an overly fair comparison. ColdFusion 4.5 wasn't a well-polished product, install-wise. IMO. And I didn't know all that much about what I was doing back then.

A better comparison would be installing CF as an Ear/War with JRun. The first time I tried that, it took an entire weekend and I managed to completely bork my CF installation twice over that period of time. Once so badly that IIS would no longer serve *anything*. Not even .html files.

I also did a little reading on making a Mongrel cluster- similar in principle to making a cluster of JRun servers and connecting them to your front webserver for performance. Good to know that I don't have to give up that ability.

I'm impressed, I gotta say.

Some high-level differences

Warning- I'm unreasonably picky about some things, and that's going to show through here.

I'm not sure what I think of the URL structure that I've seen with rails. A URL is a Uniform Resource Locater, and to me, that means a file on a webserver. Somehow, having a URL that doesn't point to a file on a server seems wrong to me. It obviously works, and I'm not saying that this is A Thing That Should Not Be. But it bugs me.

This next part comes from an example in the book, which may have been written to be simple, rather than a recommended practice. I don't know enough to say yet. however, database connection information is stored in a .yml file in the application folder. Really? No centralized database connection information? If someone more experienced with Rails reads this and can correct me in this, I'd love to hear it. At work, we recently moved our production databases to new servers and changes user permissions, login information, and even the ports used to connect to the databases. Thanks to ColdFusion's centralized Datasource Manager, it was a near-painless and fairly simple operation to make sure that our websites didn't start failing. With the large number of web application we support, even using automated tools to change connection information in each application would have been a chore. I wonder if it would be possible to use symlinks on *nix to help with this some.

Along the lines of database stuff that I want to read more on before forming a firm opinion, a word or two on a command that will be more familiar to any Rails readers I may have than CF readers. rake db:migrate
Here's the scoop, as I understand it. When you create a model object in Rails- post and comment, for instance- a database migrate object is created. The "rake db:migrate" command will apply changes to the database, based on the model objects you have made. Post and Comment become tables and the attributes you have given those objects become fields. If you change those attributes, you can update your migration so that your database stays up to date with your model.

It seems convenient, but I don't know that I like it much. I used the example of Post and Comment for a reason- there's a relationship between these two tables in a database. A relationship that Rails' migrate tool doesn't appear to create. What you get with Rails is two seperate tables, whereas I would also create the Primary/Foreign key relationship, and probably put an index (possibly a clustered index) on the foreign key of the Comment table. A web app's big performance bottleneck is the database. The more effecient the database, the better. While I can certainly add that relationship in myself after migrate has created the tables (and certainly would), however I don't like having a tool that handles *most* of my database changes, but not all of them. I'd rather just generate SQL scripts from the database definition and save those scripts in source control somewhere.

Are these dealbreaker issues?

Nope.

Am I pretending to fully understand all of them?

Nope. Still learning, and I expect my first opinions to change as I learn more.

Am I done?

Yeah- for now.

First Impressions

So, the book I bought is "Agile Web Development With Rails" by Dave Thomas and David Heinemeier Hansson, and as of this post, I'm in the middle of chapter 8.

The biggest thing that has struck me at this point is how similar this is to what I do on a daily basis with ColdFusion. Rails is an MVC framework, as is Mach-II. Rails uses ActiveRecord as an ORM, and I use Transfer. I haven't found an equivilent for ColdSpring- a dependency injection framework- but I could just be missing it.

More to the point, the basic makeup of Rails is very familiar. The basic URL structure of http://domain.com/controller/action is similar to the more familiar (to me) http://domain.com/?event=eventName. In both cases, you are specifying an event (or "Action" as this book refers to it), and a controller reacts to that event.

In other words, I'm not learning something new, I'm learning a new take on something familiar. Funny how a new take on something familiar help you learn more about the new *and* the old, isn't it?

Rails uses WEBrick, Mongrel, or Lighttpd as web servers- and I'm sure that Apache can be put in the mix there somewhere. Still familiar- I'm used to Apache or IIS fronting for JRun.

So there's a lot that is conceptually the same between what I'm used to and what I'm learning. Just to keep posts somewhat focused, I'll save the initial differences for the next post.

So what's this all about, anyway?

I've been a web developer from almost 10 years now, evolving from the same ugly, hacked-together pages that most of us did ten years ago to using an object-oriented approach with an MVC framework and an ORM to make dealing with the database less arduous.

Almost every step of the way, I've used Allaire/Macromedia/Adobe's ColdFusion, and for the same reasons now as I did then. it lets me do what I want, the way I want to. Back then, I was happy just to see how easily I could pull data from an Access database and display it on a web browser. Now, when I'm looking for all the latest buzzwords- OO, MVC, ORM, Dependency Injection- CF *still* lets me do what I want, the way I want to.

Which isn't to say that I want to stop with CF. Like any decent programmer, I'm always on the lookout for something new. Let's face it- creating web applications pays the bills, and I enjoy doing it, but learning new stuff is *cool*. (Yes- I got beat up a lot in high school.)

Which brings me to why I'm blogging. on a whim, I picked up a Ruby on Rails book the other day, and started reading through it. Just the first two chapters started me thinking- enough that I started making mental notes about things I wanted to think about more. Since I spend most of my day staring at a browser, one thing led to another, led to BlogSpot.

What I am doing here:
I think better when I talk things out, and even better when I take the time to write them out. So a lot of the point here is to just help me process what I'm reading. If someone reads this and wants to chime in, so much the better.

I'm also putting down some of my impressions. There have been a few things that I've read that I really liked, and some that I'm not so sure of yet. However, as I go further into this, I'll have a way of looking back at my earlier impressions and seeing how they held up over time.

With any luck, this blog will help out.