u/mgyk1024

Har hållit på med det här på fritiden ett bra tag. Bakgrunden är att jag några gånger försökt kolla upp hur partierna röstat i en fråga och gett upp, för riksdagens egen data är i princip oläslig om man inte redan kan hur det funkar.

Exempel: voteringen om TBE-vaccin i februari förra året. Den heter "TBE". Förslagstexten är "Riksdagen avslår motionerna 2024/25:541 av Adrian Magnusson m.fl. (S), 2024/25:713 av Daniel Persson (SD)..." och så fortsätter det i tio rader till. Vad handlade det om? Vad innebar ett ja? Ingen aning utan att öppna betänkandet och läsa.

På airiksdagen.se står det istället att frågan gällde om TBE-vaccin ska in i det nationella vaccinationsprogrammet redan nu, eller om man ska vänta in Folkhälsomyndighetens pågående arbete. Ja betyder avslå motionerna, alltså som idag. Nej betyder att ställa sig bakom S reservation. Och så hur alla faktiskt röstade: M, KD, L, SD och C ja, S nej, V och MP avstod.

Sånt finns för samtliga 2 539 voteringar under mandatperioden. Man kan söka fritt på ämne, typ "färdtjänst" eller "eget boende", och filtrera på utskott, månad och politikområde. Källänk till riksdagen på varje ärende så man kan kolla att jag inte hittat på något.

Gratis, ingen reklam, ingen tracking, ingen inloggning. Kod och data ligger öppet.

Det finns även en AI-grej som jämför hur partierna röstat med vad de skrivit i sina egna valmanifest. Den delen är betydligt osäkrare och täcker bara 675 av voteringarna, så ta den med en nypa salt. Förbehållen står på sidan.

Om ni hittar ärenden där sammanfattningen är fel eller vinklad vill jag gärna veta. Det är den sortens fel jag har svårast att upptäcka själv.

(Eget hobbyprojekt, ingen finansiär, inget parti inblandat.)

I spent about the last ten years on one fleet of first-gen industrial devices. We started shipping them in 2015 and we're only swapping them out now, in 2026, which I'm honestly a bit proud of. And the thing is they're basically fine. Hardware's fine, firmware's fine, they'd keep going for years. We're replacing them because 3G is going away and a box that can't reliably get online isn't much use, that's the whole reason. So some of how long a device lasts you just don't control, the network underneath it can die before the device does. But the ten years of actually keeping the fleet running and debuggable, that was on me, and it was nearly all software.

The worst one was small and stupid. We wanted to debug a device out in the field without messing with production, so we set up a staging environment with its own endpoint and built a separate staging firmware that pointed there. Fine, sensible, whatever. Except now you've got two firmware builds floating around and you absolutely cannot put the staging one on a prod device or the other way round, so we wrote a pile of code to check the build matched the device and refuse if it didn't. Then spent forever fixing the corners of that check, because there's always another corner. And after all of it the thing still wasn't clean and still wasn't even much good for actually debugging anything.

The whole thing only existed because the endpoint lived in the firmware. One build, one endpoint, every device pointed at the same place. So I needed a second build to point staging somewhere else, and then code to stop the two builds getting flashed to the wrong devices. None of which I'd have needed if each device just had its own endpoint to begin with.

So we flipped it. Each device gets its own endpoint I can change without touching firmware, and the second build just evaporates. One firmware everywhere. Want to poke at one unit, you send that one device to staging and nobody else moves, there's nothing to cross-flash because there's no second build to cross. The way it actually shakes out is DNS, every device is {id}.gw.example.com, a wildcard points them all at the main gateway, and if I want to peel one off I drop in a single record just for it. We ended up wiring that into our own UI too, so it's not me running a script at 2am anymore, support or one of the engineers can grab a unit into debug or shove a whole test fleet onto another cluster themselves.

And the annoying thing is hardcoding the endpoint was a perfectly fine call on day one. Worked great for a year. It just quietly decided the shape of a bunch of pain later, including a whole staging-firmware contraption I never actually needed.

Most of my mistakes there were that shape. Something reasonable at the start that slowly turns into a tax. Another one, I learned to stop believing what a device says about itself and just watch what shows up at the backend. When one dies outright it's easy, it goes quiet, you notice. It's the half-dead ones that get you, a unit cheerfully reporting itself healthy while its message count had drifted from a thousand-ish a day down to a couple hundred and nobody clocked it for a month. So now I watch what arrives, volume and freshness and reconnects, sliced by firmware and carrier, because a flat 5% errors across the whole fleet is nearly always one bad build dying on one carrier while everything else is fine.

Oh and the self-own classic. Give every device a good clock and a 60 second interval and they'll all phone home on the same second and you'll DoS your own gateway with traffic you generated yourself. Jitter it, gone. Same trap on reconnect after the gateway blips, everything that was waiting comes back at once unless you put jitter in the backoff too, otherwise the recovery is just the next outage. Thundering herd, except the herd is bolted to walls in places you can't ssh into.

Anyway, I wrote the whole list up on my blog, it's my own link so fair warning: https://mooracle.io/blog/building-iiot-that-lasts

Curious what the backend or distributed version of this is for people here. The decision that was genuinely fine on day one and turned into something you've been paying off ever since. Mine was a hardcoded endpoint.

AI assistants emit token counts on every API response, and rates are published per model. None of that reaches the commits the assistant helped produce — you lose the link between API spend and the work that caused it.

One capture approach: prepare-commit-msg writes per-commit AIC (GitHub's AI Credits) as a git trailer. Git extracts trailers by name git log --pretty='%(trailers:key=...), so the cost per PR/feature is a one-liner you can drop into CI.

How are teams handling AI cost attribution today? Where does the data live, and how are you slicing it?

Full write-up in the article - trailer format, cost hotspots as investment signals, and where it falls short. Links out to a VS Code Copilot example connector at the end:

https://mooracle.io/blog/finops-ai-planning-poker

June 1 moves every plan to usage-based AI Credits. GitHub's budgets show who spent. Not what for. Built a VS Code extension that appends trailers on commit:

  Copilot-Est-Cost: $0.41
  Copilot-Model: claude_sonnet_4 18200/6800/4.00

Format = input/output/premium_requests - same units AI Credits will bill on.
git log --grep=Copilot-Est-Cost = cost per feature.

Local only, MIT.