I started working on a web front-end project. It is a compiler for web components. The compiler reads single-file web components similar to the Vue.js ones, and emits vanilla JavaScript.
I found that it works well for a small library of reusable components, and I prefer the minimal design over something like Vue or React which might be overkill for most components.
I put the code, along with a few examples, at element-compiler-python.
The second project I worked on is a homemade Version Control System (VCS). While it doesn’t have too much fancy functionality, it has basic support for branches and commits.
The project is following the Unix philosophy of small, composable tools that each do one thing well. The internal repo format is just simple plain text files. My goal with the project is to make it easy to write code that operates on the repo. Ideally, someone will be able to replace a sub-command like log or shortlog relatively easily.
All the commits are stored in diff form starting from an empty repo. In order to publish projects developed using the VCS, I also created a sub-command that pushes the commits into a Git mirror. This makes it possible to collaborate and share the projects even before the VCS has a non-zero traction.
While a lot of it currently works, I am planning to do a few ergonomics-related fixes before releasing the tool. An old version, which will be replaced by the final one after the release, can be found at dum. Oh yeah, I called it dum, because it is a short word that has a similar meaning to Git.
I started getting more familiar with the Gemini protocol and document format. I had previously written about these in Gemini. My goal is to write my own client and server, as per Gemini tradition.
I wanted something slightly easier to complete before I made a full client, so I decided to make yet another Gemini-to-HTTP proxy and host it as a serverless script. It is not feature-complete yet, but it can render most simple pages.
Here are a few examples:
I wrote a small utility, called httptime, that can synchronize your system time based on the HTTP Date header. If you know about the header, you will know that it has a 1-second resolution. This is usually not sufficient for accurate timekeeping. The script makes multiple HEAD requests at strategic timestamps in order to synchronize itself with the server time and increase the timing accuracy.
I found that this approach can get you to between 0.001 to 0.004 seconds of accuracy, which is good enough for most use cases.
In most cases, you should just use NTP or SNTP. But if you don’t want to get an NTP daemon, or you want to use TLS or plain HTTP for some reason, this approach works well is very minimal. Most importantly, the code can be understood by mere mortals in a few minutes.
I played around with neural networks and text generation. Instead of going with something fancy and using an attention mechanism, I just fed the last N characters to the network to predict the next one. The results were as expected, the rough format of words and sentences look okay but it lacks the context that makes the fancier text generation models more comprehensible.
I also started to collect data using the Twitch.tv GraphQL endpoint about when certain channels are online or offline. I might do a project in the future where I try to predict the future schedule of channels based on past data using machine learning.
…
That’s all for this month, thanks for reading!