One of the limitations of such a system is user authentication. Each user needs to send a password alongside each comment that serves to authenticate the user against their email. This is needed because email spoofing is a thing and identity theft is not a joke; even if the stakes are low in the context of blog comments.

In that previous post, I acknowledged that sending a password in plain text via email is not best practice and I encouraged the usage of encryption. For this purpose, I provided a public PGP key that can be used to encrypt any email and can only be decrypted by me, the owner of the secret key.

Problem

The problem with this suggestion is that, even though it’s technically sound and legitimate, it is not straightforward to set up. Many email clients do not even support PGP encryption and, dare I say, even most technical people do not have it set up by default. For non-technical users, configuring everything properly would certainly be a test of computer literacy.

This is not good enough, and certainly not welcoming or inclusive.

Solution

Shortly after I published the first version of the comment system I came up with a question.

I already have a public PGP key published and ready to be used. Is there a way to encrypt the comment payload on the browser, including the password and all other data?

I wouldn’t be writing this post if the answer was negative.

After a quick web search, I came across openPGP.js, a JavaScript library maintained by the Proton team. The goal of the library is to “bypass the PGP installation requirement in every machine”. Just perfect for my use case.

I quickly set everything up. I downloaded the JavaScript library files at the root of my website and created a couple of helper functions. The first to load the library on-demand to avoid unnecessary network transactions and the second to produce a PGP encrypted message from a plain text string input.

function loadScript(src) {
    return new Promise((resolve, reject) => {
        // Prevent loading the same script twice
        if (document.querySelector(`script[src="${src}"]`)) {
            resolve();
            return;
        }

        const script = document.createElement('script');
        script.src = src;
        script.async = true;
        script.onload = resolve;
        script.onerror = reject;
        document.head.appendChild(script);
    });
}

async function encrypt(message) {
    const publicKeyArmored = `{% include pgp-public-key.txt %}`.trim();

    await loadScript('/openpgp.min.js');

    return await window.openpgp.encrypt({
        message: await openpgp.createMessage({ text: message }),
        encryptionKeys: await window.openpgp.readKey({ armoredKey: publicKeyArmored })
    });
}

It’s simple. And it works.

Note: The comment encryption functionality is not available if JavaScript is disabled on the client.

For example, if you were to write a comment for this post using the comment form and provided the following data:

username: test_user
password: test_password
comment: Test comment.

the email to be sent would be pre-filled with the following body:

Your comment has been encrypted and is ready to be submitted.
...

-----BEGIN PGP MESSAGE-----

wV4Dyk92dA2JWC4SAQdAFgNHlb6Q7nAgovzVgUnB5CTOKBWSlXxSoIOzLUQl
Zm4wBdsLdUROxNS0xcTyja4iq9QUsSazv18DYbmRd2Lix3XoL4zDrQVOPVw6
ZGlkeDhi0qEByCityS59xWSuREVqgS4tpPlZg8Lz5Go6D2nSBu+1iTXw2dy6
L9eL5NZMoFhYUqocGukxBlEcHY6j1U+3Lstvc5dZPl+u7+Zh32uTzTo8CC05
doKNwH5AP9ybHk7nr2vVLdrede6vLCIAwGTK9fVYq2V1udXfSPNCESSeunh1
68qEaAA81mjCbSSfcB/RznpL8/nOLLWDXlXxfMPlYV8/+Q==
=k2VX
-----END PGP MESSAGE-----

Your comment data (username, password, message, etc.) is automatically encrypted without any need for manual intervention.

Conclusion

Based on the above proof of concept, I can say that, even without operating a “proper” backend server, it is still possible to guarantee a reasonable level of security. And you can do so without requiring any complicated setup on the user side.

To my eyes, this is a win for secure communication when email is used as the medium. Do you agree?

Despite the abundance of such spaces, where discussions can happen, I think it is convenient and fitting — especially for blog posts — when the actual post and the readers’ comments live together.

With that in mind, and feeling the urge to hack a little more on my website, during the past weekend I set out to add support for comments in this blog.

Doing so in a static blog poses a big challenge. There is no actual server running that can handle requests and process data. That means that you do not have the necessary infrastructure for user accounts. The readers cannot log in and send their comments and there is no straightforward way to take those comments and automatically post them online.

Another method is therefore needed to receive the comments and provide them as input to the static site generator, in my case jekyll.

One of the most frequently used solutions to this problem is giscus. giscus is utilizing GitHub discussions to store comments for the different blog posts and can be configured to automatically update your website when a new comment is created.

