DEV Community

From "show me your code" to "show me your idea"

zxpmail — Thu, 10 Sep 2026 22:42:34 +0000

From "show me your code" to "show me your idea"

Or: the abdication is signed, and the court is empty

2026-07-13

Second in a six-part series on what building with AI agents did to one developer. This piece is where code loses authority — and the question becomes what can still pin "this is what I meant."

Last week someone turned a laptop toward me. A function on the screen, comments neat, tests green. He pointed at a line and said: this is what I meant.

I asked: is that what you meant, or what the model smoothed into place?

He froze. I froze. Three seconds opened in the air that neither of us would fill. In those three seconds I counted two thoughts. First: I shouldn't have asked. Second: who else is left to ask. Fingers on the trackpad edge — the heat was the machine's, not an idea's. Two people facing the same green, neither daring to hit Enter.

It wasn't supposed to be like this — I thought. There used to be a tyrant: compiler, tests, exit codes. Talk is cheap, show me the code. Pretty talk died where the run failed. Drop the brick; fakes rang. After the ask you could stand across an exit code — a piece of iron in the middle that would not lie.

The brick is still there. He pushed it over. The authority is gone. Running is no longer the same as "this is what you meant." The prettier the sample, the more the questioner looks like a nitpicker. And you still can't drop the question — drop it, and you pretend that running is the same as "this is what you meant."

So some people bring it back: show me your talk. More meetings, spell it out, align the narrative. Talk was always cheap. I always took it for empty speech — time burned, energy burned — which is why I would rather stake the final court on code. Code lost its authority. I do not want that road back.

So the ask shrinks to: show me your idea. Not inviting talk back in — wanting something that can still be pinned: a tradeoff, a fork, whose fault if wrong. Open your mouth, and it becomes talk again. Models say it too, often smoother. The waste I hated most came back in a different shirt. I am still beside him, trackpad heat still on my fingertip, not knowing whether to say "I believe you" or "prove it again." Both feel wrong. Swallow; throat goes dry.

Two days later I asked him again. Softer: not "did you mean this," but "why write it this way." He answered fast. Boundaries first, then retry on failure, then why not the other path. Clean. I almost convicted him again for being too smooth. When he finished, I changed the knife — not restatement, a fork: "If the retry budget is cut in half, what breaks first?" He stopped. Not the pause of swapping connectives. After the stop, he named something that had not appeared in the first speech — the order of cache invalidation. That inch was his. A model can answer a fork too, often more completely. I asked again: if we do it in the order you said, which step blows up first online — which sentence do you own? He pointed at the one he had just spoken. That point mattered more than answering completely. I had been measuring wrong: smooth is not evidence of guilt; standing behind the fork is.

I asked myself the same way. At night, facing a stretch I had just "written" — I had clicked Accept. The comment announced intent. I wiped the whole intent block, stared at the blank for a long time, then typed. What came out was almost as smooth as what I erased. Smooth enough to sicken me. Deleted again. Typed again. The third pass was still smooth. Finger on Save, I thought: if it writes smooth, does that mean it isn't mine. No. Reaching the same logic a second time can be called understanding. What I feared was not smooth — it was having no fork I could answer, while still using "I hesitated" to prove it was mine. I added a fork in my head, answered it poorly, and still pressed Save. The cursor moved on. I did not become more myself, or less.

Later I thought: asking can move a person and still fail to pin a lie, so nail. Nail every claim into something that runs and shows a side effect. One night I nailed eleven. The ninth went red. I fixed it, ran again, red to green. While fixing, my hand was hot — briefly, like heat on loan. When all eleven went green, the terminal lit in a row. I sat with that row and waited for "this is what I meant" to sound inside. It didn't.

That sit cleared the old books. An exit code only ever proved one thing: it runs. It never proved "this is what you meant." We treated those as the same passport and called the illusion rigor. The model did not remove the final court — it tore the illusion open. The green was steady. "This is what I meant" still did not sound. Nails can pin a lie. Nails cannot pin whose idea it was.

I did not close his laptop. I did not rewrite that comment for him. The cursor still blinks after "this is what I meant." I no longer expect it to testify for anyone. What I can require is only a sentence that can bite me later: which tradeoff I own, and if it is wrong, it is mine. That sentence can live in a PR, or only in the mouth. What matters is not a tidy format — it is whether a person will still stand behind a choice.

Those three seconds ended in stopping — stop asking green to prove both "it runs" and "this is what I meant."

Previous in this series: The Mirror Cannot Reflect Thought · To follow: Judging Fatigue — From Verifying AI to Verifying Myself · The Boundary of the Harness · A Reviewer Nailed Me in Six Places

J'ai procastiné Docker pendant un mois... Voici ce qui m'a débloquée

SIEWE SANTHE AUDREY CAMILA — Thu, 10 Sep 2026 22:29:14 +0000

Le 8 juillet, j'ai commencé un mentorat DevOps avec Endah. J'étais motivée, pleine de bonnes résolutions, prête à attaquer le Docker comme une pro.

Sauf qu'entre le 21 juillet et le 22 août, je n'ai rien publié. Mon dernier article ici datait du 29 juillet. Ce silence n'était pas de l'inaction : c'était la phase la moins visible de l'apprentissage, celle où on lit la documentation officielle, où on regarde des schémas d'architecture, où on essaie de comprendre pourquoi Docker existe avant de taper la première commande. Le déclic est venu quand j'ai arrêté de vouloir tout comprendre en théorie avant de commencer, et que j'ai accepté d'apprendre en construisant.

Si tu es en train de lire cet article en te reconnaissant un peu trop, reste. Ce texte est pour toi.

Le déclic : comprendre en construisant

Ce qui m'a débloquée, ce n'est pas un énième tutoriel. C'est une idée toute bête : créer un conteneur qui fait quelque chose, même minuscule, pour voir concrètement ce que Docker permet de faire. J'ai appelé le projet "boxeur" ; une image basée sur Alpine qui exécute en boucle un script Bash et écrit des logs.

Pas de grand plan au départ. Mais à mesure que j'avançais, les concepts clés de Docker se sont mis en place un par un : ce qu'est une image, ce qu'est un conteneur, comment ils communiquent, où vivent les données. Coder, lancer, observer ce qui casse, comprendre pourquoi c'est cette boucle qui m'a fait passer de "je regarde des vidéos sur Docker" à "je sais ce que je fais quand j'utilise Docker".

C'est là que j'ai compris un principe qu'Endah n'arrêtait pas de me répéter : sortir du tutorial hell. Regarder des vidéos, c'est confortable, mais ça reste passif. Taper docker run pour la première fois, lire l'erreur que ton terminal te renvoie, et comprendre ce qu'elle signifie, c'est ça qui construit une vraie compréhension du système.

Les galères (et ce qu'elles m'ont appris sur Docker)

Git 403 : mon premier mur

Avant même de toucher à Docker, j'ai buté sur Git. Un bête 403 Forbidden en essayant de pousser mon code. La solution : générer un Personal Access Token sur GitHub, parce que les mots de passe classiques ne suffisent plus pour l'authentification en ligne de commande. Ça m'a forcée à comprendre comment GitHub gère l'authentification aujourd'hui, pas juste à copier une commande.

Des logs qui n'existaient pas

docker logs boxeur... rien. Un terminal désespérément vide. J'ai mis un moment à comprendre pourquoi : mon script écrivait ses logs dans un fichier à l'intérieur du conteneur, pas sur la sortie standard. Or Docker ne capture que ce qui sort sur stdout c'est une distinction fondamentale entre "écrire un fichier de log" et "logger au sens Docker du terme".

J'ai donc utilisé une autre approche : lire le fichier directement depuis l'intérieur du conteneur.

docker exec boxeur_mentor cat /var/log/boxeur.log

![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/r5wywzvdwbrqmveq1gni.png)

Et là, les logs sont apparus. Cette galère m'a appris comment Docker capture réellement les flux de sortie, et pourquoi la convention "logguer sur stdout" existe dans l'écosystème des conteneurs.

Alpine n'est pas Ubuntu

J'ai voulu installer Nginx et j'ai tapé apt-get install nginx par réflexe. Erreur immédiate. Alpine n'utilise pas apt-get, mais son propre gestionnaire de paquets : apk.

apk add --no-cache nginx

Petit détail, grande leçon : chaque image de base a son propre système et son propre gestionnaire de paquets. Ça m'a poussée à comprendre ce qui différencie réellement les distributions Linux utilisées comme images de base, plutôt que de copier des commandes sans en connaître le contexte.

J'ai aussi bloqué sur un fichier nginx.conf mal écrit (une erreur dès la ligne 2), qu'il a fallu déboguer et réécrire proprement pour que Nginx accepte de démarrer.

La faute de frappe qui m'a coûté une heure

Au moment de pousser mon image sur Docker Hub, j'ai tagué mon image avec une majuscule : Dreatech/boxeur au lieu de dreatech/boxeur. Résultat, une erreur DNS aussi cryptique que frustrante :

lookup Dreatech on 127.0.0.53:53: server misbehaving

Docker Hub n'accepte pas les majuscules dans les noms de dépôt ; une convention de nommage héritée du système de registres de conteneurs. Une fois comprise, la correction était triviale :

