TLDR

When writing a command over and over again create an alias witch points to a nice function. E.g.

Utility Functions

While using docker for the last years I learned a lot. Now that I'm giving that rough knowledge to my colleagues and while doing that I noticed some things that might be helpful for the general public concerned with docker and/or powershell.

When getting into docker a bit deeper then just starting a single container an destroying that when your done, I noticed that some functions you expect to have are missing from the docker(-machine) CLI.
Following are the examples that I as of now deemed worthy of being turned into a function that is easily callable via an alias:

Remove Every Running Container

When testing docker you will leave containers running. This is especially true when using windows as the host plattform and due to the fact that auto remove via --rm does not work properly in all shells.

For that usecase I wrote the following little function:

function Remove-AllDockerContainers {
  docker ps -aq `
      | ForEach-Object { docker rm -vf $_ }
}

Executing this will pipe the id of every existing(running or not) container into the remove command with options for removal of volumes being added.

This later evolved into the following:

function Remove-AllDockerContainers {
  docker ps -aq `
      | ForEach-Object { docker stop -t 1 $_ } `
      | ForEach-Object { docker rm -vf $_ }
}

The stop with little timeout was added due to some special cases where the container process wasn`t willing to die easily.

Remove untaged Images

function Remove-AllUntagedDockerImages {
  docker images `
      | ConvertFrom-String `
      | Where-Object {$_.P2 -eq "<none>"} `
      | ForEach-Object { docker rmi $_.P3 }
}

This is pretty self explanatory. Search for all the images that have no () tag and remove them.

On board functions

To be fair the docker CLI has tools to do similar things.
docker system prunf (-f) might be the most notable. It removes basically everything that's not directly needed or just everything that doesn't stop any containers from running. For my purposes this is still the rough and for that reason I keep the functions above in my powershell(and pwsh) profile.

Get the content of any registry

function Get-DockerRegistryContent {
  [CmdletBinding()]
  Param(
  $Filter=".*",
  $RegistryEndpoint
)
  $allRepos = (Invoke-RestMethod -Uri "http://$RegistryEndpoint/v2/_catalog" -Method Get ).repositories 
  $reposMatchingFilter = $allRepos -Match $Filter
  $reposMatchingFilter | ForEach-Object {(Invoke-RestMethod -Uri "http://$RegistryEndpoint/v2/$_/tags/list" -Method Get )}
}

Speaking of on board functions. This one for some reason is nowhere to be found in the docker CLI. It uses the rest api of any given docker registry to give you and overview of its contents. I`m sure that I miss the bigger picture here but for the last couple of years this baffled me.

As always I`m happy about feedback and will answer questions if there are any. The ways of contact are on this site.

This article is part of a series:

• An Introduction
• The Social Structure
• The Hive Mind
• ...

Introduction

Since I started programming and especially after I starting to work as a developer I was eager to work on actual problems while trying out new technologies. One recurring algorithm I tend to implement is the Particle Swarm Optimizer (from now on just called PSO).

Many moving Parts - the Algorithm

The main concept behind this optimization algorithm is a number of particles which are let loose on a numerical problem. Friendly as those particles are with each other they attract each other and share a common knowledge about the best solutions to the problem they are trying to solve. With the information from there own search and from the rumors heard from the other particles in the swarm, these particles move through the problem space.
This concept was appealing because I found that it is implemented pretty fast, tested pretty easily and that it has potential to be parallelized or tinkered with some way else.

I will go over the details of the algorithm again, but for now everybody interested in the inner workings should go to the Wikipedia page and look it up.

One very interesting aspect of this algorithm is that it's not reliant on working with a well behaved function as it doesn't work with e.g. the gradient of the function thats looked at.
The other advantage, for me at least, is that the results and the way to get them is easily visualized.

F# - The current language of choice

My main focus in the last years, language wise, was in C#. For some time now though, I tried to get a better understanding of functional programming concepts in contrast to the OOP one gets used to, using C#. After looking into things like elixir and javascript I settled for F# as the most convenient choice.

First things first - The Model

When you try to learn about F#, you're going the be told that it is very good for following a DDD (Domain Driven Design) way of building your program. So let's do that:

type Optimizer = OptimizationProblem -> Solution

This seems obvious and it's not special to this algorithm. It's just the general definition of an optimization machine like thingy. Lets work our way down from this beginning.

type OptimizationProblem = {
  Function : TargetFunction
  SearchSpace : float * float
  Dimension : int
}

Still nothing that actually touches on the special nature of the PSO. An optimization problem is made up out of a actual function, which has a defined dimension and whose input parameters are typically in an interval of values(search space).

type Solution = ParameterSet * Fitnesse

type ParameterSet = float array

type Fitnesse = float

This part is just the underlying parts of the model we are working with here. A solution is a certain parameter set and its resulting function value. A parameter set is a set of numbers and the fitnesse of a solution is a single number. Nothing really to see here. Now we come to the interesting part.

type Particle = {
  Position : ParameterSet
  Velocity : float array
  LocalBest : Solution
}

Every particle consists of a position it currently has in the search space. This position is bound to change over the course of an optimization.
To move any particle has to have a velocity associated to it. This velocity is changing because the particles talk to each other and remember their own best known state.

type Swarm = {
  GlobalBest : Solution;
  Particles : Particle list
}

The swarm itself is just consisting of the current population of particles and there shared and therefor globally best solution to the optimization problem at hand.

Wrap Up

We now looked into simple model which we can use to implement a working Particle Swarm Optimizer. In the next article we will look into the behavior of the particles and the gravity like attraction they have to each other.

Versioning your projects is hard, but setting up basic versioning functionality for your projects is not. This is what I learned from a very informative Video
from Immo Landwerth which I saw some days ago. So I sat down, took an old project of mine and tried it out. Turns out it's true.

GitVersioning enters the Arena

The project I used for that is an implementation of Fibonacci Heap I wrote when I was in school. It's a basic example of minimalistic library with no dependencies. You can find the code on Github.

Following the documentation on Github I just installed the command line tool via the dotnet-cli dotnet tool install -g nbgv. After that you just have to use the install command nbgv install in your project or solution root and it will add the files Directory.Build.props and version.json.
The former gets picked up from MSBuild and injects Git.Versioning in every project.
version.json is where you define the major and minor of your version number and additional tags like beta or preview you want to use.

At this point the versioning part of things is done. Afterwards I also configured the creation of the nuget package for my library. This will be the topic of a future article.

This article is part of a series about powershell in general and the multiplatform nature of Powershell-Core specifically.

1. Powershell Everywhere
2. Multiplatform Setup for Powershell

TLDR

Got to PsDevScripts on Github to find an easy entry to using powershell with whichever OS.

My Intentions

In the last article in this series I wrote mainly about the possibility of using powershell on multiple platforms. In no way I want to talk people into abandoning there tried and true setup and diving heads deep into powershell. I just wanted to talk about the advantages I see.

How to make the Entry easy

Many comments I got for the last article read something like I wanted to try pwsh for a long time but didn't find a good book(other resource) to start with. As for resources, I named some at the end of the last article.
In my opinion the easiest way of getting into a shell is just using it though. That's why I cleaned up my personal suite of setup scripts and helper modules I use on every system: PsDevScripts on Github
I will update this repository in the future as I myself go along with learning about powershell.

Parts of my Setup

Following is a little more detailed explanation to every part of this suite.

Installer Scripts

While cleaning up the repo I noticed that I would like to just start a single script and be done with it. Everybody that wants to try out this basic setup can just run InstallDefaultSetup.ps1.

Modules

For now I included the two modules that I always install on a new machine:

Default Profile

# import all modules in this folder
Get-ChildItem -Filter "*.psm1" -File "~\Github\PsDevScripts" | ForEach-Object {Import-Module $_.FullName}

# activate modules you want always to be active
Import-Module -Force posh-git, posh-docker

# configure posh-git
$global:GitPromptSettings.DefaultPromptAbbreviateHomeDirectory = $true
$global:GitPromptSettings.BeforeText = '['
$global:GitPromptSettings.AfterText  = '] '

# additional functions that are machine specific

All this does it importing the installed modules into your session. I use the the term installed loosely here, as I also import modules included in my repository.
At the end there is a very basic configuration for posh-git just so your command prompt is a little bit cleaner when navigating through git repos.

Further Questions?

With the above setup you can get started with powershell and the git/docker based workflow I tend to follow.

Now I would be very much interested in questions that come to mind for someone reading about this setup. I would be happy to answer them in a future article or in a conversation on twitter, reddit or email.

Till next time.

This article is part of a series about powershell in general and the multiplatform nature of Powershell-Core specifically.

1. Powershell Everywhere
2. Multiplatform Setup for Powershell

In my day job I work for a company focused on Windows/.NET/WPF. While we worked on cleaning up our build processes and standardize our tools over all our projects, I had the chance to play arround with multiple script languages. One that is following me around for a while now is Powershell.

Technical Reasons to look into Powershell

Our 'legacy' apps mostly used rake or even good old batch files. As we mainly code in C#, I proposed Cake as our build tool. This naturally forced us to use Powershell, because the standard way of using Cake under Windows is a Powershell bootstraper. In a later part of the refactoring of our toolchain, I got a chance to write a bigger test suite in Powershell. This worked well, as Powershell is the standard windows shell today, and therefore greatly supported.
On another occasion we had to provision some VMs as build agents. Here another tool came in handy:
Chocolatey - This package manager written in Powershell finally made something possible that was one of my biggest painpoints of working in Windows, the long setup time when working with a fresh machine. This gets even easier when using Boxstarter which is build on top of Powershell and
Chocolatey. At this point I was locked into Powershell while working on windows.

Stylistic Reasons to use

Things I instantly liked about Powershell is its standard naming convention. <Verb>-(<SomeAddition>)<Noun>. It shows you what the normal return of Powershell functions is: An object. While I was confused for a while on how to get certain property values out of objects and when some path would be implicitly converted to a string or not, that was mostly due to me not reading docs.
At this point the New Microsoft Documentation has to be highlighted. The guys in Redmont took most complaints people had about MSDN and created an actual useful documentation with great focus on fast tutorials and working examples.

Shells on other Plattforms

Though I mostly work on windows, I use docker a lot and all my server apps these days run under linux. Back when I went to university I played around a lot with linux and always liked aspects of it. What I never liked was the missing consistency between the tools you have to use every day. While the linux shells work well communicating over plain ASCI text, the in-/outputformats are not consistent between tools. This means the overhead of connection tools can be huge.
I'm not a linux expert and certainly not a bash or sh one. Personally I used zsh when working under linux for years. This is changing because of microsofts effort to implement a cross platform toolchain.

Powershell Core enters the Stage

The first alpha release of Powershell Core went up mid year 2016. I shortly after that heard of the project and nearly fell of my chair. .Net on linux is one thing. The 'Windows-Shell' under linux sounded crazy at first. Since then 2 years have past and dotnet core is an actual thing and Powershell is not the 'Windows-Shell' anymore. You can use PWSH, as the tool is actually called, under every mainstream linux distro.
One other huge upset is performance. As Powershell Core is built on dotnet core there is a big performance uptick. In every other way powershell on linux is just like every other shell. In contrast to windows powershell the huge number of alias definitions for Cmdlets hash been removed though, as they would colide with native linux functions.

One shell config for every system

The number one reason for me to switch to powershell was that I can reuse my shell configuration on windows. To this point I didn't find any module of my configuration that isn't ported to Powershell Core yet.
The feeling to log into a linux machine and not noticing any change in my command prompt was kind of unreal. And I really look forward to being able to use the same shell config on every system.

Bottom Line

I would recommend to give powershell a chance, even if windows isn't your main OS. It's standardized Cmdlet syntax is very convenient for teams and the biggest downside, it being windows only, is finally history. The object orientated nature of the function returns is also very helpful to reason about the code written.

Resources

Finally here is a short list of resources I use often when using Powershell:

• Docs
• Powershell in Action - Book
• Awesome Powershell

Thanks for your time and feel free to contact me with any questions or feedback.

Exploring an easy to use Web Frontend for your Docker Host

While talking to a colleague about how he wanted to host his own server instance of a multiplayer game. The use case was a small LAN. We talked about hardware requirements but I couldn't help but think that actual hardware at home to host a game server is not the most ideal thing. That's why I tried to convince him to use some kind of VPS and docker for this.
My colleague told me that he wanted to control his server and the contained apps via a web-panel, so I went on the quest of finding one.

Portainer enters the stage

Inside of 5 minutes it was clear that Portainer could be the web-panel side of this equation. So we went ahead and tried it out. As all tools want to make you believe that they are easy to use, we didn't take their word for it but followed the quickstart guide I linked above:

$ docker volume create portainer_data
$ docker run -d -p 9000:9000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

When you now visit port 9000 of your docker host you get a very clean and easy to understand web-panel. There is really not that much more to say.
Id like to recommend everybody using a small VPS to host his own small apps uses this tool to have quick and concise access to the state of his containers and the host itself. For everybody who read my series about hosting your own blog this is the state of my docker host running the automatic https empowered setup. Only this time in a wonderful table:

My colleagues second point was that he wants to control the VPS itself via a frontend. Thankfully most VPS-Providers already have that functionality, I use DigitalOcean, but I'm sure there are comparable solutions.
Using the web-panel of your provider to shutdown/restart your server is already pretty convenient, but shouldn't the server just shut down when nobody is playing?
I will look into that question in a later article and will link it HERE when it's done.

...or the story of Let's Encrypt rate limits

This article is part of a series about setting up your own blog and hosting stuff in general:

1. How to host your own Blog...
2. How to host your own (secure) blog...

Photo by Markus Spiske / Unsplash

So, after the setup of my first own blog, I was left with the dilemma of me being eager to start writing up something about my current adventures in writing code and my possible shame of hosting a blog without https support.

So I started looking around for a simple but secure solution. In the end it seemed obvious to use some kind of decoupled Let’s Encrypt container in combination with or with an integrated reverse proxy. This way the app, in this case ghost, would be very simple while the complicated security stuff happens elsewhere.
The first thing I found was linuxserver/letsencrypt. This seemed promising. Just spin up the container and point the integrated reverse proxy to a linked ghost host. To make this short, this would have required me looking into nginx configuration. I'm pretty sure that this isn't that hard and I will get back to this at some point but for now I didn't want to try out too many new things at once.

The Solution

As is typical for my personal stereotype of developers, I turned to the very general solution to my problem next. I learned that you can build a docker compose configuration that hosts every other container spun up at some later point, provided its configured with some environment variables. This felt somewhat like building a framework that is only used by one application. Still I found it quiet interesting.
I ended up using ekkis/ekkis/nginx-proxy-LE-docker-compose, as it had everything I wanted:

• isolated application container for easy setup
• abstracted nginx configuration
• automatic Let's Encrypt setup
• the possibility to host multiple secured containers on one host.

The result can be found on Github . Let's go over the parts where I deviate from the original setup.

docker-compose.yml

nginx-proxy
...
nginx-gen:
  build: ./patched_nginx_gen
  image: patched-nginx-gen
... 
nginx-ssl
... 

This uses the following Dockerfile:

./patched_nginx_gen/Dockerfile

FROM jwilder/docker-gen
COPY ./nginx.tmpl /etc/docker-gen/templates/nginx.tmpl

This just fixes the problems that ekkis is talking about at the end of his Readme. The nginx template gets copied to the appropriate position in the docker-gen container. The "gen" here stands for generation (of config files).

Now with all this set up we can start any other docker container, and with the right environment variables set, the cluster of containers gets you a certificate for your application and serves it under the specified domain. This means of course there is one more prerequisite to this whole setup. You need your own domain and it has to be pointed at the URL of the docker host we are using for the reverse proxy compose construct and the served applications.

Now the critical environment variables as seen for example in my ghost definition for this blog:

The actual App-Setup

./ghost/docker-compose.yml

version: '3'

services:
  ghost:
    image: ghost:alpine
    container_name: ghost-blog
    volumes:
      - $GHOSTCONTENT:/var/lib/ghost/content
    expose:
      - "2368"
    environment:
      - url=https://$DOMAIN
      - VIRTUAL_HOST=$DOMAIN
      - LETSENCRYPT_HOST=$DOMAIN
      - LETSENCRYPT_EMAIL=admin@antonherzog.com
    networks:
      - nginx-proxy

networks:
  nginx-proxy:
    external: true

Lets got over this file from top to bottom. It binds a folder on the docker hosts filesystem as the content folder for the ghost blog. In addition it exposes the port ghost works on "2368". I think this is redundant because the ghost:alpine image already exposes this port, but I thought it is more clear to explicitly have it in your definition of the app. The first environment variable is also related to ghost. It uses url to know to which place to redirect you with links on the blog itself.
Now to the juicy part. VIRTUAL_HOST is used by the nginx proxy container to know which incoming request should got to the app. In my case this would be the value in $DOMAIN and it would be mapped to port 2368 of the ghost container.
The next two variables are for the Let's Encrypt setup. You have to specify your domain and you can name an email to contact you. As is suggested in the original repo you can now use docker logs -f nginx-ssl to see the certification process in action. This is still a nailbiter for me, because if seen it fail so much, when tried this setup for the first time. The last thing here is the entry under networks. This definition is used so every container we use in the general setup as wall as any app-container is working in the same context. For that to work, there has to be a network with name 'nginx-proxy' present. For that purpose I added a bashscript under ./init_network.sh.

The Pitfalls

Here I will now list the biggest problems hindering me from deploying this, not so complicated, setup:

Config File Generation/Encoding

This should not be a thing you have to say in my opinion, but keep in mind on which OS you are working and whether your encodings are compatible when generating files. In my case I downloaded first the main docker-compose.yml file and then the ./pachted-nginx-gen/nginx.tmpl using a copy-pasted command from Github.
curl -O https://raw.githubusercontent.com/jwilder/nginx-proxy/master/nginx.tmpl
Seems easy enough, doesn't it. Because I was working in Windows/Powershell at the time I had to replace -UseBasicParsing and appended > nginx.tmpl or so I thought. This was horribly wrong in multiple ways:

Firstly 'curl' under linux returns the content of the webrequest you send, where the Powershell-Alias 'curl' is actually just Invoke-WebRequest. This means the return in Powershell is a PSObject with a lot of properties like...

StatusCode        : 200
StatusDescription : OK
Content           : {{ $CurrentContainer := where $ "ID" .Docker.CurrentContainerID | first }}

                    {{ define "upstream" }}
                        {{ if .Address }}
                                {{/* If we got the containers from swarm and this container's port is published...
RawContent        : HTTP/1.1 200 OK
                    Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; sandbox
                    Strict-Transport-Security: max-age=31536000
                    X-Content-Type-Options: nosniff
                    X-Frame-Options: deny
                    X...
Forms             :
Headers           : {[Content-Security-Policy, default-src 'none'; style-src 'unsafe-inline'; sandbox],
                    [Strict-Transport-Security, max-age=31536000], [X-Content-Type-Options, nosniff], [X-Frame-Options,
                    deny]...}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        :
RawContentLength  : 16288

So I was happily writing this whole datatable into nginx.tmpl and it took me longer than I'm willing to say to notice that. I then fixed the command to

Invoke-WebRequest -UseBasicParsing https://raw.githubusercontent.com/jwilder/nginx-proxy/master/nginx.tmpl `
    | Select -ExpandProperty Content `
    > nginx.tmpl.

Sadly I still got errors in the realm of can't read content of 'nginx.tmpl:4'. At this point I learned that Let's Encrypt has a fail-rate-limit when certificate aquisition fails. This forced me to leave the system for a while and come back later when I wasn't persona non grata anymore.
This of course helped me to take a step back. In the end the problem is the encoding which Invoke-WebRequest uses for its content: Utf16LE. The little > I used in the command just keeps the encoding of the string it gets and writes it into the file, as he should. When using curl you get Utf8 encoded files. So, finally, I managed to get a working command to get my files from Github:

Invoke-WebRequest -UseBasicParsing https://raw.githubusercontent.com/jwilder/nginx-proxy/master/nginx.tmpl `
    | Select -ExpandProperty Content `
    | Set-Content -Encoding UTF8 nginx.tmpl

This whole problem in my opinion is a good argument for scrapping all the alias definitions in Powershell. The behaviour of curl and imposter Invoke-WebRequest is not equal in any sense, not even without additional arguments. There is hope though. I for a while now always try to use written out Powershell-CmdLets, as it is more readable in scripts, and you lern then better. The latest installment of Powershell Powershell 6.X which is running on dotnet-core is not using an alias for curl anymore. Instead it's implemented in a native way, as you can see when calling Get-Command curl when using Powershell 6:

CommandType     Name       Version    Source
-----------     ----       -------    ------
Application     curl.exe   7.55.1.0   C:\WINDOWS\system32\curl.exe

Using this curl you get plain Utf8 output, so copy/paste would just have worked.

Compose-up vs. Compose-build

This point is a more of a point to keep in mind. In my setup I use special build docker image for the nginx-gen container. For that I just copy a config file to the appropriate path in the docker-gen structure.

./patched_nginx_gen/Dockerfile

FROM jwilder/docker-gen
COPY ./nginx.tmpl /etc/docker-gen/templates/nginx.tmpl

This image gets built the first time you call docker-compose up (-d). So in my head there was this instant connection docker-compose builds all referenced Dockerfiles. But that's just not the case. When you call docker-compose up (-d) again with an image patched-nginx-gen on your machine it just uses that. That can produce unexpected update problem, when you try to get the image right. You either have to call docker-compose build or delete the current image with docker images rm patched-nginx-gen.

Human Error and missing Research

The one thing I learned again is that a little bit more time spent on research before trying to hack away would save me a lot of time in the end. The hours and hours figuring the first run with linuxserver/letsencrypt was completely unnecessary. I think this will be recurrent theme on this blog.

Summary

In the end setting up your own blog is not the biggest effort, especially when you have experience in using webservers, domains and such things. The former can be substituted for some knowledge in using docker. At some point in the future, I will get back to the setup of this blog and refine it a bit.

As always I'd like to get some feedback. Just pm/@ me on twitter. I'm happy to answer questions and take constructive criticism.

First things first: What should this blog be about? Beside and during my dayjob as a desktop developer I like to try out a lot of tech. Whether it be actual physical tech like computers or software or something in between. Over time I noticed that talking or writing about my experiences helps me to cement my new skills. In addition to that it's really helpful if you are able to reference yourself in writing when someone (for example even yourself) has a question about a topic.

At this point I will give a short introduction into who I am, so feel free to skip over this part if this is of no interest to you. This introduction will appear exeptional and only as a general impression of mine. This blog will be mostly about the technical things. I feel that personal background is still helpfull when reading other peoples thoughts.

I grew up in Dresden in Germany, Eastern Germany to be exact. I was born in 1990 so East- and West-Germany are not countries I lived to see. It's just Germany for me. I went through highschool good enough for my own needs and then had the choice between taking year of and working or going directly to university. I chose the latter and would not recommend that to my 18 year old self today. I started studying computer science and found out that, while I liked light programming at the time, the deeper technical parts weren't all that interesting to me. After going on with my studies for 18 months I left school in order to work for a while and find out what I want to do with myself. I did this and that but ended up working in HELLERAU, an event house in the outskirts of Dresden.

There I worked, like you see in the picture, as a "Hand" constructing stage parts and setting up audio and video equipment. The time I spent in Hellerau was really eyeopening to me, in the sense that I noticed that physical work, aswell as working with something like a product in the end is so very satisfying.

When the question relating to my future education came up again, at this point I was 21 years old, I took the things I experienced and started searching for an apprenticeship on software development. At this point I have to thank the IHK (Industry and Trade Chamber) of Germany, because some years before they defined a new type of apprenticeship called MATSE. This translates to "mathematical-technical-sofware-developer". It's ment to put a bigger emphasis on the maths part of software development and thus closes the gap between studying CS at the university and an apprenticeship without deeper dives into mathematics. Sounds nice doesn't it? Let me assure you, it really is.

After randomly stumbling upon a company with an open spot for a MATSE I also got to learn that the company in question specialises in Acoustic Simulations. This was a dreamlike combination for me, because I allready had some experience in that field, due to me working at the Festspielhaus in Dresden. Also interesting was that this company was situated in Berlin, so I got a bit of a scenery-change on top of my new job.

In the next two and a half years, I got taught a lot about software development in my company as well as the school which got roughly one out of three weeks of my time. I was lucky to be working in a small company where you got to know everybody and even luckier, because all the people working there were nice and interesting.

For all those reasons I am, almost exactly six years later, still working at this company and feel so pationate about this job and the whole field of software development and tech in general, that I want to give something back and write this blog. For those and the more selfish reasons I listed above, I decided to write this blog.

This concludes my personal introduction. In the next post I am going to talk about how what I had to do to set up this blog and all the things I broke before it finally worked.

As I am quiet new to this whole writing for other people stuff, I'd like to get constructive criticism about my writing. This is especially important to me, because english is not my native language.

Thank you for reading and till the next time...