NETWAYS Blog

stackconf 2022 | Are all programming languages in english?

von Katja Kotschenreuther | Mai 27, 2023 | stackconf

How about taking a walk down memory lane and seeing which insights stackconf 2022 has brought? Let’s continue this blog series with Michele’s talk “Are all programming languages in english?”.

What to Expect

After some time searching for the best programming language for his projects, Michele wondered: is there a programming language that does not use any English keyword? Of course, the short answer is no, but where do all the other non-English-based programming languages hide? How did we end up using that idiom for writing code? Let’s explore these questions during Michele’s talk!

Enjoy his valuable Expert Know-How and watch the Video!

You’re convinced by our top-level speaker and want to gain even more knowledge from our open source experts? Then you should definitely join this year’s edition of the event. stackconf 2023 takes place from September 13 – 14, 2023 in Berlin.

In case you also want to share some know-how about your topic around the whole DevOps lifecycle, feel free to submit your proposal until May 31.

We’re looking forward to hearing from you!

Katja Kotschenreuther

Manager Marketing

Katja ist seit Oktober 2020 Teil des Marketing Teams. Als Manager Marketing kümmert sie sich hauptsächlich um das Marketing für die Konferenzen stackconf und OSMC sowie unsere Trainings. Zudem unterstützt sie das Icinga Team mit verschiedenen Social Media Kampagnen und der Bewerbung der Icinga Camps. Sie ist SEO-Verantwortliche für all unsere Websites und sehr viel in unserem Blog unterwegs. In ihrer Freizeit reist sie gerne, bastelt, backt und engagiert sich bei Foodsharing. Im Sommer kümmert sie sich außerdem um ihren viel zu großen Gemüseanbau.

Lies mehr von Katja und triff unser Team

Alle Jahre wieder, kommt der Advent of Code

von Daniel Bodky | Dez 8, 2022 | Golang, NETWAYS, Development, Programmiersprachen, PHP

…zumindest seit 2015. Bereits zum achten Mal haben Rätsel- und Programmierfreunde rund um die Welt in der Nacht vom 30. November auf den 1. Dezember dieses Jahr gebannt auf die Veröffentlichung des ersten Rätsels gewartet. Ihr habt davon noch nie gehört und wollt mehr über diesen kniffeligen Adventskalender wissen? Dann seid ihr hier und heute genau an der richtigen Stelle!

Advent of Was?

Der Advent of Code ist ein 25-tägiger Rätselspaß, der jährlich vom 1. Dezember bis einschließlich 25. Dezember stattfindet und einen täglich vor zwei neue Herausforderungen stellt, die es zu lösen gilt. Die Rätsel sind hierbei in eine weihnachtliche Rahmenhandlung eingebaut, sodass man durch den Advent hindurch beim Knobeln nebenbei noch eine Geschichte erzählt bekommt. Löst man jeden Tag beide Aufgaben, erhält man in Summe 50 Sterne. Außerdem schaltet man durch seine Lösungen nach und nach auf der Website ein Bild im ASCII-Stil frei und hat also zusätzlich so etwas wie einen klassischen Adventskalender, der als Motivation herhalten kann.

Ist man bei der Bearbeitung auch noch besonders schnell, kann man es auf die globale Rangliste schaffen und den Advent hindurch Punkte sammeln, was aber quasi ein Ding der Unmöglichkeit ist. Private Ranglisten, bspw. mit KollegInnen oder im Freundeskreis, sind hier die weniger frustrierende Alternative.

Mein tagesaktueller Adventskalender auf der Advent of Code Website

Mein aktueller Adventskalender auf der Advent of Code Website. Wie das Bild wohl in 17 Tagen aussehen wird?

Das Handwerkszeug

Wie genau man die Rätsel löst, bleibt jedem selbst überlassen. Die naheliegendste Lösung ist es, programmatische Ansätze in beliebigen, mehr oder weniger gängigen Programmiersprachen zu finden – es gibt jedoch auch glühende Anhänger von Tabellenkalkulationsprogrammen, die ihre täglichen Lösungen als Excel-Datei oder Google-Sheet veröffentlichen. Auch auf Papier, mittels Minecraft-Schaltungen oder in Factorio-Fabriken wurden bereits des Öfteren Lösungen gefunden.

Alle Rätsel vereint, dass es einen pro Teilnehmer individuellen “Rätselinput“ in Textform gibt, aus dem sich eine eindeutige Lösung extrahieren lässt – meist eine Zahlen- oder Buchstabenkombination oder das Ergebnis einer Berechnung. Zusätzlich gibt es immer zumindest 2-3 Beispiele, wie die Lösungen für hypothetische Eingaben aussehen würden, sodass man sich nicht zu 100% auf seine Fertigkeiten, ellenlange Textaufgaben lesen zu können, verlassen muss.

