I love to read. I enjoy novels, science fiction, non-fiction, science and history. I also read a few technical books per year, which I review on this very blog. I was a bit late to the ebook party and preferred physical books. I received a Kindle as a gift for my birthday 3 years ago. From then on, I have been a convert: I love my Kindle and bring it everywhere.

I am also a patron of my local public library, and soon after I became an e-reader I discovered that they have an ebook selection as well!

The Itch

In California, membership to public libraries is open to any California resident, regardless of the actual city or county that they actually reside in. Usually, one can get a library card, and the benefits that come with it, by walking in to a branch and showing your driver’s license. I have done this procedure with a few libraries: San Diego Public Library (city), San Diego County Library, Los Angeles County Library and the San Francisco Public Library.

It turns out, that all of those libraries use the same ebook catalog: A service called Overdrive. Each library has a separate URL, with different authentication mechanism, but that is visibly the same website, branded for each library and containing a different catalog of books (and audiobooks, too). Each library carries a different selection of books, with different number of “copies”, according to each libraries budget, I assume.

Effective Ruby LiveLessons is a video training course by Sam Phippen, based on the excellent Effective Ruby book written by Peter Jones (see my review of that book).

The lessons are split into 5 different videos of great quality covering more than 4 hours of training in total. The video lessons, much like the book covers practical advice that can make Ruby code more readable, less verbose, while at the same time being more expressive.

My favorite parts was the lessons on testing, which stresses ordering your test in Arrange - Act - Assert order (which is usually not possible while using spies, stubs or mocks) and the primer on using the Enumerable module and it’s many functions.

The videos also illustrate common uses for the Ruby Standard Library, like SimpleDelegator or Forwardable that are often overlooked by Ruby programmers.

I enjoyed the videos, even though I generally prefer books to videos: It’s easy for videos to either be too fast or too slow, whereas reading is always at a comfortable pace. In addition, when going back to already consumed material, it’s much easier to find a particular section in a book than it is in a video.

I would recommend the video to those how prefer that format over a book.

Links:

• Publisher Site

How To Test Multithreaded Code

Mike Perham, author of Sidekiq, the popular Ruby queueing library, writes a great post on how to test multithreaded code. The first portion, deals with separating the threading portion from other logic, so that it can be tested with regular means. In addition, he details how using a callback and the native Ruby Mutex and ConditionalVariable one can test threading code, without using any sleep calls. Very informative post.

Is Rest Best In A Microservices Architecture?

Craig Williams discusses why REST over HTTP is not necessarily the best option for communicating between microservices. He illustrates two other options: Pipelines and messaging and talks about the pros and cons of each. It’s a topic that I have personally though about much and at work, we have started using messaging as opposed to REST for the reasons outlined in the article.

Learn to Code: It’s Harder Than You Think

As Mike Hadlow, the author states in the TL;DR:

All the evidence shows that programming requires a high level of aptitude that only a small percentage of the population possess. The current fad for short learn-to-code courses is selling people a lie and will do nothing to help the skills shortage for professional programmers.

The perspective and numbers in the article are particular for the UK, but I believe they apply equally well to the US.

Phoenix Is Not Rails

I have been following the Elixir community and the Phoenix framework in particular. I feel a certain familiarity between Ruby and Elixir, and Rails and Phoenix. Chris McCord, the creator of Phoenix writes, a thoughtful post on the differences, and more importantly why they matter. Sometimes, differences in Software Engineering can be esthetic only (e.g. plural vs singular database table names); Not so with these. He makes compelling arguments on the technical choices made in Phoenix.

How To Charge For Open Source

Mike Perham, the creator and maintainer of Sidekiq, explains how to go about making a business out of Open Source Software. Uncharacteristically for the internet, the comments for this post are actually very interesting, as are the links. For a more in-depth conversation into the same topic, hear (or read the transcript) of Mike’s guest appearance at the Ruby Rogues Podcast

What Is SemVer

SemVer, short for Semantic Versioning, is a convention for software version numbering. I have been using it very successfully at work with for internal gems and bundler pessimistic locking (~> operator). In this post Richard Schneeman, explains the practical aspects of choosing a release number, including security releases.

Last Saturday (11/14/2015) I attended my first code retreat, hosted by the kind folks at Pluralsight. The event was part of the Global Day of Code Retreat. 144 cities participated in the event, and for the first time San Diego was one of them.

Global Day of Code Retreat: A day to celebrate passion and software craftsmanship

The retreat is a one-day exercise in honing the craft of programming. It started with a short introduction and then we were asked to pair with someone for the first exercise: Conway’s Game Of Life. The exercise is specifically chosen because the domain is simple enough to understand within a couple of minutes, by implementing it is usually not trivial. We were not given any rules, except to use Test-Drive Development (TDD) throughout the day. Language choice and design was left up to each pair. After 45 minutes, we switched pairs and deleted our code. That is right: We deleted our code.

Why delete the code? Because the exercises are about learning, not about shipping working code. It’s supposed to be in contrast to what we do at work every day, where we create artifacts that are production ready and ship them.

For each rotation, there was usually some extra restriction added or removed. The day was very intense and interesting. I paired with a Cobol programmer, with no TDD experience, looking to come back to programming after a hiatus. A .NET code school student, and another very experienced .NET developer. In a mob-programming session, we tried starting a project in Javascript, then Java and failed in each case because we didn’t know how to get the test framework setup and ended up switching to Ruby, mainly because I know how to start a project with TDD baked in (bundle gem game_of_life). I had a chance to pair with an experienced javascript programmer, that was interested in ruby and with a gentleman that was an expert in both TDD and .NET. It was great seeing different approaches to the same problem come up. For example, I assumed that all solutions would require some sort of data structure to keep track of the state of each cell in each generation. However, several different people suggested using a set, to only keep track of live cell. Those solutions ended up being very elegant.

In each exercise, I learned something interesting. I learned that it’s easy to take for granted the shared understanding and context that you have with your team around what “clean” code looks like, what to test, how to structure test and even what type of tests there are (ie. unit, functional, integration, etc). I learned that there are many people that are just now getting acquainted with TDD and extreme programming. I learned that pair programming forces you to be explicit about what you are doing and be convincing about the path forward, since you pair needs to agree. I learned that if you are willing to listen, you can learn new things from everyone and anyone.