Ruby on Rails agreement. Part 1

The phenomenal popularity of Ruby on Rails is largely due to the transition to new trends and technologies at the right time.

But, unfortunately, technical advantages over time become irrelevant. Therefore, a detailed explanation is needed of how RoR not only continues to be relevant, but expands its influence and community.
My assumption that the indestructible factor was and remains his controversial agreement.
')
The agreement has been actively developing over the past ten years, but most of the basic ideas remained untouched. I do not pretend to some fundamental uniqueness of these ideas. The main achievement of Rails is to unite around itself a strong community of people with a non-standard approach and worldview about the nature of programming and programmers.

So, here are the nine most important pillars of the Rails Agreement and how your humble servant perceives them:

1. Optimization to the delight of programmers
2. Configuration agreement
3. The menu is Omakase
4. Lack of paradigms
5. Beauty cult code
6. Sharp blades
7. Appreciate integrated systems
8. Progress above stability
9. Build a big tent

Optimization to the delight of programmers

Ruby on Rails would not exist without Ruby, so it is logical that the first pillar of the agreement came from the very origins of Ruby. Ruby exalts the pleasure of developing on a pedestal unlike many other programming languages.

If Python can boast that there is 'one and preferably only one way to implement something', Ruby liked the expressiveness and conciseness.

Where Java actively defended programmers from themselves, Ruby dropped the rope and starter kit for the first steps in learning. Where Smalltalk broke through the integrity of an established culture, Ruby accumulated key words and constructions with gluttony.

Ruby is different because it prioritizes other ideas. And one of such ideas is to bring happiness to the programmer during development. The race that set it apart from other programming environments, as well as the perception of who the programmer is and what he should do.

Ruby was designed not only to realize, but also to accommodate the entire palette of programmer's feelings. Be it inadequacy, fantasy or joy. Matz provided the implementation of the idea of ​​amazing complexity, the essence of which is that the development environment should be an assistant programmer. Ruby is one of those cases where what seems simple and clear at first glance is an acrobatic stunt with your hands tied behind your back. You have to pay for these decisions (ask the Jruby team who tried to reverse engineer all of this), which is why they deserve respect so much.

It was a small dedication to the world of alternative vision about the essence of programming and the role of programmers who are far from the love of Ruby. Ruby is not only ease of use, not only the aesthetics of the blocks, without all this there would be no technical achievement. It was a new vision. Some other culture, a place for marginalized from the point of view of the entire professional community.

I would describe diving in Ruby as a find of a magic glove that perfectly filled my mind. The best I could imagine. An event that has become my personal transition from the paradigm of “create programs because I need them” to “create programs with love and self-expression through them”. For those familiar with the work of Mihaly Csikszentmihalyi , it’s hard to overestimate its impact on the Ruby community.

I do not exaggerate when I say that Ruby has changed me and my life. For me it was a kind of revelation. He penetrated my mind and called for helping me carry out a missionary mission as a service for the creation of Matz. In order to help spread his creation and talk about its benefits.

Now I can imagine how most of you shake your head in disbelief. I do not blame you at all. As I described above, I used to live inside the concept that programming is just a tool and if I were you, I would also have treated it with suspicion and laughed from the top of some cult language. But for this, I have to be honest with myself and those around me, which repels some or even most.

In any case, the question is, what is Ruby on Rails, and how does it continue to evolve, guided by its principles and ideas? To answer this question, I think it would be appropriate to quote one of the principles that was often used when writing Ruby in the early days: the principle of least surprise (PoLS). Ruby should behave as you expected.

It is easy to describe in contrast with Python:

$ irb irb(main):001:0> exit $ irb irb(main):001:0> quit $ python >>> exit User exit() or Ctrl-D (ie EOF) to exit 

Ruby supports both commands in order to fulfill the programmer’s clear and obvious desire — exit from an interactive console. Python, on the other hand, is very careful about what the programmer should do, although it is obvious that he knows the programmer’s intent (this is obvious because it shows an error message). This is a fairly simple and clear example of how the PoLS principle works.

The reason PoLS fell into disgrace of the Ruby community is its subjective approach. But surprisingly, to whom he fell into disgrace? Well, this man is Matz. And people who are surprised in the same way as he. As soon as the Ruby community expanded its ranks, people began to wonder at several different things, which caused countless letters.

So again, how is this related to Ruby on Rails? Rails is designed using the same principle and principle of a big big smile (DHH), which says:

API interfaces are designed with so much attention that they make me smile more and more. When I put it this way, it sounds ridiculous and narcissistic, even it is difficult for me to object to the first impression.

Creating Ruby on Rails is a rather narcissistic start. Both projects arose from the mind of the one Creator. But it is quite possible that I project my own motives on Matz, so let me appeal to what I know: I created RoR first of all for myself. In order to develop comfortably and the main value of RoR is to enjoy life more. Rid yourself of your daily routine.

Like Matz, I sometimes stumped. One such example is the Inflector class, which understands many inaccuracies in the English language in order to convert the Person class to the name of the People, Analysis table in Analyzes and Comment in Comments. This system behavior is now perceived as an untouchable part of Rails, but there were times when disputes raged on this topic, when an agreement was just being created.

Another small example that will require a bit less effort for perception:
Oh horror, Array # second #fifth (and as someone well noticed #forty_two, good trolling). These aliases were very offensive for some people who lamented the fact that why so many bells and whistles if you can just write Array # [1] Array # [2] and Array # [41].

Both solutions make me smile to this day. I am happy to write to people, third as a test case in the console. No, this is not logical. It is not effective. But it makes me smile and follow the principles to enrich my life, and justifies my continued contribution to Rails for another 12 years.

Unlike performance optimization, it is difficult to measure the ease of development and the happiness of a programmer. This made this undertaking almost antiscientific in its essence. Programmers are taught to argue and operate with measurable matters, in which one can draw a clear conclusion, where A is categorically better than B.

But while the pursuit of happiness is difficult to measure in small things, it can be more clearly seen in the aggregate. Ruby and Rails have a large community with just such goals. They boast a more saturated life, this is a set of positive emotions, and their victory is obvious.

• Part 1
• Part 2
• Part 3
• Part 4