This is a small repo for coding and testing solutions to Advent of Code puzzles.
This year I decided to write in JS because I know it well and I wanted to try and stick with it. I'm guessing that using a familiar language will cut down on the time it takes to solve each day and remove the frustrating gap between knowing the solution but not getting it to work right because of my ignorance of a new language. Both of those should give me a better shot at actually completing this year.
I also decided to write up my thought process and solution explanations on my blog. Here's a link to the index post that links out to all the other solutions.
Last year was super successful and I finished all the puzzles! So this year I'm going to stick with JS since it's working. Here's the link to the new blog post.
I'm going back and doing the 2015 year during the summer of 2022. I'm going to attempt to do each day in JS, Haskell, and Rust. As with the other years, here's a link to the blog post.
December 2022 is upon us. You know the drill by now. JS as the main language, maybe some others sprinkled in here and there, and the annual blog post.
New year with another new group of people. I'm going to do it in JS as usual but I'm toying with the idea of doing a rust port at the end with a specific time-based performance budget for all the solutions for the year in rust. I'm going to hold off on the blog posting for now since I'm so far behind on writing up previous years. I'll update here when I catch up and start writing these up.
We're back again with primarily JS. I rewrote my whole website and the way all the posts and notes are hosted, so I'm in the process of transitioning all the write-ups to that. I'm also toying with the idea of making a nice TUI cli runner thing in Rust that would allow me to build/show/run these in multiple languages and do visualizations and stuff. Hopefully I'll have some time this year to work on these ideas.
Over the course of doing these puzzles, I've come up a standard library of helper functions. These are things that are either verbose or common enough to warrant a well defined and tested function.
I'm experimenting with including both a functional and prototype extension version of most of these functions so that they can be used easily in any circumstance. Some of these are not direct translations from one paradigm to the other though. Also, extending base JS is a pretty standard anti-pattern that I'm well aware of. Use at your own risk, don't use anything in this repo as an example of good production code.
The solutions are in the ./src
folder organized by year and day. To simplify setup, testing, and running, all the days adhere to a template structure.
Each day folder has:
code.js
— must export asolutionOne
andsolutionTwo
input.txt
— the puzzle input downloaded from AOCpuzzle.md
— a copy of the puzzle text in markdowntest.spec.js
— a spec file with whatever tests for the day. This should test thesolutionOne
andsolutionTwo
functions fromcode.js
.index.js
— must export an object with the following interface
{
label: "Label for the day's answer", // purely for display purposes
path: `${__dirname}/input.txt`, // always this exactly
solutionOne,
solutionTwo,
answers: ['one', 'two'], // answers with real inputs for e2e purposes
};
To add a new day, run the CLI new
command (see below) which will copy a template day to the year and day specified.
# Install deps
npm install
# Clean and run build in watch mode for dev
npm run dev
# Running tests
npm run test
npm run test -- --watch 2020/01 # run just 2020 day 1 in watch mode
# Run build once
npm run build
# Run all puzzles and see the solution output (requires a build to run)
npm start
I've also started working on CLI for running different days and getting/submitting answers. Right now it only runs solutions.
To install the CLI run
# In the project root
npm run build
# if you want to install just the source version you built
# you'll have to reinstall after each built
npm i -g .
# or if you want to code and build and re-run via global `aoc` (recommended)
npm link
# Test it installed correctly
aoc run --help
To add a templated day
aoc new <year> <day>
Then while working on a solution the typical workflow is something like this. (given you used the npm link
installation)
- Run build watcher and tests in background
- Once the tests are passing, run the CLI for the real input and get an answer
# In one terminal
npm run dev
# In another terminal, watch the day's tests
npm test -- --watch 2020/01
# Once tests are green, run and get an answer
aoc run -y 2020 -d 01
I occasionally write solutions in other languages for fun. Here are some quick ways to run them given you have the required toolchain installed.
- Elixir:
elixir code.exs
- Haskell:
runhaskell code.hs
- Rust:
cargo run
- Build a better CLI probably using rust
- Build a better Rust specific runner
- Build a better Haskell specific runner
Probably the goal is a top level TUI with folders per language so I can use their tools/project setup. Something like
┌ cli
└ langs
├ elixir
├ gleam
├ haskell
├ js
├ lox
└ rust
This would also give me the opportunity to make CLIs in each of these languages that the TUI would call out to.