Wednesday, January 10, 2018

Getting Better at Ruby for #AdventOfCode2017

Because I'm a computing educator, I don't write code every day. I'd be lying if I said I didn't miss it. So when I heard about Advent of Code late 2017, I knew I wanted to participate.

In its third year, Advent of Code was created by Eric Wastl. On each day of December up to and including Christmas Day, a new problem is released at midnight Eastern time. Each registered user gets personalized input, and when you solve part one of the problem, a second, usually more difficult, part is revealed. Each part earns you a star. The faster you get your stars, the higher you are ranked. There's a global leaderboard showing the top participants.


I wasn't too interested in the competition aspect, knowing I couldn't be up at midnight every night working on code. Instead, I decided to commit to solving the problems as close to when they came out as I could for my circumstances. I also decided to use Ruby so I could remember the basics I used to know from working in Rails for half a year, and learn about the language on its own a bit more deeply.

I managed to solve almost all the problems the day they came out, with just two or three being finished the day after due to time constraints (read: two young children). I also learned a lot about Ruby, from the unexpected things you can do with hashes to its memory model, and more. My favourite trick was using a two-item array representing an x-y coordinate as a key to a hash.

More importantly, it was really really fun writing code every day. I couldn't believe how addicting it was. Most of the problems were fairly easy to solve using Ruby (sometimes it felt like it was cheating using that particular language!), though some were much trickier conceptually. None of them completely thwarted me though, and I managed to figure them all out on my own without looking online. Earning each star was very satisfying.

The code as I wrote it is now up on my Github – no editing after the fact. I know I'm not following all the Ruby conventions (I really do prefer camel case for example), and I'm probably being more verbose than a lot of folks doing this competition (I love readable code). Now that the competition is over, you can see all the problem descriptions to understand what I'm trying to achieve. (I think you still have to solve part 1 to see the part 2 description, though.)