Ops matthewtejo.substack.com

Why Twitter didn’t go down (from a real Twitter SRE)

Matthew Tejo:

Twitter supposedly lost around 80% of its work force. What ever the real number is, there are whole teams with out engineers on it now. Yet, the website goes on and the tweets keep coming. This left a lot wondering what exactly was going on with all those engineers and made it seem like it was all just bloat. I’d like to explain my little corner of Twitter (though it wasn’t so little) and some of the work that went on that kept this thing running.

This is a detailed post about Twitter’s caching system that Matthew and others built while working there, and it’s brilliantly summed up by commenter Johnny Manu40:

When everything works fine, they wonder why they hired you. When everything stops working, they wonder why they hired you. I.T. in a nutshell.

Sourcegraph Icon Sourcegraph – Sponsored

Sourcegraph Cloud trial

logged by @logbot permalink

Sourcegraph helps devs find, understand, and fix all their code across multiple code hosts in a single place.

With Sourcegraph Cloud, you can experience the power of Sourcegraph’s code intelligence platform used at 4 out of 5 FAANG companies and search your codebase with a secure, scalable, dedicated Sourcegraph instance on the cloud.

Sourcegraph Cloud is the fastest way to start using Sourcegraph on your organization’s code - and it’s SOC 2 compliant. Get your free, fully-featured Sourcegraph Cloud trial now, no credit card required.

Terminal github.com

`hishtory` is a better shell history

It stores your shell history in context (what directory you ran the command in, whether it succeeded or failed, how long it took, etc). This is all stored locally and end-to-end encrypted for syncing to to all your other computers. All of this is easily queryable via the hishtory CLI. This means from your laptop, you can easily find that complex bash pipeline you wrote on your server, and see the context in which you ran it.

Max Howell github.com

tea is not a package manager. tea is unified packaging infrastructure

Homebrew creator Max Howell is back with a brand new invention:

tea is a standalone, binary download for all platforms that puts the entire open source ecosystem at your fingertips. Casually and effortlessly use the latest and greatest or the oldest and most mature from any layer of any stack. Break down the silos between programming communities, throw together scripts that use entirely separate tools and languages and share them with the world with a simple one-liner.

All you need is tea.

Bold! I love how many interesting ideas are packed in to this project: pipelines, universal virtual-env, executable markdown… the list goes on. Check out the README for all the deets. My big question is: might Max and the team be thinking too big this time around?

Rust blessed.rs

An unofficial guide to the Rust ecosystem

Compared to other programming languages such as Python and Go, Rust’s standard library is very small, including only core data structures in the standard library with all other functionality farmed out to 3rd party ecosystem crates, and a common complaint from new Rust developers is that they don’t know where to start: which crates they ought to use and which crates they ought to trust. This list attempts to answer those questions.

Open Source github.com

Openblocks is an open source alternative to Retool

As the old saying goes, imitation is the sincerest form of flattery. In the software world, an open source alternative is the sincerest form of imitation. Well, Retool (a Changelog sponsor) can consider themselves flattered, because Openblocks sets out to do openly what they’ve been doing proprietarily. Here’s why:

It’s cumbersome to create a single app. You had to design user interfaces, write code in multiple languages and frameworks, and understand how all of that code works together.

Low-code/No-code platforms are fast to get started with but quickly become unmaintainable and inflexible. This creates more problems than it solves.

Retool-like solutions are great for their simplicity and flexibility, but they can also be limited in different ways compared to frameworks like React/Vue.

Openblocks wants to take a step forward. More specifically, Openblocks is

  • An all-in-one IDE to create internal or customer-facing apps.
  • A place to create, build and share building blocks of web applications.
  • A domain-specific language that UI-configurable block is the first-class citizen.

Rust Medium (via Scribe)

Using Rust at a startup: a cautionary tale

Matt Welsh:

