Merge pull request #294 from the-programmers-hangout/style-format-codebase

style: format codebase with Prettier

src/content/resources/language/javascript/promises/converting-a-callback.md

@@ -72,12 +72,12 @@ In Node.js >v8.0.0 you can make use of the built-in `util` package which exposes
 Using our example from earlier, we can write it as:
 
 ```js
-const util = require("util")
+const util = require("util");
 
-const getWeatherAsync = util.promisify(getWeather)
+const getWeatherAsync = util.promisify(getWeather);
 
-const weather = await getWeatherAync("Los Angeles").catch(console.log)
+const weather = await getWeatherAync("Los Angeles").catch(console.log);
-console.log(weather)
+console.log(weather);
 ```
 
 **Note:** the `promisify` method adds a extra argument to the arguments you passed in. In this case we are calling the custom function with a single parameter of type `String`, which means the original function should also accept `(String, Function)`, `Function` being the callback `(error, result)`.

src/content/resources/topic/projects/http-project-guide/chapter-01.md

@@ -21,7 +21,7 @@ Feel free to add the Hello World of your language to test that everything is set
 One of the key steps in this project will be to track progress and changes as you develop.
 For this we are going to be using `git`. If you do not know git,
 don't worry there will be links to [tutorials](https://www.atlassian.com/git/tutorials)
