docs: fix typos (#278)

Co-authored-by: Pieter <[email protected]>

CONTRIBUTING.md

@@ -16,7 +16,7 @@ Build the required images with:
 $ make images
 ```
 
-The images get built with [cargo-chef](https://github.com/LukeMathWalker/cargo-chef) and therefore support incremental builds (most of the time). So they will be much faster to re-build after an incremental change in your code - should you wish to deploy it locally straightaway.
+The images get built with [cargo-chef](https://github.com/LukeMathWalker/cargo-chef) and therefore support incremental builds (most of the time). So they will be much faster to re-build after an incremental change in your code - should you wish to deploy it locally straight away.
 
 Create a docker persistent volume with:
 

api/src/auth.rs

@@ -297,7 +297,7 @@ impl UserDirectory {
             &file_path
         ))?;
         let users = toml::from_str(&file_contents)
-            .context("this should blow up if the users.toml file is unparseable")?;
+            .context("this should blow up if the users.toml file is unparsable")?;
         let directory = Self {
             users: RwLock::new(users),
         };

api/src/build.rs

@@ -38,9 +38,9 @@ pub(crate) struct FsBuildSystem {
 }
 
 impl FsBuildSystem {
-    /// Intialises the FS Build System. Optionally you can define the root
+    /// Initialises the FS Build System. Optionally you can define the root
     /// of its file system. If unspecified, will default to `FS_ROOT`.
-    /// The FS Build System will fail to intialise if the directory does not.
+    /// The FS Build System will fail to initialise if the directory does not.
     /// exist
     pub(crate) fn initialise(path: Option<PathBuf>) -> Result<Self> {
         let fs_root = path.unwrap_or_else(|| PathBuf::from(DEFAULT_FS_ROOT));

cargo-shuttle/src/init.rs

@@ -330,7 +330,7 @@ pub fn cargo_init(path: PathBuf) -> Result<()> {
     let cargo_config = cargo::util::config::Config::default()?;
     let init_result = cargo::ops::init(&opts, &cargo_config)?;
 
-    // Mimick `cargo init` behavior and log status or error to shell
+    // Mimic `cargo init` behavior and log status or error to shell
     cargo_config
         .shell()
         .status("Created", format!("{} (shuttle) package", init_result))?;

cargo-shuttle/tests/integration/README.md

@@ -1,3 +1,3 @@
 # Integration Tests for `cargo-shuttle`
 
-Integration tests are organised following [matklad's recommedations](https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html).
+Integration tests are organised following [matklad's recommendations](https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html).

service/src/lib.rs

@@ -12,7 +12,7 @@
 //! Shuttle is an open-source app platform that uses traits and annotations to configure your backend deployments.
 //!
 //! ## Usage
-//! Start by installing the [`cargo shuttle`](https://docs.rs/crate/cargo-shuttle/latest) subcommand by runnning the following in a terminal:
+//! Start by installing the [`cargo shuttle`](https://docs.rs/crate/cargo-shuttle/latest) subcommand by running the following in a terminal:
 //!
 //! ```bash
 //! $ cargo install cargo-shuttle
@@ -286,9 +286,10 @@ extern crate shuttle_codegen;
 /// ## shuttle managed dependencies
 /// The following dependencies can be managed by shuttle - remember to enable their feature flags for the `shuttle-service` dependency in `Cargo.toml` and configure them using an attribute annotation:
 ///
+
 /// | Argument type                                                            | Feature flag        | Attribute            | Dependency                                                                                         | Example                                                                          |
 /// | ------------------------------------------------------------------------ | ------------------- | -------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
-/// | [`PgPool`](https://docs.rs/sqlx/latest/sqlx/type.PgPool.html)            | sqlx-postgres       | `shared::Postgres`   | A shared PostgresSql instance accessed using [sqlx](https://docs.rs/sqlx)                          | [GitHub](https://github.com/getsynth/shuttle/tree/main/examples/rocket/postgres) |
+/// | [`PgPool`](https://docs.rs/sqlx/latest/sqlx/type.PgPool.html)            | sqlx-postgres       | `shared::Postgres`   | A shared PostgresSQL instance accessed using [sqlx](https://docs.rs/sqlx)                          | [GitHub](https://github.com/getsynth/shuttle/tree/main/examples/rocket/postgres) |
 /// | [`Database`](https://docs.rs/mongodb/latest/mongodb/struct.Database.html)| mongodb-integration | `shared::MongoDb`    | A shared MongoDb database accessed using the [mongodb](https://docs.rs/mongodb) driver             | [GitHub](https://github.com/getsynth/shuttle/tree/main/examples/poem/mongodb)    |
 /// | [`MySqlPool`](https://docs.rs/sqlx/latest/sqlx/type.MySqlPool.html)      | sqlx-aws-mariadb    | `aws::rds::MariaDB`  | An AWS RDS MariaDB instance tied to your instance and accessed using [sqlx](https://docs.rs/sqlx)  |                                                                                  |
 /// | [`MySqlPool`](https://docs.rs/sqlx/latest/sqlx/type.MySqlPool.html)      | sqlx-aws-mysql      | `aws::rds::MySql`    | An AWS RDS MySql instance tied to your instance and accessed using [sqlx](https://docs.rs/sqlx)    |                                                                                  |

service/tests/resources/not-lib/src/main.rs

@@ -1,5 +1,5 @@
 // This will fail to compile since it is missing a `[lib]` section in its Cargo.toml file.
 
 fn main() {
-    println!("this is not valid as it is not a libray!");
+    println!("this is not valid as it is not a library!");
 }

www/_blog/2022-06-01-hyper-vs-rocket.mdx

@@ -230,7 +230,7 @@ Using the same benchmark as Hyper, on average Rocket returned **43,899** request
 
 ## Conclusion
 
-Writing both of theses examples were fun to build and there weren't any frustrations or problems using them. Both are plenty fast for performance to be a concern.
+Writing both of these examples were fun to build and there weren't any frustrations or problems using them. Both are plenty fast for performance to be a concern.
 
 Rockets documentation is very good and explanatory. All of Hyper's api is well documented on its [docs.rs page](https://docs.rs/hyper/latest/hyper/). Both libraries are actively developed with many commits and pull requests made in the last month.
 

www/_blog/2022-06-09-the-builder-pattern.mdx

@@ -478,7 +478,7 @@ However both of these don't the use the nice chaining syntax.
 
 ## Conclusion
 
-The builder pattern can help you write cleaner, more readable APIs, and it turn help the consumers of your APIs write better code. We can apply constraints to make sure that our structs are intialised correctly with a clean API enforcing the contract.
+The builder pattern can help you write cleaner, more readable APIs, and it turn help the consumers of your APIs write better code. We can apply constraints to make sure that our structs are initialised correctly with a clean API enforcing the contract.
 
 One thing to remember is that code is read *much* more than it's written - so it's worth going out of our way to make our code just that little bit more pleasant to read.
 

www/_blog/2022-06-16-a-short-introduction-to-async-rust.mdx

@@ -150,7 +150,7 @@ Rather than getting weather **then** getting the news. The above code starts bot
 
 <hr styles="margin-top: 5px"/>
 
-To keep this post short and to the basics we will stop here. If you want to read more about writing async the there is the [official Rust async book](https://rust-lang.github.io/async-book/) and [Tokio has a brillant tutorial](https://tokio.rs/tokio/tutorial).
+To keep this post short and to the basics we will stop here. If you want to read more about writing async the there is the [official Rust async book](https://rust-lang.github.io/async-book/) and [Tokio has a brilliant tutorial](https://tokio.rs/tokio/tutorial).
 
 ### Conclusion
 

www/_blog/2022-06-23-generative-metatag-images.mdx

@@ -266,7 +266,7 @@ Compared to the headless browser technique this process is faster. While doing a
 
 With some rough benchmarks the Rust loading, rendering and encoded was two times faster than the nodejs puppeteer equivalent (100ms vs 200ms). 
 
-This time accounts for the startup time in the nodejs version. If you aren't retaining the browser window then the results are even more noticable. Generating one of images (*cold start*) the Rust version is 7x faster.
+This time accounts for the startup time in the nodejs version. If you aren't retaining the browser window then the results are even more noticeable. Generating one of images (*cold start*) the Rust version is 7x faster.
 
 Aside from rendering performance the Rust version is self contained, only the compiled binary is needed to generate the image. No having to worry about whether chromium is in the environment. This is huge benefit if you are doing image generation in a serverless environment.