Saturday, May 3, 2014

How Mongo DB can solve Event Sourcing versionning (Part 1 of 2)

First of all I invite you to read my previous post on How to support changes in your software. It will give you a good heads up on where I’m going with this post.

imageHaving a strategy to support change is a good practice but sometimes it fails on the first change because, well you know, it’s not that easy. I’m a big fan of document database and NoSQL. Mongo DB is a good match for me because it’s easy to install on Windows and use from C# application. I won’t go in to detail on how to create a .NET Application that connect to Mongo. The are plenty of site out there (here, here, here and here) that can help you with that. Document databases are often referred to as schema less database but it’s not completely true. There is a schema, it’s just not as rigid and well defined as traditional databases. The schema used Mongo is based on Json format. For example look at the following Json document. (Only the event payload is shown here and in all other sample)

{
    "Name" : "Logitech wireless mouse",
    "Price" : "29.99$"
}

This document can be the definition of a event in an Event Store. The C# class to handle this event should be:

public class ProductAddedEvent : DomainEvent
{
    public string Name { get; set; }
    public string Price { get; set; }
}

The missing fields are manage by the DomainEventbase class. This is a really simple object to illustrate the concept.

imageNow we realize that we made an error in the definition of the Price field. We want to convert it into a double type to be able to make some calculation with it. In an event sourcing system the events are immutable, they must never be changed. The past is written in stone. So we need to work pretty much like functional programming to evolve our event to a new format. The first thing we need to do is to tag each evolution with a version number. Because all our event derived from the DomainEvent class that is easy. First add a base type to DomainEvent to hold the versioning concerns :

[Serializable]
public abstract class DomainEvent : Versionable
{
  // ...
}

Now take alook at the Versionable class :

[Serializable]
public abstract class Versionable
{
  private int? _version;

  public int Version
  {
    get { return _version.GetValueOrDefault(CurrentVersion); }
    set { _version = value; }
  }

  protected internal virtual int CurrentVersion
  {
    get { return 1; }
  }
}

This will set any new DomainEvent to version 1 by default and provide the ability to change it in the future. The Version field will be serialized and save in Mongo DB. Here is the C# class that define the event payload :

public class FooEvent : DomainEvent
{
    public string Name { get; set; }
    public string Value { get; set; }
}

The serialized version of that class will look like this :

{
    "Version" : 1,
    "Name" : "Foo",
    "Value" : "3.00$"
}

imageNow that we can know which version of the document we are processing we can start thinking about changing the C# class. The goal is to preserve all needed data from one version to the other. Depending on the type of modification different technique can be used. Our first change will be to change the Value field type from string to double. The only good way to do that is to use Mongo BSonSerializer attribute.

public class FooEvent : DomainEvent
{
  public string Name { get; set; }
  [BSonSerializer(typeof(AmountToDoubleSerializer)]
  public double Value { get; set; }
}

public class AmountToDoubleSerializer : BsonBaseSerializer
{
  public override object Deserialize(
    BsonReader bsonReader,
    Type nominalType,
    Type actualType,
    IBsonSerializationOptions options)
  {
    VerifyTypes(nominalType, actualType, typeof(Double));

    BsonType bsonType = bsonReader.GetCurrentBsonType();
    switch (bsonType)
    {
    case BsonType.String:
      string readString = bsonReader.ReadString();
      double value = Double.Parse(readString.Replace("$", ""), CultureInfo.InvariantCulture);
      return value;
    case BsonType.Double:
      return bsonReader.ReadDouble();
    default:
      string message = string.Format("Cannot deserialize BsonString from BsonType {0}.", bsonType);
      throw new FileFormatException(message);
    }
  }

