Software testing generally raises an association with tests that determine the correctness of an implementation by asserting against an expected behavior or result. Regardless of their importance, tests on unit- and integration level cannot answer all questions regarding the production readiness of an implementation. Performance, resource efficiency and security become even more important in connection with cloud solutions, where more efficient code has a much higher likelihood of scaling better and saving costs.

I recently withness and participate in intensive debates regarding the superiority of either “serverless”/FaaS or containers in any form in terms of management and orchestration. Often, people are very vocal about an extreme position of the spectrum, while I pursue a much more relaxed, neither less opiniated approach. This post is supposed to briefly summarize my opinion. I will not dive deeply into the details of containers and FaaS more than neccessary to avoid redundancy and keep the post focused.

If you are currently preparing for an AWS Solution Architect certification, you might have stumbled across numbers of articles providing hints and experiences on how to pass the exam, often consisting of affiliate links and talking heads on video. In this article, I want to provide my point of view regarding preparation and passing the exam - completely ad-free. Preparation There are several ways of preparing for an AWS Solution Architect Associate (OK Google!

For the relaunch of my personal website, I used the awesome Hugo static website generator, and for a shorter leadtime, extended it with two custom Hugo Shortcodes I use frequently. Automatic Gallery The template I am temporarily using for the launch phase already contains basic gallery support with the primary aim of styling based on Fancybox, but it lacked automatic serving of a directory as a gallery. What I knew was that I wanted to drop my galleries under /static/galleries/{name}, as I heavily prefer the convention-over-configuration maxime.

Having used legacy PHP-based CMS solutions such as Wordpress or Typo3 for a long time, I finally switched back to a static website generator, for various reasons. In this article, I want to outline a setup which makes it possible to treat distributed website development as clean as any other software, including versioning and continous deployment. Why Hugo? I retired Wordpress in favor of Hugo for several reasons: Wordpress has a very old codebase with mixed quality and reliability A lot of work was required to make it secure.

Given an overall systems architecture or infrastructure which gets the “IoT” box ticket, the will probably be a place where data transfer and size will come into account, for instance if constrained devices are using a potentially unreliable or expensive connection, such as a cellular data connection. For instance, an enbedded monitoring device which serves the purpose of delivering real-time telemetry to the core system of a car manufacturer will quickly come to a point where JSON-Encoding might exceed the computing power required for the actual job.

This is a companion article for my first talk at the Go User Group “Gophers” Aachen about Protocol Buffers and coupling Go services with Java. In a distributed system it is required to go beyond communication by shared memory, and even cross technology borders. This is nothing uncommon, it is more or less standard for a contemporary system to be designed as a distributed, interlinked collection of software modules which are not necessarily implemented in the same technology or even computer architecture.

In various test cases, primarily those covering components that interact with the filesystem and use filesystem entitites for a convention-based operation, it perfectly makes sense to provide a filesystem resource in an expected state to assess the component-under-test’s behavior. To provide a resource in an expected state, the classic approaches are: Have a handcrafted directory with testdata on the developer machine Couple the testdata with the source in the repository Both methods are quite poor, as the first will definitively yield into trouble when the application gets built on a CI or any other machine, or when the fact that the local filesystem is anything but immutable shows it evil face.

Performance Testing with Apache jMeter Designing and implementing distributed systems, both customer-faced or just datacrunching farms, one is soon required to determine performance impacts and possible bottlenecks. In this specific case, I wanted to gain information regarding the limits and scalability aspects of a customer-facing web application which also manages a high number of connected devices. Why I chose Apache jMeter The performance testing case I was working on made me opt for jMeter in the end, for the following reasons:

Let the code speak for itself. Java 8 public class Application { public static void main(String[] args) throws IOException { Map wordCounts = Files.lines(new File("samples.txt").toPath()) .parallel() .flatMap(Pattern.compile("\\W")::splitAsStream) .filter(word -> word.length() > 6) .map(String::toUpperCase) .collect(Collectors.toConcurrentMap(w -> w, w -> 1, Integer::sum)); wordCounts.entrySet().stream() .sorted(Map.Entry.comparingByValue(Comparator.reverseOrder())) .limit(20) .forEach(System.out::println); } } Golang type WordOccourences struct { word string occourcenres int } func main() { expression := regexp.MustCompile("[^a-zA-ZüäößÜÄÖ]") data, error := os.Open("samples.txt") defer data.Close() if error == nil { var wordCounts = make(map[string]int) scanner := bufio.

My company gave away a couple of abandoned spare devices previously used for evaluation purposes. So, I got hands on a dreamplug, a socket-plugin sized mini computer (ARM based) with decent power, low energy consumption, integrated dual Ethernet, WiFi, Bluetooth and, most important, an optical audio output - in other words: a Raspberry PI with a housing and the IO I was missing. The digital output was the primary reason for using it as an addon to my stereo.

Alexa Skill development and testing with Java As the mayority of the Alexa Skill developer tutorials are focusing on Node or Python, I would like to highlight the Java way and point out some things that I missed in the official trainings and some things that I would personally have solved differently. For demonstration purposes, I wrote a simple fun application which finds crew members on the enterprise spaceship. A user could ask Alexa questions like “Where is captain Picard” or “Ask Enterprise where Captain Picard is” - so this application makes perfectly no sense, but it demonstrates everything a developer has to know to implement own basic skills.

After various encounters and two projects which employed MQTT, I thought it was a good idea to write a summary about my experiences and my point of view. As my new job is very close to the IoT and Industry 4.0 sector, it did not take much time to encounter the hype. Once upon a time MQTT is, like AMQP, a messaging protocol for distributed systems, meaning that a node can pass a message to one or multiple other nodes.

When I completed my compiler design studies, I felt it was not appropriate for me to give my exercise projects any fancy names and put them on Github. With this in mind, I was used to question any new language which came out of nowhere and wait for a number of readings on my technology radar before considering to deal with it. With a number of significant readings from Google Go, I decided to give it a pleasant test drive.

During the evaluation period of two new projects with an expected lifespan of 10 years, free from any legacy constraints, I recently had to decide on a method to provide data persistency. Starting from scratch in 2015 prompts the architect with quite a lot of interesting solutions, especially because the more and more mature solutions which are not strictly pursuing the Relational Database approach. In this article I will summarize my personal “history” of how I dealt with persistency and which way I am going to choose.