docker tag boxeur:latest dreatech/boxeur:latest
docker push dreatech/boxeur:latest

Ce que je retiens vraiment

Au-delà des commandes, ce projet m'a permis de comprendre en profondeur plusieurs concepts fondamentaux de Docker :

Image vs conteneur : l'image est la recette figée ; le conteneur est l'instance qui tourne, vivante, modifiable, jetable. Cette distinction change la façon dont on pense l'architecture d'une application conteneurisée.
Docker Compose comme outil d'orchestration : en faisant communiquer mon "boxeur" et un "observateur" chargé de surveiller ses logs, j'ai compris comment Compose gère les dépendances entre services et le réseau interne qu'il crée automatiquement.
Les volumes et la persistance des données : un bind mount simple, mais qui illustre bien pourquoi la persistance est un problème à part entière quand les conteneurs sont par nature éphémères.
Le poids des images comme critère d'architecture : Alpine pèse environ 7 Mo contre une centaine de Mo pour une image basée sur Ubuntu. Comprendre cet écart m'a fait réaliser l'impact direct du choix d'image de base sur la vitesse de build et de déploiement.

Et puis, il y a eu ce moment précis :

docker run -d --name boxeur_mentor dreatech/boxeur:latest

Mon image, celle que j'avais mis du temps à comprendre et à construire, tournait enfin ; publiée, accessible, réelle.

Le rôle du mentorat

Rien de tout ça ne serait arrivé aussi vite sans l'accompagnement d'Endah, ma mentor dans le cadre du programme CloudHer, porté par Women Innovating In Cloud Africa (WIICA). Ses rappels réguliers m'ont poussée à sortir de la phase de lecture passive pour passer à la pratique ; pas en me donnant les réponses, mais en m'orientant vers les bonnes questions à me poser.

Un bon mentorat, ce n'est pas qu'on fasse le travail à ta place. C'est qu'on te rappelle que tu es capable de comprendre le sujet toi-même, même quand tu doutes d'y arriver.

Ce que je dirais à la moi d'il y a 30 jours

Si tu débutes en DevOps et que Docker te semble être une montagne :

N'attends pas de tout comprendre en théorie avant de commencer. Lance docker run hello-world, puis va lire pourquoi ça fonctionne comme ça a fonctionné.
L'erreur fait partie du chemin d'apprentissage. Un 403, un apk au lieu d'un apt-get, un tag mal écrit — chaque erreur t'oblige à comprendre un mécanisme que tu aurais pu ignorer sinon.
Construis quelque chose pour comprendre un concept, pas pour produire un résultat. Mon "boxeur" ne sert à rien de productif, mais c'est le projet qui m'a fait vraiment saisir ce que Docker fait et pourquoi.
Entoure-toi de quelqu'un qui challenge ta compréhension. Le mentorat m'a poussée à expliquer ce que je faisais, pas juste à le faire.

Pour finir

Mon image est disponible sur Docker Hub : dreatech/boxeur.

Le premier docker run, ce n'était pas difficile parce que la syntaxe est compliquée — mais parce qu'il faut accepter d'apprendre un système par la pratique, en tolérant de ne pas tout maîtriser dès le départ.

Si toi aussi tu as un projet qui prend la poussière depuis des semaines parce que tu attends de tout comprendre avant de te lancer : prends le temps qu'il faut pour bien saisir les bases, puis lance la première commande.

Tu es aussi en train d'apprendre Docker ou le DevOps ? Dis-moi en commentaire sur quoi tu bloques en ce moment;je serais ravie d'en discuter. Et si cet article t'a parlé, un partage aide énormément à faire connaître ce genre de retour d'expérience !

[Boost]

Samuel Adekunle — Thu, 10 Sep 2026 22:27:33 +0000

Samuel Adekunle

Sep 10

Automate Flutter Releases with Shorebird + GitHub Actions (Skip App Store Review)

#flutter #mobile #techwithsam #githubactions

6 min read

Automate Flutter Releases with Shorebird + GitHub Actions (Skip App Store Review)

Samuel Adekunle — Thu, 10 Sep 2026 22:27:12 +0000

A real pain point for mobile apps is waiting days or weeks for App Store and Play Store reviews whenever you need to ship a fix or a small update to users.

That exact problem is what we are solving in this article. I’ll show you exactly how to automate your Flutter releases and patches using Shorebird and GitHub Actions, so you can push updates to users in minutes instead of waiting for store review.

We are going to create a clean, production-ready CI pipeline for both full releases and instant code-push updates.

Prerequisites

Before we start, here’s what you need:

A Shorebird account and an app already set up with Shorebird
Shorebird CLI installed and logged in on your machine
A Flutter project that already has Shorebird initialized
A GitHub repository
Basic understanding of GitHub Actions

If you haven’t set up Shorebird in your Flutter app yet, check out my video on YouTube on how to set up Shorebird. This article assumes that’s already done.

Authentication Setup

The first thing we need is authentication so GitHub Actions can talk to Shorebird.

Go to the Shorebird Console → Account → API Keys → Create API Key.

Give it a clear name, e.g “GitHub Actions”, choose an expiration, and set the required permissions.

Copy the key immediately because you won’t see it again.

Now go to your GitHub repository → Settings → Secrets and variables → Actions → New repository secret.

Name it exactly: SHOREBIRD_TOKEN

Paste the key and save.

This token will be available in all your workflows as ${{ secrets.SHOREBIRD_TOKEN }}.

That’s the only authentication step you need.

Official Shorebird GitHub Actions

Shorebird provides three official GitHub Actions that make life much easier:

shorebirdtech/setup-shorebird@v1 — installs Shorebird on the runner
shorebirdtech/shorebird-release@v1 — creates a release
shorebirdtech/shorebird-patch@v1 — creates a patch

I strongly recommend using these instead of calling the CLI manually. They’re cleaner and maintained by the Shorebird team.

Release Workflow

Let’s build the release workflow first.

Create a new file in your project: .github/workflows/shorebird-release.yml

Here’s the structure:

Trigger on version tags: v1.0.0, v1.2.3, etc. or manually trigger the workflow
Set the SHOREBIRD_TOKEN as an environment variable
Pin your Flutter version (very important)
Checkout the code
Set up Java for Android (or Xcode signing for iOS)
Set up Shorebird with caching
Decode your keystore/certificates from secrets
Run the official shorebird-release action
Upload the APK, AAB, or IPA as artifacts

I’ll show both Android and iOS versions.

For Android, the key steps are decoding the keystore and creating the key.properties file from secrets.

GitHub Secrets You Need to Add for Android

Go to GitHub → repo → Settings → Secrets and variables → Actions → New repository secret

Secret name - Value
ANDROID_KEY_ALIAS - your_key_alias
ANDROID_KEY_PASSWORD - your_key_password
ANDROID_STORE_PASSWORD - your_store_password
ANDROID_KEYSTORE_BASE64 - run `base64 -i ~/path/to/upload.jks | tr -d '\n' | pbcopy`
The keystore base64 will be copied to your clipboard; paste it into GitHub Secrets

GitHub Secrets You Need to Add for iOS

Go to GitHub → repo → Settings → Secrets and variables → Actions → New repository secret

Secret name - Value
IOS_CERTIFICATE_BASE64 - base64 of your .p12
IOS_CERTIFICATE_PASSWORD - Password you set when exporting the .p12
IOS_PROVISIONING_PROFILE_BASE64 - base64 of com.example.app profile

For iOS, you need to import the certificate and provisioning profile into a temporary keychain.

# IOS_CERTIFICATE_BASE64 - export your .p12 from Keychain Access first, then:
base64 -i ~/path/to/distribution.p12 | tr -d '\n' | pbcopy

# IOS_PROVISIONING_PROFILE_BASE64 - download from Apple Developer Portal
base64 -i ~/path/to/YourApp_AppStore.mobileprovision | tr -d '\n' | pbcopy

You can check out this document on how to create an Apple Distribution Certificate.

Once this workflow finishes, you get signed artifacts ready to upload to the stores.

This is your normal full release path.

name: Shorebird Release

on:
  workflow_dispatch:
    inputs:
      platform:
        description: 'Target platform'
        required: true
        default: 'both'
        type: choice
        options:
          - android
          - ios
          - both

jobs:
  release_android:
    name: Release Android
    if: ${{ github.event.inputs.platform == 'android' || github.event.inputs.platform == 'both' }}
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Setup Android Keystore
        run: |
          echo "${{ secrets.ANDROID_KEYSTORE_BASE64 }}" | base64 --decode > android/app/keystore.jks
          cat > android/key.properties <<EOF
          storePassword=${{ secrets.ANDROID_STORE_PASSWORD }}
          keyPassword=${{ secrets.ANDROID_KEY_PASSWORD }}
          keyAlias=${{ secrets.ANDROID_KEY_ALIAS }}
          storeFile=keystore.jks
          EOF
        shell: bash

      - name: Setup Shorebird
        uses: shorebirdtech/setup-shorebird@v1

      - name: Shorebird Release (Android)
        uses: shorebirdtech/shorebird-release@v1
        id: shorebird-release
        with:
          flutter-version: latest
          platform: android
        env:
          SHOREBIRD_TOKEN: ${{ secrets.SHOREBIRD_TOKEN }}

      - name: Print Release Version
        run: echo "Released version ${{ steps.shorebird-release.outputs.release-version }}"
        shell: bash

