DEV Community: Adrian

From Zero to 3 Merged PRs: Contributing Python CLI Recipes to BasedHardware/omi

Adrian — Wed, 23 Sep 2026 07:39:54 +0000

Over the past few weeks, I’ve been contributing to BasedHardware/omi, the open-source AI wearable project. As of this week, all three of my pull requests have been officially approved and merged into main by core maintainers and Omi's founder Nik Shevchenko (@kodjima33).

Here is a quick recap of the journey, the recipes built, and 3 key engineering lessons learned along the way.

🚀 What We Built: The Python CLI Recipe Trilogy

The goal was to enable Omi users to seamlessly export and structure their conversational data without needing complex setups or external dependencies.

PR #13701: Conversations to Markdown
- Built a lightweight CLI recipe to convert raw conversation JSON dumps into structured Markdown compatible with Obsidian, Notion, and local notes.
- Handled UTF-8 character encoding and atomic file writing to prevent corrupt exports.
PR #14458: Memories Export with Categorization
- Created an exporter for Omi's memory stream, organizing insights by date and category tags.
PR #13960: Action Items to Markdown with Full Unit Tests
- The most rigorous of the three! This recipe extracts action items and checklists into formatted task lists.
- When maintainer Aryan Gupta noted that earlier attempts had messy merge commits and no tests, I went back to the drawing board:
  - Implemented 9 comprehensive unit tests using Python’s standard unittest (all 9 passed in 0.05s).
  - Executed a clean linear git rebase on origin/main to eliminate redundant commits.
  - Result: Received quick approval from @kodjima33 and was merged directly into the core repo.

💡 3 Key Lessons Learned

1. Zero External Dependencies Win Every Time

In open-source CLI tools, relying on third-party libraries introduces dependency bloat and breaking changes across user environments. Writing scripts purely with Python's standard library (urllib.request, json, datetime, argparse) guarantees that anyone can run the recipe out of the box with zero setup pain.

2. Welcome Tough Maintainer Feedback

When a maintainer asks for tests or calls a branch dirty, don't get discouraged — treat it as free mentorship. Adding automated tests not only got the PR merged, but it also made the code unbreakable against future regressions.

3. Keep Git History Squeaky Clean

Interactive rebasing and keeping commits atomic is a superpower. A clean, single-commit PR with passing CI makes a maintainer's job 10x easier to review and click "Merge".

🔮 What’s Next?

I’m currently looking into extending these recipes to support direct third-party REST API payloads (like Todoist tasks and Notion blocks).

Contributing to active AI hardware/software projects is one of the fastest ways to level up real-world software engineering skills.

Have you contributed to open-source recently? What was your biggest takeaway from working with repository maintainers? Let's discuss below! 👇

How to Find, Fix, and Earn from Open Source Bug Bounties: A Developer's Guide

Adrian — Wed, 09 Sep 2026 14:04:44 +0000

Every developer wants to contribute to open source. But navigating issue trackers, submitting clean PRs, and getting your code merged can feel daunting — especially when real bug bounties or payouts are involved.

Over the past few weeks, I've been active in open-source bug bounty hunting across repositories like Gyroflow, Drizzle ORM, EdgeChains, and OphirPay. Here is my exact workflow, technical setup, and lessons learned.

1. 🔍 Finding High-Value & Low-Risk Issues

Not all bounties or issues are created equal. When selecting issues to work on:

Check Escrow & Maintainer Trust: Look for issues with verified escrow bots or active core maintainers who merge PRs consistently.
Analyze Competition: Review existing open PRs. If 30+ PRs are already open for a single typo or simple fix, your time is better spent elsewhere.
Focus on Core Value: Look for well-defined technical issues — such as missing database schemas, edge-case parser fixes, or cross-platform metadata support.

2. 🧪 Deep Technical Investigation Before Writing Code

Before writing a single line of code:

Local Reproduction: Write an isolated reproduction script or test runner.
Architecture Audit: Understand how data flows through the upstream codebase (e.g., how result rows map in ORMs or how camera lens definitions are parsed).
Check Test Suites: Ensure you can run local unit tests clean before making modifications.

3. 🤝 Collaboration Over Competition

One of the biggest mistakes contributors make is fighting over single issues. On complex issues (like multi-part feature requests):

Propose Scope Splits: Split back-end schema work from front-end UI selectors.
Communicate Early in Comments: Let maintainers and other contributors know what part of the issue you are taking on.
Tag Core Maintainers: Agree on clean scope divisions so everyone gets credit and payouts are distributed fairly.

4. 🛡️ PR Submission Checklist

When opening your Pull Request:

[x] Clear title referencing Fixes #IssueNumber
[x] Concise breakdown of changes made and tests run
[x] Contributor License Agreement (CLA) signed
[x] Zero merge conflicts with main / master

💡 Key Takeaway

Open-source bug bounty hunting isn't just about quick payouts — it's about building a verified public track record, learning real-world production codebases, and collaborating with global developers.

What's your experience with open-source bounties or pull requests? Let's discuss in the comments below!

How I Built 16 Developer Tools with Zero Backend and Full Privacy – and You Can Too

Adrian — Tue, 08 Sep 2026 12:45:15 +0000

Modern web development often overcomplicates simple utilities. Why spin up Node.js microservices, Postgres clusters, and Redis caches just to format JSON, test regular expressions, redact API keys, or calculate loan amortization?

In this article, I want to share the exact architectural principles, client-side engineering practices, and lessons learned while building a suite of high-utility, privacy-first developer tools — hosted entirely as zero-backend static web applications.

1. The Core Philosophy: Client-Side Sovereignty

When developers paste internal configs, JWT tokens, customer payloads, or financial figures into online web tools, they take a privacy risk. Even well-intentioned platforms frequently log request payloads to telemetry, ingest data into LLM training corpuses, or leak secrets through CDN access logs.

My premise was simple:

Zero Backend Required: All data transformations occur 100% inside the user's browser sandbox using vanilla Web APIs and Web Workers.
Offline-Ready: Once loaded, these tools function completely offline without internet access.
Instant Latency: No round-trip API delays. Processing happens at sub-millisecond local execution speeds.

2. The Applications in Action

Here is the live suite that embodies these principles:

🛠️ 1. OmniTools Pro

A powerhouse client-side utility hub featuring 16 integrated developer tools:

JSON Formatter & Schema Validator: Instant formatting, minify, sorting, and error inspection.
JWT Decoder & Inspector: Client-side token header/claims decoding without sending signatures over the wire.
Regex Tester & Sandbox: Real-time regex pattern testing with capture groups and highlight overlays.
Base64, URL, Hash Generation: Instant SHA-256, SHA-512, and HMAC processing using native browser WebCrypto API (window.crypto.subtle).
Markdown Live Preview: Responsive split-pane live editor with instant AST compilation.

👉 Live Demo: https://omnitools-pro.surge.sh

🧠 2. AI PromptLab Pro

An intelligent prompt engineering laboratory for creators and engineers:

Client-side PII Masking: Automatically detects and redacts emails, API keys, phone numbers, and names before prompts are copied into AI models.
Prompt Token Counter: Accurate BPE token estimations directly in the browser.
Variables & Template Engine: Dynamic slot insertion for systematic prompt optimization.

👉 Live Demo: https://aipromptlab-pro.surge.sh

📊 3. FinCalc Pro

High-precision financial calculators running pure client-side math:

Loan amortization with dynamic amortization tables and SVG charts.
Investment growth projections with compound interest intervals.
Fire/Retirement trajectory modelling with custom inflation vectors.

👉 Live Demo: https://fincalc-pro.surge.sh

🌐 4. Personal & Engineering Portfolio

Showcasing the philosophy, benchmark metrics, and open-source contributions.

👉 Live Demo: https://elvin-portfolio.surge.sh

3. Key Architecture & Engineering Takeaways

A. Leverage Native Web APIs

Instead of bloated npm dependencies:

WebCrypto API (crypto.subtle): Delivers hardware-accelerated cryptographic hashes (SHA-256, HMAC) with zero dependencies.
Web Workers: For large file processing (e.g. 10MB+ JSON datasets), offload parse routines to worker threads to keep the UI thread responsive at 60 FPS.
Canvas & SVG: Lightweight data visualization without requiring heavy charting libraries.

B. Deploying to Edge Without Servers

Hosting is powered entirely by static edge distribution (Surge.sh / GitHub Pages / Cloudflare Pages). Deployment takes seconds, requires zero server maintenance, and costs $0 in database operations.

4. Support the Project & Source Code Access

If you find these tools helpful or want to deploy your own customized developer toolkit:

⭐️ Check out the live applications above.
☕ Support the Project / Buy Me a Coffee: Buy Me a Coffee | PayPal
📦 Source Code Packages & Commercial License: Full modular source code available on our toolkit bundle.

Let me know in the comments: What is the single most important utility tool you use every day, and how do you protect sensitive data when using online tools?

Why parsing a 10MB JSON payload freezes your UI thread (and how to offload it to Web Workers)

Adrian — Mon, 07 Sep 2026 14:51:10 +0000

If you have ever built a dashboard or data analysis tool in JavaScript, you have probably run into this scenario: your app fetches a large JSON payload (say, 5MB to 20MB of raw records), runs JSON.parse(data), and for 300ms to 1.5 seconds, the entire browser tab completely freezes.

Buttons don't click. CSS animations drop to 0 FPS. The browser might even throw an "Unresponsive Script" warning.

Here is why that happens, why most developers handle it wrong, and how to offload heavy JSON operations to native Web Workers with zero external libraries.

The Problem: JavaScript is Single-Threaded

The browser executes your JavaScript, layout calculations, and UI rendering on a single main thread.

When you execute:

const records = JSON.parse(hugeRawString);
const filtered = records.filter(item => item.active);

The main thread cannot paint a single frame or respond to user inputs until JSON.parse and filter have completely finished traversing the entire object graph.

Even on modern M-series or high-end x86 CPUs, parsing a 15MB JSON file can take 400ms+. On mobile devices, it can easily take 2-4 seconds.

The Bad Fix: `setTimeout` or `async/await`

A common misconception is that wrapping JSON.parse in a Promise or setTimeout makes it non-blocking:

// ❌ THIS STILL BLOCKS THE UI THREAD!
async function parseDataAsync(raw) {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve(JSON.parse(raw));
    }, 0);
  });
}

While setTimeout pushes the task to the next event loop tick, the moment that task executes, JSON.parse still runs synchronously on the main thread, locking the UI for the exact same amount of time.

The Clean Solution: Inline Web Worker Dispatch

Instead of adding a 50KB npm package, you can spawn an isolated Web Worker using a Blob and URL.createObjectURL. This runs in a separate OS thread without needing a separate hosted worker file:

function parseJsonInWorker(jsonString) {
  return new Promise((resolve, reject) => {
    const workerCode = `
      self.onmessage = function(e) {
        try {
          const parsed = JSON.parse(e.data);
          self.postMessage({ success: true, data: parsed });
        } catch (err) {
          self.postMessage({ success: false, error: err.message });
        }
      };
    `;

    const blob = new Blob([workerCode], { type: 'application/javascript' });
    const workerUrl = URL.createObjectURL(blob);
    const worker = new Worker(workerUrl);

    worker.onmessage = (event) => {
      const { success, data, error } = event.data;
      cleanup();
      if (success) {
        resolve(data);
      } else {
        reject(new Error(error));
      }
    };

    worker.onerror = (err) => {
      cleanup();
      reject(err);
    };

    function cleanup() {
      worker.terminate();
      URL.revokeObjectURL(workerUrl);
    }

    worker.postMessage(jsonString);
  });
}

Benchmarks & Real-World Impact

In our tests processing a 12.4 MB mock database export (approx 85,000 nested JSON objects):

Metric	Main Thread `JSON.parse`	Web Worker Pipeline
Main Thread Lock Time	680 ms (UI Frozen)	0 ms (60 FPS Constant)
Total Computation Time	~710 ms	~740 ms (incl. message clone)
User Experience	Page stutter / freeze	Smooth progress spinner

Although the total CPU time is slightly higher due to structured cloning across thread boundaries, the Main Thread stays completely responsive. Input sliders, cancel buttons, and loading animations continue to render at 60 FPS.

Where to Use This Architecture

This exact worker pattern is what powers the client-side JSON parser, YAML validator, and Diff engine inside OmniTools Pro. Even when diffing two massive files, the UI never stutters because computation happens entirely in background threads.

Have you tackled large JSON bottlenecks in your frontend apps? What's your go-to strategy? Let's discuss in the comments below!

Why your JSON and Regex tools shouldn't send data to a backend (and how I built a zero-leak client suite)

Adrian — Mon, 07 Sep 2026 14:44:54 +0000

Every developer does it at least once a week: you get an unformatted 2MB payload from an internal endpoint or a complex regex string from a colleague, and you throw it into an online web formatter or tester.

The problem? Most top search results for "JSON formatter" or "JWT debugger" are laden with heavy ad trackers, telemetry pixels, and in several cases, quietly transmit the pasted text back to an external server. If that payload contains authorization headers, customer PII, API secrets, or internal database IDs, you have just unknowingly leaked confidential data.

I got tired of worrying about this, so I built OmniTools Pro — a suite of 16 developer utilities that runs 100% inside your browser with zero backend data transmission.

How it works (and why the architecture matters)

Zero Server Footprint for Processing:
All operations—JSON parsing, YAML conversions, JWT decoding, UUID generation, Diff comparisons, and SHA/MD5 hashing—execute inside local Web Workers and standard Web APIs (crypto.subtle, JSON.parse). If you open your browser DevTools Network tab while using the tool, you will see zero outgoing POST requests.
Offline-First PWA:
The entire site is cached via a lightweight Service Worker. Once loaded once, you can turn off your Wi-Fi and format or diff code completely offline.
Sub-second Load Times:
Zero heavy frameworks, zero third-party tracking scripts. Pure vanilla HTML, modular JS, and clean CSS running on Global Edge CDN.

Live Demo & Feedback

You can test it out live here: https://omnitools-pro.surge.sh

I built this primarily to solve my own workflow friction, but I hope it saves other developers time and eliminates unnecessary privacy risks. If you run into edge cases or want additional offline utilities added, let me know in the comments!