Noah Sussman:

However there are general five general areas of interest that are always worth examining because they reveal mistakes with such surprising regularity. Specifically it’s worthwhile to find out how any system handles inputs, math, text, time and system resources.

Plenty of good testing advice.

Henry Ward:

I have long felt there is a shadow org chart, much like a shadow economy, where employees trade ideas, give direction, offer help, and spread culture. This shadow org chart is built bottom up by employees and is very different from the top down hierarchical org chart set by me.

I wanted to map this shadow org chart and find employees who have disproportionate levels of influence relative to their hierarchical position. I also wanted to see the influence centers and decision makers, and the directional current between them and the rest of the company.

Some fascinating analysis and data visualisation of a graph of influence.

An algorithm for splitting and sharing secrets.

John Lanchester:

The researchers found quite simply that the more people use Facebook, the more unhappy they are.

His idea was that if the price is falling that means the market is working, and no questions of monopoly need be addressed. This philosophy still shapes regulatory attitudes in the US and it’s the reason Amazon, for instance, has been left alone by regulators despite the manifestly monopolistic position it holds in the world of online retail, books especially.

I’ve spent time thinking about Facebook, and the thing I keep coming back to is that its users don’t realise what it is the company does. What Facebook does is watch you, and then use what it knows about you and your behaviour to sell ads.

Facebook is in the surveillance business. Facebook, in fact, is the biggest surveillance-based enterprise in the history of mankind.

Sage.

A look at the internal data structure Emacs uses to represents buffers.

Management and leadership lessons.

They kill me.

David Copeland:

Our goal should be to reduce these issues—we’ll never be truly rid of them. The first step is self-awareness. Ask yourself:

• “Do I know what I’m doing?”
• “Do I have a plan?”
• “Is this the simplest thing I could do?” (note: Simple ain’t easy)
• “What is the problem I’m trying to solve?”

Brandur Leach:

Versioning is always a compromise between improving developer experience and the additional burden of maintaining old versions. We strive to achieve the former while minimizing the cost of the latter, and have implemented a versioning system to help us with it. Let’s take a quick look at how it works.

Explicitly modeling changes between versions via a DSL.

About PumpkinDB:

PumpkinDB is essentially a database programming environment, largely inspired by core ideas behind MUMPS. Instead of M, it has a Forth-inspired stack-based language, PumpkinScript. Instead of hierarchical keys, it has a flat key namespace and doesn’t allow overriding values once they are set.

The core ideas behind PumpkinDB stem from the so called lazy event sourcing approach which is based on storing and indexing events while delaying domain binding for as long as possible. That said, the intention of this database is to be a building block for different kinds of event sourcing systems, ranging from the classic one (using it as an event store) all the way to the lazy one (using indices) and anywhere in between.

John Allspaw:

In my experience, when an architecture review brings attention to a problem and proposed solutions from multiple perspectives, decisions become less controversial. When a decision appears to be obvious to a broad group (“Question: should we (or should we not) take backups of critical databases? Decision: Yes.”) how a decision gets made almost disappears.

Extending Haskell to support dependent types.

Beautiful things.

Putting the science into computer science.

Cogent and clear advice.

Lamar Odom’s story.

Max Kreminski:

Monads are a solution to a specific problem: the problem of repetitive code. If you write enough code in a functional programming language, you start to notice that you’re writing a lot of suspiciously similar code to solve a bunch of superficially different problems. Wouldn’t it be nice if you could just write this code once and then reuse it, instead of rewriting it slightly differently every time? I’m omitting a lot of detail here, but this is effectively what monads allow you to do.

🎸

I used this to get edeliver to apply migrations in an Elixir umbrella app.

Just use this to format any Javascript you write.

Dave Copeland:

When a dangerous or difficult-to-undo operation must be performed, but it cannot be made idempotent without more context, use an Idempotency Key.

Eric Normand:

But there’s a deeper problem. I actually think ten lines of code is too big for an abstraction (Metz agrees). Ten lines of code that happen to be repeated are so unlikely to have any interesting properties, including being bug-free, reusable, and composable, that you should be very skeptical of being able to factor the whole thing out as common.

However, don’t despair! You can more often than not find lots of one-, two-, or three-line bits of code that are 1.) easy to name and 2.) reusable. If you break enough of those out, you may start to see some underlying structure to those repeated ten lines as they become replaced by your new, small abstractions.

In graphs.

UpGuard has discovered an open database containing information on what appear to be approximately 198 million American voters left misconfigured by a GOP analytics firm.

ASCII art editor for macOS. Great for adding diagrams alongside code.

A slick set of React UI components.

Lessons for leakers and journalists.

Printers drawing secret fingerprints.