Riding the Rails (and trying not to fall off…)


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.

As with learning any new programming language or framework, there is a learning curve involved. In my case, I wasn’t just learning the Rails framework – I also had to learn a bit of Ruby, brush up on my HTML and CSS, and pick up a little JavaScript along the way. Web applications are generally complex as they require use of a multitude of technologies at once to piece the application together, unlike desktop applications which can often be developed using a single language. If you’re not already familiar with developing in a web environment, there is more to take in at first.

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…


2 thoughts on “Riding the Rails (and trying not to fall off…)

  1. bob says:

    Really interesting read. I’ve been playing around with rails and it seems awesome.

    I work for a county council and manage a client server style application with a Microsoft SQL Server 2008 back end.

    I am looking at making parts of this application to be available over the web.

    1. Do you know if it is easy to put rails on ms sql server 2008 db?
    2. Is rails performance ok with 100000 records?
    3. Is rails security ok (with it being open source)?

    Hope you keep using rails and good luck.

  2. Rob Nichols says:


    1. Yes, you can use a MS SQL database back end. Have a look at this gem:


    2. In the very early years of Rails (v 1 and before) performance was an issue on larger sites. Nowadays it isn’t a common issue. The performance of both Ruby and Rails have been improved, and most deployment strategies allow applications to be delivered by teams of rails instances. For example have a look at Phusion Passenger:


    To give you an idea of the scale of Rails applications out there have a look at this list of sites using Rails:


    My own experience of working on a site holding a large number of record (https://www.drinkaware.co.uk which has hundreds of thousands of users), is that Rails is fine. You do have to take care with some of your design decisions, but that would be true no matter what the language.

    To be honest, 100,000 record databases aren’t actually that big when compared to what is currently going on out there on the internet. Sites are out there with many millions of records. Often the real issues tend to be due to the number of requests per second rather than data size, and the problem start to occur in the thousands of request a second an up region. So 100,000 records shouldn’t be a problem.

    3. Rails has many security features built in. For example to prevent SQL injection and cross site attacks. That doesn’t mean that poor coding can’t create vulnerabilities, but it does mean that it is relatively straightforward to create secure sites with Rails.

    Whether open source is more or less secure than closed source is a continual debate. In truth, both strategies have their advantages and disadvantages.

    My experiences is that open source bugs are made public quickly and loudly, but that they get addressed quickly and broadly. That means you need to keep up to date, and to apply patches as they appear, but you get to know what the vulnerabilities are. You get to choose how to deal with invulnerabilities, as an when they appear.

    With closed source, I think you are less likely to know what potential vulnerabilities are there and have less freedom as to how you deal with them. You are much more reliant on the supplier updating their product.

    For me the killer argument is that with open source the people who are fixing the bugs are the people actually using the code. It is in their interest to get the bugs fixed as well and as quickly as they can. With closed source, the people using the code are usually not the same people as those who write it. That means that the people who write the code are a level away from the people whose neck is actually on the line if an app fails. That separation affects the speed and urgency that vulnerabilities are dealt with.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: