DEV Community: Michael Lohr

After a day of programming in Zig

Michael Lohr — Mon, 01 Jan 2024 17:05:51 +0000

I am a big fan of Rust since it provides great tooling and allows me to write code with a lot of confidence in that it will work reliably. But sometimes I hate it, too. It takes more time to write code in Rust and some things are pretty difficult to properly implement (looking at you async).

In the last year, I heard a couple of times about a new low-level programming language called Zig. And now I finally found the time to try it out. In this article, I want to talk about the things I liked and disliked about Zig from the perspective of a Rust developer (and the high standards they are used to 🦀👑).

So what is Zig?

Zig describes itself as "... a general-purpose programming language and toolchain for maintaining robust, optimal and reusable software.". Sounds very generic, eh?

The "unique selling points" are:

No hidden control flow; you control everything
No hidden memory allocation; they are all explicit and allow to use different allocation strategies
No preprocessor, no macros; directly write compile time code in Zig instead
Great interoperability with C/C++; supports cross-compilation; can be used as a drop-in replacement for C.

Zig is a bit similar to Rust since both focus on performance and safety. They don't use garbage collection, use LLVM as the compiler backend, and provide code testing capabilities. Both use a modern syntax and offer programming features like error handling and options.

const std = @import("std");

/// Removes the specified prefix from the given string if it starts with it.
pub fn removePrefix(input: []const u8, prefix: []const u8) []const u8 {
    if (std.mem.startsWith(u8, input, prefix)) {
        return input[prefix.len..];
    }
    return input;
}

Even though it simplifies a lot, I like to say that Zig is to C what Rust to C++ is. Others say, that Zig is the modern successor of C. As a rule of thumb, it probably makes sense to use Zig in projects where you would have used C before.

Is it good?

I usually learn new programming languages by simply writing some simple programs from start to finish. In this case, my goal was to write a telnet client (an old network protocol for remote access to terminals). This was quite a journey since telnet is a lot more complex than it seems. But this deserves an article on its own.

It actually took me more than one day to implement this project, but after a full day of working on it, I had the feeling that I understood the basics of Zig. You can find the source code here: https://github.com/michidk/telnet-zig/

What I dislike about Zig

The barrier of liking Zig is not too high, since I really dislike programming in C. So let's first discuss the things I disliked:

The Zig community and ecosystem are rather small, and not many libraries are available. Those that are available are also not very fleshed out yet. This is very different for Rust, where you can find at least one very popular and well-implemented crate for each problem which you might want to outsource to a library.

Zig comes with a standard library that is similarly minimalistic like the Rust standard library. It is yet rather small but carefully designed. The documentation is not very good and many methods are undocumented.

