A report of my first year at Triple D. How I discovered Triple D, why I wanted to join them, how I applied for a job and what we have done together since.
A discussion on where and how to handle your validation of incoming data requests. Using domain primitives as core concepts and the application API as a bouncer.
A short report on the Belgian SoCraTes unconference that took place on 7-10 july 2022 in La Roche en Ardenne, Belgium
Ensemble (or mob) programming is a technique used by XP developers to improve a teams productivity and knowledge by working closely together. This post provides a few tips that we learned after doing ensemble programming for about 6 months.
Having to work with different environments configs on your pc can be a hassle and dangerous. Let's explore an option that will improve your experience with it.
Developing software, solving technical issues is hard. But so is communication efficiently and productively. Having productive discussions isn’t something that happens automatically. And they play a big role in the way how the software will be designed. Conway's law taught us the correlation between software design and people interaction. So we must recognize communication as a skill that we need to master. Turns out there are quite a few things to be learned from Mob Programming.
The dependency inversion principle (DIP) is at the heart of a lot of software design patterns, technologies and architectures. This article will try to connect those dots, and hopefully provide some additional insight into this important principle.
Most people that use event storming use it for gathering the "Big Picture". But it can also be used for modelling out solutions to concrete problems. This blog post, I will try to demonstrate the power and usefulness of Event Storming for modelling out solutions. By using some simple building blocks, event storming allows us to model out complex systems rapidly. Without the need for very strict standardization.
In my series on heroics within software development teams, there is a type of 'hero' that I classify as the hero-bully. This is not the simple, ordinary bully, which may come to mind, who rules by force of intimidation. A hero-bully is someone placed on a pedestal by one group and who use the power from their received status to bully those around them that do not follow suit. This can even be completely unintentional!
Throughout these posts of mine on heroic behavior, my main metaphor has been the wild west. One of the well-known archetypes there is the famous hero gunslinger. In this post, I'll address the software equivalent of this.
In software development it is possible that a posse forms inside or across teams when people start placing their loyalty to one another above their loyalty to the customer/employer
In this post I will discuss my Lone Ranger pattern, a type of human behavior of software engineers, and the impact I think it has on its surroundings. Now the lone ranger is obviously someone who mostly operates alone. Lone rangers get the job done by themselves and are counted upon to save the day. Alas, the day needs constant saving.
In this post, I'll elaborate on what I identify as the Young Buck pattern. With my Wild West metaphor in mind, with the Young Buck I refer to the image of the young gunslingers that are just leaving home, stepping out into the big world. Usually, they are still full of high ideals and have a simplistic sense of justice. Unfortunately, their lack of real-world experience sometimes lets them get played for a fool.
There are heroes in software development teams. They are software developers that are often well respected by their peers and well known by management. They can be held up as an example for others. Shining example to all. But there are downsides...
In the software industry, the metaphor that is probably used the most for explaining things is the construction of buildings. A lot of our terminology relates to it. Building, architect, architecture, design, engineer. Unfortunately it is all too often that this metaphor falls short and doesn't really address the problem sufficiently.
In this blog post I'll demonstrate how to make applications that are external to a Kubernetes cluster available to the applications that are managed by K8s. This is useful for when we have started using Kubernetes to deploy and manage some your applications but not everything is managed at once.
Tackling complexity in the heart of software. But what is DDD exactly?
Writing code is all about abstractions, they help us grasp the complexity of the code by hiding low level details from high level concepts. The key to readable code lies in grouping the right level of abstraction in the same unit of code.
The anemic domain model pattern, with OO languages, is one of the most encountered "patterns". Yet it is considered an anti-pattern by many, despite it being so prevalent. What is it exactly? What are the arguments pro and con? How does it look in code? And what is my opinion on it?
What are the effects of TDD?
If you could use our help, let us know. Our normal base of operations in
Belgium is Ghent, Antwerp, Brussels triangle.
But we are open to any interesting proposals.
Contact us!
© 2024 Triple D