If you want to look at the hack-job that made it possible, it is right here: Folder by year/month commit

But then came a day where I tried making music digitally, and that changed the whole situation around. It is a lot of fun to just mess around with music in that way, and I started to understand why there are so many people who like music production. And there is this awesome genre of music that I discovered, called chiptune music, which also feels very fitting as video game music.

Previously I made it in a little program called Bosca Ceoil, the name of the program is literally music box in Irish. There still is an active fork of the program called Bosca Ceoil: The Blue Album, which also works in the webbrowser. With it you can quickly create this kind of music, within minutes you can make a small tune like this:

With only a single instrument, you can already add a lot of variety, but it is way more fun to add more instruments. It is amazing what some people can make with just a few simple sounds, they can make the entire audio for a video game with it or mixtapes that last hours. You can probably do a way better job than me, so I would encourage to give it a try and have fun.

For now it is more a personal experiment to make music, but who knows what I will do with the music in the future.

When you have a module in your code, you could export everything and import everything where you use it. You can have a rough equivalent #include’s, and end up with a source file that is just split up over multiple files. That is, if you import by following a collapsible structure, a DAG to be specific, without tangling it into cycles.

Although this is useful, it is a small benefit compared to code with sectioning if you do not hide implementation details. Modules that reach outwards to grab stuff are not necessarily a threat to replaceability. They can be part of code up in a hierarchy, and here is the key; that can only give it’s benefit if you mostly abide by it. The further you stray from it, less of its properties are true.

Concrete example: a hierarchy for a single page application. In this example your application has pages, pages have components, components use data and utilities to act on it. A page describes what is shown, and picks the parts to compose it.

This hierarchy has the property that allows re-use the more you use it. But beware, this is a fine balance between verbosity and re-usability. The intuition that is worth having here is that code has a good-enough placement in the program at any given point. As discussed in the post about duplication, duplication and abstraction go hand in hand; you can move between the two if you follow a design.

You do not know what is best for the system in advance, as you don’t know the requirements that come it. But you can design it as such that changing the system allows you to still reason with it, and not relearn it like it is a completely new system. Code modularity is both about saving you as a developer effort, and saving your teammates the effort to relearn specifics. If you design your code with library design in mind, you are already taking modularity into account.

And if you write code that the linter complains about, take it as a hint to also consider your overall design. And if you write code that you name very similar across modules, unroll the imports manually and see what your code ends up being. Put your existing code together experimentally, if you try to figure out the fault of the design. Make it painfully obvious when the same concepts have separately evolved implementations. It is inevitable that you write this kind of code, you are human afterall, right?

The usual

I could make all the posts as HTML and serve them statically. The only parts that change from post to post are the content, date and title. This would work fine, but it has one flaw: the network traffic has a lot of boilerplate HTML. Why bother the server with that?

The API that comes with this website already serves the data that changes for each post. The job of the post page is to show it in the format you are used to. Besides that, you can always read the posts via the RSS feed (link deprecated, see top of post).

Although it saves a bit of data, it does make the website overengineered. A good friend pointed out that the pages can use caching, if you use a static site. As a bonus, more of the JavaScript can be removed, which is another victory for the website. So the website will move towards being more static, as that suits the small scale better.

This post is part two of the journey to build a life-long information system.

—

The previous post in this series ended with questioning where the book notes should live.

It lead to creating a personal wiki; vimwiki. The export-to-html feature was nice to view the notes on other devices. The tools allowed to mass-edit digital notes, with the classical folder-per-notebook slowly breaking down and relating more notes as it was so easy.

The other major feature was it supporting multiple file-types; also Markdown which made it fully compatible with markdown-tools like Obsidian. And that is where the volume of notes really took of, as the digital tooling encouraged a growth mindset so you have more to link notes to. The wiki part in vimwiki was the most misleading, as my initial thought was to create a structure resembling WikiPedia. That created a linked mess, a growth mindset set on volume instead of set on quality; contribution mindset.

Consider this task; make the block of hash-symbols rectangular, no holes if you draw a rectangle around it:

# #   # ####### ####### 

It is a common theme to have solutions be an addition instead of a removal, most would fill the top row instead of removing the top 3. Ow, and if you said that it didn’t specify you could remove symbols, did you even consider it?

The unconscious doing because it looks neat is also is the enemy for people that work with Obsidian, because they like the look of their huge graph:

That is the hidden cost of digital note-taking if left unaware; copying is so easy on a computer, that you barely have to process the information. Common remedies are writing everything in your own words, separating a place to reference quotes and literature and quitting digital all together; which will be discussed in the next part.

Figure 1: The original cover for the first spec/docs of MBLF

From the point of the compiler, it shouldn’t affect the behavior of the code. It should be purely for organizing code. That is if you take optimizations and concurrency with a grain of salt. It should be a benefit to the reader, which are the other programmers that will read this code later. This includes your future self, so you better make sure the code is readable.

But, how will this work when the program needs to change? Because the programmer will attempt to change the code to fit new requirements. And if the abstraction doesn’t fit anymore, the idea behind the abstraction got outdated.

To get rid of the now wrong abstraction, you first identify how the abstraction works and their concrete counterparts. Implicit rules of the language become explicit, like inheritance turns into explicit delegation; by duplicate calling structure and further by duplicate code.

And then you have it unrolled, right in front of your eyes, to the most modifiable state you need, all the way down to assembly if you wish. And then you freely make the needed change, a specific change to the code that takes in the new requirement. The skill is to know what to write, so the code as a whole can be re-abstracted, and it won’t be the old code with the new requirement as a blob. Code is never in a perfect state, but to leave it as the latter is neglecting the code.

How would this re-abstracting work? An oversimplified example would be taking a for-each loop, with the requirement that you only take the even indices. Assuming imperative programming, by this plan you would unroll into a for loop with a counter. Then you make the change by changing the advancement part. That puts the new requirement idea in and the old one out.

But that syntax has too much variability for this idea, so the code is under-abstracted for this idea. I find it ugly to set the counter to zero and the loop condition to remain within bounds; too much focus on the how and prone to typing errors. So you re-abstract. It might sound silly to do this for a for loop, remember that this is an oversimplified example. As having the for-each loop is clearer, even if you know it won’t fit new requirements. I argue it is better to keep the code as simple it can be for your current requirements. You can bring benefit to the future reader by keeping it simple, and not use that code further once new requirements come in. Otherwise the tendency for future-proofing is too strong. It fits with developing incrementally; each version of your project got the refactoring it needed and is usable.

