What was the problem then and why am I blogging about it now? Well, that’s pretty simple. She decided to download a copy of all her photos from Google Photos, but soon discovered that all the nice EXIF metadata were not there anymore. Pretty inconvenient, isn’t it?

Searching around, turns out that using another tool, Google Takeout, you can download your media files, along with their metadata stored in a separate .json file.

Now, with a couple of photos, this wouldn’t be an issue. But of course that was not my wife’s case, as she had almost 2 decades worth of pictures stored there.

“Wait a second, I can code something for you!”, I said.

Now, if you know me, you know that I am quite lazy. And I wanted to come up with a solution very quickly. So what did I do? Well, that’s simple: I vibecoded everything (almost). And guess what: it was working decently fine, at least enough to make my wife happy (which makes me happy as well, as you may guess). As usual, I’ve put the code in a git repo, in case anyone else has the same problem: https://github.com/mizrael/media-exif.

Now, why am I even writing about this? Good question. Let me go a bit back in time.

I wrote my first line of code around 1988 (gosh, I feel old only typing it). Since then, if something sparked my curiosity, I have always tried to figure out how it worked and if I could write it myself (especially videogames).

All of this just to say that I love coding. I enjoy the act of creation and the thrill I get when I see pixels on the screens doing what I asked the computer to do.

Vibecoding this small tool for my wife almost felt like asking somebody else to do the “dirty job” for me. The result worked, but the process took away the pleasure from me. In a way, it still had some charm though: in my mind I was playing this twisted game of golf where I was trying to get to a working solution in the least amount of prompts.

Does that mean that vibecoding is bad and I won’t be doing it anymore? No. But I am definitely using it very sparingly and consciously, like a surgeon.

Like most software engineers, I am paid to solve problems. The faster I solve them, the quicker I can move to the next one, then the next one and so on. The more problems I solve, more money the company makes, and I get to keep my job (hopefully with some nice bonuses too).

I’ve been in this game long enough, which helps me understand AI-generated code most of the times. This is definitely helping me, but I would never, ever, vibecode stuff and put it on prod.

At work I might be vibecoding a prototype, throwaway code that I would use only to test an idea and then delete. Helps me iterate quickly and get to the point faster.

Vibecoding is a great tool, but it’s not there yet. Most of the times the resulting code is too complex, too convoluted and needs a lot of refinement.

I also still want to have a certain level of control on the code, and if I have an AI produce it and then I have to fix it, it would completely defy the purpose.

There’s also another aspect to it. As I wrote before, I can read code written by others (AI or humans, doesn’t matter), and with enough time, make sense of it. This ability came after years and years of practice.

If you’re starting now to code and all you do is write prompts, then you’re doing it wrong. You’re not learning anything, so just stop and perhaps reconsider your life choices.

Let me say it clearly, and let me say it loudly: AI is not going to replace software engineers.

Let that sink in.

Now, understand this: our job is changing. The way we write code is evolving. What’s happening right now is a true singularity event. Anyone who denies this will be left behind.

If you think about it, the act of creating software can be divided into three main parts:

1. Ideation
2. Execution
3. Assessment

Let’s go through them one by one.

Ideation

This, to me, is the most fundamental—and the most fun—part. It’s where dragons lie. It’s the realm of architects and designers. This is where you (or your customers) come up with an idea and begin shaping its architecture, the underlying algorithms, and all the moving parts.

Execution

Next comes Execution. It’s quite literally a byproduct of the Ideation phase—you can’t execute without a plan. This is where ideas take shape in code. It’s about translating architecture into implementation, turning abstract concepts into working systems.

Assessment

Last, but definitely not least, we have Assessment. This is where you test what you’ve built, check for errors, and make sure you’ve met your definition of done.

Then what? You rinse and repeat.

You’ll notice this pattern—Ideation → Execution → Assessment—repeats at every level, across every stage, with varying degrees of depth.

Now, let’s circle back to the original question: Is AI going to steal our jobs?

Think about it—what do we use coding assistants for right now?

Execution.