Full release on GitHub Gist.

Patch Workflow — The Real Power

Now, the part that actually lets you skip App Store review.

Create another file: .github/workflows/shorebird-patch.yml

name: Shorebird Patch

on:
  push:
    branches:
      - main
  workflow_dispatch:
    inputs:
      platform:
        description: 'Target platform'
        required: true
        default: 'both'
        type: choice
        options:
          - android
          - ios
          - both
      release-version:
        description: 'Release version to patch (e.g. 1.0.0+1). Defaults to latest.'
        required: false
        default: 'latest'

jobs:
  patch_android:
    name: Patch Android
    if: ${{ github.event_name == 'push' || github.event.inputs.platform == 'android' || github.event.inputs.platform == 'both' }}
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Setup Android Keystore
        run: |
          echo "${{ secrets.ANDROID_KEYSTORE_BASE64 }}" | base64 --decode > android/app/keystore.jks
          cat > android/key.properties <<EOF
          storePassword=${{ secrets.ANDROID_STORE_PASSWORD }}
          keyPassword=${{ secrets.ANDROID_KEY_PASSWORD }}
          keyAlias=${{ secrets.ANDROID_KEY_ALIAS }}
          storeFile=keystore.jks
          EOF
        shell: bash

      - name: Setup Shorebird
        uses: shorebirdtech/setup-shorebird@v1

      - name: Shorebird Patch (Android)
        uses: shorebirdtech/shorebird-patch@v1
        id: shorebird-patch
        with:
          platform: android
          release-version: ${{ github.event.inputs.release-version || 'latest' }}
          args: --allow-asset-diffs --allow-native-diffs
        env:
          SHOREBIRD_TOKEN: ${{ secrets.SHOREBIRD_TOKEN }}

      - name: Print Patch Number
        run: echo "Patch number ${{ steps.shorebird-patch.outputs.patch-number }}"
        shell: bash

Full release on GitHub Gist.

Trigger this one on hotfix tags, for example: v1.0.0-hotfix.1

The structure is almost identical to the release workflow, but we use the shorebird-patch action instead.

Important points:

A patch can only be applied to an existing release
Use the — staging flag first so you can preview the update
After testing with shorebird preview — track=staging, promote it to production from the Shorebird Console.

This is the real magic. Users get the fix over-the-air (OTA) in minutes. No waiting for review. No forcing them to download a new version from the store.

Recommended Development Workflow

Here’s the clean workflow I recommend (and the one Shorebird documents):

Work on features and fixes on feature branches
Open a pull request into main
CI runs formatting, analysis, and tests
Squash and merge into main (main stays always releasable)
When you’re ready for a full release → create a tag like v1.2.0 → the release workflow runs automatically
If a critical bug appears → fix it on main → cherry-pick into the release branch → create a hotfix tag like v1.2.0-hotfix.1 → the patch workflow runs
Preview on staging → promote to production

This keeps everything automated, clean, and low-risk.

Best Practices

A few important tips:

Always pin the Flutter version on releases using — flutter-version
Use — dry-run on pull requests so you catch build issues early without creating real releases or patches
Keep your SHOREBIRD_TOKEN secure — never hardcode it
For iOS environments without certificates, you can use — no-codesign (then sign later)
Shorebird automatically runs in non-interactive mode in CI when the token is present

Follow these, and your pipeline will be solid.

Resources

All of this is based on the official Shorebird documentation:

I’m also a Shorebird Ambassador, so if you have questions, drop them in the comments.

That’s it.

You now have a complete automated system:

Full releases go through the stores as usual
Critical updates and bug fixes go live to users in minutes via Shorebird

No more waiting for review every single time.

If this was useful, hit the like button, subscribe, and turn on notifications so you don’t miss the next post.

If you want personalized help setting this up for your project, you can send a DM.

I’ll see you in the next one. Peace.

NBA play-in odds are not playoff odds: simulating the play-in tournament instead of guessing it

Elio Liberatore — Thu, 10 Sep 2026 22:26:19 +0000

In baseball, American football and hockey, "make the playoffs" is one line: finish above it and you're in. When I built an NBA version of my playoff-odds simulator, I assumed the same, and my first plan was to compare the model against the wrong market.

Basketball has a band in the middle, and getting it right changes almost every number.

Three zones, not two

In each 15-team conference:

Finish	What it means
1st – 6th	Straight into the playoffs
7th – 10th	Into the play-in tournament, where two of four survive
11th – 15th	Season over

The play-in works like this. Seed 7 plays seed 8; the winner is the 7th seed. Seed 9 plays seed 10; the loser goes home. The loser of 7 v 8 then hosts the winner of 9 v 10, and that game decides the 8th seed.

Kalshi lists these as separate markets — one for playoff qualification across all 30 teams, and one play-in market per conference — and its contract rules settle the question in one sentence: "Qualifying for the play-in tournament doesn't constitute playoff qualification."

So the play-in market is not a weaker version of the playoff market. It's a band, and the two behave almost like opposites. A title contender is a near-certainty for the playoffs and a near-zero for the play-in. A 44-win team can be close to a coin flip between the two.

Simulate the games, don't approximate them

The tempting shortcut is to say "finish 7th or 8th, you're probably in; 9th or 10th, probably not". That breaks the moment you need two numbers that agree with each other: the chance of reaching the playoffs and the chance of landing in the play-in.

So in every simulated season the model:

Plays out the remaining regular-season schedule.
Seeds each conference.
Plays the three play-in games.
Runs the full bracket: four rounds of best-of-seven series with the 2-2-1-1-1 home-court pattern.

That produces, for every team and from the same simulated seasons: top-six probability, play-in probability, playoff probability, conference finals, conference title and championship. Sanity checks come for free — the championship column sums to 1 across the league and conference finals to 4.

Basketball-specific modelling choices

Pythagorean exponent. Points scored and allowed predict future results better than record alone, but the exponent depends on the sport. Baseball uses about 1.83, hockey 2.0; for basketball I use 13.91. Plugging a baseball exponent into NBA scoring wildly compresses the gap between good and bad teams.

Uncertainty about strength itself. My first version drew game outcomes from fixed team ratings. In September it confidently told me some teams made the playoffs 100% of the time and others 0%. That's not how the NBA works. Now each simulated season redraws every team's rating once (a 0.22 spread by default), so the output is a distribution rather than one confident guess. That alone cut the average gap against the market from 15.2 to 12.9 points and removed every 0% and 100%.

The two missing games. The 2026-27 regular season is 82 games, but ESPN's schedule currently lists 80 per team: the other two depend on the NBA Cup and are scheduled later. If you simply simulate the schedule you can see, every team's projected wins sit on an 80-game scale. I simulate the missing two against an average opponent on a neutral floor.

A September snapshot

From one run on 10 September 2026:

Team	Projected wins	Top six	Play-in	Playoffs	Title
Oklahoma City	55.3	97.0%	2.8%	99.1%	23.9%
San Antonio	52.1	91.6%	7.8%	97.0%	11.8%
Boston	51.6	88.2%	11.0%	95.9%	11.6%
Toronto	44.8	51.0%	41.0%	73.7%	2.2%
Atlanta	44.4	48.2%	42.4%	71.7%	1.8%
Miami	44.3	47.9%	42.6%	71.3%	1.8%

Look at Toronto, Atlanta and Miami: roughly a coin flip to avoid the play-in, and more than 40% to end up in it. For those teams, playoff odds and play-in odds are both "live" — exactly why they need separate columns.

The number I don't trust

Against Kalshi's playoff contracts that day, most of the table lines up within a few points: Oklahoma City 99.1% in the model against 98% on the market, Miami 71.3% against 72.5%, Toronto 73.7% against 70.5%.

Then there's Charlotte: 86.5% in the model, 36% on the market. A fifty-point gap.

That is not an opportunity. Before opening night, the model knows only how last season ended, regressed towards average. It hasn't seen free agency, the draft, trades or injuries. The market has. When I first measured the model against Kalshi in September, the rank correlation was about 0.80 and the average gap about 13 points — and the largest gaps were teams whose whole case this year is the offseason.

So the simulator refuses to call anything "value" until every team has played ten games. It still reports every gap, labelled WATCH. A model that disagrees with the market by fifty points in September is telling you what it can't see, not what the market got wrong.

One market-side detail worth copying

Playoff qualification is sixteen independent yes/no contracts, so prices across the league add up to about 16, not 1. Never normalise that field to 1. And price both sides of each contract: if the model says 60% and YES trades at 75 cents, the signal is on the NO side, not "no signal".

Try it

The simulator is published as an Apify Actor: NBA Playoff Odds API — Monte Carlo Simulator & Value Bets. Standings and schedules come from ESPN and prices from Kalshi's public API, with no keys needed. Ready-made examples include play-in tournament odds by conference, championship odds from a simulated bracket, projected win totals and tracking playoff odds all season.

