Sentence edit suggestions & spelling typos (#46)

* sentence-wording

* typo

* full-word

* typo

* full-functions

* typo

* typo

* typos

* functions

* typos

* gitignore typo

* fix line length lint errors

* revert funcs

* cSpell words

* Revert "cSpell words"

This reverts commit e1cd7c9.

---------

Co-authored-by: Nikko Miu <nikko@miu.guru>

content/guides/golang-graphql-ent/02-gqlgen-setup.md

@@ -38,8 +38,8 @@ import (
 ```
 
 Let's break down what's in this file. First we put a comment to define the Go build environment. In this case we set it
-to tools so that (by default when building the app) this file isn't included in the build. Next we setting the
-package for this file. Since we aren't including it in the build we can call it whatever we want (so don't worry that
+to tools so that (by default when building the app) this file isn't included in the build. Next we will set the package
+for this file. Since we aren't including it in the build we can call it whatever we want (so don't worry that
 it doesn't match the root-level `package` in `main.go`). Finally, we just need to use the `_` (blank identifier) for
 the packages since we don't actually _use_ them.
 
@@ -160,7 +160,7 @@ We are only adding the last of the `files.exclude`. The other entries in this ar
 by default.
 {{</ callout >}}
 
-## (Optional) Add to .gitingore
+## (Optional) Add to .gitignore
 
 Before we commit our changes, we're going to add the generated code that we don't change (more on that later) to a
 `.gitignore` file:

content/guides/golang-graphql-ent/03-ent-setup.md

@@ -388,7 +388,7 @@ Now we should have `ent` set up for our app, the first schema defined, and datab
 
 {{< callout type=note >}}
 I don't get into it much in this guide, however, `ent` is technically a graph database adapter. Having ent designed to
-work with graph databases allows for some very intersting and complex graph traversals over our data to query for data
+work with graph databases allows for some very interesting and complex graph traversals over our data to query for data
 in an easy to use way.
 
 For more information on ent, take a look at [their documentation](https://entgo.io/docs/getting-started).

content/guides/golang-graphql-ent/04-wire-gqlgen-to-ent.md

@@ -63,7 +63,7 @@ method within the ent package that was generated.
 {{< callout type=note >}}
 You may be wondering why we have a `NewResolver()` and a `NewServer()` method where both are exported. You may also be
 wondering why we pass the `context.Context` into the `NewServer()` but not `NewResolver()`. In both of these cases, we
-are settingare doing it this way for testing.
+are doing this to prepare for testing.
 
 When we write tests for the GraphQL Resolvers, we will need to use the `NewResolver()` method so we can call the
 resolver methods. It's also easier for testing if we pass the `*ent.Client` instead of the `context.Context` since it's
@@ -440,7 +440,7 @@ query {
 
 ## Add Remaining CRUD Resolvers
 
-We now have the ability to create a note, get a note by Node ID using the `node()` resolver, and listing all Notes.
+We now have the ability to create a note, get a note by Node ID using the `node()` resolver, and list all Notes.
 Let's finish up by adding the update and delete methods to round out our CRUD operations. Open the
 `gql/note.resolvers.go` and implement the `UpdateNote(context.Context, int, model.NoteInput)` and
 `DeleteNote(context.Context, int)` methods like this:

content/guides/golang-graphql-ent/05-paging-sorting-filtering.md

@@ -9,8 +9,8 @@ tags:
   - ent
 ---
 
-Now that we have `ent` and `gqlgen` wired up, we can look at updaing our list notes resolver. In this section, we will
-look at implementing paging, sorting, filtering, and where clauses to provide a more robust experience to our client
+Now that we have `ent` and `gqlgen` wired up, we can look at updating our list notes resolver. In this section, we will
+look at implementing paging, sorting, and filtering using where clauses to provide a more robust experience to our client
 applications.
 
 <!--more-->
@@ -222,7 +222,7 @@ func (r *queryResolver) Notes(ctx context.Context, after *entgql.Cursor[int], fi
 }
 ```
 
-## Filtering
+## Add Filtering
 
 For filtering, we need to update the `ent` extension responsible for GraphQL generation. The extension needs to be
 configured to generate `WhereInput`s:

content/guides/golang-graphql-ent/06-cleanup.md

@@ -240,7 +240,7 @@ First, we're creating an interface (remember that interfaces in go should end in
 interface and extend it with an `ExitCode() int` method. So any struct that implements both `error` and `ExitCode() int`
 can now be considered an `ExitCoder`.
 
-Then, we're just creating the struct that implements this interface (with a static compliation check that we do actually
+Then, we're just creating the struct that implements this interface (with a static compilation check that we do actually
 properly implement this interface). We also include the `Unwrap() error` method so the error can be unwrapped using the
 `errors.Unwrap() error` method that is in the Go `errors` package.
 
@@ -431,7 +431,7 @@ func Int(key string, defaultValue int) int {
 }
 ```
 
-### Using our Envornment Variable Package
+### Using our Environment Variable Package
 
 ```go {file="pkg/config/app.go"}
 func GetApp() App {

content/guides/golang-graphql-ent/08-resolver-testing.md

@@ -55,12 +55,12 @@ func TestPing(t *testing.T) {
 
 Here, we are creating our method with a prefix of `Test` so Go will run this as a test method. When testing, we also
 need to pass a `*testing.T` struct into our func. The `*testing.T` is used to run sub-tests, setup testing environment,
-fail tests, etc. For now, we will just manually do our asssertions but later, we will refactor this to use an assertion
-library to reduce the amount of repetetive code.
+fail tests, etc. For now, we will just manually do our assertions but later, we will refactor this to use an assertion
+library to reduce the amount of repetitive code.
 
 Within our test method, we set our expected value (`pong`), initialize our resolver with a `nil` `*ent.Client`
 since for this test we don't rely on ent to resolve this, then create a context that will be canceled when we're done
-with this test (as a `context.Context` is the first parameter of all of our resoulvers). Then, we call the resolver that
+with this test (as a `context.Context` is the first parameter of all of our resolvers). Then, we call the resolver that
 we're trying to test. Finally, we assert that the values are matching what we're expecting. Since this resolver func is
 so simple, we only have one test case and don't have any error conditions to check.
 
@@ -89,7 +89,7 @@ go test ./gql/...
 The next set of tests that we can easily cover are the Note resolvers. These are the properties that exist on the Note
 struct that don't directly map to a database field (`NodeID`, `BodyMarkdown` and `BodyHTML`). Since these also don't
 rely on ent to resolve, we still won't need to set the `*ent.Client` when we create our resolver and even though there
-is an error condtition in our code for the `BodyHTML` resolver, I don't have an easy way to test it since all text
+is an error condition in our code for the `BodyHTML` resolver, I don't have an easy way to test it since all text
 should be valid Markdown.
 
 ```go {file="gql/note_test.go"}
@@ -332,7 +332,7 @@ now will yield an error like:
 cgo: C compiler "gcc" not found: exec: "gcc": executable file not found in $PATH
 ```
 
-To fix this error, we need to install our C compiler toolchian by modifying the following in the Dockerfile for the Dev
+To fix this error, we need to install our C compiler toolchain by modifying the following in the Dockerfile for the Dev
 Container:
 
 ```dockerfile {file=".devcontainer/Dockerfile",add_lines=6}
@@ -511,7 +511,7 @@ Similar to how we implemented the `ContextT(*testing.T) context.Context` we are
 into its own func that we can call from our tests. Again with this we will register a `Cleanup` func to close our
 database connection (and delete the database since we are using an in-memory SQLite database).
 
-Just update the `TestNode` func to use our new `EntT(*tesitng.T) *ent.Client`:
+Just update the `TestNode` func to use our new `EntT(*testing.T) *ent.Client`:
 
 ```go {file="gql/common_test.go",add_lines=3,rem_lines="4-5"}
 func TestNode(t *testing.T) {

content/guides/golang-graphql-ent/09-misc-testing.md

@@ -19,7 +19,7 @@ current simplicity of our `main.go` I'm not too worried about testing it using t
 ## pkg
 
 Let's look first at our `pkg` tests. These are going to be pretty simple and after we completed the resolvers there are
-only a copule of new things that we need to cover in order to complete these tests. Let's build them up starting from
+only a couple of new things that we need to cover in order to complete these tests. Let's build them up starting from
 the `env` package.
 
 ### Env
@@ -875,7 +875,7 @@ func executeWithArgs(ctx context.Context, args []string) (stdout string, stderr
 {{< callout type=note >}}
 Now that we have these options added (and public) to the `cmd` package, we can now change our testing project to use the
 `_test` suffix. If you remember, the main reason we weren't able to do this to start was because we didn't have access
-to the `rootCmd` from outisde the package. However, with these `Option`s in place, we can now access and utilize all of
+to the `rootCmd` from outside the package. However, with these `Option`s in place, we can now access and utilize all of
 this without needing our tests **within** our `cmd` package. I'm going to switch mine over, but you don't have to if you
 don't want.
 {{</ callout >}}
@@ -1008,7 +1008,7 @@ what we did in this to understand the individual parts of the testing. Most of t
 overly-complicated will soon make it easier to see that this is a "framework" that makes writing tests easier and leaves
 less room for hard to follow tests, complicated setup and teardown, etc.
 
-With theset changes we now have a solid foundation for writing testable code as well as writing the tests for it. This
+With the set changes we now have a solid foundation for writing testable code as well as writing the tests for it. This
 is great because we don't have to set up large scale testing frameworks, or create complex testing plans to validate
 that our application is working as expected. Plus, with the `context.Context` and our
 `ContextT(t *testing.T) context.Context` we make sure that our testing doesn't leak "async" code actions (since we