diff --git a/content/posts/2021-02-12-pse.md b/content/posts/2021-02-12-pse.md
deleted file mode 100644
index c9e05bb..0000000
--- a/content/posts/2021-02-12-pse.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: "What I've learned: Software Engineering in Practice"
-date: 2021-02-12
-cover:
- image: /images/writing-the-new-chip-e1522281795259-750x410.jpg
-categories:
- - studium
- - software
-tags:
- - english
- - studium
- - software engineering
-summary: some sentence about that yo
-draft: true
----
-
-Part of my computer science bachelors programme is a module called "Software Engineering in Practice".
-Students are assigned to teams of 5 by chance and their ratings on the possible topics.
-The goal is to go through planning, implementing and testing a small software engineering project in a timeframe just around 4 months.
-In the early planning phase a supervisor makes sure, that the teams don't overburden themselves or overestimate the size of their plans.
-The result after those 4 months should be a mostly working software project of around 10 thousand lines of code.
-At first this sounds like a lot of time, but the timeframe for implementing the project is three to four weeks, shortly before the exams of the semester are due.
-
-## The project
-We rated a project called "Scalable Git-Client" as a good match. The idea behind that was that it's nothing too crazy, and also shall be written in java, with which everyone should be familiar in this programme.
-The flaw with that approach, in hindsight, was that *everyone* should be able to do Java, so we were a rather mixed team regarding our prior experience.
-
-The project was developed as part of the OSL² project. Meaning that the Git-Client we wrote is intended to be used as a teaching aid in the upper classes of high-school.
-Scalable is not meant as efficient, but as can be expanded with features.
-With that in mind we grouped common git operations into knowledge levels, so students start with a very limitted set of possible git operations, and have more options later on.
-
-### The Tech
-For this project we decided to stay with an old familiar: swing, instead of its cool and new brother Java FX. Knowing the mixed nature of our team this was the right choice in hindsight.
-To be able to save settings and other data git doesnt handle for us, we decided to Persist some objects using Jackson.
-Finally for our integration with Git we settled on JGit, which we hid behind an layer of abstraction. Let's hope there is a more intuitive library for that in the future.
-
-Draft-List:
-- GitWorkflows
- - CLT2015 Valentin Haenel (:
- - Alles auf Master ist selbst wenns nur für 2 Tage ist keine option
- - -> CODE REVIEW IST NICHT OPTIONAL
-- Jackson als JSON Serialisierer/Deserialisierer
- - Custom Serialisierung
-- Gitlab runners
-- Basics JGIT
- - merge being hell.
-- Teamwork. Wie delegiert man.
- - Was macht man mit schwachen Teammitgliedern mit denen man auskommen muss?
-- Zeitmanagement: Sehr enge deadline
-- Technisches Schreiben (again)
-- Open Source Licenses
-- Gitlab stuff
-- Presenting work which is only partly finished due to time constraints
diff --git a/content/posts/2021-04-14-git-introduction.md b/content/posts/2021-04-14-git-introduction.md
deleted file mode 100644
index 6519539..0000000
--- a/content/posts/2021-04-14-git-introduction.md
+++ /dev/null
@@ -1,214 +0,0 @@
----
-title: A short introduction to Git
-date: 2021-04-17T02:04:00+02:00
-categories:
- - misc
- - git
- - software
-tags:
- - english
- - software engineering
- - tools
-summary: This post will help you to get started with using and understanding git!
-showToc: false
-draft: true
----
-
-Currently, I'm working on my slides for this semester's tutorials for our Software Engineering course.
-I aim to give the students a good introduction to git, as it is an integral part of our toolchain.
-So I decided to share a first *rough draft* of what one should know here. This post is by far not exhaustive.
-I'm probably going to expand on this post in later posts. Also I'll revise this post a few times, in the next days.
-
----
-
-![The struggles with git](/images/xkcd/1597.png)
-
Source: xkcd.com
-
-## What is it?
-
-So, what is Git? The xkcd already implies that git is a collaborative, distributed source control system.
-But that is a rather abstract definition. Let's simplify a bit for now: Git tracks changes to your files.
-
-Essentially Git keeps different versions of your files around, so you can compare them and refer to old versions.
-This is really useful, as it makes it hard for you to lose working code, and easy to compare a broken version to a
-working one, to find the culprit.
-
-
-## So how do we use it?
-
-The comic above is not wrong. A lot of git comes down to remembering different commands (or button locations for that matter).
-The first thing one needs to do, is to prepare a Repository. A repository encapsulates everything git tracks. So you move to
-your project directory and type:
-
-```bash
-$ git init
-Initialized empty Git repository in $project_dir/.git
-```
-
-Git now told you exactly what it did. It prepared a folder for the data it has to track. We now refer to the $project_dir
-as the working directory, and $project_dir/.git as the repository. Let's create some files, track some changes and take a
-look at how we can interact with them.
-
-```bash
-$ echo "our first change" > file_one.txt
-$ git status
-On branch master
-
-No commits yet
-
-Untracked files:
- (use "git add ..." to include in what will be committed)
- file_one.txt
-
-nothing added to commit but untracked files present (use "git add" to track)
-```
-
-So, we created a new file with the content "our first change". `git status` is used to get information about the current
-state of the working directory and repository. It currently tells us, that we have not committed anything at all, and that
-there is a untracked file. Let's stage it. Staging means that we tell git to *prepare* that file for a snapshot in its current
-version.
-
-```bash
-$ git add file_one.txt
-$ git status
-On branch master
-
-No commits yet
-
-Changes to be committed:
- (use "git rm --cached ..." to unstage)
- new file: file_one.txt
-```
-Git now tells us that there are no unstaged chanes, as well as no commits. And that we have prepared a new file for commit.
-So let's create our first commit. A commit basically is a snapshot of our files, frozen in time. We'll not concern ourselves
-with the semantics of a good commit for now.
-
-A commit consists of a list of files, their contents, author information, and a message describing the commit.
-
-```diff
-$ git commit -m "This is our first commit"
-$ git show
-commit cf0475067740275c6469836ff743855fcf4e4f85 (HEAD -> master)
-Author: Tobias Manske
-Date: Wed Apr 14 19:37:00 2021 +0200
-
- This is our first commit
-
-diff --git a/file_one.txt b/file_one.txt
-new file mode 100644
-index 0000000..103f365
---- /dev/null
-+++ b/file_one.txt
-@@ -0,0 +1 @@
-+our first change
-```
-
-`git show` shows us what our last commit did. In my case it is filled in with my email and my name for author information.
-The commit has the id cf04... and is currently the commit the master branch points to (more on that later).
-In the bottom part we see a so called diff of the state before the commit and the new state. We can obtain more information
-about the history with the `git log` command. Without further options it just prints the top part of `git show` for every
-commit in the history. Before we can explore that further, we need some more changes. I'll not go into detail here. Just
-repeat what we did before. Change stuff, add it to git and commit it.
-
-
-```diff
-$ git log
-commit 1849c7644425684cea7039e825168d92df4e6936
-Author: Tobias Manske
-Date: Wed Apr 14 19:57:38 2021 +0200
-
- remove a file
-
-commit 4db54105f028d23339bbd1eb51fb397ab0d45719
-Author: Tobias Manske
-Date: Wed Apr 14 19:57:23 2021 +0200
-
- Changes some more stuff
-
-commit cf0475067740275c6469836ff743855fcf4e4f85
-Author: Tobias Manske
-Date: Wed Apr 14 19:37:00 2021 +0200
-
- This is our first commit
-```
-
-As we can see, this is our history. It can be rather cumbersome to look at it this way, let's use an argument to make
-it easier to digest:
-
-```bash
-$ git log --oneline
-1849c76 remove a file
-4db5410 Changes some more stuff
-cf04750 This is our first commit
-```
-
-This is a lot more concise, but lacks quite a lot of information. I have a shorthand `git lg` in
-[my configuration](https://git.tobiasmanske.de/user/rad4day/public/dotfiles/tree/.gitconfig)
-which would show the following:
-
-```bash
-$ git lg
-* 1849c76 - (4 minutes ago) remove a file - Tobias Manske (HEAD -> master)
-* 4db5410 - (4 minutes ago) Changes some more stuff - Tobias Manske
-* cf04750 - (25 minutes ago) This is our first commit - Tobias Manske
-```
-
-The left most column is a abbreviation of the commit hash (that long number we've seen before) that git uses to identify
-and distinguish commits. The length of the abbreviation will adjust if git ever needs more symbols to distinguish two commits.
-
-## Looks complicated, can you explain this again?
-
-I will! With a graphic. Below you can see what happened step-by-step, when we committed.
-
-![How commits changed our graph](/images/git-graph.png)
-
-You can see 4 columns, which are the 4 states our repository was in; every commit changes the state from left to right.
-In the beginning we had no commits, then we created our first commit and git placed the HEAD-Pointer at it (more on that later).
-
-Each new commit has a parent-pointer to its ancestor and is now the location of our HEAD. This pattern continues till we made
-our last commit.
-
-## So how do I access my data?
-
-Until now, we just stored data into git. That's nice to know, but how could we recover code we deleted later on?
-
-For example: How do we get back our initial version of file_one.txt, how do we look at it? How can we replace our current
-version with it?
-
-There are multiple ways to achieve this. If we just wanted to restore the version of file_one.txt of the last commit, we could use
-
-```bash
-$ git checkout HEAD~ -- file_one.txt
-# or: (~ is a postfix meaning ancestor of)
-$ git checkout 4db5410 -- file_one.txt
-```
-
-Which would restore the older version, thereby overwriting our local version. If we just needed that one line we accidentally deleted, we could also extract that from a diff.
-
-```bash
-$ git diff HEAD~ # This will print the diff for all changed files
-$ git diff HEAD~ -- file_one.txt # This will only print changes to file_one.txt
-```
-
-## Branches
-
-The last thing I want to introduce today, are branches. Branches make it possible to have multiple parallel change histories.
-For example one branch could contain a feature you're working on, which is still to be completed, while another one could contain an important bugfix you had to write while developing that feature.
-
-One may wonder at this point, why we'd not just do all that on master, or at least on a single branch. We'll go into more detail about that when we talk about workflows.
-
-The basic workflow we'll think about right now is the following:
-
-1. Have idea for a new feature
-2. Create a new feature branch
-3. Develop feature on feature-branch
-4. Merge feature-branch into master
-
-We'll leave point one and three as an exercise to the reader, and just work with hypothetical commits.
-So first we create our branch:
-```bash
-$ git checkout -b feature-foobar
-# if feature-foobar does not exist it will be created.
-```
-
-If you now type `git status` it will tell you that you're now working on `feature-foobar`