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

A few months ago, the RSpec team announced the new expectation syntax. In the simplest form, the old way of saying:

Better late, than never: Last November I attended RubyConf for the first time. This year it was in sunny San Diego, which I happen to call home.

“The Software Craftsman: Professionalism, Pragmatism, Pride” by Sandro Mancuso explains the Software Craftsmanship movement and how the motivations behind it’s formation. In essence, the values that developers are encouraged to adopt are professionalism, positive attitude, focus on bringing value through software and continuos improvement. Regarding technical practices, the advice is to follow those of extreme programming, with an emphasis on test-driven development and pair programming. There is a great deal of advice for individual programmers to be proactive about their careers and take control of their skills by continuously working on them.

The REPL is a monthly feature in which I pick my favorite content from around the web, read, but not necessarily published, in the last month. Most of it is technology related.

Suspicions of nil

In her usual eloquent and clear way, Sandi Metz explores the issue with passing nil around as a return value from other objects. She shows a few of the pitfalls and type checking necessary to deal with the complexity. I’m looking forward to the promised sequel, billed to explore the Null Object pattern.

Command-line tools can be 235x faster than your Hadoop cluster

Adam Drake explores traditional Unix tools to analyze a large data set. Using cat, find, xargs and awk he shows that performance can be much better than that used by a Hadoop cluster. The comparison is based on results from another post, which I could not find, since the link seems to have gone away. Nonetheless, I think the the point is made abundantly: Before jumping on the latest shinny big-data thing, it’s probably a good idea to try the tools already installed in your server.

Myron Marston’s Response To Tenderlove

Tenderlove posted a review with his experience with MiniTest and RSpec. Myron responded to some of the issues addressed. I found both articles good reads. I have used both frameworks extensively and I am personally partial to RSpec. However, I applaud Tenderlove and Myron for their posts and the decorum which they exhibited. It is quite common for online back and forth to descend into personal insults quite fast. This is not the case. In the course of the discussion, I also learned a thing or to about both frameworks.

Pairing with Junior Developers

Sara Mei writes an excellent piece about how senior developers can make the most out of pairing with junior ones, with better results for both developers. I personally don’t pair at work all the time, but I found that most of the content is applicable not only to pairing, but working with junior developers in general. As with most things, you get more out of it if you are dedicated and mindful.