- and [guides](https://rogerdudler.github.io/git-guide/).
+and [guides](https://rogerdudler.github.io/git-guide/).
 
 Setup the git repository and push it to a remote host like Github or Gitlab or BitBucket.
 

src/content/resources/topic/projects/http-project-guide/chapter-02.md

@@ -52,6 +52,7 @@ On the server the flow is slightly more involved.
                |            |           |          |
                +------------+           +----------+
 ```
+
 When a server starts up and creates a socket, it binds that socket to an interface and a port.
 The server will then set the socket to listening for connections,
 when a connection comes in it needs to accept that connection.
@@ -59,7 +60,6 @@ Once a connection has been accepted it can receive and send to the socket the sa
 
 This overview is brushing over a few details and you are encouraged to do your own research
 
-
 ## Goals
 
 - Read up on sockets.

src/content/resources/topic/projects/http-project-guide/chapter-03.md

@@ -27,12 +27,13 @@ The interface is what IP network / device it is going to listen on, the port is
 Whenever you see a connection like `127.0.0.1:6789` the IP address comes first, then `:` then the port number.
 
 In the pseudo code this would be the required code to bind the socket. You can pick any port number for this, I chose `6789`
+
 ```js
 socket.bind("127.0.0.1", 6789);
 ```
 
 Now that the socket is bound, we can put it into listening mode. Listening mode implies that people will be connecting
-to this socket. The parameter is *usually* the backlog of connections you want to allow.
+to this socket. The parameter is _usually_ the backlog of connections you want to allow.
 
 ```js
 socket.listen(1);
@@ -69,9 +70,11 @@ nc -v -v localhost <port>
 where `<port>` is the port number you picked earlier on.
 
 If it works you should see some output like
+
 ```sh
 localhost [127.0.0.1] 6789 (radg) open
 ```
+
 If something has gone wrong then you will get a different message.
 
 When you have completed the goals for this chapter you will have created a socket, bound it, listened for connections and accepted a connection.

src/content/resources/topic/projects/http-project-guide/chapter-04.md

@@ -34,7 +34,7 @@ then closes the connection.
 
 For the time being we are going to stick to hard coded responses, but you can change that message to whatever you want.
 
-You can always send a message to a client that is *not* closed.
+You can always send a message to a client that is _not_ closed.
 
 ```js
 conn.send("hi ");

src/content/resources/topic/projects/http-project-guide/chapter-05.md

@@ -26,6 +26,7 @@ client.send("You said: \n");
 client.send(reply);
 client.close();
 ```
+
 Note that you can also test your server with netcat, use netcat as a client and whatever you write in the terminal will be sent to the server.
 
 ## Goals

src/content/resources/topic/projects/http-project-guide/chapter-06.md

@@ -6,37 +6,46 @@ title: "Chapter 6: What is a protocol?"
 ---
 
 ## Chapter 6: What is a protocol?
+
 How do we humans communicate? Through a mutually agreed convention of a language and conventions.
 Similarly, How do we make clients and servers talk to each other?
 They need some sort of agreed way to ask for things and respond with replies or errors. This mutually agreed set of rules is commonly known as a protocol.
 
-In this chapter, we are going to create a really simple protocol for getting and storing strings, a *dictionary*.
+In this chapter, we are going to create a really simple protocol for getting and storing strings, a _dictionary_.
 With our hypothetical protocol your server will store the definition to a series of words.
 You can do this nice and simply with a map-like data structure or something more complex, your choice.
 
-In a client-server architecture, genrally a client initiates communication by making a request to the server. In our case, the client will make a request to *get* a definition from the dictionary server.
+In a client-server architecture, genrally a client initiates communication by making a request to the server. In our case, the client will make a request to _get_ a definition from the dictionary server.
+
+To _get_ a definition, the client will send this:
 
-To *get* a definition, the client will send this:
 ```txt
 GET someword
 ```
+
 All lines in this protocol will be terminated with `\n`
 
 Your server will then look that word up and reply with the value stored against it.
 The server will need to reply with a sensible error message if the word does not exist.
 
 For now the reply will be either
+
 ```txt
 ANSWER the description
 ```
+
 or
+
 ```txt
 ERROR can't find someword
 ```
+
 We have created a simple reading protocol. This protocol can be extended by adding new requests of the form:
+
 ```txt
 VERB args go here
 ```
+
 I encourage you to experiment and add other verb based commands.
 
 ## Goals

src/content/resources/topic/projects/http-project-guide/chapter-07.md

@@ -6,6 +6,7 @@ title: "Chapter 7: Testing"
 ---
 
 ## Chapter 7: Testing.
+
 Im assuming most of the testing has been done by hand up to this point but this isn't really
 scalable as a long term solution. This is where unit testing comes in, all projects should have tests that cover
 at least the bare minimum of cases that are expected. This project is no different.
@@ -23,12 +24,12 @@ fun test_get_definition() {
     assert(line == "ANSWER something interesting here\n");
 }
 ```
+
 The idea here is to try and test all the functionality of your program and use the above tests to identify what may be going wrong.
 
 Coverage is a reasonably good metric for establishing if your code is well tested. Coverage is identifying what lines
 are covered by unit tests and what lines are not.
 
-
 ## Goals
 
 - Unit test any verbs defined in the previous chapter.

src/content/resources/topic/projects/http-project-guide/chapter-10.md

@@ -8,7 +8,7 @@ title: "Chapter 10: Methods and resources"
 ## Chapter 10: Methods and resources.
 
 If you haven't guessed by now, we are writing a HTTP server. Not against the entire specification (though you can if you want)
-just against a limited subset that *should* work with a browser if you have done it correctly.
+just against a limited subset that _should_ work with a browser if you have done it correctly.
 
 HTTP is a line delimited protocol. The idea being that a client will request content from a server and the server will
 deliver it.
@@ -26,7 +26,7 @@ The methods are `OPTIONS` or `GET` or `HEAD` or `POST` or `PUT` or `DELETE` or `
 Some of these you might have experienced before, others are a bit more unusual.
 
 `GET` is the simplest with "GET me this resource". Get is also considered idempotent which means the act of doing it again
-should have identical results, cause *no* side effects, it can also be cached.
+should have identical results, cause _no_ side effects, it can also be cached.
 
 `PUT` is "PUT something at this resource". This method is also considered idempotent and is usually used to create or update a resource.
 
@@ -40,7 +40,6 @@ should have identical results, cause *no* side effects, it can also be cached.
 
 `TRACE` and `CONNECT` we are going to ignore these two as they are not commonly used anymore and wont be of much use to us.
 
-
 ### Resource
 
 A resource is just something identified by a URL. An example of a resource could be `/index.html` or `/api/person`

src/content/resources/topic/projects/http-project-guide/chapter-11.md

@@ -16,8 +16,8 @@ The next line following this will be a header line.
 Headers are just key value pairs that repeat until you read an empty `\r\n` line.
 You split on the `:` and treat the left hand side as the key, and the right hand side as the value.
 
-
 This is an example request from curl.
+
 ```txt
 GET / HTTP/1.1
 Host: localhost:9995
@@ -28,12 +28,12 @@ Accept: */*
 
 This breaks down into the following information.
 
-* Method: GET
+- Method: GET
-* Resource: /
+- Resource: /
-* Headers
+- Headers
-    * Host: localhost:9995
+  - Host: localhost:9995
-    * User-Agent: curl/7.67.0
+  - User-Agent: curl/7.67.0
-    * Accept: */*
+  - Accept: _/_
 
 That's all the information contained in this request.
 

src/content/resources/topic/projects/http-project-guide/chapter-12.md

@@ -64,7 +64,6 @@ dui odio ut erat.
 
 Boom. Done.
 
-
 There are other replies we might send though, for example lets say someone requests `missing.txt` and we don't have that.
 We need to inform the client it doesn't exist. We do this by sending a 404. It's mostly the same as the previous but we change
 the number and message to something different
@@ -85,6 +84,7 @@ GasdasET /test.txt
 WHAT/1.1
 
 ```
+
 That doesn't look like a valid request so we should tell them that by sending a Bad Request response.
 
 ```txt

src/content/resources/topic/projects/http-project-guide/chapter-14.md

@@ -17,7 +17,7 @@ GET /../config.yaml HTTP/1.0
 ```
 
 This request is a relative path. So your server accepts the path. Goes up one directory from the `www` directory.
-Reads your *config* and sends it to the attacker.
+Reads your _config_ and sends it to the attacker.
 
 This is real bad. Imagine if your config had database passwords in it?
 Imagine if someone requested `../../../../etc/passwd` and your server replied with it!