Ufuk Hacıoğulları

Eertree - an interactive guide

Sat, 20 Dec 2025 21:08:22 +0000

Eertree (or palindrome tree) is a data structure used for searching palindromes in a string. It was invented in 2015 by Mikhail Rubinchik and Arseny M. Shur. The name itself is a palindrome, derived from the word “tree”. The paper is pretty straightforward as far as papers go, but it can be a bit confusing at first.

It’s easier to understand when you see how it’s built step by step. You can use the textbox below to type a string and see how it would be represented in an eertree. You can also read through the description first and come back to try it out afterwards.

How it works

Before we dive into implementation details, let’s take a moment to classify palindromes into three types:

Single characters, pretty straightforward.
A pair of the same character (eg: aa). All even-length palindromes have one in the middle.
A pair of the same character “surrounding” another palindrome (type 1, 2 or 3).

As you can see, you can make a longer palindrome simply by adding the same character to both ends.

... a b c d c d a ...

Each node in an eertree (apart from the special nodes) represents a palindrome. Since we know that every single character is a palindrome by itself, these nodes become the building blocks for larger palindromes.

A character edge, represented in black and pointing downwards, means the character surrounds the source palindrome. If the source palindrome has length n, the target palindrome will have length n + 2. Here’s how it would look for the word “kayak”.

We show the palindrome strings inside the nodes to make things easier to understand, but this isn’t required in an actual implementation. Usually, you’d just keep track of the length of each palindrome.

Suffix edges, represented in blue and pointing upwards, connect a palindrome to the longest palindrome suffix it has. For example “eve” has a suffix edge to “e”, and “eveve” connects to “eve”. Each node has exactly one suffix edge. On the other hand, it can have zero or many character edges.

Special nodes

Character edges help us represent type 3 palindromes, but we need special nodes for type 1 and type 2 palindromes. An eertree has two special nodes for this purpose.

The imaginary root (or odd root) is a node with length -1. It has character edges to palindromes with a single character. The rule mentioned above still holds as the -1+2 would give us length of 1 for the target palindrome. Of course, a palindrome of length −1 can’t actually exist, which is why this node is called the imaginary root. Its suffix edge points to itself.

The empty root (or even root) is a node with length 0. It can only have character edges to palindromes of length 2. Its suffix edge points to the imaginary root.

Constructing an eertree

We build an eertree by adding characters from the string one by one. When we see a character for the first time, it gets added as a palindrome of length 1. We also keep track of the longest palindromic suffix of the string processed so far (shown in red, and referred to as the max suffix).

When adding a new character, we check whether the character immediately before the current max suffix matches the character we’re adding. If it does, we’ve successfully extended the palindrome. We then create a new node with length increased by 2 and add a character edge from the max suffix.

If it doesn’t match, we follow the suffix edge of the max suffix (which leads to a shorter palindrome) and repeat the same check. Eventually, we either find a match or end up at the imaginary root.

You can modify the example below to get a better feel for how this works.

There is a JavaScript implementation referenced on this page. You can find examples in many other languages on Rosetta Code. You can also write your own version depending on the problem you want to solve. For example, if you’re looking for the longest palindrome in a string, you can just return the just discovered (if there was one) palindrome’s length from add function. For other problems, you may need to implement a tree traversal.

PostgreSQL Integration Testing in .NET Core

Wed, 15 Nov 2017 23:01:00 +0000

PostgreSQL is becoming an attractive alternative for .NET Core applications with support from popular ORMs like Entity Framework Core and Dapper. If you are thinking about switching to Postgres, having solid tests will make you more confident with the transition.

In this blog post, I will explain how you can use basic Postgres CLI tools, create and clean up databases for your tests.

Setup

If you have Postgres installed and you are comfortable with Postgres CLI, just skip to the next section.

Installing Postgres is pretty straightforward. Just make sure that you note down your password.

