This release brings small but important bug fixes. The previous release, version 0.2.0 introduced a number of new features. Unfortunately, two of them caused issues for some users. A new feature in the previous release was the ignore list feature. The ignore list defines console URLs and page URLs that the console never uses while discovering page recommendations. While this feature works fine, due to a bug in the implementation, the Console dialog fails to load in consoles that do not define any ignore list. This has now been fixed.

There was another issue due to which the <iframe> that displays discovered websites and pages could not load certain websites. In particular, any website that relied on same-origin context to load its own resources failed to load in the console. This has been fixed as well. Please see codeberg.org/susam/wander/issues/7 for a detailed discussion on this issue.

Apart from these two important fixes, there are a few other minor fixes too pertaining to preventing horizontal scrolling in small devices and preventing duplicate recommendations from appearing too close to each other. Please see CHANGES.md for a detailed changelog.

To learn more about Wander, how it works and how to set it up, please read the project README at codeberg.org/susam/wander. To try it out right now, go to susam.net/wander/.

Read on website | #web | #technology

This release brings a number of improvements. When I released version 0.1.0, it was the initial version of the software I was using for my own website. Naturally, I was the only user initially and I only added trusted web pages to the recommendation list of my console. But ever since I announced this project on Hacker News, it has received a good amount of attention. It has been less than a week since I announced it there but over 30 people have set up a Wander console on their personal websites. There are now over a hundred web pages being recommended by this network of consoles. With the growth in the number of people who have set up Wander console, came several feature requests, most of which have been implemented already. This release makes these new features available.

Since Wander 0.2.0, the wander.js file of remote consoles is executed in a sandbox iframe to ensure that it has no side effects on the parent Wander console page. Similarly, the pages recommended by the network are also loaded into a sandbox iframe.

This release also brings several customisation features. Console owners can customise their Wander console by adding custom CSS or JavaScript. Console owners can also block certain URLs from ever being recommended on their console. This is especially important in providing a good wandering experience to visitors. Since this network is completely decentralised, console owners can add any web page they like to their console. Sometimes they inadvertently add pages that do not load successfully in the console due to frame embedding restrictions. This leads to an uneven wandering experience because these page recommendations occasionally make it to other consoles where they fail to load. Console owners can now block such URLs in their console to decrease the likelihood of these failed page loads. This helps make the wandering experience smoother.

Another significant feature in this release is the expanded Console dialog box. This dialog box now shows various details about the console and the current wandering session. For example, it shows the console's configuration: recommended pages, ignored URLs and linked consoles. It also shows a wandering history screen where you can see each link that was recommended to you along with the console that recommendation came from. There is another screen that shows all the consoles discovered during the discovery process. Those who care about how Wander works would find this dialog box quite useful. To check it out, go to my Wander console and explore.

To learn more about Wander, how it works and how to set it up, please read the project README at codeberg.org/susam/wander.

Read on website | #web | #technology

There are only a few pages in it right now, so you cannot use it to browse the small web endlessly yet. It is just a beginning and I hope it grows. If you like this idea and want more websites to explore, you can set up your own Wander console so that I can link to it from mine. That is how the Wander network grows.

Please take a look at susam.net/wander/ and let me know what you think.

If you have your own website, please consider joining this community by hosting your own Wander console. To do so, visit codeberg.org/susam/wander and follow the instructions there. Thank you!

Read on website | #web | #technology

Anyone with a personal website can take this tool and host an instance of a Wander console. Each Wander console loads personal websites and pages recommended by the Wander community. Further, each Wander console can link to other Wander consoles, forming a lightweight, decentralised network for browsing the small web of personal websites.

Setting up an instance of a Wander console involves copying just two static files from the Wander project at codeberg.org/susam/wander. The most interesting aspect of the Wander console is that discovery of new links from other consoles happens on the client side in the user's web browser. As a website owner, you do not need to set up any server-side components beyond a basic web server. In fact, you can host a Wander console on GitHub Pages or Codeberg Pages too.

To learn more about Wander, how it works and how to set it up, please read the project README at codeberg.org/susam/wander.

Read on website | #web | #technology

Contents

• Experimental Setup
• Reset the Working Tree
• Reset the Index
• Reset the Working Tree and Index
• Summary

Experimental Setup

To experiment quickly, we first create an example Git repository.

mkdir foo/; cd foo/; touch a b c
git init; git add a b c; git commit -m hello

Now we make changes to the files and stage some of the changes. We then add more unstaged changes to one of the staged files.

date | tee a b c d; git add a b d; echo > b

At this point, the working tree and index look like this:

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   a
        modified:   b
        new file:   d

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   b
        modified:   c

File a has staged changes. File b has both staged and unstaged changes. File c has only unstaged changes. File d is a new staged file. In each experiment below, we will work with this setup.

All results discussed in this post were obtained using Git 2.47.3 on Debian 13.2 (Trixie).

Reset the Working Tree

As a reminder, we will always use the following command between experiments to ensure that we restore the experimental setup each time:

date | tee a b c d; git add a b d; echo > b

To discard the changes in the working tree and reset the files in the working tree from the index, I typically run:

git checkout .

However, the modern way to do this is to use the following command:

git restore .

Both commands leave the working tree and the index in the following state:

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   a
        modified:   b
        new file:   d

Both commands operate only on the working tree. They do not alter the index. Therefore the staged changes remain intact in the index.

Reset the Index

Another common situation is when we have staged some changes but want to unstage them. First, we restore the experimental setup:

date | tee a b c d; git add a b d; echo > b

I normally run the following command to do so:

git reset

The modern way to do this is:

git restore -S .

Both commands leave the working tree and the index in the following state:

$ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   a
        modified:   b
        modified:   c

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        d

no changes added to commit (use "git add" and/or "git commit -a")

The -S (--staged) option tells git restore to operate on the index (not the working tree) and reset the index entries for the specified files to match the version in HEAD. The unstaged changes remain intact as modified files in the working tree. With the -S option, no changes are made to the working tree.

From the arguments we can see that the old and new commands are not exactly equivalent. Without any arguments, the git reset command resets the entire index to HEAD, so all staged changes become unstaged. Similarly, when we run git restore -S without specifying a commit, branch or tag using the -s (--source) option, it defaults to resetting the index from HEAD. The . at the end ensures that all paths under the current directory are affected. When we run the command at the top-level directory of the repository, all paths are affected and the entire index gets reset. As a result, both the old and the new commands accomplish the same result.

Reset the Working Tree and Index

Once again, we restore the experimental setup.

date | tee a b c d; git add a b d; echo > b

This time we not only want to unstage the changes but also discard the changes in the working tree. In other words, we want to reset both the working tree and the index from HEAD. This is a dangerous operation because any uncommitted changes discarded in this manner cannot be restored using Git.

git reset --hard

The modern way to do this is:

git restore -WS .

The working tree is now clean:

$ git status
On branch main
nothing to commit, working tree clean

The -W (--worktree) option makes the command operate on the working tree. The -S (--staged) option resets the index as described in the previous section. As a result, this command unstages any changes and discards any modifications in the working tree.

Note that when neither of these options is specified, -W is implied by default. That's why the bare git restore . command in the previous section discards the changes in the working tree.

Summary

