Ambition and the Value of a Good Repo Maintainer
When I was a teenager I once went down to my local DIY bicycle repair shop to try my hand at wrenching on some bikes. Having worked to maintain a department store mountain bike of my own through minor maintenance, and having survived the experience, teenage me felt motivated to go lend my expertise through some volunteer work. They started me off with something decently simple: stripping a scrap bicycle for parts so that they could be placed into bins to be later found and used by patrons in search of inexpensive replacement components.
And what a simple task it was: I had pulled off the wheels, removed the derailleurs, brakes, brake levers, and shifters in no time until I was down to frame, handlebars and the fork (the bit of the bike that holds the front wheel, and connects to the stem; the bit that holds the bicycle's handlebars). Here was something unfamiliar. The handlebars were clamped into a stem, which then attached to the fork, but the setup looked different than what I had seen on my bicycle--in fact, I had never tried to service that part of my bicycle at all before, so I was doubly unfamiliar with the process.
There were two things that I could loosen, a large bolt on the top of the stem, or a couple of large nuts that held some ball bearings in place. Seeing that I needed to get the thing apart, and loosening the stem bolt yielded no positive results, I proceeded to loosen the nuts, which also did not yield the desired result. I then tried to twist the stem back and forth relative to the fork, and this sudden agitation caused about 64 little metal spheres to cascade down into the frame of the bike, jamming the fork in the frame of the bicycle.
It was about this time that a mechanic noticed what I was doing, sauntered over with hammer, hit the stem bolt with a hammer to release the stem from the rest of the bike (yes, this is the correct way of removing this part--who would have thought?), and then used the hammer to tap the jammed fork out of the frame. It was that day that I learned about quill stems. This was one of the valuable learning experiences that introduced me to some knowledge, and people (including the friendly mechanic with a hammer) that helped me develop in to a halfway decent bicycle mechanic that went on to work in a retail repair shop to help pay his post secondary school tuition.
Several years later, In the course of searching for an issue for Digital Ocean's Hacktober Fest, I stumbled across a small repository written in Rust with an issue with the properties: label:HacktoberFest label:good first issue.
I have had no prior experience with Rust whatsoever, however, since the issue was to write a test for existing code, and it described some utilities to use in the process (the tempfile, escargot, duct and reqwest crates/modules), I figured some of my prior programming experience would help my pick up the new language. This would be a decent opportunity to write some short and relatively simple code to get the test running, and get myself acquainted with the basics of the language.
The repository was for a program that would host a large number of very small compressed files on a server in an efficient manner. The integration test was to generate a bunch of temporary files, run a build of the program to compress the files, then host them on a server, query the server, and iterate through the files that were sent back, decompressing them, and checking the contents of their integrity. Partway through my task, it dawned on me that writing an integration test, required some perspective that only a certain degree of mastery of the language, the repository, and Rust library packages would bring.
I had managed to determine how to write an integration test that would be run with Rust's package manager, Cargo. I had also managed to knock together a quick and dirty way of generating a bunch of files in a temporary directory, use a module to make a command line call to do a debug build of the project's code, use that build to compress the temporary files into an archive, then host that archive. However, I had gotten stuck: I couldn't quite figure out how to properly decompress the file archive after retrieving it from the server, and I had a few questions about implementing the test that came up as I was poking around running the test.
Rust prides itself with providing a happy medium between the need to strictly control memory management as you would in C++. This brought to mind the need to handle the early/unexpected termination of my test function if it failed-especially since the test launched an independent server process, and temporary directories that were created would only be removed by the test logic if their .close() function was called. I remembered the concept of a smart pointer in C++, which wraps a pointer inside an object that is able to call a destructor as soon as the object goes out of scope so memory can be safely de-allocated even if exceptions are thrown. I needed to know if there was a sane way of replicating this behaviour in Rust to handle cleanup of a failed test.
Having decided to be ambitious enough to work with something unfamiliar, and having gotten stuck from a lack of intimate knowledge of something I was unfamiliar with, it was time to either grab the attention of the repository's maintainer, or give up working on the issue. I was apprehensive about creating a pull request for this, since the code was not complete or fully working. To be honest, I probably would have given up on the issue had the maintainer not offered his support on the issue before hand. It was time to submit some code for a review so we could look at what was going on, what the code needed to do (including how to safely kill the server on failure), and to hash out how best all this should be accomplished in greater detail.
Thus far I have received nothing but support from the repo maintainer, and have received some very useful feedback on the code, and my approach to the problem so far. This was the kind of feedback and attitude that helps to provide valuable information in learning long term coding skills. I intend to follow through with this code, and I will return to the repo to try my hand on other issues in the future, hopefully becoming more efficient and helpful as I develop my skills, and giving back in more impactful ways. What's more, having had such a positive response from exposing such ugly code for feedback, I'll probably be less hesitant to do this in the future if it means I can move forward on helping to fix an issue in other repos I'll come across in the future.
And what a simple task it was: I had pulled off the wheels, removed the derailleurs, brakes, brake levers, and shifters in no time until I was down to frame, handlebars and the fork (the bit of the bike that holds the front wheel, and connects to the stem; the bit that holds the bicycle's handlebars). Here was something unfamiliar. The handlebars were clamped into a stem, which then attached to the fork, but the setup looked different than what I had seen on my bicycle--in fact, I had never tried to service that part of my bicycle at all before, so I was doubly unfamiliar with the process.
There were two things that I could loosen, a large bolt on the top of the stem, or a couple of large nuts that held some ball bearings in place. Seeing that I needed to get the thing apart, and loosening the stem bolt yielded no positive results, I proceeded to loosen the nuts, which also did not yield the desired result. I then tried to twist the stem back and forth relative to the fork, and this sudden agitation caused about 64 little metal spheres to cascade down into the frame of the bike, jamming the fork in the frame of the bicycle.
It was about this time that a mechanic noticed what I was doing, sauntered over with hammer, hit the stem bolt with a hammer to release the stem from the rest of the bike (yes, this is the correct way of removing this part--who would have thought?), and then used the hammer to tap the jammed fork out of the frame. It was that day that I learned about quill stems. This was one of the valuable learning experiences that introduced me to some knowledge, and people (including the friendly mechanic with a hammer) that helped me develop in to a halfway decent bicycle mechanic that went on to work in a retail repair shop to help pay his post secondary school tuition.
 |
| Assorted quill stems. When tightened, the bolt (visible at the top of the rightmost stem) pulls the wedge at the bottom of the stem up, and outward to wedge into the inside of the fork's steerer tube (big metal pipe bit that passes through the bicycle frame and is supported by ball bearings to let you steer). To dislodge the wedge from the fork, the bolt is hit with a hammer after loosening. These features of its operation are obscured entirely when assembled in a bicycle. Image By: Corda, CC BY-SA 3.0, Link |
Several years later, In the course of searching for an issue for Digital Ocean's Hacktober Fest, I stumbled across a small repository written in Rust with an issue with the properties: label:HacktoberFest label:good first issue.
 |
| There's something appealing about this logo... |
I have had no prior experience with Rust whatsoever, however, since the issue was to write a test for existing code, and it described some utilities to use in the process (the tempfile, escargot, duct and reqwest crates/modules), I figured some of my prior programming experience would help my pick up the new language. This would be a decent opportunity to write some short and relatively simple code to get the test running, and get myself acquainted with the basics of the language.
The repository was for a program that would host a large number of very small compressed files on a server in an efficient manner. The integration test was to generate a bunch of temporary files, run a build of the program to compress the files, then host them on a server, query the server, and iterate through the files that were sent back, decompressing them, and checking the contents of their integrity. Partway through my task, it dawned on me that writing an integration test, required some perspective that only a certain degree of mastery of the language, the repository, and Rust library packages would bring.
I had managed to determine how to write an integration test that would be run with Rust's package manager, Cargo. I had also managed to knock together a quick and dirty way of generating a bunch of files in a temporary directory, use a module to make a command line call to do a debug build of the project's code, use that build to compress the temporary files into an archive, then host that archive. However, I had gotten stuck: I couldn't quite figure out how to properly decompress the file archive after retrieving it from the server, and I had a few questions about implementing the test that came up as I was poking around running the test.
Rust prides itself with providing a happy medium between the need to strictly control memory management as you would in C++. This brought to mind the need to handle the early/unexpected termination of my test function if it failed-especially since the test launched an independent server process, and temporary directories that were created would only be removed by the test logic if their .close() function was called. I remembered the concept of a smart pointer in C++, which wraps a pointer inside an object that is able to call a destructor as soon as the object goes out of scope so memory can be safely de-allocated even if exceptions are thrown. I needed to know if there was a sane way of replicating this behaviour in Rust to handle cleanup of a failed test.
Having decided to be ambitious enough to work with something unfamiliar, and having gotten stuck from a lack of intimate knowledge of something I was unfamiliar with, it was time to either grab the attention of the repository's maintainer, or give up working on the issue. I was apprehensive about creating a pull request for this, since the code was not complete or fully working. To be honest, I probably would have given up on the issue had the maintainer not offered his support on the issue before hand. It was time to submit some code for a review so we could look at what was going on, what the code needed to do (including how to safely kill the server on failure), and to hash out how best all this should be accomplished in greater detail.
Thus far I have received nothing but support from the repo maintainer, and have received some very useful feedback on the code, and my approach to the problem so far. This was the kind of feedback and attitude that helps to provide valuable information in learning long term coding skills. I intend to follow through with this code, and I will return to the repo to try my hand on other issues in the future, hopefully becoming more efficient and helpful as I develop my skills, and giving back in more impactful ways. What's more, having had such a positive response from exposing such ugly code for feedback, I'll probably be less hesitant to do this in the future if it means I can move forward on helping to fix an issue in other repos I'll come across in the future.
Comments
Post a Comment