Numenera (2017) by Monte Cook

Uhrwerk Verlag

This was the first time I've read a role playing game's source and rulebook from the first page to the last. I really love the premise of the universe with those many fallen civilizations leading to a world in a medieval-like state with remnants of the past scattered everywhere. It's interesting to imagine people living there who simply can't make sense of what's all around them and still live their lives as best they can.

That said about the premise I found the world as developed in the book a bit underwhelming. It presents a nice, imaginative subject, but then every boring RPG trope in existence is stamped carelessly on it. I think there was a big chance to create something truely amazing they missed there.

The rules are okay I guess. I haven't actually played it yet except for the amazing video game - Torment: Tides of Numenera. So I can't really judge this. They tell you in the book many times that the emphasis is clearly on the role playing part instead of following each rule application meticulously.

One thing I find difficult to imagine it that they tell you, as a game manager to give lots of items and time-limited abilities to the players. Wouldn't that theoretically make a character quite "unstable" - I mean wouldn't that mean that the characters play differently every other session and that the individual character development wouldn't mean a whole lot? I expect this would also lead to characters with unpredictable strength - that again would make it hard to lead a game.

The art in the book was solid and mostly fitting to the setting. I often had the impression that someone had made a great drawing and then an author wrote an unimaginative scenario into it.

Flow - The Psychology of Optimal Experience (1990) by Mikaly Czikszentmihalyi

Harper Perennial

I can only recommend reading this book. It describes the state in which you can enjoy the things you do moment-to-moment and give meaning to your whole life. The mindset and the environment that is necessary to reach this state are explained very well here by using a digestible language for the psychological concepts at play.

In my experience most of those guidebooks only "help" those that already do what is being recommended in them. But here I think you can actually get some input for how to make your life more enjoyable - if only in some situations.

Maria Stuart - Ein Trauerspiel (1800) by Friedrich Schiller

Reclam Universalbibliothek (Nr. 64)

The story dates back to a time when intrigue, betrayal and murdering your opponents was still the domain of the monarchy and not of dictators and despots. In general, the play was a good read. I like how those old plays sometimes let you dive into the past in two stages: A person from 200 years ago tells with his play a story from yet again more than 100 years earlier.

Gauntlgrym - Niewinter - Band 1 (2010) by R. A. Salvatore

Blavalent (Nr. 26851)

A novel in the Dungeons & Dragons universe. As far as I know the books by R. A. Salvatore are highly praised and I agree that this story is intriguing enough to keep on reading. But what put me off at times, however, was the large amount of detailed description of intense violence. In contrast to that was the oversexualization of some characters in descriptions and acting. I guess this is the legacy of old RPG times. I could do without that.

Also, there were so many characters with fantasy names that I actually had to make a cheat sheet of them and their role in the story.

Führer durch die Ausgrabungsstätten in Ostia Antica mit einem Abschnitt über das Renaissance-Dorf (2000) by Sonia Gallico

ATS Italia Editrice

I visited the ruins of Ostia Antica in 2009, but arrived there late in the afternoon and only had a short rush through the remains of the old roman town. By chance I found this guidebook and could in retrospect understand and appreciate what I had actually seen there more than a decade ago. It was interesting to follow the rise and fall of such a big town and read about what kind of society lived there.

Draussen vor der Tür (1946) by Wolfgang Borchert

Rowohlt Taschenbuch Verlag (Nr. 22509)

After a few pages of reading through this play's script I realized that I had already read it some years ago. Still, I kept reading because of the strange language and the strange characters, for example the talking river Elbe or the "Other one" or Death himself with a hiccup. It paints a painful image of the period after the war. And that made a big impression on me.

The subtext reads: A play that no theatre wants to play and no audience wants to see. But here I think it's not about wanting to be confronted with it, but about having to be confronted with it.

Prinz Friedrich von Homburg (1810) by Heinrich von Kleist

Reclam Universalbibliothek (Nr. 178)

An old play about a 100 year old story - again. This was strange in that the protagonist was very unlikable and even though it read like a typical drama it had an unexpected happy ending. I didn't like it too much.

Der Gefangene des Himmels (2011, English: The Prisoner of Heaven) by Carlos Ruiz Zafón

Fischer Verlag (Nr. 19585)

The final piece of his Barcelone trilogy. And again as thrilling and bitter as the other novels. Zafón manages to create characters that keep you interested in but also those that disgust you to the bones. Unfortunately as it was so long since I've read the other two books I didn't remember many of the connections and only vaguely got the revelations concerning past story threads. What bothered me were the sexual references in every other paragraph especially in the beginning - this didn't really serve the story or the characters.

