Select Page

NETWAYS Blog

DEV Retreat 2019 Recap

by | Jul 11, 2019 | , ,

In this Episode: Everybody gets blown to smithereens (digitally).

Those team events are often paired with team-building exercises, causing possibly uncomfortable situations with your co-workers or let you find out things you never wanted to know about them. That’s at least what every comedy involving such an event leads us to believe. So for the breaks between remembering what we did well and not so well since our last DEV Retreat we had a game of “Keep Talking and Nobody Explodes“: The only game released since 2000 to require a manual, it’s also great fun.

The method for retrospection did not change much from last time but we had better sticky notes this time, which helped! We started off with a general assessment of our well being and mood and I am happy to report nobody was too grumpy. This was followed by thinking back what had happened, which projects did we do, what has changed and our unfinished business. Surprisingly a lot of us remembered not only big releases of Icinga 2, Icinga Web 2 or other larger projects but also small things, like our Trainees first merge, taking a break from PHP in favor of JS or making a brochure to advertise apprenticeship at NEWTAYS.

After making concrete plans on how to improve with out team dinner was served. The Hotel had a habit of making the portions a bit smaller than some would have liked but after the dessert nobody was hungry anymore and ready for a mellow evening with Gin and Tonic.

Of course not all is happy, rainbow and unicorns. But there weren’t any problems we aren’t confident we can solve. Except what to do for our next DEV Retreat. But our colleagues went for a round of arrow tag, maybe we’ll steal that idea for next time.

It all started with a GameBoy

by | May 9, 2019 |

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!



			
			

				
			


				
														

													
								Oida, geht das nicht schneller?!							
											

				
					
by  | Jan 31, 2019 | , , 
Findet 99 Linux Befehle


Ich hatte etwas downtime, also habe ich ein kleines Programm geschrieben das Wortsalate erstellt: wordsalad, Code hier auf Github. Ist noch nicht ganz fertig, aber wie ihr sehen könnt tut es schon seinen Dienst. Es nimmt eine Liste an Wörtern und versteckt sie in einem Suchbild. Der Algorithmus hierfür ist: Schmeiß das Wort irgendwo aufs Spielfeld, wenn es klappt gehe zum nächsten. Wenn nicht versuche das ganze nochmal, bis zu 200 mal pro Wort. Sollte sich so kein freier Platz für das Wort finden, mach das ganze Spielfeld neu und starte von Null – bis zu 2000 mal. Nicht besonders intelligent aber wofür haben wir sonst Prozessoren im Gigahertz Bereich!


Die Hertz sind machen nur ein Teil der Geschwindigkeit aus, ein anderer ist die Anzahl der Threads. Parallelisierung erlaubt es modernen Programmen ihre Arbeit doppelt, vier mal, acht mal oder noch schneller zu verrichten (theoretisch zumindest). Aber was bietet Go in dieser Hinsicht? Concurrency. Und was ist das? “Irgendwas mit Multi-threadding und Parallelisierung” dachte ich anfangs. Sogenannte Goroutinen können einfach gestartet werden und haben mit channels eine simple und mächtige Form der Synchronisierung und Kommunikation.


Findet 40 Staaten in denen die USA einen Coup herbeigeführt haben


Aber ich lag falsch, Concurrency ist eben nicht Parallelisierung.


Meine Vermutung Concurrency sei nur ein anderes Wort für Parallelisierung kam von der Bedeutung und Verwendung außerhalb der IT Welt. “Concurrence” bedeutet Kooperation, Zustimmung und eben auch “zur gleichen Zeit stattfinden”, gemeint ist hierbei aber wohl die erste Bedeutung. Goroutinen laufen eben nicht gleichzeitig ab, sie wechseln sich ab. Sollte eine routine mal länger nichts zu tun haben, weil sie etwa darauf wartet etwas von der Platte zu lesen oder schreiben, kann eine andere arbeiten. So laufen sie nicht gleichzeitig, sondern miteinander ab – sehr praktisch für schnelle Prozessoren.


Findet 30 Österreichische Schimpfwörter


Aber man hat eben mehrere Prozessoren, sollen die sich die übrigen etwa langweilen während einer arbeitet? Nein, go verwendet einen Prozessorpool der goroutinen wenn möglich parallel laufen lässt. So hat man das beste beider Welten, es ist einfacher mit Concurrency zu designen und die Sprache kümmert sich im Hintergrund darum das es möglichst schnell passiert.


Sollte euch das Thema weiter interessieren, kann ich diesen Talk von Rob Pike empfehlen.