We need humans to come up with ideas.
We need humans to define the architecture.
We need humans to write the specs.
We need humans to check the output and ensure the application works as intended.

Now, replace humans with software engineers in most of those steps—if not all, depending on what you’re building.

Am I 100% sure of everything I just said? No. I believe the full shift isn’t happening now, and it will take several years before we reach that point. But even then, we’ll simply have a new definition of what it means to be a software engineer.

Imagine you had a time machine and traveled back to, say, 1979. You bring your laptop and show Visual Studio to a programmer from that era. I bet some of them would quit their jobs and open a bakery. They’d look at tools like IntelliSense, JIT, and Garbage Collection and think, “Well, I’m obsolete.”

Now ask yourself:
Aren’t you taking those tools for granted today?
Do you still feel like quitting your job?

I am currently using it to deploy Riverdam, and I will be using it for all my other Azure projects from now on, for sure.

One of the things that took me a bit to figure out was how to select the SKU for a SQL Server instance. It is not super straightforward (at least not as of today), so I figured it was a good idea to write this post in case anyone else is looking for a solution.

Enough talking, let’s get to the code:

var db = builder.AddAzureSqlServer("sql")
        .ConfigureInfrastructure(infra =>
        {
          var resources = infra.GetProvisionableResources();

          var dbRes = resources.OfType<SqlDatabase>().Single();
          dbRes.Sku = new SqlSku()
          {
              Tier = "Basic",
              Name = "Basic",
          };
        }).AddDatabase("MyDatabase");

Luckily it’s not a lot of code, so I guess there’s no real need for an explanation. Enjoy!

A long time ago, I wrote about the general idea behind Feature Gating and how it helps lessen the pain of releasing software.

This time, however, I want to make a small announcement: I have been working on another pet project for a while, and I have finally reached the first milestone.

Enter Riverdam !

I love simplicity and no-fuss applications. This is why I decided to create my own feature gating API and release it online.

Riverdam is essentially Feature Gating-As-A-Service (FGAAS? Maybe, who knows). It features a user-friendly dashboard that allows you to configure your projects and their flags for each environment, along with a super simple API to query the status.

I also added a system that lets you define custom rules for each feature and have them evaluated on the fly. For example, you can ask, “Is feature XXX enabled on DEV for the logged user?”

I am well aware that there are many commercial and non-commercial tools that offer similar functionality. However, I wanted to create something from scratch and release it publicly.

The best part? It’s totally free! Well, with some limitations for now, but it should be enough to give you a sense of what the platform does.

Give it a try and let me know what you think!

I have noticed however that many developers don’t use the most efficient method for checking if an item exists and retrieving it.

Most of the times, you’ll see something like this:

if (myDictionary.ContainsKey(key))
{
    var value = myDictionary[key];
    // do something with value
}

…which is fine and does its job. But if this code is in performance-sensitive paths, there’s a better and more concise way:

if (myDictionary.TryGetValue(key, out var value)) 
{
  // do something with value
}

“No big deal”, you might say. Well, this benchmark says otherwise:

The calls to TryGetValue are almost 2x faster! But why is that?

The reason is pretty simple actually: calling ContainsKey and then accessing the value by key is performing the lookup twice.

As you can see, I have also included a comparison between .NET 8 and 9. The difference is not abyssal, but we can still see an improvement.

As usual, the code for the benchmark is available on GitHub.

Enjoy!

This article contains a snippet from my booklet: Building Resilient Systems Made Easy

Let’s start by taking a look at the formal definition of the word “Resiliency”. The Merriam-Webster dictionary formalizes it like this:

1: the capability of a strained body to recover its size and shape after deformation caused especially by compressive stress

2: an ability to recover from or adjust easily to misfortune or change

“Resiliency” and “resilience” are synonyms and often used interchangeably, with the latter being more common and preferred in academic environments. Both describe the same concept: the capacity to recover quickly from difficulties or adapt to change.

When it comes to building software, resilience is the ability of a system to endure disruptions, recover from issues, and continuously evolve to maintain stability despite changes in its environment. A resilient system is dependable and predictable, capable of recovering effectively after setbacks.

