DEV Community: Pentine Pejay

The Cold and Hard Log

Pentine Pejay — Sat, 17 Oct 2026 17:26:06 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

Dede Mensah sells cheese. One display fridge out front, one walk-in in the back,
and a clipboard screwed to the wall next to each. Twice a day she writes down a
temperature. The UK Food Standards Agency scheme she trades under (Safer Food
Better Business, the retail HACCP flavour) says she has to: monitor the cold
points, record them, act when something goes out of range. The clipboard does
none of that between the two times she looks at it. If the display fridge drifts
warm at 2pm and she checks at 9am and 5pm, the paper says everything was fine.

Dede is a composite. I did not have a real cheesemonger to hand during the build
window, so I built for a specific made-up one with a real, legally-driven
problem. The HACCP obligation is not invented. The clipboard gap is not
invented. That is the part worth solving.

What I Built

Baridi turns a fridge sensor stream into two things Dede's clipboard cannot give
her: a breach timeline and an alert that does not lie.

The name is Swahili. "Baridi" means cold, and it is the everyday word for the
weather being chilly or a drink being cold, so it names exactly what the tool
watches: is the cold still cold? That fits the Side Hustle theme too. This is
built for the person running the whole shop alone, the cheesemonger who is also
the buyer, the cleaner, and the compliance officer. Baridi is the extra pair of
hands that watches the fridge overnight so the side hustle does not fail its
inspection over a thing nobody was awake to see.

Replay a day of readings and you get the timeline. Every stretch where the
temperature stayed over 5C for at least ten minutes shows up as an excursion
with its start, end, duration, and peak. A headline sums it: "2 excursions over
5C, 43 min total." The alert side writes one record per distinct excursion, and
it keeps writing correctly even if the process running it is killed halfway
through.

Who pays for this? A one-person food business already pays, in time and in risk.
The clipboard is unpaid labour that still leaves a hole an inspector can see.
The commercial fix is a subscription HACCP-logging service, priced monthly,
holding your readings on someone else's server. Baridi is the local version: the
readings stay in the shop, there is no per-reading fee, and the breach math is
inspectable. For a margin-thin cheese counter, local and $0-per-reading is the
difference between doing it and not.

Demo

Live: baridi.tech. The breach timeline runs there against
a real TimescaleDB, served over HTTPS. The dashboard is at
baridi.tech/dashboard.

Here is the timeline as Dede sees it. A FAIL status for the day, the two
excursions each drawn against the 5C line, with the peak temperature and minutes
over called out. You can switch sensors and days, and the footer reports the live
dataset size and the measured query time:

And the day she wants. Every sensor held at or below 5C, a PASS / all-clear state
instead of a wall of green-wash:

