Introducing Discrete Integration

Gustave Dutra at Plataformatec, discusses a concept called Discrete Integration. The process described is very similar to what I use at work at the moment. A sort of dialed-back version of Continuous Integration. It reaps a lot of the benefits of rapid feedback, just not as extreme. Feature branches are worked-on until they are at a stable state before merging into master. Good developer communications is encouraged at all stages.

Require Only What You Require

Janko Marohnić presents a well-thought out argument against requiring all code in gems up-front. His concerns are around what this communicates to other developers. The intention of each file or library required is lost as are the dependencies of each individual class. Finally, it makes it harder to clean-up dependencies once the are no longer used. I intend to adopt this style in the next gem I work on. I have actually done a similar thing in some Rails project, with a smaller scope: For example, if a class uses an external service wrapper, I require it on the top of the class even though it’s already required by bundler, as a notice to other developers on the project.

Programming Is Not A Craft

I previously wrote about my thoughts on the Software Craftsmanship metaphor. My main objection to the metaphor is that it evokes imagery that is not helpful to software development and completely unnecessary. In this article Dan North’s tells us that the risk behind the craftsmanship movement lies in putting software ahead of the benefits it provides. My understanding is that so called ‘craftsmen’ pride themselves in delivering value first, but the article did provoke in my a deep sense that there is a lot of navel-gazing going on. Let’s just focus on professionalism and excellence. Keep calm and code on.

Mark Methods Private When You Don’t Test Them

In his usual clear way Pat Shaughnessy writes about when to mark methods as private. Essentially, methods that have tests are part of what is considered the public API of the object. Untested methods and those that are private are not. Ruby performs the most basically check against calling private methods, that can be easily circumvented by using send. However, marking methods as private is more about communicating to other developers what part is internal to the class and should not be relied upon. This is very much in vein with Sandi Metz take on testing