The season starts on 20 October. Simulation and data, not tips.

NHL playoff odds for 2026-27: 84 games, the wild card rule, and why I don't trust my own model in September

Elio Liberatore — Thu, 10 Sep 2026 22:26:00 +0000

I build Monte Carlo simulators that turn standings and schedules into playoff probabilities. After baseball, American football and soccer, I assumed hockey would be a copy-paste job with new team names.

It wasn't. Four things about the NHL break a generic season simulator, and one of them changed this summer. Here they are, followed by the part I find most interesting: what the model says a few weeks before opening night, and why most of its disagreements with the market should be ignored.

1. Standings run on points, not wins

A win is two points. An overtime or shootout loss is still worth one. Roughly 23% of NHL games go past regulation, so ranking simulated teams by wins misprices every club that lives in one-goal games.

In the simulator each game has three outcomes — regulation win, overtime or shootout win, and the mirror images — and points are awarded the way the league awards them.

There is a trap on the strength side too. Points percentage averages about .557 across the league because of the loser point, while win/loss averages exactly .500 because every game has a winner. If you estimate team strength from points percentage, every team looks slightly better than average. I estimate it from wins over games played, and from goals for and against with a Pythagorean exponent of 2.0.

2. The playoff field is not "the top eight"

Sixteen of 32 teams qualify, but not by conference rank. In each conference the top three of each division get in, and then the two best remaining teams take the wild cards regardless of division. A fourth-place team in a strong division and a third-place team in a weak one are not interchangeable.

That rule has to run inside every simulated season. It also gives you a free sanity check: across all 32 teams, playoff probabilities must sum to exactly 16. If yours sum to 15.7, something is wrong.

3. Overtime is closer to a coin flip

Three-on-three and the shootout are not sixty minutes of five-on-five hockey. A better team carries less of its edge into the extra period. I damp the strength gap by half in overtime (overtimeDamping = 0.5). Setting it to 0 makes overtime a pure coin flip; 1 treats it like regulation.

4. The season is 84 games now

The collective bargaining agreement signed in 2025 moved the NHL to 84 regular-season games from 2026-27. ESPN's event count per team shows 84 for this season and 82 for last. I never hardcoded the season length — the simulator counts the games on the schedule feed — so projected point totals landed on the right scale without a code change. If you maintain a model with 82 somewhere in it, now is the time to look.

One more data quirk: ESPN names a season by the year it ends, so 2026-27 is season=2027, and before opening night the 2027 standings tree exists but has zero teams in it. You need to fall back to the previous season for the list of clubs and divisions.

What the model says right now

Here is part of a 20,000-season run from 10 September 2026, next to the live price of Kalshi's "make the playoffs" contract for each team:

Team	Projected points	Model playoff %	Kalshi	Gap
Colorado	109.6	96.5%	91%	+5.5
Carolina	103.5	82.9%	89.5%	−6.6
Buffalo	101.6	76.3%	56%	+20.3
Edmonton	95.7	68.3%	85%	−16.7
Vegas	95.2	66.4%	85.5%	−19.1
Boston	97.0	58.3%	31%	+27.3
Pittsburgh	95.5	52.5%	29.5%	+23.0
San Jose	89.7	42.3%	67.5%	−25.2

Boston 27 points above the market. San Jose 25 below. If you believed the model, those would be the trades of the year.

Why I don't believe it (yet)

In September the model knows exactly one thing about each club: how last season ended, shrunk 40% towards average. It hasn't seen a trade, a signing, an injury, a goalie change or a new coach. The market has seen all of them.

So the biggest gaps in September are not edges. They are the offseason. Betting them is betting that the summer didn't happen.

When I first compared the model with Kalshi across all 32 teams, the rank correlation was 0.65 and the average gap was about 14 points, and the largest disagreements were precisely the teams whose summers changed the most. That is what a season-carryover model should look like before the puck drops.

Instead of hiding that, I made it a rule in the output. Until every team has played a minimum number of games (10 by default), no row is allowed to call itself value. Every gap is still reported in full, but it's labelled WATCH. After that, the current season's record takes over from last season's gradually, rather than overnight after a hot week.

The fee changes which gaps matter

Kalshi's taker fee is 0.07 × p × (1 − p) per contract. It peaks in the middle: 1.75 cents on a 50-cent contract, 0.63 cents on a 90-cent one. So a 1.5-point edge on a coin-flip contract is a losing position after fees, while the same gap on a heavy favourite isn't. Any comparison that ignores this will rank the wrong teams first.

A second trap: the playoff market is sixteen independent yes/no contracts, so prices across the league add up to about 16, not 1. If you "de-vig" it the way you would a division-winner market, you divide every probability by sixteen and manufacture huge fake edges everywhere. Division winners, on the other hand, are exclusive — exactly one team wins — and there you do strip the overround.

Watching it move

The part I'm looking forward to is not the September table. It is the path. Each run can append its 32 rows to a named dataset that keeps growing, so a daily schedule gives you, by spring, how each team's probability moved across the season next to what the market charged for it on the same day — something you can't reconstruct afterwards.

Try it

The simulator is published as an Apify Actor: NHL Playoff Odds API — Monte Carlo Simulator & Value Bets. No API keys for the data; standings and schedules come from ESPN, prices from Kalshi's public API. There are ready-made examples for projected points standings, wild card odds, Presidents' Trophy odds and tracking playoff odds all season.

Simulation and data, not tips.

Correct score, BTTS and Over/Under probabilities with Dixon-Coles: what I learned building it for MLS and Liga MX

Elio Liberatore — Thu, 10 Sep 2026 22:25:35 +0000

Most football prediction pages give you three numbers — home, draw, away — and no way to check where they came from. I wanted the opposite: one model, fitted on real results, that produces the 1X2 probabilities, the Over/Under 2.5 line, Both Teams To Score and the exact-score grid, all from the same place, so they can't contradict each other.

The model I ended up with is Dixon-Coles. This post is what it does, why it beats the simpler version most tutorials start with, and what came out when I ran it on eight leagues that don't get much attention from modellers: MLS, Liga MX, Liga de Expansión MX, the Brasileirão Série B, the USL Championship, Colombia's Primera A, Uruguay's Primera División and Norway's Eliteserien.

The starting point: independent Poisson

The classic approach gives every team an attack rating and a defence rating, adds a home advantage, and turns them into expected goals for each side of a fixture — call them λ for the home team and μ for the away team. Goals are then treated as two independent Poisson variables. The probability of a 2-1 is just P(home scores 2) × P(away scores 1).

It works surprisingly well. It also has one known blind spot: low scores. Real matches finish 0-0 and 1-1 more often than two independent Poisson draws predict, and 1-0 / 0-1 slightly less often. Anything that depends on those four cells — the draw, Under 2.5, BTTS "No" — inherits the error.

The Dixon-Coles correction

In 1997 Mark Dixon and Stuart Coles proposed a small fix. Keep the Poisson grid, but multiply the four low-score cells by a factor that depends on one extra parameter, ρ (rho):

Score	Adjustment
0-0	1 − λμρ
0-1	1 + λρ
1-0	1 + μρ
1-1	1 − ρ
anything else	1

With a negative ρ, 0-0 and 1-1 go up and 1-0 / 0-1 go down — exactly the direction the data pulls.

To see how much that matters, take a match with 1.35 expected goals for the home side and 1.15 for the away side, and an illustrative ρ of −0.13:

	Independent Poisson	Dixon-Coles
Draw	26.8%	30.2%
0-0	8.2%	9.9%
1-1	12.7%	14.4%
Home win	41.3%	39.7%
Away win	31.8%	30.2%

Same expected goals, three and a half points more on the draw. If you compare model probabilities with prices, that is the difference between seeing an edge and not seeing one.

Two things the paper adds that tutorials often skip

Time decay. A result from three seasons ago should not count as much as last weekend's. Dixon and Coles weight each match by exp(−ξ·t), where t is its age in days. I use ξ = 0.0018, which halves a result's weight after roughly a year, and fit on three seasons of history.

Fit ρ from the league itself. ρ is not a universal constant. After fitting attack, defence, home advantage and the baseline by weighted maximum likelihood, I fit ρ separately for each league. They come out different. On 6 September, Colombia's Primera A gave a home advantage of 0.349 (on the log scale) and ρ = −0.044; Norway's Eliteserien gave 0.276 and ρ = −0.015. Colombian home sides get a bigger boost, and the low-score correction matters less in Norway.

Where the data comes from

All eight leagues come from ESPN's public scoreboard endpoint:

https://site.api.espn.com/apis/site/v2/sports/soccer/<league>/scoreboard?dates=YYYYMMDD-YYYYMMDD

Two things cost me time and might save you some:

Ask for a date range, not a single day. With dates= set to one day, a smaller league often returns nothing simply because it didn't play that day, which looks exactly like missing data. A week-long range removes the ambiguity.
Filter by state, not by status name. Finished matches carry status.type.state === "post" and completed: true; scheduled ones are "pre". That is more robust than matching STATUS_FULL_TIME.

Slugs are not always what you'd guess. The USL Championship is usa.usl.1, not usa.2.

