Abstract
A brief article about the initial stages of getting into the Ruby on Rails framework. Also some discussions on why the move to Ruby on Rails is worth the effort.
Still being relatively new to the rails framework, I figured it would be a good time to step back and reflect upon my newbee adventures and discuss some of the common hang ups I ran into.
Thinking back to the beginning, the hardest part was deciding rails was worth learning. I was a somewhat seasoned PHP developer at the time rails 1.0 came out and I would have never thought I would ever be pulled away from php for web applications.
Admittedly, my first look at the framework sparked a little interest but not enough for me to devote any amount of time dealing with it. Instead I took some of the ideas that I had heard rails was implementing and tried implementing them in PHP. It worked out ok, and I was able to create a rather verbose framework that had some of the key features that rails had developed. Then as I took a step back I realized that almost everyone in the PHP community was racing to generate Rails like MVC (Model, View, Controller) frameworks. I was amazed and disheartened slightly that my framework was nothing more than a fun side project.
Now, certainly side projects like these are great for education so I would never recommend anyone not try to mimic state of the art software design, but realize that rarely would this work be more than for your education! Anyways, i digress, the other important realization I made was the lack of unity in the PHP community.
Nothing is more frustrating (ok, mabye this is an exageration...) than having 10 to 20 frameworks to choose from that are nearly identical in functionality. Which one is going to lose developer interest within the next 5 years? Does one seem to have a better community than the others? Gee, framework one is great at this but fails in this other area, and the opposite for framework two! It can be a real headache dealing with these types of questions, then income the fresh and consolodated Ruby on Rails framework.
Now also during this same period of time where I spent my hours developing PHP web applications I was also employeed as a Java developer at the University of Minnesota. Java and PHP are both massively popular languages and for good reason. So at this point I was comparing the three: Java, PHP, and Ruby with Rails plugings.
Dealing heavily with Java SOAP Web Services, JSP, and JSF I quickly became annoyed by the amount of work that went into my Java applications and the amount of code that was cluttering my source files. Granted Java is great because of the massive amount of tools that automatically generate code; This is the reason productivity estimites in Java can be compared closely to those in more domain specific languages like PHP.
My disappointments in Java and PHP where still not enough to make me seriously consider Ruby on Rails! Amazing, I know, but the time investment to learn it just did not provide enough expected utility. There was still a few compounding events that needed to occur to push me over the edge.
Luckily, one of them was a friend from college who seemed in love with Ruby on Rails. One of his senior projects used the framework extensively to implement user interface plans and provide some basic backing services to test against. He asked me to help out a little bit with the project and offer user test reflections. This was a big help in promoting the hype of the framework and getting me used to some of the design patterns.
The last straw was when I was working on a simple sales website for a real-estate slash car dealer agent. I was working several hours implementing simple database scripts and refactoring code so it was as DRY (Do not repeat yourself) as possible. I began to realize how much easier most of the stuff I was doing would be if I was using the Rails conventions and framework.
That brings me to an important point about the efficiency of rails. One of the big reasons Ruby on Rails is my favorite and fastest web specific languages is because of its conventions. If you are not familiar with rails at all you will be amazed by the amount of assumptions that are made that reduce the amount of code you need to write. Conventions range from database table and coloumn naming to helper functions and RESTful routing. Of course they don't force you to follow these conventions but you better havea damn good reason not too! Now all of these magnificent design patterns that are enforced by the rails framework are not going to be described in this post because 1.) I'm not a rails guru by any means, yet... and 2.) It is beyond the scope of this article (cliche?).
When I was just beginning software development I didn't mind writting almost everything myself, after all it was a great way to learn how higher level operations where handled. Life gets shorter as you get older and the necessity becomes a driving force instead of in the moment "just cause" logic. Time is more precious and frameworks that help you get more done faster are like water sources in a barren desert.
Rails is new and the future of it is not completely transperant, which is why many companies are afraid to commit to it long term. Judging by the continued explosion in community around the project rails does indeed have a bright future and is worth any serious web developer's time. I recommend investigating the advanced features implemented by the rails development team in their latest release and at bear minimum follow the project as if your like me you'll eventaully warm up to it!