标签：#webdev

I run a fact-check site for an unreleased game. That genre is a swamp: half the pages you find are somebody's guess reprinted six times until it reads like news. I wanted the opposite, so I made provenance a schema requirement instead of an editorial habit. If a claim has no source, the build fails. Here is how that works in Astro, and what it cost me. Sources live in the content schema, not in the prose Every entity on the site is a YAML file validated by a Zod schema. The interesting part is that sources is not optional: const sourceSchema = z . object ({ url : z . string (). url (), date : z . string (), // when the source said it, not when I read it }); const base = { status : z . enum ([ ' confirmed ' , ' trailer-spotted ' , ' rumor ' , ' debunked ' ]), updated : z . string (), sources : z . array ( sourceSchema ). min ( 1 ), }; export const entitySchema = z . object ({ name : z . string (), description : z . string (), sections : z . array ( z . object ({ heading : z . string (), text : z . string (), status : z . enum ([ ' confirmed ' , ' trailer-spotted ' , ' rumor ' , ' debunked ' ]), sources : z . array ( sourceSchema ). min ( 1 ), // per section, not per page })). optional (), ... base , }); Two decisions in there matter more than they look. Sources are per section, not per page. A page usually mixes a confirmed fact with a plausible reading of a trailer. One source list at the bottom lets those blur together. Per-section sources force me to say which sentence rests on what. Status is a required enum, not a boolean. rumor and debunked are first-class. The page renders a badge from the same field, so the reader sees the confidence level next to the claim instead of a disclaimer nobody scrolls to. The cost is real: adding a paragraph means finding a citable source for it. Several times I have deleted a nice sentence because I could not back it. That is the feature working. Seven locales, and the empty ones stay invisible The site ships in seven languages, a

Modern web development has become incredibly powerful. But also increasingly complicated. Many projects begin by installing hundreds of megabytes of dependencies before writing a single page. Frameworks, bundlers, routers, templating systems, CSS tooling, and runtime libraries all solve important problems, but they also introduce additional complexity. I wanted something different. I wanted to build websites that start with plain HTML, while still providing the features developers expect today: Reusable components Markdown support TypeScript CSS and JavaScript bundling Internationalization (i18n) Content collections RSS/Atom feeds Sitemap generation Fast development builds That idea became Rino.js. What is Rino.js? Rino.js is an HTML-first website compiler for building static websites, documentation, blogs, portfolios, company websites, and other content driven projects. Instead of introducing a custom templating language or requiring a frontend framework, Rino.js treats HTML as the primary language. Pages remain valid HTML while additional functionality is added through a small set of build-time conventions. The goal is simple: Write HTML. Generate optimized static websites. Why HTML First? HTML has existed for decades, yet modern web development often treats it as something generated by another language. Rino.js takes the opposite approach. Instead of writing components in JSX or another template language, components are simply HTML files. <component rino-import= "header" ></component> That's all it takes. The compiler replaces the component during the build, producing plain static HTML with no runtime dependency. Starting Rino.js Rino.js has a command that is designed to provide default project. npm create rino@latest Project Shape A Rino.js project usually looks like this: my-site/ rino-config.js dev.js generate.js feed.js sitemap.js backoffice.js pages/ index.html about.html components/ header.html footer.html public/ images/ photo.webp scripts/ export/ app.js