History depth is not the bottleneck. The Premier League scoreboard answers back to at least 2002-03, and MLS and Liga MX back to at least 2004-05. Three seasons is plenty.

What one prediction looks like

Here is a real row from a test run on 6 September — Atlanta United at home to Orlando City in MLS:

Field	Value
λ home / λ away	1.57 / 1.63
ρ (MLS)	−0.040
Home / Draw / Away	36.5% / 24.2% / 39.2%
Over 2.5 goals	62.1%
Both teams to score	64.1%

And from Liga MX the same day, Pumas UNAM against León: λ 1.94 against 0.94, so 60.1% / 23.0% / 16.9%. A strong home side, and the numbers say so.

Every probability comes from one score grid (0-0 up to 10-10), normalised to 1, so 1X2 sums to 1, Over + Under sums to 1 and BTTS Yes + No sums to 1. I checked that on every row of a 28-match Série B run; the error was floating-point noise.

The awkward case: promoted teams

A team with no matches in the lookback window has no rating. The honest options are to guess or to say so. I start it at league-average strength and flag every fixture it plays with dataQuality: "partial-new-team", so whoever uses the numbers can decide how much to trust them until the team has a few games on the board.

What it doesn't do

It doesn't know about injuries, suspensions, rotation, weather or a manager who has just been sacked. It treats every match in the lookback window the same apart from its age. It is a baseline, not an oracle — which is exactly what makes it useful to compare against prices.

Try it without writing the model

I packaged all of this as an Apify Actor: Soccer Match Predictions API — 1X2, Over/Under & BTTS Odds. You pick a league, it returns one row per upcoming fixture with everything above. There are ready-made examples, such as MLS correct score probabilities and Liga MX match predictions, and the rest are listed on the examples page.

If you'd rather build it yourself, the table of adjustments above and the ESPN endpoint are all you need to get started. Either way: simulation and data, not tips.

I Asked a Frontier LLM to Recover Secrets from My Decompiled Build

Nikolai Sachok — Thu, 10 Sep 2026 22:18:06 +0000

The clean way to protect application logic is to keep it on a server, out of reach. When it has to live in the client, anyone can pull apart and analyze the compiled app on their device. Obfuscation cannot make recovery impossible; it can only raise its cost. Making a secret unreadable in a decompiler leaves an awkward question: how hard is it to recover?

That was the question I wanted to answer about my own build hardening. I could inspect the output and confirm that configuration values no longer appeared as readable strings. But I knew how the hardening worked. I knew which data mattered, where decoding happened, and what relationships to look for. My ability to recognize the result told me little about how difficult it would be to discover those relationships without that context.

Out of engineering curiosity, I gave a frontier LLM the build and had it investigate. I wanted to see whether it could work backward from the shipped artifact to the secrets the application could recover for itself. The interesting part of the experiment became the investigation around the model: how to challenge its interpretations, what evidence to demand, and how much confidence to place in a failed recovery attempt.

The master key ships inside the binary

I started with a boundary that had to remain explicit throughout: the master key ships inside the binary.

The application needs to decode its values, so the artifact contains what it needs to do that. A sufficiently capable reverse engineer might find the master key, understand the derivation, and reproduce the decoding. I wrote that limitation into the threat model. The hardening aims to raise the cost of reverse engineering and make encoded values harder to associate with one another.

I treated this as an obfuscation test. Calling it cryptographic protection would obscure the engineering question I could actually investigate: given the build, could an adversary find and use the material already inside it?

Making the relationships harder to discover

The configuration values are XOR-encoded. Each value uses a working key derived at runtime from a single 32-byte master key. Those working keys are never stored at rest in the binary.

XOR is straightforward to reverse once the corresponding key bytes are available. The difficulty I was trying to introduce therefore lay in discovery: recognizing which arrays held encoded values, finding the master key, and connecting it to the derivation and decoding logic. Removing readable strings eliminates an easy starting point, but those relationships are what an investigator ultimately needs to reconstruct.

The encoded values appear as numeric byte-array literals resembling hashes. There is no string in the binary that reads as a key. To someone who already understands the implementation, these arrays have clear roles. To someone examining the build blind, their appearance supplies much less context.

I also wanted to remove similarities between related values. Shared prefixes can give an investigator a useful foothold: several values that look alike may belong together, and understanding one can guide the investigation of the others. The derivation deliberately strips shared prefixes so that similar secrets do not produce similar-looking output.

That matters because recovery does not have to begin with decoding. An investigator might first cluster values, infer that a group shares a purpose, and then search for the code consuming it. Decorrelation is intended to make that earlier step harder. It removes a recognizable relationship from the output, while leaving the application able to recover each value.

Three implementations must agree byte for byte

There is an implementation cost to this arrangement. The derivation exists in three independent places: the application runtime, a build-time tool, and a native build script. They are written in three different languages and must agree byte for byte.

Conceptual agreement is insufficient here. Each implementation has to produce exactly the bytes the others expect. Differences in how languages handle bytes and numeric operations can matter when the output of one implementation becomes the input to another. If the derivations diverge, the application fails to decode its values.

That requirement gave the hardening two distinct questions to answer. The implementations had to agree exactly for the application to function, and the resulting artifact had to be difficult to interpret without knowing the design. Agreement addresses correctness. A blind investigation addresses the second question.

An adversarial court

For that investigation, I used a group of LLM agents organized as an adversarial court.

Three neutral researchers gathered facts from different parts of the build. One examined code, permissions, and obfuscation patterns. Another focused on network and data. The third investigated libraries and behavior. Their job was to establish what the artifact supported before turning observations into an argument.

A prosecutor then argued for findings, with a deliberate bias toward identifying problems. An advocate challenged those interpretations and supplied mitigating or benign explanations. An impartial judge weighed the record and decided which conclusions had enough support.

The separation mattered because a single analysis prompt makes it easy for one interpretation to dominate. Once an explanation looks plausible, subsequent observations can be fitted around it. Asking the same analysis to find evidence, develop a theory, challenge the theory, and deliver a verdict gives it several responsibilities that pull in different directions.

The opposed roles made those tensions explicit. The prosecutor had reason to pursue an uncomfortable interpretation. The advocate had reason to identify missing links and explain why the same observation might be harmless. The judge had a record containing both arguments.

This arrangement does not make the agents independent sources of truth. They can still share blind spots or make the same mistake. Its practical value is that objections become part of the process, with a role responsible for developing them. A persuasive account has to survive a challenge before it becomes a finding.

What counts as independent evidence

That only helps if the challenge is technical. I required two or three independent technical indicators before accepting a conclusion. A single suspicious pattern remained a lead.

The word “independent” carries much of the weight. Several agents repeating the same observation do not create several pieces of evidence. Nor does describing one byte array in three different ways. Corroboration has to add support that the original observation did not already contain.

For example, the presence of an encoded-looking array is a reason to investigate. A stronger case would connect that array to reachable decoding logic and then connect the decoded result to its use. Each connection answers a different question: what the data might be, whether the relevant code can run, and whether the interpretation fits the application’s behavior. That is the kind of reasoning the evidence requirement was intended to demand.

Reachability was another explicit check. Code existing in a decompiled build does not by itself establish that the application executes it. An interpretation resting on a theoretical path deserves less confidence than one supported by observed behavior.

I also required the investigation to consider a legitimate explanation before concluding. That gave the advocate a concrete task. It had to explain how the available evidence could fit an ordinary purpose, and identify what further evidence would distinguish the competing interpretations.

These rules gave the judge a basis for weighing the record beyond which agent sounded most certain. An accusation could be plausible and still unsupported. A benign explanation could be possible and still fail to account for the evidence. The purpose of the process was to make those gaps visible.

This is where role separation earns its overhead. A single broad analysis request can produce a fluent story whose weak points are difficult to see. Opposed roles and an evidence bar force more of the reasoning into view, helping surface supported findings and reducing room for invented explanations. That gives me a practical reason to prefer the structure, without treating this experiment as a measurement of its advantage across models or artifacts.

What the blind attempt established

In this blind attempt, the model could neither identify the master key nor cluster the encoded values. It had only the build and had not been told what to look for. The hardening held against that attempt.

The qualification “blind” is essential. Pointing an investigator at a particular array, explaining the derivation, or identifying the decoding path changes the task. Discovery is part of the reverse-engineering cost, and this experiment included it. The model’s failure to discover the necessary relationships says something useful about that cost under the tested conditions, even though it does not quantify it.

It does not establish that recovery is impossible. The master key remains in the binary. Another investigator, a different approach, or additional guidance could produce a different result. One unsuccessful attempt cannot settle those possibilities.

What I gained was a concrete observation about the shipped artifact from an adversary that lacked my implementation knowledge. That was more useful than inspecting unreadable values and deciding they looked sufficiently obscure.

LLMs make this kind of artifact testing practical and inexpensive enough to be worth doing. Their usefulness extends beyond reviewing source code: they can investigate what a build reveals, particularly when their conclusions have to pass through competing interpretations and explicit evidence requirements.