I think he wanted to end the reading experience of the trilogy on a positive note. That means in the final quarter of the book everything starts to just work out fine. I can understand this and don't want to criticise a few positive chapters but this shift in tone was kind of obvious. Maybe this could have been written better.

pong.mythos (2006) by Andreas Lange

Förderverein für Jugend und Sozialarbeit

This is actually a booklet to an exposition about the video game Pong. It describes the context in which the game was created, both from a historical and technical point of view and shows how it has since been taken up in media and arts. In short: How it has become a myth.

Most fascinating to me was how imaginative the processing of the theme Pong was in the arts. This was quite inspiring.

Samarkand (2001) by Olga Kharitidi

List Taschenbuch (Nr. 60855)

It's hard for me to read this as a literal, biographical text because the mysticism described is a bit too unbelievable. But it was interesting in itself to delve into the history, culture, myths and legends of Uzbekistan.

To the Lighthouse (1927) by Virginia Woolf

Wordsworth Classic

The struggle of the Ramsey family. This story's atmosphere is just pitch black and most depressing. I think this is linguistically the most difficult English book I've ever read. Adding to this its unconventional style, I had at times now clue what a paragraph was about. Still it was a worthwhile experience for me.

Der Fliegende Holländer (1841) by Richard Wagner

Reclam Universalbibliothek (Nr. 5635)

How does one come up with the idea of reading the script of an opera? - Yes!

Nothing much to say here - it takes 20 minutes to read something that singers and an orchestra would spend more than 2 hours on. Afterwards I found this recording of a modern adaptation, performed at the Bayreuther Festspiele 2021.

Harry Potter and the Deathly Hallows (2007) by J. K. Rowling

Bloomsbury Children's Books

I'm finally through with the series. As with all the previous stories this one kept me reading chapter after chapter. Some new story lines emerged in this entry that wouldn't have felt a bit disconnected if they had been hinted at earlier in the series. I mean especially the whole backstory of Dumbledor.

There is one pattern that repeats itself throughout the book: The protagonists don't know what to do, then out of desperation they do something reckless, get into trouble, barely manage to get to safety again and have not made any progress at all. But I guess this is how you fullfil a prophecy.

I think one can see that it's the book to wrap things up and it does so quite well.

Emilia Galotti (1772) by Gotthold Ephraim Lessing

Reclam Universalbibliothek (Nr. 45)

Nothing too special about this play. It's the oldest work I've read in 2023 and it's also the shortest in scope - everything happens in just one day. The story is more exciting than I initially expected.

GEO Epoche - Irland (2018) by Michael Schaper

Gruner + Jahr Verlag

A magazine with articles about the history of Ireland from the 12th century until now. And that is not a pleasant history - war, civil war, colonized, mass emigration, famine, religious murders, terrorism, rebellions and so one. And they didn't even know about the final vote on Brexit when this was published.

The articles are written in varied ways and kept me interested from start to finish. This is how I like my history lessons.

In the past few month I got very enthusiastic about AI image generation. craiyon.com and dream.ai were a source of many hours of entertainment trying to get the model to produce images I find interesting, funny or useful as inspiration.

But all those amazing tools run on servers hosted by other people and given that we are in kind of a wild west gold rush period of AI generation those services might vanish every other day. The reasons might be financial issues, merging, updating (I really didn't like the results of craiyon's v2 model at first), personal or legal reasons (I wonder how long it will take until we have decided what copyright has to say about those creations).

