Why Ruby on Rails?

What it gives to a developer? Myths and prejudices
24 May 2017   2424



Cloud Continuous Integration service.


Design & Enginering team.

Oleg Balbekov

Vexor.io Co-Founder Evrone.com Chief Executive Officer

Our team, Evrone.com, often asked: “Why did you choose Ruby?”. In this article, we will try to answer this question.

Oleg Balbekov Vexor.io Co-Founder Evrone.com Chief Executive OfficerRuby on Rails is a real magic unlike fictional unicorns.

What it takes from a developer?

To put it short, Ruby isn’t a newbie’s choice. It has quite a steep learning curve so usually programmers adopt it after some years of experience in some other languages. The average rubyist’s age is 25–28. The average Ruby on Rails developer is usually already an experienced professional with big knowledge in both web development and general software engineering skills.

What it gives to a developer?

Development Speed


A dynamic, open source programming language with a focus on simplicity and productivity.

One of greatest Ruby/RoR advantages is pretty high development speed. Our practice shows that average RoR projects are being developed 30–40% faster than their analogs in other languages/frameworks. This speed increase is based upon a wide choice of RoR’s building development tools, a huge number of production-ready solutions from Ruby community and Ruby’s elegance as a programming language.

Ruby on Rails

Ruby on Rails (RoR) - a framework written in the Ruby programming language.

One of RoR’s most important «cultural features» is its sociality. You’ve found a solution to a challenge? Help the others. You’ve implemented a really cool module? Share it with the community. This way there are thousands of complex problems solutions available in the public domain. There are AAA solutions, comment systems, financial transaction libraries, communication solutions and much more. You can always find a ready, working, tested and well-documented instrument to solve your problem rather than reinvent the numerous bicycles all by yourself.

Culture and The Standards

Ruby on Rails is a framework. Sometimes it may seem to constrain your creativity. Of course you can reinvent your own bicycle and program without being bound to any standard. This just isn’t needed. Some constraints such as files placement, coding style and design patterns make your project well-structured. Code becomes readable. You can introduce new programmers to a project quickly. Our experience shows that the project’s newcomer submits his first code in his first workday. This means there’s no problem if you pass a project from one developers team to another: RoR project is easily understandable by any RoR programmer.

Does the world need another language? In theory, no. We just need the Turing machine to solve all of our problems, in theory. Humans require more sophisticated tools to program. It’s a matter of human need. As long as some people feel happy using Ruby, that’s enough of a reason for another language for me. In addition, Ruby is designed to be human-oriented. It reduces the burden of programming. It tries to push jobs back to machines. You can accomplish more tasks with less work, in smaller yet readable code.

Yukihiro “Matz” Matsumoto 
creator of Ruby

Some nice development tools


The question of who and how will test this complex code is always among the hardest. You can’t always allow your company to hire a whole QC department but you always want the tests to be run accurately and automatically. Unlike many others, Rails has a powerful built-in test subsystem. In PHP world, well, you can find some 3rd party automated testing tools but they aren’t available just “out of box” and PHP programmers rarely use them. In Ruby on Rails style the code doesn’t really exist without the tests being written for it first. RoR encourages TDD and BDD (test-driven and behavior-driven development).


Cache engineering is something every serious web project must have. PHP has different data caching solutions. These tools are 3rd parties and should be carefully embedded into your code. In PHP community it’s still an open question: what and how to cache.

Ruby on Rails has out-of-the-box caching solution. You can cache the whole pages or individual objects, requests or ActiveRecord models. Besides the built-in you can use 3rd party tools such as Memcached or Redis. With RoR in 95% of all cases you won’t have to reinvent a wheel: all caching solutions are there production-ready and easy to use.


Quite often you may face a situation when your project must suddenly be translated into a different language. PHP developers in these cases would argue that the translation wasn’t the initial task and is too complex to implement. The simplest way there is just to copy the whole project over translating all needed messages.

Ruby on Rails contains the standard localization tools. You can use them both initially and lately in your project lifecycle. RoR can use different templates for different languages, hold dictionaries and do much other useful stuff.