Resilience is universally valued. Whether applied to individuals, machinery, or digital systems, the necessity for resilience is unquestionable.

From a technological standpoint, resilience involves ensuring our programs do not crash. Systems should handle errors gracefully, avoiding catastrophic failures that might bewilder users or, in severe cases, endanger them. Hardware resilience is equally crucial; consider whether a single machine outage is tolerable or if investment in redundant power supplies and networking is necessary to mitigate failure risks.

The advent of cloud computing has altered the landscape. Managing individual machines may no longer be under direct control. Instead, the focus shifts to selecting appropriate cloud services that fulfill specific requirements.

Why does it matter?

In 2019, British Airways suffered a major failure of their IT systems due to a significant defect in one of their applications. The bug caused more than 100 flights to be dropped and caused a huge disruption of services in the Heathrow and Gatwick airports.

In 2023, a Google data center in Paris had an incident described as “a multi-cluster failure which led to an emergency shutdown of multiple zones.” Apparently the issue was caused by a water leakage in a cooling system that brought to a fire incident in one of the rooms.

Even big companies can and will have incidents like these. What matters though is their ability to quickly investigate and recover from them.

Bottom line? Don’t stress too much. Plan for resiliency, do your best, and be prepared for Murphy’s law.

Don’t miss the rest of the chapter! Building Resilient Systems Made Easy is available now!

Today we’re continuing on that path and see how we can make use of these building blocks to create a simple Home Assistant.

The application flow is quite simple:

• an Azure Function that exposes some operations on our “smart” devices, like list, get details by id and change status
• a console app with Semantic Kernel
• our LLM deployed on Azure OpenAI

Let’s take a look at the Azure Function first.

I tried to keep things as simple as possible, so for this sample I decided to model all the sensors starting from a common Device class that looks more or less like this:

public abstract record Device
{
    public int Id { get; init; }
    public string Name { get; init; }
}

A light can be turned on and off, so it’s definition can be just:

public record Light : Device
{
    public bool IsOn { get; set; }
}

Similar thing for door sensors:

public record DoorSensor : Device
{
    public bool IsOpen { get; set; }
}

The Function App exposes a bunch of triggers to operate on these models. For example, to update the state of a door sensor, we have to do a POST call to doorsensors/{sensorId:int}/state and pass a boolean value defining the new state.

The trigger will execute this:

[Function(nameof(ChangeDoorSensorState))]
public async Task<IActionResult> ChangeDoorSensorState(
    [HttpTrigger(AuthorizationLevel.Function, "post", Route = "doorsensors/{sensorId:int}/state")] HttpRequestData req, 
    int sensorId)
{
    var newState = await req.ReadFromJsonAsync<bool>().ConfigureAwait(false);

    var sensor = _doorSensorsRepository.GetById(sensorId);
    if (sensor is null)
        return new NotFoundResult();

    sensor.IsOpen = newState;

    return new OkObjectResult(sensor);
}

Let’s have a look at the Console App now. This will be our way to “talk” with the Smart Agent.

The first thing we have to do, after having parsed the appsettings, is to setup the Kernel. We start by configuring the OpenAI Chat Completion service:

var credentials = new DefaultAzureCredential();
var kernelBuilder = Kernel.CreateBuilder();
var config = host.Services.GetRequiredService<IConfiguration>();
kernelBuilder.AddAzureOpenAIChatCompletion(
    config["OpenAiModelId"]!,
    endpoint: config["OpenAiEndpoint"]!,
    credentials);

Now we have to configure the Plugins (more on these in a minute):

var lightsPlugin = host.Services.GetRequiredService<LightsPlugin>();
kernelBuilder.Plugins.AddFromObject(lightsPlugin);
var doorSensorsPlugin = host.Services.GetRequiredService<DoorSensorsPlugin>();
kernelBuilder.Plugins.AddFromObject(doorSensorsPlugin);

And finally we can build the Kernel object:

var kernel = kernelBuilder.Build();

As we saw in Part 1, Plugins are normal classes that expose the extra functionalities we want to add. Each method has to be decorated with some attributes that describe in plain english their purpose as clearly as possible. This is necessary to help the LLM understand what the functionality does and decide if call it or not.