Every recorded mobile test I have ever inherited died the same way: someone moved a button. The recording said "tap at (340, 712)". The redesign moved that button up by one row, and the test kept tapping — now on empty space, or whatever happened to land there instead. It didn't fail right away. Three sprints later, it started failing in confusing ways, and by then nobody trusted the suite anymore. The fix isn't a better recorder. It's recording a different thing: not where you tapped, but what you tapped. That needs an element tree, and for a while we didn't have one. tapflow is an open-source, self-hosted tool that streams iOS simulators and Android emulators into a browser, so a whole team can test builds without installing anything. Until now, everything it moved was pixels in one direction and taps in the other. This post is about getting an element tree out of a simulator with no window, on both platforms. What we do with that tree — replaying flows that survive a redesign — is the next post in this series. The automation axis this feeds — the flow runner and the MCP server — is experimental . The manual browser QA path is the mature one. The constraint: no WebDriverAgent, and no simulator window tapflow already injects touches into the iOS simulator without WebDriverAgent — it loads CoreSimulator.framework and pushes HID events through SimDeviceLegacyHIDClient (that story is ep.1 ). Streaming reads the framebuffer IOSurface directly. Neither path needs Simulator.app on screen, and that's deliberate: an agent Mac in a closet running four simulators shouldn't be babysitting four windows. So whatever we used for the tree had to follow the same rule. No WDA to install and keep in sync with Xcode. No simulator window on screen. Our first attempt ran into exactly that limitation. macOS exposes an accessibility API ( AXUIElement ), and Simulator.app publishes its content through it. We wrote a helper around it, and it worked perfectly on a developer's laptop. On the

Generative coding agents are powerful, but left to their own devices, they default to visual clutter: predictable gradients, uncalibrated spacing, and bloated, outdated component structures. Impeccable is a design skill package, created by Paul Bakaus, that runs directly inside Claude Code, Gemini CLI, and Codex CLI (as well as Cursor and GitHub Copilot) to enforce strict aesthetic guardrails, with the same rule set recompiled for each harness. By applying deliberate skill design, you can steer agents away from generic patterns and push them toward precise, high-craft web experiences. What Is Skill Design, and Why Does It Matter for AI Agents? Skill design is the practice of building deterministic rails for non-deterministic AI models. Instead of endlessly asking an agent to "make it look better" or "improve performance," you inject a compiled DESIGN.md and functional directive that the agent must follow on every iteration. Impeccable builds on Anthropic's frontend-design skill and adds 23 commands that give you a shared design vocabulary with the model, plus 58 deterministic anti-pattern detection rules (default Inter font, purple-to-blue gradients, cards nested in cards, gray text on colored backgrounds, rounded icon tiles above every heading, and more). It turns the AI from a junior developer guessing at your aesthetic into a strict implementer of the visual rules you actually define. Implementing Impeccable's Constraints for Modern Web Apps Precision is everything when you wire this workflow in. Impeccable respects your existing design system rather than overwriting it: when it runs, it scans your codebase (tokens, components, Tailwind config) and loads your brand rules from your own DESIGN.md , instead of imposing a generic aesthetic. So if your identity is built on a minimalist look, the right way to enforce it is to declare it yourself in that file — a limited green-and-pink palette, a dark base background at #0c1624 , typography and tone of voice — so every

Los agentes de código generativo son potentes, pero si se les deja a su libre albedrío, por defecto producen un desorden visual: degradados predecibles, espaciados sin calibrar y estructuras de componentes pesadas y obsoletas. Impeccable es un paquete de habilidades de diseño, creado por Paul Bakaus, que opera directamente dentro de Claude Code, Gemini CLI y Codex CLI (además de Cursor y GitHub Copilot) para imponer estrictos límites estéticos, con un mismo conjunto de reglas recompilado para cada harness. Al aplicar un diseño de habilidades deliberado, puedes alejar a los agentes de los patrones genéricos y obligarlos a generar experiencias web precisas y de alto nivel visual. ¿Qué es el diseño de habilidades y por qué es importante para los agentes de IA? El diseño de habilidades ( skill design ) es la práctica de construir rieles deterministas para modelos de IA no deterministas. En lugar de pedirle interminablemente a un agente que "haga que se vea mejor" o "mejore el rendimiento", inyectas un DESIGN.md compilado y directivas funcionales que el agente debe respetar en cada iteración. Impeccable construye sobre la habilidad frontend-design de Anthropic y añade 23 comandos con un vocabulario de diseño compartido, más 58 reglas deterministas de detección de antipatrones (fuente Inter por defecto, degradados morado-azul, tarjetas anidadas, texto gris sobre fondos de color, iconos redondeados sobre cada encabezado, entre otros). Transforma a la IA de ser un desarrollador junior que intenta adivinar tu estética a un implementador estricto de las reglas visuales que tú definas. Cómo implementar las restricciones de Impeccable para aplicaciones web modernas Al integrar este flujo de trabajo, la precisión lo es todo. Impeccable respeta tu sistema de diseño existente en lugar de sobrescribirlo: al ejecutarse, escanea tu código base (tokens, componentes, configuración de Tailwind) y carga las reglas de marca desde tu propio DESIGN.md , en vez de imponer una estética genéri