Routing (Nice URLs)

In many PHP projects we see a picture: the page’s URI is long and cryptic. Ruby on Rails has a standard ability to fine-tune your routes, URLs and site sections. You can flexibly change an address of an arbitrary page without messing up the whole project. In Ruby on Rails community REST is considered a good manner. RoR app’s URIs are always simple, elegant and well understood by search engines.


Ruby on Rails implements all input data validation. Once you need to validate your customer’s Email, login/password validity or such, Rails’ there at your service!

Migrations and Persistence

Well-known PHP headache is impossibility to use any kind of comfortable toolkit to easily control your DB layer. DB structure is usually altered directly by hand. Because of this, a lot of surprising fields or even tables appear in the project when almost nobody can say why it’s there. Ruby on Rails provides a toolkit called “Migrations”. DB schema is stored as a part of app code and are configurable just as any normal code. Your schemas are thus versioned and well documented.


Ruby on Rails is positioned as an out-of-box secure platform. Standard RoR installation saves you from SQL injections and XSS attacks. All form parameters are safely escaped by default. All output is safely escaped as well unless you program the opposite. You can’t compromise your app’s security. Well, unless you really want to do that.


There area bunch of tools to do that in Rails ecosystem. For instance when you use Capistrano you issue one command, `cap deploy` — and your whole app is being safely deployed on whatever you use, either single server or a cluster-in-a-cloud.

Lines of code by itself doesn’t really mean that much to me. What you’re able to express in those lines mean a lot, though. So if you’re able to write the same piece of functionality in 10 lines instead of 100 lines you’ve made huge strides in simplicity. That’s part of the argument for why Ruby is a more pleasant language to work with than say Java or C#.

David Heinemeier Hansson
creator of Ruby on Rails framework

Also popular in Ruby world

Version Control Systems

Ruby on Rails development implies using some version control system (VCS). Deployment tools require al least one of them. Git is the usual “best choice” . Git is also a VCS of choice if you start learning Ruby because nearly all code you’ll have to fetch as examples/libraries will be available via hosted Git repositories. Lots of unexperienced developers prefer rather to skip learning VCS and keep working with PHP until they reach better understanding of web development high-tech.

Project Management and Task Control

Ruby on Rails itself was developed as a part of Basecamp, the popular online project management solution. Redmine, the other popular task manager, was also implemented in Ruby. When you manage a team of Rails developers such tools are must-have by default. All project/task managers include VCS integration which provides with the best development workflow.

Rails is the most well thought-out web development framework I’ve ever used. And that’s in a decade of doing web applications for a living. I’ve built my own frameworks, helped develop the Servlet API, and have created more than a few web servers from scratch. Nobody has done it like this before.

James Duncan Davidson
creator of the Tomcat webserver

Myths and prejudices

1. There aren’t Ruby on Rails developers out there!

They really exist out there. Less multiple than PHP-sts but present. It may be because of a steep learning curve: usually programmers enter Ruby after some years of PHP. This only speaks of a developer’s quality: really good are pretty rare in any field of technology.

2. They are too expensive!

Good programmers cost you money, that’s true. But they are costly regardless of a language or a platform. Cheap developers are rare in RoR community because “bad Ruby programmer” is a nonsense.

3. Rails aren’t scalable!

This prejudice is the most popular among those who never did a really big project in Rails. RoR scales and it does it well. See GitHub, Groupon, Basecamp: all these Rails apps my have some problems but none of them suffers from being unscalable.

4. Ruby is slower than PHP!

These days Ruby isn’t slower than PHP in most general cases. The question is, is language performance lag that important? Page rendering time depends mostly on DB query time. Taking this into account, the language’s “speed” doesn’t play a big role.

Meanwhile, you can embrace the main advantage of Ruby, its high overall development rate and low cost of support. The programmers these days are orders more expensive than a couple of extra RAM modules. Finally, a project’s performance problems aren’t a result of a “slow language” or “slow platform” but actually a consequence of a poor application design.

Ruby on Rails is a breakthrough in lowering the barriers of entry to programming. Powerful web applications that formerly might have taken weeks or months to develop can be produced in a matter of days.