This approach is very appealing, but it has one disadvantage in my opinion. The person who wants to comment needs to have a GitHub account. This can be a blocker for non-technical people.

I wanted to use a different approach and I also wanted to make commenting accessible to as many people as possible. After some thinking I decided to use the most common technology I could think of.

Email.

Almost everyone using the internet has an email address. By basing my comment system on email, I can make it accessible to a wide range of people.

The fact that every email address is unique allows to implement a kind of primitive authentication setup. I am saying primitive, because email is not secure by default, and by extension neither is any system built on top of it.

It goes without saying that this system could never be used in production in security-sensitive environments. That said, crazier things have happened.

Technical overview

At this point, it would be useful to go in a little more detail. If you are not interested in the technical aspects of the comment system implementation you can skip this section and go straight to the end. You will miss all the fun, though.

So, how does it all work?

Requirements

Before implementing the comment system, I drafted some requirements:

1. All comments should be displayed with a visible name³ selected by the commenter and the date they were made.
2. A commenter should be able to change their visible name.
3. A malicious actor should not be able⁴ to assume the identity of a commenter.
4. Sending a comment should be as easy as possible and the comment system should be functional with JavaScript disabled.
5. Comment replies should be supported and presented in a nested tree structure, which should support collapse and expansion of comment sub-trees.

Data

The comment system is based on email, so it is logical that you send a comment by sending an email. Every comment email contains all necessary information, so that the comment can be presented correctly. I decided to send the information in the YAML format, since jekyll is YAML-friendly. Additionally, YAML compared to JSON can be more readable for multi-line data, like comments, so it made it more fitting for this use case.

Every comment email sends in its body the following information.

post:
name:
password:
repliesTo:
comment: |-

Sending passwords in plain text is almost always frowned upon. But I believe this situation deserves some leeway.

• The data transferred is not sensitive and proper care is taken to ensure confidentiality.
• This is an educational project with no hard security requirements.
• A password is good to be used as a measure against sender address spoofing.
• Email can always be hardened by using PGP encryption⁵:

Upon receiving a comment email, some additional information can be obtained: email_address and date.

Implementation

Let’s see how we can satisfy the system requirements with these data.

All comments should be displayed with a visible name selected by the commenter and the date they were made.

For this we use the name and date information from the actual comment email.

A commenter should be able to change their visible name.
A malicious actor should not be able to easily assume the identity of a commenter.

All information needed to generate this website is publicly stored in a GitHub repository. This means that any personal information needs to be properly stored.

For each received comment email a SHA256 message digest (hash) is computed using the email_address and a salt⁶.

To check name availability, all email hashes that are different from the current one are gathered and their linked name is compared to the requested one. If no matches are found the name can be used.

An additional message digest is computed for the authentication of the commenter using the email_address, the password and the salt.

This authentication hash is compared against the authentication hash of one of previous comment emails that share the same email hash⁷.

In the event of any error, the commenter is informed with a response email.

Sending a comment should be as easy as possible and the comment system should be functional with JavaScript disabled.

Commenters with JavaScript enabled can enjoy a streamlined user experience (UX). Clicking on add comment or reply presents them with an HTML form with three input fields: name, password and comment. After filling them and clicking the send button, their preferred email client is launched and the message is pre-filled for them and ready to be sent.

Commenters with JavaScript disabled still get a pre-filled email message, but they have to fill the necessary information, while making sure to not break the formatting of the data.

Writing a comment using the HTML form with JavaScript enabled has two benefits:

1. Browsers are able to save the name and password fields for the commenter and pre-fill them in the future.
2. The password can be hashed in the email body. This does not improve security, but protects against curious eyes.

Comment replies should be supported and presented in a nested tree structure, which should support collapse and expansion of comment sub-trees.

Using the repliesTo field of the comment email⁸, a tree hierarchy of messages is created. This hierarchy is used to sort the comments properly and to create the necessary logic to collapse and expand the respective sub-trees of comments.

Synchronization

We are close to the end, but I have so far failed to mention one basic characteristic of the comment system. And this concerns its responsiveness, or lack thereof.

After receiving a comment email, there is, as of now, no automation set up to process the email and post it on the blog. Posting each comment requires manual intervention. This makes the discussion asynchronous. I think that this is not a big issue and does not look out of place considering the static nature of the website.

Nevertheless, I leave the door open to automation. Interacting with email is scriptable with programs like msmtp and isync. In the unlikely but welcome scenario that the volume of the received comment emails is too large to handle manually, another weekend hacking project could automate the whole process.

