Extiri Blog

Your Whole Stack, One Place: Introducing Resso

Thu, 30 Apr 2026 00:00:00 +0200

At some point, managing your own infrastructure stops being a background task and starts being a part-time job.

For me, that point came somewhere around the third cloud VM. I had three servers, a handful of domains, over eight apps and projects across different environments, Vercel deployments, SaaS accounts with their own API keys and 2FA setups, and a growing list of things I was fairly sure I remembered, but was not entirely sure about. Which SSH key goes to which server? What registrar holds that domain, and when does it expire? Which environment variable in which project points to the staging database?

The answers were scattered. Some lived in a notes app, some in a password manager, some just in my head. None of those places talk to each other, and none of them give you a picture of how everything connects.

I built Resso to fix this.

What Resso does

Resso is a native macOS app for managing your infrastructure assets. Not just listing them, but actually organizing them in a way that reflects how they relate to each other.

The core idea is that everything in your stack is an asset. A server is an asset. A domain is an asset. An app, a cloud account, a SaaS subscription are all assets. Resso gives each of them a home, a structure, and a way to link to everything else it touches.

Once your assets are in, the app starts to do something genuinely useful: it shows you your infrastructure as a graph. You can see your staging environment linked to production, your payment processor connected to the apps that depend on it, your servers holding the deployments that run on them. The dependencies that were invisible before are now visible, and staying on top of them stops feeling like a memory exercise.

Built for the kind of setup that grows sideways

Solo developers and small studios tend to accumulate infrastructure organically. You spin up a server here, register a domain there, add a Vercel project, hook in Stripe, maybe pick up a second server when the first one starts to feel crowded. Before long, you have a real stack, with real interdependencies, and almost nothing to help you reason about it as a whole.

Resso is designed for exactly this kind of setup. The focus is on giving you a clear mental model of what you have, so you can maintain it and build on it without constantly reconstructing that picture from scratch.

For solopreneurs specifically, Resso acts as a central knowledge base. You store server IPs, providers, monthly costs, and renewal dates. You track domain registrars, expiration dates, and auto-renewal status. You keep app bundle IDs, platforms, and repository URLs organized. You manage account usernames, emails, and service names. All in one place, all searchable, all structured consistently.

Assets with real structure

Resso ships with standard templates for the things most developers actually manage.

Servers capture IP addresses, providers, monthly costs, and renewal dates. When you have three VMs across different providers, having this in one structured format instead of three different notes is already a meaningful upgrade.

Domains track registrars, expiration dates, and auto-renewal status. Domain expiry is one of those things that will eventually catch you off-guard if you are not watching it somewhere intentional. Resso is intentional about it.

Apps store bundle IDs, platforms, and repository URLs. The full picture of how a project is identified and where its code lives, all in one structured view.

Accounts track service names, usernames, and email addresses. Useful when you need to find which credentials belong to which service without opening five browser tabs.

Beyond these templates, Resso also supports custom entities. If your stack has something specific that does not fit a standard mold, you can define your own asset type with its own properties. The app does not assume it knows every shape infrastructure can take.

The graph view

The visual dependency graph is one of the things that sets Resso apart from a well-organized notes app.

When you start linking assets together, the graph view turns those connections into something you can actually see and navigate. You get a spatial map of your infrastructure: which servers host which apps, which apps talk to which external services, which accounts own which resources. That kind of map is surprisingly hard to hold in your head, and extremely useful to have on screen.

The graph also makes gaps obvious. If a service is floating without documented connections, you notice it. If something is linked to a dependency that has not been fully set up yet, you can see that too. It becomes much easier to reason about the health of your setup when the setup has a shape.

Filtering that actually handles complexity

As the number of assets grows, search and filtering become essential. Resso has a filter engine that supports complex logic across different property types.

You can combine string, numeric, and date conditions. You can filter by whether a value contains something, falls below a threshold, or precedes a specific date. The idea is that when you have hundreds of assets across different categories, finding exactly what you need should not involve scrolling.

The filtering is fast enough that it does not slow you down. The goal is to make your asset library feel small even when it is not.

iCloud sync and offline support

Resso syncs via iCloud, which means your assets are available across your Macs without any extra setup. If you work across a laptop and a desktop, or want to access your infrastructure notes from a secondary machine, the library stays current.

The app also works fully offline. Infrastructure management is not always done in ideal network conditions, and Resso does not require connectivity to be useful.

Why a native Mac app

There are web-based tools for some of this. Spreadsheets, Notion databases, purpose-built SaaS products. Most of them are either too generic to be useful or too enterprise-focused to be practical for a solo developer who just wants to know when their domain expires and where to find the SSH key for their staging server.

A native Mac app that lives in your dock and opens instantly is a different kind of tool. It fits into the way you actually work instead of adding another browser tab to the pile. Resso requires macOS 26 or later and is available on the Mac App Store.

If you manage your own infrastructure, Resso is worth a look. The first few hours of setting it up will pay back quickly the next time you need to find something you were certain you remembered.

Try Resso for free on the Mac App Store

Manage your infrastructure assets with ease. Works on macOS 26 or later.

Download Resso on the App Store

The Power of Elegant Simplicity #2: Bloom Filters — The Data Structure That's Okay With Being Wrong

Sun, 12 Apr 2026 00:00:00 +0200

Part of the “The Power of Elegant Simplicity” series - algorithms that hide power in plain sight

You know what’s refreshing? An algorithm that looks you in the eye, shrugs, and says: “Look, I might be wrong. But I’m never wrong in that direction.”

Welcome to Bloom Filters — a probabilistic data structure so audaciously simple that it uses a handful of hash functions and a bit array to answer membership queries at lightning speed. No linked lists, no tree traversals, no disk reads. Just bits and honesty about its own limitations.

The Problem: Checking Without Knowing Everything

Let’s say you’re building a web crawler. Every second, you’re discovering thousands of URLs. You need to know: have I visited this URL before?

One approach: keep a giant set of every URL you’ve ever seen. Query it before each visit.

Sounds fine, until you realize you’ve crawled a billion pages. Storing a billion URLs takes serious memory — often tens or hundreds of gigabytes. Suddenly your crawler is spending more time juggling memory than actually crawling.

What if you could answer “have I seen this before?” using a fraction of the memory? What if the only trade-off was occasionally a false positive — claiming you’ve seen something you haven’t?

For many applications, that’s a completely acceptable deal. You re-check false positives. You never miss true ones.

That’s Bloom Filters in a nutshell.

The Ingredients: Embarrassingly Simple

A Bloom Filter is just two things:

A bit array of size m, initialized to all zeros.
k independent hash functions, each mapping any input to an index in [0, m-1].

That’s it. No pointers. No nodes. No dynamic allocation. Just a flat array of bits and some hash functions.

![Bloom Filter diagram showing a bit array with bits set by multiple hash functions for two elements]

How It Works: Inserting an Element

When you want to add an element to the filter, you run it through all k hash functions. Each one gives you an index. You flip those k bits in the array to 1.

def add(bloom_filter, item, hash_functions, m):
    """
    Add an item to the Bloom Filter.
    
    Args:
        bloom_filter: List of m bits (integers 0 or 1)
        item: The item to add
        hash_functions: List of k hash functions
        m: Size of the bit array
    """
    for h in hash_functions:
        index = h(item) % m
        bloom_filter[index] = 1

Let’s say we have a bit array of size 16 and 3 hash functions. We add the word "apple":

h1("apple") % 16 = 3 → set bit 3
h2("apple") % 16 = 7 → set bit 7
h3("apple") % 16 = 13 → set bit 13

Now we add "banana":

h1("banana") % 16 = 0 → set bit 0
h2("banana") % 16 = 7 → set bit 7 (already set — no problem)
h3("banana") % 16 = 11 → set bit 11

Our filter after two insertions:

Index: 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
Bits:  1  0  0  1  0  0  0  1  0  0  0  1  0  1  0  0

How It Works: Querying an Element

To check if an element is in the set, run it through all k hash functions and look up those indices.

If any bit is 0 → the element is definitely not in the set. No way around it. You never set those bits, so the element was never added.
If all bits are 1 → the element is probably in the set.

def contains(bloom_filter, item, hash_functions, m):
    """
    Check if an item is probably in the set.
    
    Returns:
        False: Item is DEFINITELY NOT in the set.
        True:  Item is PROBABLY in the set (might be a false positive).
    """
    for h in hash_functions:
        index = h(item) % m
        if bloom_filter[index] == 0:
            return False
    return True

Let’s check for "cherry":

h1("cherry") % 16 = 3 → bit 3 is 1 ✓
h2("cherry") % 16 = 7 → bit 7 is 1 ✓
h3("cherry") % 16 = 11 → bit 11 is 1 ✓

