Rails Doctrine

Ruby on Rails (or Rails), is an open source framework aimed at fast tracking web development projects. Like Ruby, Rails was made to maximise developer happiness and productivity, which is highlighted through their core principle of “Convention over configuration”. To put it simply, Rails allows you to quickly start the development of your application and design your web pages, without the laborious process of setting up and connecting all the files together.

Le Wagon teaches Ruby as a programming language and at the end of the program the students build their own web application using the Ruby on Rails framework. Thanks to Rails they manage to build complex applications in just 10 days.

Rails was created in 2003 by DHH, while working at Basecamp. At the time, Basecamp was a web agency in the US called 37 signals. They realised that a lot of their projects had similar needs. That's when DHH thought of putting all the common behaviour into a framework so developers wouldn't need to repeat the same process every time. Essentially a web application boilerplate.

It was initially used internally to deliver faster projects. It was then extracted and officially released as open source code in 2004.

The release to open source contributors is one of the reasons why the framework is so popular today. With more than 5000 contributors to date, Rails keeps getting better.

Here's a brief history of the major releases of Rails

1.0 December 13, 2005 1.2 January 19, 2007  2.0 December 7, 2007 2.1 June 1, 2008 2.2 November 21, 2008 2.3 March 16, 2009  3.0 August 29, 2010 3.1 August 31, 2011 3.2 January 20, 2012  4.0 June 25, 2013 4.1 April 8, 2014 4.2 December 19, 2014  5.0 June 30, 2016 5.1 April 27, 2017 5.2 April 9, 2018  6.0 August 16, 2019

The Rails Doctrine is a must read for all developers using the framework. It summarises the principles behind the framework.

The first three are especially important for our students to know:

This is why DHH chose Ruby as a programming language and not PHP, even though it was more popular for web development than Ruby back then. Ruby is also built to make developers happy and enjoy the coding process. It's for the same reason that we chose Ruby as a first programming language to learn for our students.

Instead of having to spend hours setting up the projects and all the files together, if you follow the Rails convention, your files will be connected without you having to do anything. This allows the developer to work on the "interesting" aspect of the web application without worrying about the boring configuration process.

In a restaurant you often lose a lot of time looking at the menu and studying everything on there. Most of the time, you're better off asking the chef what he recommends. Rails follows the same principle. When developing apps you could spend hours researching and debating which tools to use. Rails have done all the legwork for you, and if they chose this technology, you should trust that it is indeed the best one. This is especially important for junior developers, as the large number of tools available can be extremely daunting. However with Rails you can stick to, and trust, what you're given.

Although Rails has managed to build a really strong community, Ruby has an even stronger one! Lots of gems are available to fast track or help with development even further. All the gems can be found on RubyGems.

Another useful website is Ruby Libhunt, which is a collection of popular gems that are continuously maintained and improved.

Choosing a good gem for a project can be a complicated task. So here's what you should ask yourself when selecting a gem:

Finally if you're still not sure which gems to use, feel free to ask one of your teachers at the bootcamp.