The Changelog The Changelog #490  – Pinned

Schneier on security for tomorrow’s software

This week we’re talking with Bruce Schneier — cryptographer, computer security professional, privacy specialist, and writer (of many books). He calls himself a “public-interest technologist”, a term he coined himself, and works at the intersection of security, technology, and people.

Bruce has been writing about security issues on his blog since 2004, his monthly newsletter has been going since 1998, he’s a fellow and lecturer at Harvard’s Kennedy School, a board member of the EFF, and the Chief of Security Architecture at Inrupt. Long story short, Bruce has credentials to back up his opinions and on today’s show we dig into the state of cyber-security, security and privacy best practices, his thoughts on Bitcoin (and other crypto-currencies), Tim Berners-Lee’s Solid project, and of course we asked Bruce to share his advice for today’s developers building the software systems of tomorrow.

Marko Milojevic hindenbug.io

Two techniques for solving unreproducible (random) bugs

Unreproducible issues, although rare, are typical for each project, sooner or later. They can affect different system parts and make us many causes for investigating and fixing them.

In this article, I try to share some of the techniques I have used in such investigations, which gave me great help in such scenarios. I hope they are helpful to you (if you did not use them already). And, if you have techniques of your own, share them!

Startups kenkantzer.com

Learnings from 5 years of tech startup code audits

Ken Kantzer was part of ~20 code audits of companies that had just raised their A or B rounds of funding:

It was fascinating work – we dove deep on a great cross-section of stacks and architectures, across a wide variety of domains. We found all sorts of security issues, ranging from catastrophic to just plain interesting. And we also had a chance to chat with senior engineering leadership and CTOs more generally about the engineering and product challenges they were facing as they were just starting to scale.

In this post he shares some of the more surprising things he’s learned from the experience. There’s a lot to digest in this post, but I’ll highlight my favorite to whet your whistle:

Simple Outperformed Smart. As a self-admitted elitist, it pains me to say this, but it’s true: the startups we audited that are now doing the best usually had an almost brazenly ‘Keep It Simple’ approach to engineering. Cleverness for cleverness sake was abhorred. On the flip side, the companies where we were like ”woah, these folks are smart as hell” for the most part kind of faded.

Chronosphere Icon Chronosphere – Sponsored

Observability platform for scaling cloud-native

logged by @logbot permalink

Chronosphere is the observability platform for cloud-native teams operating at scale.

When it comes to observability, teams need a reliable, scalable, and efficient solution so they can know about issues well before their customers do.

Companies born in the cloud-native era often start with Prometheus for monitoring, which is obviously an amazing piece of software, but they quickly push it to its limits and often outgrow it. They run into issues with siloed data, missing long-term storage, and wasted engineering time firefighting the monitoring system vs delivering their application with confidence.

Learn more and get a demo at chronosphere.io.

Cloud github.com

Store files as YouTube videos == infinite disk space

YouTubeDrive is a Wolfram Language (aka Mathematica) package that encodes/decodes arbitrary data to/from simple RGB videos which are automatically uploaded to/downloaded from YouTube. Since YouTube imposes no limits on the total number or length of videos users can upload, this provides an effectively infinite but extremely slow form of file storage.

Filed under: ways-no-youtube-engineer-ever-imagined-people-would-use-their-software

Practices wilcosky.com

Smaller is better (the rise, fall, and rise of flat file software)

Billy Wilcosky:

Flat file web software is about having a set up which doesn’t use a “traditional” database. Instead it uses plain text files, other files, and/or maybe something like a json feed to store the data.

In this post, he explains why he thinks flat file web software is on the come up (again):

Flat file software can be powerful. Depending on what you need. And I think with the right developers and brain power behind the movement it can be more scalable and secure. The sky’s the limit. When I hear a developer saying, no, flat file isn’t good because… really all I’m hearing is they don’t want to change the way web software works. Because what I’ve found is most anything is possible.

Here’s a couple of flat file platforms which are incredible. One is a CMS/blog, the other a forum. Yes, a flat file forum.

A somewhat-related categorical question: Does SQLite count?

Google Icon Google

A text-to-image diffusion model with an unprecedented degree of photorealism

Google researchers are giving DALL-E a run for its money:

Our key discovery is that generic large language models (e.g. T5), pretrained on text-only corpora, are surprisingly effective at encoding text for image synthesis: increasing the size of the language model in Imagen boosts both sample fidelity and image-text alignment much more than increasing the size of the image diffusion model.

A text-to-image diffusion model with an unprecedented degree of photorealism

Patrick DeVivo github.com

A fluent GraphQL library for Go

This package wraps the graphql-go/graphql implementation to provide a “fluent” pattern for constructing GraphQL queries in Go. This can be valuable in situations where dynamic queries are desired: when the fields of a GraphQL query (or mutation) are not known until runtime. For most other use cases, plain query strings or a helper library such as this should be sufficient.

I wonder if this would change Mislav’s unpopular GraphQL/Go opinion

Chris Kiehl chriskiehl.com

The mindless tyranny of 'what if it changes?' as a software design principle

Chris Kiehl hits his hammer right on the head of this common sentiment in software circles:

Developers from certain languages [Java] have learned to wield this design principle with more power than many others. It’s how we end up with so much stuff in code bases that’s just… there. Existing. Superficially it appears unused, but silently and stoically, we know it protects us from the turbulent future change which lurks ever ahead.

The antithesis of one of my favorite design principles: YAGNI

Ship It! Ship It! #53

Securing K8s releases (KubeCon EU 2022)

Today we are at KubeCon CloudNativeCon EU 2022, talking to Adolfo García Veytia about securing Kubernetes releases. Adolfo is a Staff Software Engineer at Chainguard, and one of the technical leads for SIG release, meaning that he helps ship Kubernetes. You most likely know him as Puerco, and have seen first-hand his passion for securing software via SBOMs, cosign and SLSA. Puerco’s love for bikes and Chainguard are a great match 🚴‍♂️

JS Party JS Party #226

The third year of the third age of JS

In 2020, Shawn (swyx) Wang wrote:

Every 10 years there is a changing of the guard in JavaScript. I think we have just started a period of accelerated change that could in thge future be regarded as the Third Age of JavaScript.

We’re now in year three of this third age and Swyx joins us to look back at what he missed, look around at what’s happening today, and look forward at what might be coming next.

Podcasts from Changelog

Weekly shows about software development, developer culture, open source, building startups, artificial intelligence, brain science, and the people involved.

0:00 / 0:00