When can you benefit from extracting a micro-library? And, how do you build and publish that code into a RubyGem? I’ll go through the process, from A to Z.
How many times have you written the same bits of code, over and over, and thought, “You know, if only this was big enough to be a gem, I would pluck it out.” Often, we think of a RubyGem as a larger library of code that we “bolt on” to an app. And, these smaller code blobs become a hassle to distribute to the multiple apps that use them.
A small micro-library, done the right way, at the right time, can greatly improve an app.
But, when can you benefit from extracting a micro-library? And, how do you build and publish that code into a RubyGem? I’ll go through the process, from A to Z.
Core audience is a beginner/intermediate engineer who may not have a lot of experience extracting code into reusable gems.
Comparing hashes has always been a common challenge; however the code, over all is simple. So, the implementation went from excessive duplication to a file in lib being copied into each project to extracting it into a public gem. The code never grew by much, but in containing it within gem, we could simplify the distribution to our apps.
Extracting the gem took about 15 - 30 minutes, being that we already had the code and the tests.
Empower beginner and intermediate engineers to better understand the patterns of abstraction by extracting out redundant code into micro-libraries (less than 100 lines total).
This should be fun to do. It’s easy to get board with a code base. Mental exercises, such as this, reinvigorate the creative centers of the mind, encourage collaboration, and improve code quality. Win/win.
The kata is broken into a five parts:
Micro-libraries are rarely a concern for a client and require very little overhead. These are an awesome way to contribute to the community without the pressure of maintaining some large OSS contribution: a way to get your feet wet.
The library can be found: https://github.com/CodingZeal/hash_diff