(I received a free copy of Polished Ruby Programming from the publishers in conjunction with co-hosting the Ruby Rogues podcast.)
The Ruby language has two sides and both of them are trains.
One of the trains is a famous, bright red locomotive with a smiling “Thomas the Tank Engine” face. The Rails Train pulls carriages full of happy, productive programmers that wave from open-top cars. As the Rails Train speeds past downtrodden Java developers, pessimistic Pythonistas and groaning Node coders, DHH and his merry band of Rails Core coal-shovellers blow the train’s whistle, drawing the onlookers’ attention to the huge pile of billion-dollar startups in the cargo car.
In the distance, someone has tied Javascript to the tracks and the train appears to be speeding up.
The other Ruby train is very different. There are no Rails – it appears to use some kind of magnetic levitation. There is no smiling face and no open-top cars. The windows are closed to prevent accidents. Most of the time, it runs underground.
Polished Ruby is a book about this train. It’s a book from the Ruby Underground and, appropriately, it’s a bit of a gem.
True to the title, the book describes intermediate and advanced techniques that will improve your Ruby projects. However, the real value of this book is its fresh perspective on software development and maintenance. Many of the ideas discussed in Polished Ruby have not appeared in similar Ruby books. Popular views in the Ruby community are challenged and every challenge is made by examples that demonstrate the underlying logic.
Readers will witness a controlled demolition of SOLID principles. Rubocop gets defunded. The null object pattern gets culled. Class variables get a hard pass (“weird and wrong”).
Two of the most interesting ideas discussed are “code locality” and “class proliferation”. Many a Ruby veteran has despaired when working on codebases that have replaced spaghetti code with spaghetti classes. Polished Ruby presents persuasive arguments for structural simplicity and against the march of the pattern stampers.
Other spicy snippets include:
- Dependency injection leads to complexity injection
- Abstractions are not intrinsically useful
- Avoid polymorphic associations
- If you’re not adding things back in, you’re not bleeding enough
- DRY but at what cost?
Why does Polished Ruby present such a different point of view to conventional community wisdom? It could be because the author, Jeremy Evans, has maintained popular Ruby libraries for over ten years. In an industry where people often change jobs every couple of years, the “develop and dash” approach prevails. Programmers who change codebases every few months are not going to have the same priorities and Evans has not trodden the same path.
Polished Ruby is a serious book with an entertaining style. Comedy highlights include a BDD description of the halting problem. Five syllable words are conspicuously avoided with the “island chain approach”. Perl and Python programmers are exclusively referred to as “former Perl/Python programmers”.
A “cursed book” is used to demonstrate class extension using modules and one wonders if the author had a particular cursed book in mind. Similarly, when discussing method design and dealing with a hypothetical “worst data backend you can think of” that “would probably make you pull your hair out”, one suspects that this API is not hypothetical at all.
The Rails framework itself is mostly spared criticism, although ActiveRecord gets a gentle going-over in the database chapter. When the reader is warned to not blindly add “created_at” and “updated_at” to all tables, it is clear which framework is being talked about. Later on, the author alludes to Uncle Bob’s famous criticism of Rails.
The Roda web framework, also maintained by the author, gets a brief mention. I was expecting more about Roda but some of the techniques that make Roda fast are covered in the performance optimisation chapter. Fortunately, many of the sections in the book are based on the 30 (!) presentations linked on the author’s website, https://code.jeremyevans.net, and readers who want to explore topics in more detail will not be disappointed.
My minor quibbles with Polished Ruby are the use of the term “code smell” and the separate suggestion to use the numbered parameters feature, new in Ruby 2.7. In my experience, “code smell” is often used by the over-confident to denigrate the aspirational. Likewise, numbered parameters are clearly evil.
The recommendation to avoid using single-letter variables might raise eyebrows when the author maintains a framework that revolves around the single-letter variable “r”.
The book ends with some OpenBSD evangelism, an operating system famous for its security and unpopularity. When the OpenBSD community talks about “zero-days”, they are referring to the number of days most people have spent using OpenBSD.
As we approach two decades of Rails apps, many monoliths have become too majestic and are starting to look craggy. Several former colleagues have stepped off the Rails train and moved to different languages in search of a better way than the Rails Way. If you are ready to join ActionHolics Anonymous but you want to keep using Ruby, Polished Ruby presents an n+1 step recovery program for ActiveRecord addicts.
Links to purchase the book are available here: https://code.jeremyevans.net/polished-ruby-programming.html
StutsBlog 