Setting up stable diffusion on my own machine or training such models on my own seemed a bit intimidating und looking for something lighter (from a complete novice's point of view) I got the idea to try depth estimation of existing images.

The very first search result pointed me to MiDaS.

And it initially checked some of my boxes:

• It says that it actually solves my self-imposed task.
• It is kind of recent (January 2023) but also has some iterations that brought it to version 3.1.
• And finally, it comes with a Dockerfile that should make it trivial to set up using Docker.

So here I go. Following the README instructions I build the Docker image:

docker build -t midas .

First setback: The Dockerfile is based on the nvidia/cuda:10.2-cudnn7-runtime-ubuntu18.04 image (Ubuntu 18 is quite old, isn't it?) and the very first apt installation attempt triggers an error:

The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A4B469963BF863CC

Some research pointed me to the fix that made the image build successfully:

[...]
apt-key del 7fa2af80 \
&& apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/3bf863cc.pub \
&& apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/7fa2af80.pub \
[...]

Let's move on and get MiDaS to do some work. I download the medium-sized model "dpt_swin2_large_384" (800MB) into the weights/ directory, place some images into the input/ folder and follow the run instructions:

docker run --rm --gpus all -v $PWD/input:/opt/MiDaS/input -v $PWD/output:/opt/MiDaS/output -v $PWD/weights:/opt/MiDaS/weights midas

Unfortunatelly instead of nice depth maps I get:

docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].

Turned out I neither had the NVidia container runtime installed nor CUDA. Though one year ago when it was time for a new laptop I consciously chose to buy one with a dedicated GPU because "this AI stuff will be the future and sure it will require a good GPU for computation", but until now I didn't get to actually use this piece of hardware.

So on Archlinux I had to install the following packages:

• cuda-12.1.0-1
• libnvidia-container-1.12.0-1
• libnvidia-container-tools-1.12.0-1
• nvidia-container-toolkit-1.12.0-2

And as was to be expected I was greeted with the next stage of error messages instead of some greyscale images:

NVIDIA GeForce RTX 3060 Laptop GPU with CUDA capability sm_86 is not compatible with the current PyTorch installation.
The current PyTorch install supports CUDA capabilities sm_37 sm_50 sm_60 sm_70.

The NVIDIA GeForce RTX 3060 is not supported by PyTorch? How can this be? The catch here is that the Dockerfile is based on an Ubuntu 18 distribution that in turn brings along Python 3.6 that in turn doesn't run the lattest version of PyTorch which means that it can only use CUDA on older GPUs.

Wondering how it comes that a project implementing a technology described in a paper from 2022 bases its Docker infrastructure on an operating system from 2018 I was astonished to find out that this project actually started in 2019 and added a Dockerfile in 2020. That makes sense than.

At this point my options were to base the image onto a newer version of the nvidia/cuda image - which from my experience would trigger a waterfall of changes down the Dockerfile - or roll without GPU support - in the end my CPU should be capable to process at least some small images.

I decided to go without GPU support for now.

Segmentation fault (core dumped)

That's getting annoying. To cut this episode short and don't bother you with my attempts to debug this Python script: The culprit was a picture containing an Umlaut character ("ü") in its filename within the images I had randomly chosen from my collection. Somehow that caused the script to segfault.

Rename. Run. And finally the first result:

docker run --rm -v $PWD/input:/opt/MiDaS/input -v $PWD/output:/opt/MiDaS/output -v $PWD/weights:/opt/MiDaS/weights midas

My first successfully created depth estimation using the small model "dpt_swin2_tiny_256.pt".

Here we have it. The model got a 2D flat image as input and was able to decide which pixel in this image represents something that was closer to the camera and which ones are further away. Something we as humans are quite capable of. But computer vision until recently had to rely on the same techniques that a person uses: But instead of two eyes it needed two images - see photogrammetry.

The result from MiDaS above is not very sharp but we can clearly see and distinguish people and objects. Though it lacks some finer granularity at some objects there are no real errors in the estimation. In the worst case objects are placed on the same depth plane that are actually a bit in front or back. Beforehand I didn't know what to expect so judging if this was a good result or not was beyond me. Still I was happy to have gotten it to work in the end. (Will an AI model ever be "intelligent" enough to decide from whom it doesn't want to be used?)

The thing is slow. On my CPU it takes around 5 seconds for an image with 500px on the shorter side. If I let MiDaS do the shrinking and upscaling afterwards of a normal sized image it takes around 30 seconds. I hope that one day I will be able to see how much faster the GPU will do the processing.

But now it's time for experimentation. I downloaded a smaller ("dpt_swin2_tiny_256.pt" - 172MB) and the largest ("dpt_beit_large_512.pt" - 1.6GB) model, collected a new batch of different images I deemed should be interesting tests for this kind of processing and let it calculate. Here I want to present to you some of the more interesting finds.

Switching to the largest model ("dpt_beit_large_512.pt") the results are actually quite impressive. The outlines of people work very well in general.

This was a tough one.

I did not expect this dark pictures to work out so well.

The interesting thing here is that even though the actual picture is surrounded by an unvarying color, the model interprets it as closer to the camera in the bottom half.

Let's see how the model handles paintings.

Leonardo da Vinci's Mona Lisa

Edward Hopper's Nighthawks

Franz Marc's Füchse

Maja Wrońska's Colorado Springs

Even the results for the abstract painting by Franz Marc and the painting by Maja Wrońska with a lot of white space are looking quite reasonable.

All in all I'm very happy and impressed with the results even though I had hoped that the technical setup to achieve this was more straight forward.

A short last note: The image processing exports next to the PNG result file a monochrome PFM image file. This is a very simple encoding that supports floating-point number color precision. So you can have an even higher depth resolution when you are using this file. You can read more about the file format at https://www.pauldebevec.com/Research/HDR/PFM/. Gimp and GThumb were not able to display those images out of the box - but than how should they on an 24bit RGB display?