The following table summarises how the three pairs of commands discussed above affect the working tree and the index, assuming the commands are run at the top-level directory of a repository.

The git restore command is meant to provide a clearer interface for resetting the working tree and the index. I still use the older commands out of habit. Perhaps I will adopt the new ones in another six years, but at least I have the mapping written down now.

Read on website | #technology | #how-to

When a notable figure in technology or science passes away, Hacker News places a thin black bar at the top of the page in tribute. Previously some skins could obscure this element. This update ensures that the bar remains visible and clearly noticeable. In dark themed skins, the black bar is rendered as a lighter shade of grey so that it maintains sufficient contrast and remains conspicuous.

Today Hacker News has a story about Tony Hoare passing away, which made me notice that the commemorative black bar was not rendered properly with some skins. This prompted me to investigate the issue and implement the fix included in this release.

Screenshots showing how the bar appears with different skins are available at susam.github.io/blob/img/hnskins/0.4.0/.

To install HN Skins, visit github.com/susam/hnskins and follow the instructions there.

Read on website | #web | #programming | #technology

Further, the font face of several monospace based themes is now set to monospace instead of courier. This allows the browser's preferred monospace font to be used. The font face of the Courier skin (formerly known as Teletype) remains set to courier. This will never change because the sole purpose of this skin is to celebrate this legendary font.

To view screenshots of HN Skins or install it, visit github.com/susam/hnskins.

Read on website | #web | #programming | #technology

This update removes excessive vertical space below the 'reply' links, sorts the skin options alphabetically in the selection dialog and fixes the background colour of the navigation bar in the Terminal skin by changing it from a dark grey to a dark green.

Soon after making this release, I discovered a few other minor issues, such as the Cafe and Terminal themes using Courier when I intended them to use the system monospace font. This has already been fixed in the development version currently available on GitHub. However, I will make a formal release later.

See the changelog for more details. To see some screenshots of HN Skins or to install it, visit github.com/susam/hnlinks and follow the instructions there.

Read on website | #web | #programming | #technology

To use HN Skins, first install a userscript manager such as Greasemonkey, Tampermonkey or Violentmonkey in your web browser. Once installed, you can install HN Skins from github.com/susam/hnskins.

The source code is available under the terms of the MIT licence. For usage instructions and screenshots, please visit github.com/susam/hnskins.

Read on website | #web | #programming | #technology

Most of last month's notes grew out of my reading of Algebraic Graph Theory by Godsil and Royle. I am still exploring and learning this subject. This month, however, I dove into another book with the same title but this book is written by Norman Biggs. As a result, many of the notes that follow are drawn from Biggs's treatment of the topic.

Since I already had a good understanding of the subject from the earlier book, I decided to skip the first fourteen chapters of the new book. I began with Chapter 15, which discusses automorphisms of graphs and then moved on to the following chapters on graph symmetries. My main reason for picking up Biggs's book was to understand Tutte's well known result that any \( s \)-arc-transitive finite cubic graph must satisfy \( s \le 5. \) While I did not reach that chapter this month, I made substantial progress with the book. I hope to work through the proof of Tutte's theorem next month.

Contents

1. Degree of Vertices in an Orbit
2. Regular Non-Vertex-Transitive Graphs
3. Vertex-Transitive But Not Edge-Transitive
4. Edge-Transitivex But Not Vertex-Transitive
5. Bipartiteness as a Necessary Condition
6. Graph with an Automorphism Group
7. Permutation Groups Need Not Be Automorphism Groups
8. Symmetric Graphs

Degree of Vertices in an Orbit

If two vertices of a graph belong to the same orbit, then they have the same degree. In other words, for a graph \( X, \) if \( x, y \in V(X) \) and there is an automorphism \( \alpha \) such that \( \alpha(x) = y, \) then \( \deg(x) = \deg(y). \)

The proof is quite straightforward. Let \begin{align*} N(x) &= \{ v_1, \dots, v_r \}, \\ N(y) &= \{ w_1, \dots, w_s \} \end{align*} represent the neighbours of \( x \) and \( y \) respectively. Therefore we have \[ x \sim v_1, \; \dots, \; x \sim v_r. \] Since an automorphism preserves adjacency, we get \[ \alpha(x) \sim \alpha(v_1), \; \dots, \; \alpha(x) \sim \alpha(v_r). \] Substituting \( \alpha(x) = y, \) we get \[ y \sim \alpha(v_1), \; \dots, \; y \sim \alpha(v_r). \] Thus \[ \alpha(N(x)) = \{ \alpha(v_1), \; \dots, \; \alpha(v_r) \} \subseteq N(y). \] A similar argument works in reverse as well. By the definition of automorphism, if \( \alpha \) is an automorphism, so is \( \alpha^{-1}. \) From the definition of \( N(y) \) above, we have \[ y \sim w_1, \; \dots, \; y \sim w_s. \] Therefore \[ \alpha^{-1}(y) \sim \alpha^{-1}(w_1), \; \dots, \; \alpha^{-1}(y) \sim \alpha^{-1}(w_s). \] This is equivalent to \[ x \sim \alpha^{-1}(w_1), \; \dots, \; x \sim \alpha^{-1}(w_s). \] Thus \[ \alpha^{-1}(N(y)) = \{ \alpha^{-1}(w_1), \; \dots, \; \alpha^{-1}(w_s) \} \subseteq N(x) \] This can be rewritten as \[ \{ \alpha^{-1}(w_1), \; \dots, \; \alpha^{-1}(w_s) \} \subseteq \{ v_1, \dots, v_r \}. \] Therefore \[ N(y) = \{ w_1, \dots, w_s \} \subseteq \{ \alpha(v_1), \dots, \alpha(v_r) \} = \alpha(N(x)). \] We have shown that \( \alpha(N(x)) \subseteq N(y) \) and \( N(y) \subseteq \alpha(N(x)). \) Thus \[ \alpha(N(x)) = N(y). \] Thus \[ \lvert N(y) \rvert = \lvert \alpha(N(x)) \rvert = r. \] Therefore both \( x \) and \( y \) have \( r \) neighbours each. Hence \( \deg(x) = \deg(y). \)

Regular Non-Vertex-Transitive Graphs

The Frucht graph and the Folkman graph are examples of graphs that are \( k \)-regular but not vertex-transitive. In fact, the Folkman graph is a semi-symmetric graph, i.e. it is regular and edge-transitive but not vertex-transitive.

Vertex-Transitive But Not Edge-Transitive

The circular ladder graph \( CL_3, \) i.e. the triangular prism graph, is vertex-transitive but not edge-transitive.

Every vertex has the same local structure. Every vertex has degree \( 3 \) and it lies on exactly one of the two triangles and it has exactly one 'vertical' edge connecting it to the corresponding edge on the other triangle. Any vertex can be sent to any other by an automorphism.

Since triangle edges are in a triangle and vertical edges are in no triangle, no automorphism can send a triangle edge to a vertical edge or vice versa. Therefore the graph is not edge-transitive.

Edge-Transitivex But Not Vertex-Transitive

The complete bipartite graphs \( K_{m,n} \) with \( m \ne n \) are edge-transitive but not vertex-transitive.