Real requirements can go against your whole architecture. The programmer will start to panic and realize the design is crumbling down when changing the code to the requirement. It is a divide and conquer against the code, which at every step you break open the needed parts to fit the requirement. Abstracting is solidifying the ideas, while keeping duplication is accepting you don’t want to maintain the current underlying idea to that extend. Keeping duplication to a degree is delaying the second step of this plan to the future, a future where this idea is perhaps not relevant anymore. Where importance has dropped, and it isn’t the center of your design anymore.

The center of your design serves as the opposite, the parts you don’t want to change. You accept the high risk for the high reward it gives, for the months that will follow and don’t have to work with too open code.

In summary:

1. Code has a lifetime, bound to whenever the idea behind it changes.
2. Duplication is bliss while discovering change.

I wanted to re-use the notes I already had, and I came up with an interesting migrating strategy. The default would be to discard the old note, except for the lines that are still relevant and make sense to tell myself right now, to remind myself of later. That turned out to not be much, as a bunch was already internalized for the years I had it, no more need to keep it around; it had fulfilled its purpose.

The notes left were still interlinked. This sparked yet another idea: what if the purpose of the digital notes it so converge to no-connection notes? That the connections that are present represent draft connections, before I migrate it into the analog notes? Then the digital notes are truly capture notes, minimal, and made with a clear purpose.

So that is the way I will be doing it for the time being, letting go of everything that has used up its value.

It can feel like an obsession if you keep yourself to strict rules to do something daily. That also blinds you for what you are pursuing; progress. It is not that you practice so you can say you tried every day. You practice so you can achieve a goal and have fun along the way, who cares how much effort it took.

Sometimes it is easy to forget this if you only look at metrics, for programming this can be the amount of commits or the days with coding activity. To make progress also means changing what you think you are capable of because you can do more after making progress.

Because let’s be honest: If you had other areas in your life where you did hard stuff because you wanted to, you can do more than just “ow lemme do 2 more pushups, phew done it, almost sweated” That would just hold you back by pretending you are a complete beginner constantly; use the skills you have to enhance the advice. The best heuristic for physical exercise I have found thus-far is the 40% rule. What you are physically capable of is like a battery that gives warnings when it is being depleted. The 40%-depletion warning is when you get the thought “i am so done, i can’t do any more of these”. You surely know how to extrapolate this, but just in case: if that thought pops up at 20 pushups, your target for that set is 50. It is just a warning, a thought, a notification, letting you know where you are at. Because in nature, you would not survive by draining yourself to 0 for simple task; you would be too easy of a target for predators.

“But what if I go to far?” Well, have you, and if so: did you not recover? Injuries aside, which risk can greatly be reduced, finding the upper limit is a good way to set a baseline. Exercise is a fine balance, discover both sides to know the meaning of the signs your body gives you. How this upper and lower limit discovery can help, here is what good isolation of the two can do:

Let’s say you want stand on your hands. Analyze for a second what exerting too little and too much means:

• exert too little power means you fall back to your feet.
• exert too much power means you fall over.

The first case is what will probably happen. A good exercise before starting the training is forcing yourself to the last case: just go full power and fall over, learn to fall as best as you can. Now that you have fallen once, and you have seen that it wasn’t bad at all (assuming you fell on a soft-surface ;D).

This simplifies it, mentally prepares you, so you can now start the training. It is also part of setting up your learning environment, be it mentally. From there the training can begin.

Same with stamina:

• go to little and feel little discomfort.
• go too much and feel lightheaded.

From there the training can begin.

—

We gaan door / We persist

We gaan door / We persist

Ook al weet ik niet waarom / Even if I don’t know why

Ook al weet ik niet waarvoor / Even if I don’t know what for

Maar we gaan door / Yet we persist

We gaan door / We persist

We gaan door / We persist

— Youp van’t Hek

The paper shredder in question has three modes: automatic, off and reverse. So there is no just on mode, it is assumed that the shredder may only start when a paper is pushed in so that it automatically starts and stops. There is a latch in the machine that gets pushed to close the starting circuit.

The thing with this latch is that it is annoying, sometimes gets stuck or gets paper stuck on top of it. And that tiny bit of paper on top of the latch makes it harder to detect the paper. Because there is no always on option, you cannot let the paper go through, reversing also does not clear it.

So one day enough was enough, it was time to improve this piece of hardware. The electronics inside were accessible, as they should be. There was quite a bit of paper pieces that made their way inside the chassis. After cleaning that out, I removed the latch and was left with the two wires.

Connecting those wires directly two solved all problems. Now the shredder just runs until you switch it to off, and there is no latch to get stuck on. How hard would it have been to just provide an always on option as well, or is that too much to ask?

One way to solve the storage question is to not be the maintainer yourself. It sounds snarky, but for public projects it makes sense to attempt merging with the upstream. The chance of a fork getting populair is quite low if you ask me, unless it is really good.

For private projects is is a different story, but because they are private it is sufficient to just backup the repositories somewhere. For internal projects, there has always been a GitLab instance I could make use of. For public projects, most of the projects were just applications and not libraries.

After a while, I questioned if I should also publish and become a maintainer for a project. I felt comfortable enough with being a maintainer, after being one for several internal projects. At the same time there was a strong sense of perfectionism; not wanting to polute the internet with stuff that has no use.

Your requests for usablity have been heard, v0.2.0 of the software has been released. All properties that the template use now show their name in a third column. This data is only fetched once, and cached locally on your device to minimize requests. The examples in this blog post have been updated to the new output.

wikipedia-infobox-analyzer   --title Earth   --lang en   --template <infobox_template_file> 

│ Infobox requires │ Wikidata Earth (Q2) │ Property name │ ├──────────────────┼─────────────────────┼───────────────┤ │ P18              │ P18                 │ image         │ │ P170             │ P170                │ creator       │ │ P571             │ P571                │ inception     │ │                  │ P31                 │               │ │                  │ P138                │               │ │                  │ P361                │               │ │                  │ ....                │               │ 

