large_http://localhost:3000/uploads/TelegramTrackingInconsistencies.jpg

medium_http://localhost:3000/uploads/TelegramTrackingInconsistencies.jpg

small_http://localhost:3000/uploads/TelegramTrackingInconsistencies.jpg

thumbnail_http://localhost:3000/uploads/TelegramTrackingInconsistencies.jpg

http://localhost:3000/uploads/TelegramTrackingInconsistencies.jpg

large_Slide26.PNG

medium_Slide26.PNG

small_Slide26.PNG

thumbnail_Slide26.PNG

Slide26.PNG

At this point in time we are not yet convinced that software has a conscious and coherent experience of the passing of time. While a given system is still subjected by the passing of time, it may conceptually intertwine concepts of the past, the present and the future.

While on certain abstraction levels it may be fine to disregard the coherence between temporal relationships of behaviour, maintenance thereof would prove to be challenging for humans. Unlike systems, the perception of time by humans is influenced by the characteristics of the past, and the future, bound by an intangible moment known and experienced as the present. The past is defined by its immutability, whereas the future is (partially) unknowable. It is only the present in which the past can be defined, and the future can be influenced. As abstractions in logical systems can be freely defined (again; unlike humans), these systems have more freedom in the conceptual interpretation of time than humans do.

To make a system more maintainable, I would argue, we should model the temporal characteristics to mimic the way humans perceive the passing of time. We may characterize this human experience based by two aspects. First there is a coherent experience of time which binds the past and the future through the present. A second and dependent aspect is the existence of continuity, whereas current events are impacted by the past, but will also influence future events. There must be a logical succession of events explaining the present.

Approaching software design and taking the human perception of time into account we will end up with a number of recommendations which should make it easier for humans to reason about the behaviour of said software. By modelling software products in a manner compatible with our own perception we'll remove some of the cognitive burdens that naturally come with alternate mental models. I would argue the passing of time is such a fundamental aspect to the human experience that it is not only difficult to come up with an alternative approach, but if one exists it might be outright impossible to reason through its functioning in a productive manner. For this reason I believe software systems should attempt to incorporate this perspective into their functioning.

## The solution of event-sourcing
Perhaps I'm kicking in an open door by referring to the technical pattern of event-sourcing in the context of temporal relationships. Depending on the exact implementation, event sourcing already attempts to model the temporal relationship between the present state and past operations. Ultimately the current state can be considered the sum of all past operations.

An amazing capability event-sourcing provides is the ability to re-assess historic events to alter the current state. In doing so we are not altering the events themselves - after all the past cannot be changed - but changing the impact of these prior events on the current situation. This is hugely beneficial when evolving an existing system. Without event-sourcing one could only assess the current state of the system, without the rich historical context that led us to the present moment. It will prove to be the difference between a reactive and pro-active development approach.

This is analogous to the way humans process the past, and are able to re-assess it. Experiences themselves cannot be invalidated, whether good or bad, but the bias they caused in the present interpretation of reality can be re-assessed. Without this ability one would eventually develop coping mechanisms ineffective for dealing with the present. Some of which might prove to be outright destructive. Regular re-assessments are required to maintain ones mental well-being over time.

Just like humans suffer when they cannot depend on their experiences, a system unable to evaluate past decisions is bound to collapse under their own weight far more quickly than a system that would.

When building a system that is supposed to last for decades (perhaps centuries?) event-sourcing is a necessity, for otherwise the system will devolve into chaos, and its developers will become depressed.

## The past as immutable fact
Just like humans cannot change the past, I wouldn't recommend software systems to alter the past either. The sole window in which we may alter the future is the present, and the opportunities we have in this moment are defined by the context and decisions made in the past.

Ignoring this coherence in the flow of time would break the continuity aspect we started with. In the hypothetical situation we were to break it we could choose to deal with this in a number of different ways. The first one is to propagate the change and alter later events. The danger of this approach is that we might end up with a time-travellers paradox, where changes are reversed as they become incompatible with the altered timeline. This is not even considering whether such changes must adhere to current or historically held invariants, which itself is a rather difficult question. Altogether it would generally be an undesirable property of a software system to destroy information based on a change introduced in the timeline. An alternative approach is to allow changes of the timeline without re-evaluating subsequent changes. Though the implications of this approach are less severe than the time-travel paradox, we are now unable to protect our invariants. Allowing ourselves to break invariants would increase the rate at which the system deteriorates since one can no longer be sure about the exact contents of data contained within. 

