Trap with `gmtime` and other time functions

From man gmtime:

The gmtime() function converts the calendar time timep to broken-down time representation, expressed in Coordinated Universal Time (UTC). It may return NULL when the year does not fit into an integer. The return value points to a statically allocated struct which might be overwritten by subsequent calls to any of the date and time functions. The gmtime_r() function does the same, but stores the data in a user-supplied struct.

ESP8266: Always call ‘wifi_wps_enable’ before ‘wifi_set_wps_cb’

For WPS to work on the ESP8266 and using the non-OS SDK, be sure to call wifi_wps_enable() before setting the callback function with wifi_set_wps_cb().

For example:

void wps_start()
{
    wifi_wps_enable(WPS_TYPE_PBC);
    wifi_set_wps_cb(wps_callback);
    wifi_wps_start();
}

In the callback itself, call wifi_wps_disable() before wifi_station_connect().

For example:

void wps_callback(int status)
{
    wifi_wps_disable();
    wifi_station_connect();
}

ESP8266: Flash images at more than 115200 bps

If esptool is limited to 115200 bps when flashing your firmware to an ESP8266, you can try to change this by following these instructions.

  1. Locate esptool.py for your installation. On Debian and Ubuntu, this file is located in /usr/share/esptool.
  2. Edit esptool.py and change the value on the line starting with ESP_ROM_BAUD from 115200 to the maximum of 921600 or your preferred baud rate.

ESP8266: Always call `uart_init` before `gpio_init`

I don’t remember if this is in the documentation, but having spent a few hours to figure things out, I consider this essential information that must be recorded here.

For example:

void ICACHE_FLASH_ATTR user_init(void)
{
    /*
     * Always call uart_init() before gpio_init()
     */
    uart_init(BIT_RATE_115200, BIT_RATE_115200);

    gpio_init();
    PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO2_U, FUNC_GPIO2);
    PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO0_U, FUNC_GPIO0);
    GPIO_DIS_OUTPUT(BUTTON_PIN);

    os_timer_disarm(&os_timer);
    os_timer_setfn(&os_timer, &main_on_timer, (void *)NULL);
    os_timer_arm(&os_timer, 50, 1);
}

Remember, C# does not have an exponent operator

This is a cautionary tale for developers who switch between programming languages often.

Whilst reviewing some logs, I noticed that durations of pauses between API requests were incorrect. They were expected to double on every subsequent attempt, starting from a fixed base interval; for example, 5 seconds, 10 seconds, 20 seconds, 40 seconds, and so on. Instead, they were changing in an odd manner: 15 seconds, 30 seconds, 60 seconds, 0 seconds, and so on.

A colleague and I reviewed the following C# code but did not spot anything wrong.

int tmp = RetryIntervalInMs * (2 ^ retryCounter);

These calculated durations kept puzzling me throughout the day as they were mathematically impossible given the programmed exponential growth.

Later that night, when I did some embedded development in C, I suddenly realised what was wrong.

I had used the ^ operator in C#, intending it to mean ‘raised to the power of’ as in some other language — which I cannot even remember now — whereas it was actually an XOR operator. Even two of us reviewing the code together did not spot that mistake.

The fix was to use the Math.Pow(int, int) method, as follows.

int tmp = RetryIntervalInMs * (int)Math.Pow(2, retryCounter);

Avoiding time drift in virtual machines

If you use a virtual machine, you might have noticed that its system time starts to lag after it has been in the ‘powered on’ state for some time. To address this, it is useful to run an NTP (Network Time Prococol) client within the VM to have its time synchronised regularly.

On Windows, this is enabled by default and uses time.windows.com.

On a Debian-based Linux distribution, you can install NTP with apt install ntp and start it with sudo systemctl start ntp.

Caveat with AddInitialRequestCultureProvider() in ASP.NET Core

AddInitialRequestCultureProvider() in ASP.NET Core localisation seems to have an undefined behaviour when it is used in both services and application builder configurations to add a custom RequestCultureProvider.

If you want to use a custom RequestCultureProvider to customise how the applicable culture is determined for an incoming HTTP request (for example, by looking up the chosen culture of a user in the database), you must configure the provider in the services collection as described in the section ‘Use a custom provider’.

You must also call IApplicationBuilder.UseRequestLocalization(), but you must not pass any argument to the method. If a RequestLocalizationOptions argument is specified here, it supersedes what is configured in the services collection, and your custom RequestCultureProvider does not work.

Typically, you configure the middleware in the application builder before the services. But in order to emphasise the significance of setting the localisation options only in the services configuration, I have reversed this order on purpose.

How can you minimize the impact of the persistence layer on your domain models?

This is a blog response to the question ‘How can you minimize the impact of the persistence layer on your domain models?’ posted on reddit /r/dotnet, showing how I would have implemented the solution in the purest form of OOP that is possible with C#.