│ Infobox requires │ Wikidata Earth (Q2) │ Property name │ ├──────────────────┼─────────────────────┼───────────────┤ │ P18              │ P18                 │ image         │ │ P154             │                     │               │ │ P170             │ P170                │ creator       │ │ P178             │                     │               │ │ P275             │                     │               │ │ P277             │                     │               │ │ P306             │                     │               │ │ P348             │                     │               │ │ P400             │                     │               │ │ P548             │                     │               │ │ P571             │ P571                │ inception     │ │ P577             │                     │               │ │ P856             │                     │               │ │ P1324            │                     │               │ │ P2096            │                     │               │ │                  │ P10                 │               │ │                  │ P31                 │               │ │                  │ P138                │               │ │                  │ ....                │               │ 

{{... Wikidata|P18|P31|P361|P571}} 

{{Gebruikt Wikidata|P18|P154|P170|P178|P275|P277|P306|P348|P400|P548|P571|P577|P856|P1324|P2096}} 

│ Infobox requires │ Wikidata GitLab (Q16639197) │ Property names              │ ├──────────────────┼─────────────────────────────┼─────────────────────────────┤ │ P18              │ P18                         │ image                       │ │ P154             │ P154                        │ logo image                  │ │ P170             │                             │ creator                     │ │ P178             │ P178                        │ developer                   │ │ P275             │ P275                        │ copyright license           │ │ P277             │ P277                        │ programmed in               │ │ P306             │ P306                        │ operating system            │ │ P348             │ P348                        │ software version identifier │ │ P400             │                             │ platform                    │ │ P548             │                             │ version type                │ │ P571             │ P571                        │ inception                   │ │ P577             │                             │ publication date            │ │ P856             │ P856                        │ official website            │ │ P1324            │ P1324                       │ source code repository URL  │ │ P2096            │                             │ media legend                │ │                  │ P10                         │                             │ │                  │ P17                         │                             │ │                  │ P31                         │                             │ │                  │ ....                        │                             │ 

Perhaps enjoy some self-made video-games.

Having no concerns about the quality of them, they make for a great playground to improve all-round gamedev skills.

At the end, it results in something to enjoy and share.

It is as simple as that, so lets get started!

The opposite is such a demotivating mess that makes you regret doing any large changes. Make backups and allow rollbacks, keep the development version in sync with each other. So that the tests you write also execute when they are working on their changes, not breaking yours.

Often you do not have the luxary of starting out a new project from scratch. Already existing projects sometimes have complex manual setups, not always for reasons that still apply. Do yourself a favor, and make it durable to work on the code. You know the codebase is in good shape if you do not fear changing it.

Instead of compensating this lack of movement with an entire dedicated activity for exercising, do not forget to look into what you currently do and making that more active. Commuting is a good example, I know good examples like biking (partially) to work. Or walking around during breaks, not just walking to where you need to go but also for other means.

A lot of people on one side, and a lot of people on the other side. Competing for followers, competing for jobs, competing for promotions even though neither is qualified.

Then there is one shady looking dude under a tree, reading a book or a newspaper. Just in their own reality, relaxing, looking around, not giving a flying f*ck about the world around them.

I wish to be more like that, just doing their own thing they are good at and sharing it when they made a contribution. If the dude under the tree is bothered too much, they put headphones on.

In software, it might be the start of a new era, a new dawn, a new way of working. That combines modern computing with the classic IT we used to know and run.

When I see the recent developments in IT infrastructure currently, I cannot express the excitement. About what kind of projects are now possible if you do data engineering well.

Perhaps more open-source software in public infrastructure, it would make sense to me. More development of semantic web technologies and IT automation inside regular infrastructure, which are topics I would want to specialize in further.

Background

This sounds promising, you might even give it a try, especially because it is free. To begin to understand the breadth this technology is granted, try to understand the technology by thinking of it as an intern. Try to visualize the amount of knowledge that is willingly exposed as if it is an intern belonging to the company. Because it has dialogues with the employees, and it is unclear if the employee even talks to them. It can be totally hidden, attempts to spot it are a lost feat. The right hand doesn’t know what the left hand is doing, but meanwhile a new standard of performance is build. One that leaves the left hand no choice but to live up to its name it seems.

The hobby clicked when trying to make pictures of the plants, and learning about photography.

It was kinda by accident I was keeping track of growth of the plants, as friends asked about the plants and wanted to see them grow. That lead me to sharing the plants with plenty of others, as after a bit of practice more plants survive and thrive instead of wither away. There is almost something magical of seeing a gifted plant thrive at someone elses home, so I am glad to see more of it in the future.

It has already been several years since we first started coding together. Or better said, watched with admiration for his programming skills.

These developed into hacking skills I still can’t get my head fully around, yes you are definitely the better hacker😀.

As we competed against each other for fun, it was actually our past selves we competed against; We both improved our own skills, and made awesome projects. So thank you :D

The Holocene correlates with the last maximum axial tilt towards the Sun of the Earth’s obliquity. The Holocene corresponds with the rapid proliferation, growth, and impacts of the human species worldwide, including all of its written history, technological revolutions, development of major civilizations, and overall significant transition towards urban living in the present.

It starts counting years roughly after the ice age, after the adorable character Scrat finally collects and burries the acorn. It is quite easy, just add 10,000 years to the current commonly used year format. Quite a clever choice, because it is distinct enough to recognize without having to do any difficult conversion. Just write a one in front, and perhaps a comma to denote thousands for readability.

Now ofcourse it is not recommended to just change existing data to it. I see it as just a unit, a display option like Celcius and Fahrenheit. On this website, I have changed the year format on the post index page. It took a staggering one line of code and voilà, now it is fancy.

Existing urls will be kept, and so will the semantic datetime attribute.

This post is part three of the journey to build a life-long information system.

—

The previous post in this series ended with the remedy to quit digital again and keep all important notes analog like they initially were.

This analog system would be a tool to process the books I have read with more depth, by forcing you to spend time and rewrite the information so that it becomes knowledge. This is where the Antinet comes in.

The Antinet, the analog numeric-alpha tree-structure with indexes network for information, is a classy version of that and more.

