tobias
/
tobiasmanske.de
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Remove abandoned drafts

This commit is contained in:
Tobias Manske 2021-09-07 04:15:58 +02:00
parent acd58fc440
commit 0759967cd9
Signed by: tobias
GPG Key ID: D5914DC71F2F9352
2 changed files with 0 additions and 267 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
content/posts/2021-02-12-pse.md
View File

@ -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

214
content/posts/2021-04-14-git-introduction.md
View File

@ -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)
<center><i>Source: <a href="https://xkcd.com/1597/">xkcd.com</a></i></center>
## 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 <file>..." 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 <file>..." 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 <tobias.manske@example.com>
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 <tobias.manske@example.com>
Date: Wed Apr 14 19:57:38 2021 +0200
remove a file
commit 4db54105f028d23339bbd1eb51fb397ab0d45719
Author: Tobias Manske <tobias.manske@example.com>
Date: Wed Apr 14 19:57:23 2021 +0200
Changes some more stuff
commit cf0475067740275c6469836ff743855fcf4e4f85
Author: Tobias Manske <tobias.manske@example.com>
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`