## Dealing with the past in the present
That is not to say it is easy to reason about the contents of the data contained within the system. In fact, it might be the most difficult aspect of keeping a given system up and running. Invariants are bound to change over time, which result in certain ambiguity about the data contained therein.

There is yet another analogy to human nature to be found there. Generally humans seem to be able to exclusively judge based on their current understanding and context, which is recognizable in the form of shame. (Thankfully the existence of shame is a tangible result of personal growth.) It makes it all the more ironic that historic actions are often attempted to be framed in their historic contexts, more often than not solely leading to apologetic behaviour. This itself is completely useless as not only can the past not be altered, but it is also the current context that we need to deal with, regardless of any past decisions.

As such keeping historic invariants around is fairly useless, since the sole thing we are to deal with is the present. If one ever needs to consider these for archaeological reasons it can generally be considered to exist within the version control system. Generally there is no reason to deal with these, except when it is required to re-assess the impact historic events ought to have on the present.

Ultimately we do not deal with past behaviour, but a description (or consequence) of it instead. A strict separation ought to exist between our reasons for behaving and the impact of said behaviour on the present. It is our interpretation of the significance of past events which might change, but we cannot change the decision making that happened beforehand.

## Evolution
These considerations leaves us with a rather strict way through which we are able to evolve an event-sourced system to adapt to new requirements. Generally the invariants can be changed all the time, as they only impact the present decision making process. This is much different for events. Given events reflect the result of historic operations the information contained within should be preserved. What we may change however is the way events are interpreted in the present. Generally we may be able to do so through altering the way events are replayed and applied.

From a practical point of view it is therefore important that a single event has the smallest possible footprint. This allows us to compose multiple events to make up more complex operations. It's not so much the events which hold the invariants we're trying to protect, but these complex operations. It's the events merely representing a result of the evaluation of these invariants, and as such they are merely descriptive.

This allows us to freely alter any invariants to support the present use-case, while also allowing to discard events in-place when they are no longer necessary. Leaving them around signifies the historic significance of them, and still allows one to re-interpret their impact on the current system as needed. This approach of dealing with events provides a technical solution to deal with the difference between the past and the present, based on which we might influence the future. All while maintaining our ability to reason about the current and future states of the system.

To make a system more maintainable its temporal characteristics should mimic the way humans perceive the passing of time. Coherence should bind the past and the future through the present, whereas continuity should explain the present by the past.

The importance of time and coherence in event sourced systems

At DDD Europe 2022 I had been invited to deliver the session named "How complex software impacts your cognitive abilities".