Undocumented code from std.io.Writer (https://ziglang.org/documentation/master/std/#A;std:io.Writer):

There is no proper pattern matching in Zig. However, switch statements are quite powerful and when nesting them it is possible to achieve something similar, like one can do with Rust's match statement.

In Rust, traits (or interfaces in other languages) allow for polymorphism - the ability to write code that can operate on objects of different types. This is a powerful feature for designing flexible and reusable software components. Zig, however, lacks this feature. It relies on other mechanisms like function pointers or comptime polymorphism, which can be less intuitive and more cumbersome for scenarios typically handled by interfaces or traits.

But to be honest, I wouldn't have expected otherwise, since Zig is rather young and only recently gained in popularity.

Why I love Zig

Zig is great! It makes writing code fun in a similar way like Rust does.

Tooling, Build System & Tests

Even though the language is rather young, the tooling is great! However is not as advanced as the Rust tooling with cargo and clippy (yet). Only the most recent version v0.11 delivered us an official package manager, called Zon. It can be used together with the build.zig file (which is similar to a build.rs in Rust) to load libraries from GitHub into our project without much hassle (I don't even want to know how much valuable lifetime cmake and make have cost me in the past).

$ zig build-exe hello.zig
$ ./hello
Hello, world!

Similarly to Rust, Zig comes with robust testing capabilities built into the language. Tests in Zig are written in special functions, allowing them to reside alongside the code they are validating. Unique to Zig is the ability to leverage its compile-time evaluation features in tests. Additionally, Zig's support for cross-compilation in testing is particularly noteworthy, enabling developers to effortlessly test their code across various target architectures. Some people even use Zig to test their C code!

const std = @import("std");
const parseInt = std.fmt.parseInt;

// Unit testing
test "parse integers" {
    const ally = std.testing.allocator;

    var list = std.ArrayList(u32).init(ally);
    defer list.deinit();
...

The Language

The language itself is well-designed and the syntax is quite similar to Rust. Both have a type system that emphasizes strong, static typing, though the way they handle types and type inference differs.

Error Handling and Optionals

Zig and Rust both promote explicit error handling, however their mechanisms are different. Rust uses Result enums, while Zig uses a (global) error set type (though similar to an enum) and error propagation. Similarly, Rust uses the Option enum for optional types, while Zig uses a type modifier (?T). Both offer modern, syntactic sugar to handle those (call()? and if let Some(value) = optional {} in Rust, try call() and if (optional) |value| {} in Zig). Since Rust uses the standard library to implement error handling and options, users have the possibility to extend those systems which is quite powerful. However, I like the approach Zig takes in providing those things as language features. While their approach fits well into the C universe, I dislike that there is no pragmatic way to add more context to an error (but well, no allocations). Libraries like [clap](https://github.com/Hejsil/zig-clap) solve this by implementing a diagnostics mechanism.

// Hello World in Zig
const std = @import("std");

pub fn main() anyerror!void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print("Hello, {s}!\n", .{"world"});
}

C Interop

The C interoperability in Zig is world-class. You don't need to write bindings, with Zig you can just use the @cImport and @cInclude built-in functions (which parses C header files) to directly use C code.

Comptime

Zig allows us to write Zig code (no special macro syntax like in Rust), which is evaluated during compile time using the comptime keyword. This can help to optimize the code and allows for reflection on types. However, dynamic memory allocations are not allowed during compile time.

Types

Like in Rust, Zig types are zero-cost abstractions. There are Primitive Types, Arrays, Pointers, Structs (similar to C structs, but can include methods), Enums and Unions. Custom types are implemented through structs and generics are implemented by generating parameterized structs during compile time.

// std.io.Writer is a compile-time function which returns a (generic) struct
pub fn Writer(
    comptime Context: type,
    comptime WriteError: type,
    comptime writeFn: fn (context: Context, bytes: []const u8) WriteError!usize,
) type {
    return struct {
        context: Context,

        const Self = @This();
        pub const Error = WriteError;

        pub fn write(self: Self, bytes: []const u8) Error!usize {
            return writeFn(self.context, bytes);
        }
...

Memory Allocation

Unlike Rust, which employs an automatic borrow-checker to manage memory, Zig opts for manual memory management. This design decision aligns with Zig's philosophy of giving the programmer full control, reducing hidden behaviors and overhead.

At the core of Zig's memory management strategy is the Allocator interface. This interface allows developers to dictate precisely how memory is allocated and deallocated. Developers can choose from several allocators or implement custom ones tailored to specific needs or optimization goals.

This is great but can be a bit annoying in practice. The allocator is typically created at the beginning of the application code and assigned to a variable. Methods which want to allocate memory, require the allocator as a parameter in their function signature. This makes allocations very visible but also can get a bit annoying because it has to be passed around through multiple functions throughout the whole application (at least to the parts where you allocated memory).

Cross Compilation

Zig, like Rust, has native support for cross-compilation. Its integrated toolchain simplifies compiling for different architectures or operating systems. Setting the target architecture in Zig is as straightforward as passing an argument in the build command:

# Build for Windows on Linux
zig build -Dtarget=x86_64-windows-gnu

In contrast, Rust requires the installation of the target platform's toolchain through rustup and often necessitates manual linker configuration for the target platform.

Conclusion

I find Zig to be a well-designed, fun, and powerful language. It can be challenging to use because of the small ecosystem and the lack of documentation, which most likely will improve soon with increasing popularity. Zig provides modern syntax, a great type system, complete control over memory allocations and state-of-the-art language features.

Overall, I enjoyed programming in Zig and I think it has a lot of potential to become a popular choice for low-level development. Personally, I think Zig could be a real game changer for embedded systems (in a few years) and I am quite excited to see what the future holds for Zig.

I encourage you to give Zig a try⚡.

Reverse engineering Microsoft's dev container CLI

Michael Lohr — Wed, 15 Nov 2023 19:35:30 +0000

Dev containers allow you to open up projects and have them running in a fully pre-configured environment with one click!

... is how I introduced the concept of dev containers in my last article.

I also mentioned that I have been working on a small utility named vscli, which enables you to launch Visual Studio Code (vscode) from the command line (CLI) or a terminal user interface (TUI) like this:

Now this does not look very complicated, right? The cool thing is (and actually the main problem I want to solve with this tool), that it can also open devcontainers. So if it detects that the folder you are trying to open, with e.g. vscli dev/myproject, contains a dev container configuration file, it will open it in a vscode dev container instead.

Now, you might think it is as easy as calling a command like code dev/myproject --devcontainer behind the scenes. You couldn't be more wrong!

Before explaining how this actually works, I want to let you know that it will get a lot weirder when we try to add support for a new dev container feature later.

How everybody is doing it

This is not a problem that hasn't been solved before. Lots of people want to start their dev containers right from the CLI, without navigating menus in vscode. So if you look through various bash scripts and some issues on GitHub, you will find that most people solve this by executing the following command:

code --folder-uri vscode-remote://dev-container+<some_weird_hex_string><a_path>

Which then could look like this:

code --folder-uri "vscode-remote://dev-container+5c5c77736c2e6c6f63616c686f73745c417263685c686f6d655c6d696368695c6465765c7673636c69/workspaces/vscli

The last part (/workspaces/vscli in this case) is the path we want vscode to open inside the container. It is /workspaces/project_folder_name by default, but it can be overwritten inside the dev container configuration file.

The hex value is the path on the host, encoded in hex. Decoded could look like this (when the dev container was launched from WSL):

\\wsl.localhost\Arch\home\michi\dev\vscli

Note: We used WSL here, so most paths will be WSL paths. However, it works quite similarly on Windows.

How did we figure that out?

Well, I got the hint from this GitHub issue. Also, it seems like at one time a devcontainer open command existed in the old dev container CLI (it does not exist anymore since the CLI wants to be editor-agnostic).

There is also another version of the dev container CLI, which is included in the proprietary vscode dev container extension. This version actually includes the devcontainer open utility, but we only have access to the minified JavaScript code.

So if this problem is already solved, why implement our own CLI tool? Well, there are multiple reasons: closed-source, sending telemetry by default, and cannot be installed with a proper packet manager.

But we want multiple containers

It was brought to my attention, that the dev containers spec/vscode released a new feature, which would allow having multiple dev container definitions inside one project (by creating multiple configuration files in different places). I needed to try it out immediately, and actually found several use cases in my projects - so vscli needs to support it as well!

But how would I tell vscode which container to open? Using the strategy mentioned earlier, there is no way to point to some specific config. I did some research, and I haven't found a single codebase or shell script containing code to open dev containers in any other way than the command above. So nobody either managed or cared enough to figure this out. Is it even possible? Well, it has to, since vscode does it too!

Down the rabbit hole...

So I sat down together with my buddy and did a late-night investigation. Here is how it went (spoiler: we actually figured it out in the end).

First, we had a look at the closed-source version of dev container CLI again, maybe it supports this? Turns out it does!

So we downloaded the source code of the dev container extension from the official marketplace: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers. This gives us the ms-vscode-remote.remote-containers-0.320.0.vsix file. Since .vsix is basically just a .zip file, after extracting it we could explore the extension.

Luckily they not only included the compiled binary but also the Node JavaScript "source code": extension/dev-containers-user-cli/dist/node/devContainersUserCLI.js. However, it's not real source code, since the source application is probably written in TypeScript, and what we get to see is the minified, transpiled JavaScript:

This code is optimized for minimal size, so most of the functions and variable names are renamed to one-letter names and everything is put into one line without spaces.

Making sense of the code

Since this code is unreadable, it is very hard to get the control flow. We started by searching for strings we know, like vscode-remote://dev-container. And we had a match! The extracted and formatted function which uses this string looks like this:

function Z$(t, e, n, r, i, o) {
  t = moe(t);
  let s =
    r || o
      ? JSON.stringify({
          hostPath: e,
          localDocker: i,
          settings: r,
          configFile: o,
        })
      : e;
  return `vscode-remote://dev-container+${Buffer.from(s, "utf8").toString(
    "hex"
  )}${t ? `@${t}` : ""}${n}`;
}

We can see that whatever is put behind the + (variable s) is converted into hex, as we already know. n is the workspace path and the final part of the URI. t is an optional parameter I am not quite sure of. But if we look into how s (the hex-encoded part) is defined, we can see that it is either e or some JSON string depending on how r || o evaluated.

So this seems to be the solution to the problem! It is possible to pass in more data than just the project path! We don't really care for r and o at this point, but if we look into how the JSON string is constructed, we can even read what they are: r seems to be some additional settings and o the configFile? e is the hostPath, which is also used when we don't use the JSON string. So this is the path to the project we also used in the old approach. i which is put into the localDocker field is probably some boolean that describes whether to use a local or remote Docker host.

Did we solve it?

The configFile parameter is probably the file path of the dev container config file we are trying to load. So let's build up the following JSON and try to open vscode:

{
    "hostPath": "\\wsl.localhost\Arch\home\michi\dev\vscli",
    "configFile": "\\wsl.localhost\Arch\home\michi\dev\vscli\.devcontainer\testContainer.json"
}

Which opens vscode, but it will complain with the following error: \[UriError\]: Scheme contains illegal character.

We tested a few options to debug this:

Only using hostPath without configFile: works (but we cannot choose a dev container config)
Directly putting the dev container config file contents into configFile: UriError
Using Windows style file paths: UriError

So configFile expects some special URI format? It's time to look into the code a bit more: Z$ is called only once:

  let q = Z$(
      void 0,
      p,
      w.workspaceFolder,
      void 0,
      void 0,
      e ? qn.file(Ze.resolve(process.cwd(), e)) : void 0
    ),

Most parameters are void 0, which is the shorter equivalent of undefined. This shows that r, i and t of Z$ are actually not used (probably for legacy reasons), so we always use the JSON format nowadays. We also learn how the input to the hostPath is constructed: qn.file(Ze.resolve(process.cwd(), e)).

At first look, it looks like it combines the path of the current folder (process.cwd()) and the relative path to the dev container config file and then passes it into a function that builds the file representation that the URI expects. After some investigation and finally ended up with this code:

var LP = ae(require("os")),
 Ze = ae(require("path"));

We concluded that Ze.resolve() is part of the node.js path library and indeed combines path segments.

The last mystery: `.file()`

This one was difficult. We really could not make sense of this method, since it was part of a bigger library:

var { URI: qn, Utils: awe } = AF;

// and then somewhere else in the code
// ...
        (D.extname = function (A) {
          return F.extname(A.path);
        });
    })(R || (R = {}));
  })(),
    (AF = r);
})();