Our LightsPlugin is nothing more than a wrapper over an HttpClient that would call the triggers exposed by our Function App.

For example, to retrieve the list of all the lights:

public class LightsPlugin
{
  private readonly HttpClient _httpClient;
  private readonly ILogger<LightsPlugin> _logger;

  public LightsPlugin(HttpClient httpClient, ILogger<LightsPlugin> logger)
  {
      _httpClient = httpClient;
      _logger = logger;
  }

  [KernelFunction("get_lights")]
  [Description("Gets a list of lights and their current state")]
  [return: Description("A collection of lights")]
  public async Task<IEnumerable<Light>> GetLightsAsync()
  {
      _logger.LogInformation("Getting all the lights...");

      var response = await _httpClient.GetAsync("api/lights");
      response.EnsureSuccessStatusCode();
      var lights = await response.Content.ReadFromJsonAsync<IEnumerable<Light>>()
                                          .ConfigureAwait(false);
      return lights ?? Array.Empty<Light>();
  }
}

Now let’s see how we can combine everything and start using the Smart Assistant:

var chatCompletionService = kernel.GetRequiredService<IChatCompletionService>();
OpenAIPromptExecutionSettings openAIPromptExecutionSettings = new()
{
    ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions
};

var history = new ChatHistory();

while (true)
{
    var question = Console.ReadLine()!.Trim();
   
    history.AddUserMessage(question);

    var result = await chatCompletionService.GetChatMessageContentAsync(
       history,
       executionSettings: openAIPromptExecutionSettings,
       kernel: kernel);

    history.Add(result);
    Console.WriteLine(result);
}

I’ve stripped out a lot of code just to focus on the core. We start by retrieving the Chat Completion service from the kernel and then we initialize a chat history, which will be used to keep track of the requests we make to the Agent.

At this point we can start reading our input from the terminal (voice control TBD! :D ), appending it to the history and calling the chat service.

The magic trick lies in the openAIPromptExecutionSettings object: it tells the LLM to automatically invoke functions from Plugins in case they match our query.

If we now run our app, we should be able to ask our Smart Assistant to interact with the devices we have available:

All the code is available on GitHub, have fun!

Luckily, I recently moved to a new house and started messing with home automation. I am probably never going to build everything on my own, but in any case, this triggered me to start playing with AI.

I have been playing a bit with Semantic Kernel lately and it’s increbile how easy it is to integrate it with an AI model and create something from scratch.

So, for my project I wanted to have some kind of chat application where I can ask the status of my home devices and possibly interact with them.

To keep things simple, I started with just lights and door sensors. The operations would basically be:

• listing all devices (perhaps specifying the type)
• get details about a specific device
• turn on/off a light
• open/close a door

The point now is: how can I have the LLM interact with those devices? The answer is: Semantic Kernel!

The first step is to setup a Chat Completion service with a model hosted on Azure. This way I can have simple conversations in plain english, but there’s no actual interaction. Now I need to make the agent understand prompts like “how many lights do I have?” or “turn the bathroom light off”.

For this, I can leverage the concept of Function Calling that some models expose.

Functions are basically custom code we can write and expose to the model so that it can execute more advanced functionalities.

In simple terms:

• the user asks something
• the model parses the prompt and decides whether to use one or more of the registered functions
• the model tells the client application to run the functions (and can even pass parameters!)
• the model grabs the results and aggregates it with the LLM results to build the message that will be presented to the user

Semantic Kernel makes everything easy by allowing us to create Plugins, which encapsulate the Functions:

public class MyFancyPlugin
{
  [KernelFunction("get_current_time")]
  [Description("Gets the current time")]
  [return: Description("the current time in UTC")]
  public DateTimeOffset GetCurrentTime()
  {
    return DateTimeOffset.UtcNow;
  }
}

As you can see, a Plugin is a simple class that exposes our custom methods. Each method has to be decorated with the KernelFunction attribute and at least one Description, which provides some context to the model.