There is an introduction to antinet zettelkasten for the core principles and historical background, as well as a starting guide for when you are ready to take the dive, so take a look into that for all details.

After researching it, I committed to migrating all my book-notes to it. So I grabbed an old shoe-box and cut it to fit A6-cards neatly, and made all the cards required to start out; index with spacer, initial main cards with spacer and bibliography spacers. I used a bookstand inside the shoebox to keep the notes standing upwards, which is easily moved when there are more notes.

Maybe this deserves it’ own story, but what is important for now is that Doom Emacs is my main editor. It is perfect as it is so full of features, and convinced me fully on the beauty of lisp. Ow, and don’t get started on how great org-mode is, it is being used as this article is written :)

  (+evil/window-split-and-follow)   (eshell) 

(defun split-and-term ()   "Make eshell a proper terminal."   (interactive)   (+evil/window-split-and-follow)   (eshell)) 

(map! :leader       :desc "Open eshell as a terminal"       "o t" 'split-and-term) 

This idea of problem formulation directly translates into programming itself: be as clear in intent of the code as you can be, it just so happens the notation is executable by the computer.

So why not leverage compilers even more? What if the basic operations you would do on datastructures, push, pop, peek, insertion-first, -last, remove-first, -last etc. would stay the contract? What if ICollection, IList,.. would be implemented by a compiler chosen implementation, matching the usage of the basic operations optimally? This could even be semi-automated, some kind of interactive process with the programmer, always allowing the programmer to override the compiler’s suggestion.

This process would go something like this: the programmer is as declarative as possible in intent. Then the compiler can internalize the collection lenghts and intersect the used operations against the available datastructures. From there it is a game of picking the best by utilizing the time complexity tables.

The package system also supports a ton of specific repository-types, which re-sparked an idea; Post Apocalypse Coding

The challenge is to pretend there are no third-party libraries for the programming language your are currently working in. To help yourself build projects reasonably, you will also form primitive versions of common libraries and re-establish the classical ecosystems slowly.

This title co-incidentally already had a lot of related ideas, one of the closest was about building low-level tooling up to an interpreter. That would be hard mode, and would be a proper apocalypse.

A limbo of thoughts which somehow has economic efficiency residing in it permanently. Or so it seemed. It probably had to do with conversations I had lately, conversations about the crisis-crisis that is “plaguing our society yet again”. Or other conversations, on whatever self-inflicted issue topic addressed by the same folks who made it. The topic of actions being good or bad for the economy keeps popping up in such conversations. And every year the conclusion is, after a lot of shouting, that some things have improved. One of those is always that the economy grew a bit again. Another is that access to externally produced goods has improved. “That is to accommodate for more people”, a partial truth statement using poor language. It states without difference between meaning equally more, or that one is steadily outgrowing the other regardless of it.

At this stage of this thought, you get ideas like looking to the worlds regardless of money. Just seeing it as a whole as is. Constantly, physical stuff is moving around to far places, along with paper or bytes that go back and forwards between people.

It somehow justifies that a teenager stares at wall for an hour, and then permits the teenager to let a plastic figure come shipped from China to them. It is business as usual, because the numbers add up. Also, as a bonus, GDP just grew. Well done teenager, contributing to society!

By these examples, a minority people get a power-trip. From that point on, every decision accounts money, as it is so powerful if you have it. But you get nothing for it in return if you already have your basic needs in check. You only lose time to something that seems worth striving for.

If something costs 20 bucks to buy, lets say a scarf, you would buy it if you need it by simple reasoning along with the above. The yarn would be cheap, but the labor to make it is way too expensive. After two hours already it is not worth it anymore by time-spent only, according to the minimum-wage where I live. It is simple reasoning, there are tons of other reasons why you would still do it yourself. The point is more that it can be a plaguing thought, one that is permanently in that limbo.

And to remind myself of it just being that, an idea in the limbo, I made a gentle reminder to myself that also keeps me warm:

The article covering it has been translated into English, which can be read in-full here.

The posts from SURF about it can be found here and here.

There are generic structures you can utilize for the source code you write. There is a sense of code style, just as there is a writing style in prose. This can be a technical code style, which is typically dealt with by a linter that enforces nitpicks. Yet, this is not the only style for your source code, there are also styles for ordering your code. An example is ordering your code by abstraction, which is commonly known as a writing style for newspapers.

In a newspaper, you typically read the headline first, and a first paragraph that describes the article; the abstract. Abstract here means the content described in the highest abstraction, which will be the main function of our source code by analogy. So should your main function contain all details directly? Not by this analogy, as a newspaper has further paragraphs to elaborate and discuss those details. Those details are not the concern of the abstract, that is implementation detail for the further paragraphs. Every paragraph adds more detail, and allows the reader to decide if they need to read on. It does not leave open ends because details sit in the way, as those lower level details are in the later paragraphs. Ideally, you can read any amount of paragraphs from the start, and understand the program. The further you decide to read, the more details you know; yet you are never clueless about the purpose of the program until you read everything.

As a side-bonus, the server does not need to run node anymore. So the server is lighter as it only needs to serve static files. It now is Node-bloat™ free. So bye bye node.js fastify server, even you are not needed anymore. The spooky JSON layer is also removed now; Before, the server produced a JSON result from the entered posts, which was used by the client to display the proper HTML. What remains is a customizable input format that is directly converted into HTML using some templates. Adding shorthand-notations is easier then before, as it is just another layer of translation. And thus by accident, I made a transpiler!

Programming small sketches and animating them was one of early projects I did with programming. In some other posts I mentioned the use of Processing, P5.js or more recently Quil for canvas programming. I initially started with following tutorials on the internet, like The Coding Train, and repeating the code and making small modifications.

Lately I revisited what creative coding means, and got a lot of inspiration from artists and other creatives that are actively involved in it. Questioning the norm of software development, piecing it together in ways you do not expect. Or sometimes it just begins with a question, like “why are websites always expected to be online?”. The follow up then could be “well, when does it make sense to be online?”. If your answer is when the sun shines, great, you discovered the project of building a Solar powered webserver.

 __________________________ < Thank you for your order >  --------------------------         \   ^__^          \  (oo)\_______             (__)\       )\/\                 ||----w |                 ||     || 

