GitLab-CI / YAML – Write less with Anchors, Extends and Hidden Keys

GitLab-CI / YAML – Write less with Anchors, Extends and Hidden Keys

Have you ever wanted to execute a GitLab-CI job for multiple operating systems and just copied every line of YAML multiple times?
Anchors, extends and hidden keys are coming to rescue!

Let’s say you have two jobs and the only difference between them being a single environment variable:

stages:
  - echo

echo-hello:
  stage: echo
  script:
    - echo $ECHO_TEXT
  variables: 
    ECHO_TEXT: "Hello world!"

echo-bye:
  stage: echo
  script:
    - echo $ECHO_TEXT
  variables: 
    ECHO_TEXT: "Bye bye!"

Anchors and extends

Writing the same job two times can already get quite messy and hard to maintain. The more jobs you add, the worse it gets.
But don’t worry, YAML has got you covered. Anchors and extends let you reuse parts of your config and extend on them.

In this example, we create the echo-hello job and extend on it in the echo-bye task:

stages:
  - echo

echo-hello: &echo #create an anchor named "echo"
  stage: echo
  script:
    - echo $ECHO_TEXT
  variables: 
    ECHO_TEXT: "Hello world!"

echo-bye:
  <<: *echo #use the anchor created above and extend it by using "<<"
  variables: 
    ECHO_TEXT: "Bye bye!"

Templating with hidden keys

One thing you can do to further improve on that is, by using a separate task just for templating using hidden keys.
Hidden keys can be defined in YAML using a . in front of a keys name. This prevents GitLab-CI from executing a job and allows us to use it as a template.

In our last example, we create an echo template job containing our stage and script. The echo job is then extended on in echo-hello and echo-bye:

stages:
 - echo

.echo: &echo #keys (jobs in this case) with a dot in front are hidden keys and won't be executed by GitLab
  stage: echo 
  script: 
    - echo $ECHO_TEXT  

echo-hello: 
  <<: *echo 
  variables:  
    ECHO_TEXT: "Hello world!"  

echo-bye: 
  <<: *echo  
  variables: 
    ECHO_TEXT: "Bye bye!"

Some real world examples can be found in our public Icinga 2 packaging repositories: https://git.icinga.com/packaging/rpm-icinga2

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...
How to: Merge multiple Git repositories into one

How to: Merge multiple Git repositories into one

Some time ago, I worked on a project that was split into multiple Git repositories. After a few weeks we decided, that it wasn’t longer necessary to have multiple repositories for this project, so we decided to merge them. The question was, if it is possible to merge multiple code bases without losing their history. The answer is yes. We have two ways on how to tackle this. The first way uses one of the repositories as the new main repository. The second option is to create a new repository for that purpose. We chose option one, because we already had a repository that acted as the main repository. If you choose to create a new repository, you can still follow the steps below. The only difference is, that you need at least one commit on that new repository, to be able to merge into it.

Preparation:
Before merging our repositories, we might first have to do some preparation on them. To prevent merge conflicts, you could move all files into a new directory, before merging them.

# Create a new directory
mkdir repo1
# Move all files into repo1
mv * repo1
# Commit those changes
git commit -am "Prepare for repository merge"
# Push changes to origin
git push

When thats done, add the repository as a remote on the new main repository.

git remote add repo1 git@git.example.com:project/repo1.git

The merge:
After that the merge is quite simple. We just have to append --allow-unrelated-histories to allow the merge of unrelated code bases.

git merge repo1/master --allow-unrelated-histories

If thats successful, the merge is done.

Redo the steps above for every repository you want to merge.

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

GitLab CI + Docker + Traefik = ❤️

So wie vermutlich einige, bin auch ich zur Zeit sehr von GitLab und dessen CI/CD Features angetan. Vor einigen Monaten habe ich angefangen, für meine privaten Webprojekte eine Template .gitlab-ci.yml zu erstellen, welche für jeden Commit, auf jedem Branch, automatisch Docker Images baut und diese in meiner Docker-Umgebung mit zum Branch/Projekt passender Subdomain und SSL-Zertifikat bereitstellt.

Um zu funktionieren benötigt das ganze eine erreichbare Docker-API, ein darauf laufendes Traefik, ein Docker-Netzwerk namens Proxy (Traefik muss dieses auch nutzen) und einen Account + Repository auf hub.docker.com. Das ganze kann aber recht einfach umgeschrieben werden, falls man seine eigene Registry verwenden möchte.

