Polishing Ruby

by Olivier Lacan

In the talk titled 'Polishing Ruby' at RubyConf 2014, Olivier Lacan addresses how individuals can contribute meaningfully to the Ruby programming language, even if they lack confidence. He encourages attendees to leave Ruby better than they found it, highlighting that contributions don't have to be monumental. Instead, small enhancements can significantly impact the community. Lacan shares personal experiences, detailing his journey building APIs with Ruby and Rails, and the importance of writing tests to safeguard against potential issues.

Key Points Discussed:
- Emphasized the importance of engaging in the Ruby community by contributing to existing projects and defects.
- Shared personal anecdotes regarding the challenges of making substantial changes and overcoming impostor syndrome.
- Introduced the process of submitting feature requests, along with insights on writing clear, actionable proposals that consider the needs of the community.
- Provided examples from his experience with RSpec, discussing how understanding Ruby’s methods like 'include' versus RSpec's matcher can improve functionality and user expectations.
- Encouraged newcomers to start small, whether through documentation improvements or minor features, as every contribution holds value.
- Highlighted collaboration within the Ruby community, showcasing how seasoned Rubyists are eager to support less experienced developers, thus enriching the development ecosystem.
- Recommended utilizing Ruby's issue tracking system for collaboration and proposal submissions, ensuring contributions are meaningful and well-received.

The talk concludes with the message that every individual's insights and experiences within the Ruby ecosystem matter and can propel the language forward. Lacan inspires attendees to gather their ideas, engage with community members, and contribute wherever they see fit, ultimately making Ruby a more beautiful language.

00:00:18.480 Before I start, I want to give you a piece of advice. If you ever want to make a talk or submit a proposal for RubyConf, don’t submit a talk about something that you haven’t done or that you’re unlikely to do by the time RubyConf comes around. That can be really daunting and may amplify feelings of impostor syndrome. I was up really late last night, freaking out about this talk. However, I have a bunch of people here with me, and to cope with my nerves, I brought chocolates. So if you hate this talk, you can come up to me afterward, and I can give you some chocolate, and you’ll feel awesome about it.

00:01:00.000 This talk is called 'Polishing Ruby,' and the subtitle hints at what I mean by that. The idea is that together, even if you’re someone who lacks confidence, we can go through my experience of not being confident with Ruby. The question I want to ask each one of you in this room is: why are you here? It feels great to practice technical skills, but it can be really hard to manage. Why are you here at RubyConf, sitting in a room listening to people talk about Ruby? It’s probably because, at some level, you care about Ruby. I hope you do. What I want to encourage you to think about is how you can leave Ruby better than how you found it—perhaps a few years or just now. If you have any ideas, nobody is asking you to change the world, nor are we expecting you to revolutionize the garbage collector. There are others better suited for that. However, you can still add to Ruby in meaningful ways.

00:01:42.560 I don’t mean just adding 'plus ones' on repositories or simply saying nice things. You can contribute meaningfully by making small changes without trying to customize every aspect. Just take the Ruby community as it is now, and try to enhance its value just a little bit. My name is Olivier, by the way; that’s how you pronounce it—oh, Olivier. And for the record, I’m not a satanist.

00:02:17.120 I feel like I should mention that because everyone on Twitter is super excited to tell me how much I look like the character from Silicon Valley who is a satanist. I promise you I’m not. If you're curious, I work for Code School, where we teach people various things, including Ruby and Rails. If you like these subjects, we have some amazing stickers provided by Katie and Joel. Sadly, we don’t have any shirts left. Recently, I also worked on creating an API for an iOS app. I had built APIs before, but nothing that could create significant issues if they didn’t work. So, I built this API with Ruby and Rails, and astonishingly, I even wrote tests for it.

00:03:05.920 The reason I wrote tests is that I was concerned that if someone, especially me, made changes to the API later, it could potentially break the app without me realizing until someone pointed out that it wasn’t loading the right thing. I was genuinely nervous about this, just as I was worried I’d forget my pants this morning—those are my worst fears. So, I thought, let’s write some integration tests, and then we can all go have ice cream afterward.

00:03:45.920 Given a user, if I ask the user API for something, I should receive data about that user. So, you create a user with a factory or a fixture, and then you call the user API for that specific user. After that, you parse the response, and with RSpec—if you use it—you can write an expectation such as 'expect data to include the name olivier.' This works as you would expect; it’s pretty cool. Let’s go get some ice cream! I had this moment of curiosity while building this API. I thought, can I do a hash check to see if it includes another hash? So, I tried that. I asked the same parsed response and checked if it included that other hash. However, it didn’t work as I expected.

00:04:45.440 The method does not check for that kind of inclusion as I imagined. However, RSpec has a matcher called 'include,' which allows me to create my expectation for the hash. I was puzzled about what the matcher did compared to the 'include' method already present in Ruby. So, I looked into it. The matcher checks if you’re matching a hash against a subset. If both items being compared are hashes, then RSpec will actually check the keys and values to see if they match. It's a great feature, and since I want to ensure that the keys and values match, this functionality was beneficial for my API.

00:05:22.480 Now, there is a word of caution: this only works for one level. You cannot have a nested hash when checking for inclusion in RSpec. It fails if you try to match complex structures. So, I thought, how does the 'hash include' method work in Ruby? It doesn’t behave like I initially thought it would. It’s not as elegant as RSpec but still functions effectively. For instance, you could have a hash with keys 'a' as true and 'b' as false, and then check another hash with 'a' as true. When asking the first hash if it includes the second, it will respond with false. This method effectively checks only the keys.

