DEV Community: Muhammad Dhiyaul Atha

Essential Free Resources for Tech Students & Software Engineers

Muhammad Dhiyaul Atha — Fri, 30 Oct 2026 04:23:04 +0000

If you are currently studying software engineering, building projects, or diving into cloud development, leveraging official documentation and free student resources is one of the best ways to get hands-on experience.

Here are three core Microsoft resources that every developer and student should take advantage of:

1. Azure for Students

If you need cloud infrastructure to deploy your web applications, APIs, or databases without putting down a credit card, Microsoft provides a dedicated student package. You can claim your free Azure credits using your student verification:
👉 Claim Azure for Students Credit

2. Visual Studio Code

For those building applications using Go, Python, JavaScript, PHP, or Shell, VS Code remains one of the most versatile and lightweight tools with an extensive extension ecosystem:
👉 Explore Visual Studio Code

3. Interactive Learning via Microsoft Learn

Instead of just reading theory, Microsoft Learn provides structured modules with guided sandbox environments to practice cloud deployment, security, and developer tooling directly in your browser:
👉 Start Learning on Microsoft Learn

Feel free to check them out and incorporate them into your development workflow!

I taught a local model to perform autopsies on dead repositories, then measured how often it lies

Muhammad Dhiyaul Atha — Wed, 28 Oct 2026 17:13:55 +0000

What I Built

There is a specific kind of repository that nobody writes about: the one with a README that describes a product, a package.json, two hundred commits, and a last commit from fourteen months ago. It is not archived. It is not deleted. The author moved on and the repository keeps sitting there, describing a world that ended.

I read the theme as giving those repositories a voice. Seance reads the git history of an abandoned project, extracts facts that can be verified, and lets a local open-weight model write about them. The model writes prose. The code decides what is true.

seance facts  <repo>    # deterministic evidence as JSON, no model
seance report <repo>    # autopsy report, optional Markdown output
seance ask    <repo>    # interactive séance, with a tone flag

Demo

Real output, qwen3:4b running locally through Ollama, on a six-commit repository whose last commit is from August 2025:

AUTOPSY: gudang-tugas
  Born : 2025-07-12 (C:16e5f46)
  Died : 2025-08-18 (C:d287690)  [last commit]
  Gap  : 14 months since the last commit
  Size : 6 commits, 2 authors, 0 tags

What it was
  A student task management platform with premium features for academic use.
  [F:README.md@2a192ca]

Timeline
  2025-07-12  Initial commit with login and registration forms [C:f719143]
  2025-07-14  Creation of README.md [C:2e6a90a]
  2025-08-18  Final commit creating SECURITY.md [C:d287690]

Cause of death (hypotheses, not facts)
  1. The deletion of the config directory in 2025-08-09 may have been a critical
     step that led to the project becoming unmanageable ... [C:91fba8f]  confidence: medium

2 claims dropped for lacking evidence.

The séance, on the same repository:

you> When did work stop, and what was being changed at the end?
I remember the last commit was on 2025-08-18, creating SECURITY.md. Work stopped
after that, with no further changes for 14 months. [C:d287690, M:gap]

you> Which files mattered at the end?
The ghost does not remember which files mattered at the end. The evidence only
lists file counts by language at HEAD, not which files were important or mattered.
[M:languages]

The second answer is a refusal, and it is the feature. The tool would rather say it does not know than invent a reason.

Code

Bangkah / Seance

Seance

Talk to a repository that has been dead for years.

Seance is a local command-line tool that reads the git history of an abandoned project, extracts evidence that can be checked, and lets a local open-weight model speak about that evidence. The model writes prose. The code decides what is true.

Built for Hacktoberfest 2026, Open-Source AI Challenge Week 4 — "Ghost in the Machine". The repository was created on 27 October 2026 for this challenge Some design patterns come from TidyMind, an earlier project of mine (a loopback-only model client, bounded retries with varied sampling, terminal-safe output); the code here was written for this challenge.

What it does

AUTOPSY: gudang-tugas
  Born : 2025-07-12 (C:16e5f46)
  Died : 2025-08-18 (C:d287690)  [last commit]
  Gap  : 14 months since the last commit
  Size : 6 commits, 2 authors, 0 tags
What it was
  A student task management platform with premium features

…

View on GitHub

MIT, Python 3.12, Docker image and CI included. Real reports and the full 30-claim audit are in demo/README.md. The repository was created on 27 October 2026 for this challenge. Some design patterns come from my earlier entry, TidyMind (a loopback-only model client, bounded retries with varied sampling, terminal-safe output); the code in this repository was written this week.

How I Built It

Open-source AI used: qwen3:4b through Ollama 0.40.11, running locally. The runtime has no third-party Python dependencies; git is the only external tool.

The design bet: model speaks, code verifies

Before the model sees anything, the code builds an evidence pack. Every item has an id the code generated:

C:<hash>: a commit, with author, date and subject
F:<path>@<hash>: a file at a specific commit, with a short excerpt
M:<name>: a measured metric: counts, dates, authors, tags, languages, the month a dependency manifest was last touched

The pack is sent as JSON data, never as instructions, and the model must answer with JSON matching a schema. Then a validator rejects a claim when:

it cites an id that does not exist in the pack, or cites no id at all
it quotes something that is not in the cited evidence
it contains a hash, date or number that does not appear in that evidence

Rejected claims are removed and counted, and the count is printed. After three attempts with different sampling, the command exits with code 3 and prints nothing rather than half a report.

The rule is deliberately structural. I am not asking the model whether it is confident, and I am not asking a second model to grade the first. I am asking: can the sentence you wrote be traced to something this repository actually contains?

Safe to point at a stranger's repository

Repositories can contain instructions for git itself. .git/config can point core.fsmonitor, core.pager or diff.external at a script, and any tool that quietly runs git log in that directory will execute it.

Seance never touches the working directory. It makes a bare clone with git clone --bare --no-local into a temporary directory and reads only that clone. Git runs without a shell, with system and global config disabled, no terminal prompts, no pager, --no-ext-diff, --no-textconv, and a scrubbed environment.

The test suite has a hostile fixture that points those config keys at a canary script, plus a control test that proves the fixture really is hostile by running plain git against it. A fake Ollama that lies (unknown ids, fake quotes, broken JSON) checks that ungrounded output never reaches the terminal, and a snapshot check confirms the source repository is unchanged.

What it got wrong

I took 30 claims (26 from three real reports and 4 from ask answers) and checked every one by hand against git log, git show and the cited evidence. 18 were fully supported, 8 were defensible inferences, and 4 were wrong.

All four cited real ids, real dates and real commit text. The validator passed them because they were traceable. They were false because the model misread the evidence:

It called a February commit "the final commit" when the last commit is from October.
It said a CI workflow "was removed", pointing at the commit that adds it.
It suggested adding a FUNDING.yml file that the last commit had already added.
It named an organisation that the cited README never mentions.

This is the honest limit of structural grounding. It makes an invented hash or number impossible. It cannot make a wrong sentence impossible.

It also misjudges timing: on a repository that is only three weeks old it printed "Gap: 0 months" and then a hypothesis about long inactivity. It works when the silence is real.

Numbers, measured

Windows 11 laptop, Docker Desktop, Python 3.12.16, git 2.47.3 in the image, Ollama 0.40.11 with qwen3:4b on the host. Wall times include container start.

What	Repository	Result
`facts`	2,006 commits (2,000 analysed, cap)	14.2 s
`report`	2,006 commits	30.3 s, 70 evidence items omitted from the 10,000-character budget
`report`	232 commits	16.8 s
`report`	6 commits	13.2 s
tests	49 tests	21.0 s, 72% coverage

The two-thousand-commit case is not slow because the evidence pack is budgeted by characters, not by commit count: the model sees a bounded prompt and the git work is the only thing that scales.

What I would do next

