DEV Community: Aradar

What the p-value taught me about AI

Aradar — Sun, 13 Sep 2026 17:44:32 +0000

In bioinformatics, most of my work happens in R. R is deterministic: the same computation on the same data gives the exact same answer every single time. A language model does not.

That difference makes people nervous, but it follows a familiar pattern in scientific computing.

Take something as small as a p-value.

By hand, you pick a test, compute the statistic, find the right printed table, locate your degrees of freedom, interpolate between rows, and report that p is somewhere below 0.05. Most of the work is arithmetic and lookup.

With a calculator, the arithmetic goes away. You still choose the test and still read the table.

In R, you write one line. t.test(x, y) returns a p-value, a confidence interval, and the alternative hypothesis it tested.

What survives every one of those steps is the part that was always hard: choosing the right test, checking whether its assumptions hold for your data, noticing that you are about to run thousands of comparisons and need to correct for it, and knowing what the number does and does not license you to say. The manual labor became cheap. The judgment became the entire job.

Nobody argues that R users are not real statisticians because they don't do the arithmetic by hand. The tool absorbed the tiresome part, and the freed-up time went into running more analyses and thinking harder about them.

I work with software like this constantly. Aligners, motif finders, statistical packages, plotting libraries. Each one is thousands of hours of other scientists' work compressed into a function call I make. This is how the field works and has worked for a long time.

So an LLM is not a strange new category to me. It's just the next step on the same path. What is different is the size of the jump. Generating code that looks right has become cheap. The rare skill is knowing whether the problem was framed properly, whether the implementation is sound, and what breaks under real-world data or scale. The hard part didn't vanish. It moved from writing code to auditing it: R reliably runs math the same way every time, while an AI only produces plausible drafts that demand thorough validation.

How I Actually Use It

These rules apply to everything, from a serious project to a weekend hobby. They change as I learn more and as new models and tools arrive.

Research and plan before writing code. The hard job here is to resist the temptation of jumping to implementation because you are excited to test your idea. I learned the hard way that doing that actually increases the chance of failure and wasting time.
Plan how it breaks first. Before I let an agent work, and again after it is done, I write down how the system can fail. Instead of asking how to make it work, I ask how it will break: what bad inputs make it crash, where data gets silently corrupted, and what tests prove those failures haven't happened.
The core rules are mine. What the code is supposed to accomplish, what counts as correct, and what errors actually mean for the science. None of that is a code-generation problem. It's mine.
A living project spec. Each project has a directory of markdown and schemas describing what the code actually does. It gets updated as the code changes, and every so often I audit it again, in several passes, to keep it as true to the code and the logic as possible. It keeps the model's context accurate, and it keeps mine accurate too. Below is an example from a cross-platform application (the exact same structure holds whether building an app or a scientific data pipeline).

❯ tree .
.
├── 00_project_overview.md
├── 01_aso.md
├── 02_system_architecture.md
├── 03_frontend_architecture.md
├── 04_data_models.md
├── 05_business_logic.md
├── 06_storage_strategy.md
├── 07_capacitor_plugins.md
├── 08_android_configuration.md
├── 09_ios_configuration.md
├── 10_sync_strategy.md
├── 11_conflict_resolution.md
├── 12_onboarding_flow.md
├── 13_edge_cases_and_failure_scenarios.md
├── 14_known_gaps_and_todos.md
├── 15_release_process.md
├── 16_github_actions.md
├── 17_archived_decisions.md
├── 18_deprecated_features.md
├── 19_migration_history.md
├── 20_server_side_enforcement_gaps.md
├── 21_gdpr_compliance_plan.md
└── 22_medication_module_map_and_edge_cases.md

Catching frustration early. When I find myself swearing at the agent, it means my own context has drifted: I stopped planning and started hoping. The fix is to walk away, come back with a fresh head, and plan properly.

Where the Tools Stand Today

Models today are prompt-sensitive, prone to hallucination, and inclined to tell me what I want to hear. Sometimes they are lazy and disobedient. Push them and they will often report that the job is done when it is not. I expect this to improve, the way tooling generally improves once enough people depend on it and start feeding failures back in. Until then, I am still in the driver's seat.

From Debian to EndeavourOS

Aradar — Fri, 28 Aug 2026 18:32:22 +0000

