News and podcasts for developers

Today we’re joined by Jessica Lord, talking about the origins of Electron and her boomerang back to GitHub to lead GitHub Sponsors. We cover the early days of Electron before Electron was Electron, how she advocated to turn it into a product and make it a framework, how it’s used today, why she boomeranged back to GitHub to lead Sponsors, what’s next in funding open source creators, and we attempt to answer the question “what happens to open source once it’s funded?”

When I was in college my professor tried teaching us regular expressions: the theory, the algebra, all that. I left dumbfounded. When I hit the Real World I quickly ran into many practical use cases where a regular expression helped me solve a problem. That’s when I finally grokked them.

If you want to improve your understanding (and deployment of) regular expressions to solve problems, but don’t have a use case at the moment… here’s a whole bunch of them for you to practice on in the meantime.

This is our third Kaizen episode in which Adam, Jerod & Gerhard talk about GitOps the wrong way, ask questions with Honeycomb and realise that they must be holding the CDN wrong, and the effort that has been going into moving all changelog.com static files from regular volumes to an S3-like object store. If you like a good yak shake, listening to this one is a lot more fun than doing it.

Gerhard is most excited about the Ship It Christmas gifts that we have been preparing for you. While GitHub Codespaces is not going to be part of the upcoming Christmas special episode, today’s talk covers why investing in a Codespaces integration is worth it.
Changelog #459 and Backstage #20 are related to this topic.

The Evil Martians have been hard at work de-stressifying their Ruby on Rails deployments with a new tool: Kuby. In this post they share their journey getting there. It’s a lot. But in the end they seem happy with the results.

Kuby lowers the bar of adopting Kubernetes for Rails apps, leveraging the power of the convention-over-configuration principle. Just as Rails conquered the world with its “build a blog in 15 minutes” idea, so too could Kuby reign supreme in the context of deployment—”deploy Rails on Kubernetes in 15 minutes”.

If the datacenter is the computer, then the cloud is its operating system — so let’s start treating it like one and stop micro-managing thousands of individual ones.

Milosz Danczak shares a principle that was surely born from years of painful experiences:

When committing to a piece of software, favor those created by people who value backward compatibility.

But how can you tell if a piece of software is likely to remain stable? Milosz also provides some heuristics you can apply when evaluating a project.

This question could be dismissed by saying that Nix and Docker are different tools that solve different problems. One is a toolkit for building and deploying containers and the other is a package and configuration manager. However, these tools do have some overlap: they can both be used to create reproducible environments.

While both tools aim to solve this problem, they take different approaches.

A solid rundown of the different approaches these two tools take, and how you might think about picking which one to use. Maybe you can have the best of both worlds?

As mentioned on Backstage #20, I’m automating a few rsync commands using cron and Cronitor to backup my “Production” files to the Storinator AV15 on the local network.

It turns out that cron on macOS is frowned upon in favor of launchd, but information on how to use all the power of launchd is sparse to say the least. This resource is the best I’ve found in learning all the parts of launchd and how to use it.

Ask me anything in the comments, I’ll tell you everything I’ve learned.

Recently, GitHub released Copilot, which is an amazing AI pair programmer powered by OpenAI’s Codex model. In this episode, Natalie Pistunovich tells us all about Codex and helps us understand where it fits in our development workflow. We also discuss MLOps and how AI is influencing software engineering more generally.

Cate Huston with another great career-related post. Click through for explainers of each these 5 signs and a bonus 6th (meta) sign:

1. You’re not learning (and you want to be).
2. You’re learning coping mechanisms rather than skills.
3. You feel morally conflicted about hiring.
4. Your job is affecting your confidence.
5. Your job is affecting you physically.

Richard MacManus answers a couple of his own questions after the announcement of the newly formed PHP Foundation:

Why is PHP still such a critical part of the web, when other programming languages and frameworks are seemingly more suited to the modern web? Second, what are the motivations behind the companies that have formed this new foundation?

Did you know almost half of the top 10,000 websites on the internet use PHP?! That’s quite the footprint. I’m happy to hear PHP is still alive, kickin’, and continuing to evolve. The more tools we have to build awesome websites with, the better.

I’m still setting up my new rig and best-tools-for-markdown-based-workflows is on my mind. This one has a lot going for it: MIT licensed, theme-able, and feature-full.

What do you use to edit .md files these days? Anything good enough to pull you out of your code editor?

Bozhidar Batsov on the sad state of Chrome’s web rendering hegemony:

We’ve gotten to the point that Chrome-based browsers are so common that developers just stopped to bother supporting other browsers… Soon Google are going to be in complete control of web standards, unless something drastically changes. Do you want the future of browsing to lie solely in the hands of the biggest advertising business on Earth? I’m pretty sure that I don’t.

Liana Leahy tells Amal and KBall all about her journey from software engineer to product manager. Along the way we learn what a PM does, how to be great at it, how to know if it’s for you, why the role is in such demand these days, and much more. - It’s UNIX, I know this!

Sonic outperforms other Go implementations on all JSON sizes. Here are the results on a large dataset. 👇

Blueboat aims to be a developer-friendly, multi-tenant platform for serverless web applications. A monolithic approach is followed: we try to implement features of commonly used libraries (in the web application context) natively in Rust to replace native Node addons, improve performance and reduce duplicated code. Blueboat’s architecture ensures the security of the platform, prevents code duplication and keeps the overhead low.

Open Source and other source available projects have been a huge driver of progress in our industry, but building and maintaining an open source project is about a lot more than just writing the initial code and putting together a good README. On this episode of the maintenance mini-series, we’ll be discussing open source and the maintenance required to keep it going.

This week Adam is joined by Zac Smith, Co-Founder of Packet and now running Equinix Metal. They talk about the early days of the internet infrastructure space, the beginnings of Packet, the “why” of bare metal, transitioning Packet from startup to global company overnight when they were acquired by Equinix, and how all this for Zac is 20 years in the making.

We upgraded to the new MacBook Pro M1 Max and decided to share our first impressions of the new hardware, how we migrate data and settings from our old machines (or don’t), which apps were “instant installs” for each of us, which apps we’re trying to live without, and how we get our new machines set up for work and play. Nerd out with us!

Property-based tests give us more confidence in our code. They’re great at catching edge-cases we may not have thought of otherwise. But this confidence comes at a cost. Property tests take more effort to write. They force you to think hard about what the code is doing, and what its expected behaviour should be. It’s hard work. And on top of that, running 100+ tests is always going to take longer than running 3–5 example-based tests. This cost is real, and it raises the question:

How do we keep ourselves from over-specifying or writing unnecessary tests?

A fascinating look at the state of packaging apps for the Linux desktop:

The stability of the Linux desktop has dramatically improved in recent years. Core library developers are finally seeing the benefits of maintaining compatibility. Despite this, many developers are not interested in depending on a stable base of libraries for binary software. Instead, they have decided to ignore and override almost all libraries pre-installed on the user’s system.

And why the author thinks Flatpak (which some believe is the future) is not the way to go.

I am not a fan. I’m going to outline here some of the technical, security and usability problems with Flatpak and others. I’ll try to avoid addressing “fixable” problems (like theming) and instead focus on fundamental problems inherent in their design. I aim to convince you that these are not the future of desktop Linux apps.