Ablauf beim Commit:

  1. Bauen und Pushes des Images (Tag => Branch + Commit-Hash)
  2. Umbenennen des alten Containers, falls vorhanden (Suffix ‘-old’ wird angehangen)
  3. Erstellen des neuen Containers (Name => Deployment Domain bsp. master.dev.domain.tld)
  4. Löschen des alten Containers
  5. (Optional) Löschen & neu erstellen des Produktionscontainers, falls der Commit auf dem Masterbranch stattgefunden hat (Muss durch Button ausgelöst werden und läuft wie Schritte 2 bis 4 ab)
  6. Neue Container stehen unter den Deployment-Domains zur Verfügung

Pipeline eines Commits auf Master/andere Branches (Deploy auf Produktion kann durch “Play”-Button ausgelöst werden):

Pipeline eines Commits auf andere Branches:

Für jeden Branch wird auch ein Environment erstellt, welches über Operations/Environments in GitLab verwaltet werden kann.
Hier können Deployments angesehen, gelöscht, in Produktion ausgerollt und auf einen früheren Stand zurückgesetzt werden:

Zur Nutzung des Templates in einem Projekt wird ein Dockerfile im Repository, ein paar CI/CD-Variablen, und das Template selber benötigt.

Benötigte CI/CD-Variablen:

CI_DEV_URL_SUFFIX (Domain-Suffix der Development-Umgebungen): dev.domain.tld
CI_PRODUCTION_URL (Domain der Produktionsumgeben): domain.tld
CI_DOCKER_HOST (Adresse & Port der Docker-API): docker.domain.tld
CI_REGISTRY_IMAGE (Image-Name auf hub.docker.com): supertolleruser/supertollesoftware
CI_REGISTRY_USER (Docker-Hub Benutzer): supertolleruser
CI_REGISTRY_PASSWORD (Passwort des Docker-Hub Benutzers): supertollespasswort
CI_TRAEFIK_PORT (Port der Webanwendung im Container): 8080

Da das ganze Projekt bis jetzt nur Images baut und Container bereitstellt, könnten hier natürlich noch Tests eingebaut werden um das ganze abzurunden.

Zur Zeit arbeite ich an einer Umstellung auf Kubernetes und werde, sobald abgeschlossen, auch davon berichten.

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

GitKraken – Der nahezu perfekte Git-Client


Heute möchte ich euch GitKraken vorstellen, ein Git-GUI-Client welcher sich nun seit fast 3 Jahren bei mir im täglichen Einsatz findet und mir die Arbeit mit Git an einigen Tagen sehr vereinfacht.
Wieso ein GUI-Client, wenn man CLI haben kann?
Ich habe schon einige Male von Kollegen gesagt bekommen, dass ich GitKraken doch nur nutze, weil ich mit der CLI nicht zurecht komme. Der wahre Grund ist für mich einfach die viel bessere Übersicht über Changes, History und anderen Branches, schnelleres Auschecken und Resetten von Braches und auch manchmal, die Undo- und Redofunktionen.
Einfacheres Aufteilen in Commits
Jeder der oft viel schreibt und erst nach Stunden anfängt seine Arbeit in einzelne Commits aufzuteilen, weiß wie aufwendig es ist mit git add-p zu arbeiten. Diese Arbeit wird einem von GitKraken sehr vereinfacht und geht dadurch um einiges schneller. Hier können direkt einzelne Zeilen oder Hunks zum Stagen ausgewählt werden.
Was kostet der Spaß?
GitKraken kostet je nach Projekt zwischen 0€ und 99€/Jahr. Dies hängt von der Art des Projekts ab, an dem man mit GitKraken arbeitet. Möchte man mit dem Projekt Geld verdienen und es ist nicht Open-Source, dann muss man dafür mindestens 49€ im Jahr blechen. Wer jedoch ausschließlich an privaten und/oder Open-Source-Projekten arbeitet, kann GitKraken komplett kostenlos nutzen.
Nur nahezu perfekt
Auch wenn GitKraken einwandfrei funktioniert und sehr viele gut implementierte Funktionen bieten, hat es auch so einige kleine Macken. Um GitKraken nutzen zu können benötig man einen Account, GitKraken ist Closed-Source und kostet sogar Geld, wenn man es kommerziell nutzen möchte. Diese Aspekte treffen in der Open-Source-Community oft auf wenig Unterstützung.
Download
GitKraken ist für Windows, MacOS und Ubuntu/Debian erhältlich und kann hier heruntergeladen werden.

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