Now all we have to do is to register it during startup:

var kernelBuilder = Kernel.CreateBuilder();
kernelBuilder.Plugins.AddFromType<MyFancyPlugin>();
var kernel = kernelBuilder.Build();

This way we can ask the model something like “can you tell me what time it is?”.

There is already a nice list of Plugins available and the team is actively adding more and more.

That’s all for today! The next time we’ll jump into the code and see how to plug all the pieces together and build our smart assistant.

But in case you’re too curious, all the sources are already available on GitHub. Ciao!

However, they lack one critical thing: Topics.

What’s a Topic, you’d ask. Well, let me take a step back then.

Without going too much into the rabbit hole, when it comes to messages on a queue, we have two major categories: commands and events.

A command is a fire-and-forget operation, meant to be handled by a single consumer. Of course you can have multiple instances of this consumer application, all listening on the same queue. But they would all be competing for a message. In this case, first come, first served.

A Command it’s basically a request to get something done.

Another important property is that a Command should contain all the information necessary to the consumer for handling it.

On the other end, an event represents the encoded information about something that has happened on our system. We’re basically broadcasting the fact that (for example) a new user account has been created and we want the rest of the world to know about it.

The usual naming convention is with the past tense: UserCreated, OrderPlaced and so on. Events are meant to be picked up by multiple consumers, each one possibly belonging to a different group.

Groups represent the logical context that would handle that specific event. For example, suppose we’ve published an OrderPlaced event. We can have a User Notification service picking it up, that would send an email to the customer. A Warehouse Notification service that would instead send an email to the warehouse manager. A Reporting service would record the information and use it to update the reports.

Each service might have multiple instances to improve resiliency, and each instance would belong to the same consumer group.

Unlike Commands, Events instead carry only the bare minimum information necessary. For example, in an OrderPlaced, we would probably find only the OrderId, and perhaps the CustomerId. Each interested service would then pull the data they need, based on their requirements.

Now, why the long introduction? In Azure ServiceBus, we can create a Topic and link it to multiple Subscriptions, each one representing a consumer group.

Subscriptions are basically queues, all receiving the same message.

As I mentioned before, Azure Storage Queue don’t support Topics, which are the way we can easily broadcast an event to multiple subscriptions. I had some time on my hands during my summer break and I decided to fill the gap. I spent some time researching and wrote a veeeery simple Custom Binding for Azure Functions, that I called Azure Storage Topics.

Usage is pretty straightforward: just add the Nuget package to your Azure Functions project, then add the Output binding:

[FunctionName(nameof(SendToTopic))]
public static async Task<IActionResult> SendToTopic(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
    [StorageTopic("MyTopic")] IAsyncCollector<string> outputTopic)
{
    await outputTopic.AddAsync("hello world");

    return new OkObjectResult("wow");
}

Subscriptions can be configured directly in the host.json file:

{
  "extensions": {
    "storageTopics": {
      "topics": {
        "MyTopic": {
          "subscriptions": [
            {
              "name": "Subscription1"
            },
            {
              "name": "Subscription2"
            }
          ]
        }
      }
    }
  }
}

Under the hood, the library is using the configuration from the host.json file to create one queue per subscription, using this naming convention: topic-subscription, lowercase.

When we’re calling the .AddAsync() method to publish a message, the system would retrieve the topic’s configuration, loop over the relative queues and send the message.

Easy peasy :)

Testing 100% of the codebase is in most cases impossible, and, to be honest, probably not that useful that much. I mean, testing values of properties on DTOs after setting tham doesn’t provide much value. Things are different when those properties are calculated based on a formula. When there’s some logic behind, then it’s a good time to write a test.

But how do we keep track of how good our coverage is? Lukily for us, in .NET we have a quite nifty tool called Coverlet. Basic usage is pretty straightforward: the first thing to do is to add the necessary references to your test projects:

<ItemGroup>

    <PackageReference Include="coverlet.msbuild" Version="6.0.2">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>   

    <PackageReference Include="coverlet.collector" Version="6.0.0">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>

Once you have that in place, all you need to do is to run the tests and ask for coverage generation:

