Fix typos

1 files changed, 33 insertions, 33 deletions

diff --git a/architecture.mdwn b/architecture.mdwn
index a04bb61..159966a 100644
--- a/architecture.mdwn
+++ b/architecture.mdwn
@@ -11,14 +11,14 @@ evolve into also being a tool for also doing continuous deployment
 
 This document describes the technical architecture of ick.
 Specifically, the architecture for the upcoming ALPHA-6 release, but
-not further than that. ALPHA-6 is meant to usable by people other than
-the primary developer.
+not further than that. ALPHA-6 is meant to be usable by people other
+than the primary developer.
 
 What is continuous integration?
 -----------------------------------------------------------------------------
 
-Continuous integration is a style software development where changes
-get integrated to the main line of development freuqently. It is
+Continuous integration is a software development style where changes
+get integrated to the main line of development frequently. It is
 contrasted with a style where features get developed in their own,
 long-living branches and only get integrated when finished, often
 after weeks or months of development. The latter often results in an
@@ -53,11 +53,11 @@ architecture that among other things only allowed running one build at
 a time, and did not work well as a service.
 
 The second (current) generation of ick is a re-design from scratch,
-keeping nothing of the first genearation. It is explicitly aimed to
+keeping nothing of the first generation. It is explicitly aimed to
 become a "hostable" system: to allow an ick instance to be a CI system
 to a number of independent users.
 
-The name "ick" was suggestd by Daniel Silverstone in an IRC
+The name "ick" was suggested by Daniel Silverstone in an IRC
 discussion. He said "all CI systems are icky", and this prompted Lars
 to name the first generation "ick".
 
@@ -68,7 +68,7 @@ Overview
 A continuous integration system is, at its most simple core, an
 automated system that reacts to changes in a program's source code by
 doing a build of the program, running any of its automated tests, and
-then publishing the results somewhere. A continuoues deployment system
+then publishing the results somewhere. A continuous deployment system
 continues from there to also installing the new version of the program
 on all relevant computers. If any step in the process fails, the
 system notifies the relevant parties.
@@ -77,7 +77,7 @@ Ick aims to be a CI system. It deals with a small number of concepts:
 
 * **projects**, which consist of **source code** in a version control
   system
-* **pipelines**, which are reuseable sequences of actions aiming to
+* **pipelines**, which are reusable sequences of actions aiming to
   achieve some task (build program source code, run tests, etc)
 * **workers**, which do all the actual work by executing pipeline
   actions
@@ -244,9 +244,9 @@ how they are used individually and together.
   hopefully happen not too far in the future.)
 
 * The **icktool** command line tool provides the ick user interface.
-  It get an access token from the identity provider, and uses the
+  It gets an access token from the identity provider, and uses the
   controller and artifact store APIs to manage project and pipeline
-  descriptions, build artfifacts, trigger builds, and view build
+  descriptions, build artifacts, trigger builds, and view build
   status.
 
 [Qvisqve]: http://qvarn.org/qvisqve
@@ -384,7 +384,7 @@ every API client. There are three exceptions:
   the IDP.
 * Triggering a project to build. This is temporarily un-authenticated,
   to avoid having to distribute API credential to git server. This
-  willl be fided later.
+  will be fixed later.
 
 
 Getting an access token: ickui and OpenID Connect
@@ -397,12 +397,12 @@ than the client credentials grant for non-interactive use.
 
 [OpenID Connect]: https://openid.net/specs/openid-connect-core-1_0.html
 
-In summary, there are five entitities involved:
+In summary, there are five entities involved:
 
 * the end-user who owns (in a legal meaning) the resources involved
 * the "resource server" where the resources technically are: this
   means the controller and artifact store, and possibly other ick
-  compontents that hold data on behalf of the end-user
+  components that hold data on behalf of the end-user
 * the IDP (Qvisqve), which authenticates the end-user and gives out
   access tokens that allow the bearer of the access token to do things
   with the user's resources
@@ -411,7 +411,7 @@ In summary, there are five entitities involved:
 * a "facade" that sits between the browser and the resource servers
 
 The facade is necessary for security. We do not trust the browser to
