标签：#dev

A headless content API has two kinds of callers, and it's tempting to secure them the same way. That's the mistake. There's a human logging into an admin UI to edit content, and there's a machine — a website, a build step — pulling published content through a delivery endpoint. They authenticate with different credentials, and those credentials have opposite properties. Treat them identically and you either make the machine path painfully slow or the human path dangerously weak. I built a small headless content API ( Depot ) partly to get this boundary right. Here's the reasoning. The two credentials A session proves "this human is logged in." Short-lived, rides in an httpOnly cookie, checked on management routes. A delivery token proves "this machine may read this account's published content." Long-lived, sent as a Bearer header, checked on every public read. Two auth surfaces, kept explicit: /** * - requireUser() — admin session (httpOnly JWT cookie) for the management API. * - requireToken() — a `depot_…` bearer token for the public delivery API. */ Why they get different hashing Here's the part people get wrong. Both credentials get stored as hashes — never plaintext — but not the same kind of hash , and the reason is entropy. Passwords are low-entropy. Humans pick summer2024 . An attacker who steals your DB will brute-force guesses against the stored hashes, so you want hashing to be deliberately slow — that's exactly what bcrypt's cost factor buys you: import bcrypt from " bcryptjs " ; const ROUNDS = 10 ; // deliberately slow — the point is to resist brute force export function hashPassword ( plain : string ): Promise < string > { return bcrypt . hash ( plain , ROUNDS ); } export function verifyPassword ( plain : string , hash : string ): Promise < boolean > { return bcrypt . compare ( plain , hash ); } Tokens are high-entropy. I generate them — 32 random bytes — so there's nothing to guess. A stolen hash can't be reversed by brute force because the keyspace i

