incfly

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
  namespace: default
spec:
  {}

Widdershin

In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.

After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.

But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.

And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?

In dark rooms, in hushed tones, we speak of colours.

huytd

How to use:

./wordle.sh

Or try the unlimit mode:

graninas

At the beginning of 2030, I found this essay in my archives. From what I know today, I think it was very insightful at the moment of writing. And I feel it should be published because it can teach us, Rust developers, how to prevent that sad story from happening again.

---

What killed Haskell, could kill Rust, too

What killed Haskell, could kill Rust, too. Why would I even mention Haskell in this context? Well, Haskell and Rust are deeply related. Not because Rust is Haskell without HKTs. (Some of you know what that means, and the rest of you will wonder for a very long time). Much of the style of Rust is similar in many ways to the style of Haskell. In some sense Rust is a reincarnation of Haskell, with a little bit of C-ish like syntax, a very small amount.

Is Haskell dead?

katef

#!/usr/bin/awk -f

# This program is a copy of guff, a plot device. https://github.com/silentbicycle/guff
# My copy here is written in awk instead of C, has no compelling benefit.
# Public domain. @thingskatedid

# Run as awk -v x=xyz ... or env variables for stuff?
# Assumptions: the data is evenly spaced along the x-axis

# TODO: moving average

Horusiath

module Program =
        
    type InMemoryDb(replica: ReplicaId) =
        let snapshot = ref null
        let mutable events : Map<uint64,obj> = Map.empty
        interface Db with
            member _.SaveSnapshot state = async { snapshot := (box state) } 
            member _.LoadSnapshot<'s>() = async {
                match !snapshot with

sleepyfox

'Users hate change'

This week NN Group released a video by Jakob Nielsen in which he attempts to help designers deal with the problem of customers being resistant to their new site/product redesign. The argument goes thusly:

1. Humans naturally resist change
2. Your change is for the better
3. Customers should just get used to it and stop complaining

There's slightly more to it than that, he caveats his argument with requiring you to have of course followed their best practices on product design, and allows for a period of customers being able to elect to continue to use the old site, although he says this is obviously only a temporary solution as you don't want to support both.

kenziebottoms

Branches

I want all the branches at my disposal

git fetch

Change branches.

ckelner

Understanding Kubernetes in 10 minutes

Original document can be found here; written by Mike Schuette.

This document provides a rapid-fire overview of Kubernetes concepts, vocabulary, and operations. The target audience is anyone who runs applications in a cloud environment today, and who wants to understand the basic mechanics of a Kubernetes cluster. The goal is that within 10 minutes, managers who read this should be able to listen in on a Kubernetes conversation and follow along at a high level, and engineers should be ready to deploy a sample app to a toy cluster of their own.

This orientation doc was written because the official Kubernetes docs are a great reference, but they present a small cliff to climb for newcomers.

If you want to understand why you should consider running Kubernetes, see the official Kubernetes conceptual overview document. This doc

joshbuchea

Semantic Commit Messages

See how a minor change to your commit message style can make you a better programmer.

Format: <type>(<scope>): <subject>

<scope> is optional

Example