Luckily, somewhere in this library, we found an error message: The "pathObject" argument must be of type Object. Received type .... I was never as excited before to find an error message. But this is something we can Google and maybe find out which library it is!

And it worked! We found a GitHub issue in the vscode GitHub repo, which referenced the exact file it is implemented in. Turns out this is the internal URI library of vscode!

The code is still quite complex, but there was an easier way anyways. I just opened up the developer tools in vscode and called the .file() function directly, passing in the path to my dev container config:

So the .file() method returns an object that is directly serialized into JSON. The UriError message from before probably hinted at the "scheme":"file", property missing. This does not look like a proper URI interface and is probably an accident, where the developers forgot to properly serialize the path - but hey, we figured it out!

So now we can use the following JSON to open our dev containers with multiple config files:

{
  "hostPath": "\\wsl.localhost\Arch\home\michi\dev\vscli",
  "configFile": {
    "$mid": 1, // optional
    "path": "/Arch/home/michi/temp/multi/.devcontainer.json",
    "scheme": "file",
    "authority": "wsl.localhost"
  }
}

There is still some work to do with getting the paths in the proper format and to make this work on Windows, but this should get you started if you want to implement this yourself. Check out the implementation of this in vscli here: https://github.com/michidk/vscli/blob/main/src/uri.rs

Now, if you try to open a project with more than one dev container using vscli, the following dialog will appear:

Want to use vscli yourself? Check it out on GitHub: https://github.com/michidk/vscli

Dev Containers: Open, Develop, Repeat...

Michael Lohr — Mon, 30 Oct 2023 22:16:58 +0000

Dev containers allow you to open up projects and have them running in a fully pre-configured environment with one click!

It is especially useful if you want to keep your system clean of different SDKs with different (conflicting) Versions (looking at you Python 👀) or work on many different projects, which require different setups. It is also helpful to provide a dev container for other people to start working on your projects because they get up and running within seconds!

I have used them for more than two years and it made my developer workflow so much easier. I nowadays use them in every project - work and private!

Intro

How it works? Dev containers is a specification based on Docker. This specification describes a metadata file (devcontainer.json), which defines how the project (Docker container, IDE settings, plugins, etc) is set up.

It can look as simple as:

{
    "name": "Rust",
    "image": "mcr.microsoft.com/devcontainers/rust:1-bullseye",
}

Or get more complex like, this configuration which is based on a local Dockerfile, installs "dev container features" (will be explained later), configures some extensions, and my terminal:

{
    "name": "My Rust IDE",
    "build": { "dockerfile": "Dockerfile" },
    "features": {
        "ghcr.io/guiyomh/features/just:0": {}
    },
    "customizations": {
        "vscode": {
            "extensions": [
                "rust-lang.rust-analyzer",
                "tamasfe.even-better-toml",
                "serayuzgur.crates",
                "kokakiwi.vscode-just"
            ],
            "settings": {
                "terminal.integrated.defaultProfile": "zsh"
            }
        }
    }
}

As you can see from the customizations section, dev containers are IDE agnostic. For example, there is a project implementing dev container support into nvim. But since the Visual Studio Code (vscode) team at Microsoft invented dev containers, it is currently the IDE with the best dev container experience.

A dev container can be bootstraped by using the vscode UI or creating the configuration file by hand. There are a bunch of pre-made dev container configurations maintained by the vscode team and community ready to be used:

This video is a good resource on how to learn the basics of dev containers and how to use them in vscode:

Dev Container Features

dev containers not only allow you to define which extensions should be installed and which configuration settings shall be set, but they also have something they call "dev container features".

They are reusable modules that contain installation scripts and dev container configurations. This means allows you to configure your development environment even quicker (and install them using a vscode UI).

In my example above, I installed the developer tool "Just" as a dev container feature. I could also install it by adding the install script to my Dockerfile. However, I would have to build my own Dockerfile and would have to maintain this piece of code myself. This dev container Feature works on different architectures and base images, which makes them convenient to use.

A list of available dev container features, can be found here. However, you can also develop your own features and publish them, like I did.

Opening dev containers From the CLI

So you can use dev containers from the vscode user interface rather intuitively. All configurations can also be edited directly and there is even a CLI. However, this CLI is made editor agnostic, so there is no vscode integration.

What I have been always missing was just a simple command to open up a dev container in my current directory, inside vscode. Turns out it is not that easy!

