Ruby for Good 2020 06 Sep 2020

This weekend I dove into my first (sadly remote) hackathon: Ruby for Good! This event has participants from around the world collaborate to build software for non-profits of all kinds (from tool libraries to captive snail breeding programs ). The full list of projects can be found at the R4G github organization; most are ongoing and welcome contributions from developers and designers of all skill levels. I chose to join the CASA project: A Rails-based application to help facilitate the actions of non-profit Court-Appointed Special Advocate organizations.

From small bugs to big bugs

This project has been in development for some time, and is by far the largest application that I have worked on. Luckily, the CASA team leads were very welcoming and started me out nice and slow. One of the first lessons learned was how to use Github Issues to manage feature requests and bug reports, as well as provide documentation for future contributors. The first issue I tackled was a straightforward (or so I thought): add line breaks in a view file to keep line length below 120 characters. This simple request lead to me learning more about code formatting, linting, and the yarn package manager. Please read on for some laughs as a new developer learns by doing. I even link to pull requests.

• Line breaks need to be semantically relevant.

My first attempt at this task had me dutifully entering line breaks at any point that would make the lines less than 120 chars. While I achieved this goal, it did nothing for readability, and I provided next to no documentation. Thankfully I have a very patient team lead.

• Linters can make breaking changes; make sure to examine all changed files.

After learning that I didn’t need to just add one line break, but should add as many as necessary to make truly readable code, I dutifully followed my leader’s suggestions. Chastened by my initial mistake, I decided to be extra thorough and run a linter. (I am such a dutiful developer.) One minor snag, however. If my PR were merged into master, I would have taken the entire mailing system offline. Luckily these changes were caught once again, and I was able to add a config file for the linter preventing others from making my mistake in the future.

• Examine staging closely and WRITE TESTS.

The CASA project runs a CI build of our current production branch on a Heroku instance, and we were encouraged to jump on and play around with it. During one such session I encountered an unhandled error in one of the forms. Well: find it, fix it! Finally I’m starting to get the hang of the workflow. After diving into the code I found an improperly formed request was sent to the controller. Rails magic would allow this request to succeed until it was sent with an empty field which crashed the app. After properly configuring the form to send strong parameters I solved the issue. A quick crash course in RSpec allowed me to write my first test as well! Finally, a PR I can be proud of

Until next time!

My first day of my first hackathon was a hoot ! I’ve learned so much over the course of the weekend, and luckily I get to go back next weekend as well! I highly recommend R4G.