There are many CLI tools for communicating with Postgres. They are in bin folder of Postgres installation, so adding this folder to your path will make things a lot easier. For my installation, it was like below:

c:\Program Files\PostgreSQL\10\bin

We also need to provide credentials to these applications every time we invoke them. Postgres provides a way to store these credentials in a passfile but somehow it didn’t work for me. Fortunately, it’s possible to store the credentials in environment variables as well. You can easily create them from the command line:

SETX PGUSER postgres
SETX PGPASSWORD your-own-password

You will need to restart your console for the changes to take effect. After that, you should be able to connect to Postgres with psql tool.

Here you see that you are connected to postgres database (it’s not the username) and =# means that you are logged in as a superuser. A superuser can override all access restrictions within the database. Being a good developer, we will create a new user with less privileges for our tests.

Creating test user

Postgress comes with another CLI called createuser. You can invoke it directly from the command line:

createuser -d -P integration_test_user

If you are still running psql, you can execute console commands by prefixing it with \!

\! createuser -d -P integration_test_user

You will get a password prompt for the user, make sure it’s saved as well and we are done with Postgres for now.

Test project

To run our tests, we will create a new database with its schema and destroy it after the tests are run. xUnit.net offers Collection Fixtures feature that enables us to do that. We will create a collection fixture that creates a Postgres database and drop it when it’s disposed.

Creating and dropping databases can be implemented easily but it’s not something you want to write every time. Also there are some trivial stuff that you have to get right. For example: there is a background connection to the database that prevents you from dropping it, you have to kill it before you can drop the database. To hide details like this, I created DoomedDatabases.Postgres library. Create a new .NET Core xUnit project and reference this package.

Install-Package DoomedDatabases.Postgres

We’ll start really simple to make sure we can create and drop a database. Don’t worry about the connection string in the code for now, we’ll move it to a setting file.

using System;
using DoomedDatabases.Postgres;
using Xunit;

public class DatabaseFixture : IDisposable
{
    private readonly ITestDatabase testDatabase;

    public DatabaseFixture()
    {
        var connectionString = "User ID=integration_test_user;Password=yourpassword;Server=localhost;Database=postgres;";
        testDatabase = new TestDatabaseBuilder().WithConnectionString(connectionString).Build();
        testDatabase.Create();
    }

    public void Dispose()
    {
        testDatabase.Drop();
    }
}

[CollectionDefinition("Database")]
public class DatabaseCollectionFixture : ICollectionFixture<DatabaseFixture>
{
}

We will attach this fixture to a test class with a CollectionAttribute. xUnit will make sure the fixture is created before any test is run and dispose it afterwards.

using Xunit;

[Collection("Database")]
public class CreateDatabaseTests
{
    [Fact]
    public void CreateAndDropDatabase()
    {
        Assert.True(true);
    }
}

This test just makes sure that we can run the fixture code without any exceptions. If everything is ok, the test should pass. You should be able to see the database getting created and dropped while debugging.

Moving the connection string to a setting file

Test projects are not created with setting files so we have to create one manually. Create an appsettings.json file in the test project folder that includes your connection string:

{
  "ConnectionStrings": {
    "DefaultConnection": "User ID=integration_test_user;Password=yourpassword;Server=localhost;Database=postgres;"
  }
}

We also have to make sure that the file is copied to output directory. Add this line inside an <ItemGroup> tag in your test project csproj file.

<Content Include="appsettings.json" CopyToOutputDirectory="PreserveNewest" />

We need Microsoft.Extensions.Configuration.Json package to read settings from the file.

Install-Package Microsoft.Extensions.Configuration.Json

Now we can wire it up:

var configuration = new ConfigurationBuilder().AddJsonFile("appsettings.json").Build();
testDatabase = new TestDatabaseBuilder().WithConfiguration(configuration).Build();

If you want to use a different connection string name, you can use WithConnectionStringName method.

Creating the schema with scripts

