Review to «Practical Object Oriented Design in Ruby» by Sandi Metz

The name “POODR” sums up the book’s essence – it is dedicated to design in the Ruby world
19 May 2017   1123

Unfortunately, something will change. It always does. The customers didn’t know what they wanted, they didn’t say what they meant. The purpose of design is to allow you to do design later and its primary goal is to reduce the cost of change.


Sandi Metz

Reviews to the book are mostly positive. But there is second opinion too. For example, it is said that what the book describes is obvious, but I wouldn’t say so, especially considering what I usually see in the code. There is also an opinion that the given advices are questionable; they are surely arguable, but Sandi is not setting strict ground rules – you must think with your own head and make your own decision in each particular case. And the book contains nothing about the mythical five lines per method the author is usually remembered for.

Practical Object Oriented Design in Ruby 
Practical Object-Oriented Design in Ruby.

POODR has only 240 pages, little “milk-and-water” and a lot of useful information. Despite the moderate size, the explanations are quite detailed and the language is not complicated. Thus, the book is also suited for beginners (not completely inexperienced). As for experienced developers, I’d also advise them to read it or at least look through to make sure they already know all this.

In the beginning, the book tells about what design is, what it is for and how to make design-wise decisions in the constantly changing world without going crazy.

The design must be created a way that allows making changes in an application easier and cheaper instead of making it look good or “because it said so in the books”; this is especially worth considering when you need to decide between deleting everything and writing it again from scratch or making use of what you already have.

The following chapters review different OOP principles exemplifying them with the code of an application for a company involved in organizing cycling tours which is constantly being changed, complemented and refactored.

These are some examples of topics from the book:                                               

  • Single responsibility principle
  •  Loose coupling
  •  Dependency isolation
  •  Dependency injection
  •  Duck typing
  •  The Law of Demeter
  •  Development of optimal interfaces which, among other things, reviews the way interfaces are implemented in other languages allowing developers to take a wider look at object-oriented programming without getting stuck in the Ruby world (for those like me)
  •  Heritage
  •  Liskov substitution principle
  •  Template method pattern
  •  Composition, aggregation and choosing between composition and heritage

The book also reviews more general issues: developing an application from scratch, using UML-like charts, TDD, and general advices on design – for example, cases in which one should delay the decision making and even put up with code duplication.

The last chapter is dedicated to testing. It thoroughly reviews tests of different solution variants described in previous chapters. The given examples were made using minitest framework.

The book proved very useful to me: it often happens that amidst the daily routine I bury myself in the code, which makes me put off studying OOP principles and patterns or do it from time to time. As a result, the obtained knowledge is superficial – I think, I’m not the only one with this problem.

What I also liked is that the given advices can be used in daily work – I can’t say they are bookish as it often happens in literature.

Such books allow designing the architecture when developing an application from scratch, but the most important thing to me is that they inspire developers not to keep writing code smell when working with inherited and often not very high-quality code and instead refactor and improve it little by little.

Those who have read the book, please share your opinion (at least whether you liked or disliked it), and those who have read it in Russian – share your thoughts on the translation (I myself read the original version).

Author: Anna Buyanova, backend

How To Start an Open Source Project

Personal experience on the open source project; doing it effectively without mistakes
26 January 2018   1237

My name is Dmitriy Strukov and I’m Ruby developer. Today I want to share my experience creating an open source solution. I will talk about what steps the project should take, how to choose the right functionality for the first release, and what mistakes I faced personally when creating my open source project.

Half a year ago, I got the idea that it would be good to create an open source project. Instead of test tasks for the interview, it would be enough for me to send a link to the repository. The prospect of helping colleagues with the solution to their everyday problems inspired me.

I’ve always disliked gems for creating administration panels. Any extra movement needs to redefine the class, and for change fields you need to make changes to the files. After thinking and conversing with colleagues, I decided to create a new library which would be flexible and would not require dashboards or configuration files.


Initially, the project was focused on the Ruby ecosystem, but this would limit the target audience of such a solution. SimpleAdmin is a cross-platform solution for administrative panels, working as a third party service. Obtaining data from the database from the main application works with the help of a plugin. In the Ruby on Rail it engine, in which the necessary endpoints are created. In the near future, the launch of a prototype is planned.

Determine the goals

Every open source project solves a specific problem. Talk with colleagues, chats, forums, and share your idea. It all helps you on the first steps to understand important things, like which solutions already exist, and to hear criticism. Talk with people who already have open source projects. They can give you very valuable advice, so don’t be afraid to ask and take the initiative.

One important bit of advice which I got at that stage is to pay attention in the first place on the documentation of the project. You can have a very good project, but no one will spend the time to understand how it works.

The most important aspect, without which further steps are impossible, is motivation. The idea of the project should inspire you primarily. Most often people get used to the tools with which they work and fall into a comfort zone, so external opinions may be ambiguous.


The choice of a certain task manager is a matter of taste. It should have a clear picture of the tasks and stages of your project.

Divide tasks into sub-tasks. Ideally, if one task does not take more than 3–4 hours, it is important to enjoy the implementation of small tasks. This will help to avoid burnout and loss of motivation.

I use pivotal tracker . The main advantage is a free version for open source projects where you can sort tasks by type (feature, bug, chore, release), and group them into releases and determined deadlines.


Every open source project should contain these things:

  • Open Source license
  • Contributing guidelines
  • Changelog

The README file not only explains how to use your project, but also the purpose of your project. If you do not know how to properly write a README file, you can look at other known open source projects or use a template .

The license guarantees that others can use, copy and modify the source code of the project. You need to add this file to each repository with your open source project. MIT and Apache 2.0 GPLv3 are the most popular licenses for open source projects. If you are not sure what to choose, you can use this convenient service .

The CONTRIBUTING file will help other developers contribute to the project. At the first steps of the project, it is not necessary to pay close attention to this file. You can use the already prepared template from another project.

Changelog contains a supported, chronologically-ordered list of significant changes for each version. As with the CONTRIBUTING file, I do not advise paying special attention to this at an early stage.


To track important changes for users and contributors, there is a semantic version . The version number contains numbers and adheres to the following pattern X.Y.Z.

  • X major release
  • Y minor release
  • Z patch release

Continuous integration / Continuous delivery

To automatically run tests and build, I use Travis CI. It’s also a good idea to add badges to display the successful assembly of the build in the wizard, the test coverage (Codecov), and the documentation (Inch CI).

After each new commit or merge in the master, I automatically have a deploy on Heroku (very convenient integration with GitHub). All tools are absolutely free for an open source project.

My mistakes

To analyze the initial stage, I had an idea, but there was no clear plan. I decided that I wanted to do this without having a clear idea of how much time it would take or a specific representation of the functions that would be in the first version of the library. I had just a lot of desire and lack of a clear plan.

Also, after reading the history of other projects (not only open source), I noticed that at an early stage, some plans are too optimistic. They need a reassessment of their strengths and capabilities. But it’s not easy to find time each day to write a new feature in the project. Most of the tasks eventually had to be weeded out, leaving the necessary minimum for MVP.