But, the stickiness can dissolve if you let it sit and not pass it along. One example is web frameworks, especially those who have been around for longer and have improved greatly since. They still get a bad reputation because of their history.

It is easy to go along with the experience of those who have been programming in it for longer, even though their use-cases and starting point were different. Because you still don’t have the experience to join the discussion at that level, it is unfair in every way. The solution? Look into the matter yourself; give frequently changing software a fresh look, as if you are a beginner. Because you really are; just because it has the same name as before isn’t enough to know the experience, only experience will tell.

Attempt to write down how you make decisions. This will serve to give insight into your thinking, and brings awareness to what you consider for your next choice. If you have an important choice to make, its importance should allow you to take more time to consider a decision. You would re-evaluate later when you can think clearer, it makes the answers less rushed.

Here is a parody on the first part of the 1951 Christmas song “It’s Beginning to Look a Lot Like Christmas”:

It is beginning to look like a blog-site, on every site you click.

Take a look, it’s already past post five.

With silly stories, and documenting works.

It’s beginning to look like a blog-site.

Served in just simple text.

But the prettiest sight to see, is the holly that will be.

No more JS,,, for,, thee,

The following is the original songtext:

It’s beginning to look a lot like Christmas, everywhere you go

Take a look in the five and ten glistening once again

With candy canes and silver lanes aglow

It’s beginning to look a lot like Christmas

Toys in every store

But the prettiest sight to see, is the holly that will be

On your own front door

• The MBLF compiler (this is a large milestone)
• This Personal Website
  • has transfered to HyperLisp! as the markup syntax
  • has more quality-of-content upgrades
• Complete transition to Arch-Linux on desktop
  • Added more dotfiles along the way
• Completed 4 practicals within the followed CompSci course
  • Quickhull with AccelerateHS
  • Mini-C# compiler with ParserCombinators
  • Logical-Chainer (Forward and Backward)
  • A set of Prolog coding problems
• Toyed around with LISPS, following SICP

Fortunately, there is still an entire career ahead and plenty left to do. So as much as you could worry on the work you do early on, there is plenty of room to make mistakes if you consider how long the total career can be. And that gives a peace of mind, not to worry too much if a project turned out different than you expected. Because there are plenty of projects left to come, and sometimes you only understand their purpose much later.

And as you are the one who is working on the architecture, it is part of the result you deliver. You do not deliver just the architecture, you also deliver the developer experience for the next person who will work on it. Changes in the architecture that take more time to fully implement can still be started. Write them in the current architecture, as nudges for the developers to show the current heading. What would happen to the code, if architecture improvements are only drafted in a report? The code changes in the meantime and the intent may be lost. Larger changes still have a start that can be found as a minimal solution that gets the idea across. And as it is minimal, reverting also is.

To my own surprise I actually never posted anything on stackoverflow. Neither as a question or answer. So it was time to change that, I figured to answer some posts. After browsing through the new questions, I found a post to answer.

Using git tag descriptions in your CI

That final project was made three years ago and is still actively used. For instance, the project has been demonstrated as an example for the new graduation projects, which is quite an honor to hear afterwards. So I figured that it would be fun to shortly introduce the game here.

Will you hire a so-called vibe-coder, which has delegated all executive functions to a virtual chatbot. Or will you hire the “wrote the CMS by hand” wizzkid that thinks you are crazy for needing to consult the internet instead of local manpages.

It may just be a gut feeling, but it feels like a lot of cost can be saved by not hiring the first. That there are a lot of hidden costs added to projects in the form of technical debt by choosing for the first.

Further hidden costs would be the choice of frameworks and other tools that are quite niche or still in active development. I have had the delight of choosing a frontend framework more than once, which is not a lightweight decision for a website project. There are a lot of fancy options out there, but for a project with a lot of people the plain choice sticks best. If the website needs to be dynamic, going for React with JavaScript or TypeScript works well as it is well understood how the framework operates; it is battle-tested.

And the same logic can be applied to the selection of tools for cloud infrastructure. Tools like docker are also getting more sophisticated, making it sufficient to make the infrastructure solution work with lightweight tools. If all the customer asks for is a sandwich, using ten different kinds of spreads on one slice of bread does not make it better; they will probably just prefer a peanut butter and jelly sandwich.

Native cluster management exists with docker under swarm mode. And for a lot of projects, that may already be sufficient and also simple to understand. Hold the urge to be fancy, because you might add a bunch of tooling that at the end turns out to be redundant.

In addition, because the internet is full of large configs, chatbots will also sprinkle in a lot of unneeded configurations. So when you want a minimal setup, that is something to keep in mind if you let a chatbot draft up the initial configuration.

If you think I am exaggerating, I invite you to the following exercise. Open up a random email you received from a company, and look for the “show source” option in your email program. Chances are that you are presented with a large wall of HTML with probably a lot of noise that is not text content of the email. But okay, you say that is needed to make it look professional and pleasant to read, so far all reasonable.

What is not reasonable is the total size typically sent emails take up. And to understand that better, take a look at the structure of an email that is a reply. You know, with the title typically starting with “Re: …”. Under the hood that email has a “In-Reply-To” header. So if you have the previous message, your email program can piece them together and visually show the chain of messages as a thread.

If you look closer to the raw text of such a reply email, you see something different. Instead of just linking to the reply, the reply is typically also quoted in full. Modern email clients like Microsoft Outlook do this when you press “reply” and have influenced what is considered “normal” via these provided defaults.

That means that the size of the email grows steadily, as each reply copies all previous conversation history again and again. Totally unneeded if you are replying to the same person, which should already have that message history. It should not be surprising that this allows selling more storage space to organisations.

Does this go by unnoticed? Because what about the size of the emails you receive? Anything under a megabyte does not sound like much to most people. Most work environments encourage email footers, typically with a company logo. And that logo is also typically not linked, but copied in full as an attachment.

People talk a lot about “consider before you print this email”, but what about the footprint of the email itself on datacenters? This behavior is not the fault of its users, it is a symptom of the software making it. The discovery of this information for me started with using a different email client. And with curiosity of how email functions and the discussions people had in the past about email.

Recently I was pleasantly surprised and educated by the format I received an email reply in. It was neatly in text form, with interleaved replies and no further noise. That lead me to revisiting this topic and eventually also to writing this article.