Every edge connects one vertex from the \( m \)-part to one vertex from the \( n \)-part. Any permutation of vertices inside the \( m \)-part preserves adjacency. Similarly, any permutation of vertices inside the \( n \)-part preserves adjacency.

Take two arbitrary edges \[ uv, \; u'v' \in E(K_{m,n}) \] where \( u, u' \) are vertices that lie in the \( m \)-part and \( v, v' \) are vertices that lie in the \( n \)-part. Permute vertices within the \( m \)-part to send \( u \) to \( u'. \) Similarly, permute vertices within the \( n \)-part to send \( v \) to \( v'. \) This gives an automorphism that sends the edge \( uv \) to \( u'v'. \) In this manner we can find an automorphism that sends any edge to any other. Therefore, \( K_{m,n} \) is edge-transitive.

However, \( K_{m,n} \) is not vertex-transitive since no automorphism can send a vertex in the \( m \)-part to a vertex in the \( n \)-part since the vertices in the \( m \)-part have degree \( n \) and the vertices in the \( n \)-part have degree \( m. \)

Bipartiteness as a Necessary Condition

If a connected graph is edge-transitive but not vertex-transitive, then it must be bipartite.

Graph with an Automorphism Group

In 1938, Frucht proved that for every finite abstract group \( G, \) there exists a graph whose automorphism group is isomorphic to \( G . \)

Remarkably, this result remains valid even when we restrict our attention to cubic graphs. That is, for every finite abstract group \( G, \) there exists a cubic graph whose automorphism group is isomorphic to \( G. \) Moreover, the result has been extended to graphs satisfying various additional graph-theoretical properties, such as \( k \)-connectivity, \( k \)-regularity and prescribed chromatic number.

Permutation Groups Need Not Be Automorphism Groups

Consider the following specialised version of the problem discussed in the previous section: Given a permutation group on a set \( X, \) must there exist a graph with vertex set \( X \) whose automorphism group is precisely that permutation group?

The answer is no. Consider the cyclic group \( C_3 \) acting on \( X = \{ a, b, c \}. \) There is no graph \( \Gamma \) with \( V(\Gamma) = X \) and \( \operatorname{Aut}(\Gamma) \cong C_3. \) If we take \( \Gamma = K_3, \) then \( C_3 \subset S_3 = \operatorname{Aut}(K_3) \) but \( C_3 \ne \operatorname{Aut}(K_3) . \)

Symmetric Graphs

It is interesting that while we study graph symmetry through concepts such as graph automorphisms, vertex-transitivity, edge-transitivity, etc. the name symmetric graph is reserved for graphs that are \( 1 \)-arc-transitive. A vertex-transitive graph or an edge-transitive graph need not be \(1\)-arc-transitive and therefore need not be symmetric.

However, every \( s \)-arc-transitive graph is \(1 \)-arc-transitive for \( s \ge 1. \) Consequently, every \( s \)-arc-transitive graph is symmetric. Moreover, every distance-transitive graph is also \( 1 \)-arc-transitive and hence symmetric.

Formally, we say that a graph \( \Gamma \) is \( 1 \)-arc-transitive (or equivalently, symmetric) if for all \( 1 \)-arcs \( uv \) and \( u'v' \) of \( \Gamma, \) there is an automorphism \( \alpha \in \operatorname{Aut}(\Gamma) \) such that \( \alpha(uv) = u'v'. \)

Stated in more basic terms, we can say that \( \Gamma \) is symmetric if for all \( u, v, u', v' \in V(\Gamma) \) satisfying \( u \sim v \) and \( u' \sim v', \) there exists \( \alpha \in \operatorname{Aut}(\Gamma) \) such that \( \alpha(u) = u' \) and \( \alpha(v) = v'. \)

Switching gears now, we say that \( \Gamma \) is distance-transitive if for all \( u, v, u', v' \in V(\Gamma) \) satisfying \( d(u, v) = d(u', v'), \) there exists \( \alpha \in \operatorname{Aut}(\Gamma) \) such that \( \alpha(u) = u' \) and \( \alpha(v) = v'. \) Since all \( 1 \)-arcs \( uv \) and \( u'v' \) satisfy \( d(u, v) = d(u', v') = 1, \) distance-transitivity implies that there is an automorphism that sends \( uv \) to \( u'v'. \) Therefore a distance-transitive graph is also \( 1 \)-arc-transitive.

To summarise, a graph must possess a certain degree of symmetry in order to be called symmetric. It turns out that merely having a non-trivial automorphism group is not sufficient. Even being vertex-transitive or edge-transitive is not enough for a graph to be called symmetric. The graph needs to be at least \( 1 \)-arc-transitive to be called symmetric.

Another interesting aspect of this terminology is that the property of being asymmetric is not the exact opposite of being symmetric. For example, a vertex-transitive graph need not be symmetric. However, that does not make it asymmetric. A graph is called asymmetric if it has no non-trivial automorphisms, i.e. its automorphism group contains only the identity permutation. Thus, if a graph has at least two vertices and is vertex-transitive, it must admit a non-trivial automorphism that maps one vertex to another. So while such a vertex-transitive may not be symmetric, it isn't asymmetric either.

Read on website | #monthly | #mathematics

This release introduces five new questions drawn from a range of topics, including computing history, graph theory and Unix. Visit Nerd Quiz to try the quiz.

A community discussion page is available here. You are very welcome to share your score or discuss the questions there.

Read on website | #web | #miscellaneous | #game

Still, chess players can take comfort in the fact that chess is still played between humans. Players make their name and fame by beating other humans because playing against computers is no longer interesting as a competition.

Many software developers would like to have similar comfort. But that comfort is harder to find, because unlike chess, building prototypes or PoCs is not seen as a sport or art form. It is mostly seen as a utility. So while brain-coding a PoC may still be intellectually satisfying for the programmer, to most other people it only matters that the thing works. That means that programmers do not automatically get the same protected space that chess players have, where the human activity itself remains valued even after machines become stronger. The activity programmers enjoy may continue but the recognition and economic value attached to it may shrink.

So I think the big adjustment software developers have to make is this: The craft will still exist and we will still enjoy doing it but the credit and value will increasingly go to those who define problems well, connect systems, make good product decisions and make technology useful in messy real-world situations. It has already been this way for a while and will only become more so as time goes by.

This note reproduces a recent comment I posted in a Lobsters forum thread about LLM-assisted software development at at lobste.rs/s/qmjejh.

See also: Three Inverse Laws of AI and Robotics.

Read on website | #miscellaneous

$ sudo sojuctl user delete soju
To confirm user deletion, send "user delete soju 4664cd"
$ sudo sojuctl user delete soju 4664cd
deleted user "soju"

That confirmation token for a specific user never changes, no matter how many times we create or delete it. The confirmation token is not saved in the Soju database, as can be confirmed here:

$ sudo sqlite3 -table /var/lib/soju/main.db 'SELECT * FROM User'
+----+----------+--------------------------------------------------------------+-------+----------+------+--------------------------+---------+--------------------------+--------------+
| id | username |                           password                           | admin | realname | nick |        created_at        | enabled | downstream_interacted_at | max_networks |
+----+----------+--------------------------------------------------------------+-------+----------+------+--------------------------+---------+--------------------------+--------------+
| 1  | soju     | $2a$10$yRj/oYlR2Zwd8YQxZPuAQuNo2j7FVJWeNdIAHF2MinYkKLmBjtf0y | 0     |          |      | 2026-02-16T13:49:46.119Z | 1       |                          | -1           |
+----+----------+--------------------------------------------------------------+-------+----------+------+--------------------------+---------+--------------------------+--------------+

