Rennie grew up in Kenya, Honduras, Somalia, and Oklahoma; his parents volunteered for the Peace Corps before working for the US Government overseas.
Audio tape drives are real! Check out this Retrocomputing question about how the Commodore 64 audio interface worked.
If you want to remember something better, a 2014 study says you should write it out by hand.
Rennie worked at Blackberry, and Ben remembered his colleagues at the Verge fondly hoping for their comeback. In fact, here's Ben hoping for their comeback!
Alex comes up with better ways to interact with technology and writes about it on his website.
Is there a link between playing music and writing code? A previous article of ours covered the merger of the two in the music programming language, Sonic PI.
If you're curious about the weird extremes of operating system development, check out TempleOS.
Cassidy and Alex both take copious notes through Obsidian. Alex has a plugin that may help you organize notes automatically.
The infrastructure that networked applications lives on is getting more and more complicated. There was a time when you could serve an application from a single machine on premises. But now, with cloud computing offering painless scaling to meet your demand, your infrastructure becomes abstracted and not really something you have contact with directly. Compound that problem with with architecture spread across dozens, even hundreds of microservices, replicated across multiple data centers in an ever changing cloud, and tracking down the source of system failures becomes something like a murder mystery. Who shot our uptime in the foot?
A good observability system helps with that. On this sponsored episode of the Stack Overflow Podcast, we talk with Greg Leffler of Splunk about the keys to instrumenting an observable system and how the OpenTelemetry standard makes observability easier, even if you aren’t using Splunk’s product.
Observability is really an outgrowth of traditional monitoring. You expect that some service or system could break, so you keep an eye on it. But observability applies that monitoring to an entire system and gives you the ability to answer the unexpected questions that come up. It uses three principal ways of viewing system data: logs, traces, and metrics.
Metrics are a number and a timestamp that tell you particular details. Traces follow a request through a system. And logs are the causes and effects recorded from a system in motion. Splunk wants to add a fourth one—events—that would track specific user events and browser failures.
Observing all that data first means you have to be able to track and extract that data by instrumenting your system to produce it. Greg and his colleagues at Splunk are huge fans of OpenTelemetry. It’s an open standard that can extract data for any observability platform. You instrument your application once and never have to worry about it again, even if you need to change your observability platform.
Why use an approach that makes it easy for a client to switch vendors? Leffler and Splunk argue that it’s not only better for customers, but for Splunk and the observability industry as a whole. If you’ve instrumented your system with a vendor locked solution, then you may not switch, you may just let your observability program fall by the wayside. That helps exactly no one.
As we’ve seen, people are moving to the cloud at an ever faster pace. That’s no surprise; it offers automatic scaling for arbitrary traffic volumes, high availability, and worry-free infrastructure failure recovery. But moving to the cloud can be expensive, and you have to do some work with your application to be able to see everything that’s going on inside it. Plenty of people just throw everything into the cloud and let the provider handle it, which is fine until they see the bill.
Observability based on an open standard makes it easier for everyone to build a more efficient and robust service in the cloud. Give the episode a listen and let us know what you think in the comments.
A simple metric for code quality code be how easy is it to delete any given piece of code.
There's no algorithmic way to judge quality code, but experienced engineers know it when they see it.
Jeff Atwood's Performance is a Feature blog post gets a lot of mileage with our writers. But code quality isn't on the same axis; it's not a feature you can prioritize. It's part of the development process.