Read more about posting style here

And so a game was born. Would it be 3D? No, ofcourse not. 2D? Well that sounds more like it. What about making some graphics? Why not. Pair programming? Well THAT sounds really nice.

The entire project took only 35 hours ish, with 20 hours pair programming. So it was a gamejam. We had a lot of fun making it, and you can checkout the game here: Space Stride A lot of the architecture on top of MVC is from this documentation on design patterns in Elm.

To give an example how it translated to SpaceStride, just look at src/Model.hs. It has the following all-describing GameState:

16: data GameState = Playing            { _playingGame :: PlayingState } 17:                | Paused             { _pausedGame  :: PlayingState } 18:                | PlayerDead         { _deadGame    :: PlayingState 19:                                     , _animationFrameCount :: Int 20:                                     } 21:                | GameOverTypeName   { _score :: Int 22:                                     , _playerName :: String 23:                                     } 24:                | GameOverShowScores { _score :: Int 25:                                     , _playerName :: String 26:                                     , _highscoreBoard :: HighScoreBoard 27:                                     } 

This already gives you tons of information about the game, and gives you a clear idea of the data that gets passed around. And it gets even better. These records can be enhanced with Lenses and Prisms. I absolutely fell in love with how declarative the code can get with this small addition.

To illustrate this, lets have a peek at src/Controller.hs. All you need to know is in the top-level functions.

For Playing, it looks like this:

20: step :: Float -> GameState -> IO GameState 21: step secs (Playing pstate) 22:   | delta > secsPerUpdate 23:   = do randomNumber <- randomIO :: IO Int 24:        return $ (Playing $ pstate 25:          & seed %~ const randomNumber 26:          & movePlayer delta 27:          & moveEnemies delta 28:          & pruneOffScreenEnemies 29:          & scrollBackground delta 30:          & attemptEnemySpawn 31:          & elapsedTime %~ const 0 32:         )& collisionCheck 

And it reads just as you would describe it: If we are playing and it is time for an update, then we go to the next playing state. This state starts with the old one adds a new seed, which is constantly a new randomNumber, moves the player, moves the enemies, …

This simplicity also bubbles down to the event handlers, where at no cost keybindings can choose to be dependent on the current GameState variant:

59: inputKey :: Event -> GameState -> GameState 60: inputKey (EventKey (Char 'p') Down _ _) (Playing pstate) = Paused pstate 61: inputKey (EventKey (Char 'p') Down _ _) (Paused  pstate) = Playing pstate 62: inputKey (EventKey (Char 'q') Down _ _) (Playing pstate) = GameOverTypeName (getScore pstate) "" 63: inputKey (EventKey (Char 'q') Down _ _) (Paused  pstate) = GameOverTypeName (getScore pstate) "" 

And likewise supports updating in the same clear way:

64: inputKey (EventKey (MouseButton LeftButton) ks _ __)  (Playing pstate) = Playing $ pstate 65:   & (player . moveDirection %~ updatePlayerDirection 'a' ks) 66: inputKey (EventKey (MouseButton RightButton) ks _ __) (Playing pstate) = Playing $ pstate 67:   & (player . moveDirection %~ updatePlayerDirection 'd' ks) 68: inputKey (EventKey (Char c) ks _ _)     (Playing pstate) = Playing $ pstate 69:   & (player . moveDirection %~ updatePlayerDirection c ks) 70: inputKey _ gstate = gstate 

Go back to fundamentals of what source-code allows; It is the creation of programs. No rocket science indeed. The more source code you have written in a certain programming language, the richer the logic of the created program can be. Viewing source-code is as the composition of logic acting on data hits you deeply; These components are striving for reusability, capturing identical abstractions between their uses.

Uniting software would be the act of considering common parts between projects. A clear example would be static-site-generators, which captures content being static from the start/when updating the site. The capture is general enough to allow different types of outputs; HTML, RSS, Gopher-Markdown, etc. So it allows a simpeler codebase and more features. Great! Steps taken to reconsider the “capture” the project has, is refactoring on the highest level.

It felt great to be around people who just understand this passion, and make a living doing what they love. And that made me aware of the dream I still pursue as a software engineer, to eventually reconcile this passion into day-to-day work.

Luckily there were plenty of people sharing how they managed to do it, which reignited this dream of mine to double-down on it.

Oh, and the security talks, they were also great, it is insane how far that technology has come.

Oh, and stickers, can never have too many stickers of the various open source projects, love it!

The trip itself was quite comfortable, I took the international train from Rotterdam to Brussels. It only stopped at Antwerpen, as it was the direct line to Belgium and that saved a lot of time. That most people there speak French is still funny to me, so I also practised that language a bit. Did that go well? Not quite, I will just say that the results were mixed, and that mishearing “droit” and “trois” leads to an interesting conversation.

Can you use computers for your work?

I see no difference between the two era’s, and neither with next era created by AI.

As in every technological advancement, your individual capacity increases if you have access to the tools.

As in every technological advancement, there is a delay where you can be an early adopter vs when everyone expects you to use X given the expected outcome or even job.

And just as with the mass adoption of computers, the works that are around in mass will change.

And just as with the mass adoption of computers, there will be a mass adoption of AI for work that will cause earlier work to become less rare and easier to create.

If outcome is your priority, there will be more outcome.

If outcome is your priority, prepare for any means used to achieve it.

A tool is just a tool, don’t expect to learn the skill if the tool does all the effort, you then only learn to operate the tool.

You will only fool yourself. And if everyone fools themselves with it, the labor itself is lost.

Suppose you want to make the switch to a dumbphone, what are the roadblocks that lie ahead? Smartphone specific messaging services need a solid replacement when you used a smartphone before. Having your contacts switch over to other protocols could be unrealistic. You can adapt slowly, by simplifying the amount of services you use first. This also includes other services, like 2FA. I opted for the tool pass together with the extension pass-otp to replace 2FA. I like pass as you can script it.

Ideally, I wouldn’t even carry a smartphone. But until that is a reality, let’s focus on other stuff shall we?

Introduction

This post is part one of the journey to build a life-long information system.

—