Surely, then, the confirmation token is derived from the user definition? Yes, indeed it is. This can be confirmed at the source code here. Quoting the most relevant part from the source code:

hashBytes := sha1.Sum([]byte(username))
hash := fmt.Sprintf("%x", hashBytes[0:3])

Indeed if we compute the same hash ourselves, we get the same token:

$ printf soju | sha1sum | head -c6
4664cd

This allows us to automate the two step Soju user deletion process in a single command:

sudo sojuctl user delete soju "$(printf soju | sha1sum | head -c6)"

But of course, the implementation of the confirmation token may change in future and Soju helpfully outputs the deletion command with the confirmation token when we first invoke it without the token, so it is perhaps more prudent to just take that output and feed it back to Soju, like so:

sudo sojuctl $(sudo sojuctl user delete soju | sed 's/.*"\(.*\)"/\1/')

Read on website | #shell | #irc | #technology | #how-to

Setup

It is quite straightforward to install and set up Soju on Debian. The following two commands install Soju:

sudo apt-get update
sudo apt-get -y install soju

Then setting up an IRC connection involves another two commands:

sudo sojuctl user create -username soju -password YOUR_SOJU_PASSWORD
sudo sojuctl user run soju network create -name bnc1 -addr irc.libera.chat -nick YOUR_NICK -pass YOUR_NICK_PASSWORD

Here, YOUR_SOJU_PASSWORD is a placeholder for a new password you must choose for your Soju user. Finally, we restart Soju as follows:

sudo systemctl restart soju

Database

What previously involved maintaining several files that had to be installed and configured on each machine running ZNC is now reduced to the two sojuctl commands above. Still, the configuration needs to live somewhere. In fact, the two sojuctl commands introduce earlier store the configuration in a SQLite database. Here is a glimpse of what the database looks like:

$ sudo sqlite3 /var/lib/soju/main.db '.tables'
Channel              MessageFTS_data      ReadReceipt
DeliveryReceipt      MessageFTS_docsize   User
Message              MessageFTS_idx       WebPushConfig
MessageFTS           MessageTarget        WebPushSubscription
MessageFTS_config    Network
$ sudo sqlite3 /var/lib/soju/main.db 'SELECT * from User'
1|soju|$2a$10$mM5Qcz8.OPMi9lyWDxPRh.bNxzq7jtLdxcoPl09AYTnqcmLmEqzSO|0|||2026-02-17T23:24:24.926Z|1||-1
$ sudo sqlite3 /var/lib/soju/main.db 'SELECT * from Network'
1|bnc1|1|irc.libera.chat|YOUR_NICK||||YOUR_NICK_PASSWORD|||||||1|1

Client Configuration

Finally, the IRC client can be configured to connect to port 6697 on the system running Soju. Here is an example of how this can be done in Irssi:

/network add -nick YOUR_NICK -user soju/bnc1 net1
/server add -tls -network bnc1 YOUR_SOJU_HOST 6697 YOUR_SOJU_PASSWORD
/connect net1

You can also set up multiple connections to IRC networks through the same Soju instance. All you need to do is repeat the sojuctl commands to create additional networks such as bnc2, bnc3 and so on, then repeat the configuration in your IRC client using new network names such as net2, net3, etc. These network names are entirely user defined, so you can choose any names you like. The names bnc2, net2 and so on are only examples.

Read on website | #irc | #technology | #how-to

Contents

• Viewing the Source
• The Reset Vector
• Man in the Middle
• Sphagetti Code
• Animated Television Widgets
• Good Blessings
• The CTF Scoreboard

Viewing the Source

The first story takes place in 2001, shortly after I joined university. One evening, I went to the university computer laboratory to browse the World Wide Web. Out of curiosity, I typed susam.com into the address bar and landed on its home page. I remember the text and banner looking much larger back then. Display resolutions were lower, so the text and banner covered almost half the screen. I knew very little about the Internet then and I was just trying to make sense of it. I remember wondering what it would take to create my own website, perhaps at susam.com. That's when an older student who had been watching me browse over my shoulder approached and asked if I had created the website. I told him I hadn't and that I had no idea how websites were made. He asked me to move aside, took my seat and clicked View > Source in Internet Explorer. He then explained how websites are made of HTML pages and how those pages are simply text instructions.

Next, he opened Notepad and wrote a simple HTML page that looked something like this:

<BODY><FONT COLOR="RED">HELLO</FONT></BODY>

Yes, we had a FONT tag back then and it was common practice to write HTML tags in uppercase. He then opened the page in a web browser and showed how it rendered. After that, he demonstrated a few more features such as changing the font face and size, centring the text and altering the page's background colour. Although the tutorial lasted only about ten minutes, it made the Web feel far less mysterious and much more fascinating.

That person had an ulterior motive though. After the tutorial, he never returned the seat to me. He just continued browsing the Web and waited for me to leave. I was too timid to ask for my seat back. Seats were limited, so I returned to my dorm room both disappointed that I couldn't continue browsing that day and excited about all the websites I might create with this newfound knowledge. I could never register susam.com for myself though. That domain was always used by some business selling Turkish cuisines. Eventually, I managed to get the next best thing: a .net domain of my own. That brief encounter in the university laboratory set me on a lifelong path of creating and maintaining personal websites.

The Reset Vector

The second story also comes from my university days. One afternoon, I was hanging out with my mates in the computer laboratory. In front of me was an MS-DOS machine powered by an Intel 8086 microprocessor, on which I was writing a lift control program in assembly. In those days, it was considered important to deliberately practise solving made-up problems as a way of honing our programming skills. As I worked on my program, my mind drifted to a small detail about the 8086 microprocessor that we had recently learnt in a lecture. Our professor had explained that, when the 8086 microprocessor is reset, execution begins with CS:IP set to FFFF:0000. So I murmured to anyone who cared to listen, 'I wonder if the system will reboot if I jump to FFFF:0000.' I then opened DEBUG.EXE and jumped to that address.

C:\>DEBUG
-G =FFFF:0000

The machine rebooted instantly. One of my friends, who topped the class every semester, had been watching over my shoulder. As soon as the machine restarted, he exclaimed, 'How did you do that?' I explained that the reset vector is located at physical address FFFF0 and that the CS:IP value FFFF:0000 maps to that address in real mode. After that, I went back to working on my lift control program and didn't think much more about the incident.

About a week later, the same friend came to my dorm room. He sat down with a grave look on his face and asked, 'How did you know to do that? How did it occur to you to jump to the reset vector?' I must have said something like, 'It just occurred to me. I remembered that detail from the lecture and wanted to try it out.' He then said, 'I want to be able to think like that. I come top of the class every semester, but I don't think the way you do. I would never have thought of taking a small detail like that and testing it myself.' I replied that I was just curious to see whether what we had learnt actually worked in practice. He responded, 'And that's exactly it. It would never occur to me to try something like that. I feel disappointed that I keep coming top of the class, yet I am not curious in the same way you are. I've decided I don't want to top the class anymore. I just want to explore and experiment with what we learn, the way you do.'

