Skip to content

Commit

Permalink
update readme
Browse files Browse the repository at this point in the history
  • Loading branch information
asmello committed Dec 2, 2023
1 parent 5301534 commit 32f7bb6
Show file tree
Hide file tree
Showing 2 changed files with 52 additions and 0 deletions.
49 changes: 49 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,2 +1,51 @@
# aoc2023
My solutions to Advent of Code 2023

## Goals

- Experiment with some new tooling, language features and crates.
- Test different approaches and design trade-offs.
- Improve how I approach problem-solving.
- Have some fun.

## Anti-goals

- Rank high in the scoreboards. I'm not doing this competitively.
- Write the fastest, cleverest, most idiomatic or most concise code.
- Make optimal choices. I want to learn, including from mistakes.

## How this project is organized

I'm developing this as a library, with each day implemented as a module.

```
aoc2023
├──  src
│ ├──  lib.rs
│ ├──  day1.rs
│ ├──  day2.rs
│ └──  day2
│ ├──  chumsky.rs
│ └──  manual.rs
└──  tests
├──  common
│ └──  mod.rs
├──  day1.rs
├──  day2.rs
└──  resources
├──  day1
│ └──  input.txt
└──  day2
└──  input.txt
```

In general each day module will export two functions, `part1()` and `part2()`, which implement the solutions to each part of the day's challenge. For now, I'm planning to have each take `impl Read` as the main argument representing the full input. Although I expect all problems will have a reasonably small input that can comfortably fit in a String, this generic interface is a good way to practice building a more realistic API. Note that some problems involve additional parameters that may also be passed to these functions.

Some modules may contain submodules with alternative implementations. Since I'm taking an educational approach to these challenges, it is sometimes useful to compare different implementations. When this happens I'll export one of the implementations at the day module. The other implementations will also be public.

I'm implementing most tests as integration tests. Each day gets its own integration test module under `tests/`. This helps ensure I keep the public library interface adequate, as I'm effectively using it like an external consumer would (not that I expect any). Someone once told me a good (programming?) life hack is to always be your own client.

## Roadmap

- Complete the 2023 challenges
- Maybe add a CLI tool?
3 changes: 3 additions & 0 deletions src/day2.rs
Original file line number Diff line number Diff line change
@@ -1,6 +1,9 @@
pub mod chumsky;
pub mod manual;

// default implementation
pub use chumsky::{part1, part2};

#[derive(Debug, Default, PartialEq, Eq)]
struct Game {
id: usize,
Expand Down

0 comments on commit 32f7bb6

Please sign in to comment.