DEV Community: Torben Haack

Shipping npm Packages Offline — Right in Your Browser

Torben Haack — Fri, 01 Aug 2025 00:00:00 +0000

For years, at work and in my own projects, I kept running into the same hurdle:
installing npm packages in air-gapped or locked-down environments. Most
solutions lean on backend services, shell scripts, or private registries. I
wanted something simpler, more transparent, and truly portable.

So I built Packy: a browser-based utility that bundles any npm package plus all
its dependencies into a single tarball for offline use. No backend. No server.
Just your browser doing the work.

https://t128n.github.io/packy/

The Problem

If you've ever debugged inside a secure network, on a factory floor, or in a
classroom PC without internet, you know the pattern. You need one more package,
but you can't run npm install. Copying files around by hand is brittle and
slow. Standing up a local registry is overkill and often blocked by policy.

I wanted a tool I could open in any modern browser, type a package and version,
and end up with a single archive that "just works" offline later.

What Packy Does

Packy resolves, fetches, and packages your target npm module and all of its
transitive dependencies into one tarball you can move by USB, shared drive or
sneakernet. Everything happens locally in the browser via WebContainers. No API
keys, no telemetry, no server.

Concretely, Packy orchestrates the same steps you'd do by hand, but automated
and sandboxed:

1) It runs npm i to resolve and materialize the full dependency
tree in an isolated filesystem.

2) It rewrites the package.json of the selected package to include it's dependencies in bundle.

3) It runs npm pack to generate a single tarball that contains the
package and its dependencies, ready for offline delivery.

Why a Browser-Only Approach?

Zero setup and zero trust surface. A browser app:

avoids maintenance
works crossplattform
requires zero setup

It reduces friction. You get in, get a clean archive and get moving.

When It's Useful

Packy shines when you need to move fast without internet or infrastructure. It's
ideal for shipping Node.js apps into locked-down or air-gapped environments
where online installs aren't an option. It's equally at home in teaching
contexts (workshops, classrooms and trainings) where connectivity can be flaky or
restricted and you need a predictable setup. It also doubles as a dependable way
to archive dependencies for reproducible builds or long-term snapshots. And when
you're heading into the field, Packy helps you prepare "dev kits" that contain
everything required to get unstuck.

Implementation Notes

WebContainers provide a Node-like runtime inside the browser with a virtual filesystem and process API.
npm i runs inside that sandbox, producing a real, resolved node_modules tree.
The package's package.json is rewritten to include all dependencies when being packaged.
npm pack emits a standard tarball you can store, move, and install from later.

This approach mirrors npm's semantics closely while remaining transparent and
auditable.

Try It

Packy is open-source and evolving. Use it here:

https://t128n.github.io/packy/

If you're curious how it works or want to contribute, dive into the codebase,
file issues or suggest improvements.

Summarizing Videos with AI

Torben Haack — Wed, 30 Jul 2025 00:00:00 +0000

Just today, a casual chat with a colleague sparked an idea that I couldn't wait to try implementing after work: building an AI-powered video summarizer. The result is vid,
a proof-of-concept project designed to distil video content into summaries.

The core idea behind vid is to meticulously leverage both the audio and visual streams of a video, process them with specialized AI models
and then synthesize these diverse insights into a coherent, high-value summary.

The `vid` Pipeline: How It Works

Here's a quick look under the hood at the workflow:

Audio Extraction & Transcription: The journey begins with FFmpeg, which extracts the audio track from the input video. This audio is then fed into OpenAI Whisper, a powerful speech-to-text model, generating a detailed transcript complete with timestamps. This gives vid the spoken content of the video.
Intelligent Frame Selection: For the visual component, OpenCV is at the heart of the process. Rather than extracting every single frame (which would be inefficient and redundant), vid processes frames to identify those with significant visual changes. A subsequent filtering step is applied to remove visually similar frames, ensuring that only truly distinct moments — "key frames" — are captured. This keeps the visual data meaningful and focused.
Visual Context with Gemma: Each carefully selected key frame is then sent to Gemma 3, which I'm running locally via Ollama. Gemma analyzes these images and generates precise textual descriptions of their content. This crucial step enriches the video's understanding beyond mere spoken words, adding vital visual context that a transcript alone can't provide.
Unified Summarization: Finally, the multimodal magic happens. Both the comprehensive audio transcript and the detailed visual descriptions of the key frames are combined. This rich, integrated input is then fed back into Gemma 3. With this holistic view of the video's content and visuals, Gemma is prompted to generate the ultimate concise summary, capturing the essence of the entire video.