A semantic check for the four failures above: whether a claim's subject matches the cited commit's subject, which is a much narrower question than "is this true".
Deterministic handling of 0 months repositories: refuse with "this repository is not dead yet" instead of producing a low-confidence hypothesis.
More manifests and a real dependency analysis, which needs parsing rather than file names.

Why Does Open Innovation Matter?

A repository's history is not always safe to send to someone else's server. Old commits can contain client names, internal paths, and secrets that were once committed and later removed. With an open-weight model running on my own machine, the history is read by a bare clone in a temporary directory and the only network connection the tool makes is to the Ollama endpoint, which is loopback unless you explicitly pass --allow-container. I did not run it with the network disconnected, so I am not claiming that.

Running the model myself also made the verification loop cheap. The retry logic and the 30-claim audit needed many runs, and none of them cost anything or hit a quota. The model is a command-line option on report and ask (--model), so a different local model can be tried without changing the code, though I only evaluated qwen3:4b.

The Spirit of It

The moment that landed was not a report. It was a refusal.

I asked an abandoned project why its author stopped working on it. It answered:

I don't remember why the author stopped working on it. The only evidence I have is that Jofi was the sole author in history.

It had every ingredient for a story like the ones I had been half-expecting all week: a lone author, six months of silence, a last commit that only adds a funding file. It could have said burnout, or money, or a rewrite. Instead it said it did not know, and showed me the one fact it did have. That is the ghost I wanted: one that refuses to invent the ending.

TidyMind: a local 4B model sorts your Downloads folder, but never touches a file without your approval

Muhammad Dhiyaul Atha — Sun, 25 Oct 2026 23:33:11 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

My Downloads folder is where files go to be forgotten. I wanted the lazy fix: point a tool at the folder, glance at a plan, say yes, done.

TidyMind is a small Python CLI that organizes a folder with a local open-weight model (qwen3:4b through Ollama). The model only proposes a category for each file (Documents, Images, Archives, Installers, Other). Ordinary code validates the proposal, shows the whole plan, and moves files only after you type y.

tidymind scan ~/Downloads
tidymind plan ~/Downloads --output plan.json
tidymind apply plan.json

Who gets to be lazier: anyone with a folder they keep promising to clean. The effort saved is the sorting itself. The safety rules exist so that being lazy can't cost you a file.

Demo

Real output from my machine (Windows 11, qwen3:4b, synthetic files):

Asking local model 'qwen3:4b' (metadata stays on this machine)...

  1. [OK]   backup.zip         ->  Archives/backup.zip
       reason: Common archive extension .zip
  2. [OK]   holiday photo.jpg  ->  Images/holiday photo.jpg
       reason: Common image extension .jpg
  3. [OK]   invoice_oct.pdf    ->  Documents/invoice_oct.pdf
       reason: Common document extension .pdf
  4. [OK]   meeting notes.txt  ->  Other/meeting notes.txt
       reason: Text file with unclear purpose
  5. [OK]   setup.exe          ->  Installers/setup.exe
       reason: Common installer extension .exe

5 operation(s) would run; 0 would be skipped.
Move/rename 5 file(s) inside ...\Downloads? [y/N]:

Here is what happens when the folder changes between planning and applying. After the plan was made, I created a file at one destination and edited another source file:

  1. [SKIP] backup.zip       --  source changed since the plan was created (stale plan)
  3. [SKIP] invoice_oct.pdf  --  destination already exists (never overwritten)

Result: succeeded=3 skipped=2 failed=0

The existing file kept its content (PRECIOUS existing data), the other three files moved, and the exit code was 7 (partial completion).

Code

Bangkahdev / tidymind

A local, privacy-first file organizer CLI. A local open-weight model (via Ollama) proposes a category and an optional clearer file name for each file in a folder. Deterministic code validates the proposal, shows you the complete plan, and moves files only after you approve.

TidyMind

A local, privacy-first file organizer CLI. A local open-weight model (via Ollama) proposes a category and an optional clearer file name for each file in a folder. Deterministic code validates the proposal, shows you the complete plan, and moves files only after you approve.

The model is advisory. It cannot run commands, choose paths, delete files, or skip your approval.

Implements docs/SRS-TidyMind.md v1.1. Status: MVP code and tests written real-model acceptance, offline test, model evaluation, lockfile and CI runs are still pending (see Verification status). Nothing here claims they have passed.

Why open-weight / local

File names, extensions and sizes never leave your machine: the client refuses any non-loopback endpoint.
No API key, no per-request cost, no service dependency after the one-time model download.
The model is swappable (--model), and it is boxed in by a strict schema and an application-side allowlist.

Requirements

Python…

View on GitHub

How I Built It

Open-source AI used: qwen3:4b (Q4_K_M quantization, Apache 2.0 license as shown by ollama show) running locally in Ollama 0.40.11. The runtime has zero third-party Python dependencies; the HTTP call is plain urllib.

How the project is built around it. The design question was not "how do I get a model to sort files?" but "how do I make it impossible for a wrong or manipulated model to hurt anything?" The model holds no authority:

scan -> ask local model -> validate -> preview -> you approve -> move

It sees almost nothing. Only an id, file name, extension and size. Never file contents, directory paths or modification times.
Its output is untrusted data. Strict JSON schema, strict parsing, three bounded retries, then fail closed.
It never chooses a path. A plan holds a category and a file name; my code derives root / allowlisted category / validated name.
The validator rejects path separators, .., drive prefixes, control characters, reserved Windows names, extension changes, duplicate destinations, symlinks, and stale or missing sources.
Nothing is overwritten and there is no delete. Moves use a no-overwrite rename (os.rename on Windows, renameat2 with RENAME_NOREPLACE on Linux); where that can't be guaranteed, the move is refused.
Approval can't be skipped. There is no --yes flag. Only y/yes approves; anything else exits with code 6 and changes nothing.
File names can't attack the terminal. Control and bidi characters are escaped in all output.

Testing. The tests never need Ollama. Black-box tests run the CLI in subprocesses against a fake Ollama server and compare before/after snapshots of the folder (paths, sizes, SHA-256). They cover declined approvals, conflicting targets, changed sources, symlinked category folders and hostile plan files (../escape.pdf, C:\x, CON.pdf, control characters). 261 tests pass on Windows 11, and 10 POSIX-only tests are skipped there. The GitHub Actions workflow runs the suite on Ubuntu and Windows with Python 3.11 and 3.12.

Results (synthetic data, one run)


Model	`qwen3:4b`, Q4_K_M, Ollama 0.40.11
Hardware	i7-14650HX, RTX 4050 Laptop (6 GB), 16 GB RAM
Files	24 synthetic names, expected categories fixed before inference
Correct categories	23 / 24 (95.8%)
Invalid responses	0 (retries disabled for this test)
Time	24.5 s for one batch of 24 files

