September 14, 2012 by swri2
When I began working with Ruby on Rails a couple of months back, it was with some trepidation. As a .NET developer who usually works on Windows applications, my experience with web development was fairly limited, and although I had previously dabbled with web technologies such as PHP, I had never worked with a web framework before. Somewhat tentatively, I jumped into Rails not really knowing what to expect.
For those who don’t know, Ruby on Rails is a framework for writing web applications using the Ruby programming language. Rails itself is a code library that writes most of your application for you, leaving you to write the parts of the application that make it do the specific things you want.
This is great, obviously, and on top of Rails you can easily add more functionality to your application via the use of gems. Gems are packaged code libraries, written in Ruby, that provide functionality for a specific need, making development even quicker. As it is open source, there is a strong community behind Rails who are always working on new things, and you can often find a gem to do what you need. Rails itself is a gem, so underneath it all, everything in Rails is just Ruby code.
In short then, Rails helps you build web applications quicker than ever before… as long as you know what you’re doing, of course, and you make sure you follow the conventions…
Rails has a set of conventions that encourage you to work in a certain way. It sounds awkward but this is a good thing, as it reduces the need for heavy configuration, speeding up development time and keeping your code concise and readable. By following certain patterns and placing files in certain locations, your application just works. I found some of these conventions confusing at first, and felt that it added even more unwelcome complexity, but they do start to make sense the longer you work with Rails. You can break the conventions if you feel it necessary, but you are more likely to run into problems that way, plus you will start to lose the benefits of Rails, which are speed and simplicity of development.
Working with Rails has been an interesting experience. It has been frustrating at times, especially in the early stages when I struggled with some of the documentation and didn’t fully understand what was going on behind the scenes. I found the online tutorials useful but a lot of concepts were not really made clear to me until I stopped following the examples and attempted to write my own application instead. I was more inclined to practice different things working on my own project and subsequently learned a lot more about the framework and how it all hangs together. Using Rails I’ve been able to build a dynamic, database driven application in literally minutes, which is really impressive. Building something that is actually useful obviously takes longer, but it’s clear to see how Rails can help us become more efficient in delivering new systems that fit into our architecture.
The next step is to help our developers become productive in Ruby on Rails, and establish a strong development community to share new tools and methods, and ensure coding standards and best practice are properly disseminated. More on this soon…