feat: Add React WebUI, make server improvements

media/Server/101.002 y2s2 devlog.norg

@@ -0,0 +1,241 @@
+@document.meta
+title: 100.002 y2s2 devlog
+description:
+authors: wessel
+categories: school, development, c#, robotica
+created: 2024-04-15T18:50:55
+updated: 2024-06-04T15:06:23+0100
+version: 3.1.0
+@end
+
+=TOC
+
+* Summary
+
+* [I    06-02-2024] Groepskeuze
+** Initiele groepskeuze en opsplitsing door indelingsfout
+   Als eerste had ik besloten om een groepje met Semih en Vincent te vormen.
+   Echter bleek er na een aantal dagen dat de groepsverdeling fout was waardoor
+   Wouter Buurman alleen was. Hierdoor heb ik er uiteindelijk voor gekozen om op
+   te splitsen en met Wouter Buurman verder te gaan, zodat hij het niet alleen
+   hoeft te doen.
+
+   Uiteindelijk kwam ook Tom Slikker, een al afgestudeerde student, bij ons
+   groepje. Dit vak (Robotica) is het enigste vak wat hij nog moest halen om
+   zijn diploma te krijgen.
+
+** Eerste indruk van de groep
+   Zelf ben ik wel optimistisch over dit project, ik denk dat, met de help van
+   Tom wij dit project met een goed cijfer kunnen afronden. Aan het begin zal ik
+   mij wel wat meer bezig halen met het halen van het Embedded Systems project,
+   maar als dat geweest is zal ik mij hier volop gaan focussen.
+
+* [II   14-02-2024] Projectkeuze
+** Projectkeuze van mijn oorspronkelijke groepje
+   In eerste instantie had ik al een oppervlakkig idee uitbedacht met Semih en
+   Vincent. Wij zouden een bestaande roomba (robot stofzuiger) gaan modificeren
+   zodanig dat hij een kamer uit kan kaarten. Deze kaart zou dan vervolgens
+   beschikbaar zijn om bekeken te worden door een gebruiker.
+
+** Projectkeuze adaptatie voor het nieuwe groepje
+   Nadat ik afgesplitst was van Semih en Vincent, vond ik het zonde om het idee
+   zo maar te laten gaan. Daarom hadden we er uiteindelijk voor gekozen om dit
+   idee verder uit te werken.
+
+   Toevallig had Tom al wat ervaring met path finding en room mapping, dus dat
+   kwam goed uit. Daarom hebben wij er uiteindelijk voor gekozen om onze eigen
+   robot te maken die een kamer uit mapt en de makkelijkst mogelijke route
+   berekent om de hele kamer af te leggen.
+
+** Projecteisen
+   Voor dit project moet er minimaal 3 grote onderdelen bedacht worden, die
+   vervolgens met behulp van een Object Oriented programmeertaal uitegewerkt
+   worden.
+
+   Als extra eisen hebben wij bedacht:
+   - De robot moet via een API aangestuurd kunnen worden vanuit een
+     afzonderlijke server
+   - De robot moet een kamer kunnen uitmappen
+   - De robot moet de makkelijkst mogelijke route kunnen berekenen om de hele
+     kamer af te leggen
+
+   Als OOP taal hebben wij er uiteindelijk gekozen om C# te gebruiken, omdat
+
+* [III  15-02-2024] Rolverdeling
+  Uiteindelijk hebben we de rollen verdeeld.
+  - *Ikzelf* zal mij voornamelijk bezig houden met de *communicatie*. Aangezien
+    een van de Projecteisen is dat de robot via een API aangestuurd moet kunnen
+    worden vanuit een afzonderlijke server, zal ik deze API server gaan maken.
+  - *Tom* zal zich voornamelijk bezig houden met het maken van het
+    *path finding algoritme*. Aangezien hij hier al recentelijke ervaring mee
+    heeft, leek ons het het verstandigste als hij dit deel uitvoert
+  - *Wouter* zal zich voornamelijk bezig houden met het *uitmappen* van de kamer.
+
+   Wij zullen met zijn allen de onderdelen voor de robot bij elkaar zoeken,
+   een frame maken en de hiervoor benodigde software schrijven.
+
+* [IV   20-02-2024] Eerste ontwerp
+** Onderdeelkeuze
+   Nu wij een algemeen idee hebben, willen wij gaan kijken naar welke onderdelen
+   wij nodig hebben voor de robot. Hierbij hebben wij de volgende onderdelen
+   bedacht:
+   - Frame
+   - Wielen
+   - Motoren
+   - Sensoren
+   - Batterij
+   - Microcontroller
+
+** Mockup-model
+  Vandaag hebben we het eerste ontwerp gemaakt van de robot. Ik heb een
+  3d model van het frame gemaakt door middel van Fusion 360. Vervolgens heb ik
+  ook de bijbehorende CAD bestanden van de onderdelen bij elkaar gevonden en
+  deze toegevoegd aan de mockup.
+
+* [V    27-02-2024] Finalisering eerste ontwerp, onderdelen bestellen
+
+* [VI   01-03-2024] Begin van de server code
+  Vandaag ben ik begonnen met het schrijven van de server code. Ik heb een
+  simpele server gemaakt die een GET request kan ontvangen. Mijn doel is het om
+  zo min mogelijk libraries te gebruiken, daarom heb ik alleen de ingebouwde
+  library voor een `TcpServer` gebruikt.
+
+* [VII  07-03-2024] Routing
+  Om het maken van verschillende endpoints simpel te maken heb ik er uiteindelijk
+  voor gekozen om een aparte *Router* class te maken, deze class zal alle
+  requests apart verdelen over een opgegeven `Dictionairy<string, IRoute>`.
+** IRoute interface
+   Om het routen mogelijk te maken, wordt er gebruik gemaakt van een interface.
+   Dit interface bevat alle mogelijk methodes (GET, POST, PUT, PATCH, etc.) die
+   een HTTP/1.1 request kan maken. Hierdoor kan een class die gebaseerd is op
+   dit interface afgehandeld worden door de *Router*.
+** Router parsing
+   Om fouten te voorkomen zal alles wat de Router gebruikt alvast geparsed
+   worden door `HttpRequest`. Vervolgens zal de Router gebruik maken van de
+   geparsde routes en methodes (in de vorm van een *enum*). Dit zorgt er voor
+   dat als er een probleem met het parsen is, deze allemaal centraal verbeterd
+   kunnen worden.
+* [VIII 15-03-2024] Data serialisatie
+  Er is voor gekozen om JSON te gebruiken om data over de API te versturen.
+  Daarom heb ik een JSON serialisatie library geschreven die data van en naar
+  json kan parsen.
+
+  Voor beide de `JsonReader` en `JsonWriter` class is er besloten om gebruik te
+  maken van een `this <object|string> item` als eerste parameter.
+  Hierdoor kan de functie aangeroepen worden via `object.ReadJson()` of
+  `string.WriteJson<object>()` in plaats van `<JsonReader>.ReadJson(object)` of
+  `<JsonWriter>.WriteJson<object>(<json:string>)`.
+
+** JsonReader
+   De JsonReader class geeft *één publieke* statische functie mee, namelijk
+   `<object>.ReadJson()`.
+
+   De functie leest het meegeleverde object uit, en zet alle publieke velden van
+   het object om in een bruikbare JSON string.
+
+** JsonWriter
+    De JsonWriter class geeft *één publieke* statische functie mee, namelijk
+    `<object>.WriteJson(<json:string>)`. Door het gebruik van
+    *Generic Type Parameters* zal deze functie het zelfde datatype terug geven
+    als het meegeleverde object.
+
+    De functie leest de meegeleverde JSON string uit en *cast hem naar `object`.
+    Als geen `object` meegeleverd is, zal dit een geanonimiseerd
+    `Dictionary<string,object>` zijn. Hier kunnen vervolgens de waardes van
+    uitgelezen worden door middel van _type casting_. Een voorbeeld hiervan is:
+    `(Dictionary<string,object>)obj)["name"]`.
+
+* [IX   20-03-2024] Unit tests
+  Onderhand wordt de code base al aardig groot, daarom heb ik besloten om een
+  aantal unit tests toe te voegen. Ik heb besloten om de volgende tests te maken:
+  - LibParse
+  -- ClassToJson -> Test of de `WriteJson` functie werkt
+  -- ParseToAnonymous -> Test of de `ReadJson` functie werkt
+
+** Gevonden bug
+   Door deze unit tests uit te voeren was ik achter een bug gekomen in de
+   `LibPrase`die mij niet eerder was opgemerkt:
+   > Als er `null` meegegeven wordt aan de `WriteJson` functie, zal de functie
+   > lege string teruggeven in plaats van null.
+
+   Verder werkte alle code wel als verwacht, en was ik tevreden met de resultaten.
+
+* [X    25-03-2024] UML diagram gemaakt
+  Uiteindelijk heb ik de UML diagram gemaakt voor de API server, echter
+  was dit wat ingewikkelder dan geplant, omdat een van de vereisten was dat de
+  UML over de duur van het project moet groeien en veranderen. Aangezien ik al
+  een deel van de API server heb gemaakt, moest ik onthouden wat ik een
+  terug had gebruikt.
+* [XI   01-06-2024] Databse intergratie afgerond
+  Vandaag heb ik de routes vastgelegd die de *Server API* zal gebruiken.
+  Ik heb de volgende routes gemaakt:
+** GET /api/v1/database/metadata
+   Deze route laat de metadata van het database zien, hier kwamen geen problemen
+   naar voren aangezien de code ook maar 3 lijnen lang is.
+** GET /api/v1/database
+   Deze route wordt gebruikt om regels uit het database te vragen.
+   - In eerste instantie lukte het niet om met een *UUID* een entry te zoeken,
+     uiteindelijk bleek het dat de wrapper die ik gebruik om contact te maken
+     met de database geen strings maar `Guid`'s accepteerd als input op een
+     *UUID* veld. Na wat testen was deze fix redelijk simpel
+   - Het net afhandelen van errors/verkeerde inputs was ook even uitvogelen,
+     uiteindelijk heb ik er voor gekozen om het programma te laten erroren,
+     en deze vervolgens op te vangen met een try-catch blok. Dit maakt het ook
+     heel simpel om incomplete velden terug te sturen d.m.v. `throw`.
+     Zo hoeft er voor ieder incorrecte waarde maar een return statement te zijn.
+   - CQL (Cassandra Query Language) staat het niet toe om bij een `SELECT`
+     statement x OF y OF z toe te laten, daarom heb ik er uiteindelijk voor
+     gekozen om de opgegeven zoekparameter te bepalen d.m.v.
+     een ternary operator, de volgorde voor zoekkeuzes gaat van
+     `UUID->Date->Version`.
+   - Aangezien de Cassandra wrapper de gevonden rows als een iterator teruggeeft,
+     moest er ook een kleine functie gescreven worden om deze om te zetten naar
+     een valide JSON-object. Uiteindelijk heb ik er voor gekozen om nog een
+     struct te maken die alle velden van een row bevat, waar vervolgens weer een
+     array van wordt gemaakt om met `LibParse` om te zetten naar een JSON string.
+** POST /api/v1/database
+   Deze route wordt gebruikt om data in het database in te voeren.
+   - Deze route was vrij simpel om te implementeren vergeleken met de `GET`
+     route, in verband met dat er maar een veld opgegeven kan worden door de
+     gebruiker, namelijk `objets`.
+   - In eerste instantie gebruikte ik de `uuid()` functie in CQL om een UUID
+     te genereren, dit heb ik later echter vervangen door de Csharp functie
+     `Guid.NewGuid()` zodat deze UUID ook weer teruggegeven kan worden aan de
+     gebruiker na aanmaak van de row.
+* [XII    03-06-2024] Database delete route implementeren
+  Vorige keer was ik vergeten om de `DELETE` route te implementeren, daarom
+  dat ik er vandaag nog voor heb gekozen om deze te schrijven.
+** DELETE /api/v1/database
+   Deze route verwijdert een entry uit de database.
+  -- Het eerste gedeelte van deze functie gebruikt het zelfde als de `GET`
+     route om te kijken of de database entry uberhaupt bestaat. Als hij bestaat
+     wordt er vervolgens een `DELETE` operatie uitgevoerd, en wordt de
+     verwijderde row teruggestuurd naar de gebruiker.
+  Ook heb ik alle database calls herschreven om gebruik te maken van de
+  `Prepare()` en `Bind()` statements. Dit voorkomt enige SQL injectie die kan
+  gebeuren met het gebruik van hard-coded user-input in SQL (CQL) queries.
+* [XIII   04-06-2024] Verbinding met de server op de robot
+  Om te vermijden dat beide robots publiekelijk aanroepbaar moeten zijn,
+  ben ik ook begonnen om een paar routes te implementeren die de gebruiker
+  via de server een connectie met de robot geeft (commando's versturen).
+  Op deze manier hoeft alleen de server exposed te worden naar het internet om
+  de robot te laten draaien.
+** POST /api/v1/control
+   Via deze endpoint wordt er bepaald door middel van de meegeleverde body wat
+   er naar de robot wordt gestuurd, de volgende opties zijn mogelijk:
+   - `robotId: _` bepaald naar welke robot het eventueel wordt verstuurd
+   - `task: start|stop` bepaald wat de robot moet gaan doen
+   -- `start` Geeft aan dat de robot moet starten met mappen
+   -- `stop` Geeft aan dat de robot direct moet stoppen met mappen
+** Gevonden bug
+   Tijdens het maken van deze endpoint is er een bug gevonden:
+   > Als er een extra slash aan het einde van de URL is, wordt hij niet correct
+   > geroute.
+
+   Dit was een vrij simpele bug, door bij de router aan te geven met een regex
+   dat de laatste slashes altijd verwijdert mag worden, maar wel handig dat hij
+   aangepakt is omdat dit best vaak voorkomt.
+* [XIV    06-06-2024] WebUI gemaakt in React
+  Voor het UI gedeelte van de communicatie heb ik er voor gekozen om React te
+  gebruiken. Dit omdat JavaScript niet puur OOP is, wel OOP geschreven kan worden.
+* [XIV    06-06-2024] UML diagrammen bijgewerkt

media/Server/tex-boilerplate/.editorconfig

@@ -0,0 +1,66 @@
+root = true
+
+[*]
+indent_style = space
+indent_size = 2
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+cpp_indent_braces=false
+cpp_indent_multi_line_relative_to=innermost_parenthesis
+cpp_indent_within_parentheses=indent
+cpp_indent_preserve_within_parentheses=false
+cpp_indent_case_labels=false
+cpp_indent_case_contents=true
+cpp_indent_case_contents_when_block=false
+cpp_indent_lambda_braces_when_parameter=true
+cpp_indent_goto_labels=one_left
+cpp_indent_preprocessor=leftmost_column
+cpp_indent_access_specifiers=false
+cpp_indent_namespace_contents=true
+cpp_indent_preserve_comments=false
+cpp_new_line_before_open_brace_namespace=ignore
+cpp_new_line_before_open_brace_type=ignore
+cpp_new_line_before_open_brace_function=ignore
+cpp_new_line_before_open_brace_block=ignore
+cpp_new_line_before_open_brace_lambda=ignore
+cpp_new_line_scope_braces_on_separate_lines=false
+cpp_new_line_close_brace_same_line_empty_type=false
+cpp_new_line_close_brace_same_line_empty_function=false
+cpp_new_line_before_catch=true
+cpp_new_line_before_else=true
+cpp_new_line_before_while_in_do_while=false
+cpp_space_before_function_open_parenthesis=remove
+cpp_space_within_parameter_list_parentheses=false
+cpp_space_between_empty_parameter_list_parentheses=false
+cpp_space_after_keywords_in_control_flow_statements=true
+cpp_space_within_control_flow_statement_parentheses=false
+cpp_space_before_lambda_open_parenthesis=false
+cpp_space_within_cast_parentheses=false
+cpp_space_after_cast_close_parenthesis=false
+cpp_space_within_expression_parentheses=false
+cpp_space_before_block_open_brace=true
+cpp_space_between_empty_braces=false
+cpp_space_before_initializer_list_open_brace=false
+cpp_space_within_initializer_list_braces=true
+cpp_space_preserve_in_initializer_list=true
+cpp_space_before_open_square_bracket=false
+cpp_space_within_square_brackets=false
+cpp_space_before_empty_square_brackets=false
+cpp_space_between_empty_square_brackets=false
+cpp_space_group_square_brackets=true
+cpp_space_within_lambda_brackets=false
+cpp_space_between_empty_lambda_brackets=false
+cpp_space_before_comma=false
+cpp_space_after_comma=true
+cpp_space_remove_around_member_operators=true
+cpp_space_before_inheritance_colon=true
+cpp_space_before_constructor_colon=true
+cpp_space_remove_before_semicolon=true
+cpp_space_after_semicolon=false
+cpp_space_remove_around_unary_operator=true
+cpp_space_around_binary_operator=insert
+cpp_space_around_assignment_operator=insert
+cpp_space_pointer_reference_alignment=left
+cpp_space_around_ternary_operator=insert
+cpp_wrap_preserve_blocks=one_liners

media/Server/tex-boilerplate/.gitattributes

@@ -0,0 +1,2 @@
+# Auto detect text files and perform LF normalization
+* text=auto

media/Server/tex-boilerplate/.github/CODEOWNERS

@@ -0,0 +1 @@
+* @Wessel

media/Server/tex-boilerplate/.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,133 @@
+
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual
+identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the overall
+  community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or advances of
+  any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email address,
+  without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+[INSERT CONTACT METHOD].
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of
+actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or permanent
+ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the
+community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
+[https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

media/Server/tex-boilerplate/.github/COMMIT_CONVENTION.md

@@ -0,0 +1,160 @@
+> This is adapted from [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+
+# Conventional Commits 1.0.0-beta.4
+
+#### TL;DR:
+
+Messages must be matched by the following regex:
+
+```js
+/^(revert: )?(feat|fix|docs|style|refactor|perf|test|workflow|build|ci|chore|types|wip)(\(.+\))?: .{1,72}/;
+```
+
+## Summary
+
+The Conventional Commits specification is a lightweight convention on top of commit messages.
+It provides an easy set of rules for creating an explicit commit history;
+which makes it easier to write automated tools on top of.
+This convention dovetails with [SemVer](http://semver.org),
+by describing the features, fixes, and breaking changes made in commit messages.
+
+The commit message should be structured as follows:
+
+---
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer]
+```
+---
+
+<br />
+The commit contains the following structural elements, to communicate intent to the
+consumers of your library:
+
+1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
+1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in semantic versioning).
+1. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning).
+A BREAKING CHANGE can be part of commits of any _type_.
+1. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [Angular convention](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
+
+We also recommend `improvement` for commits that improve a current implementation without adding a new feature or fixing a bug.
+Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE).
+<br />
+A scope may be provided to a commit's type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`.
+
+## Examples
+
+### Commit message with description and breaking change in body
+```
+feat: allow provided config object to extend other configs
+
+BREAKING CHANGE: `extends` key in config file is now used for extending other config files
+```
+
+### Commit message with optional `!` to draw attention to breaking change
+```
+chore!: drop Node 6 from testing matrix
+
+BREAKING CHANGE: dropping Node 6 which hits end of life in April
+```
+
+### Commit message with no body
+```
+docs: correct spelling of CHANGELOG
+```
+
+### Commit message with scope
+```
+feat(lang): add polish language
+```
+
+### Commit message for a fix using an (optional) issue number.
+```
+fix: correct minor typos in code
+
+see the issue for details on the typos fixed
+
+closes issue #12
+```
+
+## Specification
+
+The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed
+  by an OPTIONAL scope, and a REQUIRED terminal colon and space.
+1. The type `feat` MUST be used when a commit adds a new feature to your application or library.
+1. The type `fix` MUST be used when a commit represents a bug fix for your application.
+1. A scope MAY be provided after a type. A scope MUST consist of a noun describing a
+  section of the codebase surrounded by parenthesis, e.g., `fix(parser):`
+1. A description MUST immediately follow the space after the type/scope prefix.
+The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string._
+1. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
+1. A footer of one or more lines MAY be provided one blank line after the body. The footer MUST contain meta-information
+about the commit, e.g., related pull-requests, reviewers, breaking changes, with one piece of meta-information
+per-line.
+1. Breaking changes MUST be indicated at the very beginning of the body section, or at the beginning of a line in the footer section. A breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon and a space.
+1. A description MUST be provided after the `BREAKING CHANGE: `, describing what has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
+1. Types other than `feat` and `fix` MAY be used in your commit messages.
+1. The units of information that make up conventional commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
+1. A `!` MAY be appended prior to the `:` in the type/scope prefix, to further draw attention to breaking changes. `BREAKING CHANGE: description` MUST also be included in the body
+or footer, along with the `!` in the prefix.
+
+## Why Use Conventional Commits
+
+* Automatically generating CHANGELOGs.
+* Automatically determining a semantic version bump (based on the types of commits landed).
+* Communicating the nature of changes to teammates, the public, and other stakeholders.
+* Triggering build and publish processes.
+* Making it easier for people to contribute to your projects, by allowing them to explore
+  a more structured commit history.
+
+## FAQ
+
+### How should I deal with commit messages in the initial development phase?
+
+We recommend that you proceed as if you've already released the product. Typically *somebody*, even if it's your fellow software developers, is using your software. They'll want to know what's fixed, what breaks etc.
+
+### Are the types in the commit title uppercase or lowercase?
+
+Any casing may be used, but it's best to be consistent.
+
+### What do I do if the commit conforms to more than one of the commit types?
+
+Go back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is its ability to drive us to make more organized commits and PRs.
+
+### Doesn’t this discourage rapid development and fast iteration?
+
+It discourages moving fast in a disorganized way. It helps you be able to move fast long term across multiple projects with varied contributors.
+
+### Might Conventional Commits lead developers to limit the type of commits they make because they'll be thinking in the types provided?
+
+Conventional Commits encourages us to make more of certain types of commits such as fixes. Other than that, the flexibility of Conventional Commits allows your team to come up with their own types and change those types over time.
+
+### How does this relate to SemVer?
+
+`fix` type commits should be translated to `PATCH` releases. `feat` type commits should be translated to `MINOR` releases. Commits with `BREAKING CHANGE` in the commits, regardless of type, should be translated to `MAJOR` releases.
+
+### How should I version my extensions to the Conventional Commits Specification, e.g. `@jameswomack/conventional-commit-spec`?
+
+We recommend using SemVer to release your own extensions to this specification (and
+encourage you to make these extensions!)
+
+### What do I do if I accidentally use the wrong commit type?
+
+#### When you used a type that's of the spec but not the correct type, e.g. `fix` instead of `feat`
+
+Prior to merging or releasing the mistake, we recommend using `git rebase -i` to edit the commit history. After release, the cleanup will be different according to what tools and processes you use.
+
+#### When you used a type *not* of the spec, e.g. `feet` instead of `feat`
+
+In a worst case scenario, it's not the end of the world if a commit lands that does not meet the conventional commit specification. It simply means that commit will be missed by tools that are based on the spec.
+
+### Do all my contributors need to use the conventional commit specification?
+
+No! If you use a squash based workflow on Git lead maintainers can clean up the commit messages as they're merged—adding no workload to casual committers.
+A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.

media/Server/tex-boilerplate/.github/CONTRIBUTING.md

@@ -0,0 +1,49 @@
+# Contributing
+
+<!---
+Used linters:
+  [ESLint](https://eslint.org/)
+  [EditorConfig](https://editorconfig.org)
+--->
+
+If you wish to contribute to {{project.name}}, feel free to fork the repository and submit a pull request.
+{{project.linter}} is enforced to correct most typo's you make and keep the code style the same throughout the whole project,
+so it would be much appreciated if you installed {{project.linter}} to your editor of choice
+
+<!---
+Prerequisites for Node.JS:
+
+* [Node.JS V18.14.0](https://nodejs.org/en/)
+* [Docker](https://www.docker.com)
+* [ESLint](https://eslint.org)
+* [(OPTIONAL) Yarn](https://yarnpkg.com)
+--->
+## Prerequisites
+The following prerequisites must be met before installing {{project.name}}:
+{{setup.prerequisites}}
+
+<!---
+Install commands:
+  JavaScript/TypeScript: `yarn --dev` or `npm install --dev`
+  Rust: `cargo run`
+  C: `make clean install`
+
+Run commands:
+  JavaScript/TypeScript: `yarn test` or `npm run test`
+  Rust: `cargo run`
+  C: `make clean dev`
+--->
+## Setup
+To get ready to work on the codebase, please do the following:
+
+1. Fork & clone the repository, and make sure you are on the **master** branch
+2. Run {{setup.install}}
+3. Code your ideas and test them using {{setup.test}}
+4. [Submit a pull request](https://github.com/{{project.master}}/{{project.name}}/compare)
+
+## Testing
+When creating any new functions, please also create unit tests for them in the `tests` directory.
+Use the library associated with the project when creating such tests.
+
+When modifying existing functions, make sure to test them before making a pull request, this will prevent
+anything from breaking on the production environment.

media/Server/tex-boilerplate/.github/FUNDING.yml

@@ -0,0 +1,2 @@
+github: wessel
+ko_fi: wessel

media/Server/tex-boilerplate/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,78 @@
+# Adapted from https://github.com/discordjs/discord.js/blob/main/.github/ISSUE_TEMPLATE/bug_report.yml
+name: Bug report
+description: Report incorrect or unexpected behavior of a package
+labels: [bug, need repro]
+body:
+  # - type: markdown
+  #   attributes:
+  #     value: |
+  #       Use Discord for questions: https://discord.gg/djs
+  - type: dropdown
+    id: package
+    attributes:
+      label: Which part is this bug report for?
+      options:
+        - {{tree.parts}}
+    validations:
+      required: true
+  - type: textarea
+    id: description
+    attributes:
+      label: Issue description
+      description: |
+        Describe the issue in as much detail as possible.
+
+        Tip: You can attach images or log files by clicking this area to highlight it and then dragging files into it.
+      placeholder: |
+        Steps to reproduce with below code sample.
+    validations:
+      required: true
+  - type: textarea
+    id: codesample
+    attributes:
+      label: Code sample
+      description: Include a reproducible, minimal code sample. This will be automatically formatted into code, so no need for backticks.
+      render: {{project.lang}}
+      placeholder: |
+        Your code sample should be...
+        ... Minimal - Use as little code as possible that still produces the same problem (and is understandable)
+        ... Complete - Provide all parts someone else needs to reproduce your problem
+        ... Reproducible - Test the code you're about to provide to make sure it reproduces the problem
+  - type: input
+    id: version
+    attributes:
+      label: Version
+      description: Which version of the package are you using?
+    validations:
+      required: true
+  - type: input
+    id: lang-version
+    attributes:
+      label: {{project.lang}} version
+      description: |
+        Which version of {{project.lang}} are you using?
+    validations:
+      required: true
+  - type: input
+    id: os
+    attributes:
+      label: Operating system
+      description: Which OS does your application run on?
+  - type: dropdown
+    id: priority
+    attributes:
+      label: Priority this issue should have
+      description: Please be realistic. If you need to elaborate on your reasoning, please use the Issue description field above.
+      options:
+        - Low (slightly annoying)
+        - Medium (should be fixed soon)
+        - High (immediate attention needed)
+    validations:
+      required: true
+  - type: input
+    id: dev-release
+    attributes:
+      label: I have tested this issue on a development release
+      placeholder: d23280c (commit hash)
+      description: |
+        The issue might already be fixed in a development release or main. This is not required, but helps us greatly.

media/Server/tex-boilerplate/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,7 @@
+blank_issues_enabled: false
+# Example entry:
+#    name:
+#    url:
+#    about:
+contact_links:
+  - {{project.contact}}

media/Server/tex-boilerplate/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,42 @@
+# Adapted from https://github.com/discordjs/discord.js/blob/main/.github/ISSUE_TEMPLATE/feature_request.yml
+name: Feature request
+description: Request a new feature
+labels: [feature request]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Please only use this form for submitting new, original ideas.
+  - type: dropdown
+    id: package
+    attributes:
+      label: Which part is this feature request for?
+      options:
+        - {{tree.parts}}
+    validations:
+      required: false
+  - type: textarea
+    id: description
+    attributes:
+      label: Feature
+      description: A clear and concise description of what the problem is, or what feature you want to be implemented.
+      placeholder: I'm always frustrated when..., A good addition would be...
+    validations:
+      required: true
+  - type: textarea
+    id: solution
+    attributes:
+      label: Ideal solution or implementation
+      description: A clear and concise description of what you want to happen.
+    validations:
+      required: true
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternative solutions or implementations
+      description: A clear and concise description of any alternative solutions or features you have considered.
+  - type: textarea
+    id: additional-context
+    attributes:
+      label: Other context
+      description: Any other context, screenshots, or file uploads that help us understand your feature request.

media/Server/tex-boilerplate/.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,19 @@
+---
+name: Pull Request
+about: Propose changes to {{project.name}}
+title: "[PR] Your changes"
+labels: pullrequest
+assignees: Wessel
+
+---
+
+**Please describe the changes this PR makes and why it should be merged:**
+
+
+**Status**
+- [ ] Code changes have been tested and there aren't any typos in it
+
+**Semantic versioning classification:**
+- [ ] This PR changes {{project.name}} core codebase (methods or parameters added)
+  - [ ] This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
+- [ ] This PR **only** includes non-code changes, like changes to documentation, README, etc.

media/Server/tex-boilerplate/.github/auto_assign.yml

@@ -0,0 +1,5 @@
+addReviewers: true
+reviewers:
+  - {{project.reviewers}}
+numberOfReviewers: 0
+runOnDraft: true

media/Server/tex-boilerplate/.github/labels.yml

@@ -0,0 +1,62 @@
+- name: bug
+  color: d73a4a
+- name: caching
+  color: 80c042
+- name: chore
+  color: ffffff
+- name: ci
+  color: 0075ca
+- name: dependencies
+  color: 276bd1
+- name: documentation
+  color: 0075ca
+- name: duplicate
+  color: cfd3d7
+- name: error handling
+  color: 80c042
+- name: feature request
+  color: fcf95a
+- name: good first issue
+  color: 7057ff
+- name: has PR
+  color: 4b1f8e
+- name: help wanted
+  color: '008672'
+- name: in progress
+  color: ffccd7
+- name: in review
+  color: aed5fc
+- name: interactions
+  color: 80c042
+- name: invalid
+  color: e4e669
+- name: need repro
+  color: c66037
+- name: priority:high
+  color: fc1423
+- name: question
+  color: d876e3
+- name: ratelimits
+  color: 80c042
+- name: refactor
+  color: 1d637f
+- name: regression
+  color: ea8785
+- name: REST
+  color: 80c042
+- name: semver:major
+  color: c10f47
+- name: semver:minor
+  color: e4f486
+- name: semver:patch
+  color: e8be8b
+- name: tests
+  color: f06dff
+- name: threads
+  color: 80c042
+- name: typings
+  color: 80c042
+- name: utility
+  color: 80c042
+- name: wontfix
+  color: ffffff

media/Server/tex-boilerplate/.gitignore

@@ -0,0 +1,9 @@
+!.gitkeep
+
+tmp/
+src/tmp
+
+node_modules/
+
+obj/
+out/

media/Server/tex-boilerplate/LICENSE

@@ -0,0 +1,22 @@
+
+The MIT License (MIT)
+
+Copyright (c) 2023 Wessel T <discord@go2it.eu> (https://wessel.gg/)
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

media/Server/tex-boilerplate/README.md

@@ -0,0 +1,40 @@
+<!---
+To update:
+  project.
+    master        - The master org or user of the repo
+    linter        - The linter used for the project
+    name          - Project name
+    lang          - The (primary) programming language used
+    logo          - Project logo
+    contact       - All ways to contact for any inqueries
+    reviewers     - A list of users to auto-assign to issues and features
+  info.
+    toc           - Table of Contents of README
+    desc          - Small project description
+    badges        - Any extra badges
+  setup.
+    prerequisites - The prerequisites needed to run the project
+    install       - Command for initial installation
+    test          - Command for running tests
+  tree.
+    parts         - All individual parts of the project
+--->
+<img src="{{project.logo}}" align="left" width="192px" height="192px"/>
+<img align="left" width="0" height="192px" hspace="10"/>
+
+> {{project.name}}
+
+[![MIT License](https://img.shields.io/badge/license-MIT-007EC7.svg?style=flat-square)](/LICENSE) {{info.badges}}
+
+{{info.desc}}
+
+<br><br>
+
+<!---
+Example table of contents:
+* header
+  * sub header
+--->
+## Table of contents
+{{info.toc}}
+

media/Server/tex-boilerplate/src/main.tex

@@ -0,0 +1,59 @@
+\documentclass[10pt]{article}
+
+%/ Use case: margins
+\usepackage[letterpaper,
+  top=2cm,
+  bottom=2cm,
+  left=2cm,
+  right=2cm,
+  marginparwidth=1.75cm]{geometry}
+%/ Use case: language and spell checking
+\usepackage[utf8]{inputenc}
+\usepackage[english]{babel}
+%/ Use case: uppercase headers
+\usepackage{titlecaps}
+\usepackage{sectsty}
+%/ Use case: text formatting
+\usepackage{url}
+\usepackage[outputdir=tmp]{minted}
+\usepackage[colorlinks=true, allcolors=teal]{hyperref}
+\usepackage{textcomp}
+\usepackage{amsmath}
+%/ Use case: images
+\usepackage{graphicx}
+\usepackage[export]{adjustbox}
+\usepackage[font=small,labelfont=bf]{caption}
+%/ Use case: tables
+\usepackage{booktabs}
+\usepackage[flushleft]{threeparttable}
+\usepackage{pgfplots}
+\usepackage{pgfplotstable}
+
+\pgfplotsset{compat=1.18}
+
+\allsectionsfont{\mdseries\scshape}
+
+\title{\titlecap{\scshape Title}}\normalfont
+\author{Wessel Tip $<$contact@wessel.gg$>$ (Student number 696770, \url{https://wessel.gg/})}
+\date{Computer Engineering at InHolland University of Applied Sciences\linebreak Year 2, Semester 2 (Jan. 2024 - Jun. 2024)}
+
+\begin{document}
+
+\maketitle
+
+\begin{abstract}
+In dit verslag zal de ontwikkeling van mijn persoonlijke bijdrage aan het project
+Robotica worden besproken. Mijn persoonlijke bijdrage zal de communicatie tussen
+de gebruiker, de robot en een aparte dataserver beheren.
+
+Het hele project zal in Csharp worden geschreven door zijn objectgeoriënteerde aard.
+\end{abstract}
+
+\tableofcontents
+
+\input{sections/1 introduction}
+
+\bibliographystyle{IEEEtran}
+\bibliography{references.bib}
+
+\end{document}

media/Server/tex-boilerplate/src/references.bib

@@ -0,0 +1 @@
+

media/Server/tex-boilerplate/src/sections/1 introduction.tex

@@ -0,0 +1,6 @@
+\newpage
+
+\section{Introduction}
+\label{sec:introduction}
+
+