  public override void Serialize(
    BsonWriter bsonWriter,
    Type nominalType,
    object value,
    IBsonSerializationOptions options)
  {
    if (value == null)
    {
      throw new ArgumentNullException("value");
    }

    bsonWriter.WriteDouble((Double)value);
  }
}

The AmountToDoubleSerializer will be able to convert string type to double but also to read and save properties that are already in double format. This will allow for our system to read past events as well as new ones.

In the next post I will show how can we do other transformation such as adding, removing and renaming a property.

Tuesday, April 29, 2014

How to support changes in your Software

Event Sourcing is a very powerful architectural concept. Pretty much like a bank account statement everything you write on it is considered immutable. There is no way you can change anything in the past. The only option is to add a new entry to fix a previously made error.

imageThe goal of such concept is to never loose any information not even mistakes. In real life we make mistake all the time. In any good entry form the will be a lot of validation in place to limit those mistakes. But even then mistake can happen.

If the only mistake would be data it won’t be too much of a problem. Any bad data entry can be corrected by a compensating entry that does the exact opposite. But what happens when mistakes are structural.

In software development we always have to choose amongst many differents options. Every time we decide between one structure over another we have to live with the consequences of that choice for the rest of the life of our software. The ability to change the structure of our software decrease exponentially as the features are added. For every new feature we multiply the number of ways we can combine it with other existing features.

How can we build a software that will last longer than its competitor? How cae we embrace changes in our software? In a CQRS and Event Sourcing developed software it’s easy. There is only two main parts that are subject to big change: The Read Model and the Domain.

imageChanges in the Read Model are not so bad. Because all Read Models are built by replaying all historical events, it’s easy to flush them and rebuild them from scratch. The real challenge is to maintain domain events integrity across the life time of your application.

As I wrote before, event store is meant to be immutable therefore it shouldn’t change in any way. But what if you realize that you forgot an important information that you need to track in your domain? Worse, what if you need to remove some properties of your event or an event property need to change its type. Of course those changes should not be the norm but, you know, sh*t happens. In a CQRS and Event Sourcing application supported by Domain Driven Design (DDD) it should be possible to allow such changes. The domain itself may evolve over time. Some business rule may be changed or added and they may need more information to be applied.

The domain objects are good for hiding the internal process of business rules but, in order to be able to do their job, they need some external information. Those information will be persisted in the event store so they will be available later to rebuild the entire object state and be ready to accept any new state change.

imageConceptually the domain only need to know the latest structure of each event in the event store. It should be able to apply them as is to its internal state. In fact the event store will contain earlier version of those events. The goal is to threat them as if they are like their latest counterparts. The best way to do this is exactly like how source control system work such as Git or Mercurial. In those SCM each change set is recorded as a delta from the previous state. They records any new or removed lines of code. So to make that work all we need to do is to have a piece of code that manage transition from any version to the next. Then we need to apply those transitions from the last saved version to the latest version.

How can we do that in our events? See my next post to know more about how to do just like that with a Mongo DB event store.

Saturday, April 26, 2014

Imagine a world where the past is all and only truth

Palais_de_la_Decouverte_Tyrannosaurus_rex_p1050042 Your computer system must be full of structured and relational databases. You might take regular backup of them if you don’t want to loose any information. Despite all those precautions you loose all in-between state of your information.
If all you care about is the final state it’s not a big deal but there are good chances that you have to answer some questions like:
  • How much time passed between the first item was put in the shopping cart and the completion of the transaction
  • How many times an item was removed from a shopping cart
  • What was the state the purchase order before the crash
If you didn’t implement some ways to trace those events you won’t have any answer to give. Even if you find a way to do it, you will only get information from the moment you put it in place.
I suggest you a new approach to never have to answer “it’s imposible” to your boss when he asks you that kind of question: CQRS and Event Sourcing. The power of this duo comes manly from Event Sourcing. You remember everything that you learned about side effects and why you should do everything possible to avoid them. Here those effects are the only important things. In that kind of system we do not keep data for say, we keep the effect of an action that we call passed events. For example, if we execute the following command:
var command = new AddItemToCart(cartId, itemId);
command.Execute();
The system will produce the following event:
var @event = new ItemAdded(cartId, itemId);
ApplyEvent(@event);
The strength of the system comes when we delete items. We are able to trace those delete as events too:
var command = new RemoveItemFromCart(cartId, cartItemIndex);
command.Execute();
Will produce:
var @event = new ItemRemoved(cartId, cartItemIndex);
ApplyEvent(@event);
In this system, all event derived from a base event:
public class EventBase
{
 public Guid Id { get; set; }
 public int Sequence { get; set; }
 public DateTime TimeStamp { get; set; }
}
A framework class ensure that every events get its date and sequence properties set.
In such system, only events are valuable. They reflect what really happened in the past. Those event will be used to build specific read models for each surrounding system the are interested. Each one will have its own small database to answer to its needs and any changes to that database will only affect this system.
Those read models are only transient representation of the system’s past.

Wednesday, October 30, 2013

Agile Tour Montreal 2013

Agile tour is comming soon and I will be part of it.

If you attend, dont miss my talk on : Top 5 des meilleures façon d’améliorer votre code. Yes it will be in french, of course.

Tuesday, April 16, 2013

Are you “fluent” in C#?

I’m starting a new codeplex project to build a fluent library for design patterns. For example let’s take those examples.
Here is how to build a chain of responsibility is a standard manner:
var command1 = new Command1();
var command2 = new Command2("Test");
command1.NextInChain = command2;
command1.Execute(null);
Here is the same construct in a fluent manner:
var chain = new ChainBuilder<ChainCommand>()
  .Add<Command1>()
  .Add<Command2>(() => new Command2("Test"))
  .Build();
chain.Execute(null);
Which one do you like the most? In my case I prefer the fluent way. Building a chain of responsibility in not that difficult if you have only a handful of element to chain, but if you have more it become boring to remember to link the previous element to the next. My builder take car of that for you. Because of “fluent” concept you always now what comes next. For exmaple the ChainBuilder class only expose some overload of Add and a Build method.
So if you like this way of thinking, join my codeplex project and give me your feedback about it.
See : http://fluentpatterns.codeplex.com/

Friday, January 13, 2012

Recommandation + embauche = 2000 $

Recommandation + embauche = 2000 $:

Pour répondre à la demande incessante de l’Agilité, Pyxis a l’objectif d’embaucher 22 nouveaux collègues en 2012. Nous avons décidé de prendre la pénurie de main-d’œuvre en TI par les cornes : nous donnerons 2000 $ pour chaque personne recommandée embauchée.

N’hésitez pas! Recommandez-nous un de vos contacts pour un des postes suivants : Scrum Master, coach organisationnel, coach d’équipe ou conseiller technique.

Si la personne recommandée est embauchée, nous vous remettrons 2000 $. C’est aussi simple que ça!

Tuesday, September 13, 2011

Vote for Your Favourite Session to be Included in TechDays 2011

Vote for Your Favourite Session to be Included in TechDays 2011:

techdays_canada_3WOW! That’s all I can say to the response we received to our open call for sessions for TechDays 2011! We had almost 60 individuals submit close to 130 sessions to be delivered at TechDays 2011 in Toronto, Vancouver and Montreal. This made the task of narrowing it down for a short list for your votes challenging to say the least but we were able to make it happen. Now it’s your turn!

Today we have made all of the sessions on the short list available for you to cast your vote and tell us the kind of content you want delivered at TechDays 2011 that would help you grow in your career and help your organization grow their IT infrastructure and applications.

To cast your vote for the sessions you want to see at TechDays 2011, go to http://bit.ly/tdcan2011vote and make your selections. Voting is open until 11:59pm Eastern Time on Friday, September 16th so cast your votes now. Just like in all those reality shows featuring great talent, you need to vote for the sessions and individuals who proposed them if you want to see them at TechDays 2011 so don’t wait – VOTE NOW!!

We will be announcing the sessions selected from the audience vote next week.

DamirB-BlogSignature

Monday, March 28, 2011

How to Databind to ListBox’s SelectedItems property (Silverlight)

 

It’s been a while since the last time I published some useful code sample. I apologize!

Today I found what I qualify as a bug in Silverlight 4.0. Those who know me are aware that I’m working on a big Silverlight project for about a year now. As you also know I’m a big fan of patterns and for Silverlight, the obvious one is MVVM.

Every pattern has its own standard and often its own framework. With MVVM the omnipresent framework feature is Databinding. In XAML, Databinding is really powerful. Of course Silverlight doesn’t have all the power WPF has but almost. I’m already used to deal with the limitation of Silverlight binding and the lack of Markup extension for example. But today I it a wall with something I didn’t expect, data binding to the SelectedItems property of a ListBox.

If you look closely at ListBox’s properties you will find that almost all of them are DependencyProperty except for SelectedItems (don’t miss the “s”). SelectedItem (without an “s”) is a ok but not SelectedItems. Why? I suppose its was forgotten.

How to fix that? I found many complex implementation of solution to solve this issue but I didn’t found one I was satisfied with. When trying to debug this “bug” I realized that if I inspect the content of the SelectedItems property in the debug view then the binding was working. So I came up with a solution around that strange side effect.

First let’s try to reproduce the problem. The first thing you need to do is to create a new Silverlight application. Accept all the default, it doesn’t matter. Next put this code in the MainPage.xaml

<UserControl x:Class="ListBoxSelecteItemsBug.MainPage"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:fix="clr-namespace:ListBoxSelecteItemsBug"
             mc:Ignorable="d"
             d:DesignHeight="300"
             d:DesignWidth="400">