System Overview

For a visual walkthrough of how these components fit together, check out the system mockup:

Get Involved

This project is very much a proof of concept, but it establishes a robust foundation for more advanced video understanding and summarization systems. If you're intrigued by the technical implementation or want to experiment with it yourself, the code is open-source and available on GitHub.

Explore vid on GitHub: https://github.com/t128n/proof-of-concept-vid

FiDuP Lernzettel: Meine AP2-Materialien für Fachinformatiker Daten- und Prozessanalyse

Torben Haack — Fri, 23 May 2025 00:00:00 +0000

Ende 2024 habe ich meine Abschlussprüfung Teil 2 (AP2) als Fachinformatiker für Daten- und Prozessanalyse (FiDuP) erfolgreich abgeschlossen – mit einer Abschlussnote von 1,4. Die Vorbereitung war intensiv, aber strukturiert. Heute teile ich meine kompletten Lernzettel als Open-Source-Projekt.

Warum ich meine Lernzettel veröffentliche

Bildung sollte zugänglich sein. Während meiner Vorbereitung habe ich gemerkt, wie fragmentiert die verfügbaren Lernmaterialien für FiDuP sind. Viele Ressourcen sind entweder nicht vorhanden, kostenpflichtig oder unvollständig.

Meine Lernzettel haben mir nicht nur beim Bestehen geholfen – sie haben mir eine sehr gute Note ermöglicht. Diese Materialien kostenlos verfügbar zu machen, ist mein Beitrag zu einer besseren Ausbildungslandschaft in der IT.

Was das Repository enthält

Das fidup Repository ist modular aufgebaut und deckt alle prüfungsrelevanten Themenbereiche ab:

Datenmodellierung und Datenbankdesign: Von ERD bis Normalisierung
Programmierung und Skriptsprachen: Python, SQL, und mehr
Datenanalyse und Visualization: Statistische Methoden und Tools
Prozessanalyse und -optimierung: BPMN, Workflow-Design
Projektmanagement: Agile Methoden, klassisches PM
IT-Sicherheit und Datenschutz: DSGVO, Compliance, Backup-Strategien
... und viele weitere Themen

Jedes Thema ist in kompakte, verständliche Abschnitte unterteilt. Die Notizen basieren auf dem Erwartungshorizont für Winter 2024/25, bleiben aber größtenteils auch für zukünftige Prüfungen relevant.

Für wen sind diese Materialien gedacht?

Primäre Zielgruppe: Auszubildende im FiDuP-Bereich, die sich auf die AP2 vorbereiten.

Sekundäre Zielgruppe: Quereinsteiger, Umschüler oder erfahrene Entwickler, die sich formal zertifizieren lassen möchten.

Die Materialien setzen grundlegende IT-Kenntnisse voraus, erklären aber komplexere Konzepte von Grund auf.

Ein Hinweis zur Verantwortung

Diese Lernzettel haben mir geholfen, aber sie sind nicht fehlerlos. Der Erwartungshorizont kann sich ändern, und individuelle Lernstile variieren. Nutze sie als Ergänzung zu offiziellen Materialien, nicht als Ersatz.

Ich übernehme keine Haftung für Ungenauigkeiten oder veraltete Inhalte. Die Verantwortung für deine Prüfungsvorbereitung liegt bei dir.

Wie du beitragen kannst

Das Repository lebt von der Community. Du kannst helfen durch:

Issues erstellen für Fehler oder fehlende Inhalte
Pull Requests für Verbesserungen oder Ergänzungen
Feedback geben über deine Erfahrungen mit den Materialien

Besonders wertvoll sind Beiträge von Personen, die die Prüfung bereits abgelegt haben oder aktuelle Änderungen im Erwartungshorizont kennen.

Warum Open Source?

Bildung prosperiert durch Zusammenarbeit, nicht durch Konkurrenz. Indem ich meine Lernzettel öffentlich mache, ermögliche ich:

Transparenz: Jeder kann sehen, wie die Materialien entstanden sind
Verbesserung: Die Community kann Fehler korrigieren und Inhalte ergänzen
Zugänglichkeit: Keine Kosten, keine Registrierung, keine Paywalls

Open Source bedeutet auch Nachhaltigkeit. Selbst wenn ich das Projekt nicht mehr aktiv pflege, kann die Community es weiterführen.

