DEV Community: Nikita Katchik

They know how to fix notifications

Nikita Katchik — Sun, 09 Oct 2022 20:08:13 +0000

The problem

The notifications on mobile devices are terrible. On all of them. Once in a while, mobile operating systems get new notifications-related features claiming to give the users more control over the notifications flooding their space visually and auditorily. While providing more flexibility, those features usually burden the users with maintaining the correct settings. Misconfiguring the notifications could result in missing important notifications. However, even if the users do keep their configuration perfect, they will still get spammed, regardless, since there is no control over frequency.

Now, I would like to avoid speculating on the mobile operating systems developers' motives for not providing any control over the frequency. However, one thing is crystal clear: they know about the problem.

Let us talk about one simple idea for solving this problem. Imagine the following situation.

[11:15:02] Text notification 1 arrives
[11:15:03] Text notification 2 arrives
[11:15:04] Text notification 3 arrives

In total, these events would fire three notifications. However, was there any thinkable purpose for the last 2 of them? Did they bring any actionable information? The only thing that comes to mind is the number of messages. Although, what if there were ten messages? Would we still count the beeps, or would we just conclude that a bunch of messages has been delivered? That kind of conclusion could be driven without listening to 10 eternally annoying beeps.

Frequency suppresion

One simple thing to do would be to work smart with the reminder-notifications which usually fire with certain interval after the first or the last unread notification, depending on the platform and the app.

Let us look at the conventional way first.

As you can see, each event fires a notification, and there are also the reminder-notifications. For simplicity, let us assume that notifications are read/released/forgotten by the system after a reminder is fired.

A way to handle a series of single-type events here would be to only fire a notification instantly when there are no unread notifications. All subsequent events would only affect the interval and the tone of the reminder notification.

The tone is changed so that the user can hear that the reminder notification is getting more urgent.
The interval is shortened so that the delay is appropriate for the suspected urgency.

Here is how it would look.

The apparent effects this strategy brought are:

The number of notifications fired is down to 6 from 13.
The chance of two notifications being fired with almost no interval has significantly decreased (it happened only once in the second chart).

Types, sources and caveats

The mentioned frequency suppression strategy can be applied globally or together with an event grouping strategy, including, but not limited to:

By notification type
By app, which dispatched the notification
By notification urgency level declared by the dispatcher
By contact or other app-level sources

This part could be much bigger than implementing the core of the strategy itself, and this is also the kind of thing that cannot be investigated in a short dev.to piece in your free time. The complications of the event grouping may be precisely why this or a similar notification frequency suppression strategy is not implemented.

Nevertheless, the notification frequency problem exists. Suppose you are not ready to disable some apps' notifications entirely. In that case, it is currently an unsolvable problem, regardless of how much effort you are ready to invest in configuring mobile notifications.

Building with Docker

Nikita Katchik — Sun, 02 Oct 2022 22:51:03 +0000

Intro

Client engineers, embedded systems engineers, and other engineers who never worked with the backend can still benefit significantly from using containers. In this piece, I would like to share how I structure nearly all of my side projects so that they can be built on any machine that has make and docker installed.

Motivation

Environment guarantee

Multiple contributors and the continuous integration server (CI) can be confident they are building in exactly the same environment.

Environment versioning

Every team member does not have to build the builder images locally. Docker Registry can be used to store and version the images.

Easy workstation/CI build agent setup

As mentioned above, the only tools required to build such a project are make and docker.

Make is not used here as the project build system but rather as a convenient tool to wrap lengthy docker commands. For the scope of the article, we will assume a Rust project located at $(ROOT_DIR)/main using cargo build system.

Linux target

Let us start simple. Docker is always Linux, so the easiest platform to target is Linux since this does not imply cross-compilation. This also works perfect for unit testing if you are writing a Linux or platform-independent application.

The following Makefile utilizes an official rust:1.61.0 image.

Makefile

ROOT_DIR := $(shell dirname $(realpath $(firstword $(MAKEFILE_LIST))))
SOURCE_DIR := $(ROOT_DIR)/main

IMAGE_BUILDER_LINUX := rust:1.61.0

build_linux: builder_linux
    @docker run \
    --rm \
    -v $(SOURCE_DIR):/src \
    $(IMAGE_BUILDER_LINUX) \
    sh -c 'cd /src && cargo build'

test_linux: builder_linux
    @docker run \
    --rm \
    -v $(SOURCE_DIR):/src \
    $(IMAGE_TESTER_LINUX) \
    sh -c 'cd /src && cargo test'

builder_linux:
    @docker pull $(IMAGE_BUILDER_LINUX)

