Code Void blog,
programming and ramblings
by Rendijs Smukulis

I've been using git for over a decade now, but never really dug into the internals of how it actually works. This week I stumbled upon some youtube videos that do a great job of lifting the veil and uncovering the internals. Turns out, the way git represents the commits and dilesystem snapshots is a very elegant, simple approach which can be grokked in 20 minutes...

So the blog has been dead for a while, but I'm still among the living.

For years I've been taking a lot of notes of whatever fun side-project I discover, and keeping them private, in OneNote. I figure some of the things I find interesting to dig into might be interesting for others as well, so I might as well start sharing them. So the plan is to start publishing "living documents" of whatever I find interesting at the time - more of a braindump than edited articles. On top of that, I intend to update them whenever I dig deeper into any topic.

Recently, I've had to implement a secure storage service in a .NET5 C# application, and ended up selecting SQLCipher as the encrypted store for the data.

During the work, I found a lot of misleading advice online which boils down to "SQLCipher with Entity Framework is too slow to be useable", so this blog post is here to alleviate these claims. This blog post will be a high-level walk-through on how I tuned its performance under Entity Framework Core from "unuseable" to "this will work well for us".

Hu:toma recently launched their open beta, and since I've had a bit of fun playing around with it, I think it deserves a quick post. So what is Hu:toma? It's a platform for developing, publishing and selling conversational bots. It enables developing and training bots that your users can have a free-text conversation, while integrating with your APIs. For example:

So you've written an aiohttp (or Flask, or Tornado..) app in Python, and want to run it as a production service. The easiest approach would be to simply run it in production the same way you do while developing, simply by calling python server.py. While this is a simple approach, and works well while developing, aiohttp is not actually a webserver - it's a framework that is intended to be hosted in a production-ready webserver. One such webserver is Gunicorn, used to host Python-based web services. The main argument for using Gunicorn is raw performance: Gunicorn will run enough aiohttp processes to use all available CPU cores, while aiohttp's development webserver would only run it in a single process. Other benefits of using Gunicorn are improved security and its configurability. There is a good post on this topic found on serverfault by the Gunicorn's developer.

This walkthrough will start off with the code from the simple aiohttp project built in the previous post. You can clone it from github or modify the code samples to match your own project.

Note: this walkthrough assumes you have Python 3 and docker installed on your machine.

Python 3.4 added support for asynchronous I/O code, known as asyncio. Asyncio allows writing performant code that would have previously been bottlenecked by IO performance, and has spawned a number of great libraries based on it. One of these libraries is aiohttp, an asynchronous HTTP client/server which can support much larger number of parallel requests when compared to other client-side libraries (e.g. urllib or requests), or server-side libraries (e.g. flask).

After a cursory search, I could not find a Docker image with a basic 'hello world' implementation of an aiohttp server, so decided to build one, and document the process.