This winter break I gave myself the project of becoming more proficient in standard Ruby (sans Rails). In order to do this I did a bunch of coding challenges. One of the sets of challenges I tried was an Advent calendar made up of coding puzzles.
I wanted to write up a blog post about what what I learned about Ruby from gaining all 50 advent of code stars. I did a great job of erasing all Rails from my mind this break and concentrating on my programming fundamentals and use of Ruby. This will probably hurt a lot when I return to class on Monday but it also helped to cement things I’ve learned so far and teach me new things about programming. So here are a couple of things I learned from this winter adventure.
Advent of Code is a 25 day challenge leading up to December 25. It’s a fun project put together so that it’s accessible for all skill levels and can be completed in any programming language. I am definitely bookmarking AoC for when I have to learn a new programming language. I tried the first five days in R and Ruby and it helped me relearn a lot of the R I’ve slowly been pushing out of my brain. My GitHub repo of AoC can be found here. This is not the prettiest code in the world and there are definitely exercises I’m more proud of than others, but regardless of code quality it’s something I finished and I learned a lot in the process. Here are a few of the things I learned.
1. Range of CS-Related Topics
What I really liked about the layout of the challenges is that most touched on a range of topics in the development world. One challenge took advantage of parsing JSON files, something web devs would know a lot about. One talked about MD5 hashes, and another about password encryption, which relates to cybersecurity. There was a challenge that related to hardware, one for bitwise operators, and lots of interesting sorting problems. It was a fantastic array of subjects to learn about for someone who has only been programming for a little while. I learned a lot about Regular Expressions as many of the puzzles had to do with large amounts of string input. I also was able to brush up on my math for the puzzles that involved coordinates. Overall, once you have the basics of a language down, doing coding puzzles like this can really help introduce you to CS topics when you did not go to school for that. The one area where my background in economics helped me was on an optimality constraint problem where you calculate happiness of guests based on who they are sitting next to. But besides that, I was pretty lost when solving problems with “jumps” and “registers” and learned a lot in the process.
2. Every Language Has Strengths and Weaknesses
During my three weeks of working on Advent of Code, I spent a lot of time on the AoC sub-Reddit reading about how people saw the problem and looking at code in Python, Java, C#, C++, Ruby, and many many more languages. I had the most fun with people’s solutions that didn’t even use code at all, but instead used pen and paper and manual logic to solve the problem. In this process, I started to realize how lucky I was to have Ruby for some of the more Object Oriented problems (everything in Ruby is an object, EVERYTHING!) and how sad I felt on the Math problems or things like bitwise operators where other languages naturally excel. By about the 10th day I could really tell if a problem could be easily solved in Ruby right away and just see the algorithm in my head if that were the case.
3. Classes, Hashes, Arrays, oh my!
I learned a lot about the various advantages and disadvantages of data structures doing these puzzles. I generally am inclined towards using arrays and hashes, but there were many times I had to scrap my algorithm half-way through realizing that I should create my own class instead. Classes are great ways to organize related data and reuse that information later. My first reaction as a new programmer is always to go for a simple way of storing the data like an array. Working through more complex puzzles made me teach myself to use objects much more often. Instances could sometimes hold information so much more clearly than hashes could. This was the most helpful on the horrible two days at the end of the puzzles where you had to basically build an RPG in order to calculate minimums. I also quickly began to adapt using hashes much more often than arrays. The information in a hash can be unordered and pulled out without an index, but with a reasonable call like a name or identifier, which is super helpful when you have a lot of information and don’t want to remember the order. I kicked myself many times for using arrays early on and then having no idea where my data was by the end of the code. I also internalized a lot about classes and object creation in the longer puzzles.
4. Countless Amazing Ruby Things
The biggest thing I learned during the last two weeks has been all of the amazing Ruby modules, methods, gems, etc. that make doing hard stuff easy. The three biggest modules I learned advanced things about while solving the puzzles were Array, Enumerable, and Regexp. I probably know or have seen every Ruby enumerable at this point. Here are my new favorite Ruby things in no particular order:
- #each_cons(n): gives you arrays of n amount in consecutive order so if you called it on [1, 2, 3, 4] and wanted arrays of 2 it would give you back [1, 2], [2, 3], [3, 4]. Isn’t that grand? Great for combinations of linear items.
- #combination(n) and #permutation(n): Give an array and the number of elements in each array and get all combinations or permutations of that array. The difference between these two methods was hard to get used to. Basically, if order matters you want a combination and if it doesn’t, go for permutation.
- Class: Set: I used sets a lot instead of array#uniq in order to push only uniq items into a data structure.
- Module: Benchmark: Provides methods to measure and report time used to execute the code. When I wasn’t sure if I was just being inefficient or stuck in an infinite loop, I’d use Benchmark.
- #each_with_index: Oh, God. What would I do without #each_with_index? This method allows you to do what each does but also keep track of the index you are at in the array.
- Class: Digest.hexdigest: Returns the hex-encoded hash value of a given string, helpful for the cyber security questions.
- #zip: takes one element from an array and merge the corresponding elements from each array, zipping them together.
- Rubular: a website that allows you to play around with Ruby regular expressions.
- Handling of bitwise operators (binary numerals at the bit level) showcased well in this article.
- #sub, #match, #gsub, #inspect, #take and #name_captures: all ways to handle regular expressions and find string or digit matches inside a particular string. #name_captures even returns a hash! Figuring out how to use all these correctly was a major hurdle and felt great to overcome.
There are many more awesome Ruby things I learned in this process. I also enjoyed comparing Ruby solutions with other languages. I would love to return to these one day and solve them in another language (or two!).
5. Scalability a.k.a. “THERE’S A PART TWO?!”
A great thing about AoC is that every puzzle had a second part. That second part was either easy or hard to solve, usually based on how you set up the first part. With that in mind, it was always helpful to not be hack-y in your solution to the first part. This caused me to spend more time thinking through what the puzzle was asking than brute force hacking.
6. ❤ pry & irb ❤
This post is dedicated to irb and pry. I love you. And you are my best friends in Ruby. Thank you. You will find commented out (and a few stray not-commented-out) binding.pry’s in all of my code. Debugging was key to finishing these puzzles.