Professional software engineer, musician, gamer, stoic, democratic socialist

  • 1 Post
  • 95 Comments
Joined 2 years ago
cake
Cake day: July 2nd, 2023

help-circle


  • Organizationally, you don’t want your API handler to care about implementation details like database queries. All DB interaction should be abstracted into a separate layer.

    Generally API handlers only care about injecting any “global” dependencies (like a database object), extracting the request payload, and dispatching into some lower-level method.

    None of this requires generic code. It’s just about having a clear separation of concerns, and this can lead to more reusable and testable code.




    • Has a simple backup and migration workflow. I recently had to backup and migrate a MediaWiki database. It was pretty smooth but not as simple as it could be. If your data model is spread across RDBMS and file, you need to provide a CLI tool that does the export/import.

    • Easy to run as a systemd service. This is the main criteria for whether it will be easy to create a NixOS module.

    • Has health endpoints for monitoring.

    • Has an admin web UI that surfaces important configuration info.

    • If there are external service dependencies like postgres or redis, then there needs to be a wealth of documentation on how those integrations work. Provide infrastructure as code examples! IME systemd and NixOS modules are very capable of deploying these kinds of distributed systems.








  • Agreed.

    And sometimes code is not the right medium for communicating domain knowledge. For example, if you are writing code the does some geometric calculations, with lot of trigonometry, etc. Even with clear variable names, it can be hard to decipher without a generous comment or splitting it up into functions with verbose names. Sometimes you really just want a picture of what’s happening, in SVG format, embedded into the function documentation HTML.


  • There are plenty of good resources online. Here are some topics you probably wouldn’t see in an intro algos course (which I’ve actually used in my career). And I highly recommend finding the motivation for each of these in application rather than just learning them abstractly.

    • bloom filter
    • btree
    • b+ tree
    • consensus algos (PAXOS, RAFT, VSR, etc)
    • error correction codes (Hamming, Reed Solomon, etc)
    • garbage collection (mark+sweep, generational, etc)
    • generational arena allocator
    • lease (i.e. distributed lock)
    • log-structured merge trees
    • min-cost + max-flow
    • request caching and coalescing
    • reservoir sampling
    • spatial partition (BVH, kd-tree, etc)
    • trie
    • write-ahead log


  • I’m not in the market, but I’ve actually had similar thoughts of building a project on top of NixOS that’s focused on self-hosting for homes and small businesses. I recently deployed my own router/server on a BeeLink mini PC and instead of using something like OpenWRT, I used NixOS, systemd-networkd, nftables, etc.

    DM me if you want to discuss more. I think the idea has potential and I might be interested in helping if you can get the business model right (even if it just ends up being some FOSS thing).