Now, there is a proprietary dev container CLI version included in vscode (which can be only installed by adding C:\Users\<USER>\AppData\Roaming\Code\User\globalStorage\ms-vscode-remote.remote-containers\cli-bin to the PATH), that offers a devcontainer open command. I am not sure if there is a version for Linux as well. But what I am sure of, is that it sends some kind of telemetry data to Microsoft by default.

I was not happy with this solution, so I built vscli, a vscode CLI tool to launch projects and support dev containers. It works on most platforms and is written in Rust. It includes a simple terminal UI, which allows you to quick-launch your recently opened projects:

Check it out here: https://github.com/michidk/vscli

GitHub Codespaces

dev containers also power GitHub Codespaces, which allows you to have the same dev container experience in the Browser running in the Cloud!

It is a bit like github.dev (you can replace the .com with a .dev or just press . on any GitHub repo and you will get the project editable in a vscode web version), but with all the extensions and dev container running on a machine in the Cloud.

Closing Thoughts

I recommend you to check out dev containers, it made my life so much easier. At this stage, they are also pretty mature and supported by a large community.

I even know some VIM people, using vscode from time to time just because of dev containers 😉

Making IBANs more memorable

Michael Lohr — Sun, 23 Jul 2023 11:01:29 +0000

Or: "How I fixed IBANs with Bitcoin". This article is supposed to walk you through the journey I had while exploring an idea I had in mind for making IBANs more memorable.

The IBAN (International Bank Account Number) is a standardized international numbering system for bank accounts. It's used across countries to send money securely from one bank account to another.