Final thoughts

Creating a comment system based on email has been a worthwhile experience. I revisited some long-studied concepts and learned new ones. It was a good exercise in balancing trade-offs which I believe is one of the most important aspects of designing a system.

The final result leaves me satisfied, while also leaving room for improvements in the future.

And after all this work, I can finally say

Let me know what you think in the comments.

Hacking with technology and procrastination may seem unrelated, but I believe that in tandem they paint an accurate picture of how lots of people, myself included, interact with technology in their free time.

When I am referring to hacking, I intend to convey the original meaning. Wikipedia¹ phrases it quite nicely.

The act of engaging in activities (such as programming or other media) in a spirit of playfulness and exploration is termed hacking. However, the defining characteristic of a hacker is not the activities performed themselves (e.g. programming), but how it is done and whether it is exciting and meaningful.

The key words in the above segment are: playfulness, exploration, excitement, meaningfulness. I will come back to them shortly.

I guess most people are at least vaguely familiar with procrastination. Let’s not mention any definition containing the words laziness or carelessness. I prefer to keep it nice and neutral².

The act of procrastinating; putting off or delaying or deferring an action to a later time.

And if you are interested in the actual etymology, it can get a little more fun³.

From Latin prōcrāstinātiō, from prōcrāstinō (“procrastinate”), from prō + crāstinus (“of tomorrow”), from crās (“tomorrow”).

What is techrastination then? I will try to give a definition of my own.

The act of procrastinating by focusing on the technology associated with an activity rather than focusing on the activity itself.

You may have an idea where I am going with this. I am gonna give some examples anyway.

The first one is quite relevant.

It’s when you spend hours upon hours tinkering with your blog, fixing the theme, checking the fonts, trying to perfect the alignment of CSS elements and the margins of your titles and subtitles, yet you are not working towards creating actual blog posts⁴.

It is also when you constantly rework your configuration files and scripts to increase your productivity, when you are not actually working on something that you need to be productive in.

Or when you are more interested in the technologies you are using – programming language, stack, tools – and you like to engage in heated arguments with people about them, instead of just focusing on the actual target at hand, whatever that may be.

It would be safe to assume that we can think of many more similar examples.

I admit I have been guilty of all these to a lesser or greater degree.

But, is guilty the right word? Should there be a negative tone when we are describing such activity? Shouldn’t we always try to be as productive as possible?

Not really.

Let’s go back to the key words of the hacking definition above.

Playfulness. Play is not just for kids. Having some amount of play in our lives is beneficial to our well-being. This matches my experience while hacking. When friends or family ask me how I find satisfaction from my computer projects, I usually respond that it feels like playing.

Exploration. It is said that repetition is the mother of learning, but I believe that exploration is an equally important part of knowledge acquisition. We don’t have to constantly innovate. But we must test the limits of our knowledge to expand it and savor its benefits in the form of personal and professional growth.

Excitement. Who involved with programming and technology in general has not felt immense satisfaction after completing a task? Or even without completing it. Completing the task is not even a requirement. Being in the flow comes with its own set of satisfying emotions. The actual end product does not hold all value. It may not even be that useful, if we were to strictly evaluate it. But this excitement is very important. It encourages further exploration that leads to more play that leads to more excitement.

Meaningfulness. Now we are entering tricky territory. So far I have argued that engaging in techrastinating activities can be useful without the need to find an actual meaning. That statement does not have to be betrayed. The actual meaning does not derive from the usefulness of an activity. It comes from the effect it has on the acting individual. If an activity satisfies us, then it is meaningful.

All this sounds extremely positive. What about the dark side? I would argue that the dark side is not strictly related to technology activities. Any activity can have a negative impact, when it is exercised without measure and it begins to affect other parts of our life (e.g. relationships or health). A general balance should always be maintained.

To sum it all up, hacking with your computer, or actively engaging with technology in general, does not need to have a purpose. The experience itself can be immensely rewarding and there are real benefits to be had, even if not immediately visible to the naked eye.

Whether the word sticks or not, if I had to give one piece of advice, it would be the following.

Do not worry about the outcome. Techrastinate.

It’s been a while since my last post and I did not want to leave 2025 behind without making any.

During the past year I have been gradually migrating my development and configuration file setup to Nix Home Manager (aka home-manager).

This has not been a quick transition, but I am satisfied with the result and I believe it was worth it.

I note the following benefits:

1. It enables me to handle all changes (program versions and configuration files) from a single directory. A single source of truth that can be easily tracked by git.