    <Grid x:Name="LayoutRoot"
          Background="White">
        <StackPanel Orientation="Vertical">
            <ListBox x:Name="myListBox"
                     Height="200"
               SelectionMode="Extended"
                     ItemsSource="{Binding MyItems}" />

            <Button Content="Click me"
                    Command="{Binding DoItCommand}"
                    CommandParameter="{Binding SelectedItems, ElementName=myListBox}" />
      <Button Content="Make it work"
              Click="ButtonBase_OnClick" />
        </StackPanel>
    </Grid>
</UserControl>

Notice the “CommandParameter” binding at line 22 binding to “SelectedItems” on “myListBox”. Then Put the following code in the MainPage.xaml.cs (code behind).

using System;
using System.Collections;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Controls.Primitives;
using System.Windows.Data;
using System.Windows.Input;

namespace ListBoxSelecteItemsBug
{
  public partial class MainPage : UserControl
  {
    private readonly ICommand _doItCommand = new MyCommand();
    private readonly ObservableCollection<string> _myItems = new ObservableCollection<string>();

    public MainPage()
    {
      _myItems.Add("test1");
      _myItems.Add("test2");
      _myItems.Add("test3");
      _myItems.Add("test4");
      _myItems.Add("test5");
      _myItems.Add("test6");
      _myItems.Add("test7");

      InitializeComponent();

      DataContext = this;
    }