For a long time, I used Debian. I still run it on my office laptop. It is hard not to respect a distro with that kind of stubborn integrity, quietly holding up half the internet without ever caring about being cool.

Debian users have the energy of someone who drives a 1998 Volvo with 450,000 km on the clock, changes the oil on schedule, and looks at you like you are insane if you suggest buying a new car. This one runs fine. A computer is an appliance, not an adrenaline rush.

Naturally, I stayed far away from Arch. Everything I heard made it sound like an exhausting hobby: unstable, fragile, and demanding constant babysitting.

Then Debian 13 arrived and broke my audio on the pc and laptop.

I tried to fix it properly. When that failed, I gave up and wrote a shell alias called fixsound. Every time I had a Zoom meeting or wanted to play music, I had to run it first.

It worked, but it was a pathetic little ritual. It let me pretend everything was fine while I spent my day tiptoeing around my own machine.

Two weeks ago, I finally got fed up and installed EndeavourOS.

It turns out Arch is not a grenade waiting to go off. EndeavourOS gives you a clean starting point without hiding how the system actually works. You manage the machine yourself, keep backups, read the update notes, and know what you have installed.

Two weeks in, the system is dead quiet. Zoom works. Music works, everything is fine. I finally deleted the fixsound alias.

The old Volvo had a great run, but it is nice to drive something that can stream the latest music.

Why I Built an Open-Source, Zero-Cloud Period Tracker with React 19 & Capacitor

Aradar — Sun, 23 Aug 2026 17:11:13 +0000

In an era where health data is increasingly commodified, tracked, and exposed in data breaches, personal data privacy isn't just a bonus feature — it's a fundamental requirement.

Most period and cycle tracking apps require cloud accounts, transmit deeply intimate health telemetry to remote servers, and integrate third-party ad SDKs. When data lives on a central server, it is vulnerable to leaks, corporate sales, and subpoenas.

We asked a simple engineering question: What if the server simply didn't exist?

That philosophy led to Mooneva Cycle — a 100% offline-first, private, and open-source (GPL-3.0) period & cycle tracker built for web, iOS, and Android.

🎯 Core Architectural Philosophy: Zero Trust, Zero Cloud

Our design rule from day one: Data that never leaves the user's device cannot be leaked or compromised.

Traditional Cloud Trackers	Mooneva Cycle
Stored on third-party cloud databases	Stored exclusively on-device (`localStorage` / Secure Storage)
Third-party analytics & telemetry trackers	Zero analytics, zero ad SDKs, zero crash loggers
Requires email/phone registration	No account, no signup, instant access
Susceptible to remote breaches	No centralized database to breach

🛠️ The Tech Stack

To deliver a snappy, native-like mobile experience across iOS and Android without maintaining separate native codebases, we opted for a modern web-to-native stack:

Frontend Core: React 19 + TypeScript
Build Tool: Vite 6
Native Runtime: Capacitor 8 (iOS & Android bridge)
Styling: Tailwind CSS + Vanilla CSS tokens
Internationalization: i18next (supporting 12 languages + RTL layout)
Reporting & Export: html2pdf.js for on-device clinical PDF reports
Testing: Vitest + @testing-library/react

🔐 Key Technical Highlights & Design Decisions

1. Local-First Encrypted Backups with PBKDF2 & AES-GCM

Since there is no remote database to restore from, data portability and secure backup exports are critical. We use standard Web Crypto APIs for user backups:

Password-derived cryptographic keys via PBKDF2 (high iteration counts + dynamic salt).
AES-GCM (256-bit) authenticated encryption for backup archives.
Zero external cryptographic dependencies needed — fully native to modern Web and WebView runtimes.

// Client-side key derivation & encryption flow
async function deriveKey(password: string, salt: Uint8Array): Promise<CryptoKey> {
  const enc = new TextEncoder();
  const baseKey = await crypto.subtle.importKey(
    'raw',
    enc.encode(password),
    'PBKDF2',
    false,
    ['deriveKey']
  );

  return crypto.subtle.deriveKey(
    {
      name: 'PBKDF2',
      salt,
      iterations: 250_000,
      hash: 'SHA-256'
    },
    baseKey,
    { name: 'AES-GCM', length: 256 },
    false,
    ['encrypt', 'decrypt']
  );
}