(Note: The implementation of the factory and persistence classes is simplified for demonstration purposes.)

So here is the code. It is tested with .NET 5 on Windows 10.

using System;
using System.Data;
using System.Diagnostics;

namespace Example.Domain
{
    // Let's pretend this namespace is in a separate assembly so that
    // the 'internal' scope modifier applies

    public interface IAccount
    {
	string Username { get; }

	bool IsEnabled { get; }

	void Disable();
    }

    public interface ISavedAccount : IAccount
    {
	int Id { get; }
	
	void Enable();
    }

    // Not accessible from outside assembly
    internal abstract class AccountBase : IAccount
    {
	public string Username { get; protected set; }

	public bool IsEnabled { get; protected set; }

	internal AccountBase(string username)
	{
	    Username = username;
	}

	public void Disable()
	{
	    IsEnabled = false;
	}
    }

    // Not accessible from outside assembly
    internal class MyAccount : AccountBase
    {
	internal MyAccount(string username)
	    : base(username)
	{
	}
    }

    // Not accessible from outside assembly
    internal class MySavedAccount : AccountBase, ISavedAccount
    {
	public int Id { get; private set; }

	internal MySavedAccount(int id, string username, bool isEnabled)
	    : base(username)
	{
	    Id = id;
	    if (isEnabled) 
	    {
		Enable();
	    }
	}

	public void Enable()
	{
	    IsEnabled = true;
	}
    }

    public static class AccountFactory
    {
	public static IAccount Create(string username)
	{
	    return new MyAccount(username);
	}

	public static ISavedAccount Create(int id, string username, bool isEnabled)
	{
	    return new MySavedAccount(id, username, isEnabled);
	}
    }
}

namespace Example.Persistence
{
    using Example.Domain;

    public static class AccountStorage
    {
	static readonly DataTable dt;

	static AccountStorage()
	{
	    dt = new DataTable();
	    dt.Columns.Add("id", typeof(int));
	    dt.Columns.Add("username", typeof(string));
	    dt.Columns.Add("enabled", typeof(bool));
	}

	public static DataRow AddAccountRow(ref IAccount account)
	{
	    var dr = dt.NewRow();
	    dr["id"] = dt.Rows.Count+1;
	    dr["username"] = account.Username;
	    dr["enabled"] = account.IsEnabled;
	    dt.Rows.Add(dr);

	    // This variable does not point to a valid account after it has been saved
	    account = null;

	    return dr;
	}

	public static DataRow UpdateAccountRow(ISavedAccount account)
	{
	    var dr = FindAccountRow(account.Id);
	    dr["username"] = account.Username;
	    dr["enabled"] = account.IsEnabled;
	    return dr;
	}

	public static DataRow FindAccountRow(int id)
	{
	    for (var i=0; i<dt.Rows.Count; ++i)
	    {
		DataRow dr = dt.Rows[i];
		if (((int)dr["id"]) == id)
		{
		    return dr;
		}
	    }
	    return null;
	}
    }
}

namespace Example.Client
{
    // Let's pretend this namespace is in a separate assembly so that it
    // doesn't see the 'internal' definitions from the Example.Domain
    // namespace

    using Example.Domain;
    using Example.Persistence;

    class Program
    {
        static void Main(string[] args)
        {
	    var account = AccountFactory.Create("joebloggs");

	    // FAIL! A new account does not have an id
	    // Debug.Assert(account.Id > 0);

	    // FAIL! A new account cannot be enabled
	    // account.Enable();

	    var newrow = AccountStorage.AddAccountRow(ref account);

            Debug.Assert(account == null, "The account object is no longer valid");

	    Debug.Assert(((int)newrow["id"]) > 0, "The 'id' value is set");
	    Debug.Assert("joebloggs".Equals(newrow["username"]), "The 'username' value is set");
	    Debug.Assert(! (bool)newrow["enabled"], "The 'enabled' value is not set");

	    var savedaccount = AccountFactory.Create((int)newrow["id"], (string)newrow["username"], (bool)newrow["enabled"]);
	    savedaccount.Enable();
	    Debug.Assert(savedaccount.IsEnabled, "The account is enabled");

	    var unused = AccountStorage.UpdateAccountRow(savedaccount);

	    var loadedrow = AccountStorage.FindAccountRow(savedaccount.Id);
	    var loaded = AccountFactory.Create((int)loadedrow["id"], (string)loadedrow["username"], (bool)loadedrow["enabled"]);

	    Debug.Assert(loaded.Id > 0, "An id is assigned");
	    Debug.Assert("joebloggs".Equals(loaded.Username), "The username is set correctly");
	    Debug.Assert(loaded.IsEnabled, "The account is enabled");
        }
    }
}

The line below might be questionable because we are effectively passing ownership of the account object to the persistence layer, but we could assume that there is a contract that formalises this.

	    // This variable does not point to a valid account after it has been saved
	    account = null;