So let us stick to physical notes for now. A few years back, I started taking notes seriously with a purpose. The main idea was to get rid of sticky-notes, and have one place to find all the small notes; a journal.

There are presets you can use on any notebook; I prefer free writing with fixed logs for time-periods (days, months, future).

It was a place to write, track and get things done. All kinds of lists, like book to read or already read, got a place where they could easily be found, used and extended. So I questioned where the notes on those books should be stored. In the random notebooks I used till now? Or somewhere where you could also work with the notes? This will be discussed in the next part.

Change, after change, after change. Isn’t software just done after some point? The set of responsibilities the software has moves around. There seems to be a temptation to make software be more and do more, all while reducing its lifetime by hackjobs.

Even software that doesn’t change in the source code, it still rots. The language its source code is in, how known the software is and the users that actively use it; they can all decline as the software gets older.

It is all replaceable and updateable, by developers that change in their preference. The same software can keep on existing in other forms; by being rewritten in other programming languages according to the original as the specification. If the software you build is still not done, and needs the support from the new features of the dependencies, then you should adapt to the larger shifts in ecosystems that developers work in and libraries exist for. If the software you build is already done, it would only need to if the ease of installation and ease of using it as a dependency is at risk; That is, if you still want active use. If none of the above apply, software can serve as inspiration in the current form, even when it doesn’t compile anymore. The source code can tell the story, and it becomes a part of history.

So would you consider changing the programming language of your project. Or does that feel the same like distro-hopping, where it only affects the starting-conditions? It doesn’t have to feel that way, as the old and new languages can co-exist. Bonus points if the newer languages transpiles to the old one, or any bytecode that the old one uses. It allows to use the old ecosystem as a stable base, incrementally update the old code where needed, and have an present day advanced ecosystem to work in for the new code. This made me go back to Java land, JVM languages take advantage of the decades used to build the Java ecosystem.

Compare that to editors where you write and do not directly see the result; for example LaTeX for writing. When you are used to seeing the changes instantly, you may also apply this mindset to LaTeX. Then you are the equivalent of a F5-spamming monkey, when it is not really needed.

Are you really productive when you keep waiting for it to compile on every minor change? When do you see the pattern of your change, and will you trust that it will give the output that it should?

Into the land of LISP

That is why the conclusion of most is to learn just enough to know what you can do, and little enough that is does not take a lot of time and makes you stop persuing. To show how little you have to know for certain impossible looking skills, here are a few:

In the early days of this website, about five years ago, it had a mongodb database for the blog articles. It made a request to that database each time someone was trying to access a blog article. Quickly I figured out that static was the way to go, which removed much of the complexity and made the infrastructure almost boring in a good way.

So then the posts are more frequent, with smaller posts. More of a idea-dump/what have I been up to kind of thing. He did it on the gopher protocol, which was a protocol I did not hear of before. It is quite an elegant and minimal protocol to use instead of HTTP(s). The website you are currently visisting is also reachable over Gopher, it has a simple landing page that redirects to the HTTP(s) site for the blog.

Accessing the internet through gopher feels like you travelled back in time, in a good way. The websites of enthousiasts are way more visible, and popular content is mirrored. You can access these sites via a gopher client like gophie, it is worth taking a look around and perhaps you may also make your website accessable here.

As the current framework, vue.js, did not fit the fine-grained control preferred for this site, a challenge came up: rewrite the entire front-end in a day. No more. Just one day. To spice it up some more, no JS dependencies allowed.

Less BLOAT!!! It does not float my boat. Here is a confession: front-end is not my specialty, at all. I could use some help with that. Focusing on the features of the site instead of centering a div, which can be hard from time to time according to some, keeps me smiling instead of crying (not literally, crybabies).

And, surprisingly, it worked out perfectly. The site works just like before, without the shitty performance and with even more hidden extra features I could sneak in. As the site is mostly HTML and CSS, it displays fine without JS enabled. So for the more secure browser users, they can actually see the site (mostly). Only the post page does not work, as is fetched on the client side.

For those still wanting to check out the post, a RSS feed will be added soon ;). And yes, I am aware these users can’t read this post, so I will make it really obvious the RSS feed is added.

Check out the changes I made here: GitLab

An example of this setup is shown here, it models a simple graph that spawns bananas. Each banana event spawns a single apple event which does nothing further. The event graph is visualized using a tikzpicture in LaTeX, so the additional information is added as comments.

\begin{tikzpicture}   \node[ellipse, draw, minimum width=2.5cm, minimum height=2.5cm, align=center] (B) at (0,0) {Banana}   \node[ellipse, draw, minimum width=2.5cm, minimum height=2.5cm, align=center] (A) at (4,0) {Apple}   \draw[->] (B) to (A); % np.random.uniform(0, 10)   \scheduleEventArrow{B} % Banana; 3; np.random.uniform(0, 80) \end{tikzpicture} 

All distributions should be specified for the graph, otherwise a warning is issued. This example uses standard distributions, drawn from the numpy library. Other types of distributions are also easily made, for example an empirical module can also be exposed besides numpy to support distributions based on the empirical data. That way they can be called the same way, so you would for example write empirical.random_arrival() as a comment.

The remaining event handler to write hooks into the information of the event graph. So when you call schedule_event(), you no longer have to specify the distribution; that was already provided in the event graph as comments.

global event_queue global statistics  event_queue = [] statistics = [] sources = [] connections = []  with open("event_graph_sample.tex", 'r', encoding="UTF-8") as f:   (sources, _, connections) = graph.read_event_graph(f.readlines())  def event_handler(event):   if event['label'] == 'A':     pass   if event['label'] == 'B':     schedule_event(event['label'], 'A', connections)  def update_statistics():   statistics.append(model['time'])  run_model(lambda: queue_from_sources(sources), event_handler, update_statistics) 

Then you may think it over, and realize that adding such importance only added chaos, so you might give removing and grouping a try. By which you realize it works, and you overdo grouping to the point it becomes way too rigid and becomes a chore to maintain. Yes, removing and separating adds value to the items, to the point you sense similarity and can search it. And for this sense of similarity you can use categories you are already familiar with, you are hacking your own association skills. Remember that it is just an entry point from which you start reading notes, so making it too specific makes it unused and unusable as there may only be one note adhering to it. Allowing chaos in notes means having room for the notes to belong to, and be discard from without having to restructure or to crawl to many notes to find the right one.