Postman – API development and testing made simple

As a Icinga 2 developer I often use the Icinga 2 REST API to test new features or debug Icinga itself. Of course most people use curl for that kind of task, and so did I.
That resulted in sometimes rewriting the same request a lot over the course of a few weeks. To counter that I just saved my most used requests into my notes which wasn’t that simple to maintain.
A few weeks ago that finally changed as I stumbled across Postman. Postman is a tool for developing, maintaining and testing REST APIs. I’d like to give you a quick rundown of its features, to show you why it has made my development life so much easier. (mehr …)

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

How to: Icinga 2 – CA Proxy

Die in Kürze erscheinende Icinga-Version 2.8 erweckt den CA-Proxy zum Leben. Mit diesem Blogpost möchte ich nun zeigen, wie man dieses Feature verwendet und wozu es nützlich ist.
Was bringt der CA-Proxy?
Am besten ist dies anhand eines Beispiels zu erklären. Man nehme an, das Setup besteht aus einem Master, einem Satellite und mehreren Clients. Während der Einrichtung dieses Setups muss man bisher für jeden Client ein Ticket auf dem Master erstellen und eine direkte Verbindung zum Master haben, was nicht in allen Setups immer möglich oder einfach ist.
Der CA-Proxy ermöglicht es nun, Certificate-Signing-Requests nicht direkt an den Master, sondern an einen Satellite zu senden. Der Satellite leitet den Request dann an den Master weiter.
Mit Version 2.8 kommt zudem die Möglichkeit hinzu, ein Certificate-Signing-Request an den Master zu senden, ohne vorher ein Ticket zu erstellen. Diese Requests können danach am Master manuell beantwortet bzw. das Zertifikat signiert werden.
Durch die Kombination dieser beiden Features, muss weder der Master, noch ein Ticket im Node-Wizard angegeben werden. Firewalls, die den Master abschirmen, stellen hier auch kein Problem mehr da, solange der Client den Satellite erreichen kann.

Einrichtung eines Clients
Auf dem Client muss nun der Node-Wizard ausgeführt werden. Hier kann, wie vorher erwähnt, das Ticket einfach leer gelassen werden:

root@icinga-agent-1:~# icinga2 node wizard
Welcome to the Icinga 2 Setup Wizard!
We will guide you through all required configuration details.
Please specify if this is a satellite/client setup ('n' installs a master setup) [Y/n]: y
Starting the Client/Satellite setup routine...
Please specify the common name (CN) [icinga-agent-1]: [ENTER]
Please specify the parent endpoint(s) (master or satellite) where this node should connect to:
Master/Satellite Common Name (CN from your master/satellite node): icinga-satellite-1
Do you want to establish a connection to the parent node from this node? [Y/n]: y
Please specify the master/satellite connection information:
Master/Satellite endpoint host (IP address or FQDN): 10.211.55.23
Master/Satellite endpoint port [5665]: [ENTER]
Add more master/satellite endpoints? [y/N]: n
Parent certificate information:
Subject: CN = icinga-satellite-1
 Issuer: CN = icinga-satellite-1
 Valid From: Nov 8 11:37:56 2017 GMT
 Valid Until: Nov 4 11:37:56 2032 GMT
 Fingerprint: BA 1F 61 BE 26 8E CB 4E 8B 4D 20 3F 10 5B D5 0C C4 BF 91 00
