Hello there! This month's newsletter is brought to you by Jan whom you might have already seen in some of our Tech Weeklies videos.
Jan is a software developer at Futurice Munich. Before coming to Futurice, he already collected a variety of work experiences from different areas, such as being a maintainer of the popular frontend framework Cycle.js, as well as writing control software for a satellite that is now orbiting earth. His passion is using tools, languages and techniques to improve the quality and security of software and services around him. For that reason the main topic for this Dev Breakfast is "correctness by construction".
To start off with the theme of correctness, I want to share this blog article by Alexis King with you. Validation is a very common task for developers, but is usually done in a rather ad-hoc way. The article describes how we can push validation to the outskirts of our application by refining our data types to be impossible to construct without said validation.
Just like the previous post advertises refining data structures to gain information about external data, in this article the author shows the problem with using simple boolean values: The only information they contain is a simple true or false, not why or what that value represents. This problem usually is called "Boolean blindness" and can be solved by thinking differently about our APIs.
While improving quality in the code of applications itself is good, it misses the fact that most of the software we use is not written by us, but only configured by us. Usually this means at best a loosely structured standard like JSON or a mess like YAML where you can't tell a boolean value apart from a country name. Luckily, there exists a very interesting alternative called Dhall, that not only avoids typos by using a type system, but also allows you to template parts of your configuration with functions. See the blog article for a case study of using Dhall for DevOps.
Lastly, we should never forget testing when talking about software quality. Usually testing is done by creating example based unit tests, but they tend to not show the interesting bugs or test for race conditions. In general no one can be expected to write a test for an edge case that they did not think of yet! This is where random testing comes into play. Instead of writing out examples by hand, you specify an abstract behavior and check if random inputs follow that expected behavior. In the talk, John Hughes shows a series of real-world examples how random testing can help with finding bugs with less effort than normal unit testing.
Kha Nguyen built an application combining Amazon Alexa's voice assistant with Helsinki Regional Transport Authority's (HSL) data API to build functionality to know when specific buses and trams leave from near his home.
As you know, Amazon Alexa is a virtual assistant that can be programmed to make your life easier. Kha explains how Alexa works behind the scenes and how to use its interfaces to run custom Javascript code based on different voice commands and intents.
We are looking for people who know their stuff, who are passionate about it and want to learn more - not just a person for a specific position. We want this person to be involved in communicating with the clients and we want them to have a say on how something should look and work. If building usable digital services is your thing, checkout this opportunity!
Whether it’s JavaScript frameworks, REST APIs, NoSQL databases or DevOps - web is your thing! You can position yourself in frontend, backend or somewhere in between and you have the proven ability to implement complex, multi-layered services with high-quality frontend and backend code. This might be the career move you've been waiting for.