    public ICommand DoItCommand
    {
      get { return _doItCommand; }
    }

    public ObservableCollection<string> MyItems
    {
      get { return _myItems; }
    }

    private void ButtonBase_OnClick(object sender, RoutedEventArgs e)
    {
      MessageBox.Show(string.Format("{0} actual selected items", myListBox.SelectedItems.Count));
    }
  }

  public class MyCommand : ICommand
  {
    #region ICommand Members

    public bool CanExecute(object parameter)
    {
      return true;
    }

    public void Execute(object parameter)
    {
      var list = (ICollection<object>) parameter;
      MessageBox.Show(string.Format("{0} items selected", list.Count()));
    }

    public event EventHandler CanExecuteChanged;

    #endregion
  }
}

For simplicity purpose I put everything in the same file but wouldn’t do that normally.

The concept here is simple. If you run this application you will see a ListBox with 7 items in it. You can select one or more of these items and click on “Click me” button. If you do that you should see a popup with “0 items selected” displayed. This proves that the “SelectedItems” is not working. Now if you click on “Make it work” button you should see the actual number of item you have selected previously. Now click again on “Click me” and the number should also be right.

What happened in this sequence of event is simple. The first time you click on “Click me” button you see the initial binding value of number of “SelectedItems” which is 0. The next time you click on it will display the right number because accessing “SelectedItems” outside of data binding seems to refresh its value.

How can we trigger that refresh automatically? With an attached property.

Now add a new file to the Silverlight project call it ListBoxFix and paste it this content:

using System.Windows;

namespace ListBoxSelecteItemsBug
{
  public static class ListBoxFix
  {
    public static bool GetSelectedItemsBinding(System.Windows.Controls.ListBox element)
    {
      return (bool)element.GetValue(SelectedItemsBindingProperty);
    }
      