That was all he said before getting up and heading back to his dorm room. I didn't take it very seriously at the time. I couldn't imagine why someone would willingly give up the accomplishment of coming first every semester. But he kept his word. He never topped the class again. He still ranked highly, often within the top ten, but he kept his promise of never finishing first again. To this day, I feel a mix of embarrassment and pride whenever I recall that incident. With a single jump to the processor's reset entry point, I had somehow inspired someone to step back from academic competition in order to have more fun with learning. Of course, there is no reason one cannot do both. But in the end, that was his decision, not mine.

Man in the Middle

In my first job after university, I was assigned to a technical support team where part of my work involved running an installer to deploy a specific component of an e-banking product for customers, usually large banks. As I learnt to use the installer, I realised how fragile it was. The installer, written in Python, often failed because of incorrect assumptions about the target environment and almost always required some manual intervention to complete successfully. During my first week on the project, I spent much of my time stabilising the installer and writing a step-by-step user guide explaining how to use it. The result was well received by both my seniors and management. To my surprise, the user guide received more praise than the improvements I made to the installer. While the first few weeks were productive, I soon realised I would not find the work fulfilling for long. I wrote to management a few times to ask whether I could transfer to a team where I could work on something more substantial.

My emails were initially met with resistance. After several rounds of discussion, someone who had heard about my situation reached out and suggested a team whose manager might be interested in interviewing me. The team was based in a different city. I was young and willing to relocate wherever I could find good work, so I immediately agreed to the interview.

This was in 2006, when video conferencing was not yet common. On the day of the interview, the hiring manager called me on my office desk phone. He began by introducing the team, which was called Archie, short for architecture. The team developed and maintained the web framework and core architectural components on which the entire e-banking product was built. The product had existed long before open source frameworks such as Spring or Django came into existence, so features such as API routing, authentication and authorisation layers, cookie management, etc. were all implemented in-house as Java Servlets and JavaServer Pages (JSP). Since the software was used in banking environments, it also had to pass security testing and regular audits to minimise the risk of serious flaws.

The interview began well. He asked several questions related to software security, such as what SQL injection is, how it can be prevented and how one might design a web framework that mitigates cross-site scripting attacks. He also asked me a few programming questions, most which I answered pretty well. Towards the end, however, he asked how we could prevent MITM attacks. I had never heard the term, so I admitted that I did not know what MITM meant. He then asked, 'Man in the middle?' but I still had no idea what that meant or whether it was even a software engineering concept. He replied, 'Learn everything you can about PKI and MITM. We need to build a digital signatures feature for one of our corporate banking products. That's the first thing we'll work on.'

Over the next few weeks, I studied RFCs and documentation related to public key infrastructure, public key cryptography standards and related topics. At first, the material felt intimidating, but after spending time each evening reading whatever relevant literature I could find, things gradually began to make sense. Concepts that initially seemed complex and overwhelming eventually felt intuitive and elegant. I relocated to the new city a few weeks later and delivered the digital signatures feature about a month after joining the team. We used the open source Bouncy Castle library to implement the feature. After that project, I worked on other parts of the product too. The most rewarding part was knowing that the code I was writing became part of a mature product used by hundreds of banks and millions of users. It was especially satisfying to see the work pass security testing and audits and be considered ready for release.

That was my first real engineering job. My manager also turned out to be an excellent mentor. Working with him helped me develop new skills and his encouragement gave me confidence that stayed with me for years. Nearly two decades have passed since then, yet the product is still in service and continues to be actively developed. In fact, in my current phase of life I sometimes encounter it as a customer. Occasionally, I open the browser's developer tools to view the page source where I can still see traces of the HTML generated by code I wrote almost twenty years ago.

Sphagetti Code

Around 2007 or 2008, I began working on a proof of concept for developing widgets for an OpenTV set-top box. The work involved writing code in a heavily trimmed-down version of C. One afternoon, while making good progress on a few widgets, I noticed that they would occasionally crash at random. I tried tracking down the bugs, but I was finding it surprisingly difficult to understand my own code. I had managed to produce some truly spaghetti code full of dubious pointer operations that were almost certainly responsible for the crashes, yet I could not pinpoint where exactly things were going wrong.

Ours was a small team of four people, each working on an independent proof of concept. The most senior person on the team acted as our lead and architect. Later that afternoon, I showed him my progress and explained that I was still trying to hunt down the bugs causing the widgets to crash. He asked whether he could look at the code. After going through it briefly and probably realising that it was a bit of a mess, he asked me to send him the code as a tarball, which I promptly did.

He then went back to his desk to study the code. I remember thinking that there was no way he was going to find the problem anytime soon. I had been debugging it for hours and barely understood what I had written myself; it was the worst spaghetti code I had ever produced. With little hope of a quick solution, I went back to debugging on my own.

Barely five minutes later, he came back to my desk and asked me to open a specific file. He then showed me exactly where the pointer bug was. It had taken him only a few minutes not only to read my tangled code but also to understand it well enough to identify the fault and point it out. As soon as I fixed that line, the crashes disappeared. I was genuinely in awe of his skill.

I have always loved computing and programming, so I had assumed I was already fairly good at it. That incident, however, made me realise how much further I still had to go before I could consider myself a good software developer. I did improve significantly in the years that followed and today I am far better at managing software complexity than I was back then.

Animated Television Widgets

In another project from that period, we worked on another set-top box platform that supported Java Micro Edition (Java ME) for widget development. One day, the same architect from the previous story asked whether I could add animations to the widgets. I told him that I believed it should be possible, though I'd need to test it to be sure. Before continuing with the story, I need to explain how the different stakeholders in the project were organised.

Our small team effectively played the role of the software vendor. The final product going to market would carry the brand of a major telecom carrier, offering direct-to-home (DTH) television services, with the set-top box being one of the products sold to customers. The set-top box was manufactured by another company. So the project was a partnership between three parties: our company as the software vendor, the telecom carrier and the set-top box manufacturer. The telecom carrier wanted to know whether widgets could be animated on screen with smooth slide-in and slide-out effects. That was why the architect approached me to ask whether it could be done.

I began working on animating the widgets. Meanwhile, the architect and a few senior colleagues attended a business meeting with all the partners present. During the meeting, he explained that we were evaluating whether widget animations could be supported. The set-top box manufacturer immediately dismissed the idea, saying, 'That's impossible. Our set-top box does not support animation.' When the architect returned and shared this with us, I replied, 'I do not understand. If I can draw a widget, I can animate it too. All it takes is clearing the widget and redrawing it at slightly different positions repeatedly. In fact, I already have a working version.' I then showed a demo of the animated widgets running on the emulator.

The following week, the architect attended another partners' meeting where he shared updates about our animated widgets. I was not personally present, so what follows is second-hand information passed on by those who were there. I learnt that the set-top box company reacted angrily. For some reason, they were unhappy that we had managed to achieve results using their set-top box and APIs that they had officially described as impossible. They demanded that we stop work on animation immediately, arguing that our work could not be allowed to contradict their official position. At that point, the telecom carrier's representative intervened and bluntly told the set-top box representative to just shut up. If the set-top box guy was furious, the telecom guy was even more so, 'You guys told us animation was not possible and these people are showing that it is! You manufacture the set-top box. How can you not know what it is capable of?'