Viel Spaß beim Suchen 🙂


			
			

				
			


				
														

													
								On giving up and trying an IDE							
											

				
					
by  | Oct 18, 2018 | , , , 
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!


			
			

				
			


				
														

													
								The Walrus Has Landed – Structured Logging in Go							
											

				
					
by  | Aug 2, 2018 | 
Walrus pup at Kamogawa Seaworld, Japan. Photo by Max Smith.


Logs let us understand which combination over time lead to a specific event, we can further analyze them to monitor trends or have them print enough information to narrow down a problem to a single line of code. They are the written history of the IT world. Did I lay it on too thick? Probably. But the bottom line is, logs can be very useful. But before you can read logs, one has to write log messages, assign severities and decide which information is worth print and which is not.

An attempt to make logging easier for the programmer, more readable for the user and better formatted for log processors is structured logging. This concept has been around for a while but ‘got cool’ only recently with the advent of large scale logging processors like ElasticSearch or Graylog. Let’s go by example, the following are two log messages, the first being good old lines of text and the second structured logging


[2018-07-31T16:25:07+02:00] - Information/Api: New connection ("GET") from "192.1.1.8" to endpoint "/v1/get-the-cookie" with token "aa76dfdf1023dfa567".
time="2018-07-31T16:25:07+02:00" level=Info msg="New connection" context=Api request_type=GET remote=192.1.1.8 endpoint=/v1/get-the-cookie authtoken="aa76dfdf1023dfa567



It’s easy to see how the structured logging message is easier to comprehend for a logging processor. And while you can grep use grep on both the same way to get a quick overview in this case, the key=’value’ scheme of the second line will always have that advantage while string logs may get convoluted – we all had to chain multiple instances of `grep` and `grep -i` to get rid of false positives at some point, no?

Now let’s look at the code, since I promised it would be easier for developers as well. In this case I’ll be using logrus, a structured logging library for Go. Here is code how these two lines could look like:


log.Information("Api", "New connection (\"%s\") from \"%s\" to endpoint \"%s\" with token \"%s\", conn.type, conn.remote, conn.path, conn.token)



Simple enough. Timestamps are automatic, the severity part of the function call and the context is one of the parameters. Now the same with logrus:


log.WithFields(log.Fields{
		"context":      "Api",
		"request_type": conn.type,
		"remote":       conn.remote,
		"endpoint":     conn.path,
		"authtoken":    conn.token
	}).Info("New connection")



This looks like a lot more to write and less simple at that! Was I lying? Of course not. The big advantage of using logrus are temporary loggers with default fields:


apiLogger := log.WithFields(log.Fields{
		"context":      "Api",
		"request_type": conn.type,
		"remote":       conn.remote,
		"endpoint":     conn.path,
		"authtoken":    conn.token
	})
apiLogger.Info("New connection")



Any future logging within the Api context can use this `apiLogger`. Letting us shape the log messages with exactly the information we need, without too much copy and paste or having to think about the type of object we want to log:


apiLogger.WithField("data",conn.data).Debug("Submitted Data")
apiLogger.WithFields(log.Fields{
		"error": "Too much data",
		"error_id": 5,
	}).Warn("Connectivity issue")
apiLogger.Info("Connection terminated")
.... Outputs:
time="2018-07-31T16:25:17+02:00" level=Info msg="New connection" context=Api request_type=POST remote=192.1.1.8 endpoint=/v1/give-me-cookies authtoken=aa76dfdf1023dfa567
time="2018-07-31T16:25:09+02:00" level=Debug msg="Submitted Data" context=Api request_type=POST remote=192.1.1.8 endpoint=/v1/give-me-cookies authtoken=aa76dfdf1023dfa567 submitted_data="{some json blob}"
time="2018-07-31T16:25:17+02:00" level=Warn msg="Connectivity issue" context=Api request_type=POST remote=192.1.1.8 endpoint=/v1/give-me-cookies authtoken=aa76dfdf1023dfa567 error="Too much data" error_id=5
time="2018-07-31T16:25:24+02:00" level=Info msg="Connection terminated" context=Api request_type=POST remote=192.1.1.8 endpoint=/v1/give-me-cookies authtoken=aa76dfdf1023dfa567



It’s easy to see how having to write log messages the usual way would be quite tiresome and prone to missing some information, be it by oversight or misjudged importance. Stay tuned for future updates on our journey into the world of Golang and hopefully we’ll see you at OSMC.


			
			

				

				

				 
			

				
				
				
				
			

			

				
				
				
				
				

				
				
				
				
				


Trainings








Web Services








Events