Now a simple make build_linux and make test_linux should:

Make sure the builder Docker image is pulled
Run build/test using the image

Custom builders

It is most likely that, eventually, you will need to customize the builder image. That would imply creating a Dockerfile and building an image using it instead of pulling the image as we did above.

Assuming the Dockerfile is located at $(ROOT_DIR)/image/x:

Makefile

ROOT_DIR := $(shell dirname $(realpath $(firstword $(MAKEFILE_LIST))))
SOURCE_DIR := $(ROOT_DIR)/main
PROJECT_NAME := $(shell basename $(ROOT_DIR))

IMAGE_BUILDER_X := $(PROJECT_NAME)-builder-x

builder_x:
    @docker build -t $(IMAGE_BUILDER_X) $(ROOT_DIR)/image/x

WebAssembly

Let me use this opportunity to share some scripts to build Rust code into WebAssembly and run the unit tests.

Makefile

ROOT_DIR := $(shell dirname $(realpath $(firstword $(MAKEFILE_LIST))))
SOURCE_DIR := $(ROOT_DIR)/main
PROJECT_NAME := $(shell basename $(ROOT_DIR))

RUST_TARGET_WEB := wasm32-unknown-unknown

IMAGE_BUILDER_WEB := $(PROJECT_NAME)-builder-web

build_web: builder_web
    @docker run \
    --rm \
    -v $(SOURCE_DIR):/src \
    $(IMAGE_BUILDER_WEB) \
    sh -c 'cd /src && cargo build --target $(RUST_TARGET_WEB)'

test_web: builder_web
    @docker run \
    --rm \
    -v $(SOURCE_DIR):/src \
    $(IMAGE_BUILDER_WEB) \
    sh -c 'cd /src && CARGO_TARGET_WASM32_UNKNOWN_UNKNOWN_RUNNER=wasmtime_test_runner.sh cargo test --target $(RUST_TARGET_WEB)'

builder_web:
    @docker build -t $(IMAGE_BUILDER_WEB) $(ROOT_DIR)/image/web

image/web/Dockerfile

FROM rust:1.61.0

RUN \
rustup toolchain install '1.61.0-x86_64-unknown-linux-gnu' \
--target 'wasm32-unknown-unknown' \
--component 'rust-std'

RUN curl https://wasmtime.dev/install.sh -sSf | bash

COPY wasmtime_test_runner.sh /usr/bin

VOLUME ["/usr/local/cargo/registry"]

image/web/wasmtime_test_runner.sh

#!/bin/sh

/root/.wasmtime/bin/wasmtime "$@" --invoke main 0 0

It is relatively easy with Rust because rustup has a wasm32 toolchain ready to download, but with a more complicated cross-compiler setup, being able to make a Dockerfile describing the setup sequence is a lifesaver.

Thoughts

The more complicated the required build setup is, the more I recommend looking at the Docker-based building. Setting up a workstation to build a project requiring multiple cross compilers, especially when using certain toolchains that might require some user-fixing, can take up to a few hundred bash commands. That could theoretically be done without containers by a bash script, but that how numerous caveats, including:

State zero would have to be identical before running the script
Updating the build setup while keeping it identical between workstations is a challenging task
No environment guarantee
No switching between build setup versions

The simplest traits showcase

Nikita Katchik — Mon, 22 Aug 2022 23:39:36 +0000

Intro

It is handy to be able to separate the interface from the implementation; however, it often is not enough. In this piece, I'd like to talk about probably the simplest example of an interface-class paradigm limitation.

What if we had to design a Size class in Java or other classic OOP language? There are many variations, especially in construction (factories) and setters (if any), but one thing would have remained unchanged in every single implementation: the two numbers.

// Java

class Size {
    private int mWidth;
    private int mHeight;

    public Size(int width, int height) {
        if (width < 0 || height < 0) {
            throw new IllegalArgumentException();
        }
        mWidth = width;
        mHeight = height;
    }

    public int width() {
        return mWidth;
    }

    public int height() {
        return mHeight;
    }

    public int area() {
        return width() * height();
    }
}

Every engineer had to write something like this a couple of times, but has this never bothered you from the data perspective? It strikes me odd every time a pair of numbers is suddenly a Size. A pair of numbers can be anything, but since the data is not detachable from implementation, we create classes like Size, Point, and ComplexNumber – all containing precisely two numbers: from a data perspective, they are not different types.

Of course, we do this because, in Java, we have to think from the interface's perspective; implementation simply contains all the necessary member variables to fulfil the interface contract. The price we pay here is having to create a Size even if we have a pair of perfectly fine numbers on the stack.
In the case of Size, it does not seem like a big sacrifice; however, once the structure of the types, the transformations performed on them, and the wiring become more complex, not being able to use perfectly fine data can become rather limiting, especially if it's be something big.