dotnet test /p:CollectCoverage=true

The list of possible parameters is pretty long, and it’s possible to configure literally any aspect of it.

One nice thing though, is that you can generate the coverage during your build pipeline and then run any type of analysis you want on that.

For example, if you’re using GitHub Actions, you can do something like this:

name: .NET

on:
  push:
  
jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Setup .NET
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: 8.0.x
    - name: Restore dependencies
      run: |
        dotnet restore
    - name: Build
      run: |
        dotnet build --no-restore
    - name: Test
      run: |
        dotnet test --no-build -m:1 \
          /p:CollectCoverage=true \
          /p:CoverletOutput=../TestResults/ \
          /p:MergeWith="../TestResults/coverage.json" 

We start with the usual process: we checkout the repo, setup .NET on the agent, restore the dependencies and build the solution.

At this point we can run dotnet test and skip the build, but we also instruct it to generate the coverage.

The interesting point here is that if you’re doing this on an entire Solution, by specifying the MergeWith argument, all the results from each individual project are merged into one file and then saved into the TestResults folder.

We also pass -m:1, which will ensure that the tests projects are processed sequentially. This would avoid any type of contamination that might occurr with parallel executions.

Now, let’s say that you want to add a nice badge on your readme file, showing the coverage results. We have to update a bit the Test step and add an additional one:

- name: Test
  run: |
    dotnet test --no-build -m:1 \
      /p:CollectCoverage=true \
      /p:CoverletOutput=../TestResults/ \
      /p:MergeWith="../TestResults/coverage.json" \
      /p:CoverletOutputFormat=\"opencover,json\"

- name: Create Test Coverage Badge
  uses: simon-k/dotnet-code-coverage-badge@v1.0.0
  id: create_coverage_badge
  with:
    label: Unit Test Coverage
    color: brightgreen
    path: ./tests/TestResults/coverage.opencover.xml
    gist-filename: [the file name from the gist]
    gist-id: [the gist id]
    gist-auth-token: $

We’re specifying the output format and instructing the CLI to generate both json and opencover. We need json for the intermediate results, so that MergeWith would keep working. opencover instead will be used by dotnet-code-coverage-badge.

Now, there’s a couple of things to do:

1. we need to create a new gist, with just one empty .json file in it, and copy the id
2. we need to create a new Fine-Grained token with read and write access to gists. You can do it from https://github.com/settings/tokens.
3. register the token as secret in your repository and update the workflow code.

Bonus point

Some of you might have noticed that the coverage has been generated also for the actual test projects. But that’s not exactly what we want. So how do we exclude them?

The solution is pretty simple: add a .runsettings file and pass it to dotnet test:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <!-- Configurations that affect the Test Framework -->
  <RunConfiguration>
    <MaxCpuCount>1</MaxCpuCount>
    <!-- Path relative to directory that contains .runsettings file-->
    <ResultsDirectory>.\TestResults</ResultsDirectory>
    
    <!-- true or false -->
    <!-- Value that specifies the exit code when no tests are discovered -->
    <TreatNoTestsAsError>true</TreatNoTestsAsError>
  </RunConfiguration>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
        <Configuration>
          <CodeCoverage>
            <ModulePaths>
                <Include>
                    <ModulePath>[your assembly name].*.dll</ModulePath>
                </Include>
                <Exclude>
                    <ModulePath>.*Tests.dll</ModulePath>
                </Exclude>
            </ModulePaths>
          </CodeCoverage>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

The core lies in that ModulePaths node: we can specify which projects we want to include in the coverage generation, and which ones we really don’t want. Now all we have to do is update our workflow and pass this settings file using -s:

- name: Test
      run: |
        cd ./src
        dotnet test --no-build -m:1 -s ../tests/tests.runsettings \
          /p:CollectCoverage=true \
          /p:CoverletOutput=../TestResults/ \
          /p:MergeWith="../TestResults/coverage.json" \
          /p:CoverletOutputFormat=\"opencover,json\"

If you want to see all of this in action, I’m using this method on my small DB engine, Evenire.

Enjoy!