By Paul de Raaij & Evelyn van Kelle

Software development is at the core of most companies. We’re all digital enterprises that need to understand how technology is heavily influencing our core business and can make or break our competitive advantage. Making the right decisions when it comes to investing in technology has become a crucial skill for digital leaders. 

When using AWS Lambda functions you typically want to return a response to the client ASAP. However, imagine a situation where you calculate the response for the client and want to do some actions after sending the response to the client (e.g., write some metrics). Since standard AWS Lambda functions do not allow you to execute any actions after returning the response,  the client will experience extra latency due to the other actions which must be completed first. This blog explains how to use AWS Lambda custom runtimes to reduce the added latency and still do the additional processing.

Let me start with a short recap of my previous post. The reason we got to this point. I talked about the difference between being a true expert and relying on expert intuition. Sharing the struggles of a millennial social scientist that often gets asked if we can train our brain to be better at using System 2. Because, well, I’m going on stage talking about this stuff, so I better have an answer and step-by-step guide for how to achieve this.

And then I have to disappoint by saying that there is no such list of exercises and training. That I do have some suggestions, but it does not come in a ‘5 easy steps to reach your full System 2 potential – template’. 

What is happening to product quality?

Throughout my career as a quality engineer, I have developed a deep passion for quality. This passion goes way beyond the quality of software products. It is also about the quality of all interactions, quality of processes, and quality of work and life experience. I strive to bring excellence to every aspect of my life, and it hurts to see when greatness is lacking.

In my working life, I’ve seen the market focus shift more and more from quality to speed. We build more products than ever before; unfortunately, many of them are not up to par.

How IT organizations have tried to fix the degradation of quality until now confuses me sometimes.

tl;dr: Scroll down to Conclusion immediately

• In Storybook, each story is a new Vue app
  ⇒ register Vuex plugin on Vue prototype
• In Vue Test Utils, each test reuses the existing Vue constructor
  ⇒ register Vuex plugin on local Vue instance

This blog post demonstrates how to set up a simple unit test and story for a component that is connected to a Vuex store. These components usually are smart/container components.

In my current project assignment I have the honor to help 4 teams starting to improve code quality and to release more often. Unfortunately there are not a lot of dumb components, which are easier to test and to write stories for.

There is no safety net (tests + stories) created yet, so refactoring is kind of risky. The perfect Chicken and Egg problem! How can I still test these components? How do I mock the Vuex store?

Some time ago I forked a github project and published it on Bintray, so it could be used as a dependency by one of my other projects. Because publishing to Bintray was quite a hassle, I decided to take a look at GitHub Packages, which was released last year. My question was, would this be an easier way to publish a package and use it as dependency in another project? Let’s find out.

Bugs in recursion

Lets first talk about Day 24 – “Planet of Discord”. This puzzle reminded me of the fascinating Conway’s Game of Life that dates back to 1970.

Part one was about finding a repeating pattern in the ever-changing constellation of bugs. Now my loop detector that I had prepared earlier on day 12 to solve “The N-Body Problem” came in handy. So this part was quickly resolved. So let’s continue with the typical more advanced part.

We’re almost there, just two more days to go. Yesterday’s puzzle was a difficult one. In fact, it is my first one I didn’t finish on the day I started it. Even worse, I have yet to get my second star. I guess my modular arithmetic needs some brushing up… So I was glad to see an easier puzzle today. And it was another IntCode one, the 11th time this year already.

After having repaired our ship, we now have to rebuild the network from scratch. There are 50 computers that are all running the IntCode program. They send each other packets using the output and input instructions. That sounds familiar, right? We’ve already connected 5 amps together. But the twist here is that any computer can send to any other computer, and more importantly, the in- and outputs are non-blocking. So how does my IntCode implementation hold up?

Advent of Code‘s calendar unlocked a fiendishly hard puzzle today — one of the more difficult challenges this year as judged by the time the first hundred competitors needed to solve both parts. A little bit over two hours… while part 1 was relatively simple, as can be seen in the scatterplot visualizations of the daily global leaderboards.

….Aaaand here we are, in the last stretch of the #AdventOfCode 2019 puzzle-a-ganza! Like every year, the evil genius that is Eric Wastl has ramped up the puzzles gradually, and we’re now at those puzzles that you look at and go: “oof, another one? I just finished the previous day!”