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

Pedro Ribeiro Simões Fernando Pessoa Triple Portrait (2004) - Julio Pomar (1926-2018) | Source: https://www.flickr.com/photos/pedrosimoes7/48214193806

medium_48214193806_1b82ff1356_c.jpg

small_48214193806_1b82ff1356_c.jpg

thumbnail_48214193806_1b82ff1356_c.jpg

48214193806_1b82ff1356_c.jpg

small_domain aggregate.png

thumbnail_domain aggregate.png

domain aggregate.png

small_Group-of-People-01.png

thumbnail_Group-of-People-01.png

Group-of-People-01.png

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.

Collecting position information 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

An improvement upon the previously proposed event sourced aggregate where command provides type information about its returned domain events.

More transparent command to event transformation

In order to allow an event sourced software system to evolve I believe it to be important to issue coarse commands emitting granular events. In this post I explain why.

Coarse commands, emitting granular events

Since it would be beneficial for commands to be able to issue multiple events reflecting its behaviour I modified an earlier approach to event sourced aggregates to allow this use-case.

Mapping one command to multiple events

Implicit vs explicit meetings

The aggregate is a well understood concept within DDD practices. The addition of event sourcing to the mix might however complicate things, and the once pretty domain is now in shambles. In this post I'll cover the addition of ES, while keeping the awesomeness of DDD in place.

Curls, clouds and code

Featured posts & categories

Subscribe?