Creating a database won’t be very useful without the schema and proper data in place. If you are following the evolutionary database design, it’s very easy to create it from scratch. You can easily run the scripts in a folder on the test database.

public DatabaseFixture()
{
    var configuration = new ConfigurationBuilder().AddJsonFile("appsettings.json").Build();
    testDatabase = new TestDatabaseBuilder().WithConfiguration(configuration).Build();
    testDatabase.Create();
    testDatabase.RunScripts("./DatabaseScripts");
}

RunScripts method will run all the files in lexicographical order.

If you have script files in another project already, you can link them in your test project like this:

<Content Include="..\OtherProject\DatabaseScripts\*.sql"
         Link="DatabaseScripts\%(Filename)%(Extension)"
         CopyToOutputDirectory="PreserveNewest" />

Creating the schema with Entity Framewok Core

Entity Framework Core can also be used to create the schema. We will be using Postgres provider for Entity Framework Core. Andrew Lock has a great post for using the Postgres naming convention (snake_case) in EF Core, I moved it to a gist for the sake of brevity, you can plug it in easily if you wish. We’ll create a really simple DbContext.

public class User
{
    public int Id { get; set; }
    public string Username { get; set; }
}

public class TestDbContext : DbContext
{
    public TestDbContext(DbContextOptions options) : base(options)
    {
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);
        //modelBuilder.UsePostgresConventions();
    }

    public DbSet<User> Users { get; set; }
}

Now we can instantiate TestDbContext in DatabaseFixture and let EF create the schema:

public DatabaseFixture()
{
    var configuration = new ConfigurationBuilder().AddJsonFile("appsettings.json").Build();
    TestDatabase = new TestDatabaseBuilder().WithConfiguration(configuration).Build();
    TestDatabase.Create();

    var builder = new DbContextOptionsBuilder<TestDbContext>();
    builder.UseNpgsql(TestDatabase.ConnectionString);
    DbContext = new TestDbContext(builder.Options);
    DbContext.Database.EnsureCreated();
}

public TestDbContext DbContext { get; }

Finally we can implement tests using EF:

[Collection("Database")]
public class UserTests
{
    private TestDbContext testDbContext;

    public UserTests(DatabaseFixture databaseFixture)
    {
        testDbContext = databaseFixture.DbContext;
    }

    [Fact]
    public async Task InsertUsers()
    {
        await testDbContext.Users.AddAsync(new User { Username = "Pramod" });
        await testDbContext.Users.AddAsync(new User { Username = "Martin" });
        await testDbContext.SaveChangesAsync();
        var count = await testDbContext.Users.CountAsync();
        Assert.Equal(2, count);
    }
}

Overwriting the connection string for the ASP.NET Core MVC application

We want to use the test database while we are creating a test server for our ASP.NET Core MVC application. Assuming you have the schema in place already, you need to use the connection string for the database we create:

var webHostBuilder = new WebHostBuilder().UseStartup<Startup>()
                                         .UseSetting("ConnectionStrings:DefaultConnection", testDatabase.ConnectionString);

var server = new TestServer(webHostBuilder);

Adding extensions to the test database

One thing you will be missing in a default Postgres database is GUID ids. It can be easily enabled by adding an extension but only superusers have this privilege. Since we are deliberately not using a superuser, we cannot do it with the test scripts. We can accomplish this with template databases. This also requires a superuser but we have to do it only once.

We create a new database with the superuser from the console:

createdb uuid_extension_enabled

Connect to this database with psql:

psql -d uuid_extension_enabled

Enable the extension:

create extension "uuid-ossp";

Mark the database as a template

update pg_database set datistemplate=true  where datname='uuid_extension_enabled';

Finally close the psql process (there should be no active connections to a database template when we want to use it) and we can use the template now:

testDatabase = new TestDatabaseBuilder().WithConfiguration(configuration).WithTemplateDatabase("uuid_extension_enabled").Build();

