24 hours of coding in Bonn

Every now and then, we have a companywide event we call a 24h Sprint. This means that we have one day where everyone interested can spend a whole working day not on their regular projects but on a technical topic of their choice. Food and drinks are provided, also, of course, technical equipment (if needed) and naturally a great atmosphere. We had another of these 24h Sprints again a couple of days ago and here are some of the cool things we did in our Bonn office:

Over engineering Tic-tac-toe

When learning something new, you don't always have to go the most efficient route. Take the game of tic-tac-toe for example. You could quite easily build it as a client only application - heck, Google even lets you play the game within your search results! But if your goal is to learn about new technologies you can do what we did: build a version of Tic Tac Toe using React for the frontend which communicates with a webservice built with Spring Boot and Spring Rest to calculate the winner.
A Tic Tac Toe game built with React
These technologies work together really nicely. If you like, you can even serve your React application using Spring Boot... But that's for another time.

A little bit of Go

One thing we often do for and with our customers is building microservices. Most of these are built in Java (e.g. using Spring Boot like we did with tic-tac-toe) or JavaScript (as you'll see in the MagicMirror example), but we're always open for new ideas. So, the Micro toolkit in combination with the Go Micro framework peaked our interest.
As the name suggests, the latter is written in Go - a language that has a few unexpected quirks, as it turned out. The first step was to understand a Hello, World! example; including understanding how Go worked there. Then we extended the example to create a client and two services. All of them are accessed via an API gateway which uses Consul for service discovery. In the end, the client could be accessed via the HTTP gateway and could talk with both services. Success!

Mirror, mirror on the wall...

The MagicMirror2 project allows anyone to build an augmented mirror which shows you... well, whatever you like. There are predefined modules you can use but it's also possible to build your own. So, we built a frontend module and Rest webservice to show company share key data for some of the largest stocks in the German financial market.
Our MagicMirror^2 showing weather information
In theory, this is relatively simple - the mirror basically just displays a web application which can be built with any kind of technology. However, getting the data wasn't as simple as one might imagine, since no free API seems to supply all of the data we wanted. We ended up building a web scraping node.js microservice for three different sites, collecting information about 30 different company shares while the frontend was some simple JavaScript embedded into an existing PHP application. And it worked!
If you're interested, you can find the microservice for collecting financial data on GitHub.

Beat down my ELK

When you have a sufficiently complex distributed application, you probably don't want to handle log files manually - which log contains the information I need? Or are there several? And which instance of which server did the user talk to? Stuff like that. A common solution is using an ELK stack = Elasticsearch + Logstash + Kibana. However, with Logstash (which is often run once for each application server on which logs are produced) performance can be a challenge. That's where Beats comes into play - specialized, low profile agents can take over the collecting role of individual Logstash instances, sending their data to a central instance and thereby improve performance drastically while, for example, handling backpressure with ease. At least, that's the claim.
To test this claim we built a small Spring Boot application which produced logs consumed by a Beats agent. The agent then passes the information on to an ELK stack, persisting them in Elasticsearch. And we can confirm, that at least in our demo application it did a great job.

Estimate my story: mobile edition

Many of the projects we work on at Senacor are agile and more often than not, part of that is playing planning poker. Traditionally this often happens using cards with numbers or T-shirt sizes printed onto them. But why not build an app which allows everyone to estimate on their phones and then tallies up the results? That's what we did!
In addition to React (for web applications), Facebook also built React Native to build native apps for iOS and Android using the same design as React but integrating with native mobile functionality. We built the estimation part of this using React Native and the result view using React, both of them communicating via WebSockets.
Who is going to estimate?
This worked out really well. The whole application is fast and responsive, the result view shows the team who gave which estimation (including the highest and lowest results) and we have versions for both iOS and Android without any extra work. Nice!

The estimation app on iOS The estimation app on Android
The project consists of three parts, which are all available on GitHub:

Terraform my infrastructure

Of course, we couldn't just ignore the whole DevOps movement. Specifically, we wanted to take a look at Terraform, which is an open source tool for handling infrastructure as code. After all, if our code can be version controlled why not do the same with the environments our code runs on? That would go a long way towards fixing the whole works on my machine issue.
Without going into too much detail, Terraform supports a huge range of cloud providers (including Google Cloud Platform, Amazon Web Services and Microsoft Azure, to name just a few) which are terraformed to our desired infrastructure. Or is "infrastructureformed" a word? Whatever.
Also, it offers dry runs to check that what you created works before pushing it to the cloud. And to prove it works, we built a complete infrastructure consisting of a private cloud VPN server, an internet gateway, private and public routing, a Ubuntu VM and an NginX INSTANCE serving stuff on port 80 - all defined in Terraform configuration files and then automatically installed onto AWS. Try doing that with bash scripts!

My computer says: That's a panda!

TensorFlow is a machine learning library created by Google and first released to the public in late 2015. It allows anyone to train neural network models and use such models (self-trained or downloaded) in your software. However, the main API and most examples (including all of the Getting started section) use Python. That's a problem when you create most of your software in Java and JavaScript. Luckily, there is a Java API. And a Hello, World! example. And... Well, that's pretty much it.
A panda waiting to be recognized by TensorFlow
Therefore, to recognize above creature with Java, we had to experiment a bit. By translating existing Python examples into Java, we finally got a promising match:
It's a panda!
So, we can finally confirm: it is a panda! (At least, with a probability of 95.21%.)

What's next?

Some of the experience we collected will probably be used in future projects while other parts were just for fun. But that's the great thing about these 24h Sprints: they don't have to lead to anything as long as they're fun. :-) And if that appeals to you and you're not yet a part of Senacor, you can always apply for a job. ;-) The next 24h Sprint is sure to come and along with it many great topics.


Images

The header image was taken by Pixabay user Free-Photos and the image of a panda was taken by Pixabay user skeeze. Both were published under the CC0 Creative Commons license.
All other photos and screenshots were taken by us and may only be used with explicit permission.