00:00:03.360
Hey everyone, we are about to start, but first I want to acknowledge that we have some audio issues. We'll fix those during the longer break. Now, let me introduce our next speaker, Vincandandro. He currently lives in Japan and is a really nice guy; he brought Japanese snacks to dinner last night, which was great! Today, he is going to share his contributions to Ruby, specifically the implementation of the CSV::TSV module. So, please give him a warm round of applause.
00:00:48.970
Thank you very much for this opportunity to speak to you all about my journey contributing to Ruby. I never thought I would be able to share my experiences about contributions and how they can become part of a Ruby release. Today, my presentation will cover some technical aspects, but I will try to simplify them for everyone. We'll start with a discussion of basic problems that many developers face and the solutions to those, as well as an overview of the entire contribution process that includes reviewers and testing.
00:01:06.799
I'm particularly focused on long-term implications because this theme is about thinking long-term in Ruby. Just a bit of introduction about myself: I'm a software engineer based in Japan, and it took quite some time to travel all the way to this part of the world. I'm mostly interested in both hardware and software development, so I often build things that bridge these areas, particularly in the Internet of Things (IoT) realm as well as industrial IoT.
00:01:54.320
While working with Ruby, my recent contribution was not my first open-source contribution, but it took about a month to bring to fruition. Given that we are discussing the long-term impact of decisions made in programming, we need to remember that contributions to any open-source library are not just about our own convenience. We must think in terms of decades, understanding that while days may feel long, decades can pass quickly. Every line of code we write carries significance and technical weight that may impact the developer community for many years.
00:02:29.920
For instance, I worked on a TSV—the tab-separated values format. Many of us are familiar with CSV (comma-separated values), but did you know that the information bioinformatics community frequently uses TSV instead? They find it easier to process because it consumes less space and is generally faster. However, I was surprised to find that Ruby lacked built-in support for TSV when many other programming languages, like Python and R, have it.
00:03:01.120
This made me question why such a widely used language didn't have a straightforward implementation for handling TSV files. It led to some self-doubt about whether my contribution to create such an API would actually have a lasting impact. After all, contributions can often seem repetitive if someone else has tackled similar issues before. Yet, through this process, I realized that even simple case studies reveal truths about how we can enhance our experiences with programming.
00:03:40.800
When programming with TSV today, we typically have to specify that we are using tab-separated values instead of comma-separated ones, which can be cumbersome. For new developers, it’s not always clear that they need to provide the correct parameterization. I found that many developers, regardless of experience, were unaware of how to work with TSVs in Ruby, leading to an unnecessary learning curve. This realization echoed my earlier thoughts—if Ruby developers want to work effectively with TSVs, there must be a more intuitive way to do so.
00:05:01.679
During my exploration, I found that in January 2023, another developer expressed the same concern regarding the lack of support for TSV in Ruby, highlighting the cumbersome eight keystrokes required to specify tab separation. It seemed clear that advocating for a simpler solution in Ruby could not only help current developers but also enhance the overall Ruby ecosystem. Proposing a new feature often requires courage, especially in contexts where existing solutions may be seen as sufficient.
00:06:04.399
Discussions about handling TSV ended up being categorized into two major problems: should we support TSV, and if so, how should we implement the separator? Initially, I was unsure whether to propose both an alias and a TSV class. My first pull request was quickly closed because the reviewers preferred a more phased approach. A new perspective surfaced during this process: contributions to core libraries should be atomic and incremental to ensure stability. After making adjustments to focus only on creating the TSV class, that proposal eventually succeeded and gained acceptance.
00:07:19.680
The crucial aspect learned was that major changes to core libraries should be made incrementally. One essential lesson here is that when submitting pull requests, addressing one issue at a time is much more effective. This prevents the review feedback from becoming overwhelming and ensures quality involvement in discussions about future functionalities. The feedback I received during this stage taught me that a successful API design must consider simplicity and maintainability.
00:09:13.439
While working on this project, I had numerous interactions with reviewers focused on the final design and implementation. Following their guidance led to a much simpler solution than my original proposal. It became fundamentally important to think about how API designs could evolve over the long term and what implications my decisions could have on other developers taking advantage of this feature.
00:10:29.520
The final solution uses a mere three lines of code and inherits functionality directly from the CSV class. This significantly reduces maintenance overhead for the maintainers. Furthermore, it simplifies the user experience by allowing easy use of TSV just by importing the CSV module. This solution reflects core design principles, such as reducing surprises for users and providing a straightforward implementation for working with both CSV and TSV formats.
00:11:46.079
This change laid the groundwork for a more intuitive user experience for Ruby users. However, it also raised questions about writing adequate test cases to catch edge cases, such as handling empty files and handling invalid filenames. Focusing on comprehensive test coverage became key in supporting robust long-term changes to library codes. We must understand that when developing libraries, each component should adapt and evolve through user feedback and requirement changes.
00:13:08.480
I also had to navigate namespace considerations. Initially, I preferred to simplify usage with a direct namespace for easier access. But I learned from reviewer comments that a more foundational approach could mitigate potential conflicts with future libraries. Prioritizing ecosystem stability over immediate developer convenience was an essential revelation that came up numerous times during discussions.
00:14:22.799
Going through the review process emphasized the importance of accommodating backward compatibility. Many requested changes during these discussions highlighted how maintaining stability is critical to the success of core libraries. It was a valuable experience to recognize that while immediate fixes can seem convenient, prioritizing longer-term stability results in fewer breaking changes, ultimately benefiting the developer community in the long run.
00:15:37.860
Eventually, after a month, my contribution made its way into the Ruby release. It was surprising to see my changes adopted, but even more gratifying was knowing that my contributions would make life easier for fellow Ruby developers. Now, directly importing CSV also allows developers to work with TSV seamlessly. Seeing my code integrated into the official Ruby release served as a strong motivational boost that reminded me of the significance of persistent and thoughtful contribution.
00:17:32.480
To conclude, every contribution, no matter how small, can have a long-lasting impact. We should strive to contribute perspectives that consider not only today's needs but those that may resonate with future developers 10 or 20 years down the line. As a newcomer to the Ruby community, I invite everyone to think critically about long-term problem-solving in open-source contributions, as the diversity of perspectives helps shape better solutions.
00:18:48.159
Thank you for listening to my experiences today. I hope these insights on building for the future resonate with you. Ruby has a vibrant community, and together, we can work toward enhancing its long-term viability by designing APIs that stand the test of time. There’s great potential for contributions, especially when we consider diverse perspectives in our community. Even if you're just starting, I encourage you to raise issues, propose changes, and actively participate in the development process. Every small effort counts, and I’m here to assist as you begin your journey in open-source contributions.