Integrating Jenkins with Octopus Deploy

Sun, 20 Apr 2014 14:20:56 +0000

Jenkins can easily produce deployable NuGet packages for Octopus Deploy. You should start by adding OctoPack package to the project you want to deploy.

Install-Package OctoPack

I’m getting MSBuild to generate the assembly versions so I don’t have to manually increment them. OctoPack will use the same version for creating the deployable package(unless you use a nuspec file or specify it with a command line parameter). We will edit AssemblyInfo.cs to make this work.

[assembly: AssemblyVersion("1.0.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]

We commented out AssemblyFileVersionAttribute becase MSBuild can’t generate it for us. This way it will use the same version for the file version too.

Next I’ll create a Jenkins project. Setup your source control and MSBuild plugin. I will use Git plugin for this demo. Source code is on a public repo on GitHub so you can use the same parameters if you want to make a test deploy. It’s an ASP.NET MVC 4 project so make sure that Visual Studio 2012 is installed or the necessary files are copied to the server.

Once you configured the plugins, create the project with the following parameters:

The parameters you may want to copy(don’t forget to clone octopus branch):

https://github.com/uhaciogullari/SimpleMvcSitemap.git
SimpleMvcSitemap.Sample\SimpleMvcSitemap.Sample.csproj
/p:Configuration=Release;RunOctoPack=true

Try to build the project. It should fail with the OctoPack error below, otherwise there’s a configuration error with your plugins or the project.

OctoPack cannot be run because NuGet packages were restored prior to the build running, and the targets file was unavailable when the build started. Please build the project again to include these packages in the build. You may also need to make sure that your build server does not delete packages prior to each build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317568.

Build the project again and it should succeed. You can find the package OctoPack created in project’s obj\octopacked folder. If you can verify that it’s there, go on and install Octopus Deploy. Once it’s up, create an API Key from http://your-octopus-server/app#/users/me. We will use it to publish the packages to the built-in NuGet repository. Change the MSBuild parameters in your Jenkins project to this (replace the API key and the Octopus URL):

/p:Configuration=Release;RunOctoPack=true;OctoPackPublishApiKey=YOURAPIKEY;OctoPackPublishPackageToHttp=http://your-octopus-server/nuget/packages

After a successful build you should see that the built-in NuGet repository has the package. You can check it from http://your-octopus-server/app#/configuration/feeds/feeds-builtin/test.

There’s one last thing we have to fix. When you only change a view in an MVC project, MSBuild won’t generate a new version number thinking that the assembly has not changed at all. Although I have not tested it, it will be probably same for the content files. This wouldn’t be a problem if Octopus Deploy would allow overwriting packages. In fact it silently drops the packages with the same version number. It is planned to be fixed soon but it still won’t allow overwriting. We have to force MSBuild to create a new version number in each build. That can be done with rebuilding the project. Just update the MSBuild parameter like this:

/t:Rebuild /p:Configuration=Release;RunOctoPack=true;OctoPackPublishApiKey=YOURAPIKEY;OctoPackPublishPackageToHttp=http://your-octopus-server/nuget/packages

That’s all, you can go on and deploy the packages.

Strategy Pattern with Dependency Injection

Sun, 05 Jan 2014 21:08:22 +0000

Strategy pattern is one of the most useful design patterns in OOP. It lets you select an algoritm’s implementation at runtime. However most of the examples you will find online won’t make sense if you are using dependency injection. Here’s one of them:

public interface IPaymentMethod
{
    PaymentResult Process(PaymentRequest request);
}

public class CashOnDelivery : IPaymentMethod
{
    public PaymentResult Process(PaymentRequest request)
    {
        Console.WriteLine("Pay with cash on delivery");
        return null;
    }
}

public class CreditCardPayment : IPaymentMethod
{
    public PaymentResult Process(PaymentRequest request)
    {
        Console.WriteLine("Pay with credit card");
        return null;
    }
}

public interface IPaymentService
{
    PaymentResult Pay(string paymentMethodName, PaymentRequest request);
}

public class PaymentService : IPaymentService
{
    public PaymentResult Pay(string paymentMethodName, PaymentRequest request)
    {
        IPaymentMethod paymentMethod = null;

        if (paymentMethodName == "Cash")
        {
            paymentMethod = new CashOnDelivery();
        }
        else if (paymentMethodName == "CreditCard")
        {
            paymentMethod = new CreditCardPayment();
        }
        else
        {
            //default implementation
        }

        return paymentMethod.Process(request);
    }
}

This example has a few problems:

PaymentService class is tightly coupled to the implementations of IPaymentMethod.
We are using new keyword to create instances instead of letting them be resolved by the DI container. It will get worse if we don’t have default constructors for these types. Service Locator is out of the question!
Open/closed principle will be clearly violated once we have to create new payment methods.

We have to find a way to resolve the implementations by DI container. We can start by adding an identifier to the strategy interface to move the selection outside of the client code.

public interface IPaymentMethod
{
    string Name { get; }
    PaymentResult Process(PaymentRequest request);
}

public class CashOnDelivery : IPaymentMethod
{
    public CashOnDelivery()
    {
        Name = "Cash";
    }
    
    public string Name { get; private set; }

    public PaymentResult Process(PaymentRequest request)
    {
        Console.WriteLine("Pay with cash on delivery");
        return null;
    }
}

public class CreditCardPayment : IPaymentMethod
{
    public CreditCardPayment()
    {
        Name = "CreditCard";
    }

    public string Name { get; private set; }

    public PaymentResult Process(PaymentRequest request)
    {
        Console.WriteLine("Pay with credit card");
        return null;
    }
}

We added a simple name property to the strategy interface. It will make our selection code much simpler. You can use a method here if your selection logic is more complex.

Selecting a strategy is really easy now but we can make use of an another abstraction to keep the client code simpler.

public interface IPaymentMethodResolver
{
    IPaymentMethod Resolve(string name);
}

public class PaymentMethodResolver : IPaymentMethodResolver
{
    private readonly IEnumerable<IPaymentMethod> _paymentMethods;

    public PaymentMethodResolver(IEnumerable<IPaymentMethod> paymentMethods)
    {
        _paymentMethods = paymentMethods;
    }

    public IPaymentMethod Resolve(string name)
    {
        IPaymentMethod paymentMethod = _paymentMethods.FirstOrDefault(item => item.Name == name);
        if (paymentMethod == null)
        {
            throw new ArgumentException("Payment method not found", name);
        }
        return paymentMethod;
    }
}

Resolve method is pretty simple and we get the payment method implementations by constructor injection. The only thing left to do is registration. Any decent DI container will let you inject multiple implementations of an interface as a collection. Here’s how you can do it with Castle Windsor.

container.Register(
    Component.For<IPaymentService>().ImplementedBy<PaymentService>(),
    Component.For<IPaymentMethodResolver>().ImplementedBy<PaymentMethodResolver>(),
    Classes.FromThisAssembly().IncludeNonPublicTypes().BasedOn<IPaymentMethod>()
           .WithService.FromInterface()
    );

CollectionResolver collectionResolver = new CollectionResolver(container.Kernel);
container.Kernel.Resolver.AddSubResolver(collectionResolver);

It’s done. Now the PaymentService looks like this:

public class PaymentService : IPaymentService
{
    private readonly IPaymentMethodResolver _paymentMethodResolver;

    public PaymentService(IPaymentMethodResolver paymentMethodResolver)
    {
        _paymentMethodResolver = paymentMethodResolver;
    }

    public PaymentResult Pay(string paymentMethodName, PaymentRequest request)
    {
       IPaymentMethod paymentMethod = _paymentMethodResolver.Resolve(paymentMethodName);
       return paymentMethod.Process(request);
    }
}