fix: misc typos

Author: pieterocp

_posts/2017-03-26-auto-balancing-7-hours-tests-between-100-parallel-jobs-on-ci-buildkite-example.md

@@ -59,7 +59,7 @@ There is one more useful thing which is retry failed CI node feature. You can ju
 We are going to use [knapsack_pro gem with Queue Mode for RSpec](https://docs.knapsackpro.com/overview/#queue-mode-dynamic-split).
 You can find here info how to add it to your Gemfile and [install knapsack_pro for your project](https://docs.knapsackpro.com/knapsack_pro-ruby/guide/).
 
-Knapsack Pro supports buildkite environment variables to determine git commit, branch name and number of parallel jobs. The only thing you need to do is to configure the parallelism parameter in your pipeline step and run the appropiate knapsack_pro command.
+Knapsack Pro supports buildkite environment variables to determine git commit, branch name and number of parallel jobs. The only thing you need to do is to configure the parallelism parameter in your pipeline step and run the appropriate knapsack_pro command.
 
 **Create pipeline:**
 

_posts/2020-06-13-how-to-run-slow-rspec-files-on-github-actions-with-parallel-jobs-by-doing-an-auto-split-of-the-spec-file-by-test-examples.md

@@ -23,7 +23,7 @@ To solve the problem of a slow test file, we need to split what's inside it. We
 
 First, it needs work. Although admittedly quite plausible in a described scenario, in real life it's usually not just the one file that's causing problems. Oftentimes there is a number of slow and convoluted test files, with their own complex setups, like nested `before` blocks, `let`s, etc. We've all seen them (and probably contributed to them ending-up this way), haven't we? ;-) Refactoring files like that is no fun, and there seem to always be more higher priority work to be done, at least from our experience.
 
-Second, we belive that the code organization should be based on other considerations. How you create your files and classes is most likely a result of following some approach agreed upon in your project. Dividing classes into smaller ones so that the CI build can run faster encroaches on your conventions. It might be more disturbing to some than the others, but we feel it's fair to say it'd be best to avoid - if there was a better way to achieve the same...
+Second, we believe that the code organization should be based on other considerations. How you create your files and classes is most likely a result of following some approach agreed upon in your project. Dividing classes into smaller ones so that the CI build can run faster encroaches on your conventions. It might be more disturbing to some than the others, but we feel it's fair to say it'd be best to avoid - if there was a better way to achieve the same...
 
 ## Enter split by test examples
 

_posts/2021-02-18-how-to-build-knapsack-pro-api-client-from-scratch-in-any-programming-language.md

@@ -96,7 +96,7 @@ Users can define those environment variables in their CI server settings to cont
 
   - CI build has many parallel CI nodes. Each parallel CI node should have the same `KNAPSACK_PRO_CI_NODE_BUILD_ID` value. This means the parallel CI nodes belong to the same CI build.
   - Knapsack Pro client by default should try to detect CI build ID for popular CI providers by looking for it in the environment variables.
-  - If `KNAPSACK_PRO_CI_NODE_BUILD_ID` value was defined by the user then it should be used during a request to the Knapsak Pro API. It has [higher priority](https://github.com/KnapsackPro/knapsack-pro-core-js/blob/0f44c6a3daa369cd4353e315abbf5539295289ea/src/config/knapsack-pro-env.config.ts#L79,L81) than [detected CI build ID from a CI provider](https://github.com/KnapsackPro/knapsack-pro-core-js/blob/0f44c6a3daa369cd4353e315abbf5539295289ea/src/config/knapsack-pro-env.config.ts#L83,L86) environment variables.
+  - If `KNAPSACK_PRO_CI_NODE_BUILD_ID` value was defined by the user then it should be used during a request to the Knapsack Pro API. It has [higher priority](https://github.com/KnapsackPro/knapsack-pro-core-js/blob/0f44c6a3daa369cd4353e315abbf5539295289ea/src/config/knapsack-pro-env.config.ts#L79,L81) than [detected CI build ID from a CI provider](https://github.com/KnapsackPro/knapsack-pro-core-js/blob/0f44c6a3daa369cd4353e315abbf5539295289ea/src/config/knapsack-pro-env.config.ts#L83,L86) environment variables.
   - If the user did not define `KNAPSACK_PRO_CI_NODE_BUILD_ID` then a default value `missing-build-id` should be used.
     - Knapsack Pro API understands `missing-build-id` string and knows the CI build has an undefined CI build ID then. In such a case only one parallel CI build can be run at a time for a given set of values (`git commit hash` AND `branch name` AND `number of parallel CI nodes`) - otherwise, tests could be accidentally split between 2 CI builds.
       - Why this set of values matter? From the Knapsack Pro API perspective, a unique CI build is a set of test files that belongs to a git commit hash, branch name and it is split across a certain number of parallel CI nodes. When the user will run a few CI builds at the same time for the same git commit, branch name and on the same number of parallel CI nodes then we need a way to distinguish CI builds from each other. That's why CI build ID is useful and recommended to be pass in request to Knapsack Pro API.
@@ -347,7 +347,7 @@ For instance use:
 
 ## README
 
-It's good to create a well-documentented README for your packages. You can get inspired by checking documentation for:
+It's good to create a well-documented README for your packages. You can get inspired by checking documentation for:
 
 - [`@knapsack-pro/core` readme](https://github.com/KnapsackPro/knapsack-pro-core-js#knapsack-procore)
 - [`@knapsack-pro/jest` readme](https://github.com/KnapsackPro/knapsack-pro-jest#knapsack-projest)

_posts/2021-04-01-how-and-when-to-use-ruby-case-statements.md

@@ -121,7 +121,7 @@ when (8..10) then 'high value'
 end
 {% endhighlight %}
 
-One last tip. You can provide multiple patterns for each `when`. This would effectively mimic the logical `||` operator, with each pattern beig compared against.
+One last tip. You can provide multiple patterns for each `when`. This would effectively mimic the logical `||` operator, with each pattern being compared against.
 To illustrate this, let's expand on a previous example:
 
 {% highlight ruby %}