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.

While I was preparing the deployment of a private pet project, I got the impression that my approach had significant room for improvement in the front-facing reverse-proxy department. The project consists of a scalable set of microservices serving several tasks in the backend, tied together with a message bus protocol. While the backend was perfectly capable of handling its own environmental adaptions and even supports multitarget deployment perfectly, either to a Kubernetes Cluster or docker-compose on my little VPS, the situation was much worse on the frontend.

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.