Tim O’Reilly, of O’Reilly Media

How To Start an Open Source Project

Personal experience on the open source project; doing it effectively without mistakes
26 January 2018   1240

My name is Dmitriy Strukov and I’m Ruby developer. Today I want to share my experience creating an open source solution. I will talk about what steps the project should take, how to choose the right functionality for the first release, and what mistakes I faced personally when creating my open source project.

Half a year ago, I got the idea that it would be good to create an open source project. Instead of test tasks for the interview, it would be enough for me to send a link to the repository. The prospect of helping colleagues with the solution to their everyday problems inspired me.

I’ve always disliked gems for creating administration panels. Any extra movement needs to redefine the class, and for change fields you need to make changes to the files. After thinking and conversing with colleagues, I decided to create a new library which would be flexible and would not require dashboards or configuration files.


Initially, the project was focused on the Ruby ecosystem, but this would limit the target audience of such a solution. SimpleAdmin is a cross-platform solution for administrative panels, working as a third party service. Obtaining data from the database from the main application works with the help of a plugin. In the Ruby on Rail it engine, in which the necessary endpoints are created. In the near future, the launch of a prototype is planned.

Determine the goals

Every open source project solves a specific problem. Talk with colleagues, chats, forums, and share your idea. It all helps you on the first steps to understand important things, like which solutions already exist, and to hear criticism. Talk with people who already have open source projects. They can give you very valuable advice, so don’t be afraid to ask and take the initiative.

One important bit of advice which I got at that stage is to pay attention in the first place on the documentation of the project. You can have a very good project, but no one will spend the time to understand how it works.

The most important aspect, without which further steps are impossible, is motivation. The idea of the project should inspire you primarily. Most often people get used to the tools with which they work and fall into a comfort zone, so external opinions may be ambiguous.


The choice of a certain task manager is a matter of taste. It should have a clear picture of the tasks and stages of your project.

Divide tasks into sub-tasks. Ideally, if one task does not take more than 3–4 hours, it is important to enjoy the implementation of small tasks. This will help to avoid burnout and loss of motivation.

I use pivotal tracker . The main advantage is a free version for open source projects where you can sort tasks by type (feature, bug, chore, release), and group them into releases and determined deadlines.


Every open source project should contain these things:

  • Open Source license
  • Contributing guidelines
  • Changelog

The README file not only explains how to use your project, but also the purpose of your project. If you do not know how to properly write a README file, you can look at other known open source projects or use a template .

The license guarantees that others can use, copy and modify the source code of the project. You need to add this file to each repository with your open source project. MIT and Apache 2.0 GPLv3 are the most popular licenses for open source projects. If you are not sure what to choose, you can use this convenient service .

The CONTRIBUTING file will help other developers contribute to the project. At the first steps of the project, it is not necessary to pay close attention to this file. You can use the already prepared template from another project.

Changelog contains a supported, chronologically-ordered list of significant changes for each version. As with the CONTRIBUTING file, I do not advise paying special attention to this at an early stage.


To track important changes for users and contributors, there is a semantic version . The version number contains numbers and adheres to the following pattern X.Y.Z.

  • X major release
  • Y minor release
  • Z patch release

Continuous integration / Continuous delivery

To automatically run tests and build, I use Travis CI. It’s also a good idea to add badges to display the successful assembly of the build in the wizard, the test coverage (Codecov), and the documentation (Inch CI).

After each new commit or merge in the master, I automatically have a deploy on Heroku (very convenient integration with GitHub). All tools are absolutely free for an open source project.

My mistakes

To analyze the initial stage, I had an idea, but there was no clear plan. I decided that I wanted to do this without having a clear idea of how much time it would take or a specific representation of the functions that would be in the first version of the library. I had just a lot of desire and lack of a clear plan.

Also, after reading the history of other projects (not only open source), I noticed that at an early stage, some plans are too optimistic. They need a reassessment of their strengths and capabilities. But it’s not easy to find time each day to write a new feature in the project. Most of the tasks eventually had to be weeded out, leaving the necessary minimum for MVP.