In Germany, an IBAN might look like this: DE67834783927384738238\. Now if you lend someone money for lunch (because they didn't have cash on them) and want it back, you would send them your IBAN. Now you have three options:

Log in (and authenticate) to your banking app and copy & paste the IBAN
Copy it out from your notes app, where you wrote it down before
Take out your banking card and copy the IBAN number that is printed on it
You both have PayPal, and you just share your email
You are a maniac and know your IBAN by heart

All those options are a bit annoying and dependent on how often you find yourself in such a scenario, you might get pissed off about how unmemorable IBANs are. I am pissed off about how unmemorable IBANs are (in case you wondered).

Inspiration

You might have heard of BIP-0039. No, you probably didn't, but you might have seen something like this:

canyon situate farm wedding cluster budget truck bag goose
obtain surround soda cable galaxy spoil utility tip remember
scan danger cat lawsuit staff riot

This is a Bitcoin wallet seed encoded in the so-called mnemonic code, which was proposed in BIP-0039. It is easier to remember, verbally communicate and write down than binary or hexadecimal data. This would be really handy to have for IBANs as well!

I want my IBAN to be a 'simple cluster truck wedding bag goose soda galaxy'

The Bitcoin implementation comes with a few Bitcoin-specific add-ons, which we don't need. So we could just follow the implementation by Oren Tirosh, which everybody seems to reference when talking about mnemonic code.

The Theory

The Mnemonic encoding by Oren works by taking a segment of bytes and calculating an index that maps to a word of a wordlist. This is not just one random wordlist extracted from a dictionary. The words are carefully selected by adhering to a set of criteria (which is heavily discussed on the internet), as seen here. So we just have to import some library and convert an IBAN into a bunch of bytes?

Well, first, we have to discuss how we actually convert an IBAN to bytes. We want to use as few bytes as possible since each extra byte will result in additional words, which one must remember.

How IBANs work

But in order to be able to properly encode IBANs into bytes, we first have to understand what they are and how they work.

IBANs are defined in the ISO 13616-1 standard, which is actually quite readable (which I am not used to when reading standards). It defines that an IBAN consists of the following elements:

Two-letter country code, aka "alpha-2 code", according to ISO 3166-1
Checksum consisting of two numbers
Up to 30 characters and numbers called the "BBAN"

The BBAN has to have a fixed size per country code and also encode a bank identifier whose position and length are also fixed per country code.

This means that each country has its own "sub-standard" for IBANs (or BBANs, to be specific).

The country code is often indexed by a numeric code that is bigger than 255, meaning it would not fit in one byte. But if you look at the actual country code list, there are just 249 entries. This means by simply numbering them from 0 to 248, we can store that index in just one byte.

In theory, we could remove the checksum from the mnemonic code and recalculate it when parsing the code, which would remove one byte. Since mixing up a word is more unlikely than mixing up a number, this could be a valid consideration. However, I think mixing up the order of words is still pretty likely, so some kind of verification check is still necessary.

Encoding the BAN is the difficult part: Each country has its own BBAN standard, as seen on Wikipedia. It would be nice to have a way to support arbitrary IBAN numbers and convert them to bytes in the most space-efficient way. For this, one probably has to incorporate the country-specific BBAN specification to parse characters and numbers in the correct places (numbers need way fewer bytes than characters).

For German IBANs, it's quite easy: After the checksum, there are 18 numeric characters left to parse. The first 8 are the bank identifier, and the following 10 are the account number. These 18 numbers characters can be interpreted as a 7-byte integer. No ASCII characters, which would increase the byte representation in size. Together with the country code, we arrive at 8 bytes in total.

For comparison, here are some other countries with their IBAN format and required bytes:

Country	IBAN Length	Format (excluding country code and check digits)	Bytes
Germany	22	8 numeric (BLZ), 10 numeric (Account No.)	8
France	27	5 numeric, 5 numeric, 11 numeric, 2 numeric	11
United Kingdom	22	4 alphanumeric (Sort Code), 6 numeric, 8 numeric	11
Spain	24	4 numeric, 4 numeric, 10 numeric, 2 numeric	10
Italy	27	1 alphanumeric, 5 numeric, 5 numeric, 12 numeric	12
Netherlands	18	4 alphanumeric, 10 numeric	8
Belgium	16	3 numeric, 7 numeric, 2 numeric	6

Implementation

Most programming languages have libraries that already implement Oren's mnemonic encoder/decoder (e.g., Python or Rust).

So to implement the conversion from some IBAN string to mnemonic code, we would follow these steps:

Split the country code of the IBAN, so that checksum and BBAN remains
Calculate the index of the country code and convert it to a byte
Parse the checksum and BBAN as some big integer and convert them into bytes
Put the country code byte and other bytes together and feed them into the mnemonic encoding library

To implement parsing the mnemonic code into an IBAN, we would just reverse the steps. If we discarded the checksum while encoding, we would have to recalculate it again. I also recommend verifying the IBAN using its built-in checksum mechanism.

I would love to provide the source code of my implementation, but I would have to clean it up first. If you did a proper implementation of this, let me know!

Further Considerations

This is a list of "add-ons" to this idea, which I might extend in the future.

By discarding the IBAN checksum and implementing a custom crc-based checksum, one could reduce the storage footprint of the checksum.

It would also be possible to separately encode the checksum in an extra word which is appended to the end. Then the "checksum word" would be optional, and the user could decide whether he wants to remember this additional word.

Conclusion

This was a fun experiment that allowed me to dive deeper into topics that always interested me but never had a use case for. Maybe this idea is actually helpful - if you think so, let me know. I might write a simple web service that allows for an easy conversion. The problem with these things is that they are useless until not everybody (or some big banks) is adapting this. It would be really awesome if in the future, I could just enter some words into my banking app to send my money to someone. However, there are probably also some security considerations I haven't thought of.

Changing the primary display on Windows by code is easy... right?

Michael Lohr — Sat, 29 Oct 2022 10:27:27 +0000

I have this issue where Windows is sometimes randomly changing my primary display after a system restart. So I wanted to create a simple command-line application that would allow me to change the display settings on system startup - should be easy, right 🤔?

There are great tools like MultiMonitorTool that already provide this functionality, but they come with a lot of UI and utilities, that I don't need - I want a lightweight tool that I can include in my automated Windows setup.

I did some research and found various blog articles and forum entries about how to change the primary display. They (e.g. here and here) suggest to use the ChangeDisplaySettingsEx call to the user API (winuser.h).

After some testing, I just couldn't get it to work even though it's supposed to be one simple call to the winuser library. So I used API Monitor to see what API calls MultiMonitorTool makes. There are more than 50 calls to the winuser APIs alone. But I eventually found the ChangeDisplaySettingsEx call and tried to replicate its content exactly (even byte by byte) - still no success.

After some more research and having a look at random source code snippets from GitHub, I finally found out how to change the primary monitor properly - and it's way more complicated than I could have ever imagined.

So before diving into the details - here it is: displays - a lightweight CLI tool and Rust library to change display properties like primary display, resolution and orientation. I developed the application in Rust using the winsafe crate, which basically creates a safe wrapper around the Windows API. However, I had to contribute various changes to that crate in order to implement the following API calls.

I am by no means an expert with regard to the Windows API. There are probably other calls that work as well and simplify some things. But I wanted to keep the tool generic so that it can be used to change the orientation, resolution, primary etc of any amount of monitors connected. So let's get started:

First, you have to find out the identifier of the display you want to make the new primary. In order to do that, you have to call EnumDisplayDevices multiple times with an increasing counter as a parameter in a loop. Stop looping as soon as a call returns an error.

After that, you can call EnumDisplaySettings (or the Ex version) by passing the identifier to retrieve the so-called DEVMODE structure. This struct contains information about the display, like position, which is required for the following calls.

Now we are finally ready to call ChangeDisplaySettingsEx, right? Turns out you need to call this for every display that is connected and active (I will elaborate on the reason for this later), which means you also gotta call EnumDisplaySettings for every monitor. Finally, we can execute the program... And nothing happens.

Turns out you have to call ChangeDisplaySettingsEx one more time while passing NULL to every parameter, in order to actually "commit" the changes (the monitor will flicker and apply the new properties afterwards).

MultiMonitorTool does it the same way (other than it issues some additional calls, that are not important for this) - so did we solve the problem? Nope, still doesn't work 😐. After comparing the parameters of other's tools' calls as well as mine', I noticed that the position properties of the ChangeDisplaySettingsEx call are different.

And here comes the weird part: The values change depending on which monitor I set as primary. So there is clearly some magic happening, that calculates new position values. This seems to be the difference between the other's approach and my broken one.

Finally, I found a hint in some Chinese codebase that hinted at the virtual screen model that Windows uses. Turns out that the primary display also defines the origin of the coordinate system that the other monitors use when specifying the position. So instead of just passing the position from the EnumDisplaySettings call, we need to recalculate it accordingly for each active display. To figure that out took me waaay to long - I wish Microsoft had some information about this in their documentation.

Implementing this is not hard: The new primary display always is located at position (0, 0). The other ones should be moved by the negative position of the old primary display to align them to the new origin:

new_display_position = -old_primary_position + old_display_position;

And voila - it works just fine now.

🙃

Feel free to check out the code on GitHub or get the tool from crates.io or Chocolatey.

Edit: Apparently there is a new API that simplifies this process (docs)

The struggle with SSH key management under Linux

Michael Lohr — Thu, 10 Mar 2022 16:20:14 +0000

Cover Photo by Samantha Lam on Unsplash.

When using tools like git, ssh etc. from the command line, reentering the passphrases of your keys can become very tedious rather quickly. This is where key management comes into play: Basically, you want to unlock your key once and keep it ready in your session for the tools to use it until the point where a timeout or system restart occurs.

I always just used some zsh ssh-agent plugin or had eval ssh-agent in my .bashrc totally unaware of the fact that this is a very suboptimal solution...

SSH keys

When connecting to a server using SSH or pushing your changes to a git server you have to authenticate yourself using an SSH key. Git also allows HTTP authentication using a password, but you definitely should use SSH. SSH keys also should have a non-empty passphrase as an additional layer of security. If somebody steals your key (the file on your hard drive), they won't be able to use it without your passphrase.

You also might want to digitally sign messages and git commits with GPG, which also requires a password-protected key. Now, when actually signing a commit or connecting to a remote server using SSH, you have to enter the passphrase to your key. This is annoying if you have a long secure passphrase and use that very often.

ssh-agent

ssh-agent solves this problem: It creates a Linux socket that offers your ssh client access to your keys. It is started with the command ssh-agent, which returns a path to the socket:

After adding this path to the environment variables you can use ssh-add <path of your ssh key> to add your SSH key to the "cache" (you can list your added SSL keys with ssh-add -l).

Most instructions online, will tell you to add something like eval "$(ssh-agent -s)" to your .bashrc file or similar. You might have already noticed, that executing ssh-agent will give you a new socket every time you execute that command. Meaning with every shell session you now start, you will spawn a new ssh-agent:

You will also have to enter your passphrase once per session. There has to be a better way, right? Right?!

As ysh7 pointed out, it is also possible to set a custom socket path using the flag -a bind_address and then set the environment variable SSH_AUTH_SOCK to that same value. ssh-agent can then be started as systemd service as described here.

keychain, ssh-find-agent, zsh ssh-agent, bash scripts...

Jon Cairns wrote a similar article about this problem and presented a solution: A script that tries to find and reuse existing ssh-agents. There are multiple scripts with similar approaches all written in bash: ssh_find_agent, zsh-ssh-agent, and the most popular one: keychain. (And later I also discovered envoy). But being bash scripts, they are hard to read, not really fast, and make debugging a hell. I had used keychain successfully until I encountered a problem that I wasn't able to understand. Also, those tools depend heavily on ssh-agent and ssh-add instead of using the socket directly.

I was ready to implement something similar to keychain in Rust

I then actually sat down and implemented a prototype of my SSH/GPG agent manager in Rust, which forced me to really understand the tooling around SSH keys. But there was a problem, I could not solve: Every time I restarted my environment (in my case WSL), I had to reenter all my passphrases to all the keys even if I wouldn't need them.

gpg-agent to the rescue

After some reading through the confusing docs of different (outdated) versions of gpg-agent (yes not ssh-agent), I finally found a working solution: Apparently gpg-agent uses its own socket and works way smarter than ssh-agent. Luckily gpg-agent has support to also manage your ssh keys (and of course also manages your gpg keys)!

I don't fully understand the design decision behind ssh-agent, which prints fairly essential information out as executable code, and doesn't update the current shell with the required environment variables; that just seems a bit bizarre to me. - Jon Cairns

So how do we use it, then?
First of all, you need GnuPG, which installs the necessary tools. Sadly there is still no all-in-one version, but GpuPG comes with everything we need.

Now put the line enable-ssh-support into your ~/.gnupg/gpgagent.conf (create it, if it does not exist). You can also specify a timeout, by adding the following lines:

## 1-day timeout
default-cache-ttl 86400
max-cache-ttl 86400

Then add the following lines to your .bashrc, .zshrc or whatever you are using:

export GPG_TTY=$(tty)
gpg-connect-agent --quiet updatestartuptty /bye >/dev/null
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)