For me, the strongest result was a bounded one: a frontier LLM operating blind failed to find the master key or cluster the encoded values, despite an investigation designed to challenge comfortable conclusions. I can use that result because I can state its limits just as plainly. The key is still there; this adversary did not find it.

How I Slashed a Docker Image from 442 MB to 56 MB (87% Cut) and Hardened It for Production

Alan Varghese — Thu, 10 Sep 2026 22:17:59 +0000

We've all been there: you whip up a simple microservice in Python, write a quick Dockerfile, run docker build, and suddenly your container image weighs almost half a gigabyte (or 1.75 GB uncompressed on disk!).

For a 15-line Flask application with two routes? That felt unacceptable.

Bloated Docker images slow down CI/CD pipelines, increase registry storage bills, consume unnecessary bandwidth during deployment, and—worst of all—expand the security attack surface with packages that have no business being in a production container.

In this project, I took a bloated baseline image and systematically redesigned it. The outcome?

🔥 Image Content Size: Reduced from 442 MB to 56.6 MB (87.19% reduction)

💾 Disk Usage: Dropped from 1.75 GB to 256 MB (85.37% reduction)

🛡️ Security: Transitioned from running as root to a hardened, non-root system user

⚡ Build Time: Dramatically improved iterative build speeds using Docker layer caching

🚀 Runtime: Replaced Flask's single-threaded dev server with a production WSGI server (Gunicorn)

Here is the full breakdown of how I did it, the pitfalls I ran into, and the key lessons you can apply to your own containers today.

🛑 The "Before": A Naive, Bloated Baseline

Here is what our initial Dockerfile.baseline looked like:

FROM python:3.12

WORKDIR /app

COPY . .

RUN apt-get update
RUN apt-get install -y curl git vim

RUN pip install --no-cache-dir -r requirements.txt

EXPOSE 5000

CMD ["python", "app.py"]

At first glance, it looks familiar. It sets a workdir, copies files, installs tools, installs dependencies, and runs the app.

Let's build it and inspect the damage:

docker build -f Dockerfile.baseline -t myapp:baseline .
docker images myapp:baseline

Output:

REPOSITORY   TAG        IMAGE ID       CREATED          SIZE
myapp        baseline   a1b2c3d4e5f6   10 seconds ago   442MB

Checking uncompressed disk usage with Docker desktop / inspect: 1.75 GB!

What Went Wrong Here?

The Base Image: python:3.12 is built on a full Debian distribution packed with compilers, header files, and utilities our web app will never call.
Unnecessary Packages: We installed curl, git, and vim. Why does a production container need a text editor and a version control tool?
Separate RUN instructions: RUN apt-get update and RUN apt-get install created two separate filesystem layers, storing temporary cache files forever in the image layer history.
Poor Layer Caching: COPY . . came before RUN pip install. Any tiny change to app.py busted Docker's cache and forced pip install to execute again from scratch.
No .dockerignore: Test files, git history, and local virtual environments were beamed right into the Docker daemon context.
Insecure Execution: The app runs as root (UID 0).
Development Server: Flask’s built-in server is not built for production workloads.

Let's fix this step-by-step.

🛠️ The 6-Step Optimization Playbook

Step 1: Switch to a Minimal Base Image (`-slim`)

The single highest-leverage change you can make is picking the right base image.

Instead of the full python:3.12, we switched to python:3.12-slim:

FROM python:3.12-slim

Why not Alpine (python:3.12-alpine)?

Alpine uses musl libc instead of glibc. While Alpine is tiny, Python packages with C extensions (like numpy, cryptography, etc.) frequently lack pre-compiled wheels for musl, triggering slow compilation during build or subtle runtime bugs. Debian slim is the sweet spot for Python: rock-solid compatibility with standard glibc wheels and a tiny footprint.

Step 2: Ruthlessly Prune Unnecessary OS Packages

Running docker history myapp:baseline exposed where the bloat lived:

apt-get update layer: ~21.3 MB
curl git vim layer: ~53.1 MB

Neither git nor vim belong in a running container. If you need to debug a running container, use ephemeral debugging sidecars or mount volumes—don't permanently ship development utilities to production.

We dropped the apt-get commands entirely.

Step 3: Add a Scrupulous `.dockerignore`

Whenever you run docker build, Docker first transfers the entire directory (the "build context") to the Docker daemon.

Without .dockerignore, you're sending .git logs, .venv, .pytest_cache, and temporary files.

We added .dockerignore:

.git
.gitignore
__pycache__
.pytest_cache
.venv
tests
*.pyc
README.md
Dockerfile*

This trimmed build context overhead and ensured sensitive or extraneous files could never leak into the container.

Step 4: Master Layer Caching (Order Matters!)

Docker caches image layers. A layer is invalidated as soon as the files it depends on change.

In our baseline:

# ❌ BAD: Edits to app.py invalidate pip install cache
COPY . .
RUN pip install --no-cache-dir -r requirements.txt

In our optimized build:

# ✅ GOOD: Dependencies change rarely, application code changes frequently
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY --chown=appuser:appuser app.py .

Now, during local development, editing app.py results in a rebuild that finishes in under a second because the heavy pip install layer is pulled straight from cache!

Step 5: Adopt a Production WSGI Server (Gunicorn)

Flask's built-in server warns you right in the logs:

"WARNING: This is a development server. Do not use it in a production deployment."

We added gunicorn to requirements.txt and updated our entrypoint:

CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]

Gunicorn gives us process management, worker concurrency, and resilient request handling without bloating image size.

Step 6: Hardening Security — Run as Non-Root

By default, Docker containers run as root. If an attacker discovers a Remote Code Execution (RCE) vulnerability inside your app, they are root inside the container, making container breakout attacks significantly easier.

We created an unprivileged system user and switched to it:

RUN useradd --create-home --shell /bin/bash appuser

COPY --chown=appuser:appuser app.py .

USER appuser

We can verify this directly on the running container:

docker exec docker-opt-optimized whoami
# Output: appuser

🏆 The "After": Hardened & Optimized Dockerfile

Here is our final, production-ready Dockerfile.optimized:

FROM python:3.12-slim

WORKDIR /app

# 1. Leverage layer caching for dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 2. Security: Create dedicated unprivileged user
RUN useradd --create-home --shell /bin/bash appuser

# 3. Copy application code with proper ownership
COPY --chown=appuser:appuser app.py .

# 4. Drop root privileges
USER appuser 

EXPOSE 5000

# 5. Production WSGI server
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]

Total lines: 18. Clean, readable, and lightning-fast.

📊 The Scorecard: Baseline vs. Optimized

Metric	Baseline	Optimized	Difference
Base Image	`python:3.12`	`python:3.12-slim`	Streamlined
Content Size	442 MB	56.6 MB	-385.4 MB (-87.2%)
Uncompressed Disk	1.75 GB	256 MB	-1.49 GB (-85.4%)
Extra OS Tools	`curl`, `git`, `vim` (~74 MB)	Zero	Clean runtime
Layer Caching	Broken on every commit	Optimized	Instant rebuilds
User	`root` (UID 0)	`appuser`	Least privilege
Web Server	Dev server	Gunicorn WSGI	Production ready

🥊 Real-World Gotchas & Lessons Learned

Optimization isn't just about shaving megabytes in a spreadsheet—here are real obstacles encountered during the project:

1. The "Host Port Already in Use" Trap

When launching the container:

docker run -p 5000:5000 myapp:optimized
# Error: bind: address already in use

On macOS, port 5000 is frequently taken by the OS AirPlay Receiver service.

Solution: Understand Docker's port mapping format (HOST_PORT:CONTAINER_PORT).

We mapped -p 5001:5000, letting the internal app stay on 5000 while exposing it cleanly on host port 5001.

docker run -d --name docker-opt-optimized -p 5001:5000 docker-image-optimization:optimized
curl http://localhost:5001/health
# {"status":"healthy"}

2. "Disk Usage" vs "Content Size"

When running docker images, Docker may report one size, while docker system df -v or registry push reports another.

Content Size: The compressed size of layers transferred across networks/registries (56.6 MB).
Disk Usage: The uncompressed layer footprint unpacked on the host filesystem (256 MB vs 1.75 GB). Always use consistent metrics when publishing benchmarks!

3. Never Optimize Without Validation

An image with 0 MB size that crashes is useless. After trimming the image, always test both endpoints and run automated test suites:

# Automated tests via pytest
mise exec -- pytest

tests/test_app.py ..                             [100%]
====================== 2 passed in 0.08s =======================

💡 Quick Docker Optimization Checklist for Your Projects

Save this checklist for your next Dockerfile:

[ ] Use -slim or minimal official base images.
[ ] Maintain a .dockerignore containing .git, caches, virtual environments, and tests.
[ ] Copy requirements.txt / package.json before copying application code.
[ ] Remove curl, vim, git, and build tools from final production images.
[ ] Use --no-cache-dir (Python) or --no-cache / clean commands when installing dependencies.
[ ] Create and switch to a non-root USER.
[ ] Replace development servers with production application servers (Gunicorn, Uvicorn, Nginx).
[ ] Validate image behavior with health checks and unit tests.

💬 Over to You!

Have you ever inspected your production Docker images with docker history and found unexpected surprises? What's your favorite trick for shrinking containers? Drop your thoughts in the comments below! 👇