Der nächste Schritt

Falls du dich auf die FiDuP AP2 vorbereitest: Schau dir das Repository an. Nutze es als Ausgangspunkt für deine eigene Vorbereitung.

Falls du bereits die Prüfung abgelegt hast: Teile deine Erfahrungen. Korrigiere Fehler. Ergänze fehlende Inhalte.

Falls du Ausbilder oder Lehrkraft bist: Nutze die Materialien in deinen Kursen. Feedback von Profis ist besonders wertvoll.

Bildung funktioniert am besten, wenn Wissen geteilt wird. Diese Lernzettel sind mein Beitrag dazu.

Repository: github.com/t128n/fidup

Kontakt: Fragen, Anregungen oder Feedback gerne per Issue oder E-Mail

Original Article: https://t128n.github.io/writings/2025-05-23_fidup_lernzettel_fachinformatiker

Simplifying Cursor Installation on Linux

Torben Haack — Thu, 08 May 2025 00:00:00 +0000

In the world of modern development tools, Linux support often feels like an afterthought. While tools like VS Code and JetBrains IDEs have excellent Linux integration, newer AI-powered editors frequently lag behind. This is particularly evident with Cursor, an AI-first code editor that's gaining traction in the developer community.

The Problem

Cursor's official Linux distribution method leaves much to be desired. Users are expected to manually download AppImages, manage permissions, and set up desktop integration themselves. This creates unnecessary friction for developers who just want to get started with the tool. In an era where developer experience is paramount, this kind of friction is unacceptable.

The Solution

I've created a set of installation scripts that bring Cursor's Linux experience up to par with other professional development tools. The solution is simple but effective:

curl -sSL https://raw.githubusercontent.com/t128n/cursor-linux/main/install.sh | sudo bash

One command. That's all it takes to get Cursor properly installed on your Linux system.

Why This Matters

When we accept subpar installation processes, we're implicitly telling tool creators that Linux support is an afterthought. By creating and sharing these installation scripts, I'm not just making life easier for Linux users – I'm demonstrating what proper Linux support should look like.

The scripts handle everything:

Proper system integration
Desktop environment compatibility
Automatic updates
Clean uninstallation

Technical Details

The implementation is straightforward but robust. The scripts:

Download the latest AppImage directly from Cursor's servers
Install to /opt/cursor (following Linux filesystem hierarchy standards)
Set up proper permissions and symlinks
Create desktop entries for seamless integration
Handle updates and uninstallation gracefully

Try It Out

If you're a Linux user interested in Cursor, give these scripts a try. They're open source, well-documented, and designed to make your life easier. And if you find any issues or have suggestions for improvement, contributions are welcome.

Remember: good developer experience isn't just about the features of a tool. It's about how easily and reliably you can get started with it. Let's raise the bar for Linux support in modern development tools.

Original Article: https://t128n.github.io/writings/2025-05-08_simplifying_cursor_installation_on_linux

Optimizing Search Performance: Client-Side Routing and the Potential of AI

Torben Haack — Fri, 02 May 2025 00:00:00 +0000

DuckDuckGo's "Bangs" are a widely appreciated feature that exemplifies acknowledging the limits of a single search index. By allowing users to prefix a query with a specific identifier (e.g., !g for Google, !so for Stack Overflow), Bangs provide a convenient shortcut to search directly on other platforms. This functionality enhances DuckDuckGo's utility, effectively turning it into a jumping-off point for a vast array of specialized search engines and websites. For many users, Bangs are a key reason to use DDG.

However, this powerful feature has an architectural limitation that impacts performance: it relies on a server-side redirect.

The Current Bangs Request Flow

Understanding the standard HTTP request flow from a browser's search bar is key:

User types query into browser search bar.
Browser sends an HTTP GET request to the configured default search engine's server (e.g., duckduckgo.com/?q=...).
The search engine server processes the query and returns an HTML response.
Browser renders the results page.

With a DuckDuckGo Bang query, the flow introduces an extra step:

User types query with a bang (e.g., react 19 release date !g) into the browser search bar.
Browser sends a GET request to duckduckgo.com/?q=react+19+release+date+!g.
DDG Server receives the request, identifies the !g bang, looks up the corresponding redirect URL (for Google), and responds with an HTTP 302 Redirect status code.
Browser receives the redirect response.
Browser initiates a new GET request to the target search engine URL (e.g., google.com/search?q=react+19+release+date).
The target search engine server processes the query and returns results.
Browser renders the results page.