GnuPG uses pinentry, which allows it to create the console UI asking for your password. This dialog system requires the GPG_TTY environment variable to be pointing at your current tty. The next line starting with gpg-connect-agent starts the gpg-agent as a demon in the background if it is not already running and tells it to use your current terminal for those UI dialogs. Since it always outputs "OK", even when we specify --quiet, we forward the output into /dev/null to hide it. Finally, we use gpgconf to tell SSH where the socket of gpg-agent is located and export it to the environment (so now we use a socket managed by gpg-agent and not ssh-agent anymore).

Conclusion

This is exactly what I have been looking for. I wish I had explored gpg-agent sooner. Now my shell asks me only once when using specific keys for the first time. The dialogue looks like this:

The only downside I see with this approach is that we have to call two commands (gpg-connect-agent and gpgconf) every time we launch a new shell. But this is fine, as they are really fast:

gpg-connect-agent --quiet updatestartuptty /bye > /dev/null  0.00s user 0.00s system 60% cpu 0.004 total
gpgconf --list-dirs agent-ssh-socket  0.00s user 0.00s system 89% cpu 0.001 total

If you want to have a look at my dotfiles, feel free to do so. Thanks for reading!

Automatically deploy websites to Plesk using GitHub Actions or GitLab CI

Michael Lohr — Wed, 07 Apr 2021 13:45:43 +0000

Plesk is a commonly used webspace control panel, and thanks to the free Plesk Git extension, it is possible to automatically deploy all your changes from any CI.

Dreaming about a setup where you just push your changes, and they will be immateriality live?

It’s possible! I use Hugo and NPM to build my static websites and deploy them automatically from GitHub/GitLab to my Plesk webspace.

So how is this possible? The secret is the Plesk Git extension, which can pull any git repository as soon as a webhook is called (this extension has to be installed by your provider, but with most providers, it is available). For that we have to push our built artifact to another branch (similar to how github-pages works), which is then deployed to the webspace.

Step 1: Modify your CI

Here it depends what on CI you use. I will provide examples of how it’s done with GitHub Actions and GitLab CI. Generally, the steps are:

Create an ssh key (deploy key) and put it into a CI variable to grant the CI push access to the repo
Use an image with git or install git and set up the key
Create a new branch, e.g., deploy
Clone the deploy branch and delete everything besides the .git folder
Move the built artifact from the previous build step to the cloned (and now empty) folder
add, commit, push

Instructions: GitHub

First, generate an ssh key. With GitHub you can then create a deploy key under Settings->Deploy keys by inserting the public key. Then make a repository secret named SSH_PRIVATE_KEY under Settings->Secrets and insert the private key.

Your Action definition then might look like this (don’t forget to change the repository URL):

Instructions: GitLab

First, generate an ssh key. With GitLab you can then create a deploy key under Settings-> Repository->Deploy keys by inserting the public key. Then make a protected variable named SSH_PRIVATE_KEY under Settings->CI/CD->Variables and insert the private key.

Your .gitlab-ci.yml CI definition then might look like this (don’t forget to change the repository URL):

Step 2: Create website in Plesk

Next, create the website in Plesk and add a Git repository. If the repository is private, you have to add the public key given by Plesk to GitHub/GitLab as the deploy key for the SSH connection. Don’t forget to select the deploy branch and correct folder on your webspace! Instruction can be found here.

Plesk always clones the main branch for the first time before you switched to the other branch. When switching, the old files won’t get deleted, so you might have to clean up once and remove some of the old files from the webspace folder.

Step 3: Configure the webhook

Plesk will give you a webhook-URL under the repository settings of the git extension in Plesk. Then configure GitHub/GitLab to call that webhook URL every time a push happens.

With GitHub and GitLab, this can be done under Settings->Webhooks . Select push events and test it.
Step 4: Profit

That’s it! This should basically work with every CI that has access to your repository and the git Plesk extension.

Happy coding!

Easy Docker LaTeX Setup with vscode and Grammarly

Michael Lohr — Thu, 16 Apr 2020 11:39:46 +0000

Introduction

LaTeX is a document preparation system, which enables to produce .pdf documents from text and commands for formatting. I use it to write academic research papers and other documents, like my résumé.

I wanted an easy setup for an powerful LaTeX environment using an extensible IDE with Grammar.ly integration, running
in Docker so my system stays clean.

Requirements

So the requirements for the setup were:

Works on Windows and Linux
Uses Visual Studio Code (vscode) as editor
Grammar.ly integration
Uses texlive-full together with biber and latexmk
… but without installing them to my system
Should not require more than a few clicks (or commands) to set up

Setup

Thanks to the awesome vscode extension latex-workshop, which recently added Docker support, this was quite easy to achieve.

Requirements:

Docker
vscode

Here are the steps:

Install these two vscode extensions: latex-workshop, Grammarly
Set “latex-workshop.docker.enabled”: true in your vscode settings
Build your project with latex workshop

