mirror of
https://github.com/Stone-Red-Code/website.git
synced 2026-09-04 09:15:58 +02:00
feat(resources) http-project-guide grammar and clarity changes
This commit is contained in:
@@ -19,7 +19,7 @@ If you are using a build tool that sets up the environment for you now would be
|
||||
Feel free to add the Hello World of your language to test that everything is setup correctly.
|
||||
|
||||
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,
|
||||
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/).
|
||||
|
||||
|
||||
@@ -10,14 +10,14 @@ title: "Chapter 2: So what are we building?"
|
||||
The actual final end goal is going to remain a mystery for the time being, but what I can tell you is that we are going
|
||||
to be building a server!
|
||||
|
||||
What is a server? Its a program that accepts incoming connections, reads and writes to that connection and closing
|
||||
What is a server? It's a program that accepts incoming connections, reads and writes to that connection and closing
|
||||
it eventually.
|
||||
|
||||
You will hear the term socket used a lot in this project. Sockets are a way of connecting two devices on a network together.
|
||||
One socket listens, the other socket connects.
|
||||
|
||||
The main design of sockets in the unix world is [Berkeley Sockets](https://en.wikipedia.org/wiki/Berkeley_sockets) and
|
||||
on windows its [Winsock](https://www.wikiwand.com/en/Winsock).
|
||||
on windows it's [Winsock](https://www.wikiwand.com/en/Winsock).
|
||||
|
||||
This project will mostly be using berkeley sockets but if you want to use windows APIs feel free.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ title: "Chapter 4: Reading from the socket"
|
||||
|
||||
## Chapter 4: Reading from the socket.
|
||||
|
||||
Its a good start, we have a server that can accept connections. It will write a message to the client.
|
||||
It's a good start, we have a server that can accept connections. It will write a message to the client.
|
||||
|
||||
But we aren't reading anything from the client. This will all change now.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ They need some sort of agreed way to ask for things and respond with replies or
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
@@ -37,7 +37,7 @@ We have created a simple reading protocol. This protocol can be extended by addi
|
||||
```txt
|
||||
VERB args go here
|
||||
```
|
||||
I encourage you to mess about and add other verb based commands.
|
||||
I encourage you to experiment and add other verb based commands.
|
||||
|
||||
## Goals
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ fun test_get_definition() {
|
||||
assert(line == "ANSWER something interesting here\n");
|
||||
}
|
||||
```
|
||||
The idea is to try and test all the functionality of your program and use these tests to identify what is going wrong.
|
||||
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.
|
||||
|
||||
@@ -44,7 +44,7 @@ should have identical results, cause *no* side effects, it can also be cached.
|
||||
### Resource
|
||||
|
||||
A resource is just something identified by a URL. An example of a resource could be `/index.html` or `/api/person`
|
||||
These are both resources, its down to the server to decide what these resources mean. In a web application they might
|
||||
These are both resources, it's down to the server to decide what these resources mean. In a web application they might
|
||||
correspond to a controller, or as a file on disk.
|
||||
|
||||
### Version
|
||||
|
||||
@@ -66,7 +66,7 @@ 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. Its mostly the same as the previous but we change
|
||||
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
|
||||
|
||||
```txt
|
||||
|
||||
@@ -8,7 +8,7 @@ title: "Chapter 12: Config"
|
||||
## Chapter 12: Config.
|
||||
|
||||
For the time being we have been hard coding all the various values like the port and the web directory,
|
||||
its about time we made this configurable.
|
||||
it's about time we made this configurable.
|
||||
|
||||
Lets create a config file that we can set the port and the host in. Lets say this config file is called `config`
|
||||
and can contain any format you want. YAML, JSON, INI, Plain text; whatever suits you and your language.
|
||||
@@ -27,7 +27,7 @@ The whole point of making it configurable is the person deploying this in the fu
|
||||
change values in your program to get it to work to their usecase. So by providing a way to configure your application
|
||||
it makes it more portable and usable in different situations.
|
||||
|
||||
This should be quite an easy chapter but its a reasonably important one.
|
||||
This should be quite an easy chapter but it's a reasonably important one.
|
||||
|
||||
## Goals
|
||||
|
||||
|
||||
@@ -21,10 +21,10 @@ This project will guide you in the direction of what you need to do but it leave
|
||||
Feel free to ask for help, search topics online, look for tutorials for any of the concepts presented.
|
||||
|
||||
The idea is to guide you along but not give you all the answers. There will be pseudo code in some of the chapters in
|
||||
this project its down to you to achieve the functionality in your language of choice.
|
||||
this project it's down to you to achieve the functionality in your language of choice.
|
||||
The pseudo code isn't representative of a final project and is there to convey specific ideas you need to achieve
|
||||
|
||||
## Rules
|
||||
|
||||
- Put in the work yourself. Don't copy and paste, the only person you are cheating is yourself.
|
||||
- If you are helping don't spoon-feed. Its about the journey not the destination.
|
||||
- If you are helping don't spoon-feed. It's about the journey not the destination.
|
||||
Reference in New Issue
Block a user