Ow, and there is no need to apply structure to all you have lived with unorganized in the past and worked fine with, that would be redundant work. Often I hear these complaints on sorting email, that the inbox has thousands of items and it is too daunting to go through. So archive it all, so you can still search it like you normally do, and start like how you want with an empty inbox. You will thank yourself later.

Look carefully at this snippet of code:

switch(mode) {     case Mode.ELITEmode:         if (someCondition)             return false;     case Mode.NORMALmode:         break;     default:         throw new ArgumentOutOfRangeException(); } 

Do you see anything odd? This is not valid C# code sadly, here is the version that is valid:

switch(mode) {     case Mode.ELITEmode:         if (someCondition)             return false;         goto normal;     case Mode.NORMALmode: normal:         break;     default:         throw new ArgumentOutOfRangeException(); } 

Eew goto-statement!

switch(mode) {     case Mode.NORMIEmode:     case Mode.ELITEmode:         if (someCondition)             return false;     case Mode.NORMALmode:         break;     case Mode.NORMALmode:         break;     default:         throw new ArgumentOutOfRangeException(); } 

switch(mode) {     case Mode.NORMIEmode: UNIQUE_CASE_1:         // Note that empty body case already has this fall-through         // Just not executed code in-between         goto UNIQUE_CASE_2;     case Mode.ELITEmode: UNIQUE_CASE_2:         if (someCondition)             return false;         goto UNIQUE_CASE_3;     case Mode.NORMALmode: UNIQUE_CASE_3:         break; // or continue; or return;         // Still generate, not called anyway         // Look into optimizing later ;D         goto UNIQUE_CASE_4;     case Mode.IMPOSSIBLEmode: UNIQUE_CASE_4:         break;     default:         throw new ArgumentOutOfRangeException(); } 

switch(mode) {     case Mode.NORMIEmode:         // Note that empty body case already has this fall-through         // Just not executed code in-between         goto case Mode.ELITEmode;     case Mode.ELITEmode:         if (someCondition)             return false;         goto case Mode.NORMALmode;     case Mode.NORMALmode:         break; // or continue; or return;         // Still generate, not called anyway         // Look into optimizing later ;D         goto case Mode.IMPOSSIBLEmode;     case Mode.IMPOSSIBLEmode:         break;     default:         throw new ArgumentOutOfRangeException(); } 

I want to zoom in on the result of that phase, what does the adoption of your software mean to the outside world? If people start to use your software and improve the data it is using, is that it or does that improvement translate elsewhere? This is where open datasets come in. Once you dive into them you cannot go without them anymore.

Take an example like OpenStreetMap, and why projects like VeggieKarte use its data. This dataset provide a good starting point for that application, as it can query the supported food preference if it has been entered. When people improve the data inside of OpenStreetMap, your application benefits. And when your users improve the data and update further outdated information like opening hours and contact details, everyone else also benefits. Or when someones new favorite veggie restaurant opened, and it has not been registered yet, they register it for everyone to see on the map.

That is the natural strength of using open datasets, that all applications now using the dataset are improved. Once this ball is rolling, the collaborative power is immense. So take a good look at the software you use, and if they allow open contributions to the data they use. If you are out of luck, there is always Wikipedia that can use more edits.

The main usecase is to update existing values or to set a next value. That is the limit, skipping more indices does throw an IndexOutOfBounds exception. As soon as you do that though, a map/dictionary/associative array makes more sense anyway. But we can still mess around with this assoc on vectors, and implement some other primitives.

The first thing we can implement is the conj function. It is an assoc with the count of the current vector, they have the same effect.

(conj [1 2] 3) ;; => [1 2 3] (assoc [1 2] (count [1 2]) 3) ;; => [1 2 3] 

And as soon as you implement conj for a single element, you can also implement it for multiple elements. Just doing it right after each other works, a reduce with the indices grows the vector one element at a time. Each of the elements will have the intented index along with it, as the assoc requires an index.

(->> [[0 10] [1 20] [2 30] [3 40] [4 50]]      (reduce (fn [xs [i v]] (assoc xs i v)) [])) ;; => [10 20 30 40 50] 

From here it is a small step to implement concat. Instead of the empty vector to start the reduce, use the first list and iterate over the second list to be concatenated. All of the indices used to assoc need to be incremented, as the elements will be placed after the first list. A small detail is that it returns a vector, as at every point it remains a vector.

(concat [10 20 30] [40 50 60]) ;; => (10 20 30 40 50 60)  (->> [40 50 60]      (map vector (map #(+ % (count [10 20 30])) [0 1 2]))      (reduce (fn [xs [i v]] (assoc xs i v)) [10 20 30])) ;; => [10 20 30 40 50 60] 

Or should I say WikiData, as that is what this is about. It is one of the many projects that start with Wiki- in the name, and it is the knowledge backbone for the structured data. So what is structured data, not those pesky XML documents right? There is a whole area of internet technologies that I was not aware of called Semantic Web Technologies. And it is possible to serialize them to XML, as OWL/XML or RDF/XML. This is not going to be a full explanation of what it all means, as it is much more fun to go through this learning process yourself if you never heard about it.

To me it meant learning about all kinds of technologies that power projects that do stuff that you would not believe a computer could reliably do. Like if someone would tell you, you would think it would be some specific software, but as it turns out it has been generalized and standardized to a high level; W3C high. Make your own little ontology and connect it to the rest of the internet and by logic make it behave like a magic answering machine, all fully transparent and extendable. Stretching the line of extendability to the point you ask what you have been doing wrong with data projects in the past. So much handrolling of this parsing and interpreting of data, when you could have used the shiny ontology and improve someone elses dataset instead. Because your data probably sucks, and the code that you operate it with even more so.

After a few years of tinkering, the paranoia of single point of failure asked for a solution. That solutions being mirroring to other git-servers; GitLab and a self-hosted git-server.

The self-hosted one required no extra installs, as it was git clone –bare till the end of repo’s was there. So it didn’t have one of those fancy front-end dashboards, issue-trackers and the rest of the jazz which makes it seem like a proper project to outsiders. So, announcing it here, it is now available for you to see as git-tea.