Well, turns out, reading-wise, 2023 was the year of Plato. As mentioned back in the 2021 list, I've set out on reading through his works. At this point I'm about half-way through. I didn't know what I was getting myself into when I first opened up the collection, but I have to say I'm really enjoying myself. Not only are Plato's words worthy of pondering and contrasting with modern thought, they're also entertaining. Ideas that shaped over two millenia of philosophy are interspersed with wit, humor, sometimes even sharp sarcasm.

Anyways, here's the list of dialogues I got through last year:

1. Parmenides
2. The Sophist
3. The Statesman
4. Philebus
5. Symposium
6. Phaedrus
7. Alcibiades
8. Second Alcibiades
9. Hipparchus
10. Rival Lovers
11. Theages
12. Charmides
13. Lysis
14. Protagoras
15. Gorgias

If you're a selfhosting enjoyer like me, you may have been using Luke Smith's wonderful emailwiz to host your very own email server. It's a simple script that allows you to not think much: just run it on your Debian box, and it will install everything, and then tell you all the DNS records you need to set for your email server to work correctly. This includes records for the DMARC, DKIM, and SPF protocols, which increase security and help prevent spam. So just make sure to follow these instructions, and you can send mail anywhere.

Or can you?

It's a common complaint you hear from people selfhosting their email server: the server works fine, you can send and receive email for the most part, but there are several email hosts that just will never accept mail from you, replying with those dreaded "Undelivered Mail Returned to Sender" messages. The biggest culprit being gmail, which also happens to have the biggest market share of personal emails. Meaning you can't send anything to your friends, or even less established businesses and organizations that simply keep using their personal gmail accounts for communications.

The error message gmail will return contains something like this:

The IP address sending this 550-5.7.25 message does not have a PTR record setup,
or the corresponding 550-5.7.25 forward DNS entry does not point to the sending
IP. As a policy, 550-5.7.25 Gmail does not accept messages from IPs with missing
PTR records. 550-5.7.25 For more information, go to 550 5.7.25

My, and probably many others', conspiracy theory has always been that gmail is just malicious towards new email hosts, especially small selfhosting landchads. Turns out that it's something different: gmail just happens to be more strict about SPF records! Something that Luke missed.

SPF (the Sender Policy Framework) specifies several mechanisms. You can read more about them here. Luke's script only specifies a and mx mechanisms (plus the general -all to reject anything not matching those). But you can also explicitly specify the IP addresses allowed to send mail from your domain with ip4 and ip6 mechanisms. And it looks like gmail requires these to be specified to accept your email. I guess you could look for some maliciousness in the fact that they're not clearer about what one has to fix to comply with their policies. But in the end, the solution is...

TL;DR

If you're getting 550-5.7.25 errors from gmail, make sure you do have your PTR record set up correctly, but also that your SPF record looks something like this:

v=spf1 mx a:<your mail host> ip4:<your IPv4 address> ip6:<your IPv6 address> -all

Credits

I got to this solution after the owner of storin.nl emailed me about nocss.club. When I tried to reply to him, I got an "Undelivered Mail Returned to Sender" reply, but with a different error message than gmail's:

not allowed to send mail from 550 m-chrzan.xyz: Please see
http://www.open-spf.org/Why : Reason: mechanism (in reply to RCPT TO command)

Tom from tfaz.xyz is working on a PR to emailwiz to correct the SPF record.

And big thanks to Luke for emailwiz, without it I wouldn't even have my own mail server to begin with.

• It's open source.
• Syncs with git (which I can selfhost).
• The underlying format is just MarkDown, which means that I can easily edit the notes on my laptop with my editor of choice.

But there's also some issues I kept running into:

• Search is not very good (in particular, there's no in-page search, only searching for notes that contain a certain string)
• The hierarchical organization of notes is nice and simple, but has its limits, not all relationships between ideas are tree-like.
• The git implementation on the mobile app has its problems. E.g. merge conflicts are not going to be resolved, sometimes leading to forced commits that remove notes. All of this can be resolved on a computer with access to the repo, but it can become a hassle.
• There's no easy way to link between notes, which could have been very nice.
• Some other bugs I've noticed, e.g. sometimes duplicate notes appearing, or others completely disappearing (could be caused by the git issues mentioned above, or the way I was managing notes computer-side away from the app).

None of these issues are absolute deal breakers, and I still think GitJournal is a really nice solution that I can recommend, but all the slight annoyances led me on a search for a potential replacement. If I didn't find anything better, I would have been happy to stick with GitJournal, but maybe there's a note taking solution somewhere out there that would suit me better?

If you do some research on note taking apps you'll be greeted with a flood of content from "productivity" YouTubers, bloggers, etc. Turns out there's a ton of options for different types of workflows and preferences, however most of them are

• proprietary
• bloated
• for syncing, require registration with a SaaS startup that you have no idea how long it will stay in business, or how much of their monetization model depends on scraping your data.

Enter LogSeq.

Enter LogSeq

Let me start off by saying that LogSeq is not the perfect solution for me, but I'll go over my personal gripes with it later. First, let's talk about what LogSeq even is and what's good about it.

LogSeq is an open source note taking application that is privacy-first, outline-based, non-hierarchical, and features bidirectional linking. Let's break that down:

• Privacy-first: all notes are stored as plain-text files on your computer. By default, there's no synchronization; in particular, there's no central server the app talks to.
• Outline-based: each line of text is a bullet point (and these can be nested), there's no plain paragraphs/headings like in MarkDown or basic HTML.
• Non-hierarchical: notes are not organized into a tree-like directory structure. Instead, each note is a separate page, and you organize your notes by linking/tagging between pages.
• Bidirectional linking: these links between pages go in two directions, i.e. when page A links to page B, page B will have a section of backlinks, making it easy to jump back to where B is referred from (be that back to page A, or any other pages that link to B).
  • This feature is inspired by another app, Obisidan, which you might be familiar with. Both Obisdian and LogSeq are touted by some to be good tools for building a so-called "second brain."

Some other features to mention:

Journal

LogSeq automatically creates daily journal pages. These can be used for journaling or as a dumping spot of random ideas, links you encounter, notes to jot down. Thanks to backlinks, if you include tags or links to topic pages in your notes, you'll be able to find these seemingly chaotic daily notes when looking at a specific topic later.

Plugins

There is a plugin interface, and an already fairly large marketplace of community-built plugins available. Many are just visual tweaks you can add if you like them, there's also a bunch of integrations with various other note taking/productivity apps (which I personally don't use, but many find them useful, from what I hear, in their workflows). There's really only one plugin I'm using currently, more on that in the next section, but overall its nice to see extensibility.

Synchronization

As mentioned, there's no synchronization enabled by default. There is a recommended cloud sync option with LogSeq's servers, which respects your privacy by end-to-end encrypting all your content, but you know me. I prefer to sync my notes with git. Not only does this allow me to selfhost my notes, it also gives me all the benefits of version control (history, a way to deal with merge conflicts when dealing with multiple devices).

Since all of LogSeq's note files are just plain-text on your disk, setting up git synchronization is trivial: just make the notes directory a git repo, add a remote, and voilá.

Here's also where a plugin comes in useful: there's a git plugin that makes it easy to commit, push, and pull changes from within LogSeq itself, rather than having to switch between it and a terminal.

Note: LogSeq does have a separate built-in version control feature that's based on git, but I recommend against it. It's based on automatically committing every x seconds, so you never exactly know if your latest changes are already committed, and you end up with a very messy history of partial and/or unrelated changes going into individual commits.

Mobile app

There is a functional mobile app, with the same look and most of the same features as the desktop application. It is missing plugins, so in particular, no git plugin. git synchronization on Android is still possible with Termux, but less convenient than on a desktop, since it requires you to manually go into Termux to commit/push/pull changes (and be very careful of ending up with a merge conflict on your phone, that's much less fun to deal with on a phone screen than in your favorite desktop editor).

Other features

• Aliases: you can create aliases for tags, so that when you tag a note with any of the aliases, it will still point to the original tag. For example, if you have a tag "book", and add an alias "books", you won't have to remember if the tag was in the singular or plural.
• To-do lists.
• Scripting/queries: this is a feature I haven't looked into much yet, but it sounds very useful. You can write queries in a very general syntax to find notes that satisfy particular conditions. E.g. find all articles (tagged with #article) that are about graph theory (tagged with #[[graph theory]]) published in the last year (a date property is within a particular time frame).
• Embedding blocks: a bullet point (with everything nested below it) can be directly embedded elsewhere (such that editing either instance changes both).
• Whiteboards.
• The Graph: a visualization of links/relationships between your pages.
• Flash cards.

The first two I use regularly. Queries I want to eventually get into. The others I don't really find use for.

Problems

There are a few things I'm personally not a fan of with LogSeq.

Bloat

The biggest general problem for me is that despite a nice, minimal interface, LogSeq is an Electron application. The logseq-desktop-bin AUR package is 500MB! All for a note taking application. In addition to the bloat coming from Electron, I think a lot of it is also features that I have absolutely no use for (like the aforementioned graph view and whiteboards, which go way beyond basic text editing and markup).

Many people these days brush bloat under the rug, saying that on modern machines it doesn't matter, and frameworks like Electron are good because it means faster, simpler development. But these problems do end up having consequences. For example, LogSeq struggles with large files.

The full text of Shakespeare's Othello (around 160KB) takes several seconds to load, and the app displays a bright orange warning message that "Large blocks will not be editable or searchable to not slow down the app." vim opens the same file in a fraction of a second, a web browser takes maybe about a second.

Not exactly MarkDown

The LogSeq team say that the underlying text files are just MarkDown, but that's not exactly true.

The notes have to be all organized into bullet points, you don't have plain paragraphs or headings. Furthermore, additional markup is inserted, e.g. for block references. All of that makes the text less human-readable/-editable, a core feature of MarkDown.

Which leads to the next very sad problem...

It's not vim

Once you get used to vim, all other text editing options are just inferior. Bram's gift to humanity is both a blessing and a curse, since there's no getting away from sometimes needing to edit text outside of it.

Yes, there's a "vim" plugin that implements some keybindings, but I tend to stay away from those, as they're always disappointing: they implement some of the most basic keys, but others I'm used to relying on are not supported. So I'd have to remember which plugin for which piece of software implements which ones, and it just becomes more of a hassle than a convenience.

As mentioned above, using vim directly on the text files is also not a solution, since the notes format is not exactly standard MarkDown, and either way you'd lose all the benefits of LogSeq, especially links/backlinks.

Conclusions

So, with that ranty section above over, what's my final verdict on LogSeq? I've been using it daily for the past several months, and until something better comes along, I don't plan on switching. Despite all its shortcomings, I really like it, it helps me organize my notes and thoughts.

I was actually aware of Obsidian before, and it had piqued my interest, seemed like a useful tool. However, I didn't want to jump onto a proprietary note taking solution. When doing my recent research on these apps, I found LogSeq, which is a FOSS alternative. I was reluctant at first, for all the reasons stated above, but after just a bit of test running, turns out the benefits outweigh the trade-offs I have to make, and LogSeq has replaced GitJournal for me.

The pipe dream

To finish this post, let me go on a little fantastical journey into what my ideal note taking solution would look like.

• Given my vim addiction, it would be a vim plugin.
• Given my newly-found backlink addiction, the plugin would implement backlinking (e.g. displaying backlinks to a note in a separate pane, with links that can be followed VimWiki-style).
• Plain MarkDown syntax for notes.
• An easy-to-use query syntax.
• An Android application that supports backlinks, queries, and git.

From a purely technological perspective, these AI developments look incredible. We're getting to the point where computer assistants we know from sci-fi films are becoming an every day reality.

But what are the wider implications of this?

There's tons of potential societal outcomes this could lead to, starting with kids a few years from now wondering why Tony Stark is the only character with an all-knowing AI assistant in Iron Man, all the way to a full singularity event. For this article, I'll focus on just one aspect: Internet content.

AI content on the web

For some time already, there's been a ton of AI-composed or -aided "content" on the web. You may have heard others (e.g. Luke Smith, Jacob Smith; no relation between the two as far as I'm aware) complaining about the generic SEO garbage sites that just produce tons of generic, search-engine friendly articles on commonly searched topics, just to farm clicks and ad views.