00:06:20.760 The 'include' method serves as an alias for 'has_key?' in the Ruby core library. Interestingly, Ruby seems to value keys over values. It's often noted that values may end up feeling devalued compared to their associated keys. This realization led me to understand that the necessary features of Ruby could sometimes be overlooked, particularly if they have high astonishment factors. It's essential to consider if a change would genuinely improve the feature or folklore for Ruby. For example, I wondered if expanding the purpose of 'hash include' to accommodate checking for sub-hashes would be an improvement.

00:06:58.960 So, with this idea in mind, I gathered my thoughts and wrote down my feature request, hoping for feedback from my peers. I received plenty of useful input. It was crucial to realize that my expectations and surprises regarding Ruby methods are not always shared by those coming from a computer science background. Consequently, I realized that while I thought my proposal was valid, it might not resonate with those accustomed to the language's existing paradigms. One key takeaway for anyone interacting with Ruby is to avoid making changes that would break existing APIs. The core team prioritizes maintaining API integrity and documentation.

00:07:51.760 Fortunately, through discussions with seasoned Rubyists, I gained insights on how I could proceed with this feature request without breaking existing functionalities. I presented my request, and several people agreed the method should be named something like 'hash contain' as it seemed intuitive to check if one hash contains another. This was a key moment for me. Engaging with this supportive community filled me with a sense of possibility that my features could be integrated into Ruby.

00:08:14.720 As I began to draft the implementation, I discovered the patch process was quite efficient. Even if you feel inexperienced with the C programming language, there are numerous members willing to assist you. The Ruby community contains many experts—like Terence, Zack, Nobu, and many others—who are eager to help. Their contributions significantly benefit the Ruby development process. They will help you even if your arguments and proposals are still developing.

00:08:43.440 Now, transitioning to actionable steps, I want to emphasize the importance of the Ruby issue tracking system, bugs.rubylang.org. Familiarizing yourself with it is essential as it is where you can find ongoing discussions and proposals for feature changes. It may not have the fanciest interface, but it contains invaluable information about helping Ruby and improving its features. The wiki has some really helpful content, especially the section for developers, which includes a guide on how to request new functionality.

00:09:45.120 As you start thinking about your feature request, first assess whether your contribution will be a meaningful improvement to Ruby. Try to define precisely what you want to add and ensure it hasn't already been proposed. For instance, check the existing discussions about adding similar ideas. If the feature you're proposing already exists as a requested change, familiarize yourself with the arguments that led to its rejection or approval. Finally, if there are alternative ways to achieve what you envision, make those known in your discussion.

00:10:12.720 You're likely not alone in your innovations. If many people use the feature you're considering, it's worth facing possible findings that are similar or complementary. If you've been thinking about a feature and it happens to align with the needs of the Ruby community, that’s HUGELY beneficial for everyone. Therefore, I encourage you to dedicate time thinking about naming your proposals. The title should evoke clarity about the feature’s purpose and usability. It helps create smooth discussions and increased visibility.

00:10:51.760 Your feature request needs to be easy to follow. You don’t necessarily have to know Japanese to engage in discussion on issues; what matters is the clarity in your descriptions. Include actual code snippets that illustrate precisely what you are addressing. This level of clarity will keep the focus on engaging with the challenges present in Ruby. Remember that your input is significant, and many people who may not ideally reflect your opinions, will appreciate the effort and time you take to submit clear prose.

00:11:30.080 Follow through on your proposals, especially when the core team interacts with you. Whether the feedback is positive or critical, be receptive, and engage as that helps build and improve solutions. You'll find that many Ruby community members are eager to share their insights and thoughts with you if you ask suitably. Consequently, I want to emphasize that while suggestions for feature requests tend to be more complicated than bug fixes, they also add significant value if they match common needs. However, you should ensure you or another party is ready to maintain them.

00:12:12.640 The Ruby community is vast, and when you become involved, it becomes progressively clearer that you are aiding in enhancing a collective effort. You could try your hand at smaller contributions or even documentation. There are also many significant features awaiting your consideration. Use resources listed on the Ruby documentation website and familiarize yourself with others within the community who can offer guidance and support, as many are excited to engage newcomers seeking guidance.

00:12:54.320 I've seen how others were encouraged to fix documentation errors, to address issues they found and to advocate for those features they felt strongly about. This happens all the time. Start where you feel comfortable. The Ruby documentation project is an excellent starting point for those uncertain about jumping straight into the development process; revising documents can be less intimidating and just as impactful. If you feel apprehensive about submitting patches, instead help improve what is already present. Small contributions matter! They may inspire confidence in others.

00:13:50.320 So, when you engage with Ruby, whether it be through suggestions, development, or maintenance, take time to think critically and start to contribute gradually. As a community, let’s push Ruby forward and make it sparkle, uniting resources and skills available in our network to better Ruby, for lovers of the language. We all share aspirations, goals, and challenges that will ultimately help deepen your knowledge and understanding, which is the backbone of a supportive developer community.

00:14:38.960 As we draw this discussion to a close, remember that across the Ruby ecosystem, each individual matters. Your experiences and insights can drive the language forward, providing valuable perspectives that can be addressed with fresh eyes. Gather your thoughts, engage with individuals in the Ruby community who inspire you, and contribute where you see fit. Thank you all for being here today, and I hope you leave feeling informed and inspired to make Ruby all the more beautiful.