Forem

Why Your App Needs a Loading Skeleton (Not a Spinner)

Shefali — Tue, 14 Apr 2026 06:26:49 +0000

Open any app. Something is loading. What do you see?

If it’s a spinner, it’s just a circle going round and round. You don’t know what’s loading, how much is left, or how long it’ll take. You just wait.

Now imagine this instead: the layout shows up instantly. You see grey boxes where content will be, a circle for the avatar, lines for text. A subtle shimmer runs across them. Then the real content loads in.

Same loading time. But it feels much better.

That’s exactly what skeleton screens does.

What Are Skeleton Screens?

Skeleton screens are simple placeholders that shows the shape of the content before it loads.

Instead of a spinner, users see a basic layout of the page, even before the real data appears.

Here’s what it feels like:

Instead of showing a spinner or a “Loading…” message, the interface displays a preview of the layout, and that small change makes the experience feel much smoother.

Now that we understand what it is, let’s see why spinners don’t always work well.

The Problem with Spinners

Spinners aren’t bad.

They work well for quick actions like submitting a form, clicking a button, or uploading a file. In those cases, the user initiated something and just needs a simple signal that it’s in progress.

The issue starts when spinners become the default for every loading state. Page load, feed refresh, dashboard data, everything shows the same spinning indicator.

The problem is that a spinner gives no useful information. It doesn’t tell users what is loading, how much is left, or what to expect when it’s done. It simply shows that something is happening, without any context.

And that leads to the real UX issue: uncertainty.

When users don’t know what’s going on, it becomes frustrating very quickly. A spinner creates that uncertainty, while a skeleton screen reduces it by showing the structure of the content in advance, helping users understand what they are waiting for even before the data arrives.