Additional Setup

If you have a Grammarly account, log in by specifying

    "grammarly.username": "your grammarly email",
    "grammarly.password": "your grammarly password",

I also like to add the following configuration values:

    // Grammarly acadmic writing style
    "grammarly.domain": "academic",

    // always open pdf preview in new vscode tab
    "latex-workshop.view.pdf.viewer": "tab",

I also use the vscode Material Icon Theme plugin in my LaTeX projects.
Which vscode plugins do you use in your LaTeX projects?

Have fun!

Create a Digital Sign Using a Raspberry Pi (Automated Setup)

Michael Lohr — Fri, 10 Apr 2020 11:52:05 +0000

Introduction

I was asked to create digital signage using a Raspberry Pi 4, displaying upcoming events of a club based in Munich.

One requirement was, to implement an automated setup so that it can be quickly deployed to new devices.

After a bit of research, I found DietPi which is a lightweight OS based on Debian. DietPi is configured using a config file. In there, system settings can be configured. DietPi will then set up your system on the first run using those settings. It is also possible to automatically launch a Chromium instance on a specific URL after starting up.

Our digital sign is implemented using Vue.js and a simple Bootstrap slider which cycles through images. It is served on a publicly accessible URL.

Configuration

You can adjust the standard Raspberry Pi config file to your needs. In most cases, you want to disable the overscan using disable_overscan=1 and disable the splash screen with disable_splash=1. If you are using a Raspberry Pi 4, you also want to switch to the new graphics driver by setting dtoverlay=vc4-fkms-v3d.

You can create a dietpi-wifi.txt file to specify a WiFi network, the Pi should automatically connect to:

# - Entry 0
#   WiFi SSID (Case Sensitive)
aWIFI_SSID[0]='My Wifi'
#   Key options: If no key (open), leave this blank
aWIFI_KEY[0]=''
#   Available options: NONE (no key/open) | WPA-PSK | WEP | WPA-EAP (then use settings below)
aWIFI_KEYMGR[0]='WPA-PSK'

The most important configuration is done in the dietpi.txt. Here you want to define a static IP, set an SSH server to launch for maintenance, and set the Pi to wait for a network with CONFIG_BOOT_WAIT_FOR_NETWORK=2. To enable the automatic setup, define AUTO_SETUP_AUTOMATED=1, AUTO_SETUP_AUTOSTART_LOGIN_USER=root and AUTO_SETUP_INSTALL_SOFTWARE_ID=113 (the 113 instructs DietPi to install chromium, see here). Chromium will be automatically launched in kiosk mode by setting AUTO_SETUP_AUTOSTART_TARGET_INDEX=11.

Then configure chromium. E.g.:

SOFTWARE_CHROMIUM_RES_X=1920
SOFTWARE_CHROMIUM_RES_Y=1080
SOFTWARE_CHROMIUM_AUTOSTART_URL=https://google.de

Custom Automation Script

You can also define a script that runs once at the setup. This is useful if you want to pass custom arguments to the chromium executable and handle other logic as automatically turning off the display during night time.

To be able to use a custom script, set AUTO_SETUP_AUTOSTART_TARGET_INDEX=7 and AUTO_SETUP_CUSTOM_SCRIPT_EXEC=0.

Then create a new shell script called Automation_Custom_Script.sh.
Add the following to that script to automatically run a script during startup:

echo -e "if [[ \"$(tty)\" = \"/dev/tty1\" ]]; then
  . /root/startup.sh
fi
" > /root/.bashrc

echo -e "# turn off screensaver
xset -dpms
xset s off
xset s noblank

# Resolution to use for kiosk mode, should ideally match current system resolution
RES_X=$(grep -m1 '^[[:blank:]]*SOFTWARE_CHROMIUM_RES_X=' /DietPi/dietpi.txt | sed 's/^[^=]*=//')
RES_Y=$(grep -m1 '^[[:blank:]]*SOFTWARE_CHROMIUM_RES_Y=' /DietPi/dietpi.txt | sed 's/^[^=]*=//')

# URL
URL=$(grep -m1 '^[[:blank:]]*SOFTWARE_CHROMIUM_AUTOSTART_URL=' /DietPi/dietpi.txt | sed 's/^[^=]*=//')

# Chromiom args
CHROMIUM_OPTS=\" --no-sandbox --homepage \$URL --app --start-fullscreen --check-for-update-interval=604800 --window-size=\$RES_X,\$RES_Y --app-window-size=\$RES_X,\$RES_Y --window-position=0,0 --incognito --noerrdialogs --disable-infobars \"

# Chromium binary
FP_CHROMIUM=\"$(command -v chromium-browser)\"

xinit \$FP_CHROMIUM \$CHROMIUM_OPTS -- -nocursor
" > /root/startup.sh

These commands will also create the custom startup script, which will disable the screensaver and run Chromium on the URL specified in the dietpi.txt as before. The chromium arguments will launch chromium in fullscreen app mode and block any messages from appearing.

Turn the Screen off During Nighttime

To turn the screen off during certain times, add and adjust the following to the Automation_Custom_Script.sh:

echo "0 1 * * * root DISPLAY=:0 xset dpms force off
55 7 * * * root DISPLAY=:0 xset dpms force on
" >> /etc/crontab

Install the Raspberry Pi

So lets set up the Raspberry Pi:

Prepare the SD card

Download the DietPi image
Unzip the image
Insert SD card
Use balenaEtcher to patch the image onto the SD card.
A) Put the config.txt, dietpi.txt, dietpi-wifi.txt and Automation_Custom_Script.sh in the root (/) folder on the SD card. You might want to modify dietpi-wifi.txt, to adjust the WiFi credentials.

Setup

Safely eject the SD card and put it in the Raspberry Pi
Plug all your cables into the Raspberry Pi (making sure the power cable is last).
Let the setup run. You have to interact once and accept software terms by pressing enter. The website should open after the setup finished.

Two Helpful Tools to Automate Your Windows Setup

Michael Lohr — Fri, 10 Apr 2020 09:27:31 +0000

I like to have the same configuration & software on all my systems. I also do not want to spend hours on my setup, while resetting my machine or setting up a new one. With Linux, this has always been pretty easy: Just put your dotfiles on a git repo and clone them when you set up a new machine.

Microsoft is currently working on enhancing the development experience on Windows. They are actively working on a new terminal emulator, a window manager, a way to use Linux on your Windows machine and more.

Two years ago they started working on a collection of scripts, to get a new development machine ready with just one click. They have scripts to set up a WSL/Hyper-V, Docker/Kubernetes, NodeJS, Machine Learning, C++ desktop app or Web stack development environment. While those are great, you can also use them as inspiration to create your own collection of scripts.

