Merge pull request #419 from holochain/fix/typo

fix: several minor typos

src/pages/concepts/11_lifecycle_events.md

@@ -46,7 +46,7 @@ We covered both of these callbacks in the section on [validation](../7_validatio
 
 Shortly after a cell is instantiated and connects to the network, the conductor looks for an init callback in every coordinator zome. This function is a place to initialize source chain data with necessary information, or make connections to peers, or anything necessary to bootstrap the cell. When all coordinator zomes in a cell have finished executing their init callback, the final [genesis record](../3_source_chain/), the 'init complete' action, is written to the source chain.
 
-An init callback can return 'pass', 'fail' with an error string, or a list of unresolved dependencies. If one init callback fails, initialiation of the entire cell fails and the cell is put into a disabled state.
+An init callback can return 'pass', 'fail' with an error string, or a list of unresolved dependencies. If one init callback fails, initialization of the entire cell fails and the cell is put into a disabled state.
 
 !!! warn Lazy initialization
 The init callbacks aren't actually called until the first time something calls a function in any coordinator zome.

src/pages/concepts/2_application_architecture.md

@@ -32,7 +32,7 @@ These data integrity rules create a membrane between a participant and her peers
 
 There's another membrane, which sits between a participant and her copy of the application. The application's public functions define the processes that can be used to access, interpret, and create data, as well as communicate with other participants and applications. Her copy of the application makes those functions available to any client on her machine that wants to act on her behalf, such as a UI or a scheduled script. Those functions are also made available to her peers in the same network so she can delegate some of her agency to them. The application developer can give her tools to control access to these functions using [capability-based security](../8_calls_capabilities/).
 
-![One participant's copy of the hApp. A membrane surrounds her hApp. On her device, three clients are successfully calling the hApp's functions while a malware is rejected. From the network, two peers try to call her hApp's functions; one succeds while another fails.](/assets/img/concepts/2.3-process-membrane.png){.sz80p} {.center}
+![One participant's copy of the hApp. A membrane surrounds her hApp. On her device, three clients are successfully calling the hApp's functions while a malware is rejected. From the network, two peers try to call her hApp's functions; one succeeds while another fails.](/assets/img/concepts/2.3-process-membrane.png){.sz80p} {.center}
 
 ## Layers of the application stack
 
@@ -54,7 +54,7 @@ The client is like the front end of a traditional app and can be written with wh
 
 ### Conductor
 
-![A participant's conductor hosts multiple hApps for her, mediating the connections between the hApp and her clients, as well betwee then hApp and other participants' conductors running the same hApp.](/assets/img/concepts/2.5-conductor.png){.sz80p} {.center}
+![A participant's conductor hosts multiple hApps for her, mediating the connections between the hApp and her clients, as well between then hApp and other participants' conductors running the same hApp.](/assets/img/concepts/2.5-conductor.png){.sz80p} {.center}
 
 The hApp is hosted in the participant's **conductor**. It's the runtime that sandboxes and executes hApp code, handles cryptographic signing, manages data flow and storage, and handles connections both locally with clients and remotely with peers. When the conductor receives a function call, it routes it to the right function in the right hApp.
 
@@ -129,7 +129,7 @@ That's the entire stack of a Holochain hApp. Let's review, this time from the in
 2. One or more zomes are bundled into a **DNA**, which is like a microservice that defines all the rules for a given network.
 3. A DNA comes alive as a **cell** bound to an agent ID, running on behalf of a participant.
 4. One or more cells are slotted into roles in a **hApp**, which makes up an application's back end.
-5. A participant's **conductor** hosts the hApps she uses, mediating local and network access to them and executig their code.
+5. A participant's **conductor** hosts the hApps she uses, mediating local and network access to them and executing their code.
 6. The participant's **clients** access the hApp via the conductor's local RPC interface, while the conductor also allows the hApp to communicate with other participants' cells that belong to the same networks.
 
 ## Key takeaways

src/pages/concepts/4_dht.md

@@ -133,7 +133,7 @@ Let's see what happens when a simple 'create entry' record is published to the D
 
 * A **store entry** operation, containing both the entry blob and the create-entry action, goes to the **entry authorities** whose arcs cover the entry hash. When it's integrated, the authorities will hold the entry data at that base, along with metadata that contains the action.
 * A **store record** operation, containing the action, goes to the **record authorities** whose arcs cover the action's hash. When it's integrated, the authorities will hold the action at that base.
-* An **register agent activity** operation, containing the action, goes to the **agent activity authorities**, peers whose arcs cover the author's public key. When it's integreated, the authorities will hold the action along with all prior action.
+* An **register agent activity** operation, containing the action, goes to the **agent activity authorities**, peers whose arcs cover the author's public key. When it's integrated, the authorities will hold the action along with all prior action.
 
 No matter what operation they receive, all three authorities check the signature on it to make sure it hasn't been modified in transit and it belongs to the agent that claims to have authored it. If the signature check fails, the data is rejected.
 

src/pages/get-started/index.md

@@ -24,7 +24,7 @@ tocData:
  href: 4-6-scaffold-entry-types
  - text: 4.7. Scaffold a collection
  href: 4-7-scaffold-a-collection
- - text: 4.8. Run your applicaiton in dev mode
+ - text: 4.8. Run your application in dev mode
  href: 4-8-run-your-application-in-dev-mode
  - text: 4.9. Integrate the generated UI elements
  href: 4-9-integrate-the-generated-ui-elements
@@ -62,7 +62,7 @@ In this section, we'll walk you through the step-by-step process of installing H
 
 ### 2.1. Hardware requirements
 
-Before you install the Holochain development ment, make sure your system meets the following hardware requirements:
+Before you install the Holochain development environment, make sure your system meets the following hardware requirements:
 
 * 8GB+ RAM (16GB+ recommended)
 * 4+ cores CPU (6+ cores recommended)
@@ -565,7 +565,7 @@ There are a few different kinds of actions, but the most common one is `Create`,
 
 Every action contains the ID of its author (actually a cryptographic public key), a timestamp, a pointer to the previous source chain record, and a pointer to the entry data, if there is any. In this way, actions provide historical context and provenance for the entries they operate on.
 
-The pointer to the previous source chain record creates an unbroken history from the current record all the way back to the source chain's starting point. This 'genesis' record contains the hash of the DNA, which servs as both the identifier for the specific set of validation rules that all following records should follow and the ID of the network that this source chain's actions are participating in.
+The pointer to the previous source chain record creates an unbroken history from the current record all the way back to the source chain's starting point. This 'genesis' record contains the hash of the DNA, which serves as both the identifier for the specific set of validation rules that all following records should follow and the ID of the network that this source chain's actions are participating in.
 
 An action is cryptographically signed by its author and is immutable (can't be changed or erased from either the source chain or the network's data store) once written. This, along with the validation rules specified by the DNA hash in the genesis record, are examples of a concept we call "intrinsic data integrity", in which data carries enough information about itself to be self-validating.
 
@@ -1111,7 +1111,7 @@ Next some variables are instantiated: one to hold the Holochain client that conn
 
 **Take note of the line that starts with `$:`**. This is a special Svelte label that turns regular variables into **reactive variables**. We won't get too deep into Svelte right now, because this is a tutorial about Holochain, but when a reactive variable changes, Svelte will re-render the entire component. This lets you write a template declaratively, enclosing the reactive variable in `{}` braces, and let Svelte handle the updating of the template wherever the variable changes.
 
-Finally, there's an `onMount` handler, which is run when the component is first displayed. The handler currently does one thing: it connects to the hApp backend via the conductor, waits until the connection is establised, sets `loading` to false, and adds the resulting client connection to the context so that all components can access it.
+Finally, there's an `onMount` handler, which is run when the component is first displayed. The handler currently does one thing: it connects to the hApp backend via the conductor, waits until the connection is established, sets `loading` to false, and adds the resulting client connection to the context so that all components can access it.
 
 #### `<main>` section
 

src/pages/get-started/install-advanced.md

@@ -93,7 +93,7 @@ In the `outputs` set, this flake composes a dev shell that inherits its inputs f
 
 ### `flake.lock` file
 
-Once the `flake.nix` is created (and added to the git repo), the lockfile can be initiliazed by running `nix flake udpate`. The resulting `flake.lock` records pinned references to all the `inputs` at the given point in time, in our case to the the `holochain-flake` and of all its inputs transitively; altogether keeping track of all the dependencies of your app's development environment.
+Once the `flake.nix` is created (and added to the git repo), the lockfile can be initialized by running `nix flake update`. The resulting `flake.lock` records pinned references to all the `inputs` at the given point in time, in our case to the the `holochain-flake` and of all its inputs transitively; altogether keeping track of all the dependencies of your app's development environment.
 
 ### A Gotcha with Flakes and Git