| This is a brief comment on this article on API design principles: | |
| https://gist.github.com/vurtun/192cac1f1818417d7b4067d60e4fe921 | |
| I've called that style of API a coroutine, iterator, state machine, push/pull or client/server API | |
| depending on what seems most appropriate for the context, but they are all variants of the same idea. | |
| It's particularly superior in many cases as an alternative to callback-based APIs, which are the more | |
| common way of providing this kind of fine-grained interleaving between library code and user code. | |
| Callbacks can still be superior in usability for context-free operations like memory allocation, |
I am currently dealing with a lot of libraries at work. Both third party as well as libraries written or being currently in process of being written by me. I absolutely love writing and working with libraries. Especially if they present or bring me to either a new or different approach to solve a problem. Or at least provide a different view.
Over time I noticed however that quite regulary we had to decide that we cannot use a third party library. Often it is the usual reason.
Some time has past (three years!) since I last wrote about API specifically about coroutines style APIs so I thought why not write another one about a different API type I encounter relatively often. The builder API.
Now first let me take a step back and put this into 20,000 feet view on where builder APIs are located in the grant scheme. In general everything in computing is separated into input, processing and finally output. In its most basic form I am currently typing on my keyboard. All pressed keys are processed from the OS up to the browser I am writing this in and finally rendered and displayed on the screen as output. Of course this example is very user centric
See how a minor change to your commit message style can make a difference.
Tip
Have a look at git-conventional-commits , a CLI util to ensure these conventions and generate verion and changelogs
| # Full NixOS configuration for a ZFS server with full disk encryption hosted on Hetzner. | |
| # See <https://mazzo.li/posts/hetzner-zfs.html> for more information. | |
| { config, pkgs, ... }: | |
| let | |
| # Deployment-specific parameters -- you need to fill these in where the ... are | |
| hostName = "..."; | |
| publicKey = "..."; | |
| # From `ls -lh /dev/disk/by-id` |
I wanted to write a module that generates multiple systemd services and timers to scrub some zfs pools at certain intervals. The default scrub config does not support individual scrub intervals for each pool.
I want the config to look like this:
{
services.zfs-auto-scrub = {
tank = "Sat *-*-* 00:00:00";