-be keep an access token secure from malware running on the end-user's
+keep an access token secure from malware running on the end-user's
 machine or device, including in the browser. The facade runs on what
 is assumed to be a more secure machine, and can thus be trusted with
 the access token. The facade can also provide a more convenient API
@@ -423,8 +423,8 @@ front-end, and includes the access token to those.
 
 * User initiates login, by clicking on a "login" link in the front-end
   UI. Or else the facade initiates this, when its access token
-  expires. Either way, the browser makes a request the facade's login
-  endpoint.
+  expires. Either way, the browser makes a request to the facade's
+  login endpoint.
 * Facade redirects user's browser to Qvisqve.
     * This is called the "authorization request". It includes some
       data that's needed to prevent various security intrusions.
@@ -498,21 +498,21 @@ parameters. If it looks OK, Qvisqve creates an "authorization attempt
 object", and stores `CLIENTID`, `RANDOMSTRING`, and `CALLBACKURI` in
 it. It also generates an object id (a UUID4).
 
-Qvisvqe returns to the browser a login form, asking for username and
+Qvisqve returns to the browser a login form, asking for username and
 password, plus a hidden form field with the authorization attempt
 object id.
 
 The user fills in the login form, and submits it. The submitted form
-includes the authorization attempt object id field. Qvisqve checks the
-id value corresponds to an existing authorization attempt object, and
-that the credentials are valid. If so, it creates an authorization
-code, stores that into the authorization object, and responds the form
-submission with:
+includes the authorization attempt object id field. Qvisqve checks
+that the id value corresponds to an existing authorization attempt
+object, and that the credentials are valid. If so, it creates an
+authorization code, stores that into the authorization object, and
+responds to the form submission with:
 
     HTTP/1.1 302 Found
     Location: CALLBACKURI?code=AUTHZCODE&state=RANDOMSTRING
 
-Here, `CALLBACKURI` and `RANDOMSTRING` are the retrieved from the
+Here, `CALLBACKURI` and `RANDOMSTRING` are the ones retrieved from the
 authorization object.
 
 Browser follows the redirect to the facade. The facade checks that
@@ -536,9 +536,9 @@ Qvisqve. The client id must be the same as given in the initial
 authorization request.
 
 Qvisqve checks the client's credentials (`Authorization` header), and
-the `AUTHZCODE` is one it has generated and that hasn't yet been used,
-and that `CALLBACKURI` is registered with the facade. If all is well,
-it responds the facade's token request:
+that the `AUTHZCODE` is one it has generated and that hasn't yet been
+used, and that `CALLBACKURI` is registered with the facade. If all is
+well, it responds to the facade's token request:
 
     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
@@ -630,14 +630,14 @@ diagram.
                 deactivate resources
                 facade -> browser : some thing
             deactivate facade
-            broser -> enduser : show thing to user
+            browser -> enduser : show thing to user
         deactivate browser
 
     end
 
     @enduml
 
-(This should be the same protocol as descibed in prose above.)
+(This should be the same protocol as described in prose above.)
 
 The worker-manager
 -----------------------------------------------------------------------------
@@ -866,16 +866,16 @@ Ick controller resources and API
 
 See the example project for examples. Each item in the `projects` and
 `pipelines` lists is a resource. The example is in YAML syntax, but is
-trivially converted to JSON, which the API talks. (The exampel is
+trivially converted to JSON, which the API talks. (The example is
 input to the `icktool` command and is meant to be human-editable. YAML
 is better for that, than JSON.)
 
 For a fuller description of the APIs, see the [yarn][] scenario tests
 in the ick source code: <http://git.liw.fi/ick2/tree/yarns>
 
-A build resource is created automatically, when a project is triggerd,
-at `/builds/BUILDID`, a pipeline is triggered. It can't be changed via
-the API.
+A build resource is created automatically, when a project is
+triggered, at `/builds/BUILDID`, a pipeline is triggered. It can't be
+changed via the API.
 
     {
         "project": "liw.fi",
@@ -899,7 +899,7 @@ for now we'll have just the name.
         "worker": "bartholomew"
     }
 
-A work resource resource tells a worker what to do next:
+A work resource tells a worker what to do next:
 
     {
         "project": "liw.fi",