Goes into the (dearth) of applications as well as how it works.

Reminds me of The Newtonian Casino.

An app to help you use less apps.

Kevin Rutherford:

What follows is my personal, opinionated, idiosyncratic approach to React/Redux development, forged in half a dozen attempts to pursue test-driven development at a good pace.

Some interesting approaches in here. I like the use of more classic terms for some of the Redux concepts. Commands instead of Action Creators. Events instead of actions. Read models instead of reducers or selectors.

A podcast about Watergate.

Tips to visualise and limit context switching.

A useful service for improving the security of your users’ accounts.

A useful overview.

From a couple years ago. The section dispelling dogma that’s arisen around the approach was particularly interesting (from 22:40).

Camille Fournier:

If you are (or were) a highly opinionated engineer, practicing making space for information rather than quickly jumping in and sharing your conclusions is a must for leadership growth.

Joel Spolsky:

I don’t know what the original idea of Twitter was, but it succeeded because of natural selection. In a world where the tech industry was cranking out millions of dumb little social applications, this one happens to limit messages to 140 characters and that happens to create, unintentionally, a subtlety-free indignation machine, which is addictive as heck, so this is the one that survives and thrives and becomes a huge new engine of polarization and anger.

DHH:

Creativity, progress, and impact does not yield easily or commonly to brute force.

The Case for Learned Index Structures:

Indexes are models: a B-Tree-Index can be seen as a model to map a key to the position of a record within a sorted array, a Hash-Index as a model to map a key to a position of a record within an unsorted array, and a BitMap-Index as a model to indicate if a data record exists or not. In this exploratory research paper, we start from this premise and posit that all existing index structures can be replaced with other types of models, including deep-learning models, which we term learned indexes.

…

Our initial results show, that by using neural nets we are able to outperform cache-optimized B-Trees by up to 70% in speed while saving an order-of-magnitude in memory over several real-world data sets.

Not the weather, but the climate.

He didn’t know whether to fix it or sell tickets.

A deep dive into the feature progression of Google Maps and how far ahead of the pack they are.

I used to find it odd that these hypothetical AIs were supposed to be smart enough to solve problems that no human could, yet they were incapable of doing something most every adult has done: taking a step back and asking whether their current course of action is really a good idea. Then I realized that we are already surrounded by machines that demonstrate a complete lack of insight, we just call them corporations.

Feel the pain.

Ryan Kazanciyan:

I’ve been waiting eagerly for this episode to air — it’s my favorite of the season. As I looked through my notes, I was surprised to find that Kor and I first started working on scenes for “eps3.4_runtime-err0r.r00” as far back as January. The attacks against E Corp’s Hardware Security Modules (HSMs) are among the most complex hacks we’ve depicted on the show 

Eric Normand:

Rich Hickey explained the design choices behind Clojure and made many statements about static typing along the way. I share an interesting perspective and some stories from my time as a Haskell programmer. I conclude with a design challenge for the statically typed world.

…

People often talk about a Person class representing a person. But it doesn’t. It represents information about a person. A Person type, with certain fields of given types, is a concrete choice about what information you want to keep out of all of the possible choices of what information to track about a person. An abstraction would ignore the particulars and let you store any information about a person. And while you’re at it, it might as well let you store information about anything. There’s something deeper there, which is about having a higher-order notion of data.

It was emotional.

Jamie Talbot:

Having a formal system means we can better support the growth of our engineers. We’re able to have more honest, open conversations about progress, promotions, and opportunity. While the framework is still relatively new, it is showing early promise at incentivising the kinds of behaviours we want to see in the team, and recognising the different kinds of value that people add.

We already have ideas on how to improve the framework further, and plan to continue iterating on it over time. We are releasing it publicly now, in the hope that it can help other companies that are thinking about how to grow and support their employees.

Medium’s growth framework looks well thought out and nicely structured.

A series of posts on options for creating a unified UI over disparate services.

The L16 replaces one big lens with 16 small ones and combines the images via software.

The old clustering of commodity hardware with software approach keeps on popping up in different contexts.

Some handy tips in here.

Maciej Ceglowski:

The real story in this mess is not the threat that algorithms pose to Amazon shoppers, but the threat that algorithms pose to journalism. By forcing reporters to optimize every story for clicks, not giving them time to check or contextualize their reporting, and requiring them to race to publish follow-on articles on every topic, the clickbait economics of online media encourage carelessness and drama. This is particularly true for technical topics outside the reporter’s area of expertise.

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.

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?”

They kill me.

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.

Everything’s a fold.

Shows a distinct lack of crocodiles.

A map of pain.

Off the hook.

Ripper.

CellF is a neural synthesiser. Its “brain” is made of biological neural networks that grow in a Petri dish and controls in real time it’s “body” that is made of an array of analogue modular synthesizers that work in synergy with it and play with human musicians.

Watch stone carver Anna Rubincam as she goes from measuring a live person to a clay model to a finished stone portrait in three weeks.

Seeya Chris 😢

Some nuggets of gold in this.

Rails to React.

Brandur Leach:

It’s not that new technology should never be introduced, but it should be done with rational defensiveness, and with a critical eye in how it’ll fit into an evolving (and hopefully ever-improving) architecture.

It suggests improving increasing productive output by continually improving the efficiency of a system even while keeping input the same. I project this onto technology to mean building a stack that scales to more users and more activity while the people and infrastructure supporting it stay fixed.

Programming calendar time is hard.

I always enjoy the behind the scenes stories of comedians.

A look into some of the inspiration and decisions in the design of Elixir.

Jujitsu and meditations on narrative and consciousness.

A visual demo.

Ben Smith:

Building applications following domain-driven design and using CQRS feels really natural with the Elixir – and Erlang – actor model. Aggregate roots fit well within Elixir processes, which are driven by immutable messages through their own message mailboxes, allowing them to run concurrently and in isolation.

I too think that Elixir is a good fit for CQRS/ES applications.

The post provides a thorough walkthrough that builds an event sourced/CQRS Elixir application using Phoenix, Commanded, and Eventstore. The Commanded and Eventstore libraries look to have implemented most of the features I’m looking for.

Some amazing work.

Greg Young:

We will talk about what seems to be the most complex areas of event sourcing for most developers especially those first getting into it. Versioning.

Remapping the event stream is an approach we’ve used. I like the idea of emitting stop and stopped events to the store to support zero downtime migrations while remapping the stream.

Killer drumming.

Eric Evans on avoiding the pursuit of perfection when using DDD.

Chris, Andy, and Greg 😍

Dan North:

Over the last year or two I have been exploring OKRs—Objectives and Key Results—with several organisations, from a few hundred people in size to a couple of thousand. Some are well over a year in, some are just starting out. There doesn’t seem to be much out there in terms of experience reports or hands-on advice so I have tried to capture the advice I wish I’d had when I started out.

A different future.

Formidable:

Clean and robust state management for React and React-like libs.

The library grew from the idea that state should be just as flexible as your React code; the state containers you build with freactal are just components, and you can compose them however you’d like. In this way, it attempts to address the often exponential relationship between application size and complexity in growing projects.

Like Flux and React in general, freactal builds on the principle of unidirectional flow of data. However, it does so in a way that feels idiomatic to ES2015+ and doesn’t get in your way.

The single state object, reducers, and selectors associated with Redux feels overwrought and often gets in the way. Freactal looks like an interesting alternative.