More recently, as various advanced language models started being published, people started speculating that eventually AI will start replacing even the higher-class content. YouTuber penguinz0 claims that, in his opinion, a bit of playing around with ChatGPT produced a better game review than a popular game journalism website. BuzzFeed openly stated that they will start publishing AI generated articles.

One author

While people have been suspecting that eventually more and more content will be generated, Microsoft is now straight up recommending you do it now (see minute 37:30 of the press conference, linked above).

Composing individual social media posts might not seem like that big of a deal. But it is if you take into account how media builds upon itself. Much content is created by citing, commenting on, being inspired by other content. And AI is itself specifically suited to quickly generating this sort of derivative material. As the density of AI generated content increases, its rate of increase will start to grow non-linearly.

Just imagine. A Wikipedia article cites that so-and-so said something on Twitter. That The Guardian reported that this or that happened. A leaked email from so-and-so revealed that... But all those sources were written by AI. And maybe the article itself was composed with the help of Bing's compose functionality?

Then you search for something relevant and the Bing bot reads the article and provides you an answer based on it. Maybe you're smart enough to double check there are "real" sources to corroborate the bot's answers and it's not something it made up, so you find the Wikipedia article yourself, full of external citations, and are satisfied.

But fool you are, the internet has one author.

• Joined WLOD, a brass orchestra that plays traditional dance music from the Roztocze region of Poland (actually joined it late last year, but this year's season was much more active).
• Also joined WLOD's funeral sub-orchestra, where we play traditional funeral marches from the repertoire of Roztocze orchestras.
• Joined Bonanza, a small ensemble playing mostly oldies music from the 1920s-30s popular in Polish cities (initially as a substitute, now as a full member).
• Spent most of the summer going to various traiditional music events.
• Finally completed my master's in computer science! You can check out my thesis here and the LaTeX sources for it here.
• Don't expect a "Books read in 2022" article, didn't read that much this year, unfortunately, but planning on doing so more in the coming months.
• The Sunday Corner was empty for quite a stretch of time, but I've been more regular on updating it recently. No promises as to whether this trend will continue, but you might want to start checking it out once in a while again if you enjoyed it but stopped after it was inactive for a while.

So in summary, a year of traditional music. This has been my main focus in the past months, and I want to continue in this direction, widening my repertoire, improving my fiddling skills, expanding tuturutu.net , and maybe even starting my own band eventually.

And since it's that time of the year, Dear Reader, I'm wishing you a Merry Christmas and a happy New Year!

Anyways, here's the list:

1. The Shallows, Nicholas G. Carr. Words of warning about how the internet and computer technologies negatively affect our lives. In my opinion, Carr's takes aren't quite spicy enough, and the Ellul book mentioned below gives a much fuller picture of how cautious we should be of technology. That said, this might work as a decent wake up call for anyone not quite yet ready to jump into 300 pages of dense sociology that Ellul presents.

2. The Great Gatsby, F. Scott Fitzgerald. Finally got around to reading this classic.

3. The Enchiridion, Epictetus. A very quick read, works as a nice summary of the stoic position.

4. Foundation, Isaac Asimov. Finally got around to reading this sci-fi classic.

5. The Technological Society, Jacques Ellul. I actually started reading this in 2020 but didn't get far, picked it up and finished the rest of the way in 2021. A very good read, highly recommended reading if at any point you've run across Ted Kaczynski's manifesto and any part of it intrigued you.

   Ellul takes a deep dive into how technology (or more generally, technique, which by his definition is any process that is the best currently known for achieving a particular goal) has interacted with and changed our humanity.

6. First Philosophers (second half, on the sophists), Robin Waterfield. As mentioned in last year's post, I read half of this in 2020. Honestly the first half on the presocratics was much more interesting. Now, at the end of 2021, I don't remember much from the sophists at all.

7. Can Life Prevail, Pentti Linkola. A much more radical take on what it means to "save the envrionment" than what you'll hear on TV. Linkola spent his life studying the declining health of European forests and bird life, and fishing using traditional methods. He speaks about nature from the point of view of a brother, not a virtue signaling committee.

8. Crisis of the Modern World, René Guénon. Though written in the 1920s, the symptoms of crisis Guénon described have only grown stronger by the 2020s. He ends up dealing with some of the same subjects as the Ellul book mentioned previously, but from the point of view of esoterics and tradition rather than technology.

9. Plato's dialogues. I'm reading from the version of his complete works edited by John M. Cooper and D. S. Hutchinson. I haven't officially committed to going through the whole thing, I'll just keep going until I'm bored and decide to switch to something else. Here's the dialogues I got through this year:

   1. Euthyphro. Happens days before Socrates' trial. Socrates and Euthyphro discuss the meaning of piety and justice.

   2. Socrates' apology. Plato's rendition of Socrates defending himself in court against the charges of impiety and corruption of the youth.

   3. Crito. Socrates' friend visits him in prison, trying to convince him to attempt an escape before his execution. Socrates explains, much to Crito's disappointment, why it would be improper for him to do so.

   4. Phaedo. Several of Socrates' friends visit him the day of his execution. Socrates attempts to lift their spirits with a discussion about death and the afterlife, before (spoiler alert) drinking the kool-aid.

   5. Theaetetus. Socrates speaks with a young student of philosophy about the nature of knowledge. They try out a few different potential definitions, unhappy with each, arriving at absurdities and contradictions with each attempt. This dialogue has an overall very conversational and even light-hearted style, while getting into some really complex and dense case analysis at times.

Making money off of video game skins is a very shrewd idea: you pay for a few hours of a graphic designer's time, and from then on can sell limitless copies of the item, each sale being instantaneous, requiring no shipping, no storage, no store front. If you're able to pull it off, it's better than print-on-demand or drop shipping.

But so far this sort of model has been mostly limited to gaming. This is a very specific demographic, mostly male, skews towards younger people, and even among them, only the gamers most emotionally invested in the game will be willing to spend money on cosmetic items.

Now, if Fortnite skin sales can support a large development studio that then ends up with enough money for some of the craziest marketing stunts, imagine the profits if you could widen the demographic from "gamer" to "your average internet user".

This is exactly the opportunity that Zuck and others are investing billions of dollars into under the memes of VR and NFTs. By directing your average internet user into a virtual reality as a primary means of interacting with social circles, work, and digital media, and doing so in an anthropomorphized avatar (a word that became increasingly creepy with each repetition of it from Zuck's mouth during the Meta announcement), Meta and others focused on VR will create emotional attachment to a gamified reality where products can be produced even more cheaply than previously possible with humid sweatshops and child labor.

VR didn't succeed at first because it was just a gimmick that made some people puke, but there wasn't enough profit to be made for companies to keep investing into research and development around it. With the perfect storm of "NFT" becoming the hottest Silicon Valley buzzword and more people switching to a work-from-home lifestyle, some of the tech opportunists, including Zuck, must have finally put 2 and 2 together, finally seeing a reason to begin pumping cash into VR again.

The medium is the message. It is far less important what VR will be used for (it will still be just social media, online shopping, communications, gaming, and other entertainment, like current technologies), far more important how it can be used to affect people and their behaviors.

Furthermore, do not get your hopes up thinking that by embracing NFTs, Facebook or any other big tech silo is going to move towards decentralization. "NFT" just stands for "non-fungible token", there's nothing about decentralization in the name. Do you really think Zuck will use decentralized, trustless, uncensorable protocols like Ethereum, or will it be safer (from his profits' perspective) to put everything on Libra/Diem, or even more likely, just chuck it all in a database? Oh, Zuck promised you interoperability with other "metaverse" protocols? Yeah, that's just going to be an API hosted in Meta's data centers.

TF2 hats are NFTs. Fortnite skins are NFTs. To illustrate the point, this post is now an NFT, running on the m-chrzan.xyz ledger.

I'm air dropping it to Tom Fasano. The bottom of this post will work as a public block explorer of the ledger. If the current owner of the NFT wants to transfer it, he or she should email me and provide me with acceptable contact details (ideally email+PGP key or an XMPP address) of the new owner.

For those curious about technical details of the m-chrzan.xyz ledger, here is the whitepaper:

The m-chrzan.xyz ledger is based on novel PoM (Proof of Martin) technology. The ledger is guaranteed to be secure and live as long as 100% of the Martins running it act honestly and maintain uptime.

The m-chrzan.xyz Ledger:

History of ownership of the m-chrzan.xyz/blog/the-nft-vr-cash-grab.html NFT:

1. Tom Fasano (minted on December 29, 2021)

But there is a second, more technical why question we could ask: why did modern music arrive at the specific qualities it arrived at? I want to posit a potential, partial reason for why all songs on the radio are in a 4/4 time signature. The idea to write this came to while thinking about whether Polish traditional music could have evolved into something popular with the modern masses, the way Negro spirituals evolved into blues, evolved into rock.

Much of Polish music, before it became replaced by Western influences, was based on 3/4 rhythms. The wild, trance-like spinning of the mazurek and oberek, or the slower, more waltz-like kujawiak are all counted in 3. Why could these rhythms not survive the musical revolutions of the mid 20th century?

It is not for a lack of energy and liveliness in the music. Just look at the sort of a musical fire an old man from a small village can spark up with a fiddle: www.youtube.com/watch?v=io-RC6USnyk. It's not even necessarily the crazy, non uniform rhythms of the music that would have been a problem. Should the mazurek have been destined to influence modern popular music, the industry would have watered down and simplified its complexities for the shopping center visitor's ears. That of course would have been a great disservice to the music and I'm glad it didn't happen, but it was possible.

The problem I see is technical, and comes down to the fundamental design of the mazurek, its purpose being contrary to what is necessary for modern popular success. So let's first talk about the technical requirements of modern music.

During the 20th century music became an entertainment product for individuals. It is a music you listen to on the radio while cleaning the house, in headphones on a commute. You don't go to a concert just to spend time with friends, but in large part to have an individual experience of the music. To say "I was there, I heard them, I saw them". Of course there is still a social aspect to concert-going, but in centuries past, it was the primary aspect of music making. It was a social glue and lubricant in the same way as alcohol. These days when you go to a concert, you sit or stand in your own spot, facing the stage, and experiencing the music on your own, inside your own mind, inside your own body. Maybe jumping up and down with the rest of the crowd, but you're doing the jumping by yourself.

You can't jump to an oberek in a mosh pit under the stage. It simply won't work. If you jump on every beat, it will be too fast. If once a measure, it's going to be awkward and too slow. Either way, it's just not going to feel right. The oberek is a dance fundamentally designed to be danced spinning with a partner. That's what the accents guide you towards. There is a flywheel effect of one partner leading in one measure, the other in the other measure. It simply is not a music for individuals. And that's a good thing.

VR as a social and communication medium, which appears to be Zuck's focus, and is likely to end up being one of the widest VR markets in terms of number of users and overall man-hour usage time, is not progress in any way. It doesn't actually introduce any new features that would make life better. It will never replace real world human connections as Zuck seems to imply it can. At least not until we reach Matrix-levels of simulation, but that comes with a whole host of other obvious problems.

Remember — it's not social media, it's marketing media. VR social media is simply a huge investment of developer time, and a trade off of internet bandwidth, to squeeze extra attention and shopfront-facing time from users. VR is fancy, engaging, and can probably be made to be even more addicting than the current flat phone screens. Just like it's hard to take your eyes off of a flashing TV screen, even if you're not actively interested in what's currently on, it will be difficult for the people that plug themselves into VR to take the headset off. Zuck talked a lot about interoperability of "metaverse" systems: this is also going to be useful from a profits perspective, by seamlessly guiding users (useds in Stallmanian terms) from a chat with friends to purchasing a new product.

Internet ads already replaced magazine, newspaper, radio, and to an extent even TV ads. By building a simulated world for people to spend time in and move around, Zuck (and other VR investors) could now also steal market share from highway billboards, sidewalk posters, and other places we encounter marketing while moving around the physical world.

That's all there is to it. If you see Zuck investing billions into a new effort, remember that it's to see a return on investment. And for a marketing product like Facebook, returns come from sapping human attention.

Quick word of warning: it's 100% in Polish, so you probably won't get much use out of it if you're not a Polish speaker. Even if you are, you probably still won't get much use out of it if you're not interested in traditional music.

In this post I'll go over three things: the what, the why, and the how of tuturutu.net.

What is tuturutu.net?

Right now the website is just a simple listing of a few songs from Polish villages, mostly the types that would be sung at a wedding, or otherwise related to the concept of love. I got most of the lyrics at a week-long workshop I went to a year ago.

Most of the lyrics also have short sheet music notating the main vocal melody. For the most part, these are transcribed by ear by me, hopefully there aren't any inaccuracies. That said, the sheet music is only provided for reference, and honestly should not be used to learn the songs. Classical notation is an imperfect tool for this purpose, as in the real world the melodies often vary from performer to performer and freedoms can be taken with both rhythm and pitches. The best way to learn is to listen to performances (if possible, live performances; and in those cases, bonus points if it's in an environment where you can join the singing, not just listen to it like at a concert, further bonus points if you're dancing while doing it).

Where I could find them, recordings from YouTube or Bandcamp are linked.

Each song is downloadable as an individual PDF for convenient offline storage, or for printing individual songs for distribution to a group learning them.

On the main page, there's also a PDF that's a songbook containing all of the songs. This is, in my opinion, the main "product" on the website. All the song pages on the website are nice if you need to quickly look something up, but if you're going to be needing the songbook at a party, it's probably best to download the whole thing and use that (it looks good on large screen ereaders, and has a clickable index). Very printable, too!

Why did I build this?

Primarily just for myself. In the recent months I'd been going to some parties where this sort of traditional music would be played, but when trying to Google some of the lyrics I would hear people singing, I wasn't able to find anything. Additionally, the lyrics I did have from the workshop I mentioned before were stored in my phone's camera's folder as photos I took of somebody else's phone screen showing a photo from a Facebook post of a laptop screen with a Word document open. Seriously. They weren't easy to find and definitely weren't searchable. So if I couldn't rely on lyrics websites that already exist, I decided I need to create something of my own. And the nice thing is, my website can be as clean as I want it to be, rather than a bloated mess of newsletter popups, cookie preferences, and flashing ads.

As mentioned above, the sheet music on the website is not really provided for anyone to use to learn the melodies. Instead, since currently I myself am the target audience of this website, the sheet music is there to remind me the melodies if I ever forget them (which I sometimes do). If anyone else finds them useful, great. Again, I do recommend learning by ear instead.

For now the website is just a small index of a few songs I know. If I have the time and motivation (or funding/volunteers), I would love to expand it to a much wider and more general archive of this sort of music.

The songbook will probably receive a field test in the coming days, as the next edition of the workshop I went to last year is coming up, and we might end up using tuturutu.net as the "official" songbook.

How is tuturutu.net implemented technically?

Just like this website, tuturutu.net is a static site. I adapted the Ruby script that generates this website to build the songbook website, which is simpler in some ways, and more complex in others. Instead of a list of blog articles written in (potentially templated) HTML, the sonbgook website has, for each song, up to three files:

1. song.txt: a plain text file with the lyrics
2. song.ly: a(n optional) Lilypond source file notating the melody. Lilypond is a music notation language with a compiler that beautifully engraves it as sheet music to various formats.
3. song.yaml: a metadata file that contains information like the song's title or links to recordings. In the future these might also contain important tags like the genre of music, region from which the song originates, etc.

The Lilypond files are compiled into SVG images that are then displayed on individual songs' pages, PDFs, as well as the main songbook PDF. The PDFs themselves are compiled from LaTeX templates.

Future additions to the website will probably include a search feature, tags, and, if enough songs are added, multiple songbooks that represent curated collections, rather than just the one that lists all the songs on the website.

When I got to the airport, I was a little annoyed because the line through the security check looked really long. I had lots of spare time arriving at the airport, so I wasn't worried about missing my flight, but standing in an airport line is never fun.

What annoyed me more, however, were Clear employees shouting as loud as they could, for everyone in the security line to hear, that "you're going to miss your flight!", "you're going to have to wait through this entire security line!", unless you enroll with Clear (which is quick, easy, and only requires you to give away a scan of your personally identifiable biometric data to some new, overfunded tech company).

I was initially annoyed by this just because I'm not sympathetic to either marketing or privacy violating technologies. But I got really mad when I realized that

1. the line was actually moving really fast;
2. the spacer tape appeared to deliberately be set up in a way that made the line visually appear as long as possible.

Like I said, the line was moving quickly, there were many TSA lines open processing a lot of people at a time. The Clear employees, standing by the line for hours at a time, would have known this, but of course they're going to use the scary looking queue as a fear tactics marketing opportunity. I got through the line in about 30 minutes, which is a perfectly reasonable amount of safety margin time any air traveler will include in their schedule.

Moral of the story

When you're being marketed something on the basis of fear (or on any basis, really, but especially when your emotional instincts might be exploited), take the time to really consider whether the bogeyman you're supposed to fear actually exists and is that scary. I'm sure you'll find other situations where similar logic applies.

You can try to access the page on other days but there's no use, you'll just be told to return next Sunday.

For now I'm going to treat this as an experiment. I'm not sure how long I'll keep it running, but I'm hoping it's going to be light enough for me to not need to care about it much. I won't mind if it remains empty some weeks, but if it stays empty for weeks in a row, I'll probably shut it down and consider the experiment as failed.

The Corner is going to be an outlet for

• random thoughts
• musings
• small updates
• tiny poems or jokes; why not?
• maybe small rants? I don't usually complain much, but maybe that's just because I've never had a good place to do so at.

I hope the ephemerality of this project will help me be more off-the-cuff and share thoughts that I normally wouldn't in full blog posts. And, assuming this actually leads to me thinking and sharing more thoughts, maybe it will additionally lead to more interesting ideas that can evolve into full articles.

Anti Social Media

This experiment is anti social media. Not in the sense that it's anti social — quite the opposite, since as always you are welcome to email me if you have any comments about anything I've written, and that includes anything you happen to see in the Corner. It's anti social media in the sense of being opposed to "social" media.

Social media tries to keep you hooked in as long as possible every day. It wants to bombard you with all sorts of random content, then learn which of it sticks. The Corner is available only one day a week. Once you've seen a Sunday's contents, there's no reason to stay on the page, to refresh, to wait for a notification (none will come). You'll have to wait until next Sunday for fresh thoughts from a new week. The thoughts will all come from me. They might be boring, they won't be targeted, you might not relate to most of them. I might even write some of them in Polish so who knows if you'll be able to read them.

Technical

The Corner is implemented as a CGI script written in Ruby. You can find the source code here. Feel free to copy my code or implement a similar idea for your own personal website!

I also just wrote an article for LandChad about CGI scripting, if you're interested in CGI scripting in general. The example used there is in concept very similar to the Corner.

Much has been said about how social media companies achieve this maximization from a psychological point of view. Dopamine-inducing "likes", targeting users with news/messages that will cause strong emotions (such as anger) to keep them engaged, things like that. But what is the real technical innovation that has made social media so irreplaceable in many people's lives, even those that are rational enough to see that those previously mentioned "incentives" are negatives for their lives?

The basic functionality that a social media platform like Facebook offers its users is a non-intrusive broadcast to all your friends and family. Now, the "broadcast to all your friends and family" is supposedly the "social" part of social media. But what do I mean by "non-intrusive"? I mean that, on Facebook, your life updates don't necessitate a reply, don't start personal conversations (at best, just a stream of "Congratulations!" or "Thoughts and prayers..." comments), and it's not rude to just completely ignore them.

Before, to announce a new baby or invite friends to party, you had to manage your own contacts list.

You would send postcards from vacation to a few select people, now you just post the best pictures you got taken of yourself to Facebook, maybe with a witty caption, and the best one of them all might even be worthy of Instagram.

Instead of discussing clever and/or silly ideas with your buds and a beer in hand, you post them on Twitter, hoping for retweets and likes rather than a conversation partner.

So while social media has made all sorts of social interactions much more time and energy efficient than phone calls, email, snail mail, and real life conversations, it also has replaced all these social interactions with much less social alternatives. Additionally, we have to realize that most of the content on "social" media isn't even social — it's marketing!

Any platform that allows non-personal broadcast — like Facebook pages or any account on asymmetrical follow platforms (Instagram, Twitter) — becomes a marketing platform rather than a social platform. Even without the concept of promoted posts, Instagram has influencers and paid posts. Twitter is all about thought leaders preaching their takes, politicians jumping at each other's throats, and celebrities gossiping out in the open. TikTok perfected the promotion algorithms to launch the careers of thousands of self-made 5-second comedians and snake-oil salesmen.

"Perfecting the promotion algorithm" is something you do to build an advertising platform, not a human social network.

Stop calling it social media. It's marketing media.

The question of whether it is possible to preserve a person's mind and consciousness is a well known idea in speculative fiction and transhumanist thought, as well as touching on more general philosophy and the hard problem of consciousness.

The first thought experiment to consider is one many people have already played around with on their own. What happens when you create a perfect copy of a brain? If you copy a brain, molecule by molecule, atom by atom, even electrical charge by electrical charge to achieve the same state, will the object you create be conscious? Would it have the same memories and ideas as the source brain?

Assuming no hidden metaphysics that somehow breathe consciousness into our human beings, the intuitive answer to the above questions seems to be yes. If our intelligence, memories, etc., are all just based on brain structures and electrical charges within the brain, a perfect copy should function exactly the same as the original.

Now suppose we clone your entire body, brain and guts and all. Is this clone also "you"? I think the intuitive answer here is that no, it isn't. You would end up with two different seats of consciousness. Each with exactly the same memories and ideas, but still different individuals, like identical twins on steroids. You wouldn't be able to see through your clone's eyes, hear their thoughts. If you were killed, it's not like your consciousness would be preserved in your clone's body.

This so far has been fairly common thought experiments that probably most fans of sci-fi had encountered at one point or another. This is for example related to a common depiction of teleportation, in which the teleportee's body is perfectly scanned and destroyed on one end, then rebuilt molecule by molecule as an identical copy on the other end. Personally I would never use such a device — while I might appear as the same "he" to my friends after teleportation, I don't see any reason to believe the person on the other end would be the same "I", and I myself would be dead.

Now comes the "linked brain" part. What if the clone, instead of being built as a separate person standing next to you, was initially built as an extension of you? What happens if we first build a second brain attached to your own? Let's say the two brains are connected at the brain stem, allowing for communication between them. We create a siamese twin for you, joined at your brain stem and we give some time for your consciousness to "spread" to both brains.

Eventually, we separate the two copies. Which one is now "you"? Who is the other person and at which point did they become a second consciousness?

Maybe split brain studies can shed some intuitions on these questions. In certain experiments, split brain patients appear to be inhabited by two separate conscious entities where there once was one. Maybe there's no such thing as consciousness and "conscious" thought is just a weird sensory artefact.

I for one definitely feel like I have a singular (though multi-faceted) "I" inside of me. But maybe I'm just not enlightened.

Addendum

I guess this thought experiment could also be a modified to an "upload your brain to a computer" variant. Suppose we can perfectly simulate a brain inside a supercomputer. Let's also assume we have a perfect brain-computer interface (the 1000th generation of Neuralink) and we link a living human brain to a simulated replica of a brain on a super computer. Can these merge into a single consciousness? What happens when you unplug?

As mentioned before, I started self hosting email a while ago. Exactly three months ago, in fact, and I know this because that's how long Let's Encrypt SSL certificates are valid for. Yesterday, my email clients started complaining about an invalid certificate coming from my mail server.

After a few minutes of worrying if I'm being man-in-the-middled, I ssh'd into my VPS to debug.

TL;DR: Root cause and solution

Turns out when configuring Dovecot (the IMAP server I use), the SSL certificate you set is just a static string, not a filename pointing to a file that Dovecot will read every time it needs to serve it. As such, even after Certbot correctly got a new certificate, Dovecot was still using the old one.

This can be fixed by restarting Dovecot, allowing it to read the new certificate, assuming its available at the same path.

Long term solution

I already have a cronjob that runs certbot renew once a month to renew any SSL certificates going stale. I'm going to change it to instead point to a script that does

certbot renew
systemctl restart dovecot

Learnings

A few things I learned while debugging this issue:

Viewing certificate info on the command line

My first step was to check the certificate I thought should have been served by Dovecot. In particular, I wanted to see its expiry date as well as compare its fingerprint to that reported by my mail client.

Certificates are stored in ASCII armor format, which is not human readable. Turns out you can get a human readable interpretation of your certificate with the openssl CLI tool:

openssl x509 -text -noout -in <certificate file>

Adding the -fingerprint flag will also output the fingerprint hash. The -noout flag is just there to suppress the output of the non-readable ASCII armor text.

Let's Encrypt certificate locations

Currently valid certificates from Let's Encrypt are stored under /etc/letsencrypt/live/<domain name>/. This is where my Dovecot server was configured to get its certificate from, so before I realized that the certificate is only read once, I was surprised that the fingerprint of the certificate stored here did not match the one my mail client was receiving.

Turns out Let's Encrypt also stores historic certificates under /etc/letsencrypt/archive/. Here I was able to find the certificate with a matching fingerprint to the faulty one received by my client, and confirm that it did indeed expire yesterday. Finding this is what led me to realizing how Dovecot handles its certificate configuration.

My main reasons for using termite were its minimalistic design, keyboard-driven, vi-like selection mode, and easy configuration. Alacritty, turns out, does all of these, while also being faster and more secure.

Switching to alacritty

On first hearing this, I immediately installed alacritty, just to check out if it really is a viable option for me. Before the installation completed, my first instinct was that I would have probably needed about a week or so to tweak my config and get used to the interface. I was expecting some switching friction.

Turns out there was zero friction. After 5 minutes of test running, I'd set alacritty to be my default terminal. I'm writing this post from inside it, and I don't even notice the difference, other than a slightly darker default color scheme. The vi-like selection mode is still at the familiar ctrl+shift+space keybinding, and it seems like that was the biggest termite-specific feature I was used to.

If anything, I'm already seeing big improvements when compared to termite. Specifically, the vi mode in termite had slight annoying issues: jumping by word didn't always work exactly the way I expected it to, and when copying selected text, the cursor actually had to be one character right of the last character you wanted to copy. I'm not seeing these issues with alacritty's vi mode, and so far it feels even more intuitive than termite's.

Bonus tip: terminal vs. ssh

On the occasion of getting a new terminal, I'm reminded of a very useful blogpost by Yaroslav de la Peña Smirnov thanks to which I solved a mild annoyance I've had with termite for years. Basically, when logging into an ssh session on various machines from termite, I would have weird problems in the shell, the remote machine apparently not understanding how to communicate properly with my terminal. This would make commands like clear or tmux not work, or even more annoyingly, cursor navigation and erasing characters with backspace were broken.

Previously, I had fixed this by hacking environment variables, but you can solve it much more cleanly with the following:

# on your local machine:
infocmp $TERM > $TERM.terminfo
scp $TERM.terminfo <remote machine>:~/

# on remote machine:
tic -x $TERM.terminfo

I had to repeat this little ritual with alacritty and the remote machines I frequent, and now everything is working smoothly!

The "app market" for mobile phones is a very sad place. I wish it had followed the direction of Linux distributions, with their repositories containing all the useful software tools you'd ever need, free and open source. Instead we have a duopoly of app stores that are both filled with "app developers" trying to make a buck instead of tools that people actually want.

As such, when I find a phone application that is actually built for usefulness, follows decent design principles, and allows for a personalized workflow, I think it's necessary to give it a shoutout.

For a long time I've wanted a digital note taking solution that would allow me to synchronize notes across multiple devices. I wouldn't want to use Evernote or any other proprietary, centralized service. Selfhosting something like Nextcloud just for the purpose of notes feels like shooting a fly with a cannon. If I were limited to computers, it would be a no-brainer to just keep the notes in a git repo (like I do with my command line cheatsheets). How do we synchronize with a phone though?

Enter gitjournal.

Enter gitjournal

Gitjournal essentially provides a git client on your phone whose design is centered around note taking. I won't go into all the features and design details, but it's got everything I need for simple note taking:

• Edit notes in markdown
• Todo list mode
• Organize notes in a directory structure

And of course the git repository can be hosted anywhere. If you trust your forge with your personal notes, be it GitHub, GitLab, sourcehut, or anywhere else, your forge is now also your note synchronization hub. Personally, I host my notes on my VPS.

Computer side, I've written a short script that takes care of git operations and some of the metadata in gitjournal notes, and lets me select a note to edit with fzf. But even manually navigating to notes and handling git operations wouldn't be a bad experience.

Caveats

The app, in the end, is made for profit. In particular, on the Apple App Store even the basic version costs money (it's free on Android). There are some additional features that are further paywalled. This includes tagging and multiple repositories, both of which would be nice to haves for me, but their lack is not a deal breaker in my case. However, the app is open source (I think including the "pro" features) and AGPL'd so if you know how to build it for your phone, it's yours.

I haven't had to deal with merge conflicts in the app. I'm not sure how they're handled. I'm not too worried though, if anything weird does happen, I'm sure I'll be able to fix it computer-side. Nothing a little force pushing to master can't solve.

You might have to be careful with some symbols in note titles that are treated as special symbols by your OS (e.g. ~, !, [, ], etc.). The app won't complain about them, they might cause problems on your computer.

As mentioned, the app commits every change you make to your notes. As such, I prefer to use it for jotting down ideas, archiving links, writing down interesting thoughts I have, long term todos — in other words, more persistent notes. For daily todo or shopping lists I use a different app. This isn't a huge problem since I don't really need those things synchronized across devices. I think in my ideal world, gitjournal would have "scratch notes" that are not tracked in the git repo, so that I can keep all these things in one app without littering git history with "buy eggs" every week.

The obvious way to get a PDF of a website would be to use my browser's built in print-to-PDF feature. But this has some minor problems for me:

• Articles from different websites will look very differently. I can't anticipate how the website's CSS will affect readability (things like font, text size, etc.).
• It's not super easy to automate. Maybe this is possible with headless browsers? But I haven't played around with those much and it feels silly to spin up a whole browser just to render some HTML as a PDF.

That second point — about automation and scripting — was particularly important to me. So the obvious tool for the job was the Swiss-army knife of document conversions, pandoc.

For a while I was wondering if I would have to write some clever script that downloads all of the article's HTML and other resources (like images) and then inputs them to pandoc. Fortunately, it turns out that pandoc <article url> -o <output file> does exactly what you think it does. The article ends up converted to PDF, with LaTeX used as an intermediate step, so everything is in the beautiful LaTeX font. pandoc also takes care of downloading and including images.

Hotkeys

I wrote a short script that calls pandoc and saves the PDF in a specific directory. With that script available and working, I added hotkeys to my browser and RSS reader that invoke it. These are the two programs in which I might find articles to read, and now I can easily generate PDFs from both.

Here's what the newsboat config looks like:

macro p set browser "article2pdf %u" ; open-in-browser ; set browser "elinks %u"

config.bind(
        '"P',
        'spawn article2pdf {url}'
)

Caveats

This doesn't work perfectly.

• There's some issues with certain Unicode characters (including emojis) that LaTeX apparently can't handle. Adding the --pdf-engine=xelatex flag when calling pandoc doesn't fully mitigate the issue, but it will produce reasonable output without completely failing.
• Sometimes images are not handled great. For example they might not fit width-wise. LaTeX completely fails on images in the WebP format.
• Similarly, sometimes code blocks might get cut off and not fit width-wise. This is admittedly a pretty big problem.
• Headers and footers from many sites will not be rendered great. This doesn't bother me, all I care about is the main article contents.

But "sleeping" for 5 minutes, after already having been awoken by a loud alarm, is useless, at least in my experience. If I have 5 minutes left before I know the alarm will sound again, I'll a) not have time to actually fall asleep again, b) spend the whole time angry at the alarm knowing it will start buzzing again any second now. Any difference in grogginess between getting up immediately and after the 5 minutes would be insignificant, so might as well get up without the snooze.

How I snooze

The above is not to say that I'm the perfect human who is always able to wake up full of energy no matter how early my alarm is set. But instead of torturing myself with 5 minute fragments of back-and-forth between trying to force myself to pass out and a blaring alarm, I take an actual nap.

If I wake up sleep deprived and I know I can delay my morning by at least half an hour (or maybe skip whatever first commitment I had, assuming it's lower priority than me not being a zombie all day), I'll set a fresh alarm half an hour (or more if I'm more groggy and have a wider margin available) ahead. That is usually enough time to actually fall asleep and actually start the day with a clearer mind.

The most baffling use of a snooze button to me is people saying that it's normal for them to wake up after hitting "snooze" several times. If you're able to stay in bed for several snooze button hits without missing any absolutely critical scheduled events, you should forget the snooze button and do what I do — set an alarm that gives you time for a real nap.

The study measures the impact of X on some output(s) Y, and just based on the fact that it concludes with a positive impact on Y (no matter the magnitude), the pop science article reports that X is objectively good, and will end by recommending that every reader should now do X, incorporate X into your daily routine, need never feel guilty again doing X (since often X is something associated with bad habits, like drinking a particular alcohol, playing video games, etc).

Clickbaity headlines like that will easily imprint a positive association with X in most readers' minds. But just because a study found a positive impact of X on Y doesn't necessarily warrant saying that it is objectively "good for you".

Even barring general problems with many studies (was it performed on a large enough population? was the methodology correct? were there any biases introduced? was the population representative of the reader?), any study will be able to test only a limited number of outputs Y. So even if the study was performed perfectly, and you agree with the authors on what change in Y is positive or not, the study can make no claim on all other aspects that could be potentially impacted by X, including ones that we wouldn't even expect to be affected.

You will most likely benefit more from using "Lindy" things (per Nassim Taleb's terminology) than jumping on any particular pop science trend.

• I get a bit of insight into website traffic from Nginx logs, without needing to resort to something like Google analytics.
• I gain some internet independence. Sure, now I'm relying on Vultr instead of GitLab, but I can always switch to a different VPS provider (or, with enough grit, use own hardware) which will have the same environment, while GitLab Pages is a setup specific to GitLab.
• I've wanted to play around with self-hosting various services for a while now.

Current setup

As mentioned, the website is served with Nginx. It's still statically generated with my Ruby script. I build locally and use rsync to incrementally update the hosted files.

I use certbot with the Nginx plugin to get an SSL certificate. A cron job should ensure the certificate is updated automatically before expiry.

Website traffic analysis

I've already gotten some interesting statistics from server logs. The day I posted a Hacker News comment linking to one of my blog posts, there were four times as many HTTP requests received, including around 200 unique IPs referred from news.ycombinator.com.

So far my log analysis has been very ad hoc — just manually parsing the log files with command line tools and Vim. For example, to get that 200 number from above I ran

awk '/ycombinator/ { print $1 }' logs | sort | uniq | wc -l

Self-hosting

In addition to this website, I'm also using the VPS to host a personal email server and some git repos. The email server is based on Postfix and Dovecot and was painlessly installed and configured thanks to emailwiz. The git frontend is cgit. I might write a post about setting up and configuring it later. Overall quite happy with what it looks like and what it offers.

1. Moby Dick, Herman Melville. The Great American Novel. Haven't actually quite finished this one, but I've gotten most of the way through it, so feels more appropriate to include it in the 2020 list rather than the 2021 one (I do intend on finishing this book).

   Interestingly, despite its length, I found it fairly easy to pick the book up midway after a longer pause from reading it. This might be due to quite a different structure compared to the more modern novels I'm used to. Though it happens mostly chronologically, it's not really a linear, continuous story where you have to keep track of the plot and characters. Instead, you're presented with short vignettes of whaling life (and, sometimes, everyone's favorite cetology lectures).

2. Się, Edward Stachura. A collection of short stories by the Polish poet, one of his last published works before his suicide two years later. The stories are mostly set in travels around both Poland and the American continent.

3. The First Philosophers, Robin Waterfield. Guess you could say I'm finally starting with the Greeks (I did read The Republic the year prior, reading it was an interesting experience but I'm sure a lot of it went way over my head at the time).

   Like Moby Dick, I haven't quite finished the whole book yet — I read the first half on the presocratics, but will need to get back to the part on the sophists at some point.

4. Fight Club, Chuck Palahniuk. Probably shouldn't talk about this one much, but man, this is the first time in a while a book sucked me in this strongly. A literal page turner that kept me awake late into the night.

5. Antifragile, Nassim Taleb. Very glad I finally got around to reading something from Taleb.

6. Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig. Another foray into philosophy, though definitely more modern than the Greeks. It wasn't until I was about halfway through the book that I found out it's mostly autobiographical rather than pure fiction.

7. Vagabonding, Rolf Potts. I've published extended reading notes here.

8. The Sovereign Individual, James Dale Davidson and William Rees-Mogg. Widely popular amongst and recommended by Bitcoin/blockchain fans.

9. Brave New World, Aldous Huxley. Probably my favorite dystopian novel I've read so far.

10. Thinking, Fast and Slow, Daniel Kahneman. An interesting (and long!) volume on how our brains work.

Interestingly, in the first month alone of 2021, I've already read nearly half as many new books. Granted, none of them were quite as long as, say, Antifragile or the Kahneman book, but still a welcome metric. Off to more reading, now!

Advent of Code 2020 has come to an end. At the time of this writing, around seven thousand people finished the whole thing, out of the 150000 that had submitted a solution to the first day's problem. And I'm one of them!

You can see my solutions here. I started out with C, moved on to Ruby, and near the end switched to Lua. I'm going to need some Lua knowledge for the Redis section of the databases class I'm taking right now, so AoC was a good time to get familiar with the language.

Thoughts on AoC 2020

I found most of the problems fairly simple, but it was fun to go through them all anyways.

Most Tedious Award goes to...

Day 20 Part 2. My solution ended up being a good 340 lines of Lua split between two scripts. This is the last problem I solved because I knew it would require a lot of work to get working, so I procrastinated on it until the end.

In the end, the process of solving this was actually kind of fun, and getting the final solution satisfying. I think it might have something to do with the geometric/visual nature of the problem. There's just something nice about rotating and flipping ASCII squares with code, and seeing them all line up correctly in the end.

Most Cheesed Award goes to...

Day 19 Part 2. Rather than implementing a parser generator that could handle this grammar by hand, I bodged together a Bison (aka Yacc) solution . It's not very pretty, especially the Bash script that just calls the parser with each input word separately and counts how many times it didn't exit with a syntax error. But it works! And I finally learned something about Bison/Yacc and Flex/Lex, which I've had indirect exposure to before, but never actually used.

I was quite pleased with my Part 1 solution though, where I implemented a simple recursive parser generator.

Runner-up in the Most Cheesed category

Day 13 Part 2. I'll admit it, I just copied a Chinese Remainder Theorem implementation from Rosetta Code. I'm sure the Python guys just used numpy's CRT, so treating it as a library function doesn't seem too cheaty for me.

Most Fun Award goes to...

Probably a tie between the already mentioned Day 20 Part 2 and Day 19 Part 1. Day 20 had that cool geometric component and satisfaction of putting a puzzle together, but I'm a sucker for recursive parsers implemented with higher order functions.

Thoughts on Lua

Learning Lua was probably the most useful outcome of this year's AoC for me. I feel pretty comfortable with the basic constructs of the language, and even played around a bit with metatable-driven OOP. I don't know how closely I stuck to general conventions, and didn't interact with any external libraries, but can definitely read and write the language comfortably now.

My one sentence summary of feelings towards Lua is that Go is to Java what Lua is to Python/Ruby/JavaScript. Its very small vocabulary means you learn the language quickly and don't need to think much while writing it, but your programs can end up more verbose than the equivalent Ruby/Python.

It turns out the original design is very flexible. We can modify the auction's properties to incentivize different behaviors or handle specific scenarios. For example, we'll be able to mimic the auction mechanism used by Google's AdWords to auction off search results positions.

Quick recap

The previous article introduced an auction that works in two phases:

1. bid phase

   Users submit bids stating "I'm willing to pay x XYZ for y ABC." The transaction should include a payment of x XYZ so the user can't back out later.

   The user's transaction not only records this bid in the contract's storage, but also inserts it into a balanced BST (sorted by XYZ/ABC ratios).

2. fill phase

   Users with highest XYZ/ABC ratios can receive their bought ABC, while the remaining users are refunded their locked up XYZ. We can determine which bids to fill and which to refund thanks to an additional value we've been keeping in our BST's nodes (the total amount of ABC in the node's subtree)

Blind Auction

As mentioned in a footnote to the previous article, we can hide users' bids during the auctioning phase. This is something that's probably desired in most smart contract auctions of this sort, for example to avoid frontrunning or block congestion in the last few moment's of the bidding phase. In an open bid auction, bidders could compete for the final strike price in the gas auction if all bids were open.

Closed bids also mean that users submit their own personal valuation of the auctioned asset, rather than one influenced by other market players.

Blinding bids was omitted from the original description for brevity and clarity. The central idea in the first article was using a BST for an on-chain auction, blinding bids is just a technical detail. Here's how we can implement it.

We replace the bid phase with a commit phase and a reveal phase:

• In the commit phase, users submit a hash of their bid information (buyAmount, sellAmount), and a random salt. They also send a prepayment that should be equal to or greater than their sellAmount. We save this hash and the amount sent in the smart contract.

• The reveal phase is very similar to the original bid phase, where users submit their buyAmount and sellAmount. Now they additionally reveal their salt. The smart contract hashes these inputs and verifies this hash matches the one submitted during commit — if it does not, the bid is invalid and will not participate in the auction. We also verify that the amount prepaid during commit was at least as much as the revealed sellAmount.

  After these additional verification steps, we proceed as in bid, sorting the bid information into a BST.

Note a positive property that this auction has over a simple single-unit blind auction. While the prepayment sent with commit reveals an upper bound of how much the bidder is willing to invest in this auction, it doesn't reveal anything about how they price the sold asset — they could be sending a bid with a high price purchasing few tokens, or vice versa, attempting to purchase a lot of tokens but for a low price.

Second price auction

A second price auction¹ is the Google AdWords mechanism mentioned in the introduction. In this type of auction, users bid on multiple items (e.g. ordered slots on a search results page). The items are distributed to the highest bidders, but the bidders actually pay less than they bid. Specifically, the highest bidder pays the second-highest bidder's price, the second pays the third's, and so on.

We can implement this in our BST auction design by modifying the fill phase. When filling a user's bid, we can check the next highest bid's price by walking to the next node in the inorder traversal order. On a balanced tree like we're keeping, this will take time O(log n).

Uniform price auction

A similar modification we can make is to have all the auction participants pay the same exact price — that of the last winning bidder. We will add a set price phase in which the smart contract finds and verifies this lowest accepted price. During the fill phase, we will charge winning bidders based on this price, refunding them the rest of their prepayment.

This modification is possible thanks to the total value we've decorated our BST's nodes with. In our new set price phase, we can start in the tree's root and binary search down to the last bid that is fillable. We note down this node's price as the strike price of the auction for all participants.

Note that we described set price as a separate phase, but it could instead be included into the fill phase, running the above algorithm on the first call to fill.

Conclusions

In these two articles I described several novel smart contract decentralized auction designs. They can be implemented to be completely trustless, tamperproof, and censorship resistant, leveraging these properties of blockchains.

The important thing to note about these designs is that, while offering the above properties, they are relatively gas efficient. Individual operations work in time (and thus gas cost) O(log n), where n is the number of auction participants. This can still get fairly expensive, especially given the number of storage writes when inserting into a BST. However, we spread the cost of these operations evenly between auction participants.

The classic Dutch auction wins out on the efficiency front, having very cheap O(1) operations, but has its problems. Dutch auction bids can be easily frontrun. These auctions can cause sudden block congestion spikes when a price favored by many participants is reached. And in some cases, you just want an auction with different game theoretic properties than those the Dutch auction offers. The BST auctions described here widen your decentralized auction toolbox.

1. Or more precisely, a generalized second price auction. The term second price auction (also known as a Vickrey auction) is usually reserved for single unit auctions.

readline is a library that can be used to add keyboard shortcuts to various CLI programs. If you're a command line user on Linux or Mac, you're probably already using it even if you don't know it — bash keyboard shortcuts come from readline.

By default, readline uses Emacs-like bindings. If you were ever confused by the weird key combinations in bash, this is where they come from.

readline can be configured via an ~/.inputrc config file in your home directory.

There are several other libraries that provide similar functionality that are used by certain CLI programs. libedit is a popular alternative with a more permissive ("less free") license. Many Haskell projects use haskeline, created specifically for ghc.

Configuring readline

All of the above libraries can be configured with config files in your home directory. Here's what to put in your dotfiles to use vi keybindings by default:

# ~/.inputrc
set editing-mode vi

# ~/.editrc
bind -v

# ~/.haskeline
editMode: Vi

One other useful tip: if you want to just quickly switch bash to vi keys, perhaps on an account that's temporary and you won't be putting effort into customizing it, you can do so by running set -o vi.

Where this doesn't work

The above configs cover some of my most used CLI tools, like bash, REPLs for Ruby, Python, Haskell. My biggest pain is that I haven't found a satisfactory way of getting vi keybindings in a Node.js shell.

In some cases you can hack your way around a CLI not using any of the readline-like libraries using a tool called rlwrap. Unfortunately, it's not a silver bullet. I remember it working fine enough for the OCaml REPL, but it doesn't play well with Node.

Long term travel, the sort that isn't just plain tourism, is something I've had in the back of my mind for a while. This read definitely pushed it farther forward in my mind — who knows, maybe I'll end up in Asia or South America for a few months after I'm done with university.

Quotes

(many of these are from other sources, quoted by Rolf; he's quite the quote aggregator!)

These first three quotes are basically on that philosophy I mentioned above, that if you feel a personal need for more to life than the modern day to day, don't let the material world hold you down.

we end up spending (as Thoreau put it) "the best part of one's life earning money in order to enjoy a questionable liberty during the least valuable part of it."

This notion — that material investment is somehow more important to life than personal investment — is exactly what leads so many of us to believe we could never afford to go vagabonding.

Vagabonding sage Ed Buryn knew as much: "By switching to a new game, which in this case involves vagabonding, time becomes the only possession and everyone is equally rich in it by biological inheritance."

On spontaneity, unplanned travel (what Nassim Taleb would call flânerie over tourism).

John Muir used to say that the best way to prepare for a trip was to "throw some tea and bread into an old sack and jump over the back fence."

On planning a little bit, after all.

And, as Phil Cousineau pointed out in The Art of Pilgrimage, I tend to believe that "preparation no more spoils the chance for spontaneity and serendipity than discipline ruins the opportunity for genuine self-expression in sports, acting, or the tea ceremony."

On "seeing beyond the guidebook" (from Mark Twain's The Innocents Abroad).

"The pilgrims will tell of Palestine, when they get home, not as it appeared to them, but as it appeared in [the guidebooks]."

I ran into this while working on meta-tooling around smart contracts, specifically scripts for running upgrades of proxied contracts. To this end, I wanted to write unit tests that would use minimal example contracts with edge cases that might not easily appear "in nature". I want to keep these dummy contracts in a test resources directory rather than cluttering up the main contracts/.

Unfortunately, not all parts of the Truffle API are very well documented, but here's how I got my sweet, sweet Truffle contract wrappers.

Getting the contract object

import truffleContract = require('truffle-contract')
const Contract = truffleContract({
    abi: artifact.abi,
    unlinked_binary: artifact.bytecode,
})

Making it usable

Before you go run off playing with your new Contract, a few last housekeeping things to take care of. If you try, say, deploying this contract with Contract.new(), you'll get a nasty error message saying

Error: Contract error: Please call setProvider() first before calling new().

Actually not that nasty since it tells you what you need to do to fix things! Call Contract.setProvider() with a standard Web3 provider. If you already have a Web3 instance lying around,

Contract.setProvider(web3.currentProvider)

Last things last, at this point you would start seeing the following:

Error: Contract has no network id set, cannot lookup artifact data. Either set
the network manually using Contract.setNetwork(), run Contract.detectNetwork(),
or use new(), at() or deployed() as a thenable which will detect the network
automatically.

At this point you'll be able to call Contract.new() to get a handle to a freshly deployed contract, or Contract.at(address) to interact with an already deployed instance of the contract.

TL;DR

Here's the little helper function I wrote to construct these Truffle objects:

import truffleContract = require('truffle-contract')

const makeTruffleContract = (artifact) => {
  const Contract = truffleContract({
    abi: artifact.abi,
    unlinked_binary: artifact.bytecode,
  })
  Contract.setProvider(web3.currentProvider)
  Contract.setNetwork('development')

  return Contract
}

Final note on linking

If you're using any linked libraries in your contract, first deploy the libraries, then link them with Contract.link('LibraryName', libraryAddress).

Multiunit auctions

Multiunit auctions are a generic financial primitive that could be useful in various decentralized financial systems. I'd like to present an alternative to the Dutch auction that may be more suitable in certain situations.

Designing an auction smart contract

Let's first define the basic behavior we want from our auction. Then we'll be able to see which steps would break if implemented naively, and how to address those problems. Let's frame it in the context of a currency auction, where currency A is being sold for currency B:

1. The auctioneer decides he wants to sell a pot of x units of A.
2. Users submit bids that say "I want to buy y units of A for z units of B."
3. We go through the bids from highest z/y ratio to lowest, filling them as we go. We stop if the sum of paid out ys reaches the size of the pot x. ¹

To make this all a little more concrete, let's define an interface we might expect from an auction smart contract:

interface IAuction {
    function start(uint pot);
    function bid(uint sellAmount, uint buyAmount) returns (uint bidId);
    function end();
    function fill(uint bidId);
}

The above is very similar to an example from the Solidity tutorial showing how to build a single unit auction. The big difference is that when making a bid, we specify how much we're willing to pay and how many units of the auctioned asset we're bidding on.²

The problem, as hinted at earlier, is that we can't just sort the list of bids and go through it, bid by bid, when implementing step 3 of our protocol. Sorting is an O(nlogn) operation, and even the linear scan would greatly limit the allowable number of participants in an auction given block gas limits.

Sorting

The solution to this problem, as is often the case in computer science, comes in the shape of a tree.

We'll have bid store bids in a balanced binary search tree. The in-order traversal of the resulting tree gives us a sorted list of all bids. We're essentially having each auction participant pay the necessary gas to sort just their bid into the data structure.

Here's a scaffold of what bid could look like:

contract Auction {
    // Node in a red-black tree
    struct Node {
        uint sellAmount;
        uint buyAmount;
        uint left;
        uint right;
        uint parent;
        bool red;
    }

    Node[] tree;
    uint root;

    function greaterThan(Node n1, Node n2) {
        return n1.sellAmount * n2.buyAmount >= n1.buyAmount * n2.sellAmount;
    }

    function bid(uint sellAmount, uint buyAmount) payable returns (uint bidId) {
        bidId = tree.length;
        tree.push(Node(sellAmount, buyAmount, 0, 0, 0, false));
        ... // do RBT insertion with greaterThan as the comparison function
    }

    ...
}

When all bids have been submitted and sorted into the tree, we need to be able to fill the bids of those users that submitted the highest bids. When a user comes in and says "Hey, look at my bid, I paid z amount of B so now I deserve y amount of A!", we need to be able to verify that their bid actually fit into the pot and can be filled.

At this point, when implementing fill naively, we would still need a linear traversal to determine whether a given bidId should be filled or not. To finish off this auction design, we'll augment the BST such that we can implement an O(logn) fill.

Filling

We'll augment each node of the tree to contain the total amount of buyToken in the node's subtree. This will allow us to quickly calculate the amount of buyToken in all nodes with a better price than a given bid.

This augmentation is possible because updating this total is efficient when updating the tree. We only need to modify the insert and rotation operations:

function insert(Bid bid, uint bidId) {
    uint current = tree.root;
    uint parent = current;
    while (current != 0) {
        parent = current;

        // Increase totals on the path from root to newly inserted node
        tree.[parent].total = tree[parent].total + bid.buyAmount;

        if (greaterThan(bid, tree.bids[current])) {
            current = tree.bids[current].left;
        } else {
            current = tree.bids[current].right;
        }
    }
    
    // ...
}

// Called at the end of each rotation operation
function recalculateTotalsAfterRotation(uint n, uint pivot) {
    tree[pivot].total = tree[n].total;
    tree[n].total = tree[tree.bids[n].left].total +
        tree[tree[n].right].total +
        tree[n].buyAmount
}

This in our data structure gives us a logarithmic algorithm for checking how much of the token would be bought by bidders at higher exchange rates. We walk up from our node to the root. Any time we step up from a right child, we'll add the total from our sibling's subtree and parent node's value (since, by the BST property, those are the nodes with greater rates than our starting node).

function totalFromHigherExchangeRates(uint bidId) view returns (uint) {
    uint total = tree[tree[bidId].left].total;
    uint parent = tree[bidId].parent;
    uint currentNode = bidId;

    while (parent != 0) {
      if (tree[parent].right == currentNode) {
        total += tree[tree[parent].left].total;
        total += tree[parent].buyAmount;
      }

      currentNode = parent;
      parent = tree[parent].parent;
    }

    return total;
}

fill can now use totalFromHigherExchangeRates to determine whether or not a given bid should be filled. The per-bid computational complexity (and thus gas cost) is logarithmic with respect to the total number of bids.

Origin

I originally came up with this auction design while working on Celo's on-chain stability mechanism. The idea was to use periodic currency auctions to expand or contract the supply of a token to match demand, thus stabilizing its price.

Later we came up with an even more clever stabilization mechanism, one that can function continuously. It's based on Uniswap and you can read more about it in this Medium post .

1. The last successful bid might only be partially filled. This is a detail that needs to be addressed, but it's easy to do so. For simplicity of the rest of the text, I'll avoid discussing it.

2. For simplicity, we'll talk about a two phase, open bid auction. As with the single unit auction, this could be modified to a hidden bid auction by adding a commit step.

I'm definitely not a fitness expert, and I'm sure this program is far from perfect. But it hits most of the major muscle groups, is an energizing way to start each day, and definitely gets me sweaty, so I'll use that as a metric of it being sufficient for now.

Workout A: Upper

• Push-ups 3xFailure (this is around 20 for me, up from 10 at the beginning of lockdown)
• Kettlebell shoulder press 3x7 per arm
• Kettlebell row 3x12 per arm

Workout B: Lower and Core

• Plank 3x1:45
• Kettlebell swings 3x1:45
• Kettlebell goblet squats 3x12

I also throw in chin-ups or pull-ups throughout the day on both workouts.

I alternate these workouts for five days a week, with two rest days a week.

Thoughts

• I definitely can recommend getting a kettlebell. If you get the right weight for you (the recommended starter weights are 16kg for men, 8kg for women), it's a single piece of equipment that can be used for a wide range of exercises. A very affordable option in general, and especially right now while gyms are closed.
• If you've never touched a kettlebell before, Pavel Tsatsouline's Enter the Kettlebell is a great starting point, going over general use and the most popular exercises.
• Working out is not just for getting in shape, but will also have a very positive impact on mental well-being. It can be especially useful now as a way of jump-starting days in lock-down.
• Doing something is better than doing nothing. I don't recommend following my plan - it's based entirely on intuition, what feels good, and the equipment I have available. If you find any other home workout plan that seems to suit your likes - follow it. Then again if you don't, following mine or whatever plan you come up with for yourself is going to be better than nothing.

Write a piece of JavaScript that defines a function named s that

• Takes three non-negative integer arguments: x, y, t (x and y less than 16).
• Returns a non-negative integer less than 16².
• The code can be syntactically written in a 16x16 block of characters.

The source code defining s will be visually displayed on a 16x16 grid. 32 times a second, it will be separately called for each x, y coordinate of the grid, initially with a t parameter equal to 0, and incrementing by one with each series of calls.

The result of each call to s will determine the shade of the character in the corresponding grid location.

In code:

var step = 0
_frame = function() {
    for (var row = 0; row < 16; row++) {
        for (var column = 0; column < 16; column++) {
            var shade = s(row, column, step)
            var cell = display.children[row].children[column]
            cell.style.color = `rgb(${shade}, ${shade}, ${shade})`
        }
    }
    step++
}
setInterval(_frame, 31.25)

An example

What surprised me was the choice I was offered. Normally, it's either accept all cookies vs. leave the site, or the ability to turn off some unnecessary tracking cookies. In this case, one option was the classic "Agree and Continue", but the second was "Decline and visit plain text site".

Not "Decline and go away". Not "Decline and never speak to us ever again". But "Decline and visit plain text site".

Wait, so I can use a streamlined, easy to read, nondistracting version of your website and not be tracked by multinational advertising megacorps? Nice.

Other small big sites

Turns out this text-only version has been around since 2005. CNN also has a text-only version, though it's not as easy to find. It also includes analytics javascript which is not as cool as NPR's pure HTML. In both cases, these light versions were created to make news accessible in locations or times with low connectivity — for example during natural disasters.

As much as I'm not a fan of Facebook, I'm very impressed with mbasic.facebook.com. This is a minimal, no-ads, no-javascript version of the service, that offers most of the functionality of the full website or app. It was created with emerging markets in mind, but I find it to be a good daily driver that doesn't distract and suck away attention as much as Facebook's products normally are supposed to.

To mention a few other big sites with very minimalist design, Hacker News is a news aggregator known by all in the tech community that relies on minimal javascript and is mostly text-based. Warren Buffett didn't shell out much on the design for Berkshire Hathaway's corporate website.

# jk - move up/down
unbind-key j
unbind-key k
bind-key j down
bind-key k up

# hl - move in/out of feeds/articles
bind-key h quit
bind-key l open

# q quits the program
unbind-key q
bind-key q hard-quit

# g/G to go to top/bottom
unbind-key g
unbind-key G
bind-key g home
bind-key G end

# f to follow links (like qutebrowser)
unbind-key f
bind-key f goto-url

I can recommend following a similar practice to anyone, though I don't recommend using my cheatsheets. They are usually quick notes that follow my own mental shortcuts, and in general are optimized to be quickly understood by me, based solely on my past experiences with these tools. I won't include options that are already obvious to me (if you haven't used git add -p or git rebase -i, you should go learn about them!), and might instead include tools that are already a second language to you (any ffmpeg ninjas out there?).

There are existing tools that aim to improve command line productivity in similar ways, like tldr or cheat. For my personal workflow, I figured that there's no reason to overcomplicate things when tools I already have (vim + git) do the job fine.

Now, for any new UNIX system I intend on spending a lot of time on, I'll git pull gitlab.com/m-chrzan/cheatsheets in my home directory. When I want to remind myself of a command's use case, or have just figured out a new cool trick that I know I'm going to forget if I don't write it down, my notes are just a vim ~/ch<TAB> tool.md away. If I do write any new tips down, a quick git push allows me to keep the cheatsheets synced across all other systems.

You can play it by running the following in a bash shell:

c=x; while [ $c ]; do clear; curl -c k -b k hex.m-chrzan.xyz/$c; read c; done

This was an exercise in minimalism. The game server is implemented in less than a thousand lines of Ruby code. It is completely stateless, requiring no database. The front end "client" is a single line of bash, less than 80 characters long. The only dependency is curl, a CLI tool already available on most Unix-like systems.

The source code is available here.

Let's get curling

The whole concept arose from two ideas I had:

• curl and a simple web server could be used to create a simple remote CLI program.
• For a webapp that implements a simple state-transition system (like a simple game), one could forget about session management and a database, and just store the state client-side in a cookie.

To create a new "curling" system, you extend Engine and implement four methods:

• step: performs a single step of the state-transition function.
• message: outputs a message related to the most recent step.
• hash_to_state and state_to_hash: these are just overhead glue methods. They should deserialize and serialize between your engine's internal state and a Ruby Hash.

The Sinatra skeleton instantiates an engine with the received cookie, runs a step, sends back the new state in the returned cookie, and responds with the engine's message. The code for it fits in half of a browser window:

require 'sinatra'
require 'sinatra/cookies'

# exposes `Hex`, which extends `Engine`, implementing a simple dungeon crawler
require './hex_engine'

def secret
  # get secret from environment
  ENV['HEX_SECRET']
end

get '/:command' do |command|
  # `new` uses `hash_to_state` to initialize the engine's state
  engine = Hex.new cookies.to_h
  engine.step command
  # `state_h` uses `state_to_hash` to serialize the engine's new state
  engine.state_h.each_pair do |key, value|
    cookies[key] = value
  end
  engine.message
end

O(1) space webapp

Hex Curler is hosted online but has no session management, no database. It's an O(1) space webapp.

As mentioned before, the game's state is stored in a cookie. The server need only know the contents of that cookie to return a new state back to the user.

To prevent a user from tampering with the cookie, for example by increasing their health to a ridiculous number, becoming invulnerable to enemies in Hex, the cookie also contains a checksum field. This checksum is the hash of the state together with an appended secret only known by the game server. The server will refuse to respond to requests whose cookie does not have a valid checksum.

This introduces some interesting possibilities. For example, let's say Alice wants to boast to her friends about how she just beat Hex, ended with 100 HP remaining, and had upgraded her magic armor to level 5. Her friend Bob doesn't just have to take her word for it, or trust a screenshot that could have easily been photoshopped.

Alice can send Bob her state cookie. If a request to the game server with it succeeds, Bob can be assured that he has cryptographic proof of Alice's claims.

Ingredients:

• raspberries
• vodka or neutral spirits mixed with water to desired alcohol content
• sugar

Steps

Stage 1: Preparation (3 minutes)

1. Fill jar with raspberries.
2. Cover raspberries with alcohol.
3. Shut jar and find spot to store.

Stage 2: Infusion (~2 weeks+)

Let sit for about two weeks, giving the jar a good shake once a day. With time, the liquid will become a deep, clear red.

Stage 3: Maceration (~1 week+)

1. Pour through strainer. Store liquid in a bottle or another jar.
2. Throw raspberries back into jar. Cover with sugar.
3. Like really cover them. Give the jar a few good shakes and add more sugar.
4. Let sit again for a few days, shaking once a day.

Stage 4: Aging (1 week - until the heat death of the universe)

1. Pour contents of jar through strainer. Throw away whatever solids remain of the fruits.
2. Combine this syrup with the previously set aside raspberry alcohol.
3. Let sit for at least a few days or weeks. As with the krupnik, the mixture will become smoother with shelf time.

Related posts

• Krupnik recipe

The only good recipes I've seen are in Polish, so wanted to share some with the English speaking world.

In this post I'll give a recipe for krupnik staropolski ¹ .

Ingredients:

(makes a 16oz. Mason jar of liqueur)

• vodka or neutral spirits mixed with water to desired alcohol content
• 4oz. honey
• spices:
  • 5-10 cloves
  • 3-7 allspice berries
  • ½ stick of cinnamon
  • 3-7 whole cardamom pods
  • others as you like! (star anise, nutmeg, vanilla beans or extract, whole peppercorns, etc.)
• fresh ginger
• juice from half a lemon
• lemon peel
• orange peel

Steps

Stage 1: Preparation (10-30 minutes)

1. Boil honey in pot.
2. The honey should have separated. Remove the top foamy layer.
3. Pour the liquid honey into jar.
4. Add rest of ingredients to jar.
5. Fill the rest of the way up with alcohol.
6. Shut jar and find spot to store.

Stage 2: Infusion + Filtration (~2 weeks+)

1. Let sit. For like 2 weeks or so. This is where the alcohol mixes with honey and becomes infused with flavors from the spices.
2. Pour through strainer and throw away the solids.
3. Filter through several layers of gauze or a coffee filter. This is to remove that nasty layer of sediment at the bottom of the otherwise beautifully golden liquid.²

Stage 3: Aging (1 week - multiple years)

Finally, it's good to let the krupnik sit on a shelf at least a few days before drinking. If you try it right after the infusion stage, you might notice it still reeking of ethanol and being hard on your taste buds and throat.

With time, the liqueur will become very smooth and all the flavors will mix and complement each other.

Related posts

• Malinówka recipe

1. Not to be confused with the tasty Polish grain soup.

2. Honestly, sometimes I skip this step because I'm too lazy. I'll just pour the liquid out to a new jar and stop pouring when the sediments start mixing with the good stuff.

There's a cool method for implementing simple object-orientation (complete with polymorphism) in C that can also be applied in Solidity to solve similar problems.

Let's look at how Linux kernel programmers deal with filesystems.

Each filesystem needs its own low-level implementation. At the same time, it would be nice to have the abstract concept of a file, and be able to write generic code that can interact with files living on any sort of filesystem. Sounds like polymorphism.

Here's the first few lines of the definition of struct file , used to keep track of a file in the Linux kernel.

struct file {
    struct path                     f_path;
    struct inode                    *f_inode;
    const struct file_operations    *f_op;
    // ...
};

The important bit is the f_op field, of type struct file_operations. Let's look at (an abridged version of) its definition .

struct file_operations {
    struct module *owner;
    loff_t (*llseek) (struct file *, loff_t, int);
    ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
    ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
    ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
    ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
    int (*mmap) (struct file *, struct vm_area_struct *);
    int (*open) (struct inode *, struct file *);
    // ...
};

To emulate OO, inside our "object" (struct file) we manually store a container for its "methods" (struct file_operations). Each of these, as its first argument, takes a pointer to a struct file that it's going to operate on.

With this in place, we can now define a generic read system call:

ssize_t __vfs_read(struct file *file, char __user *buf, size_t count,
           loff_t *pos)
{
    if (file->f_op->read)
        return file->f_op->read(file, buf, count, pos);
    else if (file->f_op->read_iter)
        return new_sync_read(file, buf, count, pos);
    else
        return -EINVAL;
}

const struct file_operations ext4_file_operations = {
    .llseek     = ext4_llseek,
    .read_iter  = ext4_file_read_iter,
    .write_iter = ext4_file_write_iter,
    // ...
};

We can do the same thing in Solidity!

The example we'll work with is a decentralized exchange. Users can call a trade function with the following signature:

function trade(address sellCurrency, address buyCurrency, uint256 sellAmount);

To compilcate things a little, let's say that the exchange deals with more than just ERC20 tokens. Let's allow for ERC20 - ERC20, ERC20 - Ether, and Ether - ERC20 trades.

Here's what a first attempt at implementing this might look like:

// Let address(0) denote Ether
function trade(address sellCurrency, address buyCurrency, uint256 sellAmount) {
  uint256 buyAmount = calculateBuyAmount(sellCurrency, buyCurrency, sellAmount);

  // take the user's sellCurrency
  if (sellCurrency == address(0)) {
    require(msg.value == sellAmount);
  } else {
    ERC20(sellCurrency).transferFrom(msg.sender, address(this), sellAmount);
  }

  // give the user their new buyCurrency
  if (buyCurrency == address(0)) {
    msg.sender.transfer(buyAmount);
  } else {
    ERC20(buyCurrency).transfer(msg.sender, buyAmount);
  }
}

This doesn't look terrible yet.

Now imagine that you wanted to handle even more asset classes.

What if there was a token YourToken that had mint and burn functions callable by the exchange contract? Instead of holding a balance of YourToken you just want to either take tokens out of ciruclation when they're sold, or mint new ones into existence when they're bought.

Or you want to support MyToken which I annoyingly implemented without following the ERC20 standard and function names differ from other tokens.

With more and more asset classes, the complexity of the code above would increase.

Now let's try to implement the same logic but taking inspiration from the Linux kernel's generic handling of files.

First, let's declare the struct that will hold a currency's information and methods for interacting with it. This corresponds to struct file:

struct Currency {
  function (Currency, uint256) take;
  function (Currency, uint256) give;
  address currencyAddress;
}

Now let's implement taking and giving tokens for two different asset classes.

function ethTake(Currency currencyS, uint256 amount) {
  require(msg.value == sellAmount);
}

function ethGive(Currency currencyS, uint256 amount) {
  msg.sender.transfer(buyAmount);
}

function erc20Take(Currency currencyS, uint256 amount) {
  ERC20 token = ERC20(currencyS.currencyAddress);
  token.transferFrom(msg.sender, address(this), amount);
}

function erc20Give(Currency currencyS, uint256 amount) {
  ERC20 token = ERC20(currencyS.currencyAddress);
  token.transfer(msg.sender, amount);
}

Finally, we can perform generic operations on currencies:

function trade(Currency sellCurrency, Currency buyCurrency, uint256 sellAmount
) {
  uint256 buyAmount = calculateBuyAmount(sellCurrency, buyCurrency, sellAmount);

  sellCurrency.take(sellCurrency, sellAmount);
  buyCurrency.give(buyCurrency, buyAmount);
}

Adding support for a new asset class is now as simple as defining a pair of take/give functions. The code inside of trade need never be touched again, following the Open/Closed principle.

Static site generation for GitLab Pages

Unlike some other static site hosts (like GitHub Pages), GitLab doesn't have you just upload the html/css/js files for your static site and host them directly, but gives you the option to maintain a repo that uses some sort of static site generator (say Jekyll, a popular option). It then has you use the gitlab-ci system available for every repo to actually compile the website, and if that succeeds, makes your website available.

You still have the option to host a set of plain html files, and GitLab provides a template for that setup.

One slight point of confusion I encountered was when I missed that the build directory has to be called public. Just looking at different .gitlab-ci.yml examples, I thought GitLab would look under whatever path was specified with

pages:
    artifacts:
        paths:
        - <path>

DNS configuration

I picked Namecheap as my registrar because they're considered reliable, have cheap registration (got this .xyz for $1 for the first year!), and they're not GoDaddy. Registration and payment was super simple, would recommend. The DNS configuration page can be slow to respond unfortunately.

I've never played around with configuring DNS records, but GitLab's documentation had fairly clear explanations. The biggest gripe I had was that the official documentation recommends against using a CNAME record , while the Pages UI under my repo had a CNAME record (and no A record) made available for copying, as if that were the recommended route. I ended up creating an A record pointing to 35.185.44.232 as described in the docs.

I had a few issues that I'm not sure if they were caused by Namecheap or just expected DNS propagation delays. It took several hours for the A record to appear in DNS queries. Additionally, I missed the part where when creating the TXT record that verifies ownership of a domain name, if you're creating it for an A record, you should just use your top-level domain. Again, confusingly, the Pages UI provides a copyable text field to a dummy subdomain and I had to dig through the docs to find the correct approach.

(•_•)
<)  )╯Always
/  \

\(•_•)
 (  (>  Own
 /  \

 (•_•)
<)  )>  Your Platform
 /  \

In the spirit of minimalism, it's (as you can see) very bare-bones.

In the spirit of self-reliance, it's built with a custom static site generator (which is really just a few glorified Ruby scripts) that (again, in the spirit of minimalism) do only what I need them to do (and hopefully do so well!). ]]>