I inherited some legacy Python code that sends emails the following way (code simplified):

message = MIMEMultipart()
message["From"] = email_from
message["To"] = email_to
message["Subject"] = email_subject

message.attach(MIMEText(email_msg, "plain"))
context = ssl.create_default_context()

with smtplib.SMTP(os.getenv("SMTP_HOST"), os.getenv("SMTP_PORT")) as server:
    server.ehlo()
    server.starttls(context=context)
    server.ehlo()
    server.login(os.getenv("SMTP_USER"), os.getenv("SMTP_PASSWORD"))
    server.sendmail(email_from, email_to, message.as_string())
    server.quit()

I wanted to run and test this code without modifying it at this point and without using the actual mail server. That's why I set off to find some locally runnable email server solutions that fit well within the docker-compose stack I was already using.

The most promising servers I found were the following:

• maildev/maildev (previously known as djfarrelly/maildev) and
• mailhog/MailHog

Both come with convenient Docker images that run out of the box and have documentation for the most important configurations. They also feature nice web front ends to view the received emails that don't differ that much on first sight and the REST-API to request this data has all the needed information.

In the end I settled on MailHog as it had the most recent stable version (summer 2020 vs. summer 2019).

Unfortunately what both servers also have in common is that they don't support SSH and STARTTLS that I need to use as you can see from the code snippet above. Both have feature requests in their repositories about this functionality but there seems to be no activity in this regard. Browsing through those tickets I stumbled about recommendations to use a reverse proxy to work around this problem and there was one specific mention of Simple Mail Forwarder and I decided to give it a try.

Though I take security very seriously it is not my strongest subject and I'm always happy if solutions exist that set things up securely by default and provide the needed documentation to fill the gaps as needed.

In this case I had to bite my way through it and probably spent way too much time on it. In the end I got it working and here I want to protocol how I got there.

Getting the MailHog container running

This step is fairly easy: Add this to your services inside docker-compose.yml and define the environment variables in your .env file:

email_test_server:
  container_name: ${COMPOSE_PROJECT_NAME}_email_test_server
  image: mailhog/mailhog:v1.0.1
  ports:
    - ${PUBLISH_PORT_EMAIL_TEST_SERVER_FRONTEND}:8025
  networks:
    - default

It actually exposes the ports 8025 (web interface over HTTP) and 1025 (SMTP server). As I only need to access the later from within the container network I didn't forward it in the ports section. Otherwise I didn't need to change much and am immediately able to access the front end and the API that are both unsecured.

Creating the glue

The next step is to get the Simple Mail Forwarder (SMF) to work and now it's getting interesting. I made this iteratively as I was unsure how the certificate generation would work. So I started it up with the following setup:

email_test_forwarder:
  container_name: ${COMPOSE_PROJECT_NAME}_email_test_forwarder
  image: zixia/simple-mail-forwarder:1.4
  depends_on:
    - email_test_server
  environment:
    SMF_DOMAIN: email_test_forwarder
    SMF_CONFIG: "@email_test_forwarder:to@email_test_server:testPw"
    SMF_RELAYHOST: email_test_server:1025
    TZ: Europe/Berlin
  networks:
    - default

This creates the SMTP user @email_test_forwarder with password testPw and forwards every message received that is directed to the @email_test_forwarder domain to to@email_test_server. During the setup process SMF complains about the domain names without a top level domain. This might be solved by using something like @email_test_forwarder.local but I didn't try it out as it worked anyway.

SFM takes care of generating self-signed certificates for you if don't provide it some yourself. The important thing here is setting SMF_DOMAIN correctly.

When you run this image in your container it works well. But when I ran the Python code to connect to the server I got the following error message:

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:1091)

That's reasonable: By default Python doesn't want to connect to a server using a self-signed certificate. So I need to install it in the Python container.

For figuring out what to do next executing the following command from within the Python container was helpful:

openssl s_client -starttls smtp -connect HOST_EMAIL:SECURE_PORT

or in my case:
openssl s_client -starttls smtp -connect email_test_forwarder:25

It returns among other things the server certificate. I identified this certificate as the one generated as /etc/postfix/cert/smtp.ec.cert inside the email_test_forwarder container. To share this file easily I pulled it out from the forwarder container and saved it (and smtp.cert) in a new data/smtp_test_cert/ directory.

Now to reuse those saved certificates I based a simple Dockerfile on the original one and copied those files over:

FROM zixia/simple-mail-forwarder:1.4

