After our deep dive into a Redis event store implementation we’re now getting back to actually adding functionality to the blogging application. Like the Getting started with Rails guide we’ll add the capability to add comments to blog posts. Adding this functionality is straightforward, but it will require us to look into resolving conflicts when multiple people make modifications to the same blog post or comment concurrently.
In the previous part we developed a fake event store for our blogging application. This event store just kept all events in-memory, making it unsuitable for production use. But it did allow us to adapt our application to using an event store, and let us work out the details of the event store interface without having to worry about an actual persistence mechanism.
In this part we’ll develop an event store implementation on top of Redis, a key-value store with support for additional data structures (such as lists and hashes), publish/subscribe, and transactions. If you’re more interested in adding new application functionality, you can safely skip this part and go to part 4 – conflict resolution.
In the first part of this series we developed a simple blogging application that uses event sourcing to keep track of all changes made by the users. However, we did not yet write these events to durable storage. This means all data is lost when the application is restarted, which is clearly not acceptable. Saving and restoring events will be the responsibility of the event store, which we’ll start implementing in this part. But before we get to actually writing events to disk, we must first tackle the problem of maintaining data consistency when using event sourcing.
This is the first part of a series on building an event sourced application. We’ll build a simple blogging application (inspired by the Ruby on Rails “Getting Started” tutorial), so the domain should be familiar. This allows us to focus on implementing a memory image based architecture using event sourcing. Another goal is to show that this kind of architecture is not more complex (and arguably, simpler) than those implemented by traditional database centered applications. The example code is in Scala using the Play! web framework, but should be understandable enough if you come from a Java (or similar) background.
Continue reading Simple event sourcing – introduction (part 1)
Last friday I gave a Masterclass called ‘Lean Agile Architecting’ to architects. Very interesting masterclass and a couple of things struck me. The issue for architects in an Agile environment is their position and responsibility.
The thing with the change from waterfall to agile is that architects feel their role is being undercut, the team just goes fast and are only paying attention to the Product Owner. The standard answer they seem to get is: ‘then join the team’, but they feel reluctant to do so, and most of the times they can not fully commit (full time). So they pass, and they feel miserable about it, since now this Agile project is going to make mistakes, and can not learn from past experiences and their expertise.
The answer lies in the closer observation of the definition of Agile and Architecture.
Continue reading Architect in Scrum
Recently I had to adapt some older Java code to support a new requirement: an existing CSV report needed to include a user’s email address, translated from the user id. Pretty simple, but how does the CSV report generator translate the user id to an email address?
Continue reading Picking the right abstraction
Searching the web for new Agile games I came across: You sunk my Methodology. This game seemed like a strong metaphor to show the power of early feedback, while using Scrum.
Each shot costs 10.000 and when you sink a ship you get the_ships_size * 50.000 (e.g. the submarine of size 3 will reward you with 150.000). If you keep track of the balance after each iteration, you could also try to get across the idea that stopping after a few iterations might give ‘good enough’ rewards.
**Update: Now also direct playable on GitHub.
Play! is a web framework for Java and Scala. Play promises to bring the developer productivity of web frameworks like Ruby on Rails to the Java and Scala languages. Of course, it wouldn’t make much sense just to copy Rails. So Play adds its own spin: Play 2.0 is fully statically type checked, giving the developer quick feedback when something doesn’t make any sense.
Now that Play 2.0 is getting closer to final release I took some time to dive in. Here are my first impressions, using the Scala APIs.
Continue reading Play! 2.0: A First Impression
Development teams new to Scrum are introduced to a number of mandatory aspects that come with the framework. One of these is the Daily Scrum, or often referred to as the Daily Standup (meeting) or Standup in short. The purpose of this meeting is to synchronize the status of the development team and to do this in a short and focused manner. In this post I’d like to discuss an anti-pattern I see observing and being part of Daily Scrum meetings and how to overcome it.
Continue reading Use your Daily Scrum as a success driver
I am a big fan of Big Visible Charts, also referred to as Information Radiators. By radiating information using such charts everything is visible and people can use that information to act upon it. Recent observations made me realize that not all charts are visible though. Even when they are big and in your face.
Continue reading Big -but not so visible- charts