The solution

What if there was an idiomatic way to treat data in different ways on different occasions? This is precisely what a trait is: a predefined way to interpret certain data type. Let us have a look at how similar thing could be done with traits in Rust.

First, we don't even have to declare a data type here: we can simply use a tuple instead. Here is how we'd declare a variable suitable to be treated as a size.

// Rust

let s = (2, 3);

Then we declare a trait. Notice that we define area() function right away. That's because the area calculation does not depend on the details of width() and height() functions implementation details.

// Rust

trait Size {
    fn width(&self) -> u32;

    fn height(&self) -> u32;

    fn area(&self) -> u32 {
        return self.width() * self.height();
    }
}

All that is left to do is to define to interpret a tuple of two integers (u32, u32) as a Size.

// Rust

impl Size for (u32, u32) {
    fn width(&self) -> u32 {
        return self.0;
    }

    fn height(&self) -> u32 {
        return self.1;
    }
}

It is just as simple to implement the Size trait for a slice of two u32's.

// Rust

impl Size for [u32; 2] {
    fn width(&self) -> u32 {
        return self[0];
    }

    fn height(&self) -> u32 {
        return self[1];
    }
}

We have just implemented Size trait for two basic data types which preexisted in the language. Now let us try invoking these implementations.

// Rust

fn foo() {
    let tuple = (2, 3);

    // Automatic trait resolution
    println!("Area: {}", tuple.area());

    // Explicitly choose trait implementation
    println!("Area: {}", Size::area(&tuple));


    let array = [4, 5];

    // Automatic trait resolution
    println!("Area: {}", array.area());

    // Explicitly choose trait implementation
    println!("Area: {}", Size::area(&array));
}

Thoughts

Data doesn't have to be glued together with the implementation even when the interface is declared separately, and creating useful code without defining redundant data types is possible. With traits, we can interpret the same piece of data differently on different occasions, which changes everything in the pursuit of a good design. Traits are sometimes referred to as a concept of object-oriented programming, but in my opinion it is misleading: the complete traits can only be found in languages leaning towards data-oriented design, like Rust.

Demystifying the complexity of RAII

Nikita Katchik — Tue, 10 May 2022 22:14:11 +0000

The idiom

Whenever I look at an article explaining Resource Acquisition Is Initialization (RAII) idiom, I feel uncertain if I would understand it if I did not already know it, so here is my attempt to make it easy.

First, let us roughly group the mainstream languages by the memory management model.

Manual: C, Assembly
Garbage-collected (GC): Java, Python, Javascript, Kotlin, C#
Automatic Reference Counting (ARC): Swift, Objective-C
Resource Acquisition Is Initialization (RAII): C++, Rust

There are numerous differences between ARC and tracing garbage collection, but we are interested in a particular one. Unlike tracing garbage collection, there is no background process deallocating the objects asynchronously in ARC. Therefore the objects are destroyed within the same reference decrement invocation where the reference count reaches zero.

One of the ways to see RAII is as ARC, with excess freedoms removed. If we take ARC as a baseline, then RAII would be different in the following ways:

Reference count can only be equal to 0 or 1. In other words, every resource can only be owned by a single variable.
A reference can be explicitly moved from one variable to another using features built into the language.
A reference can be borrowed when providing it as a function argument without increasing the reference count.

Let us take a look at some RAII pseudocode.

// RAII pseudocode

// Create new object and assign it to the variable.
var a0 = A(); // 🟢 OK

// This wouldn't build.
// An object can only be held by one variable.
var a1 = a0; // ❌ ERROR

// Move the object to another variable.
// a1 is uninitialized after that (known at compile-time).
var a1 = move a0; // 🟢 OK

// Copy the object into another variable.
// a1 keeps its original value.
var a2 = copy a1; // 🟢 OK

// This function requires ownership of an instance of type A.
fun foo(A) : B;

// Provide the object as a function argument, moving it.
// Just like when we moved the object to initialize a
// variable, this leaves the source variable uninitialized.
var b1 = foo(a1); // ❌ ERROR
var b2 = foo(borrow a1); // ❌ ERROR
var b3 = foo(move a1); // 🟢 OK

// This function does not require a dedicated instance.
// We use & to signal that a borrowed object is enough.
fun bar(A&) : B;

// Provide the object as a function argument, borrowing it.
// Although function bar does not require a dedicated
// instance, it can work with one.
var с1 = bar(a2); // ❌ ERROR
var с2 = bar(borrow a2); // 🟢 OK
var с3 = bar(move a2); // 🟢 OK