I tried to live an entire day inside apps built with Expo. Here's where it broke.

Dan — Thu, 10 Sep 2026 22:07:28 +0000

There are thousands of apps on the App Store and Google Play running on Expo's open source tooling. That's a big number, but it doesn't tell you much. What I actually wanted to know: do those apps cover a full day, start to finish, without me reaching for anything else on my phone?

So I ran the experiment. One day, Expo apps only. By breakfast I'd paid a celebrity to record a video. By lunch I was generating an app from my phone. By late afternoon I was sweating through a shirt. By bedtime I was too tired to feel smug about any of it.

Short answer: yes, it works. The longer answer is more useful, because the moments where the day fell apart are exactly the moments where somebody should go build something.

Morning

Rise, sleep tracking and energy forecasts
Espresso, news from The Economist
WeatherWise, forecast and live radar
AirNow, air quality index from the US EPA
Delish, recipes with video steps

First app of the day was Rise, a sleep tracker that also predicts when you'll get energy spikes and when your body wants to wind down. Genuinely useful for planning a day this ridiculous.

Next, Espresso, from The Economist. News in small, fast hits, which is the whole premise. Content-heavy apps like this have always been a strong spot for Expo, and it shows: an app like this lives on navigation and linking, which is exactly the job Expo Router is built for.

I needed to know if the weather and air quality would cooperate with my afternoon plans. WeatherWise covered the forecast and live radar, feeling like the pro version of the weather app that already ships on your phone. For air quality I used AirNow, from the US EPA. It gives you the current index and the outlook for the week. The UI could use some attention, and I'll say that plainly, but it works, and there's something quietly great about a federal agency reaching for Expo to help people figure out if it's safe to go outside during wildfire season.

I'm the cook in my house, so I opened Delish for dinner ideas. Hand-picked recipes with real videos and step-by-step instructions, no eight-paragraph story about someone's grandmother sitting on top of the ingredient list. Do not browse it hungry.

The messaging gap

Cameo, personalized videos from celebrities

Normally around here I'd text my wife what I'm making for dinner. This is where the day fell apart, because there isn't really a messaging app built with Expo. We use iMessage, and iMessage was off the table.

The problem with messaging apps is that shipping one isn't enough. Both sides of the conversation need it. I can install an app for myself, but I can't install one on my wife's expectations about how she wants to be reached. That's a real gap in what's out there.

So I got someone else to text her instead. Cameo runs on Expo, and their team has a case study about scaling through a stretch of hyper-growth on it. Cameo is the app where you pay a celebrity to record a personal video for someone. My wife and I watch a lot of Food Network, so I tracked down a Food Network star who could deliver same-day. Was this the intended use case? No. Was it cheap? Also no.

Afternoon

Tesla, navigation and car controls
Tommy's Express, drive-through car wash
Replit, coding with a built-in agent
Mercari, second-hand marketplace

I found a car wash running on Expo, then realized I had no way to get there since there's no Expo maps app either. The Tesla app has navigation built in and also controls the car itself, which solved two problems with one tap.

Once I got there, the Tommy's Express app let me use the car wash without talking to another human. Pull into the lane the app tells you, it reads your plate, it already has your plan and card on file, gate opens. If you're an introvert, this is close to a religious experience.

Then I set up at a cafe to get some actual work done, using the Replit app. A few people in our YouTube comments have asked for a mobile app to check EAS builds and workflows on the go, and this felt like the right day to start one. Replit has a coding agent built in, so I had it generate a first draft.

I also spent some time in Mercari, a second-hand marketplace where people sell the good stuff out of their closets. My feed that day was, for reasons I can't explain, an oops-all-hats situation. Found one that's extremely Silicon Valley coded, so I might go back for it.

Evening

Runna, personalized running plans
Rover, pet sitting and dog walking
Once Upon, printed photo books
Voidpet Garden, self-reflection as a game
Book of the Month, a short list of books to read

I have a race coming up this fall, so I used Runna to track a training run. Tell it a bit about yourself and it writes a personalized plan, whether you're training for your first 5K or something longer. This is where the sweating happened.

After dinner I walked the dog, which reminded me we need a sitter for an upcoming trip. Rover is a genuinely nice app for finding people to look after your pet. When I lived in New York City, finding boarding with actual availability was hard. The sitters I found through Rover were kind enough to my dog that I'd book them again without thinking twice.

I also used Once Upon to turn photos out of my library into a printed book. It has short videos showing what hardcover versus softcover and matte versus glossy actually look like, a detail most apps skip entirely, then let me drag photos around until the layout felt right.

To unwind, I played Voidpet Garden, made by Ben Awad. It turns self-reflection into a game: you catch creatures, tend a garden, fight the occasional battle, and along the way it asks how your day went and how things made you feel. We could use more of that.

Last thing before bed was the Book of the Month Club app. Walking into a bookstore means facing a few thousand choices at once. This trims it to five or seven. I picked one called The Last Contract of Esequibo, mostly for the tagline: "Live by the code or die by the knife." Felt about right for development life these days.

Loose ends

Three things resolved after the day was already over.

The Cameo video didn't arrive that evening. Celebrities, it turns out, have schedules. It showed up a few days later, we loved it, and now I owe my wife that dinner all over again.

The photo book arrived, and it's genuinely nice.

And the EAS companion app I started in Replit made real progress. I showed it around internally, more people got excited than I expected, and we're now actively working on it. Expect something to look at later this year.

What the gaps tell you

The three places the day broke were messaging, maps, and camera, and they're really the same gap wearing different clothes.

Messaging is hard because it needs two people to adopt it at once. Maps and camera are hard for the opposite reason: your phone already ships with a good-enough version, and good-enough is genuinely difficult to beat. Which is exactly why these categories are worth building into.

One of the goals at Expo is letting more people build for mobile. The screen in your pocket is the one most of us stare at all day, for better or worse, and everyone should be able to build for it.

Start something

If one of those gaps sounds like your idea, here's the whole path in: the getting started guide walks you to a build on a real device, and EAS Build takes it to the app stores without you ever opening Xcode or Android Studio. If you get stuck along the way, come find us in Discord.

This post is based on content from the Expo blog. Follow @expo for more React Native content.

Metrice: Zero-dependency post-quantum P2P mesh network

Ahmet Göktürk — Thu, 10 Sep 2026 22:06:31 +0000

Metrice is a decentralized peer-to-peer (P2P) mesh networking protocol engineered with zero external npm dependencies (Zero-Dependency), running natively on Node.js core libraries (node:crypto, node:net, node:dgram, node:sqlite, node:dns). It features quantum-resistant cryptography (Post-Quantum Cryptography) and a Tor-like multi-hop onion routing architecture.

The system incorporates NIST FIPS 203 ML-KEM-768 key encapsulation, Ed25519-based RFC 4648 Base32 cryptographic node identities, AutoNAT dialback consensus, Rendezvous persistent reverse tunnels for CGNAT traversal, multi-relay transit bridging (EDGE Transit Routing / CAP_EDGE_TRANSIT), Layer 4 HAProxy PROXY Protocol v1 & v2 support, and an embedded in-memory SSH-2 server.

Architecture & Core Components

1. Cryptographic Node Identity & Addressing

Every node maintains a persistent Ed25519 identity key pair.
The 16-character Node ID (NodeID) is derived from the first 10 bytes (80 bits) of the SHA-256 digest of the raw Ed25519 public key encoded in RFC 4648 Base32 (^[a-z2-7]{16}$).
Network addressing is completely IP/Port agnostic using virtual .mesh domain namespaces:
- User Address: @user:NodeID.mesh
- Federated Channel: #channel:NodeID.mesh
- Global Mesh Channel: #genel

2. AutoNAT & Reachability Consensus

Nodes exchange their observed peer addresses (observedAddress) during the cryptographic handshake.
A Reflected Public IP consensus is established once at least two independent peers report consistent observations.
Nodes initiate reachability testing by transmitting a DIALBACK_REQUEST containing a cryptographic nonce.
The target peer attempts a TCP dialback connection to the requesting node's physical remote address (socket.realRemoteAddress || socket.remoteAddress). If verified, the node attains the CAP_RELAY role; otherwise, it remains in CAP_EDGE.
SSRF Defense: Injected targetIp values inside DIALBACK_REQUEST are strictly discarded; only the verified physical TCP socket remote address is used. Dialbacks targeting RFC 1918 private networks or loopback addresses are blocked.

3. Rendezvous, CGNAT Reverse Tunnels & Transit Routing (CAP_EDGE_TRANSIT)

Firewalled or CGNAT-bound EDGE nodes establish persistent reverse TCP tunnels to multiple publicly reachable RELAY nodes (maxEdgeRendezvousRelays, default: 4).
Tunnel sessions are authenticated via Ed25519 cryptographic signatures in RENDEZVOUS_BIND packets.
Firewall session state is preserved through 30-second single-byte keepalives: 0x09 (PING) and 0x0A (PONG).
Active tunnel capacity per relay is bounded to 64 to prevent resource exhaustion (maxRendezvousTunnels).
Dynamic Role Escalation (CAP_EDGE_TRANSIT): An EDGE node connected to at least two independent relays with ALLOW_EDGE_ROUTING=true dynamically ascends to CAP_EDGE_TRANSIT, enabling bidirectional in-and-out reverse tunnel bridging between segmented relays.
Loop-Free Gossip Bridging: Transit edge nodes cross-bridge presence announcements (PRESENCE_ANNOUNCE) and global #genel messages between relays without broadcast loops (ALLOW_EDGE_GOSSIP=true).

