Categories
links

Links

  • Cloudflare firewall rules: Nice writeup about how Cloudflare evolved their firewall rules product. This is something we’re looking to put in place at work
Categories
links

Links

  • Marc Brooker talking about how multi-threaded programs can run more slowly than single threaded ones. (Certainly they often behave not the way we might think initially.) Some good usage of perf as well. So context switching and serializing task (synchronization?) access to a lock. Eliminating shared (global) state and the need for coordination is helpful when you’re parallelizing programs

Categories
links

Links

  • How big technology changes happen at slack: Explore, expand, migrate. They’ve chosen a practice that involves 3 distinct phases where anyone (or nearly anyone?) can advocate for a new technology, but they must convince their peers of its value and do that by getting other people in the org to use it.
    • Most experiments fail fast which is something they like. The ones that do achieve widespread adoption make it to the migration phase where the company actively roles it out across all things.
    • It sounds great, but my question would be how do you stop a proliferation of technologies from being put to use in different spots. The maintainability of a system in such a state seems monstrous. If you bake something new that no one else uses deeply into a service, you have to learn that new thing in order to properly support and enhance that service. Does every service have 1 or 3 things like this uniquely theirs at Slack? How does this shake out? How do experiments work?
    • There has to be some friction to get to phase 1. (Along with a bunch of communication across the immediate team) You always start with a real problem you need to solve. Can you find more than 1 of a few other people who are also concerned about your problem and talk through it with them?
Categories
links

Links

  • Batch operations in REST apis: Interesting. I have never considered the implications of trying to support batch operations using a RESTful style interface. When I use REST apis, I’m usually doing things one-at-a-time (make a new thing, delete this thing) and the urls I poke at to do this largely represent a single entity. Not so I guess when you’re thinking about batch operations. The other interesting side of this is how do you indicate response status. (200 if everything’s ok, but what about partial failure?) Now clients are probably going to have to parse the response body and try to figure out what happened …
Categories
links

Links

  • Cloudflare waf: The waf has been redesigned and rewritten from the ground up. A very capable piece of tech my workplace is currently evaluating for use with our software (among other Cf products :))
Categories
links

Links

  • Commits are snapshots not diffs: A good conceptual primer about what git is trying to do for you under the covers. The data model is actually quite simple, and elegant. This is a great narrative
Categories
links

Which shot should I get?

Categories
links

Links

  • Languishing: Something between depression and flourishing. A feeling of blah. Not a lack of energy, but more a lack of an inner need to move. The author suggests flow can be a powerful tool to help avoid this state of mind. (Becoming absorbed in the task of the moment. Losing track of time. A challenge that is surmountable but just hard enough.) A suggestion as a way to get there is to protect ones time
Categories
links

Links

Categories
links

Links

  • The majestic monolith: A post from DHH about monoliths and microservices that resonates with me quite a bit. Side effects of complexity in a system I’m thinking of now are failures, emergent behaviour, dev + operator cognitive load, trickier production support, … Many many applications don’t need the extra complexity now and never will
  • Humble objects: Making a class easier to test by factoring out smaller bits into easily tested ones. I’ve heard the term “sprouting” recently referring to the same concept