Context Map was the first visualisation for the Bounded Context pattern from Domain-Driven Design. In a nutshell, it is a map of the different Bounded Contexts and their relationships. I tend to create a Context Map during or after a Big Picture EventStorming. Changing perspectives can be helpful, to challenge assumptions and get the best of different techniques.

However, sometimes it is hard to reach a consensus on the Context Map. I often operate in brownfield projects, with large organisations. Although people agree with the different bounded contexts, it is a process that takes time, and most significant energy. Which can lead to fatigue towards the method, and at the same time raises exciting patterns in the behaviours. But this blog post is not about emergent behaviour. 🙂

Chaos Engineering is a practice that has its roots at Netflix. It born from the challenges of moving their workloads from the data centre to the cloud; the transient nature of the cloud affected the way that they build and operate a system at scale. The initial project was called Chaos Monkey, and it has almost 10 years.

Since then the community grew, fueled by Netflix practitioners. Today there are commercial and open-source tools, and we can see more initiatives in different communities. The technical practices had matured, and the knowledge started to spread in the IT world.

However, it is deemed perceived as a technical practice. Can we leverage Chaos Engineering as a management practice?

Team Topologies is the work of Matthew Skelton and Manuel Pais, and I use it as part of my job. From a sociotechnical perspective, a team-first approach is paramount for any organisation and helps to decrease the accidental complexity. As such, I’m often asked “How can we operate in DevOps?” or “How can I have a reliable service to deliver value to my customer?”.

Recently, I was invited for a podcast interview by my brilliant colleague João Rosa. It was my first podcast interview (yes I was excited and nervous), and it has been keeping my mind busy ever since I received that calendar invite. The idea was that we would discuss a heuristic and see where we’d end up after 30 minutes. The heuristic for my interview was ‘If something is too complex to understand, it must be wrong.’ 

My first reaction was “Yes! That’s actually a heuristic I regularly use myself; what a coincidence!”. As hours and days went by, I started to notice that something was changing in my convictions. After some careful consideration and hours of contemplating, I can now say that my expert opinion regarding this heuristic is: “It depends”. (Ha! Surprising answer for a consultant, right?)

TL;DR: There’s a lot of articles and blog posts on preventing or shortening cold-starts for AWS Lambda instances. I learned that AWS Lambda forces cold-starts to happen nevertheless by terminating active, running instances every two hours.

AWS Lambda is an event-driven, serverless computing platform delivered by Amazon. It runs code in response to events and manages all the computing resources required by that code. In their responsibility for managing computing resources, it is known that AWS terminates idling Lambda instances. I discovered that AWS also terminates active, running instances, and quite predictably so.

Recently on Twitter Chris Richardson asked if anyone has created a consistent and comprehensive glossary for EventStorming core concepts.

I replied saying that #EventStorming is fuzzy by design. There are standard core concepts, and depending on the context, we use different words for the post-its. Because with that fuzziness, you get more insights. I call it just enough structure to let transactional conversations flow and create a shared mindset and tons of new insight—a shared pool of understanding. However thinking back at past workshops, and from skimming the EventStorming book checking out the core concepts, Chris has a point, we lack an excellent consistent glossary of the core concept, also specific per type. This post describes my take on EventStorming core concepts written down in a consistent and comprehensive glossary. Just be sure to try and avoid jargon as much as possible, as it sets up the unnecessary insider-outsider distinction.

I have moved the content of this blog to the DDD-crew GitHub page, were it will be updated by the community.

https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet

Nowadays, Cypress is rapidly becoming the standard for UI test automation. With cross-browser support being available as per early June 2020, we at Xebia see the traction growing and growing. We’ve recently contributed to this growth by open sourcing a plugin that ensures that Cypress tests can deal with file download dialogs from the browser. In this blog, we explain the background and how we approached it.

Likely, a lot of the code you run is not code you wrote. But what does that mean in terms of security? In this post, we will discuss how long it takes to detect a malicious package, what happens if you include one of these packages, and what you can do about it.

Introduction

Automated browser testing is essential for asserting the quality of the code you deliver when developing web applications. Some defects only become visible at the point when you tie everything together in your application. You want to catch these defects as early as possible to minimize the cost of fixing them. There are a lot of great tools out there to help you with this and I would like to highlight a tool named Playwright.

Asynchronous streaming solutions, such as Rx or Reactor, rely on callbacks to perform flow control (or backpressure). Without flow control, systems could overflow and eventually crash. In this post we will look at the difference between flow control in synchronous applications and their asynchronous counterparts? [more…]