Block Kit, signature verification, and the design decisions that stop a button click from becoming an incident. That screenshot is a bot asking permission to delete an EBS volume. Clicking Approve Remediation snapshots the volume, waits for the snapshot to complete, deletes the volume, and edits the message to say what happened. Getting that to work is mostly plumbing. Getting it to work safely , so that a stale click, a replayed request, or a resource someone protected in the meantime cannot cause damage, is the interesting part. This walks through both, using the Slack adapter from FinOps Sentinel . The shape of the problem Slack interactivity is two separate channels that only look like a conversation: Your app ──── incoming webhook ────▶ Slack channel │ user clicks │ Your app ◀─── HTTP POST ──────────────────┘ (a completely new request, from Slack's servers) The click arrives as an unauthenticated POST from the public internet to whatever URL you registered. Nothing about the request proves it came from Slack, or that a human clicked anything. That is the security problem in one sentence, and everything below follows from it. Part 1: Setting up the Slack app Create the app and get a webhook api.slack.com/apps → Create New App → From scratch Name it, pick your workspace Incoming Webhooks → toggle On → Add New Webhook to Workspace Choose a channel, click Allow , copy the URL SLACK_WEBHOOK_URL = https://hooks.slack.com/services/TXXXXX/BXXXXX/XXXXXXXX Webhooks post to exactly one channel and cannot read anything. For a notification bot that is the right amount of privilege: no OAuth flow, no bot token, no scopes to review. Enable interactivity Interactivity & Shortcuts → toggle On → set the Request URL: https://your-domain.example/callbacks/slack Locally you need a tunnel: ngrok http 8000 # → https://a1b2c3d4.ngrok.app # Request URL: https://a1b2c3d4.ngrok.app/callbacks/slack The free ngrok URL changes on every restart, and you must update Slack each time. Save your

If you have ever bought a domain on Namecheap to redirect traffic to your main web app, you might have hit a frustrating wall: Namecheap's free "Domain Redirect" feature works fine for plain http:// requests, but it completely falls flat when someone hits https:// . Browsers try to perform an SSL/TLS handshake before following the HTTP redirect header. Because Namecheap does not issue a free SSL certificate for basic domain forwarding, your users end up seeing a scary "Your connection is not private" error. Here is how to set up a full, seamless redirect from an old domain ( snapseek.co ) to a new domain ( snapseek.app ) using Cloudflare's free tier. This approach handles both HTTP and HTTPS, while preserving all incoming URL paths and query parameters. The Big Picture Instead of serving traffic through Namecheap's basic forwarding servers, we hand off DNS management to Cloudflare. Cloudflare acts as a reverse proxy, provides a free universal SSL/TLS certificate, and handles the redirection right at the edge using its modern Single Redirect Rules engine. Step 1: Add Your Domain to Cloudflare Log into your free Cloudflare account (or sign up if you do not have one). On your dashboard under the Home tab, click Add a domain . Type in your source domain (e.g., snapseek.co ) and choose Quick scan for DNS records . When prompted to select a plan, scroll down to the bottom and pick the Free plan. Cloudflare will scan your existing DNS setup. Scroll down and click Continue to activation . Cloudflare will display a pair of custom nameservers (for example: ada.ns.cloudflare.com and sam.ns.cloudflare.com ). Copy these down. Step 2: Update Nameservers in Namecheap Log into your Namecheap account and go to your Domain List . Click Manage next to your domain ( snapseek.co ). Find the Nameservers dropdown section. Switch it from Namecheap BasicDNS to Custom DNS . Paste the two Cloudflare nameservers into the fields and click the green checkmark to save. Note: DNS propagation usual

Embedding a browser game looks simple: <iframe src= "https://games.example.net/my-game" ></iframe> That line lets a third party join the page lifecycle immediately. It can download a large bundle, establish connections, run scripts, request storage, display advertising, or fail before the visitor decides to play. AI-assistance disclosure: I used AI to help draft and edit this article, then reviewed its architecture, code, claims, and limitations before publication. For a game directory, that default is both expensive and surprising. A visitor may have opened the page to read the controls, compare games, or check whether the game works on a phone. Loading the player before that intent is known wastes bandwidth and collapses two separate decisions—visiting the guide and opening the third-party game—into one. While working on a browser-game portal, I treated the site and the embedded player as two different trust and performance boundaries. The page renders first-party information immediately. The third-party frame is created only after an explicit Play action. This article explains that pattern and the engineering details that made it useful rather than merely decorative. Start with a two-layer model The outer page should be a complete page without the game: A descriptive heading and summary Controls and gameplay tips Developer and platform information Related games and category navigation A poster or cover image A real button that starts the player The inner layer is a small launcher responsible for the game lifecycle: Validate the requested game. Wait for an intentional Play action. Create the provider iframe. Report loading state. Offer recovery when loading is slow or blocked. Remove the frame when the player resets it. Do not put the remote URL in the initial markup Native iframe lazy loading is helpful below the fold, but it is not an intent gate. Browsers decide when a loading="lazy" frame is close enough to fetch. If the goal is “no third-party game request be

Every year, thousands of people struggle to find blood donors during emergencies. I wanted to build something that could simplify that process while improving my full-stack development skills. So I built a Blood Donation Management System using the MERN Stack. The goal was simple: create a platform where donors, recipients, and volunteers can connect efficiently through a modern web application. In this article, I'll share the architecture, key features, and the lessons I learned while building it. Tech Stack : Frontend React.js React Router Tailwind CSS Axios Backend Node.js Express.js Database MongoDB Mongoose Authentication JWT bcrypt Deployment Vercel (Frontend) Render (Backend) The Problem Finding blood donors during emergencies is often difficult because information is scattered across social media and messaging apps. I wanted to build a centralized platform where users could: Register as blood donors Search donors by blood group and location Request blood Manage donation information Keep donor data organized 🏗️Project Architecture Client (React) │ REST API │ Node.js + Express │ ├── Authentication ├── Donor Management ├── Blood Requests ├── User Dashboard └── Admin Panel │ MongoDB Keeping the frontend and backend separated made the project easier to maintain and scale. Key Features Secure user authentication Role-based dashboard Blood donor registration Search donors by blood group Blood request management Responsive UI Protected routes RESTful API Project Structure client/ ├── components/ ├── pages/ ├── hooks/ ├── layouts/ └── routes/ server/ ├── controllers/ ├── middleware/ ├── models/ ├── routes/ ├── utils/ └── config/ Organizing the project into separate folders helped keep the codebase clean and easier to extend. Authentication Flow Authentication was implemented using JWT and bcrypt. The basic flow looks like this: Register ↓ Password Hashing ↓ MongoDB ↓ Login ↓ JWT Token ↓ Protected Routes This keeps user data secure while allowing authenticated access

The first version of a webhook is always the same four lines: await fetch(customer.webhookUrl, { ...

When I first started working with APIs, "Swagger" was almost synonymous with API documentation. If...

TL;DR: MCP servers run with significant privileges inside AI agent pipelines, and most teams ship them without any security review. mcp-security-scan is an open-source CLI and GitHub Action that checks for credential theft patterns, data exfiltration, unsafe execution, and code obfuscation — and outputs a 0-100 trust score that integrates with AgentGraph's identity layer. The Moltbook breach last year is still the clearest example of what happens when you scale agent infrastructure without thinking about trust. 770,000 agents, zero identity verification, and when it went down it exposed 35,000 emails and 1.5 million API tokens. The tokens were the real problem — many of them were credentials passed through MCP servers that nobody had audited. MCP (Model Context Protocol) servers are the connective tissue of modern agent systems. They sit between your LLM and the outside world, handling tool calls, filesystem access, API requests. That position gives them a lot of power. It also makes them an obvious target. And yet most teams treat MCP servers like they treat npm packages circa 2015: install and trust. What Actually Goes Wrong Before getting into the scanner, it's worth being specific about the threat categories. There are four that show up most often in real codebases: Credential theft — MCP servers that read environment variables indiscriminately, log request/response payloads, or forward tool call arguments to external endpoints. This one is subtle because the server might be doing legitimate work and exfiltrating credentials. Data exfiltration — Outbound HTTP calls to domains that weren't declared in the server's manifest, or calls that happen inside tool handlers where the LLM can influence the destination URL. Prompt injection into tool parameters is the attack vector here. Unsafe execution — eval() , exec() , subprocess calls, or dynamic require() / import() where the argument comes from tool call input. If an LLM can influence what gets executed, you have a

Everyone evaluating AI avatar platforms focuses on voice quality. The bigger UX killer is almost always latency — and it's a harder problem than picking a good TTS provider. Where the delay actually comes from: User speaks/types → STT (if voice input) → LLM generates response (streaming helps, but first-token latency matters) → TTS converts text to audio → Audio playback + lip-sync rendering Each hop adds latency. A naive implementation that waits for the full LLM response before starting TTS can easily hit 2-4 seconds of dead air — long enough for a user to assume the bot is broken. How production systems actually solve this: Token streaming into TTS — start synthesizing audio on partial LLM output (sentence-by-sentence chunks) instead of waiting for the full response Speculative rendering — start lip-sync animation slightly ahead of audio using predicted phoneme timing WebSocket/SSE persistent connections — avoid the overhead of repeated HTTP round-trips per turn Regional API routing — TTS/LLM provider latency varies a lot by user geography; this matters more than most benchmarks show A practical note: platforms that advertise "real-time" avatars but load all logic behind a single request/response cycle will feel noticeably worse than ones built around streaming pipelines, even if they use the identical LLM and TTS providers underneath. If you're evaluating a platform (or building one), test with realistic network conditions, not office wifi — that's where the architecture differences actually show up. Bottom line: the voice provider matters less than people think. The orchestration around it — how aggressively you stream and pipeline each stage — is what separates a "wow" demo from a production-ready conversational agent.

Introduction For the last few weeks, I’ve been running a small experiment. Instead of building another SaaS startup or chasing investors, I decided to build a simple website around AI tools and document everything publicly. No team. No marketing budget. No SEO agency. Just curiosity, consistency, and a lot of trial and error. I genuinely want to answer one question: Can a small AI website still grow organically in 2026? ⸻ Why I Started AI tools are everywhere now. Every day another directory, another “best AI tools” list, another comparison website appears. Most people say it’s already too late. Maybe they’re right. I wanted to find out myself instead of trusting opinions. So I bought a domain and started building. ⸻ My Rules To make the experiment interesting, I gave myself a few restrictions. No buying backlinks. No paid traffic. No huge content team. No publishing hundreds of AI-generated articles. Everything has to be something I would actually publish. Quality first. ⸻ The First Product Instead of only writing articles, I decided the website should also offer something genuinely useful. The first tool is a free AI Background Remover. Nothing revolutionary. But it solves a real problem in a few seconds, and that felt like a better starting point than another generic blog post. ⸻ What I’ve Learned So Far The biggest surprise wasn’t building the tool. It was realizing how much work happens after pressing “Publish.” Indexing. Technical SEO. Site structure. Internal linking. Performance. Small details matter far more than I expected. ⸻ The Goal I’m not trying to build the next unicorn. I simply want to see whether a small independent website can still earn organic traffic by creating useful content and useful tools. If it works, great. If it fails, I’ll document that too. Either way, I’ll share the results. ⸻ Try the Tool If you’re curious, you can try the first tool here: 👉 https://letomix.com/free-tools/background-remover/ I’d genuinely appreciate any feedback.

Internships are one of the most valuable experiences for any undergraduate, and I am grateful to have completed mine. This journey allowed me to bridge the gap between academic knowledge and real-world software development while improving both my technical and professional skills. From my very first day, I was introduced to a collaborative development environment where teamwork, communication, and problem-solving played a major role. I had the opportunity to work on real projects, understand industry workflows, and learn how professional software products are built and maintained. Throughout my internship, I gained hands-on experience with modern web technologies, version control using Git, API integration, debugging, and deploying applications. I also learned the importance of writing clean, maintainable code and following industry best practices. Working alongside experienced developers helped me improve my coding standards and exposed me to new tools and frameworks. One of the biggest lessons I learned was that software development is not only about writing code. It involves understanding user requirements, collaborating with team members, managing deadlines, and continuously learning new technologies. Every challenge I encountered became an opportunity to grow and improve my skills. Beyond technical knowledge, this internship strengthened my confidence, communication, time management, and ability to work effectively in a professional team. The guidance and support from my mentors played a significant role in my growth throughout this journey. Looking back, this internship has been a milestone in my career. It has given me practical experience, valuable industry exposure, and a clearer vision of the software engineering field. I am excited to apply these lessons in my future projects and continue growing as a developer. I would like to express my sincere gratitude to my mentors, teammates, and the organization for providing me with this incredible opportunity. Th

A few weeks ago I wrote up what agents were paying for on NetIntel , my platform of pay-per-call APIs settled in USDC over x402 — no signup, no API keys, no accounts. An agent hits an endpoint, gets a 402 Payment Required , pays a fraction of a cent, and gets structured data back. That's the whole loop. Since then the dataset has grown, I've instrumented every settled call into a proper database (payer wallet, endpoint, price, latency, transaction hash), and I've launched a second settlement rail. So this is the rewrite with real numbers instead of eyeballed ones — and the findings didn't soften. They sharpened. The setup 2,646 settled paid calls from 194 distinct paying wallets, across 101 live endpoints , over six weeks of instrumented production data. Every call in this dataset is a real on-chain payment with a transaction hash — no test traffic, no estimates. Settlement runs on Base, and as of this month on Solana too. This is still one platform's data in a young ecosystem — the caveats are at the bottom, and one of them is bigger than it looks. But the shape has now held for six weeks straight, and it's the same shape I flagged the first time. Finding 1: revenue is absurdly concentrated — and it stayed that way Five endpoints drive 69% of all revenue. One of them — a text-to-structure endpoint that takes messy input and returns strict typed JSON — is 42% by itself . The rest of the top five are all in the same family: translation, structured LLM inference, and one domain-intelligence report. The other 96 endpoints split the remaining 31%. Thirty-five of the 101 have never been paid for once. Not "underperformed" — zero settled calls, ever. When I first published this pattern I wondered if it was an artifact of a small sample. The dataset has since more than doubled and the concentration ratio barely moved. I now treat it as the market talking, not noise. Here's the part I'd want to know if I were reading this: that 42% endpoint is essentially one buyer — a wall

Six months ago I wrote up my local AI setup and a reader bookmarked it, tried to reproduce it last week, and emailed me confused because half of it no longer matched what I actually run. Fair. Stacks rot quietly. So here's the mid-2026 state of mine: what's still earning its place on disk, what I deleted, and where I quietly went back to the cloud. Context for the numbers and opinions below: I do smart contract security work, I run everything on WSL2 on a machine with a modest GPU, and I've been doing the local-model thing daily for over a year, not as a hobby but as part of shipping. Still here: Ollama as the runtime Ollama remains the center of the local stack and honestly it's not close. I've tried the alternatives, llama.cpp directly for control, a couple of the newer serving layers for speed, and I keep coming back for one boring reason: the API is stable and everything I've built talks to it. My audit tooling, my shell scripts, my editor config, they all point at localhost:11434 and they've pointed there for a year without breaking. That stability matters more than a marginal tokens-per-second win. When a model update lands, ollama pull and I'm done. The day something meaningfully better appears with the same API shape, I'll switch in an afternoon, which is exactly the position you want to be in. Still here: qwen2.5-coder, both sizes, different jobs I run two models and the split has stayed remarkably stable: qwen2.5-coder:1.5b is the reflex model. It handles anything where speed matters more than depth: quick "what does this diff do" summaries, commit message drafts, pre-filtering files before a heavier pass, and the small classification jobs inside my pipelines ("does this file handle user input, yes or no"). It's fast enough on my machine that I never think about invoking it, and that's the whole point. A model you hesitate to call is a model you stop calling. qwen2.5-coder:7b is the thinking model. Code review, security triage, structured findings extracti

Hey everyone, Whenever I start scaling out a new Rust service or protocol, I always find myself hitting the same wall: testing gets messy fast. You end up juggling basic cargo test unit checks, hacking together ad-hoc integration scripts, and manually setting up coverage tools every single time. I put together RustForge to solve that headache for my own projects, and figured it might save a few of you some time too. It’s a clean, zero-bloat starter template designed to take you from simple unit tests all the way to compiler-style UI snapshots and coverage tracking without having to reinvent the harness every project. https://github.com/rwilliamspbg-ops/RustForge

Beginner's Guide: Connect React with Supabase 🚀 If you already know basic React (components, useState , useEffect ), this guide will show you how to connect your React app to Supabase — an open-source Firebase alternative — and build a simple To-Do app with full CRUD (Create, Read, Update, Delete). Let's go step by step. No prior Supabase knowledge needed. What is Supabase? Supabase gives you a Postgres database , authentication , and instant APIs — without writing any backend code. Think of it as a backend-as-a-service. For this guide, we'll just use the database + auto-generated API part. Step 1: Create a Supabase Project Go to supabase.com and sign up (GitHub login is fastest). Click New Project . Fill in: Name : todo-app (anything you like) Database Password : save this somewhere safe Region : pick the closest one to you Click Create new project and wait ~1-2 minutes while Supabase sets everything up. Step 2: Create the todos Table In your Supabase project dashboard, go to the Table Editor (left sidebar). Click New Table . Name it todos . Add these columns (in addition to the default id and created_at ): Column Name Type Default task text — is_complete bool false Click Save . 💡 Tip: You can also do this via the SQL Editor by running: create table todos ( id bigint generated by default as identity primary key , task text not null , is_complete boolean default false , created_at timestamp with time zone default now () ); Turn off Row Level Security (for learning purposes only) Go to Authentication > Policies (or Table Editor > todos > RLS), and disable RLS for now so your students can read/write freely without setting up auth. ⚠️ Important for your session : Tell your juniors this is only for a demo/learning project. In a real production app, RLS should always be enabled with proper policies. Step 3: Get Your API Keys Go to Project Settings > API . Copy two things: Project URL (looks like https://xxxxx.supabase.co ) anon public key (a long string) You'll need both

A few weeks ago I needed to check something in the Action Mailer docs, just a quick lookup. I ended up spending much more time there than expected and found a few features I had no idea existed, even though I've been using Action Mailer in production for a while. One of them lets you see an email before it's ever sent. Another lets you modify an email right before it goes out. And the third one allows you to override the default delivery options dynamically. I figured I probably wasn't the only one who had missed these, so here are three Action Mailer features that caught my attention. If you want to explore more, the official Action Mailer documentation is always a great place to start. 1. Previews Before I found this, testing an email meant sending it to myself, checking my inbox, tweaking the template, and repeating. Turns out ActionMailer has a built-in way to preview emails in the browser, without sending anything. You add a preview class in test/mailers/previews like: class InvitationMailerPreview < ActionMailer :: Preview def team_invitation InvitationMailer . with ( user: User . first , company: Company . first ). team_invitation end end And visit http://localhost:3000/rails/mailers/invitation_mailer/team_invitation . This removes the usual feedback loop of tweaking a template. You just refresh the browser instead. Rails also allows custom preview paths if you want to keep previews in a different location: config . action_mailer . preview_paths << " #{ Rails . root } /lib/mailer_previews" This was a small discovery, but it immediately improved my workflow. 2. Interceptors An interceptor is a hook that runs right before an email is handed off for delivery, letting you modify it. A common use case is preventing mistakes in staging environments. Nobody wants to accidentally send a real looking email from a staging application to an actual customer. Another common approach is redirecting all outgoing mail in staging or development environments to a single defaul