2. I am a fan of Nix reproducible environments and builds and I considered using home-manager a nice opportunity to familiarize myself with the language.

3. Nix packages enable me to create a predictable development environment across different machines (e.g. home, work, etc.), irrespective of the underlying operating system and the packages that it provides by default.

I finally finished the migration last month, so I thought it is a good idea to share the interesting bits of my current setup. Maybe someone will find it useful.

I don’t know how many posts I will make about it, but let’s get started.

Template files

When sharing a home-manager configuration between multiple machines, a common scenario is to have a file that needs to be slightly different in each machine.

For example, in my vim configuration, I want to configure the number of async workers that clangd will use when launched by the LSP server. In my laptop which has only 4 cores, I want to use 3 of them. In my work computer that has 20, I want to use more (e.g. 16).

How can we utilize home-manager to automate this customization?

Baseline

This post does not provide an introduction to home-manager. Nevertheless, we need to agree on some necessary baseline knowledge.

home-manager requires a configuration file home.nix that typically lies in the $HOME/.config/home-manager directory. In home.nix we can define the files that are generated via home-manager by populating the home.file¹ attribute set.

{
  pkgs,
  lib,
  ...
}:
{
  # Other home-manager configuration options
  ...

  # Files
  home.file = {
    # Key-value file entries
  };
}

Every “key-value” entry in this attribute set corresponds to a file that we want to generate in our $HOME directory.

For example, if we want to generate the $HOME/.bashrc file, we need to add the corresponding entry in the home.file attribute set.

  ...
  home.file = {
    ".bashrc" = {
      # File options
    };
  };
  ...

The file options attribute set fully configures the generation of each file. This includes the contents, setting the executable bit, any actions to perform when the file changes and more.

This post only deals with the contents of the generated files. For this we have two options:

• the source attribute, which is a Nix path to a file whose content will populate the home-manager generated file

  home.file = {
    ".bashrc" = {
      source = /. + "<absolute-path-to-source-file>";
    };
  };
  

  or

• the text attribute, which is a Nix string defining the content of the home-manager generated file

  home.file = {
    ".bashrc" = {
      text = ''
        # This is the content of the $HOME/.bashrc file.
      '';
    };
  };
  

Implementation

We can create a templating layer on top of home-manager and programmatically generate files with parametrizable content.

How do we do that? We can use a template engine like jinja.

For the purposes of my configuration I am using jinja2-cli, because I want to easily invoke jinja from the command line.

Let’s take it step by step.

1. Decouple templating layer from the actual home.file attribute set.

We create an attribute set that mirrors the structure of the home.file. We do not want to deviate too much from the actual “structure” that home-manager expects, so that the configuration and programming logic is simpler.

  files = {
    ".bashrc" = {};
    ".inputrc" = {};
  };

2. Modify each “key-value” file entry using builtins.mapAttrs².

Currently the values of the file entries are empty. We need to populate these attribute sets, so that they are valid home-manager file entries.

As already mentioned, to set the file content, we need to define either the source or the text attribute.

For non-template files the map function is simple:

  makeSimple = builtins.mapAttrs (
    path: options: {
      source = /. + "<absolute-path-to-config-files>/${path}";
    }
  );

You may wonder what this <absolute-path-to-config-files> is.

In my configuration, I have created a directory inside $HOME/.config/home-manager that mirrors the directory structure of the $HOME directory. This allows referring to the home-manager source file and the actual generated location with the same relative path and permits using lib.mapAttrs to modify the initial files attribute set.

For template files we need to provide some more information (i.e. the jinja data). We do so by adding a data attribute.

  files = {
    ".bashrc" = {};
    ".inputrc" = {};
    ".vimrc" = {
        "data" = "<absolute-path-to-json-data-file>";
    };
  };

Now, we define the map function.

  makeTemplates = builtins.mapAttrs (
    path: options: {
      text = template {
        src = /. + "<absolute-path-to-config-files>/${path}";
        data = /. + "${options.data}";
      };
    }
  );

We can see that we rely on the output of a helper function: template. This function in its simplest form³ takes two paths as arguments:

1. src is the path to the template file.
2. data is the path to a file containing data in JSON format.

The return value of this function has to be a Nix string that is then used as the value of the text attribute.

We define the template function as follows:

  template =
    { src, data }:
    let
      out = pkgs.runCommand "" { buildInputs = [ pkgs.jinja2-cli ]; } ''
        # If jinja2 fails (e.g. missing keys), just use the input file unchanged.
        jinja2 --format=json ${src} <<< "$(< ${data})" -o $out 2>/dev/null || cp ${src} $out
      '';
    in
    builtins.readFile out;