Meanwhile, I continued working on the proof of concept. It worked very well in the emulator, but I did not yet have access to the actual hardware. The device was still in the process of being shipped to us, so all my early proof-of-concepts ran on the emulator. The following week, the architect planned to travel to the set-top box company's office to test my widgets on the real hardware.

At the time, I was quite proud of demonstrating results that even the hardware maker believed were impossible. When the architect eventually travelled to test the widgets on the actual device, a problem emerged. What looked like buttery smooth animation on the emulator appeared noticeably choppy on a real television. Over the next few weeks, I experimented with frame rates, buffering strategies and optimising the computation done in the the rendering loop. Each week, the architect travelled for testing and returned with the same report: the animation had improved somewhat, but it still remained choppy. The modest embedded hardware simply could not keep up with the required computation and rendering. In the end, the telecom carrier decided that no animation was better than poor animation and dropped the idea altogether. So in the end, the set-top box developers turned out to be correct after all.

Good Blessings

Back in 2009, after completing about a year at RSA Security, I began looking for work that felt more intellectually stimulating, especially projects involving mathematics and algorithms. I spoke with a few senior leaders about this, but nothing materialised for some time. Then one day, Dr Burt Kaliski, Chief Scientist at RSA Laboratories, asked to meet me to discuss my career aspirations. I have written about this in more detail in another post here: Good Blessings. I will summarise what followed.

Dr Kaliski met me and offered a few suggestions about the kinds of teams I might approach to find more interesting work. I followed his advice and eventually joined a team that turned out to be an excellent fit. I remained with that team for the next six years. During that time, I worked on parser generators, formal language specification and implementation, as well as indexing and querying engines of a petabyte-scale database. I learnt something new almost every day during those six years. It remains one of the most enjoyable periods of my career. I have especially fond memories of working on parser generators alongside remarkably skilled engineers from whom I learnt a lot.

Years later, I reflected on how that brief meeting with Dr Kaliski had altered the trajectory of my career. I realised I was not sure whether I had properly expressed my gratitude to him for the role he had played in shaping my path. So I wrote to thank him and explain how much that single conversation had influenced my life. A few days later, Dr Kaliski replied, saying he was glad to know that the steps I took afterwards had worked out well. Before ending his message, he wrote this heart-warming note:

‘One of my goals is to be able to provide encouragement to others who are developing their careers, just as others have invested in mine, passing good blessings from one generation to another.’

The CTF Scoreboard

This story comes from 2019. By then, I was no longer a twenty-something engineer just starting out. I was now a middle-aged staff engineer with years of experience building both low-level networking systems and database systems. Most of my work up to that point had been in C and C++. I was now entering a new phase of my career where I would be leading the development of microservices written in Go and Python. Like many people in this profession, computing has long been one of my favourite hobbies. So although my professional work for the previous decade had focused on C and C++, I had plenty of hobby projects in other languages, including Python and Go. As a result, switching gears from systems programming to application development was a smooth transition for me. I cannot even say that I missed working in C and C++. After all, who wants to spend their days occasionally chasing memory bugs in core dumps when you could be building features and delivering real value to customers?

In October 2019, during Cybersecurity Awareness Month, a Capture the Flag (CTF) event was organised at our office. The contest featured all kinds of technical puzzles, ranging from SQL injection challenges to insecure cryptography problems. Some challenges also involved reversing binaries and exploiting stack overflow issues.

I am usually rather intimidated by such contests. The whole idea of competitive problem-solving under time pressure tends to make me nervous. But one of my colleagues persuaded me to participate in the CTF. And, somewhat to my surprise, I turned out to be rather good at it. Within about eight hours, I had solved roughly 90% of the puzzles. I finished at the top of the scoreboard.

In my younger days, I was generally known to be a good problem solver. I was often consulted when thorny problems needed solving and I usually managed to deliver results. I also enjoyed solving puzzles. I had a knack for them and happily spent hours, sometimes days, working through obscure mathematical or technical puzzles and sharing detailed write-ups with friends of the nerd variety. Seen in that light, my performance at the CTF probably should not have surprised me. Still, I was very pleased. It was reassuring to know that I could still rely on my systems programming experience to solve obscure challenges.

During the course of the contest, my performance became something of a talking point in the office. Colleagues occasionally stopped by my desk to appreciate my progress in the CTF. Two much younger colleagues, both engineers I admired for their skill and professionalism, were discussing the results nearby. They were speaking softly, but I could still overhear parts of their conversation. Curious, I leaned slightly and listened a bit more carefully. I wanted to know what these two people, whom I admired a lot, thought about my performance.

One of them remarked on how well I was doing in the contest. The other replied, 'Of course he is doing well. He has more than ten years of experience in C.' At that moment, I realised that no matter how well I solved those puzzles, the result would naturally be credited to experience. In my younger days, when I solved tricky problems like these, people would sometimes call me smart. Now people simply saw it as a consequence of my experience. Not that I particularly care for labels such as 'smart' anyway, but it did make me realise how things had changed. I was now simply the person with many years of experience. Solving technical puzzles that involved disassembling binaries, tracing execution paths and reconstructing program logic was expected rather than remarkable.

I continue to sharpen my technical skills to this day. While my technical results may now simply be attributed to experience, I hope I can continue to make a good impression through my professionalism, ethics and kindness towards the people I work with. If those leave a lasting impression, that is good enough for me.

Read on website | #technology | #programming

Contents

1. Cayley Graphs
2. Vertex-Transitive Graphs
3. Arc-Transitive Graphs
4. Bipartite Graphs and Cycle Parity
5. Tutte's Theorem
6. Tutte's 8-Cage
7. Linear Congruential Generator
8. Numbering Lines

Cayley Graphs

Let \( G \) be a group and let \( C \subseteq G \) such that \( C \) is closed under taking inverses and does not contain the identity, i.e. \[ \forall x \in C, \; x^{-1} \in C, \qquad e \notin C. \] Then the Cayley graph \( X(G, C) \) is the graph with the vertex set \( V(X(G, C)) \) and edge set \( E(X(G, C)) \) defined by \begin{align*} V(X(G, C)) &= G, \\ E(X(G, C)) &= \{ gh : hg^{-1} \in C \}. \end{align*} The set \( C \) is known as the connection set.

Vertex-Transitive Graphs

A graph \( X \) is vertex-transitive if its automorphism group acts transitively on its set of vertices \( V(X). \) Intuitively, this means that no vertex has a special role. We can 'move' the graph around so that any chosen vertex becomes any other vertex. In other words, all vertices are indistinguishable. The graph looks the same from each vertex.

The \( k \)-cube \( Q_k \) is vertex-transitive. So are the Cayley graphs \( X(G, C). \) However the path graph \( P_3 \) is not vertex-transitive since no automorphism can send the middle vertex of valency \( 2 \) to an end vertex of valency \( 1. \)

Arc-Transitive Graphs

