Git is a decentralized version control system, meaning that there is no one superior repository. Every single copy of a Git repository is just as complete as any other. Of course we can pick one particular repository and declare it to be the one source of truth, the “upstream” repository. Usually this upstream repository is then hosted on some server, and if we are interested in openness and collaboration this server is part of a larger web service, called a “forge”. Out of these forges GitHub is perhaps the most popular one. Unfortunately this means if we are interested in contributions we have to make the GitHub repo our upstream and use its web services and web UI for our workflow. At least that is the common wisdom, but it does not have to be that way.
A while ago I announced my new pet project HSSG, the hackable static site generator. The final step of generating a web site is writing the actual files to the file system of the operating system. So far this has been a messy affair where information about file paths had to be dragged through the entire chain from start to finish. This was ugly, hard to maintain and it muddied the layers of abstraction. In this post I will explain how I brought order to HSSG through a file system abstraction.
The term “user-friendly” gets thrown around often, but what does it even mean to be “user-friendly”? Clearly we can say that something is more user-friendly the fewer defects it has. But beyond that? Is a GUI application more user-friendly than a text-based application? Is a lower learning curve more user-friendly than a steep learning curve? Is a product which has many features built-in more user friendly than a barebones product or an extensible product?
I am glad to announce a new Neovim plugin: nvim-cmp-vlime (GitHub mirror). It is a completion source for nvim-cmp which uses the Vlime plugin to fetch completion candidates from a running Common Lisp process. Vlime is a plugin similar to Slime for Emacs, it lets the editor communicate with a running Lisp process so we can evaluate code at runtime, debug, inspect values, and of course get auto-completion. In fact, Vlime uses the same Backend, Swank, as Slime, so the results should be equally good.
In June of this year I introduced my Common Lisp library cl-cmark (GitHub mirror), which implements parsing [CommonMark] documents and manipulating the resulting document tree. I have been hammering out the last kinks over the past weeks and I am now ready to call it done. Before I officially put the 1.0 stamp on it though I would like if a few more people could take a look at the library and give it a try.
In January 2019 I switched the static site generator for this website from Pelican to a custom one written in GNU Guile. Most (or all?) static site generators out there have an opinion on what a website should be made of. You might have full control over the layout and content of individual pages, but not so much over how the web site itself is composed. Writing my own static site generator freed me from these constraints. Now if I want to have sub-sites and multiple blogs I can do so. However, the custom generator was suffering from the same problem: it had one specific web site composition in mind, it just happened that this time it fit my needs. That is why I have created HSSG: the Hackable Static Site Generator.
A few days ago I wanted to re-install Sid Meier's Civilization III on my machine and play it again. This blog post is a summary of the tricks I had to use to make it work it work well; I am writing it down for posterity, maybe someone else will find it useful. That someone might even be future me.
For the past few weeks I have been working on a little side project, a library of Common Lisp bindings to cmark, the CommonMark reference implementation: cl-cmark (GitHub mirror). CommonMark is a dialect of Markdown which aims to remove any ambiguity, clean up the language specification and provide a common dialect of Markdown for other projects to use. The cmark library is the reference implementation for parsing CommonMark. It is written in C, so creating bindings for other language is fairly simple.
A web application typically consists of three layers: the frontend, the backend, and some sort of database system for persistence. While developing the frontend we often need to send messages to the backend, receive some response and process that response. Faking backends in automated tests is a solved problem, but sometime we don't want to write tests, we want to wildly experiment with various inputs as we are trying out the frontend by hand. We want to intercept messages and look into what is being transmitted. In this post I will demonstrate a simple fake backend using the mitmproxy application.
I love Free (Libre) and Open Source Software (FLOSS); not only does the software respect your personal freedom, you can also contribute back to make it better. It becomes a communal cooperative effort. But just because you can contribute, that doesn't mean that you necessarily should.
Quicklisp is a popular systems manager for Common Lisp, it allows users to download, install, update and uninstall Common Lisp systems (what other language call packages, but that term already means something else in Common Lisp). However, Quicklisp has one glaring security issue: it downloads everything through HTTP. This means every time you use Quicklisp to download a system you open yourself up for a man-in-the-middle (MITM) attack. We can use a local proxy server to route all traffic to Quicklisp through HTTPS, and in this blog post I will illustrate how to achieve this using mitmproxy.
A lot of new Neovim plugins come with a
setupfunction which lets you specify the settings of the plugin. Users are expected to call that function with a table as arguments which contains the user's personal settings to override the defaults. This works, but Lua is all about tables, so let's look at an alternative.
Over the last couple of years I have been noticing two trends among internet videos, especially on YouTube: videos that could easily be three to four minutes long are stretched to over ten minutes in length, and thumbnails where people are making stupid faces. This comes from YouTube's recommendation algorithm favouring thumbnails with people's faces, and videos needing to be at least ten minutes long to be eligible for advertising revenue. At least those used to be the rules back then, they might have changed since, but the videos still follow the same pattern.