Book Review Change Design Design Patterns Object Oriented ruby

Book Review of Practical Object-Oriented Design in Ruby – Chapter 1

Practical Object-Oriented Design in Ruby

Sandi Metz wrote the book titled “Practical Object-Oriented Design in Ruby”.¬† As the title implies this book is about object oriented design using Ruby. After reading¬† a couple of chapters, I decided to share my thoughts about this book but I wanted to do it a little bit different. I want to take each chapter and reflect on the contents. I don’t want to write a book review with a few words. I want to take the time and do it right.

For chapter 1, Sandi starts with the phrase “The world is procedural” but the next paragraph she introduces us to the world as software developers see the world. She writes “The world is also object-oriented”.

I agree with her view of the world as being object-oriented. Everything is an object and they must interact with other objects. She calls these interactions “messages”. I never saw these interactions as being messages. I always saw them as calling a method on my object and getting a response back. I like the word message because it allows you to explain your design to non-technical people.

She also shares the benefits of having a well designed application and contrasting it with the perils of maintaining a poorly designed one. In one hand, you have the joy and pleasure to work in a well designed app and that leads to enjoy the changes introduced by new requirements. You don’t have to modify the entire code base. It is a minimal change. On the other hand, working with a poorly designed application leads to anger and confusion. Imagine having to add a new feature but that change will force you to modify a lot of objects. This is painful and we have experienced the pain with our projects. In the following chapters, she gives us common solutions to these problems.

“Change is unavoidable”, writes Sandi. As software engineers, we know that applications are constantly changing. We must fix this page that suddenly stop working. We got a new requirement for a new feature. We must embrace change and having well designed apps will allow to make those changes without compromising quality or the stability of our project.

She continues with the problem that is introduced when objects and messages know too much about each other. The more they know about each other, the more tightly coupled the design is. This is what she calls dependencies. In the next chapters, she gives us tool to manage these dependencies.

She also introduces Design Patterns and the Gang of Four. If you are an experienced software developer, you must know what Design Patterns and who the Gang of Four are. But to give you a quick refresher, the design patterns are a set of solutions to common software problems. The Gang of Four are Erich Gamma, Richard Helm, Ralph Johnson, and Jon Vlissides. They got together and wrote a book on software patterns in 1995. Both of these resources have helped many organizations with their design. They took time to study common problems and gave us solutions to these problems. These resources are a must have for any software company.

We know that having no design at all is a recipe for disaster. But also having a over-designed application. I have experiences with architects that over-engineered apps and requesting a change required lots of effort. Sandi makes a good point about bringing together design and code. If there is no constant feedback from the designer and coder, this is a recipe for disaster.


In conclusion, I think that Sandi does a great job introducing her book. She starts with getting our thoughts in place, and asks us to “start thinking in terms of objects”. Once our mind set is correct, she compares a well design systems with one with on design at all. Then she briefly mentions design patterns, the Gang of Four, and how their contributions will help us with our design. I will have a review of chapter 2 next week.


Git open source Source Control Tips

Ignoring files with Git


Git ignore allows you to specify files or folders that you don’t want to track with git. Some of the files that we don’t want to track are files that differ from one developer to another. They might be files resulting from a build. Other files might be artifacts that will change every time you build your project.

For example in Asp.Net projects, all of the dll files go inside the bin folder. Some of the dll files might be coming from a public nuget repository while others are private. Adding the bin folder to the .gitignore file will notify Git to ignore that folder and all of its contents.

If you are using Git, you can create a new file called “.gitignore” and place it in the root of your project. Now add [Bb]in/ to the first line of the file and save it. From now on, any files that reside in Bin or bin folder will be ignore or untrack by Git. There is a public repository at github called gitignore that has common settings for different languages. There is one for Visual Studio and you can find the project here. You can take a look at those settings and copy those to your project.

To read the official Git documentation, go to the gitignore page. I hope this article helps you gain more knowledge about Git and its features.

ruby ruby on rails rubygem

Why Ruby’s File.executable? method behaves different between Windows and Linux

Ruby File.Executable

I was working with the RSpec team about some issues with their Windows’ continuous integration build hosted at Appveyor. One of the unit tests was failing on Windows but it was working correctly on Linux. After running only the failing test, I was able to identify the issue with the unit test that was using Ruby’s File.executable? method.

The RSpec team uses Travis CI to run and build their software against Linux operating systems. To run and build their software against Windows, they use Appveyor.

It was strange to me that File.executable? method was working fine on linux but it was failing on Windows. The first thing I did was to read the official Ruby documentation on the File class. After reading the documentation a few times, one word received my attention, “executable”. This is what the documentation says about File.executable?: “Returns true if the named file is executable by the effective user id of this process.”

In the same document, it says “On non-Posix operating systems, there may be only the ability to make a file read-only or read-write.” This means that the executable permission is not available in Windows. It is only available on *nix operating systems.
After reading the official File documentation, I wanted to see if other projects have experienced the same issue. I was able to find a bug report for Puppet Labs titled “Windows File.executable? now returns false on ruby 1.9.” The team decided to close this bug and made minor changes to their unit tests to be OS specific.

We decided to do the same with the RSpec team. Here is the diff view to see the changes.