The cube \( Q_3 \) is \( 2 \)-arc-transitive but not \( 3 \)-arc-transitive. In \( Q_3, \) a \( 3 \)-arc belonging to a \( 4 \)-cycle cannot be sent to a \( 3 \)-arc that does not belong to a \( 4 \)-cycle. This is easy to explain. The end vertices of a \( 3 \)-arc belonging to a \( 4 \)-cycle are adjacent but the end vertices of a \( 3 \)-arc not belonging to a \( 4 \)-cycle are not adjacent. Therefore, no automorphism can map the end vertices of the first \( 3 \)-arc to those of the second \( 3 \)-arc.

For intuition, imagine that a traveller stands on a vertex and chooses an edge to move along. They do this \( s \) times thereby walking along an arc of length \( s, \) also known as an \( s \)-arc. By the definition of \( s \)-arcs, the traveller is not allowed to backtrack from one vertex to the previous one immediately. In an \( s \)-arc-transitive graph, these arcs look the same no matter which vertex they start from or which edges they choose. In the cube, this is indeed true for \( s = 2. \) All arcs of length \( 2 \) are indistinguishable. No matter which arc of length \( 2 \) the traveller has walked along, the graph would look the same from their perspective at each vertex along the arc. However, this no longer holds good for arcs of length \( 3 \) since there are two distinct kinds of arcs of length \( 3. \) The first kind ends at a distance of \( 1 \) from the starting vertex of the arc (when the arc belongs to a \( 4 \)-cycle). The second kind ends at a distance \( 3 \) from the starting vertex of the arc (when the arc does not belong to a \( 4 \)-cycle). Therefore the cube is not \( 3 \)-arc-transitive.

Bipartite Graphs and Cycle Parity

A graph is bipartite if and only if it contains no cycles of odd length. Equivalently, every cycle in a bipartite graph has even length. Conversely, if every cycle in a graph has even length, then the graph is bipartite.

Tutte's Theorem

For any \( s \)-arc-transitive cubic graph, \( s \le 5. \) This was demonstrated by W. T. Tutte in 1947. A proof can be found in Chapter 18 of Algebraic Graph Theory by Norman Biggs.

In 1973, Richward Weiss established a more general theorem that proves that for any \( s \)-arc-transitive graph, \( s \le 7. \) The bound is weaker but it applies to all graphs rather than only to cubic ones.

Tutte's 8-Cage

The book Algebraic Graph Theory by Godsil and Royle offers the following two descriptions of Tutte's 8-cage on 30 vertices:

Take the cube and an additional vertex \( \infty. \) In each set of four parallel edges, join the midpoint of each pair of opposite edges by an edge, then join the midpoint of the two new edges by an edge, and finally join the midpoint of this edge to \( \infty. \)

Construct a bipartite graph \( T \) with the fifteen edges as one colour class and the fifteen \( 1 \)-factors as the other, where each edge is adjacent to the three \( 1 \)-factors that contain it.

It can be shown that both descriptions construct a cubic bipartite graph on \( 30 \) vertices of girth \( 8. \) It can be further shown that there is a unique cubic bipartite graph on \( 30 \) vertices with girth \( 8. \) As a result both descriptions above construct the same graph.

Linear Congruential Generator

Here is a simple linear congruential generator (LCG) implementation in JavaScript:

function srand (seed) {
  let x = seed
  return function () {
    x = (1664525 * x + 1013904223) % 4294967296
    return x
  }
}

Here is an example usage:

> const rand = srand(0)
undefined
> rand()
1013904223
> rand()
1196435762
> rand()
3519870697

Numbering Lines

Both BSD and GNU cat can number output lines with the -n option. For example:

$ printf 'foo\nbar\nbaz\n' | cat -n
     1  foo
     2  bar
     3  baz

However I have always used nl for this. For example:

$ printf 'foo\nbar\nbaz\n' | nl
     1  foo
     2  bar
     3  baz

While nl is specified in POSIX, the cat -n option is not.

Read on website | #monthly | #mathematics | #programming | #javascript | #shell

This release contains a minor bug fix in Unit 4.3. Unit 4.3 is a 'Control' unit that lets you practise typing partial words as well as full words. In one place in this unit, the following sequence of partial and full words occurs:

l li lime lime

The full word lime was incorrectly repeated twice. This has been fixed to:

l li lim lime

To try out QuickQWERTY, go to quickqwerty.html.

Read on website | #web | #programming

First came the infamous infinite scroll. I remember feeling uneasy the first time a web page no longer had a bottom. Logically, I knew very well that everything a browser displays is a virtual construct. There is no physical page. It is just pixels pretending to be one. Still, my brain had learned to treat web pages as objects with a beginning and an end. The sudden disappearance of that end disturbed my sense of ease.

Then came the bogus notifications. What had once been meaningful signals turned into arbitrary prompts. Someone you followed had posted something unremarkable and the platform would surface it as a notification anyway. It didn't matter whether the notification was relevant to me. The notification system stopped serving me and started serving itself. It felt like a violation of an unspoken agreement between users and services. Despite all that, these platforms still remained social in some diluted sense. Yes, the notifications were manipulative, but they were at least about people I actually knew or had chosen to follow. That, too, would change.

Over time, my timeline contained fewer and fewer posts from friends and more and more content from random strangers. Using these services began to feel like standing in front of a blaring loudspeaker, broadcasting fragments of conversations from all over the world directly in my face. That was when I gave up on these services. There was nothing social about them anymore. They had become attention media. My attention is precious to me. I cannot spend it mindlessly scrolling through videos that have neither relevance nor substance.

But where one avenue disappeared, another emerged. A few years ago, I stumbled upon Mastodon and it reminded me of the early days of Twitter. Back in 2006, I followed a small number of folks of the nerd variety on Twitter and received genuinely interesting updates from them. But when I log into the ruins of those older platforms now, all I see are random videos presented to me for reasons I can neither infer nor care about. Mastodon, by contrast, still feels like social networking in the original sense. I follow a small number of people I genuinely find interesting and I receive their updates and only their updates. What I see is the result of my own choices rather than a system trying to capture and monetise my attention. There are no bogus notifications. The timeline feels calm and predictable. If there are no new updates from people I follow, there is nothing to see. It feels closer to how social networks used to work originally. I hope it stays that way.

Read on website | #web | #technology

One of the caveats of the Markdown universe is the wide variety of Markdown implementations available. In these parallel universes, the rules of Markdown rendering differ subtly. In this post, we will focus only on the CommonMark specification. Since GitHub Flavoured Markdown (GFM) is a strict superset of CommonMark, whatever we discuss here applies equally well to both CommonMark and GFM.

Contents

• Basic Code Fences
• Fancy Code Fences
• Basic Code Spans
• Fancy Code Spans
• Specification

Basic Code Fences

Corey had a knack for working with computers ever since he was a kid.

Corey at his computer:

```
(o_o)--.|[_]|
```

Everything was perfect in Corey's world. The CommonMark renderer would convert the Markdown above to the following HTML:

(o_o)--.|[_]|

<p>Corey at his computer:</p>
<pre><code>(o_o)--.|[_]|
</code></pre>

At this point, all was well. Corey grew quickly. Before long, he had a head full of spiky hair. Then the fences began to matter.

Corey, all grown up:

```
 ```
