init Repo Readme
This commit is contained in:
commit
54b6bcb45e
175
.gitignore
vendored
Normal file
175
.gitignore
vendored
Normal file
@ -0,0 +1,175 @@
|
||||
# Byte-compiled / optimized / DLL files
|
||||
__pycache__/
|
||||
*.py[cod]
|
||||
*$py.class
|
||||
|
||||
# C extensions
|
||||
*.so
|
||||
|
||||
# Distribution / packaging
|
||||
.Python
|
||||
build/
|
||||
develop-eggs/
|
||||
dist/
|
||||
downloads/
|
||||
eggs/
|
||||
.eggs/
|
||||
lib/
|
||||
lib64/
|
||||
parts/
|
||||
sdist/
|
||||
var/
|
||||
wheels/
|
||||
share/python-wheels/
|
||||
*.egg-info/
|
||||
.installed.cfg
|
||||
*.egg
|
||||
MANIFEST
|
||||
|
||||
# PyInstaller
|
||||
# Usually these files are written by a python script from a template
|
||||
# before PyInstaller builds the exe, so as to inject date/other infos into it.
|
||||
*.manifest
|
||||
*.spec
|
||||
|
||||
# Installer logs
|
||||
pip-log.txt
|
||||
pip-delete-this-directory.txt
|
||||
|
||||
# Unit test / coverage reports
|
||||
htmlcov/
|
||||
.tox/
|
||||
.nox/
|
||||
.coverage
|
||||
.coverage.*
|
||||
.cache
|
||||
nosetests.xml
|
||||
coverage.xml
|
||||
*.cover
|
||||
*.py,cover
|
||||
.hypothesis/
|
||||
.pytest_cache/
|
||||
cover/
|
||||
|
||||
# Translations
|
||||
*.mo
|
||||
*.pot
|
||||
|
||||
# Django stuff:
|
||||
*.log
|
||||
local_settings.py
|
||||
db.sqlite3
|
||||
db.sqlite3-journal
|
||||
|
||||
# Flask stuff:
|
||||
instance/
|
||||
.webassets-cache
|
||||
|
||||
# Scrapy stuff:
|
||||
.scrapy
|
||||
|
||||
# Sphinx documentation
|
||||
docs/_build/
|
||||
|
||||
# PyBuilder
|
||||
.pybuilder/
|
||||
target/
|
||||
|
||||
# Jupyter Notebook
|
||||
.ipynb_checkpoints
|
||||
|
||||
# IPython
|
||||
profile_default/
|
||||
ipython_config.py
|
||||
|
||||
# pyenv
|
||||
# For a library or package, you might want to ignore these files since the code is
|
||||
# intended to run in multiple environments; otherwise, check them in:
|
||||
# .python-version
|
||||
|
||||
# pipenv
|
||||
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
|
||||
# However, in case of collaboration, if having platform-specific dependencies or dependencies
|
||||
# having no cross-platform support, pipenv may install dependencies that don't work, or not
|
||||
# install all needed dependencies.
|
||||
#Pipfile.lock
|
||||
|
||||
# poetry
|
||||
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
|
||||
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
||||
# commonly ignored for libraries.
|
||||
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
|
||||
#poetry.lock
|
||||
|
||||
# pdm
|
||||
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
|
||||
#pdm.lock
|
||||
# pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
|
||||
# in version control.
|
||||
# https://pdm.fming.dev/#use-with-ide
|
||||
.pdm.toml
|
||||
|
||||
# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
|
||||
__pypackages__/
|
||||
|
||||
# Celery stuff
|
||||
celerybeat-schedule
|
||||
celerybeat.pid
|
||||
|
||||
# SageMath parsed files
|
||||
*.sage.py
|
||||
|
||||
# Environments
|
||||
.env
|
||||
.venv
|
||||
env/
|
||||
venv/
|
||||
ENV/
|
||||
env.bak/
|
||||
venv.bak/
|
||||
|
||||
# Spyder project settings
|
||||
.spyderproject
|
||||
.spyproject
|
||||
|
||||
# Rope project settings
|
||||
.ropeproject
|
||||
|
||||
# mkdocs documentation
|
||||
/site
|
||||
|
||||
# mypy
|
||||
.mypy_cache/
|
||||
.dmypy.json
|
||||
dmypy.json
|
||||
|
||||
# Pyre type checker
|
||||
.pyre/
|
||||
|
||||
# pytype static type analyzer
|
||||
.pytype/
|
||||
|
||||
# Cython debug symbols
|
||||
cython_debug/
|
||||
|
||||
# PyCharm
|
||||
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
|
||||
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
|
||||
# and can be added to the global gitignore or merged into this file. For a more nuclear
|
||||
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
|
||||
#.idea/
|
||||
|
||||
# Generated by Cargo
|
||||
# will have compiled files and executables
|
||||
debug/
|
||||
target/
|
||||
|
||||
# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
|
||||
# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
|
||||
Cargo.lock
|
||||
|
||||
# These are backup files generated by rustfmt
|
||||
**/*.rs.bk
|
||||
|
||||
# MSVC Windows builds of rustc generate these, which store debugging information
|
||||
*.pdb
|
||||
70
README.md
Normal file
70
README.md
Normal file
@ -0,0 +1,70 @@
|
||||
# Advent of Code 2022
|
||||
|
||||
## Overview
|
||||
Welcome to my repository where I share my solutions for the [Advent of Code 2022](https://adventofcode.com/2022). Advent of Code is an annual online event where participants solve a series of programming puzzles released daily from December 1st until December 25th. Each puzzle is a fun and unique challenge designed to test problem-solving skills.
|
||||
|
||||
## Structure
|
||||
This repository is organized to make navigation through the solutions as seamless as possible.
|
||||
Each day's puzzle solution is in its respective folder, named `DayXX`, where `XX` is the day of the month.
|
||||
|
||||
- `Day01`
|
||||
- `Day02`
|
||||
- `...`
|
||||
- `Day25`
|
||||
|
||||
Within each folder, you'll find:
|
||||
|
||||
- `README.md`: A brief description of the day's problem.
|
||||
- Source code files: My solution for the day's puzzle, typically in Python or Rust
|
||||
- `input.txt`: The input data provided for the puzzle.
|
||||
- Additional resources or notes if applicable.
|
||||
|
||||
## My Approach
|
||||
For Advent of Code 2022, I've decided to primarily use Python due to its readability and the extensive libraries available, which make it an excellent choice for solving diverse and complex problems quickly. In each solution, I focus not only on solving the problem but also on writing clean, efficient, and well-documented code.
|
||||
|
||||
## Progress
|
||||
Here I'll track my progress throughout the event.
|
||||
I aim to complete each day's puzzle on the same day, but as with any challenge, there might be some delays.
|
||||
|
||||
## Progress
|
||||
|
||||
| Day | Part One | Part Two | Reflections |
|
||||
|-----|----------|----------|-------------|
|
||||
| 01 | ✅ | ✅ | [Day01 README](/Day01/README.md) |
|
||||
| 02 | ❓ | ❓ | [Day02 README](/Day02/README.md) |
|
||||
| ... | ... | ... | ... |
|
||||
| 25 | ❓ | ❓ | [Day25 README](/Day25/README.md) |
|
||||
|
||||
- ✅ Completed
|
||||
- ❓ Not Started / In Progress
|
||||
|
||||
## Running the Solutions
|
||||
Each solution is a standalone script.
|
||||
To run any of the solutions, navigate to the respective day's directory and run the script using a Python interpreter.
|
||||
Make sure you have Python installed on your machine. The solutions are developed using Python 3.x.
|
||||
For example:
|
||||
|
||||
```bash
|
||||
cd Day01
|
||||
python part2.py
|
||||
```
|
||||
|
||||
For Rust you have to use the rust project generated in each Day.
|
||||
Make sure you have Rust and Cargo installed.
|
||||
You can either test or run the solution:
|
||||
|
||||
```bash
|
||||
cd Day01/rust
|
||||
cargo test
|
||||
cargo run
|
||||
```
|
||||
|
||||
Using solutions in JavaScript requires NodeJS installed on your system. Then:
|
||||
```bash
|
||||
cd Day01/js
|
||||
node solution.js
|
||||
```
|
||||
|
||||
## Feedback and Collaboration
|
||||
I'm always open to feedback and suggestions for improving the solutions.
|
||||
If you have ideas or find an issue, feel free to open an issue or submit a pull request.
|
||||
Loading…
Reference in New Issue
Block a user