The same data as raw API output (curl https://baridi.tech/api/timeline):

{
  "day": "2026-10-12",
  "threshold_c": 5.0,
  "sustain_minutes": 10,
  "headline": "2 excursions over 5C, 43 min total",
  "excursions": [
    {"sensor_id": "fridge-01", "start": "2026-10-12T10:04:00+00:00",
     "end": "2026-10-12T10:35:00+00:00", "minutes_over": 32, "max_temp": 9.404},
    {"sensor_id": "fridge-01", "start": "2026-10-12T17:04:00+00:00",
     "end": "2026-10-12T17:14:00+00:00", "minutes_over": 11, "max_temp": 7.11}
  ],
  "disclaimer": "A logging and alert aid, not a certified compliance record."
}

The first excursion is a door left open: a 32-minute climb peaking at 9.4C mid
morning. The second is a defrost cycle: 11 minutes peaking at 7.1C. A third
event, a single-minute spike to 9.87C at 05:00, is in the data on purpose and
does not appear here, because ten minutes of sustain is the rule and one minute
is not a breach.

The kill-and-resume proof. This is the one that matters for a logging tool,
because a logger you cannot trust after a crash is worse than paper. The alert
activity was given a 25-second delay so I could kill its worker after the breach
was detected but before the alert was written, then restart a fresh worker.

time (UTC)	event
21:01:20.590	worker A started (25s alert delay)
21:01:24.595	workflow submitted
21:01:25.301	worker A: alert started for the 10:04 excursion, not yet written
21:01:25.614	worker A killed with `kill -9` mid-alert; nothing is running
21:01:25.617	alerts.log line count while down: 0 (the alert was not written before the crash)
21:01:30.623	worker B restarted, no delay
21:01:56.316	Temporal redelivers the activity; the alert fires, about 31s late
21:01:56.544	final alert count: 2, one per excursion, none lost, none doubled

The alert arrived late, not lost, and it did not fire twice. Final log:

{"key": "fridge-01:2026-10-12:2026-10-12T10:04:00+00:00", "minutes_over": 32, "max_temp": 9.404, ...}
{"key": "fridge-01:2026-10-12:2026-10-12T17:04:00+00:00", "minutes_over": 11, "max_temp": 7.11, ...}

This proof is on the site too, at baridi.tech/durability,
shown as a recorded test rather than a live action:

Naive row-scan vs continuous aggregate. The breach math has a dumb version
(pull every raw row, stitch in Python) and the TimescaleDB version (read a
continuous aggregate, group in SQL). On one clean day they agree exactly and the
naive one is a touch faster, because 1440 rows is nothing:

naive row-scan:            best of 5 runs 4.08 ms
continuous-aggregate:      best of 5 runs 4.52 ms
paths agree on breaches:   True

That is the honest toy-scale result. A compliance log is not one day, though. It
is months across several fridges. Loaded to 1,038,240 readings, the same
single-day query tells a different story in the plan:

NAIVE single-day:  Buffers: shared hit=5782   (hands 5760 raw rows to Python)
HEAVY single-day:  Buffers: shared hit=59      (returns 4 finished rows)

About 98% fewer page reads, and the breach detection happens in the engine
instead of in a Python loop. Wall-clock is 14.96 ms vs 19.63 ms, a 1.31x
single-day speedup at that volume. Adding one new day to the million-row history
refreshes only that day's buckets in 1.27s, not a full rebuild.

The time_bucket SQL that produces the timeline:

CREATE MATERIALIZED VIEW readings_1min
WITH (timescaledb.continuous) AS
SELECT sensor_id, time_bucket('1 minute', ts) AS bucket,
       max(temp_c) AS max_temp, avg(temp_c) AS avg_temp
FROM readings
GROUP BY sensor_id, time_bucket('1 minute', ts);

Excursions come from a gaps-and-islands query over that view: flag each minute
over or under threshold, open a new island on each change of state, keep islands
that last at least the sustain window. Full query and plans are in NOTES.md.

Code

kiprutopentine / ColdLedger

Baridi

A cold-chain temperature stream becomes a breach timeline and a durable alert log. Replay a day of fridge readings, see every excursion over threshold with its start, end, duration, and peak temperature, and get an alert that survives a worker crash without firing twice or losing a reading.

Baridi is a logging and alert aid, not a certified compliance record.

What it does

Ingests a time-series of temperature readings into TimescaleDB as a hypertable.
Computes sustained excursions with a continuous aggregate (time_bucket) and an engine-side gaps-and-islands query, not a raw row scan.
Runs a durable Temporal workflow that ingests, checks, and alerts, with an idempotent alert keyed by {sensor_id}:{day}:{excursion-start}.
Shows the day's breach timeline on a one-page UI.

Prerequisites

Docker (for TimescaleDB)
Python 3.12 with venv
Temporal CLI (temporal server start-dev) for the durable workflow. Not needed for the offline durability proof.

Setup

python3

…

View on GitHub

How I Built It

  data/day.jsonl  (1440 readings, injected excursions)
        |
        v
  +----------------+        +---------------------------+
  |  Temporal      |        |  TimescaleDB              |
  |  workflow      | -----> |  readings (hypertable)    |
  |  (deterministic|ingest  |  readings_1min (cont. agg)|
  |   body)        |        +---------------------------+
  |     |          |                 |
  |     | check    | <---------------+  excursions(day) in SQL
  |     v          |
  |  activities    |        +---------------------------+
  |  (side effects)| -----> |  data/alerts.log          |
  |  idempotent    | alert  |  (one line per excursion) |
  |  alert         |        +---------------------------+
  +----------------+
        |
        v
  FastAPI /api/timeline  -->  breach timeline, served at baridi.tech

The split is deliberate. The Temporal workflow body is deterministic: it reads
no clock except workflow.now(), touches no disk, and makes no network call
itself. Everything with a side effect (writing readings, running the excursion
query, firing an alert) is an activity. That is what lets Temporal replay the
workflow history after a crash and land in the same place.

The alert activity is the careful part. Its key is
{sensor_id}:{day}:{excursion-start}, it checks a persisted seen-set before
firing, and it records the key with an atomic os.replace before appending the
human-readable line. A crash between the two still leaves the key marked seen,
so a resume cannot double-fire.

There is no AI model in the critical path, and that is on purpose. The breach
decision is arithmetic: temperature over threshold, sustained past a window. A
model surfaces nothing the code cannot verify, so the code owns the facts. I
left a hook for an optional blip-vs-breach model and then did not wire it,
because the sustain window already rejects the single-minute spike that a model
would have been asked to catch. Shipping the model anyway would have been
decoration.

The live site runs on an open stack end to end: the FastAPI app behind Caddy for
automatic HTTPS, TimescaleDB in a container, and the breach query in SQL. It is
hosted on a .tech domain, baridi.tech, with the
TimescaleDB bound to loopback and the public API rate-limited.

Why Does Open Innovation Matter?

Dede's readings are her own compliance liability. They are the record an
inspector asks for and the record that protects her if a customer complains.
That record should not live behind someone's subscription, on someone's server,
billed per reading.

Baridi runs on open parts end to end: TimescaleDB in a container, Temporal's open
dev server, a Python stack. The readings never leave the machine. There is no
per-reading cloud fee. The breach math is a SQL query she or her inspector can
read, not a vendor's black box.

Honest limits, stated plainly. Baridi is a logging and alert aid, not a certified
compliance record, and the UI says so. The 1.31x database win is real but modest
at one day; the stronger case is buffer reads and incremental refresh at real
volume, and I would not claim otherwise. The data is synthetic, generated by a
seeded script, and the write-up says where. The blip-vs-breach model is deferred,
not hidden: the sustain window did the job, so the model stays out. A closed API
could have done the arithmetic too, but it could not have kept the readings in
the shop for free, which is the whole point.

Prize Categories

Best Use of Temporal: the breach alert is one idempotent activity per excursion, and a worker killed mid-alert resumes and fires it about 31 seconds late without losing it or firing it twice, proven by a timestamped table and an offline idempotency test.
Best Use of Tiger Data: the excursion timeline is computed by a time_bucket continuous aggregate and an in-engine gaps-and-islands query that, at a million readings, reads about 98% fewer buffers than a raw scan and returns finished excursions instead of raw rows.
Best Use of a .tech Domain: the project is live at baridi.tech, the breach timeline served over HTTPS from the real TimescaleDB-backed app. The domain fits the product by meaning, not just by availability. "Baridi" is Swahili for cold, the plain word for a chilly day or a cold drink, so baridi.tech reads as "cold, built in tech": a cold-chain tool that watches whether the cold is still cold. The name carries the one question the product answers, and the .tech domain puts it in the address bar.

An 80-second browser freeze in Zulip's Manage channels, fixed by killing quadratic DOM work

Pentine Pejay — Fri, 21 Aug 2026 19:06:01 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

Zulip is an open-source team chat application: a Django backend and a TypeScript web client built on jQuery. The "Manage channels" overlay lists every channel you can see, with live search, sort, and filter. Each keystroke or filter change re-sorts the list in place.

Bug Fix or Performance Improvement

I fixed issue #39755. On a server with about 331 channels, opening Manage channels (or the #channels/new view, or the All tab) makes the tab unresponsive for roughly 80 seconds. Chrome shows the "Page Unresponsive" dialog. The reporter's Chrome CPU profile pinned about 90% of the freeze on two DOM operations, removeChild and querySelectorAll, triggered through the bundled jQuery.

The code is redraw_left_panel() in web/src/stream_settings_ui.ts, which sorts the list by moving DOM rows into their new order. The re-append loop looked like this:

for (const stream_id of all_stream_ids) {
    const $widget = widgets.get(stream_id);
    scroll_util
        .get_content_element($("#channels_overlay_container .streams-list")) // re-queried every iteration
        .append($widget);
}

The problem is the $("#channels_overlay_container .streams-list") inside the loop. That is a document-wide querySelectorAll, run once per channel. A querySelectorAll forces the browser to flush pending layout, so every one of the N appends triggers a full re-layout of the list. Detaching and re-appending N rows with a forced reflow each time is O(n²). With a few hundred rows, that is the 80-second freeze, and it matches the profile exactly: removeChild from the per-row detach, querySelectorAll from the per-row re-query.

Code

PR: https://github.com/kiprutopentine/zulip/pull/1

The fix, in redraw_left_panel():

// Query the content element once, before the loop.
const $content_element = scroll_util.get_content_element(
    $("#channels_overlay_container .streams-list"),
);

// ...scan .stream-row a single time, set classes, detach rows...

// Re-append each row into the CACHED element. The original re-queried the
// content element here on every iteration; that document-wide querySelectorAll
// forces a synchronous layout flush of the pending append, so each row paid a
// full reflow. Caching it removes the forced layout, and one append form keeps
// the change lint- and mock-compatible with the existing test.
for (const stream_id of all_stream_ids) {
    const $widget = widgets.get(stream_id);
    assert($widget !== undefined);
    $content_element.append($widget);
}

Three changes: query the content element once (this removes the per-row querySelectorAll and the forced synchronous layout it caused), scan .stream-row a single time instead of twice, and re-append each row into that cached element instead of re-looking it up every iteration. The ordering, the notdisplayed classes, and the function's return value are all unchanged, so behavior is identical, only the DOM work drops from O(n²) to O(n).

My Improvements

I kept the change inside the existing function and its jQuery idiom rather than rewriting the overlay. That was deliberate: Zulip's frontend tests run against a jQuery mock (zjquery) whose elements are not real DOM nodes, so a raw DocumentFragment reorder would pass in the browser but break the test suite. Staying on .detach() / .append() keeps the existing redraw_left_panel test valid, which already asserts the sorted order across search, sort, and filter cases.

Removed the per-iteration content-element lookup, the O(n²) driver: a document-wide querySelectorAll that forced a synchronous layout flush of the pending append on every row.
Collapsed two .stream-row scans into one.
Kept the plain .append($row) form, so the change is behavior- and lint-identical to the original and compatible with Zulip's zjquery test mock (a raw DocumentFragment reorder would pass in a browser but break the mock, whose elements are not real DOM nodes).

Verification: I provisioned a full Zulip dev environment on a throwaway cloud VM and ran Zulip's own tooling against the fix:

./tools/test-js-with-node stream_settings_ui → test: redraw_left_panel passes ("Test(s) passed. SUCCESS!").
./tools/run-tsc clean.
./tools/lint --only=eslint,prettier web/src/stream_settings_ui.ts clean.

The change is behavior-preserving (same order, notdisplayed classes, return value), so that existing test, which pins ordering across search, sort, and filter cases, passes unchanged.

Best Use of Sentry

This is a performance bug with zero exceptions, so error monitoring alone would never see it. I used Sentry's performance tooling to make the cost visible and to prove the fix.

I built a benchmark harness (@sentry/browser via the loader script) that rebuilds the exact redraw both ways against N real .stream-row nodes and wraps each run in a Sentry span named manage_channels.redraw_left_panel (op: ui.render):

OLD detaches each row and re-appends one at a time, re-querying the content element every iteration (forcing a synchronous layout per row): O(n²).
NEW queries the content element once and re-inserts in a single batch: O(n).

Measured in the harness, which is deliberately minimal (plain rows) so the numbers isolate the algorithm itself rather than Zulip's full per-row render cost:

channels	OLD (buggy)	NEW (fixed)
331	115.8 ms	3.7 ms
1000	477.4 ms	7.3 ms
2000	2340.4 ms	15.1 ms

OLD grows super-linearly, close to quadratic at the larger sizes: doubling the list from 1000 to 2000 channels roughly quintuples the time. NEW scales linearly and stays in the low milliseconds. At 2000 channels the redraw drops from 2.3 seconds to 15 ms, about 155x. In the production overlay each row is far heavier (real templates, jQuery, the scroll container), so the same pattern is what turns "a few hundred channels" into the reporter's ~80-second freeze instead of a fraction of a second. The harness proves the mechanism and the fix; the 80 seconds is the real-world symptom of it.

Performance / tracing: the OLD run does not just take longer, it blocks the browser's main thread. Sentry's tracing recorded it as a ui.long-animation-frame — Main UI thread blocked span (about 1.3 s in this trace), exactly the kind of long task that makes the tab unresponsive. The NEW run produces no such block.

Each run is tagged with its channels count and its kind (old/new), so the regression is visible inside Sentry, not just in the console. Filtering the manage_channels.redraw_left_panel transactions shows the fixed runs sitting in the low milliseconds (4–30 ms) while the buggy runs climb with the channel count, from ~100 ms up past 2 seconds, and beyond 17 seconds on a larger list. Sentry is not just recording one slow event; it shows the shape of the algorithm, and that the fix flattens it.

Session Replay: the replay of the OLD run shows the list locked and unresponsive; the NEW run is instant.

Three Sentry surfaces carried this fix: tracing timed each redraw as a ui.render transaction and plotted the cost curve as the channel count grew, its long-animation-frame detection flagged the blocked main thread on its own, and Session Replay captured the freeze the way a user feels it. Run it yourself, the harness is public at https://github.com/kiprutopentine/sentry

Dog Passport: a soulbound vaccination record your vet signs, on Solana

Pentine Pejay — Sun, 16 Aug 2026 19:45:59 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

Dog Passport turns a dog's vaccination and pedigree record into a
non-transferable Token-2022 on Solana that the issuing vet signs with their own
keypair.

A boarding kennel, groomer, border agent, or a new owner can open the passport,read it straight from the chain, and see two things at once: the dog's details,and whether the record was really signed by a known vet. No app account, no central server to trust, no company that can shut down and take the records with it. The token is soulbound, so it stays bound to the dog and cannot be sold or swapped like an NFT.

The problem is small and real. Paper vaccination cards get lost right when you need them for boarding or travel. Pet-record apps die with the company that made them. Breeders hand over pedigrees you have no way to check. A vet-signed on-chain record fixes the parts that hurt: it is portable, tamper-evident, and outlives any single vendor.

The passport carries a photo, passport number, owner, breed, date of birth, colour, microchip, the vaccination history, and the issuing vet's key. Every one of those fields, including the photo, is covered by the vet's signature.

Demo

Live (Solana devnet, no wallet or setup needed):

App: https://bosco-eta.vercel.app

bosco-eta.vercel.app

Open a passport directly: https://bosco-eta.vercel.app/?mint=52SP5ACC7m8BwnWge1CX3DyidhfBXWLxAz9yNdS2sf3G

The landing page has a gallery of five real dogs plus two test states, so you can click through every verification outcome:

Authentic — signed by a trusted vet. Green "VERIFIED" stamp, all checks pass.
Untrusted issuer — a valid signature from a vet who is not in the trusted list. Amber stamp.
Tampered — a field was altered on-chain after signing, so the signature nolonger matches. Red "INVALID" stamp.

The viewer renders a proper passport data page: photo, fields, a machine-readable zone, per-vaccine validity status (up to date, due soon, overdue), a verification checklist, and a QR code of the shareable link. It can also scan a printed passport QR with the device camera.

Open the live link above and click the gallery chips to see each outcome for yourself, straight from devnet.

The verification is honest. Change any field in the record and the signature no longer matches:

original verifies  : true
tampered breed     : false
tampered vaccine   : false
wrong issuer key   : false

Code

kiprutopentine / dog-passport

Dog Passport

A dog's vaccination and pedigree record issued as a non-transferable Token-2022 on Solana. A vet signs each record with their keypair, so a boarding kennel groomer, border agent, or new owner can verify the record is authentic and came from a specific vet, without trusting any central server or app.

Runs on Solana devnet.

Why on-chain

Paper vaccination records get lost. App-based pet records die when the app or company shuts down. A breeder can hand you a pedigree with no way to check it. Putting the record on-chain as a soulbound token makes it portable, tamper-evident, and independent of any single vendor. The passport is bound to the dog, not tradeable, so it cannot be sold or swapped like an NFT.

How it works

Each passport is one Token-2022 mint with three extensions:

NonTransferable — the token is soulbound. Once minted to the owner it cannot be…

View on GitHub

How I Built It

Stack: plain @solana/web3.js + @solana/spl-token, no Anchor program. A handful of Node scripts plus a static viewer, small enough to build and verify in a weekend.

The Solana part that matters. Each passport is one Token-2022 mint that combines three SPL Token Extensions:

NonTransferable makes the token soulbound. I de-risked this first with a proof-of-concept that mints a token and then tries to transfer it. The program rejects the transfer, which is exactly what a passport needs.
MetadataPointer points the mint at itself for metadata, so there is no separate metadata account.
TokenMetadata stores the whole record on-chain in additionalMetadata:passport number, name, breed, dob, sex, colour, microchip, owner, photo URL andits SHA-256 hash, the vaccine list, the issuing authority, the vet's public key, and the vet's signature.

Issuer-signed records. The value is not "data on a chain," it is who signed it. The vet holds an Ed25519 keypair. Before minting, the vet signs a canonical serialization of the record (stable key order, reproducible byte-for-byte) with tweetnacl. That detached signature goes on-chain. Verification recomputes the canonical record from the on-chain fields, checks the signature against the vet's
public key, then checks that key against a trusted-vet list. Tampering fails because the bytes being verified no longer match the bytes that were signed.

Photo integrity. The image is bound to the record by hashing its bytes and signing the hash. The viewer re-hashes the photo it displays and compares, so the picture cannot be swapped without breaking verification.

The viewer and hosting. The on-chain read and the verification run in one loadAndVerifyPassport function shared by the CLI and the web. On Vercel it runs as a serverless function at /api/passport; locally the same function runs behind a small Node server. The function is host-agnostic: it reads the photo and the trusted-vet list over HTTP from its own deployment, so nothing from the local
filesystem has to be bundled.

Two things that fought back. The public devnet faucet was rate-limited to death, so funding falls back across endpoints (an Alchemy demo endpoint saved the day). And on Vercel, @solana/web3.js pulls in rpc-websockets, which bundles an ESM-only uuid and then require()s it, crashing the function with ERR_REQUIRE_ESM; pinning uuid to its CommonJS build via an npm overrides fixed it.

Prize Categories

Best Use of Solana. - Used Token-2022's NonTransferable extension to make the passport soulbound, on-chain TokenMetadata to carry the record, and the issuer-signature model to make verification about the vet rather than a server.

What's next

Real vet identity: a registry or attestations instead of a local trusted list.
An owner-transfer flow for rehoming and adoption, without making the token freely tradeable.
Mainnet custody and a kennel/border scanner app.