We need two tools for our automated setup:

Chocolatey: A package manager for Windows (like apt-get for Linux), which can install most software with just a command
Boxstarter: A tool to automate the configuration of Windows settings and installation of Chocolatey packages.

I recommend you to copy one of the scripts from Microsoft's collection and adjust it to your needs.

You can install packages using Chocolatey like so:

Fing your package on the online database
Add the following to your Boxstarter script or open a Powershell terminal with admin privileges and execute: choco install <package name> -y

You can change your Windows settings by executing Boxstarter scripts like so:

Have a look at the Boxstarter repository and find a script you want to use.
Add the script to your Boxstarter setup script or open a Powershell terminal with admin privileges and execute it. For example: Set-TaskbarOptions -AlwaysShowIconsOn

You then can use your script to build a one-click-package by appending your public script/repo/gist to a URL, like so: http://boxstarter.org/package/url?https://raw.githubusercontent.com/GITHUB_DOMAIN/GITHUB_REPO/YOUR_BRANCH/RECIPE_NAME.ps1

Smartphone-Assisted Virtual Reality

Michael Lohr — Thu, 09 Apr 2020 15:21:51 +0000

Smartphone-Assisted Virtual Reality

Photo by Lux Interaction on Unsplash

To conclude my bachelor in computer science, I wrote my thesis about using a Smartphone as an interaction device for Virtual Reality. This article is basically a summary of my thesis as a blog. Enjoy!

Introduction

Virtual Reality is an emerging medium that enables presence and interactivity in a three-dimensional space. Conventional input devices like a mouse or a keyboard are made for two-dimensional environments. They require complex movements to complete tasks in a three-dimensional environment.

VR controllers by L. Yang on Steam Community

This is why a variety of different input devices, specially made for Virtual Reality, exist. But most of them are expensive and need complex tracking systems.

Most people already own a smartphone that they use on a daily basis. Such phones have a variety of different sensors already built-in, feature wireless capabilities, and are able to run custom software. This makes them affordable general-purpose devices.

Experiments

Screenshot of the laser pointer experiment

Three experiments were implemented to demonstrate how the smartphone can help with common interactions when using Virtual Reality applications:

Model Viewer: An application to view and rotate three-dimensional models. The rotation of the 3D model displayed in VR is synchronized with the Smartphone. To rotate the model, the phone has to be rotated in the wanted direction.

Laser Pointer: A method to select objects or UI elements. A virtual representation of the Smartphone is shown in VR. The rotation is again synced with the real Smartphone. Out of the front of the phone comes a red line (the "laser") which is used to point at user interface (UI) elements.

Virtual Keyboard: An application to write text on a virtual keyboard. The virtual keyboard is shown in VR. The buttons on it are mapped to the Smartphones's touch screen. A blue circle is used to see where the location, touched on the display, maps to the keyboard in VR.

Implementation

To get platform independence, I decided to use a web-based stack. All experiments were implemented in WebVR using Three.js and Javascript.

The networking framework Ubi-Interact, developed at my university, is used to make the proposed experiments reusable and abstracted from device-specific environments. It connects the PC, running the VR experience, and the Smartphone together. Most of the experiment-specific interaction logic is abstracted into so-called “Ubii Interactions”, which run on a server.

The client running on the Smartphone was also developed using Javascript.

Evaluation

Screenshot of the virtual keyboard experiment

In order to test the usability of the smartphone as an assistant device for VR, a user study was conducted. In the study, participants had to complete tasks with the three experiments. Also, a System Usability Scale (SUS) user study was performed to get feedback from the users.

A SUS questionnaire asks the participants to rate the following statements regarding the usability of a system from one to five:

I think that I would like to use this system frequently.

I found the system unnecessarily complex.

I thought the system was easy to use.

I think that I would need the support of a technical person to be able to use this system.

I found the various functions in this system were well integrated.

I thought there was too much inconsistency in this system.

I would imagine that most people would learn to use this system very quickly.

I found the system very cumbersome to use.

I felt very confident using the system.

I needed to learn a lot of things before I could get going with this system.

To sum up:

Model Viewer: Most participants agreed that this input method is very intuitive and effective to operate.

Laser Pointer: This experiment scored the highest amongst the ones presented in this research.

Virtual Keyboard: While the model viewer and the laser pointer scenario reached a very high score, the virtual keyboard scored slightly lower but still demonstrates high usability despite its complexity.

Conclusion

A lot of feedback was collected during the user study, which can be used to improve these implementations further. Since all experiments are considered “acceptable” according to the System Usability Scale, the Smartphone can indeed be considered a working input device for Virtual Reality.

If you want to read the full thesis, check out this link.

DEV Community: Michael Lohr

After a day of programming in Zig

So what is Zig?

Is it good?

What I dislike about Zig

Why I love Zig

Tooling, Build System & Tests

The Language

Error Handling and Optionals

C Interop

Comptime

Types

Memory Allocation

Cross Compilation

Conclusion

Reverse engineering Microsoft's dev container CLI

How everybody is doing it

How did we figure that out?

But we want multiple containers

Down the rabbit hole...

Making sense of the code

Did we solve it?

The last mystery: .file()

Dev Containers: Open, Develop, Repeat...

Intro

Dev Container Features

Opening dev containers From the CLI

GitHub Codespaces

Closing Thoughts

Making IBANs more memorable

Inspiration

The Theory

How IBANs work

Implementation

Further Considerations

Conclusion

Changing the primary display on Windows by code is easy... right?

The struggle with SSH key management under Linux

SSH keys

ssh-agent

keychain, ssh-find-agent, zsh ssh-agent, bash scripts...

gpg-agent to the rescue

Conclusion

Automatically deploy websites to Plesk using GitHub Actions or GitLab CI

Step 1: Modify your CI

Instructions: GitHub

Instructions: GitLab

Step 2: Create website in Plesk

Step 3: Configure the webhook

Easy Docker LaTeX Setup with vscode and Grammarly

Introduction

Requirements

Setup

Additional Setup

Create a Digital Sign Using a Raspberry Pi (Automated Setup)

Introduction

Configuration

Custom Automation Script

Turn the Screen off During Nighttime

Install the Raspberry Pi

Prepare the SD card

Setup

Two Helpful Tools to Automate Your Windows Setup

Smartphone-Assisted Virtual Reality

Smartphone-Assisted Virtual Reality

Introduction

Experiments

Implementation

Evaluation

To sum up:

Conclusion

The last mystery: `.file()`