How does the template function work?

The function uses pkgs.runCommand⁴ to create a Nix derivation. In our use case we only want to create one single file that we can then read from.

• We run jinja2 on the src file using the data in json format.
• We write the output to the $out file (note: the $out variable is used internally by Nix and points to the generated derivation file).
  If anything fails during the jinja2 call we copy the original template file content to the output file directly.
• Finally, we read the output file and return its content as a Nix string.

3. Merge simple and template files in one attribute set.

We are almost done. We need to map non-template files with the makeSimple function and template files with the makeTemplate function. The differentiating factor is the presence of the data attribute and we use that to create a filter.

  simpleFile = (lib.filterAttrs (path: options: !options ? data) files);
  templateFiles = (lib.filterAttrs (path: options: options ? data) files);

  result = makeSimple simpleFiles // makeTemplates templateFiles;

4. Assign the resulting attribute set to home.file.

{
  pkgs,
  lib,
  ...
}:
let
  files = ...;

  template = ...;

  makeSimple = ...;
  makeTemplate = ...;

  simpleFiles = ...;
  templateFiles = ...;

  result = ...;
in
{
  # Other home-manager configuration options.
  ...

  # Files
  home.file = result;
}

That’s it. We have successfully configured home-manager to generate files from templates.

In practice

At the beginning of this post I mentioned how one my use cases for template files is specifying a different number of async workers for clangd in my LSP configuration in vim.

How does this look like based on the described setup?

$HOME/.config/home-manager/home.nix:

  ...
  files = {
    ...
    ".vim/variables.vim" = {
      data = "/home/<username>/.local/share/home-mananger/data.json";
    };
    ...
  };
  ...

$HOME/.config/home-manager/files/.vim/variables.vim:

