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   1570

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 evrone.com

NGINX to Release Unit 1.3 Beta

Developers expanded the ability to run web applications in Python, PHP, Perl, Ruby and Go
16 July 2018   99

In open access, a beta version of the NGINX Unit 1.3 application server was released. Developers continued to expand the ability to run web applications in Python, PHP, Perl, Ruby and Go. The project code is written in C and is distributed under the Apache 2.0 license.

Features

Version 1.3 eliminates the problems with handling errors when installing HTTP connections.

Among other changes:

  • parameter max_body_size to limit the size of the body of the request;
  • new parameters for setting timeouts when setting up an HTTP connection:
         "settings": {
              "http": {
                  "header_read_timeout": 30,
                  "body_read_timeout": 30,
                  "send_timeout": 30,
                  "idle_timeout": 180,
                  "max_body_size": 8388608
              }
          },
  • automatic use of the Bundler where possible in the Ruby module;
  • http.Flusher interface in the module for the Go language;
  • The possibility of using characters in the UTF-8 encoding in the request headers.

The first version of the NGINX 1.1 application server was released in mid-April 2018. Under the control of NGINX Unit, several applications can be executed simultaneously in different programming languages, the startup parameters of which can be changed dynamically without the need to edit the configuration files and restart.