The third step – the server-side lookup and redirect – adds an unnecessary network round trip solely for routing. While seemingly minor, this extra latency can be noticeable, especially on high-latency or low-bandwidth connections, detracting from the snappiness expected of a search experience. This effectively spends network resources on an operation that could potentially be handled client-side.

An Alternative: Client-Side Interception

Could we eliminate this redundant server hop? The ideal scenario would be to interpret the bang syntax before the request ever leaves the user's browser and redirect it directly to the intended destination.

This approach would not only improve user experience by reducing latency but could also potentially decrease server load for DuckDuckGo.

Leveraging Service Workers for Client-Side Routing

Modern web technologies offer a solution: Service Workers. These are JavaScript scripts that a browser runs in the background, separate from the main page thread. One of their primary capabilities is acting as a network proxy for the pages they control. They can intercept network requests made by the page (including requests initiated from the browser's address bar if the page is the default search engine and the Service Worker is registered at the root scope).

By registering a Service Worker from our search endpoint, we can intercept the initial request containing the bang query within the browser. The Service Worker can then parse the query string, identify the bang, determine the target URL using a local lookup table, and programmatically redirect the browser to the correct destination without ever hitting the original search engine's server for a redirect.

The request flow would become:

User types query with a bang (e.g., react 19 release date !g) into the browser search bar.
Browser prepares GET request for the default search engine URL (your-search.com/?q=react+19+release+date+!g).
Registered Service Worker intercepts the fetch event.
Service Worker parses event.request.url, extracts the q parameter.
Service Worker identifies the !g bang and the remaining query (react 19 release date).
Service Worker constructs the target URL (google.com/search?q=react+19+release+date).
Service Worker instructs the browser to navigate to the target URL (e.g., using Clients.get(event.clientId).then(client => client.navigate(targetUrl))).
Browser initiates a new GET request directly to google.com.
Google server processes the query and returns results.
Browser renders the results page.

This eliminates the step involving the initial server's redirect lookup, directly reducing latency.

Routr: A Proof of Concept

To validate this client-side routing approach, I developed Routr, a small proof-of-concept. Routr consists of:

A minimal React frontend primarily for configuration and Service Worker registration.
A Service Worker script deployed from the application's origin.

The Service Worker listens for fetch events. It filters for requests matching the expected search query pattern (containing the q parameter). For relevant requests, it:

Parses the query string to identify any bang prefix (or uses a default engine if none is found).
Uses an internal mapping to determine the target URL based on the bang.
Performs a client-side redirect to the target URL, bypassing the initial server entirely for routing logic.

This demonstrates the core principle: offloading the bang lookup and redirection from the server to the client-side Service Worker.

Enhancing Search with AI: The Double-Bang

Building upon the client-side interception mechanism, we can integrate more sophisticated features that require query pre-processing. One such feature, explored in Routr, is the "double-bang" (!! or !!g).

This feature leverages the power of large language models (LLMs). When a query includes !! (followed by an optional bang like g), the Service Worker intercepts the request, extracts the query, and sends it to an AI processing endpoint (this part would likely require a server, but the routing logic remains client-side). The LLM can then analyze and potentially rephrase the query, add relevant search operators, or expand abbreviations based on the inferred user intent. The modified query is then used in the final redirect to the target search engine.

For example, !! react service worker pwa might be transformed by an LLM into something like "react service worker" PWA (performance OR offline OR manifest) before being sent to Google.

This offers a more dynamic form of query manipulation than static "lenses" or filters, potentially leading to more accurate or comprehensive search results on the target engine.

Future Directions: Context-Aware AI Routing

The double-bang is just one application of integrating AI into client-side search handling. The true power emerges when the AI can act as an intelligent router itself.

Imagine providing the LLM with context about your personal "search infrastructure" – frequently used websites, internal knowledge bases, documentation repositories, etc. Instead of relying on explicit bang syntax, the AI could analyze the user's raw query and determine the most appropriate source to search.

Query: "fix docker build permission denied" → AI routes directly to Stack Overflow or a specific internal DevOps guide.
Query: "summary marketing meeting q3 2024" → AI routes to your corporate cloud storage search or meeting notes platform.
Query: "react useeffect infinite loop" → AI routes to the official React documentation or a curated blog post.

This moves beyond simple pattern matching to intent-based, context-aware routing, creating a highly personalized and efficient search experience tailored to the user's specific information landscape.

Conclusion

While DuckDuckGo's Bangs are a valuable feature, their server-side redirect architecture introduces an avoidable performance bottleneck. By employing client-side Service Workers, we can intercept and handle search queries locally, eliminating the extra network hop and reducing latency.

Furthermore, building this client-side routing foundation opens the door to integrating powerful enhancements like AI-driven query processing (the double-bang) and potentially intelligent, context-aware routing that directs users not just based on syntax, but on the nature of their query and their personal information ecosystem.

This approach demonstrates the potential to build faster, more flexible, and more intelligent search experiences directly in the browser.

You can explore the Routr proof-of-concept and try the basic client-side routing and double-bang feature here: t128n.github.io/routr.

Original Article: https://t128n.github.io/writings/2025-05-02_optimizing_search_performance

In Defense of Boring Technology

Torben Haack — Sat, 26 Apr 2025 00:00:00 +0000

Software moves fast. Organizations, however, decay even faster. Teams churn. Priorities shift. Budgets shrink. Systems must survive this entropy — or they collapse.

Many developers, caught in the hype cycle, abandon stable systems for the latest frameworks and tools. This is not engineering. It is risk accumulation disguised as progress.

Real engineering demands boring technology: mature, battle-tested, well-understood systems.
Systems whose behavior is predictable even as everything around them changes.

Boring technologies resist entropy. Their failure modes are known. Their documentation is complete.
Expertise is widespread. When problems arise, solutions are readily available, not buried in obscure forums or half-finished GitHub projects.

Legacy code, often maligned, often represents precisely this: systems that delivered sustained value over years of change. Good legacy systems adapt without losing reliability. Bad legacy systems
reveal organizational dysfunction, not technological inertia.

By contrast, chasing unproven technologies introduces hidden complexity and operational risks that scale faster than teams can manage. "Move fast and break things" only works when the cost of failure is negligible. A rare condition in serious systems.

Engineers must be relentlessly curious, but strategically conservative. Innovation must target what differentiates the product, not the plumbing. Core systems should be boring by design: stable, predictable, understood.

Boring technology matters because it creates systems that survive entropy. In a world where change is constant, stable foundations are not optional. They are the difference between survival and collapse.

Choosing boring technology is not a failure of imagination.
It is the disciplined choice to build systems that endure.

If you want to read more about boring technology, check out the linked article.

Original Article: https://t128n.github.io/writings/2025-04-26_boring_technology

Data Over Vibes: A Case Study in Picking the Right AI Tool

Torben Haack — Thu, 17 Apr 2025 00:00:00 +0000

Most software decisions get made on vibes. Feature lists, pricing pages, hype. But when tools affect your workflow, usage, and spend, you need to ask: does this fit how I actually work?

That question came up for me when my ChatGPT Plus subscription was set to expire. I was considering T3.chat instead. At $8/month, it's a killer deal. Clean UX, great model lineup, privacy-first posture. But one thing gave me pause:

1,500 messages per month.

It sounded like enough… but was it? Rather than guess, I ran the numbers.

Export Your Data, Don't Trust Your Gut

ChatGPT lets you export your full usage history as a conversations.json file. I wrote a small Python script to:

Parse all messages between 2025-03-20 and 2025-04-17
Count how many were authored
Compute a daily average
Forecast usage through 2025-04-26 with a 20% buffer

Here’s what came back:

--- FORECASTED USAGE (2025-03-20 → 2025-04-26) ---
Total actual messages: 1632
Active days so far: 29
Avg messages/day: 56.28
Avg/day (+20% buffer): 67.53
Remaining days to forecast: 9
Projected total usage by 2025-04-26: 2239 messages

What the Data Said

If I switched to T3.chat today, I’d exceed the message cap by ~49%.

That doesn’t mean T3.chat is bad. It’s excellent for users with leaner, more intentional workflows. But for me, it would force a change:

Fewer iterative prompts
More scoped, complete instructions
Offload auxiliary tasks to GitHub Copilot or other tools

The real takeaway? This wasn’t a pricing question. It was a workflow question.

How the Script Works (and Why It’s Simple)

You don’t need a data pipeline to get useful insights. Here's a simplified breakdown of how the Python script works:

Load your conversations.json export:

with open("conversations.json", "r") as f:
    data = json.load(f)

Loop through the data and count user-authored messages:

for conv in data:
    for msg in conv.get("mapping", {}).values():
        if msg.get("message", {}).get("author", {}).get("role") == "user":
            ts = msg["message"].get("create_time")
            if ts and start_date <= datetime.fromtimestamp(ts) <= today:
                dt = datetime.fromtimestamp(ts)
                daily_counts[dt.strftime("%Y-%m-%d")] += 1

Calculate stats and forecast:

avg_per_day = total_msgs / active_days
avg_per_day_buffered = avg_per_day * 1.2
projected_msgs = total_msgs + (avg_per_day_buffered * remaining_days)

Done. Fast, accurate, and actionable.

Why This Matters

Software trade-offs aren't theoretical. They’re real, lived constraints. And if you want to stay efficient, whether you’re a developer, writer, or analyst—your tool choices need to match your patterns.

Good decisions come from data, not assumptions.

This one Python script saved me from adopting a tool that didn’t align with how I work today. Maybe I’ll evolve toward it later. But now, I know exactly what that change would cost.

TL;DR

If you’re evaluating alternatives to ChatGPT:

Export your data
Analyze your real usage
Let that shape your choice

No guesswork. No regret. Just data-backed clarity.

Original Article: https://t128n.github.io/writings/2025-04-17_data_over_vibes

Micro-Apps as Workflow Scalpel: Automating the Unfixable — One Fragment at a Time

Torben Haack — Thu, 17 Apr 2025 00:00:00 +0000

Most engineering orgs have systems you can't touch—legacy tools, rigid workflows, inflexible platforms. You know they're inefficient. But you're not going to get buy-in for a full rewrite, and you're not authorized to change the requirements.

So what do you do? You optimize the fragment.

That’s where micro-apps come in—not as platforms, not as products, but as scalpels for automating repetitive, constrained workflows when everything else is locked down.

A Common Case: “Send This Report Every Week”

You’re told to send a status email every Friday at 4PM. It needs three metrics pulled from a dashboard, one from a database, and a copy-pasted summary from last week.

You can’t change the requirement. You can’t change the dashboard. You can’t change the process.

But you can write a 50-line script that grabs the metrics, formats the body, and fires off the email.

You’ve just reclaimed 30 minutes per week—and eliminated the human error from a repetitive task.

That’s the point of micro-apps. They optimize the edge cases when the system is unfixable.

Workflow Fragmentation Is the Norm

You don’t work in a clean pipeline. You work in a mess:

Jira tickets that trigger manual emails
Dashboards you export just to reformat in Excel
CI failures that need copy-pasted logs to Slack
Environments with no API, just a browser UI and guesswork

You can’t refactor these systems. But you can wrap the friction points with micro-apps.

Not big systems. Not platforms. Not products.

Just sharp tools for well-scoped problems.

Micro-App Philosophy

If you’re building micro-apps, follow these principles:

Single responsibility: One input, one output, one job.
Zero config: If it needs onboarding, it's too big.
Fast to use: Ideally <1s interaction time.
Local-first: Run it from your machine, or a single server. No infra complexity unless necessary.
Throwaway-friendly: Build fast. Be ready to delete fast.

A good micro-app saves time on day one. A great one can be rebuilt in an afternoon if it disappears.

Don't Abuse Them

Micro-apps are not a substitute for strategic platform work. If you:

Have 7 tools doing the same thing
Built a micro-app that every team now depends on
Keep extending the same script until it’s a full stack app

…you've gone too far.

Use micro-apps to patch workflows, not design them. They’re drop-in fixes, not foundations.

They should automate what exists, not entrench what's broken.

A Healthy Micro-App Culture

Want your org to benefit from this pattern? Set some cultural defaults:

Let engineers ship small tools with minimal process.
Provide one-click hosting (e.g. GitHub Pages, Netlify, internal runners).
Maintain a simple internal app catalog with short-lived entries.
Celebrate small wins: highlight tools that eliminate 5–10 minutes of weekly toil.

This isn’t about building internal platforms. It’s about removing local friction without red tape.

Closing Thoughts

Micro-apps are for the 20% of workflows where the system won’t change, but your time is still being wasted.

They are surgical, ephemeral, and high-leverage—not scalable solutions, but highly effective responses to immovable constraints.

So next time you’re forced to do something dumb, manually, again:

Don’t file a ticket.

Don’t ask permission.

Build a tool. Use it. Delete it later.

Small tools. Big leverage. No excuses.

Original Article: https://t128n.github.io/writings/2025-04-17_micro_apps

Prompting the Right Way as a Software Engineer

Torben Haack — Tue, 15 Apr 2025 00:00:00 +0000

LLMs are changing how software engineers build, debug, and design systems. But let's be honest - most engineers still prompt like casual users.
"Write a Python script that does X." Then they complain when the result is mediocre. That's not the model's fault. It's yours.

You wouldn't give your intern vague directions and expect top-tier output. So why treat an LLM any differently?

The Intern Mindset

The best way to think about prompting is this: treat the LLM like your intern.
That means:

Don't just ask for an implementation - explain what you're trying to build.
Provide context, constraints, and goals.
Guide with function signatures, types, and expectations.
Be iterative. The first answer won't be perfect, and that's fine. You're here to collaborate.

You wouldn't hand your intern a whiteboard and say "build our auth system" and walk off. So don't prompt "Build a user service in Go" and expect magic.

Context is King

LLMs do not have access to your internal knowledge, unwritten conventions, or organizational quirks. You unconsciously apply context - coding guidelines, architectural philosophies, relevant code snippets, integration points - when solving problems. The model doesn't. You must provide that context.

Share your standards: If your team enforces certain patterns, testing practices, or error-handling approaches, state them explicitly.
Articulate your philosophy: Do you value functional purity? Defensive programming? "Move fast and break things" versus "measure twice, cut once"? Spell that out.
Give code and interfaces: Supply the LLM with relevant types, interfaces, or even critical utility functions it should use.
Be selective: Don't overload with irrelevant files, configs, or historical baggage. Context is only king if it's pertinent.

Treat context like a scalpel, not a sledgehammer - enough to illuminate, never so much it overwhelms.

Prompt Like You Design Systems

Here's the difference between a lazy prompt and a productive one:

Bad Prompt:

Write a microservice that handles user sign-up.

Better Prompt:

Design a microservice in TypeScript for user registration.
It should expose a POST `/register` endpoint that accepts name, email, and password.
Use Express. Validate input.
Hash passwords using bcrypt.
Assume a MongoDB backend.
Return success or validation errors in JSON format.
I'll integrate it into an existing monorepo later.

You gave it a function signature, data flow, constraints, and return format.
Now you're actually engineering.

Use the Right Model for the Right Job

Too many engineers throw every problem at GPT-4 or whatever model they have in front of them and expect perfect results.

That's like using your frontend dev to tune your Postgres indexes.

Here's a better flow:

Use a reasoning model (like o3-mini-high or DeepSeek R1) to break down the problem.

What architecture suits a multi-tenant document platform that must support offline syncing and granular RBAC?
Once you've got a direction, move to code generation using GPT-4.1 or equivalent.
Prompt with structure: interfaces, expected modules, or even scaffolded TODOs.
Review the result as if your intern wrote it. Push back. Iterate.
Don't accept hallucinated nonsense just because it sounds confident.

Prompt Engineering ≠ Hype—It's Professional Discipline

You don't need the title of “prompt engineer.” You need to engineer your prompts with the same precision and rigor you apply to code.
Communicate with the model as you would with a junior engineer: offer explicit context, set clear expectations, and provide iterative, actionable feedback.

Leverage the LLM's own capabilities to elevate your prompts—draft, review, and refine them using the model itself.
There is no reason to limit LLMs to code generation alone; employ them to optimize your entire engineering workflow, including prompt design.

Remember: LLMs are collaborative interfaces, not ticketing systems. Engage in a dialog, not a one-way transaction.

If the first draft misses the mark, say so—directly:
“Try again using async/await.”
“Add input validation with Zod.”
“Split this into two functions.”

Treat every session as a code review: iterate, critique, and demand clarity. That is how you extract real value.

Closing Thoughts

Prompting isn't a magic spell. It's engineering communication.
If your prompt is vague, unfocused, or lacks direction, the results will reflect that.

Treat the LLM like a sharp but inexperienced intern.
Use structure. Lead with intent. Iterate like it's pair programming.

It's not about coaxing the model into doing what you want.
It's about leading it there, step by step - just like you'd do in the real world.

Original Article: https://t128n.github.io/writings/2025-04-15_prompting_the_right_way

Git’s Trust Model is Broken - Here’s How to Fix It

Torben Haack — Sat, 12 Apr 2025 00:00:00 +0000

Git is one of the most widely used distributed version control systems in the world, relied on daily by millions of developers, especially within the open-source community. Yet, despite its immense popularity, Git's fundamental trust model is surprisingly flawed.

The Infamous `git config`

You've likely encountered that classic Git message when committing on a fresh machine:

Please configure your 'user.email' and 'user.name' in git.

Without thinking, you probably entered these commands and moved on. But have you ever wondered why Git needs your email and name even after you've already authenticated with your Git provider?

The Problem Explained

The core issue here is that Git itself simply doesn't care about your identity. GitHub cares. GitLab cares. But Git itself? Not at all. If you tell Git your email is tim@apple.com and your name is Tim Cook, Git will happily accept and record it—no questions asked.

To demonstrate just how easily Git allows impersonation, I created a commit using the name and email address of a prominent individual, the CEO of the $3.25 billion company Vercel, and successfully pushed it to GitHub without any verification (check it out here). Pretty great customer service, right?

This highlights how incredibly simple—and dangerous—it is to impersonate someone using Git.

The Simple Solution

Fortunately, there's a straightforward fix: signing your commits.

Most developers already have SSH or GPG keys set up for server authentication or Git provider interactions. These same keys can also secure your commits.

Here's how easy it is:

Generate an SSH or GPG Key:

ssh-keygen -t ed25519 -C "your_email@example.com"

Add your public key to your Git provider.
Configure Git to sign all your commits automatically:

git config --global commit.gpgsign true

Specify the key to use:

git config --global user.signingkey <your-signing-key>

That's it—your commits are now verifiable and secure.

Real-World Scenario

Imagine you're part of a 10-person team responsible for your application's authentication system, conveniently managed within a monorepo. Your CI/CD pipeline auto-deploys to production whenever you commit to the main branch, trusting your verified credentials implicitly. But what if your "friendly" coworker decides to impersonate you, injecting a malicious backdoor directly into production under your name?

This isn't a far-fetched scenario - it can happen without commit signing.

Closing Thoughts

Yes, Git is fundamentally flawed, but it's not Git's fault. When Git was created, the internet was a vastly different place. If we look back 50 years from now, we'll probably laugh at our current implementations, asking ourselves, "Why did we think that was okay?".

Despite this flaw, Git remains the best tool available—fast, reliable, and supported by a vast ecosystem. Rather than ditching Git for some obscure alternative, we should focus on improving it. Commit signing is a simple step toward making Git safer and more trustworthy for everyone.

Original Article: https://t128n.github.io/writings/2025-04-12_git_spoofing

DEV Community: Torben Haack

Shipping npm Packages Offline — Right in Your Browser

The Problem

What Packy Does

Why a Browser-Only Approach?

When It's Useful

Implementation Notes

Try It

Summarizing Videos with AI

The vid Pipeline: How It Works

System Overview

Get Involved

FiDuP Lernzettel: Meine AP2-Materialien für Fachinformatiker Daten- und Prozessanalyse

Warum ich meine Lernzettel veröffentliche

Was das Repository enthält

Für wen sind diese Materialien gedacht?

Ein Hinweis zur Verantwortung

Wie du beitragen kannst

Warum Open Source?

Der nächste Schritt

Simplifying Cursor Installation on Linux

The Problem

The Solution

Why This Matters

Technical Details

Try It Out

Optimizing Search Performance: Client-Side Routing and the Potential of AI

The Current Bangs Request Flow

An Alternative: Client-Side Interception

Leveraging Service Workers for Client-Side Routing

Routr: A Proof of Concept

Enhancing Search with AI: The Double-Bang

Future Directions: Context-Aware AI Routing

Conclusion

In Defense of Boring Technology

Data Over Vibes: A Case Study in Picking the Right AI Tool

Export Your Data, Don't Trust Your Gut

What the Data Said

How the Script Works (and Why It’s Simple)

Why This Matters

TL;DR

Micro-Apps as Workflow Scalpel: Automating the Unfixable — One Fragment at a Time

A Common Case: “Send This Report Every Week”

Workflow Fragmentation Is the Norm

Micro-App Philosophy

Don't Abuse Them

A Healthy Micro-App Culture

Closing Thoughts

Prompting the Right Way as a Software Engineer

The Intern Mindset

Context is King

Prompt Like You Design Systems

Use the Right Model for the Right Job

Prompt Engineering ≠ Hype—It's Professional Discipline

Closing Thoughts

Git’s Trust Model is Broken - Here’s How to Fix It

The Infamous git config

The Problem Explained

The Simple Solution

Real-World Scenario

Closing Thoughts

The `vid` Pipeline: How It Works

The Infamous `git config`