About this book
You don't have to understand everything at once, so please use bookmarks and take your time. You can start with the part you want to look at, and if you are not sure about a part, you can skip it.
It is not necessary to use all of the techniques in this book, and the implementations in this book are not the only correct way. It is a good idea to consider implementing or improving the parts of the book that you think your team could use.
The book is based on Rails 6.1.6 and Ruby 3.0.3, and the author's experience in Tokyo.
Intended reader
This book is intended for elementary and intermediate Rails users, and it assumes that you are more or less familiar with Rails. Specifically, people like the following.
- Those who are unfamiliar with systems other than those built by their own company, or other parts of the system for which they are responsible.
- Those who have never written an RSpec, or who have written one but feel they do not understand it in depth.
This book is not recommended for programming beginners or people who have never used Rails before, as some very basic explanations may be omitted.
I think if you get this book right, you will be on your way to becoming an advanced Rails user.
About the author
I am a freelance engineer based in Tokyo and have been working with Rails for about 8 years. I mainly focus on server-side development, and I believe I have enough knowledge as a full stack engineer.
I have worked on projects for some famous companies in Tokyo. And this book is an introduction to the techniques I used in those projects.
Before I started with Rails, I was using ".net". My first language is VB.net with Visual Studio. I have published small iPhone apps, Chrome extensions, and Javascript games on the Web.
I can read English, but this book is the first technical book I have written in English I ever made, so some of the English may be difficult to read. But I am sure the content will be worth it. If this book is read by many, I would like to update the quantity and quality. I am also interested in doing a book on more specific implementations in detail.
About the author's past articles
I have a Rails article on dev.to. You can see if interested.
dev.to - Refactoring Guide for Rails Beginners
My impression of Rails as a Framework
Rails is a double standard with Ruby, but I think that Rails tries to follow Ruby's changes and additions of Ruby as much as possible, and also makes an effort to incorporate Ruby's ideas.
Rails is a very thick Framework with many unique writing methods, so even if you have the skills to use design patterns in plain Ruby, they are not directly useful in Rails, and vice versa.
Is Rails outdated?
At the moment, that apparently not. When I started learning Rails, I was planning to switch as soon as a better Web language or Framework became available, but now I think "I want to understand how Rails works more deeply so that I can apply my thinking to even when new Web tools".
However, many systems still use PHP or Java, and I don't think that alternative languages such as Python and Kotlin will become more major than Rails.
It has been quite a long time since some people started saying "Rails is outdated." and Rails will be around for a while.
The server-side has matured relatively.
There seem to be fewer big feature additions and disruptive changes in the update than before.
One reason for this is probably that RDB does not change much, so there is no need to change features related to table manipulation.
The frontend continues to change.
In contrast, the frontend in Rails is still changing. This is probably because the frontend of Web development is still changing. With many frontend tools available, Rails continues to explore what choices should be provided.
Although it could be said that there is an option to use newer and better, it also means that there is no rail (implementation policy). It is difficult to properly select, use, and maintain frontend tools in Rails.
Riding the Rails
Riding the Rails means implementing and designing as Rails expects, and using the features provided by Rails. Then Rails users can implement speedy, simple and secure. And it is possible to make each member's implementation somewhat similar.
On the other hand, if you try to implement something outside of Rails or add special customizations, the implementations will become more complex. However, this may be necessary due to requirements. By understanding how Rails works, you will be able to deal with customizations to some extent.
Some episodes for Rails
The following are asides and can be skipped.
Balance of innovative/conservative thought
「壊れてねぇなら直すな」という発想はRailsにはないのかも
This article was written in Japanese before 2013. If interested, please use the translator to take a look.
To summarize this article saying, there are currently Rails controller methods before_action and after_action that were before_filter and after_filter in previous versions. The names were changed in Rails 4. This is a destructive change (though with a grace period) and will make it impossible to use the old ones. But there seemed to be little opposition.
Web development, especially Rails, tends to favor replacing the old with the new and more suitable, even if it is destructive like this. Some people may think, "Old things are bad just because they're old (because they weren't designed for the current era)".
On the other hand, a system in a solid industry may be valuable simply because it has been running without problems for a long time (even if it does not have a clean architecture).
A sense of balance is important here. It is probably not good to just use the latest technology or to stick to the existing way. Suitable system architectures and operations should be considered for each system and project.
Do it because want to
Here's a story.
I asked my boss, "We are spending too much time on refactoring, even though refactoring does not lead to sales".
My boss replied, "It can't be helped. We'll lose motivation if we leave the existing legacy code in place.".
In other words, he considered the engineers' motivation and let them wanted to some extent. I don't know if this is really the right decision, but the Rails user mindset is clearly different from a waterfall management approach.
* Of course, this does not mean that there is no such thing as a Rails waterfall project.
It was the same when various Javascript Frameworks and Microservices Architecture started to become popular a few years ago. I often heard things like, "I don't want to conclude that I can't do it because I've never done it before" or "If you try and fail, it's an experience".
I think that is because they are in companies with enough budgets. This is my personal feeling, companies that choose Rails have relatively larger budgets and are more willing to try new things than companies that choose JAVA or PHP.
* Of course, this is not true for all Rails projects.
* This is just my impression based on my experience in Tokyo.