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

  • 3 Posts
  • 156 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