Why Skeleton Screens Feel Faster (Even When They're Not)

Here’s something interesting: skeleton screens don’t actually make your app load faster. The data still takes the same amount of time to arrive.

And yet, users often feel like the app is faster.

This is the concept of perceived performance, which is about how fast something feels, not just how fast it actually is. In many cases, that feeling matters just as much, because user experience is shaped by perception.

When a skeleton screen appears, your brain starts forming a mental picture of the page. You can already see where things will go, so you begin to anticipate the content. By the time it loads, it feels less like waiting and more like something gradually revealing itself.

With a spinner, there’s nothing to engage with. With a skeleton, there’s something to expect, and that shift changes the entire experience.

This isn’t just theory: Apps like YouTube, LinkedIn, Facebook, GitHub, and Airbnb all use skeleton screens for content-heavy experiences.

These companies have already tested different approaches and looked at the data. Their decision isn’t based on trends or aesthetics, but on what actually improves user experience.

When you see the same pattern across so many large products, it’s a strong signal that skeleton screens work.

Once you see this, the difference becomes much easier to understand.

Spinners vs Skeletons

Here's a simple comparison to understand why skeleton screens feel better than spinners.

Feature	Spinner	Skeleton
Shows what’s loading	No	Yes
Feels faster	No	Yes
Shows page structure	No	Yes
User frustration	More	Less

So when should you use each one?

When to Use Skeleton Screens vs Spinners

It’s not about avoiding spinners completely, but about choosing what fits the situation.

Use a skeleton screen when you’re loading a full page, a list, a feed, a dashboard, or any section where the layout is predictable and there’s a lot of content coming in. In these cases, users are waiting for a whole view to appear, so showing the structure helps.

Use a spinner when the user performs a quick action like submitting a form, clicking a button, or deleting something. In these moments, there isn’t a layout to show, and the spinner simply tells the user that the action is in progress.

Once you start using skeletons, a few small things can improve the experience a lot.

Best Practices for Skeleton Screens

Here are a few best practices to make skeleton screens actually helpful, not confusing.

Match the real layout: Your skeleton should look like the actual content. When the shapes and structure are similar, the transition feels smooth. If it looks completely different, it can confuse users.
Don't overdo it: Showing a few skeleton cards is helpful, but showing too many at once can feel overwhelming. For long lists, it’s better to combine skeletons with pagination or lazy loading.
Always have an error state: If the data fails to load, don’t keep showing the skeleton forever. Replace it with a clear and friendly error message so users know what went wrong.
Accessibility matters: Some users are sensitive to motion, so constant shimmer effects can be uncomfortable. Good implementations respect reduced motion settings and adjust automatically.

Even with all this, performance still matters behind the scenes.

Performance Tip

Skeleton screens make your app feel faster, but they don’t replace real performance improvements.

The best approach is to do both: reduce the actual loading time and use a skeleton for whatever delay is left. A skeleton can make a slow load feel better, but when the load is already fast, it can make the experience feel almost instant.

Here are a few quick wins that work well alongside skeleton screens:

Cache aggressively: If a user has visited the page before, show cached data right away and update it in the background. In many cases, this means the skeleton won’t appear at all.
Prioritise above-the-fold content: Load only what’s visible on the screen first, and fetch the rest as the user scrolls. This helps the most important content appear quickly, making the skeleton disappear sooner.
Avoid waterfall requests: If your page makes multiple API calls one after another, the wait time adds up. Try to run requests in parallel so everything loads faster.

A skeleton gives you a smoother waiting experience, but it works best when you also make that waiting time as short as possible.

Now let’s quickly look at how you can start using them.

How to Get Started

You don’t need to build skeleton screens from scratch. There are good libraries for every major framework that handle animation, sizing, and accessibility for you. You can pick one based on your stack and get started quickly.

Library	Framework	What it does
react-loading-skeleton	React	A popular and easy option with ready-to-use components that work with minimal setup.
vue-content-loader	Vue	Uses SVG, which makes it very flexible and lightweight for custom designs.
content-loader	Any	A framework-agnostic option that works with React, Vue, Svelte, or even plain JavaScript.
animate-pulse	Tailwind	If you’re already using Tailwind, you can create skeletons without adding any extra dependencies.

The concept is the same across all of them: show the skeleton while data is loading, swap it for real content when it arrives. That's it.

Conclusion

Spinners aren’t bad, but they’re often used in places where better options exist. For content-heavy screens, skeletons usually provide a much smoother and more helpful experience.

Skeleton screens are simple to add, don’t take much effort to implement, and can instantly improve how your app feels to users.

The next time you reach for a spinner, take a moment to think if you can show the structure of the content instead. In many cases, giving users a preview of what’s coming will make the experience feel faster and more intuitive.

That’s all for today!

I hope you find this blog on loading skeleton screens helpful!

For paid collaboration, connect with me at: connect@shefali.dev

If you enjoy my work and want to support what I do buy me a coffee!

Every small gesture keeps me going! 💛

Follow me on X (Twitter) to get daily web development tips & insights.

Stop building custom auth for your B2B SaaS: Meet Gate Identity

Max Zhuk — Tue, 14 Apr 2026 06:22:36 +0000

Hello, fellow developers! 🧑‍💻

If you’ve ever built a B2B SaaS, you know the drill. Building the core business logic is the fun part. But then you hit the authentication layer. Suddenly, you're not just writing a simple login form; you have to figure out multi-tenancy, data isolation, routing social logins for different workspaces, and managing secure tokens. It's a massive time sink that distracts you from shipping your actual product.

I’ve been there. Honestly, I was tired of reinventing the wheel or fighting with overly complex enterprise identity providers just to get a proper B2B auth running. I wanted an API-first approach that was fast, reliable, and didn't require a Ph.D. in security to set up.

That’s why I built Gate Identity (as part of my Verne Software ecosystem) — a developer-first 🔐 Auth-as-a-Service. It takes the pain out of multi-tenant authentication, allowing you to plug it in and get back to building your app. And the best part? The core functionality is already up and running, and you can use it for your next project completely for free (with a generous free tier for early-stage projects).

In this article, I’ll show you what’s under the hood of Gate Identity, what features you can start using right now, and share my roadmap for what's coming next.

Under the Hood: The Architecture and Tech Stack

As engineers, we all love peeking under the hood. When I started designing Gate Identity, I followed one golden rule: never write your own core security and cryptography logic. I didn't want to build an identity provider from scratch; I wanted to build a robust, multi-tenant layer on top of a battle-tested open-source engine.

Here is how the system is wired together to make that happen:

1. The Core Engine: Ory Kratos
At the heart of Gate Identity is Ory Kratos. If you haven't used it, Kratos is a phenomenal API-first identity server written in Go. It handles the heavy lifting: complex authentication flows, secure credential storage, and standard OIDC integrations. However, out of the box, Kratos doesn't natively solve B2B multi-tenancy the way a SaaS needs it to. It needs a smart gateway to manage who belongs to which workspace.

2. The Edge Gateway (Built with Rust 🦀)
This is where the magic happens. All incoming traffic is terminated by Traefik, which acts as the main reverse proxy. But right behind it sits the custom Edge Gateway (edge_gw), which I wrote entirely in Rust.

Why Rust? Because an API gateway needs to be blazingly fast, concurrent, and memory-safe. Every single authentication request passes through this node. The Rust gateway acts as the strict bouncer for the multi-tenant architecture:

It parses and validates your access tokens (gat_live_{hex}).

It checks the tenant-ownership (e.g., "Does this specific subject ID actually belong to the tenant making the API call?").

It handles rate limiting and routing, safely proxying the validated requests down to Kratos or the Core API.

3. State and Data Isolation (PostgreSQL + Redis)
A proper B2B auth system must keep tenant data strictly isolated. To achieve this without bottlenecks, I split the storage layer:

Identity Data: Stored in a dedicated 🐘 PostgreSQL database managed entirely by Kratos. Here, I use distinct JSON schemas to separate roles: user (your tenant's end-users) and tenant (you, the developers using Gate).

curl -X POST https://api.vernesoft.com/v1/gate/identities \
  -H 'Authorization: Bearer vrn_gate_live_sk_9f8a7...' \
  -H 'Content-Type: application/json' \
  -d '{
    "schema_id": "user",
    "traits": {
      "email": "user@example.com",
      "custom_data": { "role": "editor" }
    },
    "credentials": {
      "password": { "config": { "password": "StrongPassword123!" } }
    },
    "state": "active"
  }'

Business Logic & Profiles: Stored in the Core API’s PostgreSQL database.
Flow States & Tokens: Handled by Redis. When a user starts a login or settings flow, the state is cached in Redis with a strict mapping (gate:flow:{id} -> tenant_id). This allows the Rust gateway to instantly verify if a user is trying to access a flow that belongs to their specific workspace, effectively preventing cross-tenant data leaks.

By combining the raw speed of Rust at the edge with the security standards of Ory Kratos at the core, Gate Identity manages to isolate tenants efficiently without adding noticeable latency to your API calls.

What You Can Use Right Now

Enough with the architectural theory—let's look at what you can actually plug into your product today. I built Gate Identity aiming to cover 90% of a typical B2B SaaS's needs right from the start, without forcing you to write boilerplate code.

Here is what is running in production right now:

Basic Authentication
The classic, reliable email and password flow. Kratos handles the secure hashing and credential storage, while the Edge Gateway ensures that sessions are correctly bound to the specific workspace (tenant).
Highly Configurable Social Logins (OIDC)
B2B clients often demand corporate account logins. Out of the box, 11 providers are supported, including Google, GitHub, Apple, Microsoft, and Discord. But here is the killer feature: each of your tenants can individually enable or disable specific providers just for their own workspace.
Painless Token Management
No more messing around with complex client-side JWTs. Gate Identity issues secure, opaque access tokens (in the gat_live_{hex} format). They support scopes and configurable lifespans. There is also a ready-to-use introspection API, so your backend can instantly verify their validity.
Tenant-Isolated Identity CRUD API
You get full control over users via a REST API. You can programmatically create, update, and delete identities without ever worrying about cross-tenant data leaks. My gateway automatically verifies tenant-ownership—the system simply won't let a request through if you try to access a user from someone else's workspace.

The Roadmap: What’s Coming Next

Gate Identity is actively evolving. While the core API handles the heavy lifting right now, I am constantly working on unlocking more of Ory Kratos' advanced capabilities and routing them safely through the Rust Edge Gateway.

Here is what is on the immediate horizon:

User Self-Service (UX)

Settings Flow (Critical Priority): End-users will soon be able to natively manage their own profiles, update passwords, and link social accounts. This means you won't have to build custom account management UIs from scratch.
Recovery & Verification: API-driven password resets and programmable email verification flows to make user onboarding completely seamless.

Enterprise-Grade Security

MFA / TOTP: Multi-factor authentication using authenticator apps is a massive priority, especially if you are targeting enterprise B2B clients.
Passwordless (OTP): Support for One-Time Passwords via email for frictionless, consumer-like login experiences.
Session Management: Giving both tenant admins and end-users the ability to view and instantly revoke active sessions across all devices.

Advanced Developer Experience (DX)

Tenant Webhooks: This is the most anticipated feature for developers. Soon, you will be able to subscribe to real-time events (e.g., user.created, user.deleted, password.changed) to instantly sync identity data with your core application's database.
Custom Identity Metadata: I will be exposing Kratos' metadata_public field. This will allow you to attach arbitrary JSON data—like user roles, billing plans, or phone numbers—directly to the identity object, managed entirely via API.

Stop Building, Start Shipping

Building an authentication and multi-tenancy layer from scratch is almost never a competitive advantage for your business. It is a necessary evil.

By leveraging a battle-tested open-source engine like Ory Kratos and wrapping it in a blazingly fast, secure Rust gateway, Gate Identity gives you enterprise-grade isolation out of the box. You get to skip the infrastructure headache and go straight to building your core product.

You can check out the documentation and try it out for your next project right now. As promised, the core features are available for free with a generous tier designed specifically for early-stage and indie projects.

I’d love to hear your thoughts! What authentication feature do you usually struggle with the most when starting a new B2B SaaS? Are webhooks, MFA, or social logins your biggest blocker? Let's discuss in the comments below!

BDO Scraper: Rejestr Odpadów (674 000+)

Peter — Tue, 14 Apr 2026 06:22:29 +0000

TL;DR

BDO (Baza danych o produktach i opakowaniach oraz o gospodarce odpadami) to oficjalny rejestr gospodarki odpadami z 674 000+ zarejestrowanych podmiotów
Każda firma produkująca, transportująca lub przetwarzająca odpady w Polsce musi być zarejestrowana
Portal to React SPA bez publicznego API
Zbudowałem aktora na Apify, który przeszukuje rejestr i zwraca JSON za $0.03 za podmiot

Dlaczego rejestr BDO ma znaczenie dla firm w Polsce

BDO to centralna baza danych służąca do śledzenia całego cyklu życia odpadów - od wytworzenia, przez transport, aż po przetworzenie lub składowanie. Rejestr został utworzony na podstawie ustawy o odpadach i jest administrowany przez Urzędy Marszałkowskie poszczególnych województw.

Rejestracja w BDO jest obowiązkowa dla szerokiego zakresu firm: producentów wytwarzających odpady przemysłowe, firm transportujących odpady, zakładów recyklingowych i przetwarzania, importerów produktów objętych regulacjami opakowaniowymi oraz firm wprowadzających towary w opakowaniach na polski rynek. Na 2026 rok rejestr zawiera ponad 674 000 podmiotów - co czyni go jedną z największych baz compliance środowiskowego w Europie Środkowej.

Praktyczne konsekwencje są poważne. Firmy, które zlecają transport lub przetwarzanie odpadów niezarejestrowanym podmiotom, podlegają karom od 1 000 do 1 000 000 PLN zgodnie z polskim prawem ochrony środowiska. Dla organizacji zarządzających odpadami na wielu lokalizacjach lub współpracujących z dziesiątkami kontrahentów, weryfikacja statusu rejestracji BDO to rutynowy wymóg compliance.

Dlaczego portal BDO nie ma publicznego API

Portal BDO pod adresem rejestr-bdo.mos.gov.pl jest zbudowany jako aplikacja React SPA (Single Page Application). Frontend komunikuje się z usługami backendowymi przez wewnętrzne wywołania API, ale te endpointy są nieudokumentowane, wymagają tokenów sesji i używają dynamicznych wzorców zapytań zmieniających się między wdrożeniami.

Ta architektura stwarza konkretne problemy dla automatyzacji:

Brak stabilnych endpointów REST do bezpośredniego wywołania
Uwierzytelnianie oparte na sesji z ochroną CSRF
Dynamiczne renderowanie JavaScript oznacza, że proste zapytania HTTP zwracają puste szkielety
Jedno wyszukiwanie na raz, bez eksportu hurtowego
Brak udokumentowanego formatu danych lub schematu do programistycznego użycia

Dla zespołów compliance środowiskowego weryfikujących dziesiątki kontrahentów, audytorów sprawdzających grupy kapitałowe czy firm odpadowych monitorujących rynek - ręczna weryfikacja przez portal się nie skaluje.

Dane z rejestru BDO: co otrzymujesz

Scraper zwraca ustrukturyzowany JSON dla każdego zarejestrowanego podmiotu z następującymi polami:

name - zarejestrowana nazwa firmy
bdoNumber - unikalny numer rejestracji BDO
nip - Numer Identyfikacji Podatkowej
regon - numer identyfikacji statystycznej REGON
province - województwo rejestracji
registrationDate - data dodania podmiotu do BDO
status - aktualny status rejestracji (aktywny, zawieszony, wykreślony)
wasteActivities - rodzaje posiadanych pozwoleń na gospodarkę odpadami

Możesz wyszukiwać po nazwie firmy, NIP, REGON lub numerze BDO. Aktor automatycznie obsługuje zarządzanie sesją React SPA, stronicowanie i ekstrakcję danych.

Jak używać BDO Rejestr Odpadów Scraper

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

run = client.actor("minute_contest/bdo-waste-registry-scraper").call(
    run_input={
        "query": "Remondis",
        "maxResults": 50
    }
)

items = client.dataset(run["defaultDatasetId"]).list_items().items
for entity in items:
    print(f"{entity.get('name')} | BDO: {entity.get('bdoNumber')}")
    print(f"  NIP: {entity.get('nip')} | Województwo: {entity.get('province')}")

JavaScript (Node.js)

import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: 'YOUR_API_TOKEN' });

