Ylan Segal

Experiment: Use RSpec Expectation Syntax

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

foo.should eq(bar)
foo.should_not eq(bar)

is now:

expect(foo).to eq(bar)
expect(foo).not_to eq(bar)

Most of my work is on a long-running project with an extensive test suite. It has over 8,000 should statements in it:

$ ag '\.should' spec | wc -l

This personal experiment is a simple one: Stop using should. Use expect.

The motivation for the experiment is to not be left behind. The writing is on the wall. Although the RSpec team has not announced the deprecation of the should syntax, it is clear that the prefer the expect syntax and believe this is the way forward.


For the last two weeks, I have been writing all new specs exclusively with the expect syntax. At this point, I have made no effort to change all existing uses of should. I have always liked the should syntax for its expressiveness, which I suspected was lacking in expect.


I was pleasantly surprised. At first, I found myself immediately reaching for my trusted should. Pretty quickly expect started to become second nature. I still believe that should is bit more expressive when reading complete lines of code. However, expect does have an advantage: It is usually at the beginning of the line, which makes it obvious which lines are setup for the example and which are the expectations or assertions.

Going Forward

expect is in, should is out for all new specs. There is no immediate intention to convert wholly to expect because the project is large and we can’t immediately move to RSpec 3.x branch anyway (becuause of a conflict with another gem). That will need to come at a later time. In the meantime, we can start converting file by file as we touch them and do the work piecemeal.

2014 RubyConf - San Diego

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.

This was my first time and I was really happy I went. I gather this was the biggest RubyConf yet, with attendance around 900 people. I had a really good time. I returned full of new ideas, which I guess that is the point of going to conferences in the first place.

I have heard often that the best part about Ruby is the community. After attending an event like this, I agree. Don’t get me wrong, I like the language itself and love it’s expressiveness. The community of people that write ruby gems, frameworks, organize conferences and prepare talks is amazing and what really sets Ruby appart from other languages I have used in the past.

The organizers did a great job: The venue and program where great. See you in San Antonio next year!

Book Review: The Software Craftsman - Sandro Mancuso

“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 second part of the book is about transforming existing organizations. It gives advice on recruitment, interviewing, keeping high morale, driving technical change and being pragmatic about the goals and limitations of transformation.

Overall, most of the advice of the book resonated with me and there is plenty that one can start applying on an individual basis, without requiring your whole team to be on board.

Software Craftsmanship, the author explains, is about a metaphor that sees software development as a craft and compare it to medieval blacksmithing, including apprentices and masters. To me, this metaphor falls completely flat: Medieval guilds were largely about protectionism. Guilds where formed by royal decree, membership to guilds was tightly controlled and the practices they followed were restricted to approved processes. The result was lack of innovation and stiffing of competition.

Software development, in my view is not a craft. It’s an Engineering discipline. It is about applying scientific principles for practical purposes. It is about finding solutions given a set of constraints. It is about bringing value to our users and stakeholders.

The Software Craftsmanship movement proclaims to be open to new comers and values skills, instead of certifications. However, the imagery that they evoke with their metaphor contradicts that. As every developer knows: Semantics matter.

I do not see a need for a metaphor. I am all for excellence and professionalism in Software Engineering. I just don’t think that calling it a craft gets us any closer to that.


The REPL: Issue 6 - January 2015

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.


Dependency management in Ruby, is almost universally done with Bundler. It provides an easy way to declare other Ruby dependencies in your application and install them on demand. It manages the explicit dependencies you tell it about in your Gemfile and also resolves the transitive dependencies, those that you do not specify directly, but are declared by the dependencies themselves.

Bundler generates a Gemfile.lock that locks those dependencies to specific versions to ensure that your application is tested and deployed to production with a known environment. The procedure solves a number of problems, one of them being insulating your application from change.

That code that you write depends on a stack of other software to operate correctly, to fulfill the function it was designed for. Bundler recognizes that in the future, new versions of the components of the stack will be release and introduce breaking changes. They will no longer work with your application in the same manner they do now.