~7 min read · Tutorial I look at a lot of MUI admin templates. material-kit-react from the minimals people is one I keep going back to. Clean, typed, and the folder structure makes sense. Repo: minimal-ui-kit/material-kit-react . But every time I just want to see it, or change one color to check something, it's the same ritual. git clone , npm install , wait, npm run dev , wait more, tab over to localhost. Few minutes gone, a few hundred MB of node_modules on disk. All that to look at a dashboard. So this time I skipped the build. Opened the folder in CrossUI Studio , rendered src/main.tsx directly. No install, no Vite, no localhost. Below is what I did, including the bits that made me stop and think. One honest note first. This does not replace your dev server. You still need the real thing for tests, prod builds, actual feature work. It's good for the look-and-tweak loop. Evaluating a template, recoloring something, showing a client. The stuff where booting the whole toolchain costs more than the task itself. Quick note : local folder support requires a Pro account. To test it out, use the code in the original blog for a free upgrade. No credit card required, available while it lasts. Your browser does not support video. Watch on YouTube . 1. Clone to local disk (don't open it straight from GitHub) Studio can mount a GitHub repo directly. For a small repo that's the nicest path. For this one I cloned to disk first: git clone https://github.com/minimal-ui-kit/material-kit-react The reason is boring. src/ alone is ~130 files, ~245 in the whole project, spread over sections/ , components/ , layouts/ , theme/ , routes/ . Opening a project means the tool has to pull the files it touches. Over the GitHub API, on demand, that's a lot of small requests. It works, just not snappy, and you can hit the rate limit if you poke around. A local folder is only the filesystem, so it's instant. For a template this size, local wins. No npm install here. I only cloned the source. The

I'm a solo dev, and for the past few months I've been building Pixanima — a pixel-art and animation editor that runs entirely in the browser, with an optional AI assistant baked in. It just launched, and I wanted to share the parts that were technically interesting: making a general image model output clean pixel art, an atomic credit system, AI inbetweening for animation, and why the whole business model falls out of one architectural fact. What it is Draw pixel art with layers, groups and effects, animate it on a frame timeline with onion-skin, and export to GIF / sprite sheets / PNG — all client-side, no install. On top of that, an AI assistant turns a text prompt into sprites, seamless tiles and palettes, re-poses characters, and generates in-between animation frames. The frontend is Vue 3 driving an HTML canvas; the backend is Laravel 12 (PHP 8.4) . Here's what I learned. Everything runs in the browser — and that decided the business model The entire editor is client-side. Projects live in IndexedDB ; nothing is uploaded. That's great for privacy and speed, but it has a consequence a lot of people miss: you cannot meaningfully gate a client-side feature. If drawing, layers and export all run in the user's browser, any "pro" paywall around them is both unenforceable and, honestly, hostile to a price-sensitive hobbyist community. So I flipped it: the editor is 100% free, forever . The only paid thing is AI — because AI is the only part with a real marginal cost, and it requires a backend (which conveniently also protects the code that costs money to run). More on that below. Making a general model output clean pixel art The naive approach — prompt a diffusion model with "pixel art, 16 colors" — gives you pixel-art-ish mush: anti-aliased edges, hundreds of colors, no real grid. Useless as an actual sprite. The fix is a post-processing pipeline. The model just produces raw input; the "pixel art" is made deterministically afterward with PHP's GD: 1. Generate a norma

Last month I set out to build a new product, and after a full week I had shipped exactly zero features. Not because I was slow. Not because the work was hard. Because before anyone could write a single line of business logic, my team had to re-decide a dozen things our company should have settled years ago . I've been a full-stack developer for almost five years — long enough to have worn most of the hats: WordPress developer, QA, frontend, backend, solution architect, founding engineer. I've built more than twenty web applications and a handful of mobile ones. Some of them I'm genuinely proud of: systems that poll PLCs every five seconds to watch over industrial equipment, a cybersecurity dashboard that mapped attacks across the world in real time using tree-based graphs, an OTT platform that streamed live events — including FIFA — to millions of concurrent viewers. Today I work on enterprise supply-chain finance software. So when I tell you the hardest part of that new product had nothing to do with code, I know how it sounds. Let me explain. The week that disappeared The experiment was ambitious on purpose. I wanted to build the new application — eventually a microfrontend inside a larger enterprise platform — but I didn't want to write most of it myself. I wanted Claude Code to implement while I acted as the architect: review, test, challenge, refine, repeat. That part worked. The AI wasn't the bottleneck. The bottleneck was everything that came before the first feature. Should we use React? Vite? Keep Create React App because the parent app still runs it — or migrate both? How does the parent consume the child, and does local development still work? Does authentication still work? Does routing? Do we adopt TypeScript when the existing app doesn't, knowing that splits one product into two standards? The app also had to feel native to the existing product — same spacing, typography, colors, interactions — except the company had a component library, not a design s

You have a row in Postgres. You want that same row in MongoDB — not tonight in a batch job, but the instant it changes. And next month you'll want it in Redis too, and maybe POSTed to some webhook. Today that's a Kafka cluster, a Debezium connector, a sink connector, a schema registry, and a weekend. For a job that is, at its heart, one sentence: a source → one or more destinations → kept in sync. Syncle is an open-source tool that does exactly that sentence, and nothing you didn't ask for. Connect your databases, draw a bridge from a source to one or more destinations, and the moment a row changes in the source it's written to every destination you linked. Any engine to any engine — PostgreSQL · MySQL/MariaDB · SQLite · MongoDB · Redis — plus HTTP endpoints when you need them. This post is a tour of what it does and, for the curious, how it's built. The core idea: a bridge A bridge reads rows from a source and writes each one to its destinations . A destination is either: another database — the headline feature. Postgres → MongoDB, MySQL → SQLite, MongoDB → Redis. One bridge can fan out to several databases at once, and bridges can chain (A → B → C). an HTTP endpoint — POST/PUT/PATCH each row to a URL with a payload you design, for feeding a service instead of a database. The interesting part isn't that it copies data — plenty of things copy data. It's the guarantees around how . No duplicates, ever Every database write is an idempotent upsert , keyed by columns you choose. So replays, retries, and at-least-once redeliveries never double-write. Under the hood each engine does it with its own native atomic operation: Engine Upsert PostgreSQL / SQLite INSERT ... ON CONFLICT MySQL INSERT ... ON DUPLICATE KEY UPDATE MongoDB updateOne(filter, ..., { upsert: true }) Inserts, updates, and deletes all propagate — a delete routes to a keyed delete on each target. Missing table? It builds it If the destination table or collection doesn't exist, Syncle creates it from the sou

In my research on the topic of Azure and Cloud, Gemini mentioned the Cloud Resume Challenge , which I looked into and picked up a copy of the book for. This post will outline my steps as I work through it 😁. Week 00 :: AZ-900 The goal here is to work through necessary course-work so I can quiz for and obtain the Microsoft AZ-900 certification. I enrolled myself in the Microsoft Cloud Support Associate Professional Certificate offered by Coursera and, as I get closer to completing it, will keep this post up to date on my status... In lieu of just studying, I am jumping ahead to work on the project, which will be outlined below. Week 01 :: Cloud Resume (Front-End) 07/23/2026 Yesterday (and today) I worked on creating / securing my Azure account, setting up my environment for Azure development and building the front-end. The development environment is VS Code with the Azure Extensions, Azure CLI and Azure Functions Core Tools. The website is, in its current state, an exact replica of my PDF resume... made with Vue.js. I will be adding a separate page based solely around this project as I included Vue Router and already worked through layout components, a 404 page, etc.

1. Introduction: What is TanStack Query? TanStack Query (formerly React Query) is a framework-agnostic state management library designed specifically to manage Server State —handling data fetching, caching, background updating, and cache invalidation. 2. Server State vs. Client State & The Memory Reality Client State: Owned and controlled entirely by the browser (e.g., isModalOpen , selected UI theme). Server State: Owned by the remote backend database (e.g., user profiles, posts, cart items). The browser only holds a read-only temporary snapshot . Where is data physically stored? Physical Location: By default, cached data lives strictly in the browser tab's JavaScript RAM (In-Memory) . Backend ("The Server"): Refers to your remote API/database (regardless of whether it runs on Kubernetes, Docker containers, serverless functions, or bare metal). Optional Persistence: You can opt to sync this RAM cache to localStorage , sessionStorage , or IndexedDB using TanStack Query Persisters. import React , { useState } from ' react ' ; import { QueryClient , QueryClientProvider , useQuery , useMutation , useQueryClient , } from ' @tanstack/react-query ' ; // 1. Initialize QueryClient (manages the RAM cache) const queryClient = new QueryClient ({ defaultOptions : { queries : { staleTime : 10000 , // Data stays fresh in RAM for 10 seconds }, }, }); // Mock API functions async function fetchPost ( postId ) { const res = await fetch ( `[https://jsonplaceholder.typicode.com/posts/$](https://jsonplaceholder.typicode.com/posts/$){postId}` ); if ( ! res . ok ) throw new Error ( ' Network error ' ); return res . json (); } async function createPost ( newPost ) { const res = await fetch ( ' [https://jsonplaceholder.typicode.com/posts](https://jsonplaceholder.typicode.com/posts) ' , { method : ' POST ' , headers : { ' Content-Type ' : ' application/json ' }, body : JSON . stringify ( newPost ), }); return res . json (); } // 2. Query Component (Fetching & Reading Data) function PostViewe

Un análisis técnico basado en BorgBackup para entornos Debian/Ubuntu Autor: Arcadio Ortega Reinoso Versión del sistema: 2.1.0 Fecha: Julio 2026 Plataforma objetivo: Debian 11+ / Ubuntu 22.04+ (x86_64) Puedes encontrarlo en: BorgShield Fortalezas Diferenciales Valor Diferencial Claro: La inclusión de 23 tipos de metadatos (repositorios git, dconf, claves GPG, snaps, flatpaks, etc.) resuelve el problema de tener los archivos pero no saber cómo reconstruir el entorno. No es solo "tus datos están a salvo", es "sabemos exactamente qué tenías y cómo volver a dejarlo igual". Restauración Semántica: test-restore va más allá de borg check . Mientras que otras herramientas solo verifican checksums (integridad técnica), nosotros verificamos si los datos son realmente legibles y útiles (integridad semántica): ¿el SQL de las BBDD se puede leer? ¿los paquetes están en formato válido? ¿las rutas esenciales existen? ¿los gzips no están corruptos? Asistente Guiado: restore-full y restore-dry-run forman un sistema de dos velocidades: simular antes de ejecutar, y guiar paso a paso durante la ejecución real. Esto reduce significativamente el "pánico" durante un desastre real, guiando incluso en la reinstalación de paquetes y fuentes APT. Resumen Este documento presenta el diseño, la implementación y la evaluación de backup.sh , un sistema de backup para Linux orientado a disco externo local. El sistema se basa en BorgBackup como motor de almacenamiento deduplicado, cifrado y comprimido. Se analizan las alternativas existentes (rsync, rsnapshot, restic), se justifican las decisiones de diseño y se presentan proyecciones de rendimiento basadas en métricas obtenidas de un sistema real con ~360 GB de datos, ~3200 paquetes instalados y ~460 paquetes instalados manualmente. Los resultados muestran que BorgBackup reduce el espacio de almacenamiento del backup completo a ~160 GB (55% de compresión con deduplicación), los backups incrementales se completan en 3-8 minutos, y el sistema permite r

Every developer has had this moment. You need a date picker, so you start searching. You find one that's perfect... until you realize it requires React. Or Vue. Or jQuery. Or an entire date library just to select a few dates. After trying several solutions, I kept asking myself: Why is such a common UI component often more complicated than it needs to be? So I decided to build my own. Meet RollDate . The Goal I didn't want to create "another date picker." I wanted to build something that I would actually enjoy using in my own projects. The goals were simple: Infinite scroll Zero framework dependencies Simple API Modern UI Mobile-friendly scrolling TypeScript support Easy customization Good documentation Why Scrolling? Most date pickers rely on clicking tiny arrows or dropdowns. On mobile devices, this often feels awkward. I wanted something closer to native mobile pickers, where changing the month or year is just a smooth scroll. That became one of RollDate's core ideas. More Than Just Picking a Date While building the component, I realized different projects need different selection modes. So instead of maintaining separate components, RollDate supports: Single date selection Date range selection Multiple date selection The API stays the same regardless of the mode. new RollDate ( " #date " , { selectType : " range " }); Optional Time Picker Many date pickers force you to install another plugin if you need time selection. I wanted it built in. RollDate supports: 24-hour mode 12-hour AM/PM mode Configurable minute steps Enable it with one option. new RollDate ( " #date " , { enableTime : true }); Dependency-Free One of the main design goals was keeping the library independent. No React. No Vue. No jQuery. No Moment.js. No Day.js. Just plain JavaScript. That means it works almost anywhere: Vanilla JavaScript React Vue Angular Svelte Astro ...or any framework capable of using DOM components. A Better Developer Experience I care a lot about developer experience. That's

If you have ever tried building a website change detection system or visual testing tool, you’ve likely stumbled into the "False Positive Trap." You configure a cron job to monitor a target URL, take snapshots every 15 minutes, and compare them. But within hours, your inbox is flooded with alerts for: Tailwind CSS dynamic hash class mutations (e.g. class="bg-blue-500_a3f9" turning into class="bg-blue-500_b81c" after a deployment) Lazy-loaded images rendering at offset offsets Anti-bot verification scripts altering invisible DOM nodes Hydration mismatches in React/Vue single-page applications At PageWatch.tech , solving these exact edge cases was the primary focus of our engineering roadmap. In this article, I’ll share the 3 core algorithmic fixes we implemented to achieve reliable, noise-free website change monitoring. 🛑 Problem 1: Structural Hash Instability in Modern Frameworks Modern frontend frameworks like Next.js, Nuxt, and Remix insert dynamic build IDs, hydration keys, and inline CSS chunk hashes into the HTML structure. For example, a innocent paragraph tag might look like this today: <p class= "text-gray-700 css-1a2b3c" data-reactroot= "" > Product Price: $99 </p> And like this tomorrow after a routine production deployment: <p class= "text-gray-700 css-9x8y7z" data-reactroot= "" > Product Price: $99 </p> A standard raw string comparison flags this as a critical change even though zero user-facing content changed . The Solution: Attribute Normalization & CSS Class Sanitization Before computing DOM structural hashes, we run a normalize pass that strips generated hashes and framework-specific attributes: import * as htmlparser2 from " htmlparser2 " ; /** * Normalizes dynamic framework attributes and hashed CSS classes * before running DOM diff calculations. */ export function normalizeDOMNode ( node : any ): void { if ( node . attribs ) { // 1. Remove hydration and framework metadata const volatileAttrs = [ " data-reactroot " , " data-reactid " , " data-hydr

When engineers talk about visual regression or website change monitoring, pixel-level diffing algorithms (like pixelmatch or Euclidean RGB distance) are usually the default solution. However, in real-world web environments, pixel-by-pixel comparisons fundamentally fail under normal user interactions and dynamic rendering conditions: Elastic Layout Shifts: A single 20px dynamic banner inserted at the top of a page pushes every subsequent DOM element down, causing 100% of the downstream pixels to fail a pixelmatch test, even if the content itself hasn't changed. Sub-Pixel Anti-Aliasing Jitter: Operating systems (macOS vs. Linux vs. Windows) render font glyphs with subtle sub-pixel anti-aliasing variations, creating thousands of false-positive pixel deltas. Semantic vs. Cosmetic Changes: Changing a single word in a paragraph should trigger a localized alert, but a minor color gradient shift in a hero image shouldn't trigger an emergency notification. At PageWatch.tech , we solved this by combining classical Structural Similarity (SSIM) , ORB Feature Alignment , and Siamese Neural Networks (SNN) for latent-space semantic comparison. In this article, I will dive into the mathematics, neural network architectures, and TypeScript implementation of our computer vision diff pipeline. 🧮 1. Beyond Pixel Comparison: Structural Similarity Index (SSIM) Unlike raw Mean Squared Error (MSE), SSIM measures visual change based on human perception across three dimensions: Luminance , Contrast , and Structure . Mathematically, the SSIM between two image windows $x$ and $y$ is defined as: $$\text{SSIM}(x, y) = \frac{(2\mu_x\mu_y + C_1)(2\sigma_{xy} + C_2)}{(\mu_x^2 + \mu_y^2 + C_1)(\sigma_x^2 + \sigma_y^2 + C_2)}$$ Where: $\mu_x, \mu_y$ are the local pixel mean intensities. $\sigma_x^2, \sigma_y^2$ are the local variances. $\sigma_{xy}$ is the covariance between $x$ and $y$. $C_1, C_2$ are stabilization constants. TypeScript Implementation of SSIM Window Sliding Below is a snippet of how

I have been quiet lately I know - but don't worry I haven't forgotten you all and how much you like...

Letting a stranger contact a car owner without giving them the number There is a small, very common problem in Indian cities that turns out to be a surprisingly good systems design exercise. A car is parked badly. It is blocking a gate, a driveway, another car. Someone needs the owner to move it, right now. The traditional fix is a phone number written on a sticker on the windscreen. That works. It also means a stranger — any stranger, forever — has the owner's personal number. Why the sticker is worse than it looks Once a number is visible on a windscreen, a few things follow: It gets scraped. Numbers on vehicles end up in marketing lists. It cannot be revoked. Change your number and every sticker you own is now wrong. It has no context. A 2am call could be a genuine emergency or someone who saw the number three months ago. It is a safety issue for some owners in a way it is not for others. A number attached to a vehicle, at a known parking spot, at predictable times, is more information than most people realise they are publishing. So the requirement is oddly specific: a stranger must be able to reach the owner, immediately, without ever learning how to reach them again. That constraint is what makes this interesting. The naive version, and why it fails First instinct: put a QR code on the vehicle that opens a page with a "call owner" button, and put the number behind the button. This solves nothing. The number is still in the page source. Anyone who wants it can get it, and now you have added a scan step for the honest majority while stopping none of the dishonest minority. Second instinct: put a contact form behind the QR. The stranger types a message, the owner gets a notification. Better on privacy, useless in practice. The person needs the car moved in the next ninety seconds. They are not filling in a form and waiting for an email. If the fast path is not there, they go back to writing an angry note. The real requirement is synchronous contact with asynchron

Watermarking a PDF — adding semi-transparent text over pages — sounds like something only desktop software handles. But with pdf-lib and a bit of canvas math, you can build a fully browser-based watermark tool. This post walks through the implementation details, including text rendering, rotation, and multi-page support. Why client-side? Traditional watermark tools upload your file, process it on a server, and send the result back. For documents that might be confidential or contain sensitive information, this introduces an unnecessary privacy risk. A browser-based approach: Processes everything locally Keeps files on the user's device Works offline after loading Avoids server-side bandwidth costs The stack Vue 3 + Composition API pdf-lib for PDF manipulation and watermarks PDF.js ( pdfjs-dist ) for preview rendering Vite for bundling Adding a text watermark pdf-lib provides a built-in PDFDocument.embedFont() method for custom fonts and page.drawText() for placing text. Here's how to add a rotated, semi-transparent watermark across all pages: < script setup lang= "ts" > import { ref } from ' vue ' import { PDFDocument , rgb , StandardFonts } from ' pdf-lib ' const file = ref < File | null > ( null ) const watermarkText = ref ( ' DRAFT ' ) const opacity = ref ( 0.3 ) const fontSize = ref ( 72 ) const rotationDeg = ref ( - 45 ) const applying = ref ( false ) async function handleFileUpload ( selected : File ) { file . value = selected } async function applyWatermark () { if ( ! file . value ) return applying . value = true try { const arrayBuffer = await file . value . arrayBuffer () const pdfDoc = await PDFDocument . load ( arrayBuffer ) // Embed the Helvetica font — required for correct rendering const helveticaFont = await pdfDoc . embedFont ( StandardFonts . HelveticaBold ) const pages = pdfDoc . getPages () pages . forEach (( page ) => { const { width , height } = page . getSize () page . drawText ( watermarkText . value , { x : ( width - helveticaFont . widthOfT

Hi, my name is Dan, I'm a frontend engineer and open-source maintainer. I've spent the last couple of years building Nano Kit — a lightweight, modular state management ecosystem for modern web apps: signals-based stores , a router , data fetching , i18n , and SSR support , all built on the same tiny reactive core. It recently hit 1.0 , and in this post I want to give you four honest reasons to try it. 1. It's fast At the heart of Nano Kit is a push-pull reactivity system based on the algorithm from alien-signals — one of the fastest signal implementations in the JavaScript ecosystem. I didn't use alien-signals directly, though. Nano Kit needed things it doesn't provide, so I built a dedicated fork called Agera : Signal lifecycles — you can listen to signal activation and deactivation, which powers Nano Kit's mountable stores (run setup logic on first listener, clean up on last). Real tree-shaking — Agera is designed so that only the code you use ends up in your bundle; alien-signals is not well tree-shakable. The result keeps almost all of alien-signals' raw speed. Here is how @nano_kit/store compares to other popular state management libraries in a reactivity benchmark : Library Latency avg (ns) Throughput avg (ops/s) alien-signals 294.00 ± 2.24% 3,559,763 @nano_kit/store 303.55 ± 0.75% 3,365,816 svelte/store 428.58 ± 0.61% 2,479,118 rxjs 454.74 ± 0.07% 2,250,397 nanostores 1,373.2 ± 5.96% 952,399 mobx 3,474.7 ± 1.86% 306,094 valtio 5,041.3 ± 11.46% 254,109 jotai 9,454.6 ± 16.45% 157,853 effector 24,885 ± 11.78% 62,744 @reatom/core 59,430 ± 15.61% 22,741 Benchmark was run on AMD Ryzen 5 PRO 3400G with Node.js v24.14.1 That's ~3.5× faster than nanostores and an order of magnitude faster than most atomic state managers — while shipping lifecycles and mountable stores on top. 2. It's small Nano Kit exists largely because of Nano Stores . I love its philosophy: atomic stores, mountable resources, logic moved out of components, and an obsessive focus on bundle size. Nan

In 1996, Bandai sold 82 million Tamagotchis. Kids carried egg-shaped plastic keychains everywhere, frantically pressing three buttons to feed, clean, and play with a pixelated blob that would literally die if you ignored it during math class. It was the first time millions of people felt genuine emotional attachment to a piece of software. 30 years later, I rebuilt that entire experience — in the browser, with TypeScript, zero dependencies, completely open source. No app store. No download. No install. Just open a tab and adopt your pet. And in the process, I learned more about state machines, game loops, and emotional design than any computer science course ever taught me. Why Build a Virtual Pet in 2025? Three reasons: 1. Nostalgia Is a Distribution Hack People share things that trigger childhood memories. It's not rational — it's emotional. A browser-based Tamagotchi hits a nerve that no todo app or dashboard ever will. When I shared an early prototype, the response wasn't "cool tech stack." It was: "OH MY GOD I used to cry when mine died in second grade" That emotional reaction is worth more than any Product Hunt launch. 2. Game State Machines Are Criminally Underrated Every tutorial teaches state machines with traffic lights or toggle buttons. Boring. Useless. Forgettable. A virtual pet has dozens of interconnected states , real-time decay, evolution paths, conditional transitions, and edge cases that force you to actually think about state architecture. After building this, implementing complex UI flows in production apps felt trivial. 3. Not Everything Needs to Be a SaaS The indie dev world is obsessed with "revenue-generating side projects." Sometimes you should build something purely because it makes people smile. The best projects are the ones you'd use even if nobody else existed. Meet Your New Pet When you open Tamagochi, you get an egg. It hatches. A tiny pixelated creature appears. It has needs. Meet them, and it thrives. Ignore them, and... well, game

One of the biggest mistakes beginners make when learning Terraform is treating their local machine as the deployment server. A typical workflow looks like this: terraform init terraform plan terraform apply While this approach is perfectly fine for learning, it quickly becomes problematic when working on real-world projects with multiple engineers. Consider these questions: Who deployed the infrastructure? Was the infrastructure reviewed before deployment? Can someone else reproduce the deployment? What happens if the engineer's laptop is lost or misconfigured? How do we know exactly what changed? These are some of the reasons Infrastructure as Code (IaC) is almost always integrated with Continuous Integration and Continuous Deployment (CI/CD) pipelines in professional environments. In this article, we'll build a simple Terraform CI/CD pipeline using GitHub Actions. Instead of focusing only on the YAML syntax, we'll first understand why each stage exists and how they work together to produce safe, repeatable infrastructure deployments. What is Terraform CI/CD? Terraform CI/CD is the process of automating the validation, planning, and deployment of infrastructure whenever changes are made to Terraform code. Instead of running Terraform commands manually from a developer's laptop, a CI/CD platform executes those commands automatically in a controlled environment. The workflow typically looks like this: Developer │ ▼ Git Push │ ▼ GitHub Repository │ ▼ GitHub Actions │ ▼ Terraform Init │ ▼ Terraform Validate │ ▼ Terraform Plan │ ▼ Manual Approval │ ▼ Terraform Apply │ ▼ AWS Infrastructure This approach provides consistency, visibility, and security while reducing the chances of human error. Why Not Run Terraform Manually? Running Terraform from your laptop works well for personal projects, but it introduces several risks in a team environment. Manual Deployment CI/CD Deployment Requires someone to remember every command Runs automatically Easy to skip validation Validat

In 2023, Bitly's free plan gave you 100 links per month with full analytics. In 2025, they slashed it to 5 links per month . Five. And they started showing full-screen interstitial ads before redirecting — even on links you created years ago. In 2026, their cheapest paid plan is $10/month — just to shorten links without ads. I was paying $120/year to turn long URLs into short ones. A problem that takes 3 lines of code to solve. So I solved it myself. For free. Forever. Introducing ZipLink ZipLink is a fast, self-hostable URL shortener built with Next.js and Firebase. Deploy it once, use it forever. No monthly fees. No link limits. No ads. No "upgrade to unlock analytics." Your links. Your data. Your domain. Your rules. https://yourdomain.com/abc123 → https://some-really-long-url.com/path/to/thing?utm=whatever That's it. That's the product. Except you own it completely. The State of URL Shorteners in 2026 (It's Embarrassing) Let me show you what the "industry leaders" are charging for what is essentially a database lookup: The Comparison Table Feature Bitly Rebrandly Short.io Dub.co TinyURL Pro ZipLink Monthly cost $10-$300/mo $13-$349/mo $19-$149/mo $24-$299/mo $9.99/mo $0 Annual cost $96-$2,388/yr $156-$4,188/yr $228-$1,788/yr $288-$3,588/yr $119.88/yr $0 Free tier links 5/month 10/month 1,000 total 25/month Unlimited (no analytics) Unlimited Custom domain Paid only Free (1 domain) Required Paid only Paid only Yes (yours) Click analytics Paid only Paid only Free (basic) Paid only Paid only Full, free Link expiration Paid only Paid only Yes Yes No Yes Password protection Enterprise only Paid only Paid Paid No Yes API access Paid only Paid only Yes Yes Paid Full, free QR codes 2 free, then paid Paid Yes Paid Paid Unlimited Self-hostable No No No Yes (complex) No Yes (simple) Data ownership Their servers Their servers Their servers Their servers Their servers Your Firebase Ads/interstitials Yes (free tier) No No No Yes (free tier) Never Links disappear if you stop pay

When a new platform team set out on implementing their roadmap through forced workflows with poor documentation, developer experience declined. Success came from simplifying governance, prioritizing what matters, and rolling out compliance incrementally through prevention, detection, and communication. Empathy, focus, and shared purpose drove successful adoption. By Ben Linders

QCon AI New York 2026 (Dec 15-16) has opened registration at The Westin Jersey City Newport. Six tracks on production AI, chaired by Eder Ignatowicz with Faye Zhang and Wes Reisz. First sessions announced in August, full program by November. By Artenisa Chatziou