Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/maxdeviant/advent-of-code
Advent of Code
https://github.com/maxdeviant/advent-of-code
advent-of-code advent-of-code-2015 advent-of-code-2016 advent-of-code-2017 advent-of-code-2018 advent-of-code-2019 advent-of-code-2020 advent-of-code-2021 advent-of-code-2022
Last synced: about 1 month ago
JSON representation
Advent of Code
- Host: GitHub
- URL: https://github.com/maxdeviant/advent-of-code
- Owner: maxdeviant
- License: mit
- Created: 2017-12-02T00:38:19.000Z (about 7 years ago)
- Default Branch: main
- Last Pushed: 2023-12-10T18:06:03.000Z (about 1 year ago)
- Last Synced: 2024-11-05T18:54:56.779Z (3 months ago)
- Topics: advent-of-code, advent-of-code-2015, advent-of-code-2016, advent-of-code-2017, advent-of-code-2018, advent-of-code-2019, advent-of-code-2020, advent-of-code-2021, advent-of-code-2022
- Language: Rust
- Homepage: https://adventofcode.com/
- Size: 597 KB
- Stars: 1
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Advent of Code
This repository contains my solutions to the [Advent of Code](https://adventofcode.com/) puzzles.
I would highly encourage solving each puzzle on your own before looking at my solutions, lest you deprive yourself of the satisfaction of solving it yourself.
## Directory
| Year | Language(s) |
| -------------- | ---------------------------------------------------- |
| [2015](./2015) | [PureScript](./2015/purescript) |
| [2016](./2016) | [PureScript](./2016/purescript) |
| [2017](./2017) | [F#](./2017/fsharp), [PureScript](./2017/purescript) |
| [2018](./2018) | [Rust](./2018/rust) |
| [2019](./2019) | [Haskell](./2019/haskell) |
| [2020](./2020) | [PureScript](./2020/purescript) |
| [2021](./2021) | [PureScript](./2021/purescript) |
| [2022](./2022) | [Rust](./2022/rust) |
| [2023](./2023) | [Rust](./2023/rust) |## My Process
When solving Advent of Code puzzles I try to approach them the way I would in the real world. I tend to take a [domain-driven design](https://en.wikipedia.org/wiki/Domain-driven_design) approach where I model the domain of the puzzle before actually attempting to solve it.
Another thing that you might notice is that in my solutions I always keep the first part of the puzzle working when I implement the second. Again, this is due to my desire to mirror real-world scenarios. Very often you must keep existing functionality working when the requirements change or new functionality is added. For a while I thought that this was a common practice, but as I've looked at other people's solutions it seems that this isn't the case: I've seen many people whose final solver only solves the second part of the puzzle.