I contributed to the improvement of the interface for the
core Ruby class. This resulted in the creation of new methods to compare
Ruby hash instances with one another. These new classes were released
in Ruby 2.3 on December 25th, 2015 and are also also available in more
recent versions of Ruby.
In Proposal for a better Ruby Hash#include? I made the case for this potential improvement. I later submitted a proper feature request after gathering feedback from fellow Ruby programmers on the idea.
After lengthy discussions and consideration from the Ruby Core Team which overseas the development of CRuby (the reference implementation of Ruby in the C programming language) the Hash Comparison Operators were merged into Ruby’s trunk on November 20th, 2015.
As demonstrated in Better Feedback on Ruby 2.2 Keyword Argument Errors the handling of argument errors involving keyword arguments used to be inadequate and confusing. I proposed an improvement to the the Ruby Core Team and implemented a fix which was applied to Ruby’s trunk on July 4th, 2017 and eventually released in Ruby 2.5 on December 25th, 2017.
In order to allow Rails developers to identify the source of specific SQL queries logged in the Rails console I contributed a new configuration option enabled by default in the Rails development environment that displays the source code file and line that triggered each specific SQL query.
This contribution was accepted and merged into Rails’ master branch and will be part of the stable release of Rails 5.2. Meanwhile it’s available as in Rails 5.2 RC1 which was released on January 30th, 2018.
I created Shields in January 2013 in a bout of constructive rage against bad open source repository metadata badges. I’m a bit amazed by how shiny that rage diamond turned out to be.
One fatelul day in May 2014 I decided I’d had enough trying to decipher the Git commits from one of my application’s dependencies. The dependency in question wasn’t some obscure repository. It was something likely used by thousands of people, and yet it didn’t have a proper CHANGELOG to speak off. Instead the maintainers did a git log diff between two version tags and dropped that into something they called a “CHANGELOG”.
That wasn’t a CHANGELOG. A CHANGELOG is a thing for humans who already know how to make a git log diff if they need to. But they don’t want to because git log diff are utterly useless to understand what has changed in a release at a high level. This frustration led me to write down what I believe are guidelines for a human-friendly CHANGELOG.
In late 2012, after nearly a year of working at Code School, I noticed that the same questions kept coming up over again. As an early member of the team, I had to explain some things that weren’t just code-related. Company traditions, vacation policies, customer support practices, etc.
Orientation was born out of the desire to concentrate as much knowledge as possible in a single point of entry that did not create interruptions for our small team, allowing us to remain as focus as possible; collaborating when it’s necessary and not to answer a single question.
People can start with Orientation — as developers do with Stack Overflow — before asking for help. I also wanted to make the act of documenting easy enough for anyone to participate in: creating a new article to ask a question to be answered should be the easiest thing in the world — and become a URL anyone can later benefit from.
This busts information sillos, avoids interruptions, and reduces the likelihood that questions will go unanswered because one person is in a meeting, on vacation, or left the company with the answer.
Orientation allows every single person who relies on a piece of information to be notified when an article is updated, creating hyperlinks of sort between mostly static information and the people who depend on it.