The phenomenal popularity of Ruby on Rails is largely due to the transition to new trends and technologies at the right time.
But, unfortunately, the technical advantages become irrelevant over time. Therefore, a detailed explanation is needed of how RoR not only continues to be relevant, but expands its influence and community.
My guess is that the invincible factor was and remains his controversial agreement.
The agreement has been actively developed over the past ten years, but most of the main ideas have remained untouched. I do not claim any fundamental uniqueness of these ideas. The main achievement of Rails is the unification around itself of 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 yours truly perceives them:
- Optimization for the joy of programmers
- Agreement over the configuration
- The menu is omakase
- Lack of paradigms
- The cult of the beauty of the code
- sharp blades
- Appreciate Integrated Systems
- Progress over stability
- Put up a big tent
Optimization for the joy of programmers
Ruby on Rails wouldn’t exist without Ruby, so it makes sense that the first pillar of the convention came from the very beginnings of Ruby. Ruby puts the joy of development on a pedestal unlike many other programming languages.
If Python boasts that there is ‘one, and preferably only one, way to implement something’, Ruby has taken a liking to expressiveness and conciseness.
Where Java actively protected programmers from themselves, Ruby threw off the rope and the starter kit for the first steps in learning. Where Smalltalk broke the integrity of the established culture, Ruby greedily accumulated keywords and constructs.
Ruby is different because it prioritizes other ideas. And one of these ideas is to bring happiness to the programmer during development. The race that set it apart from other programming environments, and the perception of who a programmer is and what he should do.
Embedded Custom Blog Engines for Ruby on Rails
Sometimes I feel like there’s a cursed place in the Ruby on Rails ecosystem: embeddable blogging engines. This is especially sweet to watch in light of the endless number of “10 minute Rails blog” screencasts.
Apparently, any attempt to create any solution for blogging as a plug-in usually leads to one of two outcomes: either the person gets tired of this work and leaves to do more pressing things, or the engine turns into a monster that can devour any Rails application even before it is initialized.
Some time ago, when I worked at ABAK-PRESS, the management ordered to add a very fashionable “feature” to the cute LookMart site today – user blogs (at the moment this functionality is under active development). The last thing we wanted to do was reinvent the wheel and make obvious wagonloads of controllers with models, but after a little exploration, we had to put up with it and do everything ourselves. Why?
Because we have not found a suitable solution, alas. The main restrictions were imposed by the problem statement and the peculiarities of the code base of our portal:
- it is necessary to track all slug changes in blog entries and avoid “broken” links when editing metadata;
- we have a very tricky rubric system that should be tied to blog posts;
- a number of modifications in the routing system somewhat complicates the implementation of plugins with their own routes;
- a no less cunning system of regions has been implemented, which is very closely integrated with the routes and characteristics of the posts.
The world is small. One of the notable existing solutions will surely come in handy for someone, and this article will help reduce the cost of reconnaissance of the area.
Description of analogues
Governor
Governor is a plugin for Ruby on Rails 3.0 that makes it almost painless to include blogging functionality in a Web application.
Kublog
There is also a more modern analogue of the Governor engine – Kublog.
Kublog is very similar to Governor in its essence, however, it is tailored for somewhat more “modern” tools: Ruby on Rails ≥ 3.1 and carrierware (analogous to paperclip).
Judging by the fact that the last commit is dated November 21, 2011, and only a partial presence of tests for the code, there is a hypothesis that there is a certain dependence between the number of Rails blog plugins and the time of year.
Despite the low intensity of development and almost no interest in the project from the community, it is used by the development company in production and probably shows very good results.
JABE
The JABE embeddable engine appeared relatively recently and already has a number of dependencies comparable to a good CMS: Rails ≥ 3.1, ActiveRecord, kaminari, devise, simple_form, and so on.
There is no test coverage as a fact, despite the very impressive version 0.7.0, to which the engine has been able to grow since December last year.
Thus, I want to ask a rhetorical question: is the original problem so irrelevant to the Ruby on Rails community that no one is publicly trying to solve it?
I dare to suggest that although the task is relevant, there are always clarifying requirements when developing a blog engine, which is why it is a Sisyphean task to create a solution for (user) blogs on rails in general.
The plugin is fully tested with RSpec and has minimal runtime dependencies: just ActiveRecord and will_paginate. User authentication and authorization methods are specified by overriding the corresponding helpers.
It’s a little annoying that the last commit to it is dated November 27 last year, and support for Rails 3.1 has not yet been announced.
locomotive
In the Ruby on Rails ecosystem, “harvesters” like Locomotive have a certain popularity, which can be built into a Web application in a completely trivial way (as an engine) and used to build custom blogs.
There is a question of expediency of embedding such solutions: these CMS can do too much. The functionality implemented in them can, at best, duplicate existing developments and sometimes spoil the architectural idyll. Not everyone is ready to accept this.
The popularity of these solutions affects both the pace of project development and the quality of code coverage by tests. Do not forget that Locomotive uses only MongoDB, which may not suit everyone.