COPY data/smtp_test_cert/* /etc/postfix/cert/

Additionally I changed the section in my docker-compose.yml:

email_test_forwarder:
  container_name: ${COMPOSE_PROJECT_NAME}_email_test_forwarder
  build:
    dockerfile: email_test_forwarder/Dockerfile
  depends_on:
    - email_test_server
  environment:
    SMF_DOMAIN: email_test_forwarder
    SMF_CONFIG: "@email_test_forwarder:to@email_test_server:testPw"
    SMF_RELAYHOST: email_test_server:1025
    TZ: Europe/Berlin
  networks:
    - default

Adjusting the Python container

At last I have to install those certificates in my Python docker container. This can be achieved by a small addition to the respective Dockerfile:

FROM python:3.7

[...]
COPY data/smtp_test_cert/*.cert /etc/ssl/certs/
RUN  ln -s /etc/ssl/certs/smtp.ec.cert /etc/ssl/certs/36cc48aa.0
[...]

The hash that needs to be used for the link (in this case 36cc48aa.0) can be found by executing the following command and appending ".0" to it.

openssl x509 -noout -hash -in /etc/ssl/certs/smtp.ec.cert

The only thing that is left to do is configuring the SMTP connection with the following values:

SMTP_HOST=email_test_forwarder
SMTP_PORT=25

# for user info see SMF_CONFIG in docker-compose.yml
SMTP_USER=@email_test_forwarder
SMTP_PASSWORD=testPw

SMTP_FROM=zzz@email_test_forwarder

Now I can test the application without having to worry about external mail servers.

A while ago I had to fit a string into a navigation menu column and didn't want to make it any wider than it already was. In my case a font size of 14px was too high while 13px felt like it was harming the readability. Testing with 13.5px I felt like I had found the sweet spot. But as I had never seen a fractional font size in style sheets before I wondered if this was allowed and supported. My coworker wasn't able to give me an advise and on StackOverflow the related discussions questioned how one should be able to render a fractional font size on an absolute pixel.

But subpixel rendering is a tried and tested technology for at least 20 years. We even have algorithms that leverage the positions of the individual red, green and blue pixel parts of specific displays. Something you will see in most of the examples below.

Surprisingly the official documents don't provide any specific's either. See https://www.w3.org/TR/CSS1/#length-units.

So when no information can be found. Let's actually test it out.

The test subjects

• Firefox (76.0.1)
• Chromium (83.0.4103.61)
• Microsoft Edge (44.18362.449.0 - not Chrome based)
• Microsoft Internet Explorer 11 (11.900.18362.0)
• Opera (68.0.3618.125 - uses the same renderer as Chromium)

The test

I put 3 div elements on top of each other with font sizes 13, 13.5 and 14 px respectively and made screenshots in all browsers.

<div style="font-size:13.5px;">
    ÈÇ - Text with font size 13.5px
</div>

The font I used is Open Sans loaded as a TTF resource.

Here you can see how this looks like:

divs rendered by your browser:

ÈÇ - Text with font size 13px

ÈÇ - Text with font size 13.5px

ÈÇ - Text with font size 14px

Image (Chromium):

Vertical comparison

2x zoom:

So putting all screenshots next to each other makes some things evident:

• Fractional font-sizes do actually work in all tested browsers.
• There are rendering differences between all browsers. At least between Chromium and Edge the div borders and the font base lines align.
• IE 11 only uses anti-aliasing (grey-scale) to have smooth lines while all other renderer use an RGB value on the neighbouring pixels to trigger individual color subpixels of your display (see ClearType or FreeType). You will notice the orange shadow left of a darker pixel and blue shadow to the right.
• div borders always align with a full pixel.

For a better comparison of the font sizes I aligned all base lines in the next image.

2x zoom:

As you can see the x-height and cap height are consistent for 13px font size between all browsers (with sub- and superscript it takes 15px).

At 13.5px the first differences occur. Caps heights (and overall height) in Edge and IE 11 are one pixel larger than those in Firefox and Chromium.

At 14px the caps heights align again between browsers. But now the overall height of the characters in Edge and IE 11 is 2 pixels lower.

Horizontal comparison

Those are the texts with font size 13.5px aligned for text length comparison.

2x zoom:

Because of the subpixel rendering it's not trivial to align the texts. But it can be seen that the variance in length between those texts lies at 1px for a 190px text which I would consider nearly identical.

Verdict

The major browsers I tested did a good job in rendering texts with fractional font sizes, even though I couldn't find any official or in-official recommendations concerning the usage of those. But as fractional em value would often lead to a fractional font-size too, I don't see how this is not a viable way to style your texts.

The CSS box model sticks to integer values even if it includes fractional font sized text. I guess this prevents some lay-outing nightmares.