You can [**find the slides here**](https://cms.corstianboerman.com/uploads/How_complex_software_impacts_your_cognitive_abilities_680d47d279.pdf).  
[A proof of concept of the techniques presented during this session can be found in this GitHub repository.](https://github.com/corstian/domain-components)  
For any remaining feedback, thoughts or questions, [ping me on Twitter; @CorstianBoerman](https://twitter.com/CorstianBoerman).




How complex software impacts your cognitive abilities

Suicide as a result of depression is a topic I have subtly written more about in the past. This time I specifically want to cover the question whether the act of committing suicide can be deemed good or bad. Have people a right to commit suicide, and how far may relatives go to prevent one from committing suicide? Lately I have been discussing the morality of suicide with a few different people which yielded an interesting viewpoint I want to write some more about.


I have grown up in a family where things could either be good, or things could be bad. Since then I figured out things are not black, nor white, but the whole world consists of many shades of gray. Usually there is no good or bad, but an "it depends", based on the circumstance. Of course there are a few moral values everyone tends to agree upon such as "thou shall not kill", but alongside those strong moral values is an ever bigger gray area where it is impossible to determine whether something is good or bad.

Suicide has become my go-to topic to explain absolute minded people why there are many shades of gray. In part as I have gained insight into the underlying mechanisms which cause someone to commit suicide, as well because it's a topic about which many people think in an absolutist way; "do not commit suicide" and therefore "suicide is bad". This is also the point of view historically fostered by christianity, which may be one reason why that point of view continues to be so incredibly persistent.


## Traditional views on suicide

There are some common arguments against suicide:

1. It's against scripture; "thou shall not kill" also applies to oneself. Besides that, suicide has been regarded as one of the deadly sins which will land you in hell.
2. "But we will miss you when you're gone"

Continuing further in this post I will try to paint an image with which I will erase the legitimacy of both statements at once. But first I'll cover a bit of the background of depression, and suicide alike.

The common conception however is that suicide is bad. In a recent discussion it dawned upon me that it is unreasonable to label suicide as either good or bad. It's simply the wrong terminology. It's easier to discuss whether suicide is justified or not, whether its a solution or whether there are better ways and so on. Doing so will automatically result in a discussion with a lot more nuance than possibly when just talking about 'good' or 'bad'.


## Getting depressed

A depression is not something you'll dive into head first. Contrary, it's something which creeps up slowly but surely, and unless acknowledged, it's there to stay.

> A quick survey such as the ([PHQ-9 (Personal Health Questionnaire, 9 questions)](https://patient.info/doctor/patient-health-questionnaire-phq-9)) may help to quickly give an indication of the severity of a depression.

At first sight the specific reasons for depression seem to differ from person to person. From my experience however it seems as if a common denominator can be found in dysfunctional family dynamics. Whether it is about neglect, abuse or other forms of physical or mental harm. Most of the people with depression I have met and spoke with seem to have experienced some kind of harm which started to influence their day to day lives. As Alice Miller put it; “People are free from depression when their feeling of self worth is derived from the truth of their own feelings, and not on the possession of certain qualities”. The truthfulness of ones feelings is one of the first things to be questioned when in harms way. It's only a natural self preservation mechanism.

When unacknowledged and not properly dealt with a depression will only grow stronger. Getting out of a depression is not a choice between staying in a depression or getting better, but between breaking or dying. When one is incapable of intervening themselves in their depression the only natural endpoint is death.


## Freedom in death?

A few days ago I found this question on Reddit; "Why do we try to stop people who want to end their lives?". I took some time to type out [an comment elaborating my point of view](https://www.reddit.com/r/morbidquestions/comments/hss2up/why_do_we_try_to_stop_people_who_want_to_end/fycqojf?utm_source=share&utm_medium=web2x) without diving into the morality of suicide itself. I will repeat the key takeaways here;

Personally I regard the aim to stop a relative from committing suicide selfish. It's not about the person willing to commit suicide, but about the feeling of said relative as captured in their words; "I do not want you to die". You'd hurt their feelings by committing suicide. Ironically it is this selfish behaviour which may as well be the root cause that there is someone fostering the wish to die.


## Freedom in life?

Imagine you're living a life in which you are not allowed to express yourself, you're being emotionally neglected while at the same time people around you impose certain expectations upon you. You're not free to be, let alone be yourself. You're not living your own life, but rather the lives of the people around you.

The situation sketched above can be considered a generic source of depression which may vary in amount and intensity. The result is just the same; freedom in life is only an illusion.


## Lack of sovereignty

I think it is fair to say that if there is no freedom in life, there will be no freedom in death. On the other hand I believe that if there is freedom to live, one does not need to worry about freedom of death because the whole issue of depression would be averted.

However, because there is no freedom in living your own life, it's not their own life one is getting rid of when committing suicide, but rather the lives of people around them. In this light "but we will miss you" is one of the most egocentric things one can say. It's not the one committing suicide they'll miss, but part of themselves which is being killed off by the one committing suicide.

The saddest part is that they do not even know who really exists beneath the depression and facade required by them. They aren't really interested in it anyway, as long as they have something of themselves in the person battling depression they can admire. It's one of the nasty implications of a form of systematic narcissism found in many dysfunctional families.


## Who's to blame then?

Even though someone commits the act of suicide on themselves, I don't think this act can attributed to themselves. Before someone seriously considers suicide they have been through such an incredible amount of mental torture that it would be fair to conclude they cannot be held accountable to their own actions. Suicide is an act of final desperation. It's the bottom. Once you're there there's not even the tiniest bit of hope left.

Contrary I think that relatives are more to blame for a suicide than the person who committed. After all, if they wouldn't have driven someone into desperation they might as well still be alive. This is probably an unpopular opinion to many, because still the person who committed suicide is the one who decided upon committing suicide. This is a totally unreasonable point of view, if only when accounting for the power imbalance between the single person getting miserably depressed versus a system of people fuelling this depression.


## On a positive note

In order to end this post on a somewhat positive note I want to give some practical advice on how to deal with suicidal people;

1. Don't make it about you
2. Don't really try to explicitly talk them out of committing suicide
3. Just talk about their life
4. Don't be afraid to ask questions
5. Try to genuinely listen to these people

If you're taking some time to sit down with these people and just talk about life you might uncover a tragic and untold story. Feel free to ask directed questions about their life and you may start to understand where their wish to die came from. You might even be the first one ever to genuinely show interest in their lives...

Many ideas surrounding suicide tend to shift the blame towards the person deciding to get rid of their life.

In this post I introduce a paradox surrounding those supporting the suicidal person, also potentially being the cause of these suicidal ideations in the first place.

Who is to blame for suicide?

In the name of prototyping and quick idea validation I have turned to Telegram to validate both the technical, social and emotional sides related to spatiotemporal matching. Telegram is an easy and cheap alternative to building a mobile app for user tracking. Although there is less control over how the data is collected, it is a decent way to test several things out before fully committing to such big project.

In this post I am going to cover the technical aspects of implementing the collection of position information using Telegram. Later on I will write a bit more about the social and emotional aspects that come with fully automatic flight logging over at the Skyhop blog.


## Getting started with Telegram

One of the great things about Telegram is how they offer first class developer support through their API's, something I wish WhatsApp would have offered. There is a whole ecosystem built around, and there are many libraries abstracting the communication bits away and give you the ability to pack a lot of functionality in a relatively short piece of code. [A friend of mine even managed to write a Telegram bot using a single line of code!](https://gist.github.com/jwdb/6e5b4daa360ce0c793dfd48ee765789f)

I have chosen to use the [`Telegram.Bot` package](https://github.com/TelegramBots/Telegram.Bot) to abstract some of the internals away, and therefore it is a dependency for the code I will be presenting in this post.

> In order to figure out how to set up a basic bot I'd recommend you to check out [this article](https://telegrambots.github.io/book/1/quickstart.html).

Telegram has two methods of delivering messages sent to your bot. The first one is webhooks, while the second ones depend on your service making an connection to Telegram. I'll be using the last method because of the better developer experience.

```csharp
class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello World!");

        var botClient = new TelegramBotClient("your-bot-token");

        botClient.OnMessage += async (s, e) =>
        {
            
        };

        botClient.OnUpdate += async (s, e) =>
        {
            
        };

        botClient.StartReceiving();
        
        Console.ReadKey();
    }
}
```

At this point I usually do have to make some important decisions:

1. Is it required that the bot autonomously sends users information? If so, what is going to be the data source?
2. How is this bot going to communicate? Does it need natural language pattern recognition, or are we going to provide navigation options?
3. How are we going to keep track of bot users?

> Don't be fooled by the complexity that comes with a communication structure! This is something which becomes mind boggling complex too quickly. Maybe I will write a library to help tackle this problem in the future. [Let me know if you're interested!](https://twitter.com/corstianboerman)


## Giving the bot something to do
Currently the bot does nothing. Though to Telegram it may look like the messages are received, nothing is done with it. Given we're trying to receive position information, let's see whether we can receive a single data point. The message's event arguments contain a `MessageType` variable which tells us the type of message we're dealing with. We're primarily focussing on messages with the `MessageType.Location` enum value.

To give life to your bot it needs to do something with the messages it receives. Doing so can be as easy as this:

```csharp
botClient.OnMessage += async (s, e) =>
{
    try
    {
        if (e.Message.Location != null)
        {
            await botClient.SendTextMessageAsync(
                chatId: e.Message.Chat,
                text: $"Lat: {e.Message.Location?.Latitude}, Long: {e.Message.Location?.Longitude}");
        }
        else
        {
            await botClient.SendTextMessageAsync(
                chatId: e.Message.Chat,
                text: e.Message?.Text ?? "Unrecognized content");
        }
    }
    catch { }
};
```

### Reacting to a live location
The `OnMessage` event handler will only get you so far. Though it works quite decent when sending a single location, and it will be notified initially when sharing a live location, it will not be triggered on subsequent location updates. To do so we would need to look at updates to the original message:

```csharp
botClient.OnUpdate += async (s, e) =>
{
    try
    {
        if (e.Update.EditedMessage?.Location != null)
        {
            await botClient.SendTextMessageAsync(
                chatId: e.Update.EditedMessage.Chat,
                text: $"Lat: {e.Update.EditedMessage?.Location?.Latitude}, Long: {e.Update.EditedMessage?.Location?.Longitude}");
        }
    }
    catch { }
};
```

> Interestingly enough the `OnUpdate` handler also gets triggered when a new message is sent. The difference with real updates however is that the `EditedMessage` property will be empty, and you can retrieve the message contents from the `OriginalMessage` property. This might be helpful to prevent code duplication.

## The bot
All the bot does is wait for messages containing a location, and parrot the location back to the user. Latitude and longitude are also the only values you can read from the location. If you wish to retrieve information regarding the heading, speed or other properties like these you should derive them from the coordinates themselves.

![](/uploads/Telegram_bot_chat_8688b34dd8.png)


### Testing the tracking accuracy

In order to test the accuracy of the reported positions I hopped on my bike and drove along the Eastern Scheldt for a bit. Most interestingly the reported positions can be incredibly accurate with an error smaller than a few meters, but also off by a big margin, like three kilometers. There's no way I managed to swim 6 kilometers within 20 minutes.

![](/uploads/Telegram_Tracking_Inconsistencies_70242a5af0.jpg)

The sampling rate however is pretty low, with an position report about every minute.


## Recap

All in all it's pretty simple to start collecting position information from a Telegram bot. What would be more difficult however is to derive added value from these position updates. Given the sample rate is relatively low, and the margin of error relatively high, there are some challenges to overcome.

How to collect location data with Telegram and .NET Core?

It seems as if I'm getting more lazy by the day. That's great, because I didn't really feel like manually mapping my data to my data models in order to have Entity Framework update them.

The thing is there are several options for you if you wish to run such operation:

- Merge: This operation combines two data sets into one based on primary keys. The [ZZZ Entity Framework Extensions library](https://entityframework-extensions.net/bulk-merge) has some nice methods to help you do this, although proprietary.
- Upsert: Upsert is a legit term used in some database engines to indicate an operation which either updates or inserts data. I for one had never heard about that one before. The [`FlexLabs.Upsert`](https://github.com/artiomchi/FlexLabs.Upsert) is really nice for some operations, but did not quite fit my needs. More on that later.
- Or you can do the old try to retrieve an entry, if it exists, update is, and if it doesn't, then create a new one. But this didn't really fit my needs either.

As I said before. I'm lazy. Real lazy. Let me explain my situation.

I've been fiddling around quite a lot with GraphQL lately. During this process I figured out that the create and update logic I write on the client-side is quite simillar. This led me to think that, unless a special operation needed to be executed, most create and update logic could be combined in `save`, or in my case `mutate` operation. Depending on whether the primary key would be provided either an update or create operation should be executed.

So all in all I did not feel like writing stuff like this:

```csharp
dbModel.FirstName = viewModel.FirstName;
dbModel.LastName = viewModel.LastName;
// etc...
```

Heck, I even ditched use of the viewmodels, mostly. I wanted to have an operation with which I could just pass on my object, and it would automagically determine which fields needed to be sent to the database.

Something like this is what I came up with. I discourage using this directly in production code. Use it by means of inspiration.

```csharp
public static async Task Mutate<T>(
    this DbSet<T> dbSet,
    T subject,
    Guid? cursor = default) where T : class, IId
{
    var context = dbSet.GetService<ICurrentDbContext>().Context;

    bool entryExists = false;

    if (cursor != default) entryExists = await dbSet.AsNoTracking().AnyAsync(q => q.Id == cursor);

    if (entryExists == false) {
        subject.Id = cursor ?? Guid.NewGuid();
        dbSet.Add(subject);
    }
    else if (entryExists == true)
    {
        subject.Id = cursor.Value;

        var entry = dbSet.Attach(subject);

        entry.State = EntityState.Modified;

        typeof(T)
            .GetProperties()
            .Where(q =>
                q.CanWrite
                && Convert.GetTypeCode(q.GetValue(subject)) != TypeCode.Object
                && q.GetValue(subject) != q.GetType().GetDefault()
                && q.GetValue(subject) != null)
            .Select(q => q.Name)
            .ToList()
            .ForEach(property => entry.Property(property).IsModified = true);
                
        entry.Property(q => q.Id).IsModified = false;
    }
}

public static object GetDefault(this Type type)
{
    return type.IsValueType
        ? Activator.CreateInstance(type)
        : null;
}

public interface IId {
  Guid Id { get; set; }
}
```

It's not as magical as it might look like. Although there are a few things to note:

- There's a check for `CanWrite` as I had a readonly property which was ruining this idea
- The `TypeCode` comparison is to remove any objects, and therefore also lists.
- It is important to compare a value with it's default value. Checking for null only will not work well with most value types.

I know there are certain people which are going to scream out loud about performance. Let me state this: performance was not a priority, nor did I benchmark it. If this ever becomes an issue I will improve it. If it doesn't, well, then that's great.

Happy hacking! And remember, life's too short to keep writing CRUD code.


Entity Framework Core: insert or update, the lazy way

There are problems in the software industry that have been solved a hundred-thousand times, and will be solved a hundred-thousand more. Rather than re-inventing solutions to these common problems we should be engaging in a discussion about meta-development practices instead.

Boring Complexity

Logging statements have no place in the domain. There are multiple better alternatives you should use instead!

How to effectively observe the runtime behaviour of your core domain

This post attempts to explain event sourcing through examples showing what it is and what it is not, while highlighting some of the strengths and reasons for using it.

Curls, clouds and code

Featured posts & categories

Subscribe?