const run = await client.actor('minute_contest/bdo-waste-registry-scraper').call({
    query: 'Remondis',
    maxResults: 50
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach(e => console.log(`${e.name} | BDO: ${e.bdoNumber} | NIP: ${e.nip}`));

Praktyczny przykład: kwartalny audyt kontrahentów odpadowych

Firma produkcyjna prowadzi 5 zakładów w różnych częściach Polski, z których każdy wytwarza odpady niebezpieczne i inne niż niebezpieczne. Współpracuje z 40+ kontrahentami odpadowymi - transportowymi, recyklingowymi i składowiskowymi. Zespół compliance środowiskowego musi co kwartał weryfikować, że każdy kontrahent posiada aktywną rejestrację BDO.

Używając scrapera, budują prosty skrypt, który pobiera listę kontrahentów (numery NIP z systemu ERP), odpytuje BDO dla każdego z nich i flaguje kontrahentów, których status rejestracji nie jest aktywny. Skrypt działa jako zaplanowane zadanie Apify co kwartał, eksportując wyniki do CSV, który zespół compliance przegląda. Wcześniej analityk spędzał dwa pełne dni każdego kwartału na ręcznym sprawdzaniu portalu. Ze scraperem cały audyt kończy się bez nadzoru w mniej niż 30 minut.

Kto potrzebuje BDO Scraper

Zespoły compliance środowiskowego - weryfikacja rejestracji BDO kontrahentów odpadowych
Firmy gospodarki odpadami - monitoring konkurencji, śledzenie nowych podmiotów i walidacja podwykonawców
Audytorzy - sprawdzanie compliance środowiskowego w grupach kapitałowych i łańcuchach dostaw
Firmy produkcyjne - weryfikacja całych sieci podmiotów odpadowych przed podpisaniem umów
Władze samorządowe - monitoring zarejestrowanych operatorów odpadowych w ich jurysdykcji
Zespoły raportowania ESG - dokumentowanie compliance odpadowego na potrzeby raportów zrównoważonego rozwoju

Ceny

Metoda	Koszt
Ręczne wyszukiwanie na portalu BDO	Darmowe (po jednym)
Ten aktor	~13 zł za 100 podmiotów

Darmowe $5 kredytów Apify = ~160 wyszukiwań za darmo.

FAQ

Jakie firmy muszą rejestrować się w BDO?

Każda firma w Polsce, która wytwarza odpady (poza standardowymi odpadami biurowymi typu komunalnego), transportuje odpady, zbiera lub przetwarza odpady, importuje produkty z obowiązkami opakowaniowymi lub wprowadza towary w opakowaniach na rynek, musi posiadać aktywną rejestrację BDO. Obejmuje to producentów, firmy logistyczne, recyklerów i większość importerów.

Czy mogę zweryfikować konkretną firmę po NIP lub numerze BDO?

Tak. Aktor obsługuje wyszukiwanie po nazwie firmy, NIP, REGON lub numerze rejestracji BDO. Wyszukiwanie po NIP jest najbardziej niezawodną metodą dokładnego dopasowania, ponieważ nazwy firm mogą różnić się formatowaniem między rejestracjami.

Jak scraper radzi sobie z aplikacją React SPA portalu BDO?

Aktor używa przeglądarki headless do nawigacji po aplikacji React, zarządzania tokenami sesji i ekstrakcji danych z wyrenderowanego DOM. To podejście obsługuje dynamiczne renderowanie JavaScript i zarządzanie sesjami, które uniemożliwiają bezpośredni scraping HTTP na portalu BDO.

Wyprobuj: apify.com/minute_contest/bdo-waste-registry-scraper

Ten artykuł jest częścią serii Polish Business Data APIs o programistycznym dostępie do polskich rejestrów publicznych.

Vibe Coding tapi masih acak-acakan ? Improve code dengan spec first.

Fauzi Fadhlurrohman — Tue, 14 Apr 2026 06:18:31 +0000

Vibe Coding Tapi Masih Acak-acakan? Improve Code Lo dengan Spec-First!
Pernah nggak sih lo lagi semangat-semangatnya buka VS Code, buka AI assistant (ChatGPT/Gemini/Claude), terus langsung ngetik prompt: "Bikin komponen navbar lengkap dengan dropdown dan dark mode"?

Beberapa detik kemudian, boom! Kodenya jalan. Lo ngerasa kayak hacker di film-film. Ini yang sekarang sering disebut sebagai Vibe Coding—ngoding ngikutin flow dan feeling, minta AI buatin semuanya on-the-fly.

Tapi... ada tapinya nih.

Setelah projectnya jalan seminggu, lo minta AI nambahin satu fitur kecil. Tiba-tiba, aplikasinya error. Lo minta AI benerin, malah merusak fitur lain yang udah jalan. Akhirnya, lo pusing sendiri ngebaca kode yang di-generate AI. Kenapa bisa gini?

Kenapa Vibe Coding Sering Bikin Mentok?
Masalah utamanya satu: AI itu nggak punya ingatan jangka panjang (Memory). AI bekerja berdasarkan context window. Saat lo ngoding secara organik (Code-First) lewat puluhan prompt, AI lama-lama bakal "lupa" sama aturan awal, struktur database, atau arsitektur yang udah disepakati di prompt pertama. Kalau lo nggak punya dokumentasi yang jelas dan cuma ngandelin history chat, AI bakal mulai halusinasi dan ngasih solusi yang nabrak sana-sini.

Hasilnya? Welcome to Spaghetti Code 🍝
Kalau lo memaksakan code-first bareng AI tanpa planning, selamat, lo baru aja menciptakan Spaghetti Code.

Spaghetti code itu ibarat mie yang kusut; kodenya saling melilit, nggak terstruktur, dan susah banget di-maintain.
Contoh Spaghetti Code: Bayangin lo punya satu file UserDashboard.js yang isinya 1000 baris. Di satu file itu, lo nge-fetch data dari API langsung di dalam render, nge-handle business logic yang kompleks, nyampur CSS inline, dan ada manipulasi state yang berlapis-lapis. Begitu lo mau ubah warna tombol, tiba-tiba query database-nya ikut error. Kusut banget kan?

Solusinya: Spec-First Development
Biar kode nggak jadi spaghetti dan AI tetap on track, lo harus ubah mindset dari Code-First jadi Spec-First.

Artinya: Tulis dulu spesifikasinya, aturannya, dan arsitekturnya, baru suruh AI nulis kodenya berdasarkan spesifikasi itu.

Nah, buat nerapin ini tanpa ribet, gue mau ngenalin satu tool yang gue buat namanya Specter 🔮.

Kenalan sama Specter 🔮
Specter adalah sebuah framework dokumentasi berbasis CLI yang di-desain khusus buat Spec-driven development dengan dukungan AI.

Intinya, Specter bakal bikinin struktur folder dokumentasi yang rapi di dalam project lo. Jadi, setiap kali lo mau nge-prompt AI, lo tinggal ngasih file spesifikasi dari Specter sebagai konteksnya. AI-nya jadi lebih pinter dan terarah!

Fitur Andalan Specter:

Organized Structure: Bikin folder docs yang super komprehensif buat misahin spek, rencana, sampai progress.
AI-Ready: Format dokumentasinya udah dioptimasi biar gampang dibaca dan dipahami sama AI (ChatGPT/Gemini/Cursor, dll).
Spec-Driven: Memaksa kita buat mikir spesifikasi dulu sebelum nulis kode.
Easy Setup: Cukup satu command, beres!
Cara Install & Quick Start

Lo bisa install Specter secara global pakai npm:
npm install -g specter

Atau kalau mau langsung sikat pakai npx:

Initialize di folder saat ini

npx specter init

Atau initialize di spesifik direktori

npx specter init ./my-project

Nanti, Specter bakal otomatis nge-generate project configuration .specterrc yang isinya metadata project lo kayak gini:

{ "version": "1.0.0", "projectName": "My Project", "createdAt": "2026-04-14T12:00:00.000Z", "specDriven": true, "aiEnabled": true }

Dan yang paling penting, Specter bakal buatin struktur folder dewa ini:

docs/ ├── specs/ # Buat naruh spesifikasi fitur, API, dan business rules ├── plans/ # Roadmap, milestone, dan sprint planning ├── tasks/ # Todo list dan task dependencies ├── techstacks/ # Dokumentasi tech stack & instruksi setup └── progress/ # Tracking progress dan blocker

Gimana Cara Pakainya Biar "Vibe Coding" Tetep Rapi?
Biar lo kebayang, ini contoh workflow mantep gabungin Specter sama AI:

Skenario: Mau bikin fitur "User Authentication"

Bikin Spek Dulu: Jangan langsung nyuruh AI ngoding. Lo masuk ke folder docs/specs/ dan bikin file auth-spec.md. Tulis di situ: "Kita pakai JWT, expirynya 24 jam, password harus di-hash pakai bcrypt."

Bikin Task: Masuk ke docs/tasks/auth-tasks.md, pecah jadi kerjaan kecil: (1) Bikin UI Login, (2) Bikin Endpoint API, (3) Setup Middleware.

Prompting ke AI: Nah, sekarang waktunya vibe coding! Lo tinggal copy-paste (atau attach file) auth-spec.md ke AI dan bilang: "Tolong buatin Endpoint API berdasarkan spesifikasi di file ini."

Update Progress: Kalau udah kelar, catet di folder docs/progress/.

Hasilnya? Kode lo bakal jauh lebih modular, nggak ada lagi cerita AI lupa context, dan nggak ada lagi yang namanya spaghetti code.

Penutup
Vibe coding pakai AI itu emang seru banget dan bikin kita produktif parah. Tapi tanpa struktur yang jelas, project lo cuma tinggal nunggu waktu buat runtuh.

Dengan metode Spec-First pakai Specter, lo bisa tetep ngoding cepet bareng AI, tapi dengan kualitas engineering yang solid dan terstruktur.

Tertarik cobain? Langsung aja meluncur ke reponya:

Jangan lupa support dengan kasih ⭐ di repository-nya ya! Built with 💚 for spec-driven development.

Gimana menurut kalian soal Spec-First development vs Code-First? Yuk diskusi di kolom komentar! 👇

CodeMap: мой первый плагин для Android Studio, который рисует то, что я не мог удержать в голове

roma romas — Tue, 14 Apr 2026 06:14:50 +0000

Привет!

Меня зовут Роман, я начинающий Android-разработчик. И это мой первый плагин для JetBrains Marketplace.

Сразу скажу: я не сеньор с десятью годами опыта, и у меня нет портфолио из пятнадцати проектов. Я обычный разработчик, который столкнулся с проблемой — и попытался её решить. Кажется, получилось неплохо.

🤯 Проблема, которая меня доканала
Когда я только начинал разбираться с Kotlin и Android, всё было понятно. Один Activity, пара кнопок, setOnClickListener — красота, всё перед глазами.

А потом появились ViewModel, UseCase, Repository, DataSource, Dagger/Hilt, корутины, Flow... И в какой-то момент я поймал себя на том, что просто не могу удержать в голове картину происходящего. Вот нажали на кнопку — данные пошли куда-то туда, потом завернули сюда, потом что-то заэмитили... Я постоянно терял нить.

Ctrl+Click помогает перейти к определению метода, но он не показывает путь. Он показывает дверь, но не коридор. А мне нужна была карта.

И я начал рисовать эти цепочки на бумаге. Честно. Квадратики, стрелочки. Потом в Miro. А потом подумал: «Слушай, я же программист. Почему я это делаю руками?»

Так родилась идея CodeMap.

🗺 Что делает CodeMap?
Если коротко: он строит интерактивный граф вызовов функций в вашем Kotlin-проекте.

Выбираете точку входа (например, onCreate в MainActivity) — и плагин показывает, какие функции она вызывает, те вызывают следующие, и так по цепочке вниз. Визуально это выглядит как дерево или граф, где каждая нода — функция, а стрелки — вызовы.

Фичи, которые я запилил:
🎨 Цветовое кодирование
Разные типы вызовов красятся по-разному:

UI-вызовы

Сетевые запросы

Работа с базой данных

Асинхронные операции (корутины)

Системные вызовы

Глаз сразу цепляется: «Ага, вот тут ViewModel лезет напрямую в SharedPreferences, а должен бы через Repository».

🔀 Ветвление условий
Если в коде есть if или when, плагин показывает оба пути. Можно кликнуть и пройти по нужной ветке. Удобно, когда разбираешь сложную бизнес-логику.

🏛 Аудит архитектуры
Это, наверное, самая амбициозная часть. Плагин автоматически проверяет проект на соответствие с выбранной архитектурой и показывает нарушения которые можно скачать.

⚡ Навигация в один клик
Кликаешь по ноде в графе — и сразу прыгаешь на нужную строку в коде. Никакого поиска по проекту, никакого Ctrl+Shift+F.

🔄 Поддержка K2
Плагин полностью работает с новым компилятором Kotlin K2. Никаких «ой, у меня новая версия студии, всё сломалось».

🛠 Как пользоваться
Всё просто:

Установить плагин из Marketplace

Нажать «🚀 Анализировать проект»

Выбрать файл и функцию на боковой панели

Разглядывать граф и тыкать в ноды

⚠️ Важное замечание про среду выполнения
Если окно инструмента пустое — не пугайтесь. Это значит, что ваша Android Studio запущена на JDK без поддержки JCEF (Chromium Embedded Framework). Решается за минуту:

Shift+Shift → «Choose Boot Java Runtime for the IDE»

Выбрать встроенный JetBrains Runtime (JBR) с поддержкой JCEF

Перезапустить студию
Примеры разбора проектов

🤔 Что дальше?
Плагин живёт в JetBrains Marketplace. Он бесплатный. Я продолжаю его допиливать в свободное время.

Буду очень рад обратной связи. Если что-то сломалось, если есть идеи по фичам, если просто хотите сказать «прикольно» или «фигня» — пишите в комментарии или создавайте issue на GitHub.

Для меня это первый серьёзный проект, который вышел за пределы моего ноутбука. И честно — мне немного страшно и очень интересно, что вы скажете.

Всем добра и читаемого кода! 🚀

P.S. Если плагин покажется полезным — поставьте звёздочку на GitHub и лайк в Marketplace. Для начинающего разработчика каждая звёздочка как допамин прямо в мозг 😅

Why Your Arduino Input Feels Wrong When It Should Work

張旭豐 — Tue, 14 Apr 2026 06:13:14 +0000

Why Your Arduino Input Feels Wrong When It Should Work

A button that sometimes doesn't register. A touch sensor that fires twice. A digital input that acts like it has "bad luck" timing.

If you've experienced this, the problem isn't your wiring. It's something most tutorials skip entirely.

The Problem Nobody Explains

Head over to Stack Exchange and search "Arduino input not working" — you'll find a question with 41 upvotes and 109,000 views asking exactly this.

The top answer explains the fix in two words: INPUT_PULLUP.

But here's what the answer doesn't tell you:

Your circuit isn't broken. Your Arduino is reading noise.

When a pin is set to INPUT with nothing connected, it floats. It picks up electrical interference from the air — your hand nearby, a power cable, ambient humidity. The pin randomly reads HIGH or LOW with no predictable pattern.

This isn't a defect. It's physics.

(Fig 1: A floating pin — without pull-up or pull-down, the Arduino reads noise, not your button)

The Two Ways to Fix It

Option 1: External Pull-Down Resistor

Connect a 10kΩ resistor between the pin and GND. This forces the pin to read LOW when the button is open.

Option 2: Internal Pull-Up (the elegant solution)

One line in your setup:

pinMode(2, INPUT_PULLUP);

That's it. The Arduino's built-in 20kΩ resistor now pulls the pin HIGH by default. When you press the button (connected between pin 2 and GND), it reads LOW.

(Fig 2: With INPUT_PULLUP, the Arduino's internal resistor keeps the pin HIGH until the button connects it to GND)

Why This Makes Your Interactive Project Feel Different

Here's what most tutorials miss: after fixing the pull-up, your button behavior is now inverted from what you'd expect.

Button open → pin reads HIGH
Button pressed → pin reads LOW

This inversion trips people up. But once you understand it, you can design around it naturally.

A Second Layer: Debounce

Even after adding pull-ups, mechanical buttons have a problem: they bounce.

When metal contacts close, they physically bounce apart and together multiple times within a few milliseconds. Your Arduino — which can read millions of times per second — interprets each bounce as a separate press.

bool lastButtonState = HIGH;
unsigned long lastDebounceTime = 0;

void loop() {
    int reading = digitalRead(2);

    if (reading != lastButtonState) {
        lastDebounceTime = millis();
    }

    if (millis() - lastDebounceTime > 50) {
        // Actual button state after debounce
        if (reading == LOW) {
            // Button is pressed — do something
        }
    }

    lastButtonState = reading;
}

The 50ms threshold is a starting point. Adjust based on your specific button's bounce characteristics.

What This Has to Do With Interactive Art

Most maker tutorials treat buttons as on/off switches. But in interactive work, a button is not a binary — it's a moment of contact between a person and a machine.

When that contact feels unreliable, the interaction breaks. The person questions whether they pressed hard enough, whether they should press again, whether the system is broken.

Fixing the pull-up and debounce does not just make your code work correctly. It makes the interaction feel trustworthy. The person can stop thinking about the button and start engaging with the experience.

The Version That Changed How I Thought About It

A few months into building interactive pieces, I stopped thinking about pins and resistors. I started thinking about this:

A floating input is the machine equivalent of anxiety. It is reacting to phantom signals because it does not know what is real.

Adding a pull-up gives the machine something to hold onto. A baseline. A sense of ground.

That shift in thinking — from "how do I wire this" to "what does the machine need to feel stable" — changed everything about how I approached input design.

If you want to go deeper on input design for interactive work, I write about the gap between "it works" and "it feels right" in my dev logs.

How to Give Your AI Agent a Multi-Chain Crypto Wallet in 5 Minutes

EmblemAI — Tue, 14 Apr 2026 06:10:35 +0000

Most AI agents hit the same wall: they can reason about money yet cannot touch it. EmblemAI solves this with a single npm package that gives any AI agent a deterministic crypto wallet spanning 7 blockchains and access to 200+ autonomous trading tools. This tutorial walks you through install, authentication, and your first on-chain operation.

The problem: agents without wallets are spectators

Most agent frameworks ship with no native financial capability. Developers end up stitching together separate SDKs for each chain, managing private keys manually, and writing custom swap logic for every DEX. A single cross-chain operation can require three or four different libraries, each with its own authentication model.

Coinbase recognized this gap and launched its Agentic Wallets product in late 2025, providing wallets with programmable guardrails. EmblemAI takes a different approach: a CLI-first tool that any agent framework can shell out to, with 200+ pre-built trading tools across 14 categories and support for Solana, Ethereum, Base, BSC, Polygon, Hedera, and Bitcoin out of the box.

Step 1: Install the CLI

EmblemAI ships as a global npm package. One command, no configuration files.

npm install -g @emblemvault/agentwallet

This installs the emblemai binary. It requires Node.js 18 or later. Verify the install:

emblemai --help

The package is open source and auditable. You can compare the published npm contents against the GitHub repository at any time using npm pack --dry-run.

Step 2: Authenticate your agent

EmblemAI supports two authentication modes. For interactive development, browser auth opens a login modal. For agents running in production, password auth works without a browser.

# Interactive mode -- opens browser for login
emblemai

# Agent mode -- zero-config, auto-generates a wallet
emblemai --agent -m "What are my wallet addresses?"

Each password deterministically generates the same wallet every time. Different passwords produce different wallets. This means you can give each agent its own isolated wallet simply by assigning a unique password:

# Agent Alice gets her own wallet
emblemai --agent -p "agent-alice-wallet-001" -m "What are my balances?"

# Agent Bob gets a completely separate wallet
emblemai --agent -p "agent-bob-wallet-002" -m "What are my balances?"

Credentials are encrypted at rest using AES-256-GCM via dotenvx. The encryption key never leaves the local machine.

Step 3: Query balances across all chains

Once authenticated, the agent has wallet addresses on every supported chain. A single natural-language query returns balances across all 7 blockchains simultaneously.

emblemai --agent -m "Show my balances across all chains"

The agent wallet provides addresses across these chain types:

Chain	Address Type
Solana	Native SPL wallet
Ethereum, Base, BSC, Polygon	Shared EVM address
Hedera	Account ID (0.0.XXXXXXX)
Bitcoin	Taproot, SegWit, and Legacy

This is one wallet identity spanning 7 chains. No separate setup per chain. No bridge configuration.

Step 4: Execute your first swap

EmblemAI interprets natural language, so your agent does not need to construct raw transaction parameters. The tool handles routing, slippage, and gas estimation.

emblemai --agent -m "Swap 20 dollars worth of SOL to USDC on Solana"

The agent operates in safe mode by default. All wallet-modifying actions, including swaps, sends, transfers, and order placement, require explicit confirmation before execution. Read-only operations like balance checks and market data queries execute immediately.

For scripted pipelines, output can be piped to other tools:

emblemai --agent -m "What is my SOL balance?" | jq .

Step 5: Multi-chain operations

The real power is cross-chain. EmblemAI supports bridge operations via ChangeNow, DeFi position management, limit orders, and market data aggregation from CoinGlass, DeFiLlama, Birdeye, and LunarCrush.

# Cross-chain bridge
emblemai --agent -m "Bridge 50 USDC from Ethereum to Solana"

# DeFi operations
emblemai --agent -m "What are the best yield opportunities for USDC right now?"

# Market intelligence
emblemai --agent -m "What tokens are trending on Solana today?"

The 200+ tools are organized into 14 categories: trading, DeFi, market data, NFTs, bridges, memecoins, predictions, and more. The AI dynamically selects the right tools based on the query. No manual tool configuration required.

Integration with any agent framework

Because emblemai is a CLI binary, any system that can shell out to a command can use it. This works with CrewAI, AutoGPT, LangChain agents, Claude with tool use, or custom Python scripts:

import subprocess
import json

def agent_wallet_query(message: str) -> str:
    result = subprocess.run(
        ["emblemai", "--agent", "-m", message],
        capture_output=True, text=True
    )
    return result.stdout

# Any agent can now trade
balances = agent_wallet_query("Show my portfolio summary")

EmblemAI also provides an MCP (Model Context Protocol) server, which means Claude Code, GitHub Copilot, Gemini CLI, and other MCP-compatible tools can access wallet operations natively without shelling out. The platform additionally supports Google's A2A (Agent-to-Agent) protocol for direct agent interoperability.

What you get

EmblemAI provides 200+ autonomous trading tools across 7 blockchains in 14 categories, accessible through a single npm install. The deterministic wallet model means one password equals one persistent identity across all chains.

The package is open source, the credentials are encrypted at rest, and every transaction requires explicit human approval. Full documentation is available at emblemvault.dev, and the npm package is at @emblemvault/agentwallet.

AI Search Showdown: Perplexity vs SearchGPT vs Claude 3.5 Sonnet (2026)

Mimo2026 — Tue, 14 Apr 2026 06:09:55 +0000

Comparative Feature Map: Perplexity AI vs. OpenAI SearchGPT vs. Claude 3.5 Sonnet

A hands-on evaluation using three identical complex prompts across accuracy, speed, citations, and multi-modal capabilities.

Methodology

To ensure fairness, I tested all three models with the same three research prompts representing distinct use cases:

Coding: "Debug and optimize a Python async web scraper that times out on large pages and has memory leaks. Explain the fixes and provide the corrected code."
General Knowledge: "What were the primary economic and geopolitical drivers behind Japan's Lost Decades, and how do they compare to China's current economic trajectory?"
Academic Research: "Provide a critical review of the evidence for GLP-1 receptor agonists in reducing cardiovascular events, including the SELECT trial, LEADER trial, and any 2024 meta-analyses."

Comparison Matrix

Dimension	Perplexity AI	OpenAI SearchGPT	Claude 3.5 Sonnet
Accuracy	⭐⭐⭐⭐☆ (4/5) Strong for factual queries; occasionally misses nuance in highly technical domains	⭐⭐⭐⭐☆ (4/5) Broad knowledge base; prone to "hallucinating" confidence in edge cases	⭐⭐⭐⭐⭐ (5/5) Best at admitting uncertainty; fewer hallucinations in technical reasoning
Speed	⭐⭐⭐⭐⭐ (5/5) Fastest (~3-5s for simple queries, ~8-12s for complex)	⭐⭐⭐⭐☆ (4/5) Fast (~4-6s simple, ~10-15s complex)	⭐⭐⭐☆☆ (3/5) Slowest (~6-10s simple, ~15-25s complex)
Citations	⭐⭐⭐⭐⭐ (5/5) Always provides inline links; easy to verify	⭐⭐⭐⭐☆ (4/5) Good source integration but links can be buried or generic	⭐⭐☆☆☆ (2/5) Rarely provides direct links; relies on training data without live sourcing
Multi-modal	⭐⭐⭐☆☆ (3/5) Limited image understanding; focuses on text search	⭐⭐⭐⭐☆ (4/5) Strong image analysis via GPT-4o; chart interpretation is solid	⭐⭐⭐⭐⭐ (5/5) Excellent at reading PDFs, charts, and images; best document analysis

Best-in-Class by Category

🏆 Coding: Claude 3.5 Sonnet

Why it wins: Claude consistently produced the most robust, well-explained code. For the async scraper prompt, it:

Identified both the timeout and memory leak root causes correctly
Explained aiohttp connection pooling and BeautifulSoup memory fragmentation
Provided clean, production-ready code with error handling
Added comments explaining why each change was made

Runner-up: SearchGPT provided functional code but with less nuanced explanation. Perplexity gave good high-level guidance but the code snippet was sometimes too abbreviated for direct use.

🏆 General Knowledge: OpenAI SearchGPT

Why it wins: SearchGPT delivered the most comprehensive and well-structured answer on Japan's Lost Decades vs. China's trajectory. It:

Balanced economic and geopolitical angles effectively
Drew clear comparative parallels (property bubbles, demographic shifts, export dependence)
Maintained a readable narrative flow without getting lost in minutiae

Runner-up: Claude was more cautious and precise but slightly drier. Perplexity was factually solid but sometimes overly list-like in structure.

🏆 Academic Research: Perplexity AI

Why it wins: For the GLP-1 cardiovascular evidence review, Perplexity was unmatched. It:

Cited the SELECT and LEADER trials with direct PubMed links
Referenced a 2024 meta-analysis (JACC) that I could verify immediately
Structured the response like a mini-literature review
Provided confidence levels for each claim

Runner-up: Claude gave an excellent critical analysis but without live citations, making verification harder. SearchGPT cited sources but occasionally mixed up trial endpoints.

Best Value for $20/Month Subscription

Winner: Claude 3.5 Sonnet (via Claude Pro at $20/mo)

While Perplexity Pro ($20/mo) and ChatGPT Plus ($20/mo) are both competitive, Claude 3.5 Sonnet offers the best overall value for a single subscription because:

Lowest hallucination rate: You spend less time fact-checking or debugging bad outputs
Best coding assistant: Comparable to dedicated tools like GitHub Copilot ($10-19/mo extra)
Best document analysis: Can process PDFs, charts, and images with industry-leading comprehension
Longest context window (200K tokens): Ideal for research, legal, and academic workflows

However, if your primary need is real-time research with citations, Perplexity Pro is the better $20 investment. If you need versatility across text, image, and voice, ChatGPT Plus is the safest all-rounder.

Summary Table

Use Case	Winner	Why
Coding	Claude 3.5 Sonnet	Best reasoning + code quality
General Knowledge	SearchGPT	Most comprehensive and readable
Academic Research	Perplexity AI	Unmatched live citations
Speed	Perplexity AI	Fastest responses
Multi-modal	Claude 3.5 Sonnet	Best PDF/chart/image analysis
Best $20 Value	Claude 3.5 Sonnet	Lowest error rate, longest context, best coding

Tested April 2026 with identical prompts across all three platforms.

Estoy construyendo un cliente de Git nativo para macOS en SwiftUI — así va la semana 1

Pool Camacho — Tue, 14 Apr 2026 06:07:09 +0000

Maple es un cliente de Git nativo, gratis y rápido para macOS hecho en SwiftUI. Sin webviews, sin Electron, sin suscripciones. Habla directo con git en tu máquina y no pretende esconder el modelo real de Git detrás de abstracciones raras.

Repo: https://github.com/poolcamacho/Maple · Licencia: MIT · 🇺🇸 Read in English

Por qué otro cliente de Git

En macOS ya hay GUIs de Git muy decentes — Tower y Fork son las que más me gustan. Empecé Maple por algo más específico: quería una app que fuera gratis, open source, 100% SwiftUI nativo, y sin miedo a exponer el modelo real de Git para power users, y a la vez quería aprender SwiftUI moderno construyendo algo que yo mismo usara todos los días.

Maple arrancó con un brief bien acotado:

100% SwiftUI nativo — sin webviews, sin Electron, abre tan rápido como Terminal.
Gratis y MIT — nunca suscripción.
Muestra Git como es — commit graph con topología real, branches y merges visibles, vista de conflictos de verdad. Cero wizards que escondan lo que está pasando.
Respeta tu flujo — shortcuts y acciones para lo que un power user realmente usa: interactive staging, stash, rebase, merge, cherry-pick.

No pretende reemplazar a Tower para todo el mundo. Es el cliente que yo quería que existiera.

Lo que ya hace

Esto es un post de avance, no un lanzamiento. Las capturas las subiré en el próximo post. Pero esto ya funciona de punta a punta en repos reales (llevo varios días dogfooding con la misma app para commitear su propio código):

Abrir cualquier repo local con el folder picker y validación de .git
Sidebar con lista de repos, branches locales y remotos
Toolbar con Pull, Push, Fetch, Stash, Branch, Merge, Rebase
Cuatro tabs: Changes, History, Branches, Stashes
Diff viewer con hunks coloreados, números de línea, y un toggle de Blame
Commit graph con topología real — algoritmo de lanes, edges curvos por cada parent, merges dibujados con círculos anillados
Merge y rebase con manejo de conflictos — detecta UU/AA/DD, banner de operación con Abort / Continue / Skip, y resolución por archivo con Use Ours / Use Theirs
Auto-refresh vía FSEvents sobre .git/
Layout adaptativo de desktops anchos a pantallas compactas

La arquitectura en una pantalla

Models/     — Data pura y Sendable (AppState, GitModels, StashModels)
Services/   — GitService (actor, ejecuta el CLI)
              GitCoordinator (@MainActor, orquestación)
              Extensiones por comando (GitCommands, GitBranchOps,
              GitStashOps, GitMergeRebase)
              CommitGraphBuilder, ConflictParser, FileWatcher
Views/      — Un archivo por vista, cero lógica de negocio
Utils/      — FolderPicker, DateExtensions

Tres decisiones que vale la pena llamar aparte:

GitService es un actor, así que todas las llamadas al CLI se serializan por un solo "portero". GitCoordinator es @MainActor y hace de pegamento entre la UI y el actor — las vistas solo llaman state.coordinator.* y nunca tocan un Process directamente. Resultado: lógica de negocio cero en las vistas, fácil de testear y refactorizar.

Cada invocación de git abre un /dev/null fresco para stdin y cierra sus pipes explícitamente. Sin eso me salía NSPOSIXErrorDomain code=9 / EBADF después de comandos largos como push, porque FileHandle.nullDevice es un singleton compartido que termina en estados raros después de muchos posix_spawn. Abrir /dev/null por llamada con closeOnDealloc: true lo arregla de tajo.

El commit graph no es el "punto + línea vertical" de toda la vida. Construye un layout real de lanes: para cada commit, reclama el lane que lo estaba esperando (el vínculo child→parent); si no hay, reusa un lane libre. Los primeros parents se quedan en el mismo lane para que la línea principal quede recta; los parents adicionales de merges abren lanes laterales con edges curvos. Los edges se resuelven en una segunda pasada porque un parent puede aparecer muchas filas más abajo.

El UX de conflictos es por archivo, no por hunk — a propósito para v1. Cuando cae un merge con conflicto, el tab Changes marca cada archivo conflictivo con un ! morado, y cada uno tiene tres botones: Use Ours, Use Theirs, o editas los markers tú mismo en tu editor favorito. Arriba aparece un banner persistente que dice Merging X con Abort / Continue / Skip. Sin modales, sin secuestrarte el flujo.

Lo que ya está armado alrededor del código

Porque la idea es que esto crezca como proyecto OSS serio, no como experimento de fin de semana:

GitHub Actions CI — build + xcodebuild analyze + SwiftLint strict en cada push y PR
CodeQL — análisis semanal de Swift más en cada PR que toque código Swift
Workflow de release — taggeas v* y sale un .app sin firmar zipeado automáticamente
Branch protection en master — status checks requeridos, no force push, no delete, conversations resueltas
Dependabot para GitHub Actions, así las versiones no se quedan oxidadas
SECURITY.md con private vulnerability reporting activado
Issue forms y PR template que fuerza la regla de "ni una sola línea de lógica de negocio en las vistas"

Nada de esto es heroico. Es el andamiaje aburrido que separa un hobby project de un repo donde la gente realmente puede contribuir.

Lo que sigue

El roadmap que estoy atacando en orden:

[ ] Interactive staging — stage de hunks o líneas individuales, no solo archivos enteros
[ ] Tag management — crear, listar, borrar tags desde la UI
[ ] Search / filtering — filtrar commits y archivos con fuzzy match
[ ] Clone from URL — ahora solo abres repos existentes, clonar es el paso obvio
[ ] Remote management — agregar, quitar, configurar remotes sin CLI
[ ] Keyboard shortcuts — Cmd+S stage, Cmd+Enter commit, Cmd+K command palette
[ ] Persistir repos abiertos entre sesiones
[ ] Settings & preferences
[ ] Releases firmados + notarizados cuando la app ya esté lista para usuarios no-devs

Pruébalo y ayúdame a darle forma

MIT, open source, todo en público:

→ github.com/poolcamacho/Maple

Si tienes macOS 14+ y Xcode 16+, git clone + Cmd+R y lo tienes corriendo en menos de un minuto. Abre issues si te topas con un flujo de Git que la UI vuelve torpe — prefiero arreglar eso a adivinar qué necesitan los power users.

Si quieres patrocinar el proyecto para que se mantenga gratis y activo, hay botón Sponsor arriba del repo, o directo en github.com/sponsors/poolcamacho. El patrocinio mantiene Maple libre para todos y me ayuda a cubrir el presupuesto de firma + notarización que voy a necesitar para shipear a usuarios no-devs.

El próximo post probablemente sea sobre interactive staging — es el problema de diseño más interesante de la lista. Nos leemos.

I'm building a native macOS Git client in SwiftUI — here's week one

Pool Camacho — Tue, 14 Apr 2026 06:07:09 +0000

Maple is a free, fast, native macOS Git client built with SwiftUI — no web views, no Electron, no subscription. It talks directly to git on your machine and exposes the full power of Git without hiding it behind abstractions.

Repo: https://github.com/poolcamacho/Maple · License: MIT

Why another Git client

There are solid Git GUIs on macOS already — Tower and Fork are both great. I started Maple for a narrower reason: I wanted something that was free, open source, native SwiftUI, and unapologetically power-user friendly, and I wanted to learn modern SwiftUI by building something I'd actually use every day.

So Maple has a pretty specific design brief:

Fully native SwiftUI — no web views, no Electron, opens as fast as Terminal.
Free and MIT-licensed — no subscription, ever.
Shows Git as it is — full commit graph with real topology, visible branches and merges, proper conflict view. No wizards that hide what's happening.
Respects your workflow — shortcuts and actions for the operations power users actually care about: interactive staging, stash, rebase, merge, cherry-pick.

It's not a replacement for Tower for everyone. It's the one I wanted to exist.

What it does today

The screenshots will come later — I'm publishing this as a progress post, not a launch — but here's what's already working end-to-end on a real repo:

Open any local repo via folder picker, with .git validation
Sidebar with repository list, local and remote branches
Toolbar with Pull, Push, Fetch, Stash, Branch, Merge, Rebase
Four tabs: Changes, History, Branches, Stashes
Live diff viewer with colored hunks, line numbers, and a Blame toggle
Commit graph with real topology — lane assignment algorithm, curved edges per parent, merge nodes drawn as ringed circles
Merge and rebase with conflict handling — UU/AA/DD detection, an operation banner with Abort / Continue / Skip, and per-file Use Ours / Use Theirs resolution
Auto-refresh via FSEvents on .git/
Adaptive layout from wide desktops down to compact laptop windows

It's a real client already. I've been dogfooding it to commit and push the work on itself.

The architecture, in one screen

Models/     — Pure Sendable data (AppState, GitModels, StashModels)
Services/   — GitService (actor, CLI execution)
              GitCoordinator (@MainActor orchestration)
              Command extensions (GitCommands, GitBranchOps,
              GitStashOps, GitMergeRebase)
              CommitGraphBuilder, ConflictParser, FileWatcher
Views/      — One file per view, zero business logic
Utils/      — FolderPicker, DateExtensions

A couple of decisions worth calling out:

GitService is an actor, so all CLI calls serialize behind a single gatekeeper. GitCoordinator is @MainActor and sits between the views and the actor — views only call state.coordinator.* and never touch Process or Pipe directly.

Every git invocation uses a fresh /dev/null stdin and closes its pipes explicitly. Without that, I was getting NSPOSIXErrorDomain code=9 / EBADF errors after long-running commands like push, because FileHandle.nullDevice is a shared singleton that drifts into bad states across many posix_spawn calls. Opening /dev/null per call with closeOnDealloc: true fixed it.

The commit graph isn't the usual “dot + vertical line” fake. It builds an actual lane layout: for each commit, claim the lane that expects it (child→parent link), otherwise reuse a free lane. First parents stay in the same lane to keep the main line straight; extra parents on merges spawn side lanes with curved connectors. Edges are resolved in a second pass because a parent may appear many rows later.

Conflict UX is per-file, not per-hunk — on purpose for v1. When a merge conflict lands, the Changes tab lights up conflicted files with a purple ! marker, and each one offers a three-button bar: Use Ours, Use Theirs, or edit the markers in your own editor. A persistent banner at the top of the window shows Merging X with Abort / Continue / Skip. No modal dialogs, no hijacking your workflow.

What's already in place beyond the app itself

Because I want this to grow as a real OSS project and not as a one-off:

GitHub Actions CI — build + xcodebuild analyze + SwiftLint (strict) on every push and PR
CodeQL — scheduled weekly Swift analysis, plus on any PR that touches Swift code
Release workflow — tag v* to publish an unsigned .app zip automatically
Branch protection on master — required status checks, no force push, no deletion, conversation resolution required
Dependabot for GitHub Actions, so pinned action versions stay fresh
SECURITY.md with private vulnerability reporting enabled
Issue forms and a PR template that enforces the “no business logic in views” rule

None of this is heroic, but it's the boring scaffolding that turns a weekend project into something other people can actually contribute to.

What's next

The roadmap I'm actively working through:

[ ] Interactive staging — stage individual hunks and lines instead of whole files
[ ] Tag management — create, list, delete from the UI
[ ] Search filtering — filter commits and files with fuzzy matching
[ ] Clone from URL — right now you open existing repos; cloning is the obvious next step
[ ] Remote management — add, remove, configure remotes without dropping to CLI
[ ] Keyboard shortcuts — Cmd+S to stage, Cmd+Enter to commit, Cmd+K for the command palette I haven't built yet
[ ] Persist open repositories between sessions
[ ] Settings & preferences
[ ] Signed + notarized releases once the app is ready for non-developer users

Try it, and help shape where it goes

It's MIT-licensed, open source, and built in public:

→ github.com/poolcamacho/Maple

If you're on macOS 14+ with Xcode 16+, git clone and Cmd+R in Xcode gets you running in under a minute. Please open issues — especially if you hit a Git workflow the UI makes awkward. I'd much rather fix that than guess what power users need.

And if you want to sponsor the work so it stays free and actively maintained, there's a Sponsor button at the top of the repo, or you can go directly to github.com/sponsors/poolcamacho. Sponsorship keeps Maple free for everyone and funds the signing + notarization budget I'll need for shipping to non-developers.

Next post will probably be about interactive staging — that one's the most interesting design problem on the list. Stay tuned.

I got tired of writing launchd XML by hand, so I built launchd-gen

Vandy Sodanheang — Tue, 14 Apr 2026 06:05:31 +0000

If you've ever tried to schedule a recurring job on macOS, you've met launchd. And if you've spent more than five minutes with it, you've probably thought: "Why is this so much harder than crontab?"

This is the story of why I built launchd-gen — a small Go CLI that takes a familiar cron expression and emits a valid macOS launchd property list, ready to drop into ~/Library/LaunchAgents/.

The problem with launchd

launchd is the modern replacement for cron on macOS. It's more powerful (it can react to filesystem events, network changes, system load, etc.), but for the 80% case — "run this script every weekday at 9 AM" — it's significantly more painful than crontab.

Here's what a "run every weekday at 9 AM" looks like in cron:

0 9 * * 1-5 /usr/local/bin/my-script

One line. Five fields. Done.

Here's what the equivalent looks like as a launchd plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.me.my-script</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/bin/my-script</string>
    </array>
    <key>StartCalendarInterval</key>
    <array>
        <dict>
            <key>Minute</key>
            <integer>0</integer>
            <key>Hour</key>
            <integer>9</integer>
            <key>Weekday</key>
            <integer>1</integer>
        </dict>
        <dict>
            <key>Minute</key>
            <integer>0</integer>
            <key>Hour</key>
            <integer>9</integer>
            <key>Weekday</key>
            <integer>2</integer>
        </dict>
        <dict>
            <key>Minute</key>
            <integer>0</integer>
            <key>Hour</key>
            <integer>9</integer>
            <key>Weekday</key>
            <integer>3</integer>
        </dict>
        <dict>
            <key>Minute</key>
            <integer>0</integer>
            <key>Hour</key>
            <integer>9</integer>
            <key>Weekday</key>
            <integer>4</integer>
        </dict>
        <dict>
            <key>Minute</key>
            <integer>0</integer>
            <key>Hour</key>
            <integer>9</integer>
            <key>Weekday</key>
            <integer>5</integer>
        </dict>
    </array>
</dict>
</plist>

Five times the fields. Forty times the lines. And here's the part that really gets you:

launchd has no concept of ranges

The reason that plist needs five <dict> entries is that launchd's StartCalendarInterval only accepts single integer values per key. There is no way to say "weekdays 1 through 5" in a single dict — you have to expand the range yourself by writing one dict per day.

This is annoying for 1-5. It becomes ridiculous fast:

*/15 9-17 * * 1-5

That's "every 15 minutes during business hours on weekdays" — a perfectly reasonable cron expression. To express it as a launchd plist, you have to write 180 separate <dict> entries, because it's the cartesian product of:

4 minute values: 0, 15, 30, 45
9 hour values: 9, 10, 11, 12, 13, 14, 15, 16, 17
5 weekday values: 1, 2, 3, 4, 5

4 × 9 × 5 = 180.

Nobody types that out by hand. They either:

Drop the schedule down to a coarser interval that's easier to write
Write a script that loops launchctl calls, defeating the purpose of having a declarative scheduler
Use a third-party GUI tool like Lingon or LaunchControl
Give up and stay on crontab, which Apple has been quietly trying to deprecate since 2005

I wanted option 5: a small CLI that takes a cron expression and outputs the right plist.

Enter launchd-gen

brew tap VandyTheCoder/tools
brew install --cask launchd-gen

Then:

launchd-gen --label com.me.my-script "0 9 * * 1-5" /usr/local/bin/my-script

That's it. The output is a fully-formed launchd plist on stdout, with all 5 weekday <dict> entries expanded automatically.

To install and load it in one go:

launchd-gen --install --load \
  --label com.me.my-script \
  --stdout /tmp/my-script.log \
  --stderr /tmp/my-script.err \
  "0 9 * * 1-5" \
  /usr/local/bin/my-script

That writes the plist to ~/Library/LaunchAgents/com.me.my-script.plist and runs launchctl load on it. From cron expression to running scheduled job in one command.

What it supports

The cron parser handles everything you'd expect from standard 5-field crontab:

Pattern	Example	Means
Single value	`0 9 * * *`	At 09:00 daily
List	`0 9,17 * * *`	At 09:00 and 17:00 daily
Range	`0 9 * * 1-5`	At 09:00 on weekdays
Step	`/15 * * *`	Every 15 minutes
Range + step	`0 9-17/2 * * *`	At 09:00, 11:00, 13:00, 15:00, 17:00
Combinations	`/15 9-17 * 1-5`	Every 15 min, business hours, weekdays
Shortcuts	`@daily`, `@hourly`, `@reboot`, `@weekly`, `@monthly`, `@yearly`

The shortcuts behave exactly as crontab — @reboot becomes a RunAtLoad: true flag, the rest expand to their equivalent 5-field expressions.

Under the hood

launchd-gen is under 600 lines of production Go (plus ~200 lines of tests), with zero external dependencies. The whole thing is one binary, MIT licensed, and the source is on GitHub.

The interesting bits:

internal/cron/parser.go — turns a cron string into a list of Interval structs by computing the cartesian product of the parsed field values
internal/plist/writer.go — hand-writes the launchd XML rather than depending on a third-party plist library, which keeps the binary tiny and go install instant
main.go — the CLI entry point, with a --install flag that writes directly to ~/Library/LaunchAgents/ and a --load flag that chains a launchctl load

I deliberately avoided pulling in cobra, viper, or any of the other usual Go CLI suspects. For something this small they're overkill, and the standard library's flag package handles it just fine.

Why I built it

I run a small daily-dashboard project on my own infrastructure. It has four scheduled jobs — a news fetcher, a daily AI briefing, an activity log summarizer, and a weekly trade-config optimizer. Each one is a launchd agent, because that's how you do scheduled work on macOS in 2026.

Writing those four plists by hand was the most painful part of the whole project. The actual work the scripts do — fetching, summarizing, posting to a webhook — was easier than getting them on a schedule. That's a smell, and I wrote launchd-gen to fix it.

The four real plists from that project are now used as acceptance fixtures in the launchd-gen test suite, which is the kind of dogfooding I always look for in a tool I'm about to depend on.

What's next

v0.1.0 is shipped and it does what I built it for. The roadmap for v0.2.0:

Day-of-week names (MON, TUE, WED, ...) instead of numeric weekdays
A --dry-run flag that prints the plist without writing it
Reverse mode: convert an existing plist back into a cron expression
Environment variable injection from a file

If any of those sound useful — or if you want something else entirely — open an issue. Pull requests welcome, MIT licensed, no CLA, no committee.

Try it

brew tap VandyTheCoder/tools
brew install --cask launchd-gen
launchd-gen --help

Source, issues, and releases: github.com/VandyTheCoder/launchd-gen

If you've ever stared at a launchd plist and wondered why something this conceptually simple has to be this verbose — this is for you.

How Do Startups Decide Between MVP and Full Product Development?

Dhruv Joshi — Tue, 14 Apr 2026 06:03:09 +0000

Startups do not fail because they lacked ideas. They fail because they built too much, too soon, or too little, too late.

That is the real tension behind MVP app development versus full product development.

One path helps you test demand fast. The other helps you launch stronger, deeper, and with fewer second guesses. But choosing the wrong one can drain budget, stretch timelines, and confuse users right out of the gate.

So how do smart founders decide? They look at risk, urgency, user behavior, and growth goals. They do not guess. They choose the build path that matches the business moment. Exactly.

Quick Answer

If you need to validate demand, reduce risk, and launch fast, choose MVP app development.

If you already know the market wants your product, have funding, and need a complete experience from day one, go for full product development.

That sounds simple, but the better answer depends on your stage, money, product complexity, and startup strategy.

Let’s break it down properly.

Why This Decision Matters So Much

This is not just a product decision. It is a business survival decision.

Startups usually work with limited cash, small teams, and short runway. That means every product choice affects hiring, marketing, growth, and investor confidence. If you overbuild, you burn money before proving traction. If you underbuild, users may leave before they understand the value.

That is why MVP app development matters so much in early-stage startup strategy. It gives founders a way to test assumptions without betting everything on one launch. At the same time, some products simply cannot enter the market half-built. In those cases, a full launch makes more sense.

So the right question is not which one is better. The right question is which one is smarter for your current stage.

What is MVP App Development?

MVP app development is about building the smallest version of a product that still delivers a clear core value.

Not a broken version. Not a cheap version. Not a demo pretending to be a product.

A real MVP solves one clear problem for one clear user group. It should be usable, focused, and measurable. The goal is simple: launch fast, learn fast, improve fast.

A lot of founders get this wrong. They hear MVP app development and think they should remove everything possible. Then the product feels empty. Users do not stay. Feedback becomes messy because the product never showed enough value in the first place.

A strong MVP usually includes:

One core use case
Simple but functional design
Basic onboarding
Analytics and feedback tracking
Scalable code where it matters
Clear success metrics

For example, if you are building a delivery app, your MVP app development version may only include ordering, payments, and tracking. No loyalty program. No advanced admin suite. No fancy personalization engine yet.

That focused approach is why many founders first work with an android application development company when they want faster market testing on a tighter early budget.

What is Full Product Development?

Full product development is a broader, deeper build. It is meant for launch readiness at a much higher level.

This path includes the complete experience you expect users to need from day one. It often covers multiple workflows, polished UI, integrations, security layers, support systems, and growth features. Instead of proving one idea, the goal is to enter the market with a stronger competitive position.

Full product development often includes:

Complete user journeys
Advanced architecture
Admin dashboards
User roles and permissions
Strong security and compliance
Third-party integrations
Performance optimization
App store readiness at a high standard

This path takes more money, more time, and more coordination. But it can be the right call when partial functionality would hurt trust, adoption, or brand positioning.

Think fintech, healthtech, enterprise SaaS, or tools that depend on deep workflow completion. In those cases, a half-step product can backfire pretty badly.

MVP vs Full Product at a Glance

Factor	MVP App Development	Full Product Development
Goal	Validate idea fast	Launch complete solution
Time to Market	Faster	Slower
Cost	Lower upfront	Higher upfront
Risk	Lower early risk	Higher early risk
Feature Scope	Core features only	Broad and polished feature set
Best For	New ideas, testing demand	Proven ideas, funded growth
User Feedback	Gathered early	Gathered after larger build
Flexibility	Easier to pivot	Harder to change direction

That table makes the difference feel clean. In real life, though, the decision is usually messier.

When Startups Should Choose MVP App Development

Here is the truth: most early-stage startups should start with MVP app development.

Why? Because uncertainty is expensive.

If you do not know how users will behave, which features matter most, or what people will actually pay for, building a full product too early is risky. MVP app development helps reduce that risk while keeping your startup strategy grounded in real-world data.

Choose MVP app development when:

You Are Still Testing Market Demand

You have a strong idea, but demand is not fully proven yet. You need real users, real behavior, and real signals before investing deeper.

Your Budget Is Tight

Early money should buy learning, not just code. MVP app development helps stretch capital while still moving the product into users’ hands.

Speed Matters More Than Completeness

Sometimes getting live first matters most. Especially in crowded categories, speed helps you claim attention, gather traction, and improve before others catch up.

Your Product Can Deliver Value with One Core Use Case

If one main workflow can satisfy early users, that is a great MVP sign.

You Expect the Product to Change Fast

If your assumptions may shift after launch, MVP app development keeps your startup strategy flexible. You can adapt without rebuilding a giant product.

An MVP is not the finish line. It is the smartest first move when clarity is still forming.

When Full Product Development is the Better Choice

Now let’s flip it.

Sometimes an MVP is not enough. Sometimes it creates a weak first impression, lowers trust, or simply cannot support the product promise.

Choose full product development when:

The Market Need Is Already Validated

You already know people want the product. Maybe you have strong customer interviews, waitlist demand, pilot users, or a successful offline service model.

Users Expect a Complete Experience

Some categories do not tolerate missing features well. If users need reliability, depth, and trust from day one, a thin launch can hurt adoption.

Compliance or Security Is Critical

In regulated products, a lightweight version may not be safe or viable. You may need stronger infrastructure before launch.

You Have Funding and a Clear Roadmap

If you have the capital, product clarity, and team strength to build properly, full product development can accelerate long-term growth.

Your Competitive Space Is Mature

In mature markets, users compare every product quickly. A shallow launch may not survive long enough to improve.

This is also where platform expectations matter. If your audience is premium, product quality matters fast, and many founders in this stage start planning with an ios mobile application development company to deliver a more refined early experience.

The 7 Questions Founders Should Ask Before Deciding

This is where the decision gets practical.

Ask these seven questions before choosing MVP app development or full product development.

1. What Is Still Unproven?

List the biggest unknowns. Is it demand, pricing, user behavior, retention, or feature value? If major unknowns still exist, MVP app development usually wins.

2. How Much Runway Do You Have?

Do not plan like you have endless time. If the runway is short, your startup strategy should favor learning and speed.

3. What Happens If the Product Is Missing Key Features?

Will users still get value, or will they bounce? That answer tells you how thin your first version can be.

4. How Expensive Will Future Changes Be?

If the product is likely to pivot, building the full version now could waste serious money.

5. What Do Users Need to Trust You?

Trust changes by category. A social app can launch lighter. A finance app really cannot.

6. Are You Selling a Vision or Solving an Immediate Pain?

If users have urgent pain, MVP app development can work beautifully. If you are selling a complete operating system for a workflow, depth may matter more.

7. What Is the Real Business Goal of Version One?

Be honest here. Are you trying to validate, attract investors, close pilots, or scale revenue? Your first build should match that goal, not just your excitement.

Common Mistakes Startups Make

A lot of founders make this harder than it needs to be.

Here are the most common mistakes:

Calling a feature-heavy product an MVP
Launching too thin and learning nothing useful
Building based on opinions instead of user evidence
Ignoring technical foundations completely
Letting investor pressure shape the wrong scope
Confusing design polish with product readiness
Skipping analytics in MVP app development
Choosing full product development without a clear growth plan

That last one hurts a lot. Because once time and money disappear, strategy gets reactive fast.

A Smarter Way to Decide

Instead of seeing this as MVP versus full product, think in stages.

A sharper startup strategy often looks like this:

Define the core problem
Build the smallest valuable product
Launch to a focused user segment
Measure behavior, not just feedback
Improve based on evidence
Expand into a stronger product release

This staged model keeps MVP app development connected to long-term growth. It avoids random building. It also keeps founders from rushing into a full launch before the product earns it.

That is the real win. Not just shipping faster, but learning smarter.

Final Verdict for Startups

So, how do startups decide between MVP app development and full product development?

They decide by looking at uncertainty, money, urgency, user expectations, and product risk.

If you need proof, speed, and flexibility, MVP app development is usually the right move. If you already have validation, stronger funding, and a category that demands completeness, full product development can be the better bet.

The smartest founders do not build to impress themselves. They build to reduce risk and increase traction. That is what strong startup strategy looks like in practice.

And if you are still unsure, work with a team that can challenge scope, not just code whatever is requested. A skilled mobile app development company in new york can help you map the right path based on business goals, not just feature lists.

Conclusion

You do not need the biggest product first. You need the right product first.

That is why MVP app development remains one of the smartest ways to launch without wasting time, money, or momentum. Still, it is not always enough. Some ideas need more depth from day one. The key is knowing what your market demands right now, not what looks impressive on paper.

Build for evidence. Build for traction. Build for the stage you are actually in.

That is how startups make better product bets, and survive long enough to scale.If you got startup, its better decision to reach for solution to an Android application development company.