2. Push-Less Local Notifications

Most apps use FCM (Firebase Cloud Messaging) or Apple APNs coupled with backend cron jobs to send reminders.

To eliminate cloud triggers, Mooneva schedules all alerts strictly on-device using @capacitor/local-notifications. The device OS manages the alarm queue locally for:

Predicted cycle & period starts
Ovulation & fertile windows
Daily symptom/mood logging reminders
Contraceptive pill/patch/ring adherence schedules

3. "Discrete Mode" & Local PIN Protection

Privacy extends to shoulder-surfing. We engineered:

Discrete Mode: Disguises the app launcher icon and name into a neutral utility.
Biometric & PIN Lock: Guarding the interface with configurable timeouts using encrypted storage for authentication state.

4. Non-Gregorian Calendar & True RTL Support

Health apps often overlook regional accessibility. Mooneva includes full support for the Persian (Jalaali) solar calendar alongside Gregorian dates, accompanied by automatic bidirectional (RTL) layout switching via Tailwind's logical directions.

5. Migration Freedom (Import from Flo, Clue & drip)

Vendor lock-in is hostile to user autonomy. We implemented client-side parsers that ingest export files from major platforms (Flo, Clue, drip), normalizing historical cycle dates, flow intensities, and logs into Mooneva's local schema directly in the browser/app memory.

🚧 Challenges Solved

Deterministic Predictions on Sparse Data: Designing cycle prediction algorithms that run entirely on client hardware without heavyweight ML dependencies, providing robust rolling-average predictions while gracefully handling irregular cycles and birth-control withdrawal bleeds.
True Air-Gapped Verification: Configuring mobile manifests (AndroidManifest.xml and Info.plist) to ensure no extraneous network privileges or background tracking services are requested.
Cross-Platform PDF Generation: Generating doctor-ready clinical PDF summaries on the fly directly inside mobile WebViews using canvas and DOM rendering without leaking document data to an external PDF generation API.

🤝 Open Source & Contributing

Mooneva Cycle is 100% free and open source under GPL-3.0. There is no venture capital, no monetization through data harvesting, and no paywalls on essential features.

If you care about local-first software, client-side encryption, and accessible health tools:

⭐ Star the repository: github.com/aradar46/Mooneva-Cycle-Private-Period-Tracker

📱 Try it on Google Play: Mooneva on Google Play

🍎 Try it on App Store: Mooneva Cycle on iOS

🌐 Website: mooneva.se

We welcome contributions — from translations and UI tweaks to cryptographic audits and prediction algorithm improvements!

Silence Is a Feature

Aradar — Sun, 23 Aug 2026 17:03:40 +0000

Originally published at aradar.top.

The server room is too loud. You picture blue LEDs blinking in the dark. It’s actually a wall of sound - thousands of small fans screaming in slightly different keys, a noise that gets into your teeth. I had the yellow ear protection on and could still feel it in my jaw. Aaron didn’t seem to notice. Or he noticed years ago and made his peace.

He walked the row, found the machine, pressed the release. The drive slid out. He held it up, turned it once in the light, and pointed at it with his chin. Grab this.

He seated the new one, waited for the light to go from amber to green, and that was it. Upstairs, a lab full of people kept working on data that had never stopped being there. Not one of them looked up.

Past the double doors, when the noise dropped away and my ears were still ringing, he said: “Silence is a feature.”

I said something. Something like sure.

“No, it’s a feature. Somebody pays for it. You pay, I pay, everybody pays. It’s just not free.” He tapped the dead drive in my hand. “This is the bill.”

We walked. He wasn’t done.

“Think about it. No alert. No status page. No email from IT. That’s the product. That big boring nothing - that’s what all the money buys. And when it breaks, the first thing you lose is the quiet. Then somebody walks back in there.” He tipped his head toward the doors behind us. “Everybody loves builders. Fine. But what you actually depend on, every hour, is maintainers. Water at the pressure you expect. Electricity that’s just there. Cables under the ocean so you can reach the whole world without once wondering how. Somebody is awake right now so that all of it feels like nothing to you.”

He dropped the dead drive in a bin by the door with a dozen others just like it. He had a ticket to close and lunch to get.

Somebody has to deal with the noise so you never feel the lack of silence.