    public static void SetSelectedItemsBinding(System.Windows.Controls.ListBox element, bool value)
    {
      element.SetValue(SelectedItemsBindingProperty, value);
      if (value)
      {
        element.SelectionChanged += (sender, args) =>
        {
          // Dummy code to refresh SelectedItems value
          var x = element.SelectedItems;
        };
      }
    }

    public static readonly DependencyProperty SelectedItemsBindingProperty =
        DependencyProperty.RegisterAttached("FixSlecetedItemsBinding",
        typeof(bool), typeof(FrameworkElement), new PropertyMetadata(false));
  }
}

The key here is the line 20. The only thing it does is accessing the “SelectedItems”. The last thing to do is to use that AttachedProperty in our ListBox:

            <ListBox x:Name="myListBox"
                     Height="200"
               fix:ListBox.SelectedItemsBinding="True"
               SelectionMode="Extended"
                     ItemsSource="{Binding MyItems}" />

Doing that, triggers the binding to be refreshed and everything should work.

Tuesday, January 25, 2011

Using a ToDo list more effectively

Have you ever had the need to place a TODO in your code? I’m sure we’ve all done so, for some reason or another. Normally it’s just a temporary reminder that we’ll get back to after finishing off something else, in an attempt to avoid breaking the expensive flow we get our minds into when writing code.

Similar to comments however, TODO’s are only valuable if they have meaningful information, and much like comments, we developers, aren’t necessarily to attentive to such things. A TODO can be a bug, a code smell, an optimization or even a feature that would need to be logged. As such, it would be more valuable if things TODO’s were defined correctly, something that doesn’t often happen (specially when considering the whole flow thing…). That translates into expecting TODO’s inline with:

// TODO: this needs cleaning up

// FEATURE: Need to add support for XYZ

but in turn we get:

// this is some stinky piece of code

// ultimately we need to support feature XYZ

// this code smells worse than a dark alley next to a Club on a Sunday morning

The problem with this, apart from the inconsistency that can cause you sleepless nights, is that things can get lost. The TaskList feature in Visual Studio requires these kind of comments to follow a certain pattern, and even when that occurs, the way they are presented leaves a bit to be desired.

image

[Visual Studio Task List]
Enhancing ToDo’s

ReSharper ToDo management adds several benefits over Visual Studio’s built-in. But before we see these, let’s first examine how we can solve the previous problem. To recall, what we want to do is be able to support multiple formats when it comes to defining comments, so // TODO: fix this and // add this to the list of ToDo’s to fix both would appear under the list of ToDo’s.

Fortunately, the way ReSharper allows us to define ToDo items make this very simple. First, in order to access the definitions, we go to ReSharper| Options | ToDo Items

image

Selecting any of the items (for instance the first one) and double-clicking or clicking on Edit, we get the definition dialog box:

SNAGHTMLd8e0cd3

As opposed to the default Visual Studio, with ReSharper we use regular expression. This provides us with the flexibility required. The above example for instance is telling ReSharper to search for any pattern that contains the word TODO in it. By default, normally these patterns are searched for in comments, although we can optionally look in strings and identifiers too. We do not have to worry about defining case-sensitivity in the regular expression. Instead we can just mark the Case sensitive checkbox if we require it. Finally, we can define the color and icon we want displayed when viewing the list of items (which we’ll see later on).

Adding new Items

By default, out of the box, ReSharper comes with four items (Todo, Bug, Note and NotImplemented). We can easily extend this to offer support for other items such as identifying code smells, features, etc. Easiest way is to simply click on an existing item and Duplicate it:

SNAGHTMLdbf5c1b

Searching and Filtering Items

Having the items defined, we can now display a list of them by invoking the Todo Items Explorer from ReSharper | Tools | To-do Items, or pressing Ctrl+Alt+D (VS Scheme)

SNAGHTMLdc547b1

The advantage of course is that it is not required for items to begin with a certain word, as this can be in any position of the string. ReSharper also allows us to filter items so that we can focus on a specific type of task by using the Filter option:

image

which can also be customized using under Tools | Options (accessible too from the To-do Explorer [icon to the left of Filter]). Last but not least, we can also group items by a variety of options, from namespaces to projects, to types, etc.

SNAGHTMLdc90bf9

Now that’s what I call a colorful, albeit long list of tasks

Source: Jetbrain.