Is this information correct? [y/N]: y
Please specify the request ticket generated on your Icinga 2 master (optional).
 (Hint: # icinga2 pki ticket --cn 'icinga-agent-1'): [ENTER]
No ticket was specified. Please approve the certificate signing request manually
on the master (see 'icinga2 ca list' and 'icinga2 ca sign --help' for details).
Please specify the API bind host/port (optional):
Bind Host []: [ENTER]
Bind Port []: [ENTER]
Accept config from parent node? [y/N]: y
Accept commands from parent node? [y/N]: y
Reconfiguring Icinga...
Done.
Now restart your Icinga 2 daemon to finish the installation!
root@icinga-agent-1:~# systemctl restart icinga2

 
Danach können wir auf dem Master über “icinga2 ca list” alle Requests anzeigen lassen:

root@icinga-master-1:~# icinga2 ca list
Fingerprint        | Timestamp                | Signed | Subject
-------------------|--------------------------|--------|--------
92a2e5bbb9b374f... | Nov  8 11:43:06 2017 GMT |        | CN = icinga-agent-1

 
Und mit “icinga2 ca sign <fingerprint>” signieren:

root@icinga-master-1:~# icinga2 ca sign 92a2e5bbb9b374f...
information/cli: Signed certificate for 'CN = icinga-agent-1'.

Nach einigen Minuten sollten die signierten Zertifikate auf den Clients landen. Hierfür ist kein Neustart nötig.

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

Bestimmte Google-Suchergebnisse in Google Chrome blockieren

Da ich in den letzten Tagen einiges mit CSS gemacht habe und in diesem Thema noch recht neu bin, habe ich mir, wer hätte das gedacht, durch Google weitergeholfen. Dabei fällt einem ziemlich schnell auf, dass die obersten Ergebnisse so gut wie immer von W3Schools kommen, was ich nicht unbedingt begrüße.
Um dieses Problem endgültig aus der Welt zu schaffen, hab ich erneut Google um Rat gebeten und bin auf ein von Google selbst entwickeltes Add-On namens “Personal Blocklist” gestoßen
 

Durch das Add-On wird nun unter jedem Ergebnis die Möglichkeit gegeben, die Angezeigte Webseite zu blockieren.


 

Und schon ist W3Schools von der Bildfläche verschwunden, jedenfalls für mich.


 

Durch einen Klick auf das Add-On Icon oben rechts im Browser, lässt sich die Blockliste öffnen und bearbeiten. Hier können Webseiten auch blockiert werden während man sie besucht.


 

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

Atom – der hackbare Editor von Github

Wer kennt es nicht, man sitzt am gewohnten Editor und trotz langer Gewohnheit, fallen einem immer wieder Kleinigkeiten oder gar sehr große Macken auf, welche leider nicht veränderbar sind. Mit Atom hört das auf! Atom ist ein lightweight, Open-Source Editor mit unglaublich vielen Möglichkeiten dank Paketen. Dank den zahlreichen Themes, bietet Atom auch visuell einiges an Auswahl.

Was hebt Atom von anderen Editoren ab?

Direkt nach der Installation ist Atom weit davon weg eine IDE zu sein. Dank den zahlreichen von Community-Mitgliedern entwickelten Paketen, ist es jedoch möglich Atom so gut wie jede Sprache beizubringen, und sogar das Debuggen und Kompilieren von beispielsweise C++ ist durch bestimmte Pakete möglich. So manch einer wird jetzt vermutlich sagen, dass sein Visual Studio genau das bereits kann, ohne dafür ein Paket zu installieren. Wer aber mit mehreren Sprachen gleichzeitig arbeitet, kann mit Atom tatsächlich nahezu jede Programmiersprache mit einem Editor abdecken.

Welche Pakete und Themes nutze ich?

Beim Theme hab ich mich sowohl beim UI als auch beim Syntax für One Light entschieden und bin bis jetzt auch ziemlich zufrieden mit meiner Entscheidung. Ich muss jedoch dazu sagen, dass ich mir noch nicht sonderlich viele Themes angeschaut habe, und es bestimmt viele andere da draußen gibt, die mir genau so gut oder gar besser gefallen würden. Bei den Paketen ist es dafür weitaus komplizierter, weshalb ich mich dazu entschieden habe, die für mich wichtigsten Pakete ein wenig näher zu bringen.

Minimap

Durch Minimap wird, je nach Belieben, rechts bzw. links vom Text eine kleine Übersichtskarte über die gesamte Datei angezeigt. Dies ist bei der Orientierung und Navigation sehr hilfreich, da man einfach per Klick an eine bestimmte stelle scrollen kann. Minimap bietet durch zusätzliche Pakete wie minimap-git-diff oder minimap-find-and-replace, die Möglichkeit, sich Git-Diffs bzw. Ergebnisse der Suchen/Ersetzten-Funktion direkt auf der Minimap anzeichen zu lassen.

Remote-FTP

Wie der Name vielleicht bereits erahnen lässt, erlaubt Remote-FTP das direkte Synchronisieren und Bearbeiten von Dateien über FTP, FTPS und SFTP und unterstützt dabei auch die Verwendung von SSH-Keys.

PlatformIO IDE Terminal

Dieses Paket fügt ein Terminal in den unteren Bereich des Editors ein, welches mit einigen netten Features wie automatisches Mapping, Themes und Tabs. Ich selbst nutze dieses Terminal sehr gerne für Git, da man nicht immer erst ein Terminal öffnen bzw. das Fenster wechseln muss.

 

Atom-Beautify, Atom-Autocomplete-PHP und Linter-PHP

Diese Pakete habe ich zusammengefasst, da sie meiner Meinung nach ziemlich essenziell für PHP-Entwickler sind und irgendwie zusammen gehören.

Atom-Beautify: Kümmert sich um die Formatierung von Code in den meisten gängigen Sprachen

Atom-Autocomplete-PHP: Führt, wie der Name schon sagt, eine Autovervollständigung für PHP ein

Linter-PHP: Statische Code-Analyse für PHP

Split-Diff

Split-Diff ermögicht das Anzeigen von Git-Diffs als übersichtlichen Split. Hierdurch kann man schnell erkennen was genau sich verändert hat und kann es mit ein paar Klicks rückgängig machen. Zusätzlich wird es durch zwei Pfeile ermöglicht zum nächsten bzw. letzten Diff-Block zu springen.

Wer also auf der Suche nach etwas Neuem ist, oder einfach mal etwas ausprobieren möchte, sollte definitiv einen Blick auf Atom werfen und sich eine Programmierumgebung nach den eigenen Vorstellungen zusammenbauen.

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

Wie kommt man eigentlich zum Programmieren?

Da ich schon von einigen Leuten gefragt wurde, wie ich denn zum Programmieren gekommen bin, erzähle ich hier nun von meinen Anfängen als Programmierer. Und das ist jetzt keineswegs als Anleitung für all Jene anzusehen die gerne Programmieren lernen wollen, sondern ist lediglich ein Beispiel wie es funktionieren kann. In diesem Text werde ich den Begriff “Programmieren” etwas weiter fassen: Ich lasse hier auch das Skripten unter den Begriff fallen und hoffe damit Niemandem vor den Kopf zu stoßen.
Begonnen mich mit diesem Thema zu befassen habe ich vor etwa 7 Jahren. Damals war ich gerade mal 11 Jahre alt und habe nahezu meine gesamte Freizeit mit Computerspielen verbracht.
Eines dieser Computerspiele war Multi Theft Auto (kurz MTA), eine Multiplayer-Applikation für GTA San Andreas. In diesem Spiel ist es möglich eigene Gamemodes in der Sprache LUA zu skripten. Dies reizte mich besonders, da das Skripten einem ein großes Spektrum an Möglichkeiten bietet, in das Spielgeschehen einzugreifen.
Alleine in ein so großes Thema einzusteigen ist immer schwer, vor allem wenn man keinen Schimmer hat, wo man anfangen soll. Glücklicherweise bin ich bei meiner Suche auf die von anderen Spielern veröffentlichten Skripte gestoßen, durch die ich mich dann mühsam durchgearbeitet habe. Dies wurde dadurch erleichtert, dass die meisten dieser Skripte unverschlüsselt, also Open Source, waren. Ich sollte vielleicht noch dazu sagen, dass ich zu diesem Zeitpunkt kein Wort Englisch konnte, was das lernen „ein wenig“ verkomplizierte.
Da ich denn Sinn von Funktionen nicht an deren Namen erkennen konnte, nahm ich meinen damaligen besten Freund, den Google-Übersetzer zur Hilfe. So hangelte ich mich Zeile für Zeile durch Skripte und versuchte durch kleine Modifikationen deren Funktion zu verstehen. Irgendwann fing ich dann an Skripte umzuschreiben und an meine Bedürfnisse anzupassen, wobei mir auch ein deutschsprachiges MTA-Scripting-Forum und das zu MTA gehörige Wiki sehr gut zur Seite standen.
Circa zwei Jahre später, war ich in der Lage eigene Skripte, zugegebenermaßen nicht mit der besten Qualität, zu schreiben und hatte zudem meine Englischkenntnisse von Null aus aufgebaut und mir einen kleinen Wortschatz angeeignet.
Irgendwann entdeckte ich dann Minecraft für mich und fand einige Monate später heraus, dass es in dort ebenfalls möglich ist Gamemodes (Plugins) zu schreiben. Diesmal hatte ich jedoch keine Skriptsprache wie LUA vor mir, sondern die Programmiersprache Java.
Da ich mein Lernen eigentlich ähnlich aufbauen wollte wie bei LUA, suchte ich nach einer Quelle für Plugins. Allerdings fiel mir hier ein Problem auf: Java wird kompiliert und ist daher in der ausführbaren Version für den Menschen nicht lesbar. Zu meinem Glück fand ich heraus, dass viele Entwickler ihren Quellcode auf Github veröffentlichen und bediente mich zudem an zahlreichen Wikis.
Im Verlauf der nächsten zwei Jahre baute ich meine Java-Kenntnisse weiter aus, wagte mich aus der Plugin-Programmierung heraus in eigene Projekte, versuchte mich mit großem Interesse an den Sprachen C#, JavaScript und PHP und hatte bereits an einigen größeren Projekten Erfahrungen gesammelt. Zu diesem Zeitpunkt war ich mir sicher, ich möchte das Programmieren später zu meinem Beruf machen.
Hätte es so etwas wie Open Source nicht gegeben, hätte ich nicht die Möglichkeit gehabt, das Programmieren so zu lernen. Aus diesem Grund bin ich umso glücklicher, am Ende bei Netways gelandet zu sein und irgendwann anderen die Möglichkeit zu geben von mir zu lernen.
Funfact: Es dauerte circa 4 Jahre, bis ich die For-Schleife kennen lernte. Ich habe keine Ahnung, wie ich es so lange ohne geschafft habe.

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

NETWAYS stellt sich vor – Noah Hilverling

Name: Noah Hilverling

Alter: 18
Position bei NETWAYS: Junior Developer
Bei NETWAYS seit: September 2016
Was genau gehört zu Deinem Aufgabenbereich bei NETWAYS?
In nicht allzu ferner Zukunft, werde ich anfangen an Icinga Web 2 und den dazugehörigen Plugins zu arbeiten. Neben Icinga Web 2 zählen aber auch kleinere Web-Projekte zu meinem Aufgabenbereich.
An welchen Projekten arbeitest Du gerade?
Zur Zeit arbeite ich zusammen mit meiner Azubi-Kollegin Jennifer an einem Sudoku-Solver, um einfach mal in die Materie rein zu kommen und sich an die Arbeit mit Git zu gewöhnen.
Was macht Dir an Deiner Arbeit am meisten Spaß?
Als langjähriger Hobby-Programmierer, hat sich bei mir der Trend fortgetzt, dass mir das Programmieren am meisten Spaß macht. Zudem liebe ich es im Team zu arbeiten, mit anderen zu kommunizieren und neue Erfahrungen zu sammeln.
Was machst Du, wenn Du mal nicht bei NETWAYS bist?
Da ich erst vor circa einem Monat nach Nürnberg gezogen bin und noch nicht sonderlich viel gesehen haben, besteht ein Teil meiner Freizeit darin, mir die Stadt anzuschauen. Ansonsten sitze ich recht viel vor dem Computer, programmiere an meinen eigenen Projekten weiter, bastel an meinem Server rum und spiele Spiele wie Counter-Strike, GTA 5 und World of Warcraft. Bin ich mal nicht vor meinem Rechner zu finden, bin ich vermutlich über das Wochenende bei meiner Freundin in Erfurt.
Wie geht es in Zukunft bei Dir weiter?
In den nächsten Jahren steht außer meiner Ausbildung nicht sonderlich viel an, weshalb die Ausbildung besonders viel Aufmerksamkeit von mir bekommen wird. Nebenbei werde ich mich in Nürnberg einleben und hoffentlich viele nette Menschen kennen lernen. Nach der Ausbildung würde ich mir wünschen, weiterhin bei NETWAYS arbeiten zu können und meine Kenntnisse im Bereich der Softwareentwicklung weiter auszubauen.
 
 

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...