All bits are set! But we never added "cherry". This is a false positive — "cherry" just happened to hash to positions that were already set by "apple" and "banana". The filter says “probably yes” when the truth is “definitely no.”

This is the deal you make with a Bloom Filter. You accept the occasional false positive. In return, you get blazing-fast queries and microscopic memory usage.

Crucially, there are no false negatives. If an element was added, every bit it set stays set — they’ll all be 1 when you query. The filter will never tell you “not in set” when it actually is.

The Math Behind the Trade-Off

Here’s where it gets surprisingly elegant. The false positive rate is not arbitrary or unpredictable — it’s precisely calculable.

Given:

m = size of the bit array
n = number of elements inserted
k = number of hash functions

The probability of a false positive is approximately:

1	p ≈ (1 - e^(-kn/m))^k

This formula is beautiful because it tells you exactly how to tune your filter:

The optimal number of hash functions for a given m and n is:

1	k = (m/n) * ln(2) ≈ 0.693 * (m/n)

The required bit array size to achieve a target false positive rate p:

1	m = -n * ln(p) / (ln(2))²

Let’s say you want to track 1 million URLs with a 1% false positive rate. How much memory do you need?

import math

n = 1_000_000  # elements
p = 0.01       # 1% false positive rate

m = -n * math.log(p) / (math.log(2) ** 2)
k = (m / n) * math.log(2)

print(f"Bit array size: {m:,.0f} bits ({m / 8 / 1024 / 1024:.2f} MB)")
print(f"Optimal hash functions: {k:.1f}")

Output:

Bit array size: 9,585,059 bits (1.14 MB)
Optimal hash functions: 6.6

1.14 megabytes to track a million URLs with 1% false positives. A naive Python set of those same URLs would consume hundreds of megabytes. Often an order of magnitude or more of memory reduction.

A Complete Implementation

Here’s a clean, practical Bloom Filter using Python:

import math
import hashlib


class BloomFilter:
    """
    A space-efficient probabilistic data structure for set membership queries.
    
    Guarantees:
        - No false negatives: if an item was added, contains() always returns True.
        - Bounded false positives: probability is calculable from n, m, and k.
    """
    
    def __init__(self, capacity: int, error_rate: float = 0.01):
        """
        Initialize a Bloom Filter.
        
        Args:
            capacity: Expected number of elements to insert.
            error_rate: Desired false positive probability (e.g., 0.01 = 1%).
        """
        self.capacity = capacity
        self.error_rate = error_rate
        
        # Calculate optimal parameters
        self.m = self._optimal_m(capacity, error_rate)
        self.k = self._optimal_k(self.m, capacity)
        
        # Bit array using a bytearray for memory efficiency
        self.bit_array = bytearray(math.ceil(self.m / 8))
        self.count = 0
        
        print(f"Bloom Filter initialized:")
        print(f"  Bit array size: {self.m:,} bits ({self.m / 8 / 1024:.1f} KB)")
        print(f"  Hash functions: {self.k}")
    
    @staticmethod
    def _optimal_m(n: int, p: float) -> int:
        """Optimal bit array size for n elements and false positive rate p."""
        return math.ceil(-n * math.log(p) / (math.log(2) ** 2))
    
    @staticmethod
    def _optimal_k(m: int, n: int) -> int:
        """Optimal number of hash functions."""
        return max(1, round((m / n) * math.log(2)))
    
    def _hash_indices(self, item: str):
        """Generate k hash indices for an item using double hashing."""
        # Two base hashes from different algorithms
        h1 = int(hashlib.md5(item.encode()).hexdigest(), 16)
        h2 = int(hashlib.sha1(item.encode()).hexdigest(), 16)
        
        # Generate k indices using linear combination (Kirsch-Mitzenmacher)
        for i in range(self.k):
            yield (h1 + i * h2) % self.m
    
    def _set_bit(self, index: int):
        byte_index = index // 8
        bit_offset = index % 8
        self.bit_array[byte_index] |= (1 << bit_offset)
    
    def _get_bit(self, index: int) -> bool:
        byte_index = index // 8
        bit_offset = index % 8
        return bool(self.bit_array[byte_index] & (1 << bit_offset))
    
    def add(self, item: str):
        """Add an item to the filter."""
        for index in self._hash_indices(item):
            self._set_bit(index)
        self.count += 1
    
    def contains(self, item: str) -> bool:
        """
        Check if item is in the set.
        
        Returns:
            False → item is DEFINITELY NOT in the set.
            True  → item is PROBABLY in the set (may be a false positive).
        """
        return all(self._get_bit(index) for index in self._hash_indices(item))
    
    @property
    def estimated_false_positive_rate(self) -> float:
        """Estimated current false positive rate based on elements inserted."""
        return (1 - math.e ** (-self.k * self.count / self.m)) ** self.k


# Example: URL deduplication for a web crawler
bf = BloomFilter(capacity=1_000_000, error_rate=0.01)

urls_to_crawl = [
    "https://example.com/page-1",
    "https://example.com/page-2",
    "https://example.com/page-1",  # Duplicate!
]

for url in urls_to_crawl:
    if bf.contains(url):
        print(f"Skipping (already seen): {url}")
    else:
        bf.add(url)
        print(f"Crawling: {url}")

# Output:
# Crawling: https://example.com/page-1
# Crawling: https://example.com/page-2
# Skipping (already seen): https://example.com/page-1

Note, this implementation uses cryptographic hashes for simplicity, but in production, you should use other faster hash functions.

Notice the use of the Kirsch-Mitzenmacher trick: instead of implementing k fully independent hash functions (expensive and complex), we use two base hashes and linearly combine them: h(i) = h1 + i * h2. It’s been mathematically proven to achieve asymptotically the same error rate as truly independent hashes — another layer of elegance.

Why This is Actually Mind-Blowing

Memory efficiency that borders on magical: You’re representing the possible presence of millions of items in a structure orders of magnitude smaller than the items themselves. You’re storing shadows of items, not the items.

Constant time, always: Both add and contains are O(k) — constant with respect to the number of elements in the filter. Whether you’ve inserted ten items or ten billion, each query runs through exactly k hash functions and looks up k bits. No searching, no sorting, no tree traversal.

Tunable trade-offs: The relationship between memory, speed, and accuracy is explicit and mathematical. You’re not guessing — you’re engineering. Want 0.1% false positives instead of 1%? The formula tells you exactly how many more bits you need.

Asymmetric error: False negatives are impossible. This asymmetry is often exactly what you want. In caching, in spam filtering, in security — you’d much rather occasionally check something twice than miss something you should have caught.

The Real-World Roster

Bloom Filters aren’t academic curiosities. They’re quietly running in systems you use every day:

Google Chrome’s Safe Browsing: Before making a network call to check if a URL is malicious, Chrome checks a local Bloom Filter. If it’s definitely not in the filter, no network call needed. Only potential hits require verification. This makes Safe Browsing both fast and private.

Apache Cassandra and other databases: Cassandra uses Bloom Filters to avoid disk reads. Before checking whether a row exists in an SSTable (which requires an expensive I/O operation), it checks the filter. A definite miss skips the disk entirely.

Bitcoin: Bitcoin’s SPV (Simple Payment Verification) nodes use Bloom Filters to request only relevant transactions from full nodes, without revealing exactly which addresses they’re interested in.

Akamai CDN: One of the largest CDN operators uses Bloom Filters to avoid caching “one-hit-wonders” — URLs requested exactly once, which would pollute the cache without providing value to future users. The filter tracks whether a URL has been seen before; it only gets cached on the second hit.

Medium, Reddit, and recommendation systems: To avoid showing you the same article twice, these platforms can use Bloom Filters to track what you’ve already seen — per user, at scale, with negligible memory overhead.

The Limitations (Honesty Is Part of the Package)

No deletions (mostly): Once a bit is set to 1, you can’t safely set it back to 0 — other elements might share that bit. If you need deletions, you need a Counting Bloom Filter, which stores counters instead of bits (incrementing on add, decrementing on remove). This trades some memory efficiency for mutability.

No retrieval: A Bloom Filter tells you whether something is in the set, not what is in the set. You can’t iterate over elements. You can’t get an element back. It’s pure membership testing.

One-way resizing: Unlike a hash table, you can’t cleanly resize a Bloom Filter. If you add far more elements than planned, your false positive rate degrades. You’d need to rebuild from scratch. Plan your capacity upfront, or use scalable Bloom Filters — a layered approach that adds new filter layers as capacity fills.