Languages & features

In RAII languages, every line is basically a try-with-resource block.

RAII originated in C++, but do not let yourself be intimidated by that. If you code in Java 7 or above, you have already glanced at certain aspects of this idiom – try-with-resource blocks.

// Java

// Java standard interface
public interface AutoCloseable { 
    void close() throws Exception;
}

try (var res = obtain()) {
    // The resource, and the variable referencing it, both
    // only exist inside this block.
}

The variable only exists inside the block.
Lifetime of the resource is bound to the lifetime of the variable.
Any usage of the res variable is effectively borrowing. No matter what happens inside the block (within reason), it will not change the scope of res, and, therefore, the lifetime of the resource it holds.

If multiple resources are required, blocks can be stacked.

// Java

public static void main() {
    try (var a = obtain()) {
        try (var b = obtainDependent(a)) {
            try (var c = obtainDependent(b)) {
            }
        }
    }
}

Furthermore, multiple resources can be declared in a single block. Once control exits the block, the resources are destroyed in reverse order of declaration, mimicking stacked blocks behaviour.

// Java

public static void main() {
    try (var a = obtain();
         var b = obtainDependent(a);
         var c = obtainDependent(b)) {
    }
}

In RAII languages, every line of code is basically a try-with-resource block. Not just every line of the function body but also every member variable declaration in a class or a structure. Destruction in reverse order of declaration mentioned above is the key to making this possible because subsequently declared resources can be dependent on one or multiple previously declared ones.

// RAII pseudocode

fun foo() {
    var a = obtain(); // Destructed third
    var b = obtainDependent(a); // Destructed second
    var c = obtainDependent(b); // Destructed first
}

// RAII pseudocode

struct Foo {
    ResourceTypeA a; // Destructed third
    ResourceTypeB b; // Destructed second
    ResourceTypeC c; // Destructed first
};

fun bar() {
    var a = obtain();
    var b = obtainDependent(a);
    var c = obtainDependent(b);

    // After this line, the a, b and c variables are empty.
    // Destroying d will trigger the destruction of all Foo
    // member variables in reverse order of declaration.
    var d = Foo(move a, move b, move c);
}

The variables, and the resources they hold, declared in either function body or as a member variable in a class or a structure, are destructed in reverse order of declaration, similar to the multiple resources in a single try-with-resource block mentioned above.

Python, too has a similar with-as feature, allowing to specify multiple resources.

# Python

with (obtain() as a, 
      obtainDependent(a) as b, 
      obtainDependent(b) as c):
    # The resources are owned by a, b, and c variables.
    # The resources and the variables only exist inside
    # this block.

RAII origins

C++ first appeared in 1985; however, if we look at the design patterns and common practices that have developed within the community pre C++11, it becomes clear that the community has not been sticking to the core idiom of the language, and for a good reason.

Before C++11, the language lacked a critical feature. There was simply no idiomatic way to move a resource (object) from one variable to another or pass the ownership in a function call. That left C++ engineers of the time with very limited options: pass raw pointers around like there is no resource management built into the language or wrap most objects in std::auto_ptr. A fallback to any of those substantially defeats the purpose of the RAII idiom.

Thoughts

I believe it is time to reevaluate the contract we signed when Java, and other languages with tracing garbage collection, appeared. Is the benefit of being able sometimes to disregard the scope of a lifetime of an object worth having to design the language around this commodity? The more experience I get with Java/C++/Rust, the more I find the language design sacrifices made in Java harder and harder to justify. To name just a few:

No real constants semantics like in Rust, C++, or even C.
We still care about memory management, but the problem moved into another perspective. At some point, any application, client or server starts having performance issues if the behaviour of the garbage collector is not taken into consideration. Java engineers have to go through a tremendous amount of learning to predict and fight the GC behaviour.
The problems above lead to having to make some classes immutable by design, which puts engineers in a weird position of having to make this choice ahead of time.

Those sacrifices may be a result of a conscious choice. However, we know way more about their consequences today than when we agreed to them in the 90s.

Although Swift does not have these problems because it uses ARC instead of a tracing garbage collector, it is still vulnerable to the reference loops. Rust, on the other hand, is not just immune to the reference loops but will not even let us make one. Except for when we use shared pointers. A strict resource management model helps to design good software by making the engineer think about the relationships.

With this in mind, I would like to invite every sceptic to have a serious look at RAII, and more specifically, Rust. As we pointed out earlier, this is not only about performance. In fact, performance is entirely secondary: the critical reasoning for giving RAII a better look is the language design decisions it allows us to make.