Posts

Over the weekend, we visited the Czech Republic for the third time (one and two). It’s mostly chance that sends us that way every time though. This time, we were invited by friends to accompany them in staying over at their family’s house - who made it their job to lead guided tours through Prague. We left Thursday right after work, hoping to get there in eight hours. A decent traffic jam, a missed exit, and some bad map reading decided otherwise; it added three hours to the trip. ...

In an Actor system, each Actor acts as a self-contained and autonomous component. An Actor can only communicate with other Actors by exchanging messages - they are not allowed to share state. Messages are handled asynchronously, and are nondeterministic. The location of Actors should be transparent; they can either live on the same machine, or on a distributed system. These properties make the Actor Model a great fit for parallel and distributed computing. ...

I just returned from our yearly Euricom retreat. This year, all forty of us got to spend four days in the South of Spain. Where we had longish sessions and a few workshops last year, we experimented with shorter talks this year - a la lightning talks, TEDx style. This format made it possible for everyone to speak, but also forced the speaker to keep the scope of the talk focused, and to organize the information in a way that attendees can get the gist of it in only twelve minutes. This makes for high-energy talks designed to peak one’s interest, to share useful tips, to plant a seed or to pitch an idea. Covering more than just technical ground alone made topics extremely diverse; from query tuning to empathy, from automated testing to how to explain your kids what you do for a living, from personal kanban to juggling with a diabolo. Going back and forth between these technical and less technical sessions kept my brain from being oversaturated. ...

On our way back from DDD Exchange, heavily influenced by yet another immersive DDD experience, we searched for ways to keep the momentum going. Sure, we met up regularly for CQRS beers, but we felt that we could do more, better. That’s when we coined the term modellathon, something like a hackathon, but instead of writing code, we would build models. Thanks to the effort of Mathias, Stijn and Yves, Tuesday marked the first get-together of the Belgian DDD user group in its official form. Combell was kind enough to provide us with a location, while Mathias fronted paper - lots of it too, post-its and markers. ...

These last few days, I have been working on a piece of our codebase that accidentally got very inheritance heavy. When it comes to inheritance versus composition, there are a few widely accepted rules of thumb out there. While prefer composition over inheritance doesn’t cover the nuances, it’s not terrible advice; composition will statistically often be the better solution. Steve McConnell’s composition defines a ‘has a’- relationship while inheritance defines an ‘is a’-relationship, gives you a more nuanced and simple tool to apply to a scenario. The Liskov substitution principle which states that, if S is a subtype of T, then objects of T may be replaced with objects of type S without any of the desirable properties of that program, is probably the most complete advice. ...

A few weeks ago, we set out to implement a feature that enabled back office users to set a new rate ahead of time. With our analyst and the involved user being out of the office for days, we had to solely rely on written requirements. Two of us skimmed the documents, but didn’t take the time to assure there wasn’t any ambiguity - it looked trivial really. I went back to what I was doing, while my colleague set out to implement this feature. Going over the implementation together the next day, he had built something a lot more advanced than I had anticipated. While I argued that this was a lot more than we needed, we agreed to wait for feedback from our analyst to return from her holiday. ...

Working on side projects, I often find myself using RavenDB for storage and IronMQ for queueing. I wrote about that last one before here and here. One project I’m working on right now makes use of domain events. As an example, I’ll use the usual suspect: the BookingConfirmed event. When a booking has been confirmed, I want to notify my customer by sending him an email. I want to avoid that persisting a booking fails because an eventhandler throws - the mail server is unavailable. I also don’t want that an eventhandler executes an operation that can’t be rolled back - sending out an email - without first making sure the booking was persisted succesfully. If an eventhandler fails, I want to give it the opportunity to fix what’s wrong and retry. ...

A good while ago, I blogged on commands (and queries). After exploring various flavors, I eventually settled on this one; commands, handlers and an in-memory bus that serves as a command executor. Commands help you in supporting the ubiquitous language by explicitly capturing user intent at the boundaries of your system - think use cases. You can look at them as messages that are being sent to your domain. In this regard, they also serve as a layer over your domain - decoupling the inside from the outside, allowing you to gradually introduce concepts on the inside, without breaking the outside. The command executor gives you a nice pipeline you can take advantage of to centralize security, performance metrics, logging, session management and so on. ...

After seventeen days, 2000 miles (3220km), seven states, eight national parks and fifteen motels, our second USA road trip has come to an end. Inspired, and with new insights, we’re leaving for Belgium in the morning. Along the way, we documented our journey in these posts: To Live & Die in L.A Fireworks, Tequila and Silvertown Blues She said yes! Stairway to heaven The long highway The road goes on forever Thanks for reading! When I return, I’ll get back to more technical writing. ...

We didn’t get to see a lot of Salt Lake City. Before heading to Idaho Falls, we hung around at the mall, feasted on Sushi, and bought new hiking shoes since ours literally fell apart. Since Idaho Falls just served as a launching point to Yellowstone, we filled the hole in our schedule with a date night; we had BBQ and went to see WorldWar Z. After another long drive the next day, we exchanged the dirt for greener scenery. We drove through Grand Teton, to get to of one our last and most anticipated destinations; Yellowstone National Park. We spent two days here, in which we drove across the extensive volcanic area, stopping at all popular attractions (geysers, pools, waterfalls…), spotting and stalking wildlife on the way. ...