4. 3-Hop Telescopic Post-Quantum Onion Routing

Anonymous 3-hop circuits (Inbound Guard, Relay/Transit, Outbound Exit) conceal network topology and packet trajectories.
The circuit selection pool (relayPool) integrates both backbone RELAY nodes and CAP_EDGE_TRANSIT nodes to enhance routing diversity.
Each hop negotiates ephemeral symmetric keys via NIST FIPS 203 ML-KEM-768 (Kyber-768) key encapsulation.
Traffic Analysis & DPI Resistance: All onion cells (ONION_CELL) are padded to a strict uniform length of 2048 bytes (Uniform Cell Padding). Raw payloads are capped at 768 bytes (MAX_ONION_PAYLOAD).
Cells are never exposed in plaintext; transport is secured inside AES-256-GCM ENCRYPTED_FRAME blocks.

5. Distributed Presence & SQLite Routing

Presence and channel subscriptions are propagated across the mesh using Ed25519-signed PRESENCE_ANNOUNCE gossip packets.
Raw IP addresses are scrubbed from gossip frames; announcements reference only virtual domain names or .mesh identifiers.
Ephemeral routing entries are cached in memory and committed to the SQLite routing_table. Inactive records expire automatically after 60 seconds (TTL).

6. In-Memory SSH-2 Server & Two-Factor Vault Authentication

Pure JavaScript SSH-2 server operates natively without requiring external system daemons (sshd).
Dynamic Version Synchronisation: Server identification string (sshServerVersion) dynamically aligns with package.json through src/version.js (default: SSH-2.0-Metrice_2.6.0) and remains configurable via environment variables.
Two-Factor Ephemeral Vault Derivation: User passwords are salted with the client's Ed25519 public key and derived via Scrypt (N=16384, r=8, p=1) and HKDF-SHA256. Authentication fails without the registered physical Ed25519 key, even if the password is correct.

7. Layer 4 HAProxy PROXY Protocol v1 & v2 Support

Nodes operating behind Layer 4 reverse proxies (HAProxy, Nginx Stream, AWS NLB) transparently resolve real client IP addresses and ports (realRemoteAddress, realRemotePort) with USE_PROXY_PROTOCOL=true.
Supports both US-ASCII text PROXY v1 (PROXY TCP4/TCP6/UNKNOWN) and 12-byte binary magic PROXY v2 with zero external libraries.
IP Spoofing Immunity: Only proxies specified in PROXY_TRUSTED_IPS (default: 127.0.0.1,::1) are authorized. Unauthorized spoofing attempts are instantly rejected with immediate socket termination (status: REJECT).
Transparent Passthrough: Direct connections without PROXY headers have unparsed bytes restored (socket.unshift(remainder)) and route seamlessly to federation, SSH, or Telnet handlers with zero data loss.

To see the full installation guide, deployment models, and deployment via Docker, check out the official repository:

Full Documentation & Source Code: https://github.com/GokturkA1/metrice

Automating Pull Request Workflows with Claude Task Master

developerz.ai — Thu, 10 Sep 2026 22:05:30 +0000

Introduction

Developers spend a lot of time managing pull requests, fixing CI failures, and responding to review comments. Claude Task Master provides a command line interface that automates this entire loop. By giving the tool a high level goal, it plans the work, writes code, pushes commits, opens a pull request, handles CI, addresses feedback, and merges when all checks pass.

How It Works

The CLI reads the repository, creates a task list, and defines success criteria before any code is changed. Each task is executed in isolation: the tool makes the required modifications, runs the test suite, and creates a commit. After the commit is pushed, a pull request is opened automatically. The pull request enters the CI stage; if any checks fail, Claude Task Master updates the code, runs the tests again, and pushes a new commit. Review comments are fetched via the GitHub API, and the tool can apply suggested changes without human intervention. When the pull request passes all checks and receives approval, the tool performs an auto merge.

Benefits

Hands off - set a goal and let the tool run until the pull request is merged.
State persistence - the CLI stores its progress on disk, so a stopped session can resume exactly where it left off.
Profile isolation - multiple Claude subscriptions can be used in parallel by creating separate profiles, each with its own configuration directory.
Extensible integration - a REST API, an MCP server, and signed webhooks expose the same lifecycle to external systems, enabling custom dashboards or CI pipelines.

Example Usage

# Install the CLI (uv, pip, or Docker are supported)
uv tool install claude-task-master

# Authenticate with Claude Code
claude login

# Run a task in your project directory
cd my-project
claudetm start "Add user authentication with tests"

The command above creates a plan, writes the authentication code, adds tests, pushes the changes, opens a pull request, and watches the CI pipeline. If the CI fails, the tool fixes the issue and pushes a new commit. Once the pull request is approved, it merges automatically.

Integration Points

Claude Task Master can be invoked from other tools via its REST API. For example, a CI job can POST a JSON payload with a goal description, and the server will start a new task. Webhooks can be configured to notify a Slack channel when a pull request is merged or when a CI failure occurs. The MCP server provides a lightweight message queue for coordinating multiple instances of the CLI.

Conclusion

Automating the pull request workflow reduces manual overhead and speeds up delivery. Claude Task Master combines planning, execution, and verification in a single tool that works with the Claude Code session or a direct Anthropic compatible API. It is open source under the MIT license and can be installed via PyPI or Docker. Try it today and see how a fully autonomous pull request loop can improve your development process.

Repository: https://github.com/developerz-ai/claude-task-master

DEV Community

From "show me your code" to "show me your idea"

From "show me your code" to "show me your idea"

J'ai procastiné Docker pendant un mois... Voici ce qui m'a débloquée

Le déclic : comprendre en construisant

Les galères (et ce qu'elles m'ont appris sur Docker)

Git 403 : mon premier mur

Des logs qui n'existaient pas

Alpine n'est pas Ubuntu

La faute de frappe qui m'a coûté une heure

Ce que je retiens vraiment

Le rôle du mentorat

Ce que je dirais à la moi d'il y a 30 jours

Pour finir

[Boost]

Automate Flutter Releases with Shorebird + GitHub Actions (Skip App Store Review)

Automate Flutter Releases with Shorebird + GitHub Actions (Skip App Store Review)

Prerequisites

Authentication Setup

Official Shorebird GitHub Actions

Release Workflow

Patch Workflow — The Real Power

Recommended Development Workflow

Best Practices

Resources

NBA play-in odds are not playoff odds: simulating the play-in tournament instead of guessing it

Three zones, not two

Simulate the games, don't approximate them

Basketball-specific modelling choices

A September snapshot

The number I don't trust

One market-side detail worth copying

Try it

NHL playoff odds for 2026-27: 84 games, the wild card rule, and why I don't trust my own model in September

1. Standings run on points, not wins

2. The playoff field is not "the top eight"

3. Overtime is closer to a coin flip

4. The season is 84 games now

What the model says right now

Why I don't believe it (yet)

The fee changes which gaps matter

Watching it move

Try it

Correct score, BTTS and Over/Under probabilities with Dixon-Coles: what I learned building it for MLS and Liga MX

The starting point: independent Poisson

The Dixon-Coles correction

Two things the paper adds that tutorials often skip

Where the data comes from

What one prediction looks like

The awkward case: promoted teams

What it doesn't do

Try it without writing the model

I Asked a Frontier LLM to Recover Secrets from My Decompiled Build

The master key ships inside the binary

Making the relationships harder to discover

Three implementations must agree byte for byte

An adversarial court

What counts as independent evidence

What the blind attempt established

How I Slashed a Docker Image from 442 MB to 56 MB (87% Cut) and Hardened It for Production

🛑 The "Before": A Naive, Bloated Baseline

What Went Wrong Here?

🛠️ The 6-Step Optimization Playbook

Step 1: Switch to a Minimal Base Image (-slim)

Step 2: Ruthlessly Prune Unnecessary OS Packages

Step 3: Add a Scrupulous .dockerignore

Step 4: Master Layer Caching (Order Matters!)

Step 5: Adopt a Production WSGI Server (Gunicorn)

Step 6: Hardening Security — Run as Non-Root

🏆 The "After": Hardened & Optimized Dockerfile

📊 The Scorecard: Baseline vs. Optimized

🥊 Real-World Gotchas & Lessons Learned

1. The "Host Port Already in Use" Trap

2. "Disk Usage" vs "Content Size"

3. Never Optimize Without Validation

💡 Quick Docker Optimization Checklist for Your Projects

💬 Over to You!

I tried to live an entire day inside apps built with Expo. Here's where it broke.

Morning

The messaging gap

Step 1: Switch to a Minimal Base Image (`-slim`)

Step 3: Add a Scrupulous `.dockerignore`