autocmd User LspSetup call LspAddServer([
    \   #{
    \       name: 'clangd',
    \       filetype: ['c', 'cpp'],
    \       path: 'clangd',
    \       args: ['--clang-tidy', '-j', {{ data.nproc * 80 // 100 }}]
    \  },
    ...

$HOME/.local/share/home-manager/data.json:

{
  "data": {
    "nproc": 4
  }
}

It is that simple⁵.

Extensions

Nix enables extensive configuration, so we could certainly improve on the described setup if we needed to. Here are some ideas:

• The template function in its current form requires two file paths as parameters. We may desire some more flexibility.
  For example, we may want to pass the template file as a Nix string. Or we may want to pass the data in a different format (e.g. as a Nix attribute set, a Nix string, etc.).
  We should be able to easily achieve that with a few small changes in the template function in order to correctly parse and transform parameters of different types.

• In a previous iteration of my configuration I was generating multiple files from a single template file by iterating over a JSON array.
  I now have no use for it, so I have not included it in this post, but it is certainly doable with a few changes.

Setting

I have been working with C++ throughout my still-young software engineering career. Until now, I had not had any in-person contact with the C++ community. That has now changed. During the past three days, and for the first time, I attended a C++ conference. Having no prior reference for such an event, I did not have any outright expectations. I approached the event with an open mind and a curious spirit, diving right in.

Talks

All conference talks are usually made available online. Attending a conference does not necessarily grant access to exclusive or hidden knowledge. And neither should it. Information should be accessible to all. Both those who can attend such events and those who cannot.

Having said that, it is one thing to watch a talk online and another one to experience it in front of you. Observing the subtle behavior of the audience and being close to the interaction between the speaker and the rest of the room elevates the whole experience. Each talk is not just a presentation – it is a live performance. It can make you think, stir your emotions, enlighten you.

The possibilities are endless.

In that regard, I am grateful to have been present in so many great talks this year. The technical talks were excellent and the information shared from the speakers is highly valuable. The present and future of the language is exciting: modules (at last), contracts, reflection, … – the list goes on and on.

But working as a software engineer is not only about designing and writing code. It’s also about interacting with people. It is my strong belief that most problems in any organization are people problems. This is why I especially appreciated the more people-centric talks that were part of this year’s schedule.

Special mention goes to Titus Winters and his excellent opening keynote. Titus gave a compelling talk, sharing his experience in reducing fear in tech, and addressing various people-related issues in the workplace. He provided us with valuable actionable advice to improve our day-to-day work with respect to the challenges. He emphasized the importance of setting clear team culture goals related to technology quality, handling internal and external pressure, and team dynamics. He mentioned how expressing gratitude towards our colleagues and embracing the team members’ mistakes can go a long way towards improving the general team morale.

Though these ideas sound simple, they are not widely practiced. Yet the potential is clear. They will translate to better results.

The audience’s reactions made evident that many in our community resonated with these ideas. One would even say that many probably felt relieved they were not alone in having such sensitivities.

So, thank you, Titus, for your talk. I truly believed it paved the way nicely for the success of the whole conference.

People

The most important aspect of any conference is the people. The stories and experiences shared by everyone are invaluable. Glimpsing into different tech sub-worlds through others’ perspectives is incredibly rewarding.

I really want to express my gratitude to each and every one of the people who shared some of their precious time talking with me. Your fascinating work and stories left a lasting impression on me.

I wish I could have met even more people, but I guess this will have to wait for the next time¹.

Organization

Organizing a conference is no easy feat. Such efforts often go unnoticed or underappreciated. People do not tend to make their opinions public about such things. Especially when, as in this case, there are no issues².

So, a big thanks has to go to the people that made Meeting C++ 2024 happen and ensured that no visible problems arose.

One aspect that could be improved to greatly enhance the whole experience would be the break time between talks. I understand that there were many great talks, and it is not easy to fit everything into the schedule, but I believe 15 minutes is not enough time.

The current setting sometimes limits opportunities for meaningful conversations, exchanging opinions, and socializing with fellow attendees. This sentiment was shared by others I spoke to as well, so it would be nice to consider it in future editions of the conference.

Conclusion

I thoroughly enjoyed my time at Meeting C++ this year. I am really grateful that my company³ supported me and provided me with the opportunity to attend.

I genuinely believe it was an enriching experience, which has nicely shaped my feelings as I am writing this:

• I am inspired to improve all aspects of my work environment – culture, technical quality, and actual products.
• I eagerly look forward to seeing you all again at the next C++ conference I attend.

Auf Wiedersehen!

PS:

1. Apparently, I, too, don’t know how to properly operate a coffee safety pot.
2. I quite like my new T-shirt.

I have been trying to utilize all available features of C++ as much as possible. One that I particularly like is std::optional². I am fond of its semantics. Here is something that may contain a value, or it may as well contain nothing. This nothing is also known as std::nullopt. std::optional removes the need of returning raw pointers and relying on comparisons with nullptr in order to check if the return value of a function is valid or not.

I must say I have not been using std::optional extensively, so I am yet to discover all its edges. But recently, I had to interact with it a little more and learned something along the way.

Pseudocode

Let’s start by writing a small example to describe my thought process.

#include <string>
#include <optional>

std::optional<std::string> ParseMessage(const std::string& msg)
{
    if (msg.empty())
    {
        return std::nullopt;
    }
    return msg;
}

int main()
{
    auto myMsg = ParseMessage("Hello World");
}

The most explicit way to print the above message is:

if (myMsg.has_value())
{
    std::cout << myMsg.value() << "\n";
}

Of course, in this small example, we could have skipped the check. But in the real world, we always have to ensure that the value is there. Otherwise, an exception – when using .value() – or undefined behavior – when directly dereferencing the std::optional – is on the table.

Knowing all these, I filled my code with .has_value() and .value() calls. I knew it was correct, but it was also quite cumbersome. There must have been an easier way to write this.

Looking online, I saw some examples that were doing something akin to:

if (myMsg)
{
    std::cout << *myMsg << "\n";
}

This is what I was looking for. Not only is this a lot simpler to write, but it permits you to reuse old code that uses the nullptr-for-no-value pattern, just by changing the type from T* to std::optional<T> in the code.

Equipped with my newly found knowledge, I removed all calls to has_value() and replaced all calls to value() with direct dereferencing using operator*.

Surprise

Unfortunately, I was greeted with a compiler error.

error: cannot convert 'std::optional<T>' to 'bool'

The code in question was trying to do something like the following:

void Check(bool value);

void Run()
{
    ...
    Check(myOptionalValue);
    ...
}

The message was clear. But why did it not work? Converting to a bool in the condition of the if statement is certainly possible.

Truth

It turns out – as always – this is all by design. To answer my questions, I had to read the available specification on cppreference.com a little more carefully.

When an object of type optional<T> is contextually converted to bool ³, the conversion returns true if the object contains a value and false if it does not contain a value.

I was not sure what “contextually” meant, so I followed the link, and I was presented with the following introductory text.

Implicit conversions are performed whenever an expression of some type T1 is used in context that does not accept that type, but accepts some other type T2; in particular:

• when the expression is used as the argument when calling a function that is declared with T2 as parameter;
• when the expression is used as an operand with an operator that expects T2;
• when initializing a new object of type T2, including return statement in a function returning T2;
• when the expression is used in a switch statement (T2 is integral type);
• when the expression is used in an if statement or a loop (T2 is bool).

It seemed to explain my situation. The last bullet must be what permits the usage of std::optional in if statements.

But wait a minute.

The first bullet should cover the function parameter scenario, too. Obviously, this was not the case. I was missing something.

The magic word is “implicit”.

The std::optional class defines the following conversion function to bool:

constexpr explicit operator bool() const noexcept

It is clearly marked as explicit, so implicit conversions do not consider it.

I thought to myself:

How, then, does the conversion to ‘bool’ take place in the ‘if’ condition?

I had to keep reading. Further below was the answer to my question about the meaning of “contextually”.

Contextual conversions

In the following contexts, the type ‘bool’ is expected and the implicit conversion is performed if the declaration ‘bool t(e)’ is well-formed (that is, an explicit conversion function such as ‘explicit T::operator bool() const’ is considered). Such expression ‘e’ is said to be contextually converted to bool.

Since C++11:

• the controlling expression of if, while, for
• the operands of the built-in logical operators !, && and ||
• the first operand of the conditional operator ?:
• the predicate in a static_assert declaration
• the expression in a noexcept specifier

Since C++20:

• the expression in an explicit specifier

It turns out that, when a boolean expression is required for defining a condition – one would say, in a conditional context –, explicit conversion functions to bool are considered as well.

Lesson

I don’t want to focus on the minefield that is modern C++ syntax and rules. People smarter and more knowledgeable than me have expressed, and will continue to express, their opinions on the language. All I want to say is that, as a deeply inquiring mind, I was quite fascinated to discover this little sub-rule, which ultimately expanded my knowledge.

I mostly use ChatGPT for my programming tasks. While learning new concepts, it has mostly replaced searching the web for me. I prefer its clean interface: a question followed by an answer. Most times the answer is on point, something you don’t get out of a traditional search engine these days. The top-ranked SEO-heavy posts create an additional burden on me to filter them, which is not always an easy task, or a worthwhile one. For specific technical matters, I still prefer to directly visit the reference or documentation websites¹.

I first set up this personal website two years ago. I realised that GitHub pages would be a simple way to go about it. I set up Jekyll and started tinkering with a theme². Initially hesitant to begin posting, I uploaded some of my photography and left it at that.

About two weeks ago, I decided that I wanted to bring some life back into it. I set up my local environment again and started improving the website, bit by bit. I introduced post tags and tag pages³. I uploaded my first post.

One thing remained and I would be set: a better gallery view for my photos. From the first moment, I wanted to have a grid view. However, I am not very proficient in CSS and, at the time, I could not make it work as I wanted. I put my photos in a single column and called it a day.

Enter ChatGPT.

I want to put photos in a three column grid. When the screen size reduces, I want it to be responsive. What is the proper way to do it?

ChatGPT replied.

<div class="grid-container">
  <div class="grid-item"><img src="photo1.jpg" alt="Photo 1"></div>
  <div class="grid-item"><img src="photo2.jpg" alt="Photo 2"></div>
  <div class="grid-item"><img src="photo3.jpg" alt="Photo 3"></div>
  <!-- Add more grid items as needed -->
</div>

and

.grid-container {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
  grid-gap: 10px;
}

.grid-item {
  width: 100%;
}

It worked on the first try. I took it from there. I knew how to proceed. I adjusted my Jekyll templates accordingly and changed the minmax value, in order to fit three photos in the widest layout. I finally had a nicely looking photo gallery. I even added captions to all the photos. Cool!

Initially, by clicking on each photo, the original full-size photo was shown. I thought that this was not very optimal, since a lot of network data needed to be transferred. Most of my photos are taken with my Nikon D3400 DSLR camera and their size can be up to 20MB. The solution would be to show some smaller version of each photo initially, and only display the full-size version after a second click.

I thought to myself, “I want each photo to have its own page. How do I do that?”. I knew that it was possible to do it. My tags plugin is generating pages for all post tags.

Enter ChatGPT. Again.

Let’s say I have a list of photos in a Jekyll website as a data file. I want to create a page for each photo, where you can see the photo and links to the previous and next photo will navigate you along the list.

ChatGPT produced some valid HTML that I could work with, but the rest of the code was not up to the task. It did not help much with the Jekyll integration part. After a quick look around the web and the Jekyll documentation, I understood I needed to write a custom plugin⁴.

Your suggestions so far are not working. I think I need to write a custom plugin.

After the usual ChatGPT answer intro, I got the coveted code.

module Jekyll
  class PhotoPagesGenerator < Generator
    safe true
    priority :normal

    def generate(site)
      photos = site.data['photos']
      photos.each_with_index do |photo, index|
        previous_photo = index > 0 ? photos[index - 1] : nil
        next_photo = index < photos.size - 1 ? photos[index + 1] : nil

        site.pages << photoPage.new(site, photo, previous_photo, next_photo)
      end
    end
  end

  class photoPage < Page
    def initialize(site, photo, previous_photo, next_photo)
      @site = site
      @base = site.source
      @dir = '' # Set the directory where you want the pages to be generated
      @name = photo['url'] # Use the photo URL as the page name

      self.process(@name)
      self.data = {
        'layout' => 'photo_page',
        'title' => photo['caption'],
        'photo' => photo,
        'previous_photo' => previous_photo,
        'next_photo' => next_photo
      }
    end
  end
end

Voila! Once more, I made the necessary edits. I introduced wrapping around after reaching the end of the photo list, simplified the code, based on the official Jekyll documentation for generators, and set the correct path for the photos to be shown.

module Jekyll
  class PhotoPagesGenerator < Generator
    safe true
    priority :normal

    def generate(site)
      photos = site.data['photos']
      photos.each_with_index do |photo, index|
        previous_photo = photos[(index - 1) % photos.size]
        next_photo = photos[(index + 1) % photos.size]

        site.pages << PhotoPage.new(site, photo, previous_photo, next_photo, index)
      end
    end
  end

  class PhotoPage < Page
    def initialize(site, photo, previous_photo, next_photo, index)
      @site = site
      @base = site.source
      @dir = "/photography/" + photo["name"]
      @basename = 'index'
      @ext      = '.html'
      @name     = 'index.html'

      self.process(@name)
      self.data = {
        'layout' => 'photo_page',
        'title' => photo["caption"],
        'photo' => photo,
        'previous_photo' => previous_photo,
        'next_photo' => next_photo,
        'index' => index + 1  # increment to start from 1,
      }
    end
  end
end

I finally had it. I struggled a little more than with the CSS grid code, but I had it. A page for every one of my photos. Enthusiastically, I uploaded the changes.

I am really satisfied with the outcome. I find it amazing how helpful ChatGPT can be, if you have a rough idea of what you want to achieve, you know the right keywords to use in your query and are willing to play a little with the code afterwards. And, testament to its value, I consider it as a great companion in my tech endeavours and look forward to further exploring its powers.

I had to evaluate my options. Many people working remotely go to cafés. They enjoy a cup of coffee and a piece of cake and hopefully something else later¹, until it is time to call it a day. Visiting the city for the first time, I had no idea where to find good cafés for working. I didn’t want to spend more time searching for a suitable place, when I should have already been working. So, I decided to play it safe.

In the maps application on my phone, I entered:

library

Libraries have always held a soft spot in my heart. I am a book aficionado and love learning new stuff, so a place that contains such a variety of books and knowledge naturally appeals to me. Despite this, I hadn’t visited a library with the intention of spending some productive time there in nearly five years. It was during my last year of studies. Before the whole Covid-19 adventure.

I scanned the map on my phone for a library within walking distance and was satisfied that the main library of the city was only 1.5 kilometre down the street. I packed my laptop and headed towards there.

The first visit to a previously unknown library is a pleasant experience for me. It mostly comes down to the curiosity about the arrangement of the books, the availability of working spaces and, most importantly, the people that are already there. I did a brief tour around. I was looking for a suitable place to “camp”, while quickly observing the other library visitors. Some working alone, some students on a group project, some on the public computers.

I soon had my spot. I unpacked my stuff and started working. I like to have my headphones on, when working in public spaces. But I don’t want to block all outside sounds. I like knowing that the environment around me is lively. It gives me a sense of purpose.

I believe that the collective focus of people working or studying, even though they do not interact directly with one another, has an interesting effect which in turn makes me more focused on my work. It is what makes libraries unique. They are not just buildings or places of public service, but a vibrant social environment. It is also why I don’t plan to wait for five more years before my next visit.

You should not wait either. If you ever need a change of scenery when working, you know what to do. Open the maps application on your phone² and enter the magic word:

library

See you there.