I hesitated writing this post, because I don’t want to start, or get into, a holy war over programming languages. (Just to get the flame bait out of the way, Visual Basic is the best language ever!) But I’ve had a number of people ask me about my experience with Rust and whether they should pick up Rust for their projects. So, I’d like to share some of the pros and cons that I see of using Rust in a startup setting, where moving fast and scaling teams is really important.

The learning curve and hiring difficulties seem to be the major culprits, in Matt’s experience.

Markdown russellbeattie.com

Why is Markdown popular?

If you loathe Markdown, read this. If you love Markdown, read this.

I truly loathe Markdown. Truly. But given the widespread use of Markdown, it might seem strange that I have such aversion to it. If you somehow really like it, or are so used to it by now, you might be tempted to think I’m the oddball. But I’m definitely not alone in my dislike of the format…

It’s popular and got a lot wrong, but also a lot right. 🤔

Kafka ololabs.github.io

How we migrated our webhook service to Kafka

Olo provides online ordering & delivery services to restaurants, a big part of which is notifying their customers when important events take place in their ordering platform. For this need, they built a webhook service, which was working great… until it wasn’t.

In this article, they share how they evaluated, chose, and eventually migrated to Apache Kafka for this service. It looks like a lot of work that paid off in the end, woo hoo!

Kubernetes github.com

A graphical tool for developing on containers and Kubernetes

Podman Desktop installs, configures and keeps Podman up to date on your local environment. It provides a system tray, to check status and interact with your container engine without losing focus from other tasks. The desktop application provides a dashboard to interact with containers, images, pods and volumes but also configures your environment with your OCI registries and network settings. Podman Desktop also provides capabilities to connect and deploy pods to Kubernetes environments.

A graphical tool for developing on containers and Kubernetes

GitHub kolide.com

GitHub Copilot isn't worth the risk

Elaine Atwell says all CTOs urgently need to answer the question: should I allow Copilot at my company?

If you haven’t already figured it out from the title, Elaine’s answer to that question is No. But that might not be the right answer for everyone. In this article, she goes over the case for and against Copilot, and how you can detect whether it’s already in use at your organization.

Chris Klug fearofoblivion.com

Build the modular monolith first

Might a “modular monolith” be the happy middle ground in the endless monolith or microservices decision? You may have to answer that question for yourself, but this post shares some good thoughts around designing a modular monolith:

When designing a modular monolith, it is all about breaking up the system into modules, and then combining those modules into a monolith for deployment.

It might be worth noting that finding what modules you will need, might not be as easy as you would think. They have to be as independent as possible. High-cohesion and low coupling is very important here, as all communication between the modules might end up being a cross network call, if you decide to break it into services in the future.

This means that all communication between modules need to well abstracted, and be either asynchronous, so that they can handle the call going across the network in the future, or use some form of messaging.

Testing new.pythonforengineers.com

Web automation: don't use Selenium, use Playwright

For web automation/testing, Selenium has been the de facto “standard” since forever. It’s simple to get started with and supports almost every programming language.
My problem with it has been: It’s good enough, but nothing more. It doesn’t work that well with modern, Javascript framework heavy sites (Angular, React etc). I’m not saying it doesn’t work– just not too well.

I know a lot of people who use Selenium, but I don’t know a lot of people who enjoy using Selenium. (That’s no knock on the Selenium team. They solved a hard problem for lots of devs over the course of many years. Huge impact!) Playwright on the other hand…

Russ Cox go.dev

Thirteen years of Go

Russ Cox, for the Go team:

Today we celebrate the thirteenth birthday of the Go open source release. The Gopher is a teenager!

It’s been an eventful year for Go. The most significant event was the release of Go 1.18 in March, which brought many improvements but most notably Go workspaces, fuzzing, and generics.

He goes on to describe many of the other notable features and events of the past year and closes with a glance into Go’s future:

In Go’s 14th year, we’ll keep working to make Go the best environment for software engineering at scale. We plan to focus particularly on supply chain security, improved compatibility, and structured logging, all of which have been linked already in this post. And there will be plenty of other improvements as well, including profile-guided optimization.

  0:00 / 0:00