(o_o)--.|[_]|
```

Let us see how this renders. I must warn you that during the Markdown-to-HTML translation, Corey loses his hair. Some viewers may find the following scene disturbing. Viewer discretion is advised. Here is the rendered HTML:

<p>Corey, all grown up:</p>
<pre><code></code></pre>
<p>(o_o)--.|[_]|</p>
<pre><code></code></pre>

Corey's hair is gone! What a catastrophic accident! Corey is alright, though. He is still quite afraid of Markdown fences, but otherwise well and bouncing back. Why did this happen? The second set of triple backticks immediately ends the fenced code block started by the first set of triple backticks. As a result, Corey's smiley face ends up outside the fenced code block. The triple backticks that were once Corey's hair are now woven into the fabric of the surrounding HTML. Fortunately, CommonMark offers a few ways to avoid such accidents.

Fancy Code Fences

In CommonMark, fenced code blocks are most commonly written using triple backticks. However, the specification also allows tildes as an alternative fence. This can be useful when the code itself contains backticks. Let us see an example:

Corey, all grown up:

~~~
 ```
(o_o)--.|[_]|
~~~

In fact, a code fence need not consist of exactly three backticks or tildes. Any number of backticks or tildes is allowed, as long as that number is at least three. The following is therefore equivalent:

Corey, all grown up:

~~~~~
 ```
(o_o)--.|[_]|
~~~~~

And so is this:

Corey, all grown up:

`````
 ```
(o_o)--.|[_]|
`````

All three examples render like this:

 ```
(o_o)--.|[_]|

<p>Corey, all grown up:</p>
<pre><code> ```
(o_o)--.|[_]|
</code></pre>

No hair is lost in translation.

Basic Code Spans

A similar problem arises with inline code spans. Most Markdown users know to use backticks to delimit inline code spans. For example:

An old picture of Corey at his computer: `(o_o)--.|[_]|`

This produces the following output:

<p>An old picture of Corey at his computer: <code>(o_o)--.|[_]|</code></p>

However, what do we do when we need to put Corey's dear friend Becky Trace within an inline code span? Becky has short, straight hair tucked neatly on either side of her face. Here's a picture of her:

`(o_o)`

I believe you can already see the difficulty here. Inline code spans use backticks as delimiters. So when we put Becky within a code span, the first backtick in Becky's face would terminate the code span immediately and then the rest of Becky would lie outside it. CommonMark offers solutions for this kind of situation as well.

Fancy Code Spans

An inline code span delimiter need not consist of exactly one backtick. It can consist of any number of backticks. So `foo` and ``foo`` produce identical HTML. There is another important but less well-known detail. When the text inside an inline code span begins and ends with spaces, one space is removed from each end before rendering. So `foo` and ` foo ` are equivalent. Therefore, when we need to put backticks within an inline code span, we can start the code span using multiple backticks and a space. For example:

Meet Corey's friend Becky Trace: `` `(o_o)` ``

Here is the rendered output:

<p>Meet Corey's friend Becky Trace: <code>`(o_o)`</code></p>

Becky has her hair intact too. We have avoided the mishap that once caused great distress to Corey. That, my friends, is how backticks survive nesting in Markdown.

Specification

Before I finish this post, let us take a look at the CommonMark specification to see where these details are defined. The excerpts quoted below are taken from CommonMark Spec Version 0.30, which is by now over four years old.

From section 4.5 Fenced Code Blocks:

A code fence is a sequence of at least three consecutive backtick characters (`) or tildes (~). (Tildes and backticks cannot be mixed.)

The content of the code block consists of all subsequent lines, until a closing code fence of the same type as the code block began with (backticks or tildes), and with at least as many backticks or tildes as the opening code fence.

From section 6.1 Code Spans:

A backtick string is a string of one or more backtick characters (`) that is neither preceded nor followed by a backtick.

A code span begins with a backtick string and ends with a backtick string of equal length. The contents of the code span are the characters between these two backtick strings, normalized in the following ways:

• First, line endings are converted to spaces.
• If the resulting string both begins and ends with a space character, but does not consist entirely of space characters, a single space character is removed from the front and back. This allows you to include code that begins or ends with backtick characters, which must be separated by whitespace from the opening or closing backtick strings.

I hope these little nuggets of Markdown trivialities will one day prove useful in your own Markdown misfortunes.

Read on website | #web | #technology

Contents

• Empty Workflow
• On
• On Push
• Jobs
• Job ID
• Steps
• Runs On
• Runs On Ubuntu Latest
• Empty Steps
• Run
• Run Echo
• Hello, World

Empty Workflow

For the first experiment we just create a zero byte file and push it to GitHub as follows, say, like this:

mkdir -p .github/workflows/
touch .github/workflows/hello.yml
git add .github/
git commit -m 'Empty workflow'
git push -u origin main

Under the GitHub repo's Actions tab, we find this error:

Error
No event triggers defined in `on`

On

Then we update the workflow as follows:

on:

Now we get this error:

Invalid workflow file: .github/workflows/hello.yml#L1
(Line: 1, Col: 4): Unexpected value '', (Line: 1, Col: 1): Required property is missing: jobs

On Push

Next update:

on: push

Corresponding error:

Invalid workflow file: .github/workflows/hello.yml#L1
(Line: 1, Col: 1): Required property is missing: jobs

Jobs

Workflow:

on: push
jobs:

Error:

Invalid workflow file: .github/workflows/hello.yml#L1
(Line: 2, Col: 6): Unexpected value ''

Job ID

Workflow:

on: push
jobs:
  world:

Error:

Invalid workflow file: .github/workflows/hello.yml#L1
(Line: 3, Col: 9): Unexpected value ''

Steps

Workflow:

on: push
jobs:
  world:
    steps:

Error:

Invalid workflow file: .github/workflows/hello.yml#L1
(Line: 4, Col: 11): Unexpected value '', (Line: 4, Col: 5): Required property is missing: runs-on

Runs On

Workflow:

on: push
jobs:
  world:
    runs-on:
    steps:

Error:

Invalid workflow file: .github/workflows/hello.yml#L1
(Line: 4, Col: 13): Unexpected value '', (Line: 5, Col: 11): Unexpected value ''

Runs On Ubuntu Latest

Workflow:

on: push
jobs:
  world:
    runs-on: ubuntu-latest
    steps:

Error:

Invalid workflow file: .github/workflows/hello.yml#L1
(Line: 5, Col: 11): Unexpected value ''

Empty Steps

Workflow:

on: push
jobs:
  world:
    runs-on: ubuntu-latest
    steps: []

Error:

Invalid workflow file: .github/workflows/hello.yml#L1
No steps defined in `steps` and no workflow called in `uses` for the following jobs: world

Run

Workflow:

on: push
jobs:
  world:
    runs-on: ubuntu-latest
    steps:
      - run:

Success:

▼ Run

  shell: /usr/bin/bash -e {0}

Run Echo

Workflow:

on: push
jobs:
  world:
    runs-on: ubuntu-latest
    steps:
      - run: echo

Success:

▼ Run
  echo
  shell: /usr/bin/bash -e {0}

Hello, World

Workflow:

on: push
jobs:
  world:
    runs-on: ubuntu-latest
    steps:
      - run: echo hello, world

Success:

▼ Run echo hello, world
  echo hello, world
  shell: /usr/bin/bash -e {0}
hello, world

The experiments are preserved in the commit history of github.com/spxy/minighwf.

Read on website | #technology