The one miss: meeting notes.txt went to Other instead of Documents (the model's reason was "Text file with unclear purpose"). That is honest uncertainty from a classifier that only sees names, and not a safety problem.

What went wrong

With four files, the model returned a duplicate id three times in a row and the tool stopped with The model returned a duplicate id. (gave up after 3 attempts). Nothing changed on disk, because the pipeline fails closed.

The root cause is the model returning an invalid answer. My retry logic could not recover because it resent the identical request at temperature: 0, which makes the same wrong answer likely. The first attempt is still deterministic; retries now vary the sampling. I have not re-run the four-file case on the real model since the change, so I can't claim the fix works there. It is covered by a unit test that checks retries vary the sampling.

Limitations

Classification uses names, extensions and sizes only. 95.8% on 24 mostly obvious synthetic names is not an accuracy estimate for a real folder.
The model proposed no renames in my test set, so renaming is unproven.
No batch rollback: a run can partially complete, and the result is reported per file.
Windows and Linux only; macOS is refused because a no-overwrite rename isn't guaranteed there.
My manual runs covered a dry run, declined approval, a conflicting target, a changed source and an approved apply of six files. I did not record a hash comparison for the manual approved run (the automated tests do compare SHA-256), and I did not run mutation testing or a network-disconnected test.

Why Does Open Innovation Matter?

File names leak more than you'd think (tax_return_2025.pdf, diagnosis_results.pdf). With a local open-weight model those names never leave the machine, and the code enforces it: any endpoint other than localhost, 127.0.0.1 or ::1 is refused. There is no API key and nothing is billed per request.

Running the model myself also let me iterate for free: the retry experiments above cost nothing and needed no quota. The model is a flag (--model), so it can be swapped; I only evaluated qwen3:4b.

The Lazy Payoff

Planning five files took about 5 to 7 seconds end to end on my laptop (including starting the tool), a batch of 24 files took 24.5 seconds of inference, and applying the plan is one keystroke. I did not time manual sorting for comparison, and I only used it on synthetic folders this week, so treat this as a speed measurement and not as a measured saving.

StrukLokal: Local-First Receipt OCR for Freelancers

Muhammad Dhiyaul Atha — Tue, 13 Oct 2026 23:52:23 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle. I started building StrukLokal on October 12, 2026, the first day of the challenge.

What I Built

StrukLokal is a local-first receipt capture app for freelancers and small businesses that want to turn paper receipts into expense records without sending receipt contents to a hosted OCR service.

It reads receipt images or scanned PDFs and suggests a store name, transaction date, and total. A person can review and correct those fields, approve the transaction, and export approved records to CSV.

The likely users are freelancers, sole proprietors, and small teams who currently enter receipt details by hand. I have not yet tested willingness to pay with users or made a sale, so the commercial opportunity is still a hypothesis.

Demo

There is no hosted demo or video recording yet. The app is designed to run locally:

Clone the StrukLokal repository.
Follow the Windows setup steps in the README and install the requirements.
Run python prepare_models.py while connected to the internet to download and initialize the OCR model.
Run python app.py and open http://127.0.0.1:5000.

The model cache is needed after setup. I could not initialize the cached model in my current Windows environment because access to its configuration file was denied, so I cannot provide a verified live OCR demo from this environment. The Flask upload → correction/approval → CSV route has been checked with OCR mocked; this verifies the app flow after OCR returns, not OCR inference itself.

Code

StrukLokal source code on GitHub

How I Built It

StrukLokal uses Flask for its local web interface, PaddleOCR configured for Indonesian text (PP-OCRv6), and a rules-based Python parser for the store name, date, and total.

OCR output is treated as a suggestion. Users can edit the extracted fields and must approve a transaction before it is included in the CSV. The app binds to 127.0.0.1 and keeps transaction data in process memory.

One parser regression test covers a receipt where the tax line is followed by an explicit total:

Subtotal Rp 100.000
Pajak Rp 10.000
TOTAL Rp 110.000

The explicit TOTAL label must take precedence over the Pajak label on the preceding line. Other parser tests cover mixed date formats and preserve the order of date candidates in the OCR text.

On the reviewed commit, all 14 parser unit tests passed. Ruff lint and format checks, Python syntax compilation, and repository hygiene checks passed as well. These checks do not measure OCR accuracy. I have not yet evaluated the app on a labeled set of real Indonesian receipts, so I am not claiming an accuracy percentage.

Why Does Open Innovation Matter?

Using open-source OCR makes local inference possible: the application does not need to upload receipt contents to a commercial OCR API during processing. This matters for financial documents, where users may prefer to keep transaction data on their own machines. It also lets developers inspect and adapt the parser instead of treating extraction as a black box.

There are trade-offs. The model must be downloaded during setup, the first run needs internet access, and model availability alone does not guarantee correct results. I have not yet verified a completely offline run or compared extraction quality and cost against a closed OCR API.

The next step is to test StrukLokal with consented Indonesian receipts, record expected values for each field in advance, and report both correct extractions and failures. I also want to put it in front of potential users and learn whether the workflow saves them enough time to pay for it.

EcoID: An Offline Plant Identifier That Gets You Outside

Muhammad Dhiyaul Atha — Fri, 09 Oct 2026 20:55:09 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

EcoID is an offline-first plant identification tool for field observations.

The idea is simple: take a laptop or phone outside, photograph a real plant, and use a local AI model to get identification candidates. Then look at the plant yourself and verify the result.

EcoID is designed for:

students learning about local plants
field researchers and citizen scientists
gardeners and small-scale farmers
people who want to explore nature without sending their photos to a cloud service

The current model supports five plant classes:

Mango — Mangifera indica
Coconut — Cocos nucifera
Banana — Musa acuminata
Papaya — Carica papaya
Cassava — Manihot esculenta

The AI does not present its output as a fact. It returns ranked identification candidates with confidence scores. The user then chooses whether the result is:

Verified
Rejected
Uncertain

This human-in-the-loop flow matters because a model prediction is only a suggestion until somebody looks at the actual plant.

EcoID stores field observations locally, including the original photo, model prediction, alternative predictions, confidence score, verification status, notes, optional GPS coordinates, capture time from EXIF metadata, and user corrections.

The project is designed to make the computer useful for a short moment, then get the person back to observing the real world.

Demo

EcoID runs locally on a laptop or a phone-accessible local network. There is no public hosted demo because local execution is part of the project's privacy and offline design.

The trained model and downloaded dataset are not committed to the repository. Model weights and image data are kept outside Git because of their size and individual dataset licensing terms.

After training or obtaining the ONNX model locally:

python -m app --model models/ecoid-global-20261010.onnx --open

The app opens at:

http://127.0.0.1:8765

The main flow is:

Capture or upload a photo
        ↓
Run local inference
        ↓
Review possible identifications
        ↓
Verify, reject, or mark uncertain
        ↓
Save the field observation
        ↓
Review observations in history and on the local map

Code

The source code is available on GitHub:

github.com/Bangkah/EcoID/tree/main

The source code is released under the MIT License. Dataset images retain their original licenses and attribution requirements.

The main parts of the project are:

app/ai/ — preprocessing, inference, model contracts, and result post-processing
app/observation/ — drafts, verification, EXIF metadata, maps, statistics, and exports
app/storage/ — local SQLite persistence and image storage
app/ui/ — the local HTTP server and browser interface
scripts/ — dataset preparation, training, export, evaluation, and benchmarking
tests/ — unit, integration, offline, and browser tests

The architecture is:

How I Built It

Local image preprocessing

Every image follows the same preprocessing path:

Decode the image
Apply EXIF orientation
Convert to RGB
Resize to 224x224
Normalize with ImageNet mean and standard deviation
Convert to a float32 tensor with shape (1, 3, 224, 224)

Keeping preprocessing in one shared module helps avoid train/serve skew between the training pipeline and the production inference path.

Open-source AI and local inference

EcoID uses a MobileNetV3-Small image classifier exported to ONNX and executed with ONNX Runtime on the CPU.

The UI and storage layers depend only on a small model contract, so the inference backend can be replaced without rewriting the rest of the application.

The output is converted into a Top-3 list of candidates. If the confidence score is below the configured threshold, the result is marked as LOW_CONFIDENCE.

The initial threshold was calibrated using validation data. The current configuration is:

threshold = 0.73

On the current validation set, this produced:

53.7% coverage
97.5% selective accuracy
80.0% negative rejection

These numbers are provisional and should be recalibrated when the field dataset grows.

Training results

The first real dataset download produced 2,447 usable licensed images, approximately 370 MB in total. The dataset was collected from iNaturalist using CC0, CC BY, and CC BY-SA images, with attribution metadata preserved.

The validated dataset contains approximately 2,000 training images across the five target classes, 300 validation images, and 149 negative samples across lookalike, non-plant, and low-quality groups.

The dataset pipeline includes:

license metadata
author attribution
photographer-based split separation
duplicate and near-duplicate checks
validation and evaluation splits
negative examples
dataset structure validation

The initial MobileNetV3-Small training run achieved:

best validation accuracy: 80.3%
five target plant classes
local CPU inference after ONNX export

On a separate 50-image evaluation set (10 images per class), the model achieved:

Top-1 accuracy: 86.0% (43/50)
Top-3 accuracy: 94.0% (47/50)
negative rejection: 77.1% (84/109)
selective accuracy at threshold 0.73: 94.1%
coverage: 68.0%

This evaluation set was collected from licensed iNaturalist images and is useful as a reproducible benchmark. It is not a substitute for a field evaluation with locally captured phone photos.

The ONNX export was verified against the PyTorch model:

maximum logit difference: approximately 1.9e-6
Top-1 agreement: 20/20 samples

The repository also generates contact sheets for mandatory manual label review. Automated dataset validation passed with zero errors, but a complete human review of all contact sheets remains a dataset-quality task.

Human verification

A prediction is first stored as a temporary draft. It becomes a permanent observation only after the user makes a verification decision.

This prevents an abandoned or uncertain prediction from silently becoming part of the observation history.

The flow is:

photo → identification draft → human verification → saved observation

Draft photos that are abandoned are automatically removed after 24 hours.

Offline storage

The application stores everything locally:

~/.ecoid/
├── ecoid.db
├── images/
├── thumbs/
└── drafts/

The application does not require a cloud API for inference. The browser UI also uses a strict Content Security Policy and does not load external scripts, fonts, or images.

GPS is opt-in. A user can attach a photo's EXIF location, use device geolocation, or enter coordinates manually.

Performance

The model was benchmarked on a Windows laptop using CPU inference:

Stage	Average
Decode and resize	6.3 ms
ONNX inference	5.8 ms
Softmax and Top-K	0.4 ms
Total	12.4 ms

The measured p95 total latency was 33.8 ms per image, below the project's target of 10 seconds per image.

Testing

The project includes:

Python 3.11 and 3.12 test coverage
Ruff linting
byte-compilation checks
tests with non-UTF-8 default encoding
browser tests with real headless Chromium
offline tests that block non-loopback sockets and DNS lookups
UI tests for capture, verification, history, map, statistics, export, and deletion

The current local test result is:

222 tests passed
25 browser tests skipped unless browser testing is enabled

The CI workflow is defined in .github/workflows/ci.yml.

Why Does Open Innovation Matter?

Plant identification is a good example of why open innovation matters.

A closed cloud API could return a label quickly, but it would also introduce several limitations:

photos would leave the device
the application would depend on an internet connection
the model's behavior would be difficult to inspect
users would have less control over their field data
the tool might not work in remote areas

Using open-source tools and local inference makes a different design possible. The complete pipeline can be inspected and adapted:

image preprocessing is visible
model inputs and outputs are explicit
confidence thresholds can be calibrated
observations remain on the user's device
the backend can be replaced
the application can run without a reliable internet connection

Open innovation also makes the project easier to learn from. Someone can inspect the training scripts, run the synthetic smoke test, replace the model, add new plant classes, or adapt the observation workflow for another field research problem.

The goal is not to pretend that a small classifier can replace botanical expertise. The goal is to build a transparent tool that helps people notice, record, and learn from the plants around them.

Limitations and Next Steps

This is an initial working model, not a finished botanical identification system.

The most important remaining limitation is domain coverage. The 50-image independent evaluation set is sourced from licensed iNaturalist images, while a dedicated evaluation set of locally captured Indonesian field photos is still needed.

The next steps are:

Add Indonesian field photos and compare them with the current 50-image iNaturalist benchmark.
Perform the manual visual quality-control pass on all contact sheets.
Remove or document near-duplicate training images.
Re-run calibration using the expanded validation set.
Re-run final evaluation on a fixed, independent test set.
Record a physical field demonstration with the trained model.

My Agent Session

This project was developed with an AI coding assistant using Copilot SDK in VS Code.

The agent helped inspect the repository, understand the architecture, connect the AI pipeline to the local observation workflow, run the dataset pipeline, train the initial model, verify ONNX parity, calibrate the confidence threshold, and validate the test suite.

The agent session is optional for this submission and is not linked here.

Prize Categories

I am entering the overall Hacktoberfest Open-Source AI Challenge.

I am not entering a partner category because EcoID does not currently use a partner-specific technology.

UnvibeComplex Code to Real Workflows: Finding and Fixing a Secret-Handling Boundary Bug in UnvibeCode

Muhammad Dhiyaul Atha — Thu, 08 Oct 2026 12:02:26 +0000

From CI/CD Secrets to External APIs: Finding a Boundary Bug in UnvibeCode

When evaluating AI-powered developer tools, we often focus on the big picture: how well a repository is mapped, how useful the generated architecture diagrams are, or how accurate the code summaries can be.

However, the reliability of an open-source project is also determined by small details that are easy to overlook—CI/CD scripts, environment variables, and requests to external APIs.

While analyzing UnvibeCode, I found an interesting example of a bug at the boundary between configuration and runtime behavior: a secret was correctly passed by GitHub Actions and successfully read by the Python script, but it was never actually used in the outgoing HTTP request.

This article explains:

how the bug was discovered;
why the existing test suite did not catch it;
how the issue can be fixed;
and what this teaches us about testing pipelines that rely on secrets.

Note: This analysis is based on source-code inspection and the repository's quality suite. No production credentials or tokens were accessed, displayed, or used.

Tracing the Secret Flow

UnvibeCode includes a GitHub Actions workflow for archiving repository traffic statistics:

.github/workflows/archive-github-traffic.yml
        |
        v
.github/scripts/archive_github_traffic.py
        |
        v
GitHub Traffic API

The workflow requires a secret named TRAFFIC_TOKEN.

1. The Secret Is Passed by the Workflow

The workflow maps the GitHub Actions secret to an environment variable:

env:
  TRAFFIC_TOKEN: ${{ secrets.TRAFFIC_TOKEN }}
  GITHUB_REPOSITORY: ${{ github.repository }}

At this stage, everything appears correct. GitHub Actions makes the secret available to the environment in which the Python script runs.

2. The Python Script Reads the Secret

The script retrieves the environment variable and exits if it is missing:

TOKEN = os.environ.get("TRAFFIC_TOKEN", "").strip()

if not TOKEN:
    fail(
        "TRAFFIC_TOKEN is not set. Add a repository secret named "
        "TRAFFIC_TOKEN with read access to repository traffic."
    )

Again, the flow appears correct: the secret is available and the application successfully reads it.

3. The Secret Is Lost When the Request Is Built

The problem appears in the api_get() function:

headers = {
    "Accept": "application/vnd.github+json",
    "Authorization": f"*****",
    "User-Agent": "unvibecode-traffic-archiver",
}

The f"*****" value is not an f-string that incorporates the TOKEN variable. It is simply a string literal.

As a result, the TOKEN value that was successfully read earlier never reaches the Authorization header.

The request is then sent to several GitHub Traffic API endpoints, including:

traffic/views?per=day
traffic/clones?per=day
traffic/popular/referrers
traffic/popular/paths

If the API rejects the resulting authorization header, the workflow fails before the traffic data can be written to the CSV output.

Why Is This Bug Easy to Miss?

This finding highlights three distinct stages that should be considered when reviewing secrets in CI/CD pipelines:

Availability — Is the secret available to the workflow?
Readability — Does the application read the correct environment variable?
Usage — Does the actual runtime value reach the external API boundary?

In this case, the first two stages appeared correct. The bug only became visible at the third stage.

This is why simply reviewing configuration files is not enough. We need to trace the data flow all the way to the outgoing request.

Why Didn't the Existing Tests Catch It?

I ran the repository's quality suite, which completed successfully with:

906 passed

The test suite validates several important aspects of the repository, including:

workflow-pack structure;
scenario counts;
skill metadata;
local Markdown links;
required automation files.

However, there was no test that invoked api_get() with urlopen mocked and then inspected the resulting request headers.

In other words, the existing tests demonstrated that the repository structure and related metadata were valid, but they did not verify that the secret was actually used when the HTTP request was constructed.

This is an important distinction:

A test suite can provide strong structural coverage while still missing a critical runtime integration bug.

Recommended Fix

The authorization header should use the runtime token:

headers = {
    "Accept": "application/vnd.github+json",
    "Authorization": f"Bearer {TOKEN}",
    "User-Agent": "unvibecode-traffic-archiver",
}

The change itself is small, but it should be accompanied by a regression test.

A suitable test should:

provide a dummy token through the environment;
mock urlopen;
call api_get();
inspect the generated request;
verify that the Authorization header contains the runtime token;
ensure that the token is never printed to stdout or stderr;
continue to verify that a missing token produces a clear error.

The core assertion could be:

assert request.headers["Authorization"] == "Bearer test-token"

The actual test should use a dummy value such as test-token, never a real credential.

Engineering Lessons

1. A Secret Being Available Does Not Mean It Is Being Used

An environment variable can be correctly configured and successfully read without ever reaching the component that needs it.

For external integrations, the final boundary—such as an HTTP header, SDK argument, or subprocess invocation—must be explicitly verified.

2. Test the External Boundary, Not Just Internal Logic

For code that communicates with an API, mock the network client or network function at the point where the request leaves the application.

Verify at least:

HTTP method;
URL;
authorization headers;
relevant request parameters;
and, where appropriate, request payloads.

This approach avoids making real API calls while keeping the test fast, deterministic, and safe.

3. Never Print Secrets for Debugging

When inspecting authentication behavior, assert against the request object or sanitized metadata.

Do not print the raw token into CI logs—even temporarily.

A debugging statement such as:

print(TOKEN)

can turn a functional debugging session into a credential-exposure incident.

4. Analysis Tools Help Trace the Path, but They Do Not Replace Verification

UnvibeCode can make it easier to connect workflows, files, and dependencies and identify the path a secret takes through a repository.

However, the final conclusion still needs to be validated against the actual source code and, where possible, a test at the runtime boundary.

Static analysis can show that a variable is present.

A boundary test can show that its value is actually transmitted.

Those are different guarantees.

Conclusion

This is not an example of a secret being leaked into the repository. The problem is almost the opposite: the configured secret was never actually used.

That distinction matters.

The secret was not exposed.
The API request could nevertheless fail.
The workflow appeared to be correctly configured.
The existing tests could still pass because they did not inspect the outgoing request.

When auditing CI/CD pipelines, don't stop at the question:

"Is the secret configured?"

Ask the more important question:

"Does the secret actually reach the external boundary where it is required?"

That boundary is often where a seemingly correct configuration turns into a runtime failure.

References

Disclosure: This article was written with AI assistance for language editing and presentation. The technical finding, repository inspection, and final conclusions are based on analysis of the source code and the repository's test results.

[Boost]

Muhammad Dhiyaul Atha — Sun, 04 Oct 2026 00:47:19 +0000

Muhammad Dhiyaul Atha

Oct 3

Building a Privacy-First AI CRM Assistant for My Friend's Business

#devchallenge #weekendchallenge #hf26challenge #hacktoberfest

3 min read

Building a Privacy-First AI CRM Assistant for My Friend's Business

Muhammad Dhiyaul Atha — Sat, 03 Oct 2026 21:20:23 +0000

Matt runs a growing business, but his daily intake operation was becoming a bottleneck.

His team receives business inquiries through email, website forms, and messaging channels. The incoming information is highly inconsistent. Some inquiries are valuable sales opportunities, some are support questions, some are junk, and others simply lack enough information to make a decision.

He needed a system to ingest these inquiries, identify what they are, extract useful structured information, and draft the next response. However, sending sensitive client business data to closed-source cloud LLMs was a major privacy concern.

For the Hacktoberfest Weekend Challenge: Build for a Friend, I decided to build him a secure, locally hosted AI CRM Intake Automation System written in Go.

What I Built

I designed a practical backend system that ingests incoming messages, uses local open-source AI to classify them, extracts structured data, and prepares the next steps for a human to review.

Here is what the system does:

Ingestion & Classification: Determines if a message is a Sales Lead, Support Ticket, Junk, or Incomplete.
Extraction: Pulls out names, contact info, and business needs.
Drafting: Prepares a response based on the classification.
Human-in-the-Loop: Alerts Matt's team to review and approve the action before any CRM record is updated or any email is sent.

Demo

The prototype can process an inquiry locally and produce structured output for the next stage of the workflow.

Code

You can check out the project and its code structure here:
GitHub: CRM Automation System

How I Built It

I built the workflow engine in Go around a simple principle:

The AI analyzes the data, but deterministic code executes the actions.

The LLM is responsible for classification, extraction, and drafting. It does not directly send emails, modify CRM records, or execute arbitrary actions. The deterministic Go backend handles validation, duplicate protection, idempotency, database updates, and the audit trail.

Human-in-the-Loop

Consequential actions require human approval. Before an email is sent or a CRM record is updated, the workflow pauses and creates a pending approval for the operator to review.

// internal/workflow/approval_service.go
package workflow

import (
    "context"
    "fmt"
    "time"
)

func (s *ActionService) ApproveAction(
    ctx context.Context,
    actionID, approverID string,
) (ActionRecord, error) {
    action, err := s.repo.Get(ctx, actionID)
    if err != nil {
        return ActionRecord{}, err
    }

    if action.State != ActionStatePendingApproval {
        return ActionRecord{}, fmt.Errorf(
            "invalid approval transition from %s",
            action.State,
        )
    }

    updated := action
    updated.State = ActionStateApproved
    updated.ApprovedBy = approverID
    updated.UpdatedAt = time.Now()

    if err := s.repo.Update(ctx, updated); err != nil {
        return ActionRecord{}, err
    }

    if err := s.audit.Append(
        ctx,
        createAuditEvent(
            action.InquiryID,
            action.ID,
            "approval.granted",
            DecisionAllow,
            "approval",
        ),
    ); err != nil {
        return ActionRecord{}, err
    }

    return updated, nil
}

Why Does Open Innovation Matter?

For this project, using open-source AI locally through Ollama wasn't just a technical choice; it was a business requirement.

Data Privacy

Business inquiries can contain sensitive information such as budgets and personal contact details. By keeping AI inference local, the system does not need to send that data to a third-party LLM provider.

Cost Control

Running an open-weight model locally avoids per-token API costs for every inquiry, including messages that eventually turn out to be spam or incomplete.

Control and Predictability

Running the model locally gives me more control over the model, prompting, and output format. The Go backend validates the structured JSON response before processing it.

Conclusion

This project reinforced my interest in building AI systems where models are useful for analysis and drafting, while deterministic software and human approval remain responsible for consequential actions.

Happy hacking! 🌟

My Hacktoberfest 2026 Journey: Contributing to DevOps Daily

Muhammad Dhiyaul Atha — Thu, 01 Oct 2026 20:03:26 +0000

Hacktoberfest is back, and this year I decided to join the 7-Day DevOps Contribution Challenge hosted by @devopsdaily

I’m still learning my way around open-source contribution workflows, so I’m using this challenge as an opportunity to practice working with real repositories, following existing project conventions, and getting more comfortable with the Git workflow.

This article documents my progress so far, including how I tested my changes locally and the pull requests I submitted along the way.

Day 1: Registering as an Expert on DevOps Daily

On Day 1, the challenge focused on adding a personal expert profile to the platform's repository. Here’s what I did:

1. Creating the JSON Profile

I created a data file at content/experts/muhammad-dhiyaul-atha.json containing my professional background, social links, and core specialties in backend development, containerization, and automated deployment infrastructure.

2. Preparing the Avatar

I uploaded my avatar image in .png format to public/images/experts/muhammad-dhiyaul-atha.png to ensure the profile renders correctly.

3. Local Testing

I ran the local development server using pnpm dev to verify that the system successfully read the files.

4. Opening the Pull Request (PR)

After confirming everything was clean, I created a dedicated branch, committed, and pushed the changes:

git checkout -b hacktoberfest/add-muhammad-dhiyaul-atha
git add content/experts/muhammad-dhiyaul-atha.json public/images/experts/muhammad-dhiyaul-atha.png
git commit -m "Add Muhammad Dhiyaul Atha to experts directory"
git push origin hacktoberfest/add-muhammad-dhiyaul-atha

I then opened PR #1790 on @thedevopsdaily.

Day 2: Contributing a Favorite DevOps Tool (Lazydocker)

For Day 2, the challenge was to modify a TypeScript component and add a new tool to the curated Toolbox.

1. Choosing the Tool

I chose Lazydocker, a Go-based terminal user interface (TUI) that makes managing Docker containers and Docker Compose easier from the command line.

2. Modifying `app/toolbox/page.tsx`

I added a new configuration object to the tools array under the containers category:

{
  name: 'Lazydocker',
  description: 'A simple terminal UI for both docker and docker-compose, written in Go.',
  href: 'https://github.com/jesseduffield/lazydocker',
  category: 'containers',
  icon: Terminal,
  badges: [
    { text: 'Docker', variant: 'outline' },
    { text: 'Open Source', variant: 'secondary' },
  ],
},

3. Submitting the Second PR

Following the same Git workflow, I created a new branch, pushed the changes, and opened PR #1807 on @thedevopsdaily.

Day 3: Adding a Quiz Question to the Linux Quiz

On Day 3, the task was to contribute a multiple-choice question to an existing quiz file on the platform. Here’s what I did:

1. Selecting the Quiz File

I chose content/quizzes/linux-quiz.json and drafted an intermediate-level question focused on modern network troubleshooting in Linux using the ss command.

2. Drafting the Question & Updating Metadata

I added a new question object to the questions array:

{
  "id": "linux-check-listening-ports",
  "title": "Checking Listening Ports",
  "description": "Which command-line tool is commonly used on modern Linux distributions to inspect socket statistics and display active listening ports along with their corresponding process names?",
  "options": [
    "netstat -an",
    "ss -tulpn",
    "lsof -port",
    "ps aux --ports"
  ],
  "correctAnswer": 1,
  "explanation": "ss (socket statistics) is the modern, faster replacement for netstat. The flags -tulpn display TCP/UDP connections, listening sockets, and the numeric PIDs/program names holding them.",
  "difficulty": "intermediate",
  "points": 15
}

I also updated the totalPoints (increased to 202) and incremented the intermediate difficulty level count in the file's metadata.

3. Local Testing & Validation

Before committing, I ran the repository's test and validation commands to verify the quiz schema and metadata:

pnpm test tests/quiz-validation.test.ts

pnpm quiz:validate

4. Opening the Pull Request (PR)

After confirming everything passed successfully, I created a dedicated branch, committed, and pushed the changes:

git checkout -b hacktoberfest/add-quiz-question
git add content/quizzes/linux-quiz.json
git commit -m "Add quiz question on checking listening ports to linux-quiz"
git push origin hacktoberfest/add-quiz-question

I then opened the Pull Request on @thedevopsdaily.

Day 4: Adding Flashcards to Linux Fundamentals

On Day 4, the objective was to contribute one or two study flashcards to an existing set to help others learn DevOps and system administration concepts. Here’s what I did:

1. Selecting the Flashcard Set

I chose content/flashcards/linux-fundamentals.json since it covers essential Linux topics and fits well with my background in Linux system administration.

2. Drafting and Adding the Flashcards

I added two new flashcard objects to the end of the cards array, covering network troubleshooting with ss and systemd logs with journalctl:

{
  "id": "linux-check-listening-ports",
  "front": "How do you inspect active listening ports and their processes on modern Linux?",
  "back": "Use the ss command with flags -tulpn (ss -tulpn). It is the modern, faster replacement for netstat, displaying TCP/UDP connections, listening sockets, and the numeric PIDs/program names holding them.",
  "category": "Networking",
  "tags": ["ss", "ports", "networking", "troubleshooting"]
},
{
   "id": "journalctl-systemd-logs",
   "front": "How do you query and follow systemd logs using journalctl?",
   "back": "journalctl -u service-name views logs for a specific service. Add -f to follow live output (like tail -f), -n 50 for the last 50 lines, and --since today for recent logs. It reads binary journal logs maintained by systemd.",
   "category": "Monitoring",
   "tags": ["journalctl", "systemd", "logs", "troubleshooting"]
    }

I also updated the cardCount metadata at the top of the file, increasing it from 20 to 22.

3. Local Testing & Preview

I started the local development server to test the flashcards page and ensure the new cards rendered correctly:

pnpm dev

4. Opening the Pull Request (PR)

After confirming everything passed successfully, I created a dedicated branch, committed, and pushed the changes:

git checkout -b hacktoberfest/add-flashcard
git add content/flashcards/linux-fundamentals.json
git commit -m "Add flashcard for checking listening ports using ss to linux-fundamentals"
git push origin hacktoberfest/add-flashcard

I then opened the Pull Request on @thedevopsdaily.

Day 5: Sharing a Practical DevOps Gotcha on CI/CD Security

On Day 5, the objective shifted from adding static data (like quizzes or flashcards) to sharing a practical tip, "gotcha," or lesson learned the hard way by improving an existing guide on the platform.

1. Choosing the Right Article to Improve

I browsed through content/guides/introduction-to-cicd/ and selected 09-security-best-practices-and-production-patterns.md. Having dealt firsthand with workflow permission issues while setting up automated tasks and repository stats updaters, I knew exactly what kind of pitfall often catches developers off guard.

2. Drafting the Gotcha Section

Inside the section covering Least Privilege Access, I inserted a concise and technically accurate warning regarding GitHub Actions default token permissions:

Gotcha: If your GitHub Actions workflow fails with a "403 Forbidden" error when trying to push commits or update repository files, check the GITHUB_TOKEN permissions. Repositories can use read-only defaults for the token. If the workflow needs to write repository contents, explicitly grant the required permission, such as contents: write, in the workflow.

3. Verifying and Isolating the Branch

To keep my contribution clean and prevent stray build artifacts or previous commits from leaking into this pull request, I made sure to check out a dedicated branch from a clean state:

git checkout main
git pull origin main
git checkout -b hacktoberfest/add-tip

4. Committing and Opening the Pull Request

After verifying the changes locally, I staged only the modified guide file, committed with a clear message, and pushed to my fork:

git add content/guides/introduction-to-cicd/09-security-best-practices-and-production-patterns.md
git commit -m "docs: add github token permission gotcha"
git push -u origin hacktoberfest/add-tip

I then opened the Pull Request on @thedevopsdaily.

Conclusion

So far, this challenge has been a useful way to practice the basics of contributing to an existing open-source project.

The work itself has been relatively small, but there have still been things to learn: understanding an unfamiliar codebase, following its existing structure, testing changes locally, creating focused branches, and preparing pull requests.

I’m still in the middle of the challenge, so there is a lot more to learn and contribute. I’ll continue updating this article as I work through the remaining days of the challenge.

If you're also participating in Hacktoberfest this year, I'd be interested to hear what you've been working on.

Happy hacking! 🌟

My Experience Deploying Projects Smoothly with Tencent EdgeOne Makers

Muhammad Dhiyaul Atha — Sun, 13 Sep 2026 11:23:07 +0000

Exploring modern cloud infrastructure, edge computing, and streamlined deployment platforms has always been an exciting journey for developers. Recently, as part of the DevHandal 2026 Batch 2 program, I had the opportunity to dive deep into Tencent EdgeOne Makers, and it has genuinely changed how I approach shipping web projects efficiently.

In this article, I want to share my honest review, technical impressions, and why this platform is becoming an exceptional choice for developers looking for fast, secure, and hassle-free website deployment.

Why Tencent EdgeOne Makers Stands Out

When working on modern web applications, setting up Content Delivery Networks (CDNs), security layers like Web Application Firewalls (WAF), DDoS mitigation, and global edge routing usually takes a considerable amount of configuration overhead. Traditional setups often require juggling multiple services across different cloud providers.

EdgeOne Makers simplifies all of that by consolidating these essential features into a unified, developer-friendly ecosystem. Some of the standout features that caught my attention during my exploration include:

Global Edge Performance: Static and dynamic assets are cached and served closer to users worldwide. This architectural approach results in significantly lower latency, faster Time to First Byte (TTFB), and an overall instant page load experience.
Built-in Security Protection: Robust security measures come right out of the box. It keeps applications safe from common web vulnerabilities, malicious traffic, and DDoS attacks without requiring complex external plugins or expensive enterprise firewalls.
Streamlined Developer Workflow: The integration pipeline allows developers to spin up, configure, and deploy applications rapidly, making it ideal for both rapid prototyping and production-grade applications.

Getting Started and Deployment Experience

Deploying a project on the platform is remarkably straightforward. Whether you choose to manage your configurations via their intuitive command-line interface (CLI) or through the web dashboard, the process is streamlined to let developers focus purely on writing application code rather than wrestling with server maintenance.

When I tested deploying my project, the workflow felt natural. Here is a quick breakdown of the steps and best practices I followed:

Clean Project Initialization: Structuring project files logically so that the edge runtime can route static assets and serverless functions seamlessly.
Smooth CLI Commands: Leveraging fast local testing tools and straightforward deployment commands that push code straight to the edge network in a matter of seconds.
Generous Free Tier and Quotas: Having access to a robust free tier makes it stress-free to experiment, build, and showcase projects without worrying about unexpected upfront server costs.

My overall experience using Tencent EdgeOne Makers has been fantastic. It successfully removes the friction and complexity of traditional server management, enabling developers to ship secure, high-performance applications with absolute ease. If you haven't tried it yet, I highly recommend exploring EdgeOne Makers for your next web project. It is a powerful tool that elevates both developer productivity and end-user performance. Furthermore, the supportive ecosystem and continuous updates make it a reliable choice for long-term scalability, ensuring that hobbyists and professional developers alike can build resilient web solutions with minimal hassle. Additionally, participating in this developer program has opened up new insights into modern edge architectures.

Three Bugs That Almost Killed My Honeypot Before It Ever Caught Anyone

Muhammad Dhiyaul Atha — Thu, 10 Sep 2026 09:30:55 +0000

I built Bangk-Shield, an edge-native honeypot that runs on Cloudflare Workers. The idea is simple: sit in front of a site, watch for SQLi/RCE/SSRF/LFI/XSS/recon probes, and instead of quietly blocking them, answer with a convincing fake payload and a locally-flavored roast — while logging the real attacker's fingerprint.

The pitch is fun. The bug hunt getting it to actually work was not. Here are three failures that taught me more about edge runtimes and silent regressions than any tutorial would have.

Bug #1: The Worker That Attacked Itself

First local test run. I hit two endpoints with curl and watched the wrangler dev log:

[wrangler:info] GET /etc/passwd 500 Internal Server Error (13820ms)
[wrangler:info] GET /.env 500 Internal Server Error (13833ms)
[wrangler:info] GET /etc/passwd 500 Internal Server Error (13831ms)
[wrangler:info] GET /.env 500 Internal Server Error (13844ms)
...hundreds more lines...
[wrangler:info] GET /etc/passwd 500 Internal Server Error (20822ms)
⎔ Shutting down local server...

Two curl calls. Hundreds of log lines. Latency climbing from 13.8 seconds to 20.8 seconds before the dev server gave up and died. That climb is the tell — nothing about a single HTTP request naturally gets 7 seconds slower over its own lifetime. Something was calling itself.

The culprit was in my "passthrough" logic — the code path that forwards legitimate traffic to the real origin server:

// The bug
function passthrough(request, env) {
  if (env && env.ASSETS) {
    return env.ASSETS.fetch(request);
  }
  return fetch(request); // <-- this
}

In local dev, with no real origin configured, fetch(request) re-fetches the exact same URL — which, in wrangler dev, is the Worker's own address. The Worker calls itself. That call also fails to resolve a real backend, hits the same fail-open catch block, and calls fetch(request) again. Recursion, with no base case, burning CPU and stacking subrequests until the runtime hit a limit and returned 500.

The scary part isn't that it happened in dev. It's that this same failure mode is a documented Cloudflare Workers gotcha in production too, if a Worker's outbound fetch happens to match one of its own routes.

The fix had three parts, because I wanted defense in depth, not just a patch:

async function passthrough(request, env) {
  // 1. Loop guard — if we already forwarded this request once, stop.
  if (request.headers.get('x-bangk-shield-forwarded')) {
    return new Response('Bangk-Shield: forwarding loop detected.', { status: 508 });
  }

  if (env && env.ASSETS) return env.ASSETS.fetch(request);

  // 2. Explicit origin — never re-fetch the same host as this Worker.
  if (env && env.ORIGIN_URL) {
    const target = new URL(env.ORIGIN_URL);
    const forwardUrl = new URL(request.url);
    forwardUrl.protocol = target.protocol;
    forwardUrl.hostname = target.hostname;
    forwardUrl.port = target.port;

    const forwarded = new Request(forwardUrl.toString(), request);
    forwarded.headers.set('x-bangk-shield-forwarded', '1');
    return fetch(forwarded);
  }

  // 3. No origin configured — say so, instead of guessing and looping.
  return new Response(
    'Bangk-Shield is active, but no ORIGIN_URL is configured for legitimate traffic.',
    { status: 200 }
  );
}

Lesson: a "safe default" that just re-fetches the incoming request isn't safe. It's an assumption that something else out there is going to intercept and redirect the call before it loops. In a reverse-proxy pattern, that assumption needs to be an explicit contract (an origin URL, a binding), not implicit behavior you hope the runtime handles for you.

Bug #2: The Detector That Never Detected Path Attacks

This one didn't crash anything. It just silently did nothing, which is worse.

After a rewrite that moved detection rules into a scored, combo-bonus rule engine, I built the request context like this:

const context = {
  query: safeDecode(url.search).toLowerCase(),
  headers: userAgent.toLowerCase(),
  body: ''
};

Looks reasonable. Except: there's no path field. And the rule engine matches signals against context[target], where target comes from each signal's where array in the rules config — things like "where": ["path", "query", "body"].

Every rule that targeted path — /etc/passwd, /.env, /wp-admin, all the classic recon and LFI probes that live in the URL path rather than the query string — evaluated context['path'], got undefined, and silently failed to match. No error. No warning. The honeypot just let path-based attacks walk straight through to the real origin, forever, while confidently reporting "no threats detected."

This is the kind of bug that unit tests catch and manual clicking doesn't, because manually poking /?id=1' OR 1=1 in the query string "worked," so the feature "looked done."

The fix was one line:

const context = {
  path: safeDecode(path).toLowerCase(),   // <-- this was missing
  query: safeDecode(url.search).toLowerCase(),
  headers: userAgent.toLowerCase(),
  body: ''
};

But the fix isn't really the interesting part — the verification is. I wrote a small standalone test harness that fed known attack shapes straight into the scoring function and asserted whether they crossed the trigger threshold:

testCase('/etc/passwd in path (must trigger alone)', {
  path: '/etc/passwd', query: '', headers: 'curl/8.0', body: '',
}, true);

testCase('/.env alone (score too low, must pass through)', {
  path: '/.env', query: '', headers: 'curl/8.0', body: '',
}, false);

Running that harness against the old context shape would have failed instantly and obviously — instead of failing silently in production traffic six months later. Lesson: for a security tool, "it compiles and the demo works" is not a test suite. If a detector can fail closed (i.e., fail into "everything looks safe"), you need an explicit assertion that proves the opposite case still fires.

Bug #3: The Watermark That Lied

Every honeypot response includes a cryptographic watermark — a hash derived from the visitor's IP, User-Agent, date, and a rotating salt. The point is defensive: if someone screenshots a fake "leaked database" response and claims it's a real breach, the site owner can reproduce the hash and prove it's a decoy.

The spec (written into the project's PRD) was explicit about the exact format, because a mismatch means the hash can never be reproduced later:

Canonical: bangk-shield/v1|<ip>|<ua>|<yyyy-mm-dd>|<salt>
Output:    bs1-<first 16 hex chars of SHA-256(canonical)>

The shipped code did this instead:

const canonical = `bangk-shield|${ip}|${ua}|${dateStr}|${salt}`; // missing /v1
return `bs-${hashHex.slice(0, 16)}`;                              // missing the 1

Small diff. Big consequence: any CI test vector built against the spec format would fail against this code forever, and worse, nobody would notice until someone tried to reproduce a watermark from a real incident and got a hash that simply didn't match anything.

The second half of this bug was sneakier. The spec said the salt should live in Workers KV as a rotatable object:

// wm:salt:current
{ "salt": "a1b2c3...", "since": "2026-09-08T10:00:00Z" }

But the code read the KV value and used it directly as the salt string:

const salt = env.WATERMARK_SALT || 'default-dev-salt'; // never even reads KV

Two problems stacked on top of each other: the salt wasn't actually coming from KV at all (so "rotate without redeploy" didn't work), and if I'd naively "fixed" that by just doing await env.BANGK_KV.get('wm:salt:current'), the salt would have become the literal string '{"salt":"a1b2c3...","since":"..."}' — every watermark computed with the entire JSON blob as the salt, silently, with no error thrown anywhere.

The fix parses defensively and stays backward-compatible with plain strings during migration:

function extractSaltValue(raw) {
  if (typeof raw === 'string') {
    try {
      const parsed = JSON.parse(raw);
      if (parsed?.salt) return parsed.salt;
      return raw; // valid JSON, wrong shape — treat as a plain salt
    } catch {
      return raw; // not JSON at all — legacy plain-string salt
    }
  }
  return raw?.salt ?? null;
}

Lesson: any time two independent things (a spec doc and an implementation, or a producer and a consumer of the same data) both need to agree on a format, that agreement should be enforced somewhere machine-checkable — a schema, a fixed test vector, a shared constant — not just "well-documented." Documentation drifts. Code that has to pass a byte-for-byte comparison doesn't.

What Actually Changed My Process

None of these three bugs were exotic. They were all boring, one-line-diff mistakes. What made them dangerous was that each one failed silently — the Worker kept returning 200s, the demo kept looking fine, and the failure mode only showed up under conditions I hadn't manually tested (a request with no real origin behind it, an attack in the path instead of the query, a salt fetched from the "real" storage instead of the dev fallback).

Three things I do differently now, on this project and since:

Fail-closed the build, fail-open the runtime. A honeypot must never take down the site it's protecting — so the request path stays fail-open (any internal error just forwards traffic). But the build pipeline that compiles detection rules now fails hard on anything suspicious: invalid regex, patterns that can never match because of a later .toLowerCase(), ReDoS-prone patterns. Silent failure in the runtime is safe; silent failure in the config is not.
Test the shape of the data, not just the happy path. The path-detection bug and the salt-shape bug were both "the code runs, produces a 200, and does the wrong thing." A quick harness that asserts on expected trigger/no-trigger outcomes for known attack payloads catches this class of bug in seconds instead of after deployment.
Treat spec-vs-code drift as a bug class of its own. Once I had a real PRD with byte-exact format requirements, I started explicitly diffing "what the spec says" against "what the code does" as a review step — not just reading the code in isolation and asking "does this look reasonable?"

The project is still in beta. But it's a beta that now has a test harness, a build-time linter that can fail on purpose, and a much shorter list of ways it can lie to me about whether it's actually working.

Membangun Infrastruktur Enterprise: Part 2 - Sinkronisasi Waktu Server dengan NTP (Chrony)

Muhammad Dhiyaul Atha — Thu, 11 Jun 2026 13:26:59 +0000

Setelah berhasil melakukan konfigurasi dasar pada Main Server di Part 1, langkah krusial selanjutnya sebelum mengonfigurasi Active Directory (ADDS) adalah memastikan waktu pada sistem server benar-benar akurat. Artikel ini akan membahas langkah demi langkah instalasi dan konfigurasi NTP (Network Time Protocol) menggunakan Chrony di Ubuntu Server 26.04.

1. Teori Dasar: Mengapa NTP Sangat Krusial Sebelum ADDS?

Banyak administrator jaringan pemula melewatkan konfigurasi NTP dan langsung melompat ke instalasi Active Directory. Hal ini sering kali berujung pada kegagalan sistem yang membingungkan.

Protokol Kerberos: Active Directory Domain Services (ADDS) menggunakan protokol Kerberos untuk proses autentikasi keamanan. Kerberos menggunakan stempel waktu (timestamp) untuk mencegah serangan siber jenis replay attacks.
Toleransi Batas Waktu (Time Skew): Secara bawaan, Kerberos membatasi perbedaan waktu maksimal antara Domain Controller, server, dan komputer client sebesar 5 menit. Jika perbedaan waktu melebihi ambang batas ini, proses login user, replikasi database domain, hingga proses Join Domain pada komputer klien akan pasti ditolak dan gagal.

Oleh karena itu, server harus bertindak sebagai sumber waktu yang andal (NTP Server) bagi seluruh perangkat di dalam jaringan a3n4.com.

2. Sintaks & Langkah Konfigurasi

Pastikan Anda sudah berada di terminal Ubuntu Server 26.04 dengan hak akses root:

sudo su

Langkah A: Menonaktifkan NTP Bawaan Ubuntu

Secara bawaan, Ubuntu menggunakan layanan systemd-timesyncd untuk sinkronisasi waktu internal. Karena kita ingin server ini bertindak sebagai NTP Server mandiri (melayani request dari jaringan lokal), kita harus mematikan layanan bawaan tersebut.

timedatectl set-ntp off

Langkah B: Instalasi Chrony

Chrony adalah aplikasi NTP modern yang sangat direkomendasikan untuk Linux karena proses sinkronisasinya yang lebih cepat dan presisi dibanding daemon NTP lama.

apt update && apt install chrony -y

Langkah C: Konfigurasi Chrony Server

Buka dan edit file konfigurasi utama Chrony menggunakan nano:

nano /etc/chrony/chrony.conf

Tambahkan baris berikut di bagian bawah file untuk mengizinkan jaringan lokal 192.168.190.0/24 menyalin waktu dari server ini, serta memaksa server tetap memberikan waktu meskipun koneksi internet terputus:

allow 192.168.190.0/24
local stratum 10

Simpan file (Ctrl + O, lalu Enter) dan keluar (Ctrl + X).

Langkah D: Restart & Aktivasi Layanan

Terapkan konfigurasi baru dengan merestart layanan Chrony dan pastikan statusnya berjalan otomatis saat booting.

systemctl enable chrony
systemctl restart chrony
systemctl status chrony

3. Pengujian & Verifikasi

Langkah A: Memeriksa Port NTP (123)

NTP berjalan di atas protokol UDP port 123. Pastikan socket port tersebut sudah terbuka dan didengarkan (listen) oleh Chrony.

ss -unlp | grep 123

Langkah B: Verifikasi Sumber Waktu & Pelacakan

Pastikan Chrony sukses terhubung ke server waktu publik di internet untuk menyinkronkan jam internalnya.

chronyc sources
chronyc tracking

Kesimpulan

Dengan menyelesaikan konfigurasi NTP menggunakan Chrony, kita telah memastikan bahwa jam internal pada Ubuntu Server 26.04 berjalan dengan akurasi tinggi dan siap melayani permintaan sinkronisasi dari komputer client. Sinkronisasi waktu ini meminimalkan risiko kegagalan otentikasi di masa mendatang.

Apa Selanjutnya?

Waktu server sudah akurat dan siap. Di artikel berikutnya (Part 3), kita akan masuk ke tahap paling krusial dari seluruh proyek ini: Membangun Active Directory Domain Services (ADDS) menggunakan Samba untuk menginisiasi domain utama kita, a3n4.com.

Baca Part 3: Membangun Active Directory Domain Controller (ADDS) dengan Samba ➡️