https://zserge.com - little toy projects and stories on various software topics with minimalist aftertaste, not to be ever used in production or taken seriously
A little computer vision library for embedded systems, by magnitudes smaller than OpenCV, but still practical enough to do feature tracking or cascade detections. Works well on ESP32 and cheap ARMs with low-resolution grayscale cameras.
You might be right, but the only place where regexps are applied in code is for validating resource text fields (which is optional). Those regexps are defined in read-only schemas by the developer (if needed). Schemas are immutable. There seems to be absolutely no connection between the data transmitted over the API (i.e. what user can inject) and regexps. I'm not dismissing the idea that there might be plenty of other possible vulnerabilities in other areas of this toy project.
In hindsight, JSONL would have been much easier to deal with as a developer.
But I still don't regret picking CSV -- DB interface is pluggable (so one can use JSONL if needed), and I deliberately wanted to have different formats for data storage (models) and data transfer objects (DTOs) in the API layer, just like with real databases.
I agree, CSV is very limited and fragile, but it made data conversion/validation part more explicit.
Like others have guessed, I limited myself to what Go stdlib offers. Since it's a personal/educational project -- I only wanted to play around with this sort of architecture (similar to k8s apiserver and various popular BaaSes). It was never meant to run outside of my localhost, so password security or choice of the database was never a concern -- whatever is in stdlib and is "good enough" would work.
I also tried to make it a bit more flexible: to use `bcrypt` one can provide their own `pennybase.HashPasswd` function. To use SQLite one can implement five methods of `pennybase.DB` interface. It's not perfect, but at the code size of 700 lines it should be possible to customise any part of it without much cognitive difficulties.
To be fair, the project is linked to the blog post I recently wrote, so it's merely a tiny personal/educational project.
I tried to experiment with an API similar to what k8s api server offers: dynamic schemas for custom resources, generated uniform REST API with well-defined RBAC rules, watch/real-time notifications, customisation of business logic with admission hooks etc.
I also attempted to make it as small as possible. So yeah, I don't try to compete with Pocketbase and others, just trying to see what it takes to build a minimally viable backend with a similar architecture.
The choice of the "database" is dictated by the very same goals. I deliberately made it an interface, better databases exist and can be plugged in with little code changes. But for starters I went with what Go stdlib offers, and CSV is easy enough to debug.
The 2x3 case is very interesting though, because it's the basic size of a Braille cell. (2x4 Braille also exists, but it does not help readability all that much here.) So you could read this font on a Braille device without knowing the actual Braille script.
Louis Braille actually invented his own 10px bitmap font for mixed visual-tactile use: https://en.wikipedia.org/wiki/Decapoint It fell out of use after typewriters were introduced.
