Things I Learned During the Advent of Code

Written by Pete Corey on Jan 1, 2018.

If you know me, you know that I’m a huge fan of programming challenges and code katas. Sometimes I think I missed my calling as a competitive programmer.

This past month I was able to satisfy my cravings for programming challenges with Eric Wastl’s Advent of Code.

Solving a programming challenge every day for nearly a month taught me interesting lessons about myself and my current programming language of choice: Elixir.

Here’s a quick rundown.

  • You’ll have good days. - There will be days where your mind is running on all cylinders. Solutions to problems will appear fully formed in your mind’s eye, and completing challenges is simply a matter of dictating your envisioned solution.

  • You’ll have bad days. - There will be other days where your mind feels like a tangle of rusty nails stuck together in a bucket of dried cement. Solutions will come slowly, if they come at all.

  • Most days will land somewhere in-between. - It’s important to try to avoid letting your perceived state of mind influence your decisions and determination. When I felt like I was having trouble, falling back to first principles always seemed to help devise a path forward.

  • Elixir’s Stream library is awesome. - Sasa Juric’s solutions to the first few days of Advent of Code inspired me to look into Elixir’s Stream module. I was so impressed with the module that I wrote an article on generating sequences with streams, and I went on to solve a good number of advent challenges with Stream-based generators.

  • Stick to the basics. - I found that my first instinct when sketching out a solution to a problem was to reach for functions shipped in standard modules like Enum, List, and Map. However, studying other people’s solutions made me realize that sticking to the basics of recursion and pattern matching can lead to more elegant, readable, and performant solutions.

  • Erlang ships with everything and the kitchen sink. - A few of this year’s challenges led me to standard modules shipped with Erlang and accessible from Elixir. Modules like :digraph, :digraph_utils, :gb_trees, and :binary are incredibly useful and overlook utilities.

  • You don’t want to split on empty strings. You want a list of graphemes. - Use String.graphemes/1 instead of String.codepoints/1 or String.split(&1, "") to split a string into its component characters. Read all about codepoints and grapheme clusters for more information.

  • Elixir’s “extended” regex modifier helps explain away the black magic. - Regexes are often cesspools of black magic. It often takes just as long, if not longer, to understand a written regex than to write it from scratch. Thankfully, Elixir’s “extended” modifier lets you explain away some of the black magic in your regexes by splitting them across multiple lines and interleaving comments.

  • Studying other people’s solutions can teach powerful lessons. - Nearly every language-specific tip or technique I learned during this year’s Advent of Code challenge came from studying other people’s solutions after I implemented my own. Reading other people’s code is, hands down, the most powerful tool for improving your own code.

I had a lot of fun with this year’s Advent of Code challenges. I learned quite a bit about Elixir and about myself. I even made some good friends in the #adventofcode channel of the Elixir Slack group.

I’ll definitely be doing this again next year.

If you didn’t do this year’s Advent of Code, it’s not too late! Go check out the problems, and if you’re curious, check out my solutions on Github.

Do you know that a man is not dead while his name is still spoken?

Written by Pete Corey on Dec 25, 2017.

In my free time I’ve been making many trips to Discworld over the past few months. I’ve been rereading my favorites like Going Postal, and devouring other classics like Hogfather for the first time.

I thought I’d take a pause this Christmas and offer up my contribution to an ongoing tribute to the late Terry Pratchett.

You know they’ll never really die while the Trunk is alive… It lives while the code is shifted, and they live with it, always Going Home.
— Terry Pratchett, Going Postal

The Clacks, as described in Going Postal, is a system of trans-continental semaphore towers used to send messages across great distances. Each packet of text sent through the Clacks is encoded using a set of standardized codes and encodings.

Sounds familiar, doesn’t it?

The codes G, N, and U, stand for “send the message on”, “do not log the message”, and “turn the message around at the end of the line” respectively. In Going Postal, these codes are used to send a character’s name perpetually up and down the Clacks.

As long as his name is spoken, he will never die.

We can write a Plug function to easily broadcast our own Clacks overhead messages from our Phoenix server:


pipeline :browser do
  ...
  plug :gnu_terry_pratchett
end

def gnu_terry_pratchett(conn, options) do
  Plug.Conn.put_resp_header(conn, "X-Clacks-Overhead", "GNU Terry Pratchett")
end

Of course, this is all a fantasy. The Clacks aren’t real, Terry’s name won’t live forever in the overhead, and any X-Clacks-Overhead messages we send will simply be ignored by the world at large.

That being said, “humans need fantasy to be human”.

HUMANS NEED FANTASY TO BE HUMAN. TO BE THE PLACE WHERE THE FALLING ANGEL MEETS THE RISING APE.
“Tooth fairies? Hogfathers? Little—”
YES. AS PRACTICE. YOU HAVE TO START OUT LEARNING TO BELIEVE THE  LITTLE  LIES.
“So we can believe the big ones?”
YES. JUSTICE. MERCY. DUTY…
— Terry Pratchett, Hogfather

Let's Get Personal

Written by Pete Corey on Dec 18, 2017.

Two and a half years ago I officially incorporated my first company and started my independent consulting career under the name “East5th, Inc.”

At that time, I really didn’t know what I wanted out of my business, or what it would ultimately grow into. When deliberating whether to go into business under my own name or under the guise of a company, I figured that working behind a fictional entity would be the safer choice.

Over the years, I’ve come to realize that this was the wrong choice for me.

Fun fact: I picked the name “East5th, Inc.” because:

  1. I lived on East 5th Avenue.
  2. My accountant suggested I tack “Inc.” to the end because, well, that’s just what you do.

Pros and Cons

You’re afforded certain freedoms when you do business as a fictional entity. You’re able to easily scale your business to multiple employees, which in turns lets you easily distance yourself from your business and eventually exit.

I don’t want either of these things.

When I first started out on my own, I imagined building a small team around myself and managing projects entirely in-house from start to finish. While I’ve done some of that and I do enjoy it, I’ve found that I do my best work when I deeply integrate myself into an existing team or project. I want to focus on the technical aspects of my work, not the complexities of managing a team.

I’ve also come to the realization that I don’t want an exit strategy. I’ve never been happier with my career than I am right now. I love the teams I’ve worked with over the years, and I love the projects we’ve worked on together. I love writing and sharing the things I’m excited about with the world.

I’m in this for life.

Good Night, East5th

All of that is a roundabout way of saying that I’ve made the decision to drop the “East5th” name. Effective immediately, this site will become www.petecorey.com. Old links to www.east5th.co will continue to work and redirect to the new domain. Additionally I’ve renamed my Medium account from “@east5th” to @petecorey.

I’m hoping this change will bring a me a new set of freedoms, like the freedom to be more honest, open, and authentic with my writings and projects.