Zeit für etwas Neues

Viele Teilnehmer nutzen die sehr offen gestellten Aufgaben, um eine neue Programmiersprache auszuprobieren oder bestehende Kenntnisse zu vertiefen – so nutze ich die Gelegenheit bspw., um endlich einmal etwas nachhaltiger in Go reinzuschauen, anstatt einmal im Quartal ein paar Zeilen Code „zu verbrechen“. Auch einige unserer Azubis haben den Advent of Code für sich entdeckt und machen momentan ihre ersten Schritte in PHP, und wieder andere KollegInnen geben exotischen Sprachen eine Chance, von denen ich zuvor noch nie gehört habe. Aber auch wenn man keine Lust hat, von Grund auf etwas Neues zu lernen oder auszuprobieren, bietet der Advent of Code eine gute Möglichkeit zum winterlichen Gehirnjogging, bevor es abends auf den Weihnachtsmarkt geht.

Wenn es eucht jetzt direkt in den Fingern juckt und ihr im Hintergrund bereits den Texteditor eurer Wahl gestartet habt, entlasse ich euch an dieser Stelle in den Advent. Aber auch ansonsten kann ich nur sagen: Probiert’s doch mal aus!

Daniel Bodky

Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Lies mehr von Daniel und triff unser Team

It all started with a GameBoy

von Diana Flach | Mai 9, 2019 | Development

It’s time to reflect and talk about video games. On how I got into programming and what drives me.

MissingNo: The glitch, the legend, my beginnings

Catch them all!

Pokémon, the first generation Game Boy games. They were the first thing that made me wonder just how programs and computers work. Back in the late 20th and early 21th century Pokémon Red and Blue were the talk of the schoolyard, if you are Generation X or a Millennial you probably know what I’m talking about. Fake rumors on how to get the rarest monsters with absurd guides were floating around: Do X while Y and have two of Z but don’t feed them after midnight. What gave these urban legends credibility were bugs in the games which had seemingly unrelated steps lead to weird and for a child even scary results – from characters being cut up and incorrectly reassembled over save games becoming unusable to a constant, never ending screaming sound.

For those who have not played these classics, I’m talking about the now famous MissingNo Glitch. Now we know the bug is caused by incorrect read and writes in the game. The games were written in Assembly and the programmers had very limited memory and space to work with, something was bound to break and such bugs are not uncommon in early console games. Most kids were just happy to have an infinite supply of Master Balls, an item in the game that could only be acquired once in the game, or get their favorite monster to the highest level quickly. For me this was enough at first as well but as time went on I grew more and more intrigued by the bug.

Minus World. A well known bug caused by incorrectly loading a level.

I asked my dad, he had no clue and neither did my mom.The internet was hard to use then still and I did not find my answers then. What I found was more confusing information and ways to manipulate the game, mostly collected by trial and error of other players, but there were also mentions of buffer overruns, memory violation and other terms I could not make sense of and didn’t hear again until I was allowed to watch The Matrix. This knowledge of the games made me the coolest kid on the playground for a while at least.

And after the Elite Four?

Only when I joined the local hackerspace and got involved with the CCC I finally got my entry point to the world of computers and programming. There was referred the book Learn Python The Hard Way and started writing code. Sadly none of my early work exists anymore, of git and GitHub I learned later still. The obvious choice then was to go to Uni and sign up for Computer Science class, three semesters I spent trying to wrap my head around the math needed to pass but ultimately quit because of it.

But my interest in programming was unbroken, I loved classes like Systems Programming which had assignments where you had to implement basic tools yourself, my own shell, my own email server, netcat – everything in C of course. That’s when I found my way to NETWAYS as an apprentice and have stayed here since, they let me write code. The code I write has changed, abstraction and new languages like Go have changed how I program but the lessons I learned from playing Pokémon in my bedroom still hold true: Sometimes it takes time to understand a bug.

If you’d like to join me in hunting bugs or talking retro games over a cup of coffee, head on over to our jobs page!

On giving up and trying an IDE

von Diana Flach | Okt 18, 2018 | Development, C++, Programmiersprachen, Golang

I dislike IDEs, at least I tell myself and others that. A 200 line long .vimrc gives a lot more street cred than clicking on a colored icon and selecting some profile that mostly fits ones workflow. So does typing out breakpoints in GDB compared to just clicking left of a line. Despite those very good reasons I went ahead and gave Goland and CLion, two JetBrains products for Go and C/C++ respectively, a chance. The following details my experiences with a kind of software I never seen much use for, the problems I ran into, and how it changed my workflow.

Installation and Configuration

A picture of my IDE wouldn’t do much good, they all look the same. So here’s a baby seal.
Source: Ville Miettinen from Helsinki, Finland

First step is always the installation. With JetBrains products being mostly proprietary, there are no repositories for easy installation and updating. But for the first time I had something to put in /opt. When going through the initial configuration wizard one plugin caught my eye: „IdeaVim“. Of course I decided to install and activate said plugin but quickly had to realize it does not work the same simply running vim in a window.
This „Vim emulation plug-in for IDEs based on the IntelliJ platform“ sadly does for one not offer the full Vim experience and the key bindings often clash with those of the IDE. Further I started getting bothered by having to manage the Vim modes when wanting to write code.
I sometimes miss the ability to easily edit and move text the way Vim allows, the time I spend using the mouse to mark and copy text using the mouse are seconds of my life wasted I’ll never get back!
Except for the underlying compiler and language specific things both IDEs work the same, identical layout, window options, and most plugins are shared, so I won’t talk about the tool chain too much. But it needs to be said that Goland just works, possibly because building a Go project seems simpler than a C++ one. Getting CLion to work with CMake is tiresome, the only way to edit directives is by giving them to the command like you would on the shell. This would not bother me as much if CMake didn’t already have a great GUI.

Coding and Debugging

Yet I wouldn’t be still using those programs if there weren’t upsides. The biggest being the overview over the whole project, easily finding function declarations and splitting windows as needed. These are things Vim can be made to do, but it does not work as seamless as it does in the IntelliJ world. It made me realize how little time is spent the actual typing of code, most of it is reading code, drawing things and staring at a prototype until your eyes bleed confusion (sometimes code is not well commented). The debuggers, again specifically the one of Goland, work great! Sometimes I have to talk to GDB directly since there are many functions but too few buttons, but the typical case of setting a breakpoint and stepping through to find some misplaced condition is simple and easy.

Alright, here it is.

There are a few features I have not found a use for yet e.g. code generators and I still manage my git repositories from the shell. The automatic formatting is cool, again especially in Go where there is one standard and one tool for it. Other than that I run into a few bugs now and then, one that proved to be quite a hassle is the search/search and replace sometimes killing my entire window manager. Were it free software, there’d be a bug report. But for now I work around it. Maybe I’ll drop CLion but I doubt I’ll be writing any Go code in Vim anytime soon.
If you think you have found the perfect IDE or just want to share Vim tips, meet me at the OSMC in November!

Flapping in Icinga 2.8.0

von Diana Flach | Okt 26, 2017 | C++, Icinga

The author viewing the code for the first time

Flapping detection is a feature many monitoring suites offer. It is mainly used to detect unfortunately chosen thresholds, but can also help in detecting network issues or similar. In most cases two thresholds are used, high and low. If the flapping value, which is the percentage of state changes over a set time, gets higher than the high threshold, it is considered flapping. It will then stay flapping until the value drops below the low threshold.
Naturally Icinga 2 had such a feature, just that it implemented a different approach and didn’t work. For 2.8.0 we decided it was time to finally fix flapping, so I went to investigate. As I said the flapping was working differently from Icinga 1, Shinken, etc. Instead of two thresholds there was just one, instead of one flapping value there were two and they change based on the time since the last check. Broken down it looks like this:

positive; //value for state changes
negate; //value for stable changes
FLAPPING_INTERVAL; //Compile time constant to smoothen the values
OnCheckResult() {
  if (positive + negative > FLAPPING_INTERVAL) {
    pct = (positive + negative - FLAPPING_INTERVAL) / FLAPPING_INTERVAL;
    positive -= pct * positive;
    negative -= pct * negative;
  }
  weight = now - timeOfLastCheck;
  if (stateChange)
    positive += weight;
  else
    negative += weight;
}
IsFlapping() {
  return 100 * positive / (negative + positive);
}

The idea was to have the two flapping values (positive & negative) increase one or the other with every checkresult. Positive for state changes and negative for results which were not state changes, by the time since the last check result. The first problem which arises here, while in most cases the check interval is relatively stable, after a prolonged Icinga outage one of the values could be extremely inflated. Another problem is the degradation of the result, in my tests it took 17 consecutive stable results for a flapping value to calm down.
After some tweaking here and there, I decided it would be wisest to go with the old and proven style Icinga 1 was using. Save the last 20 checkresults, count the state changes and divide them by 20. I took inspiration in the way Shinken handles flapping and added weight to the sate changes, with the most recent one having a value of 1.2 and the 20th (oldest) one of 0.8. The issue of possibly wasting memory on saving the state changes could be resolved by using one integer as a bit array. This way we are actually using slightly less memory now \o/

The above example would then have a value of 39.1%, flapping in the case of default thresholds. More details on the usage and calculation of flapping in Icinga 2 can be found in the documentation once version 2.8.0 is released.