blog(aoc-2022): fix typos

Signed-off-by: Matej Focko <me@mfocko.xyz>

blog/aoc-2022/01-week-1.md

@@ -227,7 +227,7 @@ It may seem as a very weird decision, but in fact it makes some sense… It allo
 you to do intersection of items that may not be possible to copy. Overall this is
 a „tax“ for having a borrow checker ~~drilling your ass~~ having your back and
 making sure you're not doing something naughty that may cause an **undefined**
-**behaviour**.
+**behavior**.
 
 :::
 
@@ -328,7 +328,7 @@ A lot of different approaches, knowing that we are dealing with input consisting
 solely of ASCII letters, I bit the bullet and went with sliding window and
 constructing sets from that window, checking if the set is as big as the window.
 
-One possible optimization could consist of keeping a bitvector (i.e. `usize`
+One possible optimization could consist of keeping a bit-vector (i.e. `usize`
 variable) of encountered characters and updating it as we go. However this has
 a different issue and that is removal of the characters from the left side of the
 window. We don't know if the same character is not included later on.
@@ -341,7 +341,7 @@ of 26 elements that keeps count for each lowercase letter.
 
 :::info tl;dr
 
-Let's simulate [`du`] to get some stats about our filesystem and then pinpoint
+Let's simulate [`du`] to get some stats about our file system and then pinpoint
 directories that take a lot of space and should be deleted.
 
 :::
@@ -351,7 +351,7 @@ directories that take a lot of space and should be deleted.
 
 ### Solution
 
-We need to „_build_“ a filesystem from the input that is given in a following form:
+We need to „_build_“ a file system from the input that is given in a following form:
 ```
 $ cd /
 $ ls
@@ -401,7 +401,7 @@ Then I looked up some implementations of trees or linked lists and decided to tr
 `Box<T>` represents a dynamically allocated memory on heap. It is a single pointer,
 you can imagine this as `std::unique_ptr<T>` in C++.
 
-`Rc<T>` represents a dynamically allocated mmemory on heap. On top of that it is
+`Rc<T>` represents a dynamically allocated memory on heap. On top of that it is
 _reference counted_ (that's what the `Rc` stands for). You can imagine this as
 `std::shared_ptr<T>` in C++.
 
@@ -419,7 +419,7 @@ to have `Rc<RefCell<T>>`.
 
 :::
 
-So, how are we going to represent the filesystem then? We will use an enumeration,
+So, how are we going to represent the file system then? We will use an enumeration,
 hehe, which is an algebraic data type that can store some stuff in itself :weary:
 ```rust
 type FileHandle = Rc<RefCell<AocFile>>;
@@ -443,7 +443,7 @@ Now to the fun part! `AocFile` value can be represented in two ways:
   contain map matching the name of the files (or directories) within to their
   respective file handles
 
-I will omit the details about constructing this filesystem, cause there are a lot
+I will omit the details about constructing this file system, cause there are a lot
 of technicalities introduced by the nature of the input. However if you are
 interested, you can have a look at my solution.
 
@@ -466,7 +466,7 @@ solution.
 One of the more exotic options would be precomputing the required information at
 the same time as parsing. That could be done by adding additional fields to the
 nodes which would allow storing such information and updating it as we construct
-the filesystem.
+the file system.
 
 ## Post Mortem
 

blog/aoc-2022/02-week-2.md

@@ -93,7 +93,7 @@ them both to `usize` type that can be used later on for indexing.
 The type signature of the function is where the fun is at :wink: We are trying
 to convert unknown type to `usize`, so we must bound the `T` as a type that can
 be converted to `usize`, that's how we got `usize: TryFrom<T>` which basically
-says that `usize` must implement `TryFrom<T>` trait vand therefore allows us to
+says that `usize` must implement `TryFrom<T>` trait and therefore allows us to
 convert the indices to actual `usize` indices. Using `.unwrap()` also forces us
 to bound the error that can occur when converting `T` into `usize`, that's how
 we get `<usize as TryFrom<T>>::Error: Debug` which loosely means
@@ -107,7 +107,7 @@ And now we are left only with the first line of the definition.
 
 :::note
 
-Skilled Rustaceans might notice that this implemention is rather flaky and can
+Skilled Rustaceans might notice that this implementation is rather flaky and can
 break in multiple places at once. I'll get back to it…
 
 :::
@@ -358,7 +358,7 @@ where
 ```
 
 This is all part of the `Solution` trait, which can implement methods while being
-dependant on what is provided by the implementing types. In this case, we just
+dependent on what is provided by the implementing types. In this case, we just
 need to bound the `Output` type to implement `Display` that is necessary for the
 `info!` and format string there.
 
@@ -589,7 +589,7 @@ also rolling down the hill…
 
 As I have said in the _tl;dr_, we are looking for the shortest path, but the start
 and goal differ for the part 1 and 2. So I have decided to refactor my solution
-to a BFS algorithm that takes neccessary parameters via functions:
+to a BFS algorithm that takes necessary parameters via functions:
 ```rust
 fn bfs<F, G>(
     graph: &[Vec<char>], start: &Position, has_edge: F, is_target: G