Hash function quality matters: Poor hash functions lead to clustering — many items mapping to the same bits — which inflates the false positive rate. Use cryptographic or well-tested non-cryptographic hashes (MurmurHash3, xxHash, FNV-1a) in production. The Kirsch-Mitzenmacher trick helps you get away with two good hashes instead of implementing k fully independent ones.

The Philosophical Bit

Here’s what I find most elegant about Bloom Filters: they institutionalize the right kind of uncertainty.

Most data structures pretend certainty. Hash tables say “definitely yes” or “definitely no.” Binary search trees say “this is exactly where it is.” That’s usually what you want.

But Bloom Filters say something more nuanced: “I can tell you for certain when something is NOT here. As for whether it IS here — I’m probably right, but you might want to double-check.”

This asymmetric honesty is surprisingly powerful. In many real systems, a definite “no” is more valuable than a certain “yes” — because “no” lets you skip expensive work entirely.

It’s a bit like a good bouncer who never lets innocent people through by mistake — but occasionally turns away someone with a slightly unusual ID. The asymmetry is the feature, not the bug.

Try It Yourself

Here’s a small experiment to make the math tangible:

import math
import hashlib
import random
import string


def make_bloom_filter(capacity, error_rate):
    m = math.ceil(-capacity * math.log(error_rate) / (math.log(2) ** 2))
    k = max(1, round((m / capacity) * math.log(2)))
    bits = bytearray(math.ceil(m / 8))
    
    def hashes(item):
        h1 = int(hashlib.md5(item.encode()).hexdigest(), 16)
        h2 = int(hashlib.sha1(item.encode()).hexdigest(), 16)
        return [(h1 + i * h2) % m for i in range(k)]
    
    def add(item):
        for idx in hashes(item):
            bits[idx // 8] |= (1 << (idx % 8))
    
    def contains(item):
        return all(bits[idx // 8] & (1 << (idx % 8)) for idx in hashes(item))
    
    return add, contains, m, k


# Create a filter for 10,000 items at 1% false positive rate
add, contains, m, k = make_bloom_filter(10_000, 0.01)
print(f"Bit array: {m:,} bits | Hash functions: {k}")

# Add 10,000 random "known" items
known = set()
for _ in range(10_000):
    word = ''.join(random.choices(string.ascii_lowercase, k=10))
    known.add(word)
    add(word)

# Test 10,000 "unknown" items and count false positives
false_positives = 0
trials = 10_000
for _ in range(trials):
    word = ''.join(random.choices(string.ascii_lowercase, k=12))  # longer = unlikely to collide
    if word not in known and contains(word):
        false_positives += 1

print(f"False positive rate: {false_positives / trials:.2%}  (target: 1.00%)")
print(f"False negatives: 0  (guaranteed by construction)")

Run it yourself and watch the false positive rate hover right around 1% — not by luck, but by math.

The Takeaway

Bloom Filters are the rare algorithm that teaches you something philosophical alongside something practical.

Practically: you can represent set membership for millions of items in kilobytes of memory, with constant-time operations, by accepting a controllable, asymmetric error rate.

Philosophically: sometimes the most powerful thing you can do is clearly define what kind of wrong you’re willing to be — and build that honesty into your system’s architecture.

A bit array and some hash functions. Probabilistic guarantees that hold up under mathematical scrutiny. Deployed at Google, Cassandra, Bitcoin, and your browser.

Elegant. Simple. Hiding something powerful in plain sight.

Further Reading:

Burton Howard Bloom’s original 1970 paper — only 3 pages long, and surprisingly readable
Kirsch & Mitzenmacher (2006) — proof that double hashing works as well as independent hashes
Network Applications of Bloom Filters: A Survey — an exhaustive look at real-world applications

How to Read Notes Aloud (Physical, Handwritten, or Digital)

Sun, 05 Apr 2026 00:00:00 +0200

Yes, even your handwritten notebook. Here’s how to get any notes — paper, PDF, or digital — read aloud on your iPhone, hands-free.

Most people searching for how to read notes aloud are thinking of one of two scenarios. Either they have digital files they want to listen to while doing something else, or they have physical notes — a notebook, printed handouts, lecture slides on paper — and they want a way to convert those into audio too. Both are very solvable on iPhone, and the best tool for the job handles both without needing to switch between apps.

Reading physical and handwritten notes aloud

If your notes are on paper, the workflow is simple: photograph the page, let the app convert it to text with OCR, then hit play. Chitneek has a built-in camera scanner that handles this entire chain in one place. You don’t need a separate scanning app, a cloud upload, or any extra steps.

Open Chitneek and tap the scan button

The built-in scanner opens your camera. Hold it over a page of notes — the app detects edges and captures a clean, deskewed image automatically.

Let OCR convert the page to text

The app runs optical character recognition on the image. This works well for printed notes and reasonably neat handwriting.

Chitneek's built-in scanner handles OCR automatically.

Scan additional pages if needed

You can scan multiple pages into a single document, so a whole section of a notebook becomes one continuous listening session rather than a pile of separate files.

Tap play

Chitneek reads the extracted text aloud using Apple’s natural-sounding TTS voices. Adjust the speed, lock your screen, and listen while you do something else.

Tip on handwriting quality: OCR accuracy depends on how legible the writing is. Print-style handwriting converts well; very cursive or compressed handwriting can produce errors.

Reading digital notes aloud (PDF, EPUB, and more)

For notes that already exist as files — PDFs exported from Notion, lecture slides saved as PDFs, ebook chapters, Word documents — Chitneek imports and reads them directly, with no scanning needed.

You can import files from the Files app, share a PDF into Chitneek from any other app using the iOS Share Sheet, or use the in-app browser to download documents directly from the web. Once a file is in your library, it’s available for offline listening any time, with no internet connection required.

What the playback experience looks like

Chitneek reads your documents with synchronized text tracking — the current sentence is highlighted as it’s spoken, which helps if you want to follow along visually. Background playback keeps the audio going when you lock your screen or switch apps, so you can commute, walk, or cook without touching your phone again.

Speed and pitch are both adjustable. Most people doing review listening settle somewhere between 1.2x and 1.5x for comfortable comprehension without mental fatigue.

🌍 In-app translation

Translate a PDF into another language before listening — useful for language learners or anyone working with foreign documents.

👥 Shared groups

Create a shared library with classmates or study partners. Everyone can upload documents and listen; individual progress stays private.

Try Chitneek free for 7 days

Scan physical notes, import PDFs, listen offline. Works on iPhone with iOS 16.6 or later.

Download on the App Store

Tips that actually improve how much you retain

Review material you’ve already seen once: Listening is most effective as a second pass, not a first encounter.
Clean up notes briefly before scanning: A quick check of OCR results ensures a coherent audio experience.
Stay between 1.2x and 1.5x speed: Speed is good, but comprehension is better.
Walk while you listen: Light movement has been shown to improve focus and memory recall during auditory learning.

Voice quality matters. Go to Settings → Accessibility → Spoken Content → Voices and download an Enhanced or Premium voice for a much more natural-sounding experience.

CodeMenu 1.7 makes your snippet library more useful

Sun, 05 Apr 2026 00:00:00 +0200

CodeMenu 1.7 is a release about getting more value out of the snippets you already have. Storing code is only half of the job. The harder part is finding the right thing at the right moment, reusing it in a way that fits your current work, and connecting your library to the rest of your workflow. This update pushes that side of the app forward with snippet-aware AI, better automation hooks, iCloud sync, and more integration features across macOS.

Chat with your snippet library

One of the biggest changes in CodeMenu 1.7 is the new snippet-aware AI workflow. In the side window, AI mode can now search through your library while it responds. There is also a dedicated AI view in the Dashboard, so these conversations no longer have to feel like a small side feature tucked away in another panel.

What makes this useful is not just that there is an AI prompt inside the app. The AI can actively pull snippets into the conversation, keep track of what it is currently using as context, and surface snippets it found during the chat. That turns CodeMenu into something closer to a searchable working memory for your code.

The practical use cases are easy to imagine. You might remember that you solved a tricky API problem a few months ago, but not what you called the snippet or where you filed it. You can describe the behavior instead of guessing keywords. You can ask the AI to compare two saved approaches before you reuse one. You can start from an old snippet and ask for a refactor, a cleaner version, or an explanation of how it works. You can also use it when you know you have solved something before, but the details are gone from your head.

Ollama support for integrated AI

CodeMenu 1.7 also expands the local AI story by adding Ollama as an integrated provider. In settings, local AI is no longer limited to the built-in path. You can choose between the built-in local model and Ollama, point CodeMenu at an Ollama endpoint, pick an installed model, or enter a model manually.

That matters because local AI setups are not one-size-fits-all. Some people want the simplest built-in experience. Others already run Ollama and want their existing models to do the work. With this release, CodeMenu is more flexible about that choice while keeping the experience inside the app.

In practice, this means you can keep snippet-aware AI closer to your own machine and your own stack. If you already use Ollama for development work, you do not have to treat CodeMenu as a separate island. If you prefer a specific local model for speed or style, CodeMenu can fit into that setup instead of forcing you into a single path.

Shortcuts app support

CodeMenu 1.7 now supports the Shortcuts app through App Shortcuts and App Intents for snippets, tags, and groups. That includes actions for creating snippets, searching snippets, listing snippets, creating tags, creating groups, and moving snippets into groups.

This is an important step because snippet management becomes much more powerful once it can participate in system automation. A snippet manager should not only wait for you to open it. It should also be able to respond to the way you already work on macOS.

There are a lot of practical directions this can go. You can capture a snippet from a Shortcut built around selected text, browser content, or clipboard data. You can create voice-driven or menu bar flows for organizing your library. You can build personal automations that drop incoming material into the right group or tag structure. For people who like connecting apps together, CodeMenu is now a much better citizen of the broader macOS workflow.

iCloud synchronization

Another major addition in 1.7 is iCloud synchronization. CodeMenu now includes iCloud-based sync infrastructure.

This is the kind of feature that disappears when it works well, which is usually a good sign. If you use CodeMenu on more than one Mac, the value is immediate. Your snippets and related library data are no longer tied to one machine and one local state. You can move from a work Mac to a personal Mac, or from a desktop setup to a laptop, without treating export and import as part of the routine.

For a tool that is meant to act like an external memory, that matters a lot. The less friction there is between your machines, the easier it is to trust the library as the place where things live.

Better HTTP server integrations

CodeMenu 1.7 also improves the built-in HTTP server with new GET /v1/snippet and POST /v1/snippet endpoints. That sounds small on paper, but it makes integrations much more practical when another tool only needs to work with one specific snippet at a time or wants to create a new one directly.

The value here is simplicity. Companion tools, editor helpers, and lightweight scripts usually do not want to pull an entire list and filter it themselves when all they need is one result. They also benefit from being able to create a snippet in a single request when something useful appears elsewhere in your workflow.

That opens up cleaner ways to wire CodeMenu into other developer tools. A helper can fetch one exact snippet by ID. A script can create a new snippet from generated output, captured text, or another app’s result. The HTTP server becomes a little more composable, which usually means it becomes a lot more usable.

Smaller improvements

There are a few smaller changes worth mentioning too. Deleting a parent group now removes its subgroups as well, which makes nested organization behave much more predictably. The preferences window resizing behavior has been cleaned up so it stays anchored more naturally. The side window header has also received polish for light mode, which helps one of CodeMenu’s most frequently used surfaces feel more consistent.

This release also continues the move away from the older utilities window. That part of the app is being deprecated and is no longer where the product direction is headed. The emphasis is now much more clearly on the main snippet workflows, integrated AI, automation, and the surfaces people use every day.

CodeMenu 1.7 is a focused release, but it moves the app in an important direction. If you already have a library of snippets inside CodeMenu, this is a good time to revisit it. The app is getting better at helping you search it, talk to it, automate around it, and carry it with you across the rest of your setup.

Building an Image Compressor with the Discrete Fourier Transform

Sun, 08 Mar 2026 00:00:00 +0100

A few weeks ago, I was flipping through one of my old programming magazines when I stumbled across an interesting claim: you can compress images using the Discrete Fourier Transform. The idea seemed almost too elegant to be true - transform an image into the frequency domain, throw away the small stuff, and reconstruct something that still looks decent. This is apparently one of the core mechanisms behind JPEG compression.

I had to try it myself.

The result is a Python script that compresses BMP files into a custom “IMGX” format. It’s not going to replace modern codecs anytime soon, but it works, and building it taught me more about signal processing than any textbook ever did. If you want to see the code, the whole experiment is on GitHub.

What is the Discrete Fourier Transform?

Before diving into the implementation, it helps to understand what the DFT actually does. At its core, the DFT takes a signal - in this case, the pixel values in an image - and decomposes it into a sum of sine and cosine waves at different frequencies.

Think of it like this: imagine you have a complicated audio waveform. The DFT tells you how much of each musical note (frequency) is present in that sound. For images, instead of sound waves, you’re analyzing how quickly pixel values change across the image. Smooth gradients have low frequencies, while sharp edges and fine details have high frequencies.

The key insight for compression is that most natural images have most of their “energy” concentrated in the low frequencies. The high-frequency components - the ones representing fine details - tend to have much smaller amplitudes. If we keep only the frequencies with the largest amplitudes and discard the rest, we can reconstruct an image that looks pretty similar to the original, but with far less data.

The First Attempt: Bigger Than the Original

My initial implementation was straightforward: apply a 1D DFT to each color channel, keep the top 70% of frequency components by amplitude, and discard the rest. The reconstructed image looked great. There was just one problem: the compressed file was larger than the original BMP.

This was frustrating, but not entirely surprising. Each pixel in a BMP uses 3 bytes (one per RGB channel). Each complex frequency value in the DFT, however, requires storing both a real and imaginary component as floating-point numbers - 8 bytes each, for a total of 16 bytes. Even keeping only 70% of the values meant I was using more space than before.

I dropped the threshold to 10% to reduce file size. The image quality suffered significantly, but the file was still bigger than the BMP. Something was fundamentally wrong.

Then I realized my mistake: I had assumed the first 70% of DFT values were the largest ones. They weren’t. The DFT doesn’t output values sorted by magnitude - I needed to explicitly find and keep only the top frequencies. Once I fixed that, things started to improve, but I still wasn’t beating BMP compression.

Making It Actually Work

Getting the file size down required three key improvements.

First: 2D DFT instead of 1D. Originally, I was treating each row of pixels independently and applying a 1D DFT. But images are inherently two-dimensional, and a 2D DFT captures spatial patterns more efficiently. Instead of transforming rows separately, the 2D DFT analyzes the image as a whole, identifying patterns in both horizontal and vertical directions. This meant fewer frequency components were needed to represent the same information.

Second: Quantization. Even with the 2D DFT, each frequency component still required far more bytes than a single pixel. I needed to reduce the precision of the stored values. By finding the maximum amplitude in each channel and scaling all values relative to that maximum, I could represent each component with just 2 bytes for the real part and 2 bytes for the imaginary part - 4 bytes total instead of 16. The trick was finding a quantization level that preserved image quality without wasting bits. After some experimentation, I settled on a quantization factor that brought the file size down significantly without introducing too many visual artifacts.

Third: Exploiting DFT symmetry. This was the real breakthrough. The DFT has a mathematical property: when the input is real-valued (like pixel intensities), the output frequencies are symmetric. Specifically, half of the frequency components are complex conjugates of the other half. This means they contain the same information - just with the imaginary part flipped in sign.

Since conjugate pairs have the same magnitude, if one frequency is in the top 10%, its conjugate almost certainly is too. Instead of storing both, I could store just half the frequencies and reconstruct the conjugates during decompression. This nearly halved the number of values I needed to save.

The Results

After implementing all three improvements, the compression finally worked. I tested it on a 16.8 MB BMP image, and the compressed IMGX file came out to 8.8 MB - a reduction of about 48%. The decompressed image isn’t pixel-perfect, but it’s remarkably close to the original, especially considering only 10% of the frequency information was kept.

For reference, modern JPEG compression would do much better on the same image, but that’s not really the point. This was never about building a production-ready codec. It was about understanding how frequency-domain compression actually works, and seeing firsthand why choices like 2D transforms and quantization matter.

What I Learned

The biggest lesson from this project was that compression algorithms work thanks to careful exploitation of patterns in data. Images happen to have most of their information in low frequencies, so discarding high frequencies works. Audio compression uses similar principles. Text compression exploits the fact that some words appear more often than others.

I also learned that the devil really is in the details. The difference between “doesn’t work at all” and “works reasonably well” came down to a few specific implementation choices: using a 2D transform, quantizing carefully, and leveraging symmetry.

If you’re curious about the implementation details, the full source code is available at github.com/wiktorwojcik112/fourier_compress. The compression script takes a BMP file and outputs an IMGX format, which you can then decompress back to BMP to view the result.

Would I use this for real image compression? Absolutely not. But building it gave me a much deeper appreciation for the algorithms we use every day and for the clever mathematical insights that make them possible.

Teaching Machines to Smell Danger: A Fun Dive Into ML-Powered Threat Detection

Sun, 08 Feb 2026 00:00:00 +0100

Every now and then at Extiri, between shipping apps and squashing bugs, I like to take a detour into a completely different corner of tech — just to see what happens. At my university there was a statistics project that could be made so it served as ane xcuse to work wht ML. So this time, the question was: can I teach a machine learning model to sniff out network attacks? Spoiler: I got it to 97% accuracy, learned a ton, and had a surprisingly good time doing it.

Here’s how this little research adventure played out.

The Spark: Why Even Do This?

Network security is, at its heart, a massive pattern recognition puzzle. Attackers leave fingerprints everywhere — weird packet sizes, suspicious timing, oddly shaped data flows. The catch? These clues are buried under mountains of perfectly normal “someone’s watching YouTube” traffic, and they change all the time.

Classic rule-based systems are fine, but they’re a bit like a guard dog that only barks at people wearing the exact same hat as the last burglar. Machine learning, on the other hand, can learn the subtle statistical vibe of “everything’s fine” versus “something is definitely off.”

That sounded like a fun experiment. So I grabbed a dataset, fired up a Jupyter notebook, and went to work.

You can find all the code on GitHub if you want to follow along or poke holes in my methodology (feedback welcome!).

The Playground: 2.8 Million Network Flows

For data, I used the CICIDS 2017 dataset — a week-long capture of real network traffic where security researchers were actively staging different attacks alongside normal activity.

The numbers are huge: over 2.8 million network flows, each packed with features like:

Packet lengths and timing
Flow duration
Forward and backward packet statistics
Inter-arrival times

And the best part — every single flow is labeled as BENIGN or one of 14 different attack types (DDoS, Port Scan, SQL Injection… the whole villain roster).

Poking Around: The Detective Phase

Before letting any algorithm loose on the data, I wanted to actually understand what I was looking at. This turned out to be the most interesting part.

A Lopsided World

First fun fact: the dataset is overwhelmingly benign traffic. Which makes total sense — most real networks are boring most of the time. But it immediately means a model that just shrugs and says “looks fine to me” for every single packet would score high on accuracy while being spectacularly useless. Noted.

Which Features Actually Matter?

I ran correlations between every feature and the target variable to find out which network characteristics are the best attack detectors. Ten features rose to the top, including:

Backward packet length statistics (standard deviation, max, mean)
Packet length variance
Inter-arrival time patterns
Average packet sizes

Here’s where it gets nerdy (in a good way): these top features had massive standard deviations — some in the millions — and extreme positive skewness. In plain English? Most values huddle near zero, but there are wild outliers stretching way out into the distance. The data is leptokurtic, which is a word I don’t get to use nearly often enough.

It makes intuitive sense though. Normal browsing = small, regular packets. DDoS attack = a firehose of chaotic bursts.

Do Attacks Actually Look Different?

I plotted the distributions of these key features for benign vs. malicious traffic side by side, and — oh yes — the difference jumped right off the screen.

Benign traffic: smooth exponential decay, lots of tiny values, quickly tapering off. Malicious traffic: similar shape, but with telltale spikes at larger values. The attacks were basically wearing neon signs, statistically speaking.

But I didn’t want to just trust my eyeballs. So I ran Kolmogorov-Smirnov tests to compare the distributions formally. The p-values came back so close to zero that Python basically shrugged and said “yeah, these are not the same.” The benign and malicious features live in genuinely different statistical universes.

Green light. If the math says they’re different, machine learning should be able to find the boundary.

There was, however, a problem due to the both types - benign and malicious - having nearly identical spikes at the low end of the distribution. In those small-value ranges, benign and malicious traffic are practically indistinguishable — you’d need additional features (or deeper packet-level data) to tell them apart. I decided to accept that limitation and file it under “things to improve later.”

The Showdown: Four Models Enter, One Wins

Time for the fun part — the model bake-off. I trained four contenders:

Logistic Regression — the reliable baseline, the control group of ML
Random Forest — a whole crowd of decision trees voting together
Gradient Boosting — learns from its mistakes, one tree at a time
AdaBoost — keeps throwing more attention at the hard cases

All features were standardized first (mean 0, standard deviation 1), because some of those wild outliers would otherwise hijack the learning process. The data has been split into two sets - training and testing - so that I could test the model with data it has never seen. The sets used the “stratify” option to guarantee that each type of traffic will appear with the same proportions as the original.

The metric I cared about most? F1 score for the malicious class. In security, you’re always balancing two headaches:

Recall: Catch as many real attacks as possible (don’t let the bad guys through)
Precision: Don’t flood the security team with false alarms (the team might not be big enough)

F1 is the harmonic mean of both — one number that captures the trade-off nicely.

Results: And the Winner Is…

Model	Accuracy	Malicious F1	Malicious Precision	Malicious Recall
Random Forest	97%	0.92	0.99	0.87
Gradient Boosting	97%	0.91	0.98	0.84
AdaBoost	95%	0.86	0.95	0.79
Logistic Regression	89%	0.60	0.98	0.43

Random Forest took the crown with an F1 of 0.92. Some highlights:

99% precision on malicious traffic — when it says “attack,” it means it
100% recall on benign traffic — zero false truth on normal activity (!)
87% recall on malicious traffic — catches 87 out of every 100 attacks

That 13% miss rate is the price of keeping false truths at essentially zero. For many real-world setups, that’s a trade-off most security teams would happily take.

Why Did Random Forest Win?

Random Forests build hundreds of decision trees, each trained on a slightly different slice of the data, and then let them vote. It’s democracy applied to machine learning, and it turns out to be great at:

Wrangling high-dimensional data with complex interactions
Staying cool around outliers (those extreme values we found earlier)
Not overfitting, thanks to built-in regularization

Essentially, the model learned hundreds of different “if this packet looks like that, be suspicious” rules and combined them into one robust detector. Wisdom of the (tree) crowd.

Bonus Round: What Kind of Attack Is It?

Knowing “something’s wrong” is step one. But what exactly is wrong? That’s what security teams really need. So I trained a second Random Forest to classify the specific attack type — and it did surprisingly well:

99% overall accuracy
Perfect F1 scores (1.00) for attacks like FTP-Patator, Heartbleed, Infiltration, and PortScan
Near-perfect results on DDoS, DoS variants, and Bot traffic

But — and there’s always a but — web attacks gave it trouble. XSS landed at 0.36 F1, SQL Injection at 0.60, and Web Brute Force at 0.66. The model kept mixing them up, which actually makes sense: from a network-flow perspective, these attacks probably look pretty similar. To truly tell them apart, you’d need deeper packet inspection or application-layer features that this dataset doesn’t capture.

Where Could This Go?

This was a clean, controlled experiment. Taking it into the real world would mean tackling:

Continuous retraining as attack patterns evolve (attackers don’t stand still)
Adversarial robustness (what if someone deliberately tries to fool the model?)
Integration with actual security tooling
Explainability so humans understand why something got flagged

But as a proof of concept? A 97% accurate detector with 99% precision on malicious traffic is a pretty solid starting point — and a really enjoyable way to spend a few weekends.

All the code, statistical tests, confusion matrices, and model comparisons are available in the GitHub repo. Reproducibility or it didn’t happen.

Tools used: Python, Scikit-Learn, Pandas, Matplotlib, Seaborn
Dataset: CICIDS 2017 (2.8M network flows, 14 attack types)
Best model: Random Forest (F1: 0.92, Accuracy: 97%)

The Power of Elegant Simplicity #1: Shamir's Secret Sharing - The Polynomial That Guards Your Secrets

Sun, 08 Feb 2026 00:00:00 +0100

Part of the “The Power of Elegant Simplicity” series - algorithms that hide power in plain sight

You know what’s wild? One of the most elegant cryptographic algorithms ever invented uses nothing more than high school algebra. No complex number theory, no quantum mechanics, just polynomials. The kind you probably learned to hate in 9th grade.

Welcome to Shamir’s Secret Sharing, where a simple quadratic equation becomes the foundation for securing nuclear launch codes, cryptocurrency wallets, and anything else you really, really don’t want falling into the wrong hands.

The Problem: Trust No One (But Trust Everyone Together)

Imagine you’re a startup founder with the keys to your company’s crypto wallet. If you keep them yourself, you’re one bike accident away from locking everyone out forever. If you give copies to your co-founders, any one of them could clean out the account and disappear to Bali.

What you need is a way to split a secret so that:

No single person can reconstruct it alone
But any group of, say, 3 out of 5 people can work together to recover it
People who don’t have enough shares learn absolutely nothing (not “almost nothing” - literally nothing)

This is exactly what Adi Shamir figured out in 1979. And the solution is beautifully simple.

The Trick: It’s Just a Polynomial

Here’s the entire algorithm in one sentence: encode your secret as a point on a polynomial, give each person a different point, and use the magic of polynomial interpolation to reconstruct it.

That’s it. No, really.

Let’s break it down with an example where we want 3 people to be able to reconstruct the secret, out of 6 total people (k=3, n=6).

Step 1: Encode Your Secret

Let’s say your secret is the number 8 (maybe it’s a password hash, or a piece of an encryption key).

Create a polynomial of degree k-1 (so degree 2 in our case) where the constant term is your secret:

1	f(x) = 3x² + 5x + 8

The coefficients 3 and 5? Completely random. Throw dice. Mash your keyboard. Doesn’t matter. But that 8? That’s your secret, hiding in plain sight at f(0).

Step 2: Generate the Shares

Now just evaluate your polynomial at different points:

def create_shares(secret, k, n):
    """
    Split a secret into n shares where k shares are needed to reconstruct.
    
    Args:
        secret: The secret value to share
        k: Minimum number of shares needed to reconstruct
        n: Total number of shares to create
    """
    import random
    
    # Create a polynomial of degree k-1 with secret as constant term
    coefficients = [secret] + [random.randint(1, 100) for _ in range(k-1)]
    
    def polynomial(x):
        return sum(coef * (x ** i) for i, coef in enumerate(coefficients))
    
    # Generate n shares by evaluating polynomial at different points
    shares = [(i, polynomial(i)) for i in range(1, n + 1)]
    return shares

# Example usage
secret = 8
shares = create_shares(secret, k=3, n=6)
# With coefficients [8, 5, 3] this gives us:
# [(1, 16), (2, 30), (3, 50), (4, 76), (5, 108), (6, 146)]

Give person #1 the point (1, 16), person #2 gets (2, 30), and so on. These are your shares.

Step 3: The Magic of Reconstruction

Here’s where it gets cool. With fewer than 3 shares, there are infinitely many polynomials that fit through those points. Just like two points define a line but could be part of any parabola, two shares from our 2nd-degree polynomial could match an infinite number of possible secrets.

But the moment you have 3 shares, boom - there’s exactly one polynomial of degree 2 that fits through all three points. Mathematics locks it in.

We use Lagrange interpolation to reconstruct the polynomial:

def lagrange_interpolation(shares):
    """
    Reconstruct the secret using Lagrange interpolation.
    
    Args:
        shares: List of (x, y) tuples representing shares
    
    Returns:
        The secret (value at x=0)
    """
    def basis_polynomial(i, x):
        """Calculate the i-th Lagrange basis polynomial at x"""
        xi, yi = shares[i]
        result = yi
        
        for j, (xj, yj) in enumerate(shares):
            if i != j:
                result *= (x - xj) / (xi - xj)
        
        return result
    
    # Evaluate the interpolated polynomial at x=0 to get the secret
    secret = sum(basis_polynomial(i, 0) for i in range(len(shares)))
    return round(secret)

# Reconstruct with any 3 shares
secret_recovered = lagrange_interpolation([(1, 16), (2, 30), (4, 76)])
print(f"Secret: {secret_recovered}")  # Output: Secret: 8

The polynomial gets reconstructed, and f(0) gives us back our secret.

Why This is Actually Mind-Blowing

Perfect Security: If you have k-1 shares, you have zero information about the secret. Not “very little” - literally zero. The secret could be any value with equal probability. This is information-theoretic security, the same kind that makes one-time pads unbreakable.

Flexibility: Want to go from 5 shares to 10? Just evaluate the same polynomial at new points — instant new shares. Want to update the secret entirely? Generate a new polynomial and distribute fresh shares. One caveat: if you need to change the threshold (say, from “3 of 5” to “4 of 7”), that means a new polynomial of a different degree, so you’d need to redistribute all shares.

Simplicity: The entire algorithm fits in a tweet. Okay, maybe a long tweet. But still.

Real-World Applications

This isn’t just a clever party trick. Shamir’s Secret Sharing is used in:

Cryptocurrency wallets: Splitting recovery seeds across multiple devices or people
Certificate authorities: Requiring multiple executives to sign off on root certificates
Nuclear launch codes: Academic example because you definitely want more than one person to agree on this
Distributed password managers: Like Hashicorp Vault’s unseal process
Threshold signatures: Multiple parties cooperating to sign transactions

The Catch (There’s Always a Catch)

Like most cryptographic primitives, the devil is in the implementation details:

Random number generation matters: Those random coefficients need to come from a cryptographically secure random number generator (CSPRNG), like Python’s secrets module. The standard random module is a regular PRNG — predictable if someone knows the seed. (The code examples in this post use random for clarity, but don’t do that in production.)
Share storage is critical: Each share is as sensitive as the original secret. If someone gets k shares, game over.
No integrity protection (mostly): Basic Shamir doesn’t have built-in authentication, but here’s a neat trick — if you collect more than the minimum k shares, you can catch liars. Just try reconstructing from different subsets of k shares. If everyone’s honest, every subset gives the same secret. If someone faked their share, the subsets containing it will produce a different result, exposing the liar. Fair warning: this gets expensive fast (the number of subsets grows combinatorially), so it’s more of a sanity check than a scalable defense. For real-world use, look into verifiable schemes like Feldman’s VSS or Pedersen’s VSS.
Computation in finite fields: For production use, you need to work in finite fields (modulo a large prime) to avoid floating-point precision issues and information leakage.
Other production concerns: A full deployment would also want share authentication (MACs or signatures on each share), replay protection, and possibly proactive secret sharing — periodically refreshing shares without changing the secret. These are beyond our scope here, but worth knowing about if you ever build this for real.

The Modular Twist: From Theory to Practice

That last point deserves its own section, because it’s both important and surprisingly simple.

Everything I explained above works algebraically over the real numbers — the polynomial math is correct, and you’ll get your secret back. But here’s the thing: over ℝ, the scheme doesn’t actually provide information-theoretic security. The range and magnitude of the share values can leak information about the secret. The “zero knowledge with k-1 shares” guarantee only holds in a finite field. So modular arithmetic isn’t just a practical fix for computers — it’s a security requirement. Let me explain.

Why Modular Arithmetic?

Problem 1: Floating-point chaos

When you reconstruct a polynomial using Lagrange interpolation with real numbers, you’re doing lots of divisions. These create fractions that computers represent as floating-point numbers. After a few operations, you might get 7.999999999998 instead of 8. Usually you can just round, but what if your secret is 7 or 8? At scale, these errors compound.

Problem 2: Information leakage

Here’s a subtler issue. If someone has k-1 shares and sees the intermediate calculations, the size of those numbers might reveal information about the secret. In real arithmetic, evaluating a degree-2 polynomial at x=100 gives much bigger results for some coefficients than others. An attacker could use this to narrow down possibilities.

The solution: Work modulo a prime

Instead of doing arithmetic over all real numbers, we do everything modulo a large prime number p. This means:

All values stay in the range [0, p-1]
No floating-point numbers at all - everything is integers
Division becomes “multiplication by the modular inverse”
Every value is equally likely, revealing nothing

How Simple Is The Change?

Remarkably simple. Take any operation from the basic algorithm and add % prime at the end:

# Basic (problematic)
result = (result * x + coef)

# Modular (production-ready)  
result = (result * x + coef) % prime

The only tricky part is division. In modular arithmetic, you can’t just divide - instead, you multiply by the modular inverse. If you want to compute a / b mod p, you calculate a * (b^(-1)) mod p, where b^(-1) is the number such that b * b^(-1) ≡ 1 (mod p).

Python 3.8+ makes this trivial:

# Division in modular arithmetic
result = (a * pow(b, -1, prime)) % prime

That’s it. The entire conceptual framework - polynomials, shares, interpolation - stays exactly the same. You’re just doing the arithmetic in a different “universe” where numbers wrap around at prime.

Choosing Your Prime

The prime p needs to be larger than:

Your secret value
The number of shares you’ll create

A common choice is a Mersenne prime like 2³¹ - 1 or, for cryptographic applications, a 256-bit prime. The “Try It Yourself” example below uses modular arithmetic properly.

Try It Yourself

Here’s a complete, simple implementation you can play with:

import random

def create_shares(secret, k, n, prime=None):
    """Create n shares of a secret with threshold k"""
    if prime is None:
        prime = 2**31 - 1  # Mersenne prime for simplicity
    
    # Random coefficients for polynomial
    coefficients = [secret] + [random.randint(0, prime - 1) for _ in range(k - 1)]
    
    def evaluate(x):
        """Evaluate polynomial at x using Horner's method"""
        result = 0
        for coef in reversed(coefficients):
            result = (result * x + coef) % prime
        return result
    
    # Generate shares
    shares = [(i, evaluate(i)) for i in range(1, n + 1)]
    return shares, prime

def reconstruct_secret(shares, prime):
    """Reconstruct secret from shares using Lagrange interpolation"""
    secret = 0
    
    for i, (xi, yi) in enumerate(shares):
        numerator = denominator = 1
        
        for j, (xj, _) in enumerate(shares):
            if i != j:
                numerator = (numerator * (0 - xj)) % prime
                denominator = (denominator * (xi - xj)) % prime
        
        # Modular inverse for division in finite field
        lagrange_coef = (numerator * pow(denominator, -1, prime)) % prime
        secret = (secret + yi * lagrange_coef) % prime
    
    return secret

# Example
secret = 12345
shares, prime = create_shares(secret, k=3, n=5, prime=104729)
print(f"Original secret: {secret}")
print(f"Shares: {shares[:3]}")  # Show first 3 shares

# Reconstruct with any 3 shares
recovered = reconstruct_secret(shares[:3], prime)
print(f"Recovered secret: {recovered}")

The Takeaway

Shamir’s Secret Sharing is sneakily brilliant because it looks so simple. Polynomials? We learned those in high school. But that simplicity hides incredible power: a mathematically perfect way to split trust, with security properties that hold up against even quantum computers.

Sometimes the best algorithms aren’t the most complex ones. Sometimes they’re the ones that make you slap your forehead and think, “why didn’t I think of that?”

That’s the beauty of elegantly simple algorithms. They hide in plain sight, doing impossible-seeming things with elementary mathematics.

Next in the series: Bloom Filters - The data structure that’s okay with being wrong (sometimes)

Further Reading:

Shamir’s original 1979 paper - Surprisingly readable
Implementation considerations for production systems
Example implementation: Secret Sharing Demo

CodeMenu as a File System for Your AI Agents

Fri, 16 Jan 2026 00:00:00 +0100

In the evolving world of AI development, there’s a growing buzz around “filesystems for AI”—essentially, structured ways to organize and access data that empower AI agents to work more intelligently and autonomously. Think of it as giving your AI a well-organized filing cabinet where it can pull out exactly what it needs without rummaging through chaos. This trend is picking up steam because AI agents aren’t just chatbots anymore; they’re becoming active participants in coding, research, and problem-solving workflows. They need reliable, queryable repositories to fetch context, code patterns, or prompts on demand.

Enter CodeMenu, a nifty Mac app from Extiri that’s quietly positioning itself as a perfect fit for this niche. It’s not marketed as a filesystem per se, but its design as an offline-first knowledge base for developers makes it an ideal local “file system” for AI agents. I’ve been exploring it, and it’s got that warm, practical feel—like a trusted notebook that’s always at your side. Let me walk you through what it offers, why it aligns with this trend, and some real-world use cases that might inspire you to give it a spin.

What Makes CodeMenu a “File System” for AI?

At its core, CodeMenu is a developer-focused tool for storing and managing code snippets, AI prompts, notes, images, and more. Everything lives locally on your Mac in a Realm database, which means no cloud dependencies, no subscriptions, and full privacy—your data stays put unless you choose otherwise. This offline-first approach is a breath of fresh air in a world of always-online tools, and it echoes the reliability we expect from a traditional file system.

But here’s where it shines for AI: CodeMenu isn’t just a static storage bin. It structures your data in a way that’s easy for humans and machines to navigate. You can organize artifacts into “Spaces” for project isolation, “Stashes” for quick ideas, and use tags, groups, and even a visual knowledge graph to link things together. Imagine a file system where files aren’t isolated silos—they’re connected nodes in a graph, allowing for relational queries.

The real magic for AI agents comes from its integration points:

MCP Server: This lets AI tools like Claude Desktop or Cursor directly query your CodeMenu library. Your agent can say something like “CodeMenu fetch the ‘stripe-webhook’ snippet” and pull in verified code without you copying and pasting.
HTTP Server: Running locally (e.g., via curl to localhost), it exposes your snippets as an API. This turns CodeMenu into a programmable data source that AI scripts or agents can tap into programmatically.
CLI Tool (cdmn): A terminal interface with fuzzy search and JSON output, perfect for scripting AI workflows.

It’s like having a lightweight, developer-centric database that AI can read from, much like how modern AI systems use vector databases or file systems for long-term memory. And with support for over 60 languages, syntax highlighting, and rendering for Markdown, LaTeX, images, and even regex testing, it’s robust enough to handle diverse AI needs.

Real Use Cases: Bringing It to Life

To make this concrete, let’s look at some practical scenarios where CodeMenu acts as that essential filesystem layer for AI agents. These are drawn from how developers are already using it, adapted to highlight the AI angle.

Building Smarter Coding Assistants: Suppose you’re working on a web app with Stripe integration. You’ve stored webhook handlers, error-handling patterns, and test prompts in CodeMenu, tagged and linked in a knowledge graph. Now, integrate it with an AI agent in Cursor (an AI-powered code editor). The agent queries CodeMenu via the MCP Server to retrieve a “stripe-webhook” snippet, then generates unit tests or refactors code based on that context. No more losing track of your best practices—your AI pulls from a structured “file” of proven code, reducing hallucinations and improving output quality. CodeMenu can also store your Agent Skills and AGENTS.md giving you a centralized place to manage them. I’ve seen devs save hours this way, turning scattered notes into a reliable AI memory bank.
Automating Research Workflows: For AI agents handling research or OSINT (open-source intelligence), CodeMenu can store screenshots, notes, links, and prompts as interconnected artifacts. Picture an agent tasked with analyzing design trends: It fetches a group of design tokens (colors, refs) from CodeMenu’s API, cross-references them with stored images, and generates a report. It’s neutral and warm in practice: No over-reliance on external APIs, just local, organized data that keeps your agent grounded and efficient.
Scripting Bulk Operations for AI Pipelines: CodeMenu’s JavaScript scripting lets you automate tasks, but pair it with AI for more power. Say you’re maintaining a library of AI prompts for generating documentation. An AI agent uses the HTTP server to list all prompts tagged “docs-gen,” then scripts a bulk update (e.g., adding ethical guidelines to each). This filesystem-like access means your AI can “read” and “write” to the repo programmatically, evolving it over time. A real win for solo devs or small teams building custom AI tools—it’s like giving your agent write access to a shared drive, but safer and more structured.
Offline AI Experimentation: In areas with spotty internet (or just for privacy), CodeMenu’s local setup is gold. Store system prompts, templates, and code for fine-tuning small models. An AI agent running locally (via tools like Ollama) queries CodeMenu for prompt patterns, tests them offline, and iterates. This use case feels particularly human-centered—it’s about empowering you to tinker without barriers, aligning with the trend of democratizing AI through accessible “filesystems.”

Why This Matters in the Bigger Picture

As AI agents become more agentic—handling tasks end-to-end—they’ll need better ways to manage knowledge. Traditional filesystems are too rigid, cloud services too invasive, but tools like CodeMenu bridge the gap with a developer-friendly, AI-ready structure. It’s not perfect for every setup (it’s Mac-only for now), but its free model and extensibility make it approachable for anyone dipping into this trend.

If you’re curious about enhancing your AI workflows, I’d gently suggest downloading CodeMenu and experimenting. Start small: Populate a Space with your go-to snippets, fire up the MCP Server, and see how your favorite AI tool interacts with it. It’s a subtle shift, but one that could make your agents feel less like tools and more like thoughtful collaborators. What do you think—ready to organize your AI’s “files”?

Try CodeMenu free for 7 days → Mac App Store

Why 2026 Is the Year of Local-First Productivity Tools (and How CodeMenu Fits In)

Tue, 13 Jan 2026 00:00:00 +0100

We’re copying API keys into ChatGPT prompts, uploading proprietary code to cloud snippet managers, and syncing our entire knowledge bases through servers we don’t control. Somewhere along the way, we normalized sending our most valuable work artifacts through someone else’s infrastructure.

That’s changing in 2026 — and it’s about time.

Privacy Isn’t Optional Anymore

The tools we used to trust are now the ones we question. Every snippet, every piece of code, every design decision we document potentially flows through a third-party server. With data breaches making headlines weekly and companies quietly training AI models on user content, developers are waking up to an uncomfortable truth: cloud-first isn’t always the answer.

The problem isn’t cloud sync itself—it’s the assumption that it must be the default. Your code snippets, your AI prompts, your research notes—these don’t need to live on someone else’s computer. They shouldn’t have to.

Local-first tools flip this model. Your data stays on your machine. You choose when (and if) to sync. You control who sees what. And when you close your laptop on a plane, everything still works because it was never dependent on someone else’s servers in the first place.

AI Needs Context, Not Your Company’s Secrets

The AI productivity revolution came with a catch: to be useful, AI needs context. The more it knows about your codebase, your patterns, your preferences, the better it performs. But feeding that context into cloud APIs means broadcasting your intellectual property to external services.

This creates a painful choice: accept reduced productivity by keeping AI out of your workflow, or accept privacy risks by sending everything to the cloud.

On-device AI changes the equation entirely. You get intelligent assistance—semantic search, content generation, automated tagging—without any data leaving your machine. The AI model runs locally, learns from your patterns privately, and helps you work faster without compromising what matters.

CodeMenu: Your Private Knowledge System

This is where CodeMenu comes in. It’s built from the ground up as a local-first tool that treats your privacy as a feature, not an afterthought.

Everything you save—code snippets in 60+ languages, design references, color palettes, AI prompts, screenshots—lives on your Mac. The on-device AI features (generation, chat, semantic search) run entirely on your hardware. Nothing gets sent to external servers unless you explicitly choose to sync or share.

What makes this powerful isn’t just the privacy angle. It’s the workflow. With parameterized templates, you can create living boilerplates that adapt to different contexts. The JavaScript automation and HTTP API let you build custom workflows that connect CodeMenu to your other tools. Built-in utilities (RegEx tester, converters, mock data generators) mean fewer context switches.

And because it’s offline-first, everything works on planes, in basements, or when your internet inevitably decides to fail right before a demo. Your augmented memory is always available.

For teams that do need sharing, CodeMenu’s optional sync and Snippets Store provide controlled collaboration—you decide what to share, when to share it, and who sees it.

ClipGuru: Local-First for Your Mobile Workflow

Not everything needs the power of a full snippet manager. Sometimes you just need to capture a URL from Safari, save a quote you’ll reference later, or keep a piece of code accessible across your iPhone and Mac.

ClipGuru takes the local-first philosophy and distills it into a lightweight clipboard manager for iOS, iPadOS, and macOS. Text, links, and images sync via iCloud (which means your data stays in Apple’s ecosystem, not a third-party server), and the custom keyboard extension gives you instant access without app switching.

It’s intentionally simple—no overwhelming features, no complex setup, just fast capture and smart search. The free version saves 4 clips, and Pro unlocks unlimited history and tags for about the price of a coffee.

Think of it as CodeMenu’s mobile companion: ClipGuru handles quick captures and clipboard management across devices, while CodeMenu serves as your deeper knowledge system on Mac. Together, they create a local-first workflow that scales from quick mobile snippets to comprehensive knowledge management.

The Offline-First Future Is Already Here

We’re seeing a shift away from the “everything must be cloud-based” mentality of the 2010s. Developers are choosing tools that respect their privacy, work offline, and give them control over their data. The technology is mature—local AI models are powerful, device storage is cheap, and sync protocols exist that don’t require surrendering your data.

2026 won’t be the year everyone abandons cloud tools. But it will be the year local-first becomes a serious consideration rather than a niche preference. When you can have the best of both worlds—powerful features and complete privacy—why would you settle for less?

Your code, your snippets, your knowledge base—these are your intellectual property. They deserve to live somewhere you control.

Ready to go local-first?

Try CodeMenu free for 7 days → Mac App Store

Or grab ClipGuru for quick clipboard access → App Store (iOS, iPadOS, macOS)

How to Use Code Snippets on Your Mac

Wed, 29 Oct 2025 00:00:00 +0100

You found a piece of code online-maybe in Python, Bash, JavaScript, Ruby, or even C-and you’re wondering how to actually run it on your Mac.
You’re in the right place. I’ll walk you through how to run snippets in both interpreted and compiled languages, explain what’s happening behind the scenes, and keep it simple.

What’s going on: interpreted vs compiled languages

Before we dive into examples, here’s a quick overview.

Interpreted languages (like Python, Bash scripts, JavaScript via Node.js, Ruby) are executed by a program (an interpreter) line by line. You paste code and it runs.
Compiled languages (such as C, C++ and others) require a compiler. The compiler transforms your source code into a binary executable that your Mac can run directly. That means a few extra steps: install the compiler → compile the code → run the executable.

Why does this matter to you? Because when you pick up a snippet, you’ll want to know whether you can paste it and run it immediately (interpreted), or if you need a toolchain set up (compiled).
Let’s go through both.

Option 1: Running Interpreted Languages

Python

Check if Python is installed:
1
python3 --version

If you see something like Python 3.9.x, you’re ready.

Run code interactively:
1
python3
Now you’re at the >>> prompt. Paste:
1
print("Hello from Python!")
Press Enter → you’ll see the output. To exit, type exit() or press Ctrl + D.
Run a script from a file:
- Open a text editor, paste your snippet.
- Save it as myscript.py.
- In Terminal, navigate to its folder.
  1
  cd ~/Desktop # adjust path as needed
- Run:
  1
  python3 myscript.py

Bash / Shell

If the snippet looks like:

1	echo "Hello from the shell!"

You can simply paste it into Terminal and hit Enter-done.

For a multi-line script:

nano myscript.sh         # open a simple editor
# paste code
# save with Ctrl + O, enter; exit with Ctrl + X
chmod +x myscript.sh     # make it executable
./myscript.sh            # run it

JavaScript with Node.js

To use JavaScript outside of a browser you’ll generally install Node.js. I’ll cover installation in the next section. Once installed:

Interactive mode:
1
node
You’ll see a > prompt. Then:
1
console.log("Hello from Node.js!");
Press Enter → output appears. Exit with Ctrl + C.

Running from file:

nano app.js           # create/edit file
# paste:
console.log("This runs using Node.js");
# save & exit
node app.js

Ruby

Check:

ruby -v

Then create a file script.rb:

1	puts "Hello from Ruby!"

Save, then run:

1	ruby script.rb

Installing Node.js (so you can run JS)

Here’s how to get Node.js running on your Mac:

Visit the official Node.js site and download the LTS version (https://nodejs.org).
Open the downloaded .pkg installer and follow the on-screen steps.
After installation, open Terminal and type:

  node -v
  npm -v

You should see version numbers, indicating successful installation.

Optionally, you can use the Homebrew package manager:

brew update
brew install node

Then verify as before.

Option 2: Running Compiled Languages - Example with C

Using compiled languages means one extra step: building (compiling) the code before you run it. Let’s walk through C on Mac.

Installing the compiler

Your Mac can use Apple’s built-in toolchain (Clang) or you can install GNU GCC. Here’s how to set up the basic tools:

Run:
1
xcode-select --install
This installs Apple’s Command Line Tools (which include Clang) without needing the full Xcode app.
If you prefer GNU GCC:
1
brew install gcc
And verify:
1
gcc --version
(verify the gcc output shows a version string)

Write a simple C snippet

Create a file named hello.c with content:

#include <stdio.h>

int main() {
    printf("Hello, C world!\n");
    return 0;
}

Compile & Run

In Terminal, navigate to the folder:

1	cd /path/to/folder

Then compile:

1	clang hello.c -o hello

or if using GCC:

1	gcc-13 hello.c -o hello

Now run:

./hello

You should see:

1	Hello, C world!

Using VS Code for C (optional)

Install VS Code
Install the C/C++ extension
Open hello.c, then use the built-in terminal (Ctrl + ~) to compile and run as above.

A Quick Peek at Other Languages You Might Encounter

C++ - Very similar to C; you’ll use clang++ or g++ to compile.
Go - Install via brew install go or official site; run a file with go run file.go.
Rust - Install using rustup, compile with cargo build, run with cargo run. The pattern stays: install toolchain → compile/build (if needed) → run.

Option 3: Run & Manage Snippets Effortlessly with CodeMenu

If you’re testing a variety of snippets across languages, switching between terminals, editors and computing steps can get tedious. That’s why I built CodeMenu.

With CodeMenu you can:

Save and organize snippets (Python, Bash, Ruby, JavaScript, C, and more).
Run them instantly without manually opening Terminal each time.
Keep everything in one place so you don’t lose track of “one that worked” or “the version I saved”. Treat it as a snippet sandbox + launcher-it simplifies your workflow so you can focus on experiments instead of setup.

👉 Try it here: CodeMenu for Mac

TL;DR (summary)

Interpreted languages (Python, Bash, JS, Ruby) = paste & run almost immediately.
Compiled languages (C, C++, Go, etc.) = install compiler → compile → run the executable.
On Mac you’ll often use Terminal to run commands; editors like VS Code add comfort.
If you’re working with lots of snippets or switching languages, CodeMenu gives you structure.

Final Thoughts

You don’t have to be a “developer” to try running code. You just need curiosity and a few practical steps. Start with a simple snippet, run it, see what happens, tweak it. The “typing commands” part might look intimidating-but once you’ve done it once, it becomes second nature. And when you want to keep your snippets organized, manageable, and easy to run-CodeMenu is there to make life simpler.