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
Categories
links

Links

  • AWS network load balancers @ Ably: Ably is a platform other developers can use to provide realtime push notifications at scale to their users. They have to handle lots of persistent connections, and a variable connection rate that can spike dramatically. Sounds like the NLB isn’t quite delivering the extreme levels of service it claims to be able to. Note: It’s an amazing box for the rest of us running applications without those constraints (Probably the vast majority of us?!)
  • Devops practice @ Algolia: Nice write up about what the team does and their process for getting things done. Work buckets: projects, operations, on call. Meetings: Once weekly Production Meetup discussing what happened last week in on-call + project statuses. Priorities: Answer customer questions, answer internal team questions, incident response, infra provisioning + management

Categories
links

Links

Categories
links

Links

  • Data engineering at Ada: Nice evolutionary story of a data usage anaylitics pipeline at Ada. Start with transaction dbs + adhoc queries, then introduce recurring jobs, then a more sophisticated scheduler, then the ability to ask questions in a more adhoc way (sql based interface to the data vs having to write a program), up to a frontend tool for visualizing queries
    • They specifically said they weren’t going to do real-time. I like this avoidance of extra complexity!
Categories
links

Links

  • Another great tracing post from Slack: This one is from before the last and describes internal project requirements, the problem they were trying to solve, and limitations of Zipkin and Jaeger. One key point was the tracing system should be useful for non-backend use cases

Categories
links

Links

  • Garbage collection in jdk16: ZGC enhancements reduces gc time. More efficient memory relocation on heap collections and heap root object set scanning is avoided entirely.
  • Name your thread pools: Being able to trace back to the origin of work in a system doesn’t happen on its own. You have to plan for it. So important.
  • Serverless app: Lenskart built a system with simple components that performs well given the current feature set at a reasonable cost

Categories
links

Links

  • Client tracing at slack: Talks about how slack is able to visualize what happens when a requests is sent from a client (browser, application) to the backend. Really neat. Mentions Honeycomb
  • Lightstep distributed tracing guide: High level guide speaks to tracing, sampling, when you need to be think about this stuff. Head-based sampling (ie. Decision made up front in a request that you’re going to start tracing – which can use a non-trivial amount of server resources – vs. tail-based where you’ve done the buffering and can decide to keep or throw away data based on testing whether there’s anything interesting contained there-in)