标签：#dev

Fable and Opus may not be the most comfortable tools for engineers who learned to code by hand. I started thinking about this after reading Simon Willison's recent note . His point is simple: with a strong coding agent like Fable, it may be better to let the model exercise its own judgment than to spell out every condition yourself. Instead of writing detailed rules like "run tests for larger features, but not for small copy changes, except for design changes...," you can simply say: write and run tests where appropriate. The same applies to cost. Rather than deciding manually which tasks should go to which model, you can ask the agent to choose an appropriate lower-cost model and delegate the work to a subagent. Manual cars and automatics This is a rough analogy, but it feels similar to driving a car. People who enjoy driving often like manual cars. They want to choose the gear themselves. They want to feel the engine speed and have the car respond directly to their intent. For people who simply want to get somewhere, an automatic is easier. Software engineers are similar. If you have written code professionally for a long time, you usually have your own way of working. You may want to get the types right first. You may prefer small diffs. You may have a specific sense for how granular tests should be. You may even have an order in which you like to read an unfamiliar codebase. (At least, I hope you do.) For someone with that kind of style, a highly autonomous model like Fable or Opus can feel a little too automatic. The stronger the model, the more small instructions get in the way This is the same structure as management in human organizations. A junior member needs concrete instructions: read this document from this angle and summarize it in this format. A senior member can take a rougher assignment: I want to solve this problem, so investigate it, come up with an implementation plan, and move it forward. Of course this does not mean throwing work over the wall.

I just shipped 5 new tools to DevNestio — a hub of 172 free, browser-only developer utilities. All tools are zero-signup, zero-upload, and work offline. 1. GraphQL Query Formatter & Minifier https://devnestio.pages.dev/graphql-formatter/ Paste any GraphQL operation and get: Pretty-print — consistent indentation Minify — strips comments and whitespace for smaller request payloads Validation — brace/parenthesis balance check Operation detection — lists all named query , mutation , subscription , fragment Useful for quick query cleanup before pasting into code reviews or API docs. 2. Protobuf (.proto) Formatter & Validator https://devnestio.pages.dev/protobuf-formatter/ Online formatter and validator for Protocol Buffer .proto files: Duplicate field number detection Message and enum structure validation Syntax-highlighted output One-click copy Great for a sanity check before pushing .proto changes in a gRPC service. 3. Docker Compose Validator https://devnestio.pages.dev/docker-compose-validator/ Paste your docker-compose.yml to catch: Missing services section Services without image or build Invalid port mappings ( 80:80 , 127.0.0.1:8080:80 , 53:53/udp , ranges…) depends_on referencing non-existent services Circular dependency detection (A→B→A) Unknown restart policies # This will flag errors: services : web : ports : - " abc:xyz" # invalid port depends_on : - missing_service # unknown service 4. Dockerfile Analyzer & Linter https://devnestio.pages.dev/dockerfile-analyzer/ Analyzes your Dockerfile for best practice violations across three categories: Security sudo usage inside RUN Container running as root (no USER instruction) Secrets baked into ENV / ARG (password, secret, token, key) Image size :latest base image tag apt-get update in a separate RUN (stale cache risk) apt-get install without --no-install-recommends apt cache not cleaned ( rm -rf /var/lib/apt/lists/* ) ADD used for local files instead of COPY Layer optimization Consecutive RUN instructions (suggest c

TL;DR Two Laravel backends started serving Flutter apps on the same day — an events platform (auth, orders, offline check-in) and a helpdesk product (ops mode for agents). gatherhub-web moved to plans-only pricing with a comparison matrix driven by one data file. A hardening pass: payment-safe queues, gateway reconciliation, one heavyweight dependency dropped. Two mobile APIs in one day Coincidence, but a useful one: two products I'm building both needed their Laravel backends to serve mobile apps this week. The events platform got the full foundation — token auth (login/refresh/logout/me), participant orders, mobile payment with status polling, push-device registration, and an offline-first staff check-in flow. That last one is the interesting bit; I wrote it up as its own post. The helpdesk product went the other way: its API was client-only, and today it became role-aware. The same endpoints now serve ops agents working tickets from their phones, with abilities deciding what each role sees. One API surface, two personas, no duplicated /admin routes. The lesson that repeated in both: API Resources are the contract. The moment a mobile dev consumes your endpoint, every field you accidentally leak becomes a field you can't remove. Plans-only pricing (public) gatherhub-web , the Next.js marketing site, dropped à-la-carte feature pricing for three plans and gained a plan comparison matrix. Everything renders from a single plans.ts — the matrix, the pricing cards, the enterprise page — so the marketing site can't drift from what's actually sold. A pricing page is a contract too; it deserves a single source of truth as much as your API does. Hardening pass Change Why Bulk email blasts isolated to their own queue one big send must never delay a payment webhook Reconciliation command for stuck pending orders webhooks fail silently; polling the gateway is the safety net maatwebsite/excel → spatie/simple-excel for exports streams rows instead of building sheets in memory, s

TL;DR A gate check-in app can't depend on live Wi-Fi: scans must work offline and sync later. Four endpoints do it: manifest download, idempotent batch push, delta pull, online search. Client-generated UUIDs + a unique index make retries safe. Duplicates are a success status, not an error. The problem Physical event, staff scanning tickets at the door, venue Wi-Fi exactly as reliable as you'd expect. If your API sits in the hot path of every scan, the queue at the gate grows at the speed of the worst signal bar in the building. So the design flips the roles: the device owns check-in, the server owns convergence. Like a cashier who keeps a paper ledger when the till goes down — record now, reconcile later. The API surface Endpoint Purpose GET /staff/events/{uuid}/manifest paginated ticket snapshot, downloaded before gates open POST /staff/events/{uuid}/check-ins/batch push queued scans; safe to retry GET /staff/events/{uuid}/check-ins?since=<cursor> pull what other devices did GET /staff/events/{uuid}/participants?q= online fallback search (lost ticket, typo) The sync loop Device Server |--- GET manifest (before event) ------->| | scan offline, queue locally | |--- POST batch [{client_uuid, ts}] ---->| dedupe on client_uuid |<-- 200 {applied | duplicate per item} -| |--- GET check-ins?since=cursor -------->| scans from other devices |<-- delta + next cursor ----------------| Idempotency is the whole trick Every scan gets a UUID generated on the device at scan time . The server puts a unique index on it and inserts-or-ignores: public function batchCheckIn ( BatchCheckInRequest $request , string $uuid ): JsonResponse { $results = collect ( $request -> validated ( 'check_ins' )) -> map ( function ( array $scan ) { $checkIn = CheckIn :: firstOrCreate ( [ 'client_uuid' => $scan [ 'client_uuid' ]], [ 'ticket_id' => /* resolved from scan */ , 'checked_in_at' => $scan [ 'scanned_at' ]], // ... ); return [ 'client_uuid' => $scan [ 'client_uuid' ], 'status' => $checkIn -> wasR

While setting up a self-managed Kubernetes cluster on Azure VMs, I hit this error when running sudo kubeadm init on a Standard_B1s VM (1 vCPU / 1 GB RAM): [ERROR NumCPU]: the number of available CPUs 1 is less than the required 2 After checking Stack Overflow and the official Kubernetes documentation ("Before you begin"), I confirmed that kubeadm requires at least 2 CPUs to install the control plane. The fix: I stopped the VM and resized it from Standard_B1s to Standard_B2s (2 vCPU / 4 GB RAM) from the Azure portal, then ran kubeadm init again — the preflight checks passed and the control plane initialized successfully. Posting this in case it helps someone hitting the same issue on a low-tier cloud VM. Thanks to the community for the answers that pointed me in the right direction!

I had just aced my mentor’s Docker exam, so of course I thought I understood containers. I had said all the right words: namespaces, cgroups, images, layers, PID 1, Kubernetes Pods. Then I typed my first serious command and Linux reminded me that knowing the nouns is not the same thing as building the thing. $ sudo unshare -p 1 test unshare: failed to execute 1: No such file or directory That was the opening scene. I had not even built anything yet. I had typed the flags wrong and accidentally asked unshare to execute a program called 1 . This was going to be less “implement Docker” and more “let the kernel correct my confidence, one error at a time.” v1: namespaces, or the first time PID 1 lied to me The first version was supposed to be easy: run a process in a new PID namespace and prove it sees itself as PID 1. So I ran the command the way I thought it worked: $ sudo unshare --pid bash # echo $$ 25184 That was not PID 1. That was just embarrassing. The rule I had missed is simple: PID namespaces apply to children. The process that calls unshare --pid does not magically become PID 1. You need to fork. The first child born into the new namespace becomes PID 1. So the working version was: $ sudo unshare --pid --fork bash # echo $$ 1 That one line changed the tone. I was inside a different process universe. The shell thought it was process 1. Signals felt different. Orphans came home to it. Then I ran ps , and got humbled again. # ps -o pid,ppid,comm PID PPID COMMAND 25310 25304 bash 25344 25310 ps That made no sense at first. I was PID 1, but ps was showing host-looking PIDs. The next reveal: ps does not ask the kernel some pure “what processes exist?” question. It reads files. If /proc still points at the host procfs, your tools will tell you the host story. So I remounted /proc from inside the namespace: # mount -t proc proc /proc # ps -o pid,ppid,comm PID PPID COMMAND 1 0 bash 7 1 ps That was when it clicked. The namespace did not become real to my eyes until /pr

Every application we use today—from banking apps to social media platforms—has something working behind the scenes. That hidden engine is called the backend. The backend is responsible for processing requests, storing data, handling authentication, enforcing business rules, and ensuring everything works as expected when users interact with an application. One of the first decisions backend developers make is choosing a framework. A framework provides the tools, structure, and best practices needed to build applications faster and more securely. Today, let's look at three popular backend frameworks: Django, Gin, and Ruby on Rails. Django (Python) Django is one of the most mature and feature-rich backend frameworks available. Built using Python, it follows the philosophy of "batteries included." This means many features developers need are already built into the framework, including: User authentication Admin dashboard Database ORM Security protections URL routing Form validation Because so much comes ready to use, developers can spend more time solving business problems instead of rebuilding common features. Best for: Content management systems E-learning platforms Business applications APIs Startups building products quickly Advantages: Fast development Excellent security features Large community Extensive documentation Scales well for many applications Trade-offs: The framework includes many components, so it can feel heavier than minimalist frameworks. Gin (Go) Gin is a lightweight web framework built for the Go programming language. Unlike Django, Gin keeps things minimal. It gives developers speed and flexibility while letting them choose many of the additional tools they want to use. One reason many developers enjoy Gin is its impressive performance. Since Go is a compiled language designed for concurrency, Gin can efficiently handle many requests simultaneously while using relatively few system resources. Best for: REST APIs Microservices High-performance syst

If you build apps for jewelers, fintech dashboards, or e-commerce price automation, you eventually need one thing: reliable, low-latency gold and currency prices . Scraping fragile sources breaks constantly. A dedicated price API solves this. In this post I'll show how to consume real-time gold (gram, quarter, coin) and FX rates over both REST and WebSocket (Socket.IO) using the Hasfiyat Gold & Currency API . Why a price API instead of scraping? Stability — a documented contract instead of HTML that changes without notice. Low latency — prices are pushed as the market moves, not on a slow cron. Multiple sources with failover — if one provider drops, the feed keeps flowing. 1. Polling with REST The simplest integration: request the prices you need with your API key. curl -X GET \ 'https://api.hasfiyat.com/api/prices?symbols=HAS,GRAM,CEYREK' \ -H 'Authorization: Bearer YOUR_API_KEY' \ -H 'Accept: application/json' // Node.js const res = await fetch ( " https://api.hasfiyat.com/api/prices?symbols=HAS,GRAM,CEYREK " , { headers : { Authorization : " Bearer YOUR_API_KEY " } } ); const data = await res . json (); console . log ( data ); REST is ideal for periodic reporting, server-side jobs, and updating e-commerce product prices. 2. Live updates with Socket.IO For price screens, signage, and mobile apps where every tick matters, keep a connection open and let the server push changes: import { io } from " socket.io-client " ; const socket = io ( " https://api.hasfiyat.com " , { auth : { token : " YOUR_API_KEY " } }); socket . on ( " gold_prices " , ( data ) => { // { symbol: "HAS", type: "Has Altın", buy: 2450.85, sell: 2455.10, timestamp: "14:32:01.045" } console . log ( data ); }); No polling, no hammering the server — each market move arrives instantly. 3. A minimal live ticker in the browser <div id= "gold" ></div> <script src= "https://cdn.socket.io/4.7.5/socket.io.min.js" ></script> <script> const socket = io ( " https://api.hasfiyat.com " , { auth : { token : " YOUR

Introduction In today's fast-paced development cycles, security can no longer be an...

"Forward Deployed Engineer" went from a Palantir-specific title to one of the hottest roles in AI in about eighteen months. But nobody had actually counted the market, so I did. I pulled every open FDE role I could find from public ATS job boards (Greenhouse, Lever, Ashby) across 11 companies and analyzed all 292 of them. Here is what the data says. Who is hiring Three companies account for 250 of the 292 openings: Palantir: 95 (they coined the title, and still call many of these roles "Deployment Strategist") Databricks: 85 OpenAI: 70 Then a long tail: Cohere and Scale AI (13 each), Sierra, Writer, Modal, Baseten, Ramp, and Sardine. What it pays Of the 40 roles that disclosed a US pay band, the median ran $197K to $294K , topping out at $390K plus equity at OpenAI and Sierra, with a floor around $137K. That is senior-software-engineer money for a role a lot of engineers have never heard of. International and most Palantir roles did not publish bands, so the true market is likely even broader. Three things that surprised me 1. 98% of these roles are customer-facing. This is the defining trait. It is not a backend role with occasional meetings. It is an engineer who lives in the customer's world, and if that sounds terrible to you, this is not a role you would enjoy occasionally. It is the whole job. 2. The title is chaos. The same role goes by at least four names: Forward Deployed Engineer (152), Forward Deployed Software Engineer (58), AI or Deployment Engineer (43), and Deployment Strategist (36). If you only search one term, you miss most of the market. 3. The job descriptions undersell the technical bar. JDs emphasize customer-facing work, cloud (AWS/GCP/Azure), Python, and integrations. But SQL and algorithms show up in only about a third of them, even though every FDE loop I have seen tests live coding and SQL under time pressure. The description sells the breadth. The interview tests the depth. The other details Geography: about 48% USA, but genuinely global

If you're using AI coding assistants like ChatGPT, Claude, Cursor, or Lovable, you've probably accumulated dozens of JSX components. Generating them is incredibly fast. Previewing them? Not so much. The Typical Workflow Every time I received a JSX component, I found myself repeating the same process. Create a React project (or open an existing one) Copy the JSX file Install dependencies Fix missing imports Run the development server Wait for everything to compile All of that... just to see one component. It felt like unnecessary overhead. There Had to Be a Better Way I asked myself a simple question: Why can't I just double-click a JSX file and preview it? We can instantly open images, PDFs, videos, and text files. Why should JSX files require an entire development environment? That's what inspired me to build PreviewKit . What is PreviewKit ? PreviewKit is a lightweight Windows application that lets you preview frontend components instantly. Supported file types include: ✅ JSX ✅ Vue ✅ HTML No project setup. No dependency installation. No terminal commands. Just open the file and see the result. Why I Built It AI has dramatically changed frontend development. We're no longer spending most of our time writing components—we're reviewing, comparing, and refining them. That means fast visual feedback is more important than ever. I wanted a tool that removed the repetitive setup process so I could focus on building better interfaces instead of preparing a preview environment. Who Is It For? PreviewKit is useful if you: Build React applications Work with Vue components Test standalone HTML files Generate UI with AI tools Review components from teammates Prototype interfaces quickly If opening frontend files feels slower than it should, PreviewKit was built for you. The Goal Isn't to Replace Your Framework You'll still use React. You'll still use Vue. You'll still use Vite or Next.js. PreviewKit isn't trying to replace your existing workflow. It simply removes one frustrat

The most dangerous moment in an AI-built app project is not when the code breaks. It is earlier. It is the moment where your idea is still blurry, the AI coding tool is sitting there politely, and you type: Build me an app that... That sentence feels productive. It also gives the tool permission to make a pile of decisions you have not made yet. Who is the app for? What is version one? Which workflow matters first? What data has to exist? What should not be built yet? What would make the first version successful? If those answers are missing, AI has to guess. And AI guessing at product shape is how beginners end up with a login system, dashboard, profile editor, notifications panel, admin area, billing flow, and settings page before one real user problem has been solved. That is not momentum. That is software confetti. I like AI coding tools. I use them heavily in real app work. But the tool gets much better when the project has boundaries before code starts changing. So before you ask AI to code your first app, run the idea through a checklist. Not a giant business plan. Not a pitch deck. Not a 47-tab spreadsheet that makes you feel like you joined a corporate strategy retreat by accident. A practical beginner checklist. The goal is simple: turn a rough app idea into something AI can help you build without inventing the whole product for you. 1. Can You Name The Person? Do not start with "users." Start with one person you can picture. Bad: This app is for people who want to be more productive. Better: This app is for freelance designers who need one place to track client feedback, revision status, and final file delivery. Bad: This app is for musicians. Better: This app is for guitarists who want to capture riff ideas quickly on their phone without opening a full mobile studio app. Bad: This app is for students. Better: This app is for college students who want to scan textbook chapters and turn them into study notes before an exam. When you name the person, the ap

If you want remote job data, you do not need to scrape HTML or sign up for anything. Four of the bigger remote job boards publish keyless public feeds. The catch is that they all speak different dialects, so the real work is normalization. Here are the endpoints and the traps. The four feeds RemoteOK returns its whole current board as one JSON array: GET https://remoteok.com/api The first element is a legal notice, not a job: they ask for a link back with attribution as a condition of using the feed. Skip element zero, and honor the attribution if you republish. Jobs carry salary_min and salary_max as numbers, tags, and ISO dates. Remotive has the friendliest API of the four, including server side search: GET https://remotive.com/api/remote-jobs?search=python&limit=100 Salary here is free text ( "$120k - $160k" ), so do not expect numbers. Attribution with a link back is required here too. WeWorkRemotely publishes RSS: GET https://weworkremotely.com/remote-jobs.rss Two quirks: the company name is not a field, it is baked into the title as Company: Role , so split on the first colon. And useful data hides in nonstandard tags like <region> , <skills> , and <category> that generic RSS parsers drop on the floor. Himalayas has a proper paginated API with a surprisingly deep catalog (100k+ listings): GET https://himalayas.app/jobs/api?limit=100&offset=0 It gives structured minSalary / maxSalary with a currency and period, seniority arrays, location restrictions, and even timezone restrictions as UTC offsets. Dates are epoch seconds, not ISO strings. The normalization layer The row schema that survived contact with all four sources: { "source" : "Remotive" , "title" : "Senior Backend Engineer" , "company" : "Acme Corp" , "tags" : [ "python" , "aws" ], "salaryMin" : null , "salaryMax" : null , "salaryText" : "$120k - $160k" , "location" : "Worldwide" , "postedAt" : "2026-07-03T20:01:13.000Z" , "applyUrl" : "https://..." } Rules that mattered in practice: Keep both salary sh

CAI.com — a custodial @cai .com email, multi-chain stablecoin wallet, and MCP-installable agent API A custodial email, a stablecoin wallet, a credential vault, and an agent-ready API — all at one @cai.com address. This post walks through what CAI is, what you get when you sign up, and how to wire the agent side into any MCP-compatible host. What you get at cai.com/app A free @cai.com email comes with four product surfaces, all under one account: A real inbox at @cai.com . Send and receive mail like any other address. The signup gives you the address; the dashboard gives you the SMTP/IMAP credentials if you want to use a desktop client. A custodial multi-chain stablecoin wallet. Built in. Six chains. External wallets supported. MoonPay for fiat on-ramp (partial-live, third-party KYC and region limits apply — see cai.com/capabilities.html ). A user vault for site credentials. Store website logins and passwords. The agent you build retrieves them when needed, with your explicit confirmation. The vault is for your site credentials, not the agent's API key. An API key for the agent you build or use. Free tier covers read scopes; pay and full scopes may require verification. The key is in the account dashboard. How the signup works The signup at cai.com/app is four steps. About 2 minutes. Go to cai.com/app . Pick "Apply for @cai.com email." Enter your name. That's the only field on the first screen. CAI emails a 6-digit verification code to the address you provide. The code expires in 15 minutes. The email has a one-time link, not the code — copy the code from the email and paste it into the form. Enter the code, create a password, and you're done. At the end you have: A @cai.com email address. A custodial multi-chain stablecoin wallet. A user vault for site credentials. An API key for the agent you build or use. No card. The email is free. The agent side (for the technical reader) For the technical reader, the agent side is the reason to look at CAI. The install is one c

I spent over 20 years working in industrial maintenance as a boilermaker. Most of that time was in refinery shutdowns and turnarounds—high-pressure environments where systems either hold or fail. There is no “mostly working” in that world. That experience has shaped how I approach software development. ⸻ I’m not just “learning to code.” I’m building systems. I’m currently working on transitioning into web development, but I’m not approaching it as a tutorial exercise I’m building real projects from day one—and documenting the process as I go. Not theory. Not exercises. Actual systems that are meant to run. ⸻ What I’m building right now A portfolio site that behaves like a system (kmwebdev.me) This isn’t a “personal website” in the usual sense. It’s a live system under controlled change. I treat it like industrial maintenance work: versioned updates instead of redesigns small, controlled changes only tracking what changed and why stability over aesthetics Nothing gets changed without intent. ⸻ A production-focused email framework (Skeleton Framework) Alongside the portfolio work, I’m building a separate system for HTML email development. Email is one of the most constrained environments in web development. Rendering is inconsistent, standards are partial, and modern CSS support is unreliable across many clients. So instead of fighting those constraints, I’m building a framework specifically designed around them. The focus is simple: predictable rendering in real-world email clients It’s still early, but it’s being developed with production use in mind—not experimentation. ⸻ The way I work hasn’t changed—only the tools have In industrial maintenance, you learn a few hard rules: don’t assume—verify don’t scale chaos don’t change more than you can test document everything that matters So I carry that directly into development: versioned releases (v1.0, v1.3.6, etc.) controlled incremental changes explicit documentation of limitations real-world testing across environmen

Every game jam lives or dies by its theme, and this year's June Solstice Game Jam handed developers something deceptively simple: the longest day of the year. What emerged from that single prompt wasn't a wave of near-identical sunrise simulators — it was a scattershot of genres, mechanics, and emotional registers, all orbiting the same core idea of light and time. One Theme, a Dozen Interpretations The solstice lends itself to more than one reading, and jam entrants leaned into that ambiguity. Some treated "longest day" literally, building puzzle games where a slowly arcing sun becomes a physical obstacle — light that reveals hidden platforms, burns away fog, or casts shadows players must dodge or exploit. Others went abstract, using the solstice as a metaphor for endurance, building narrative pieces about characters pushing through their hardest, brightest, most exhausting day. Sci-fi submissions reframed the concept entirely: distant planets with artificial suns, space stations timing their orbits to a 24-hour light cycle, or crews racing against a ship's failing life-support "day" before darkness means death. Meanwhile, a handful of more grounded, historically-minded entries used the solstice as a backdrop for ritual and tradition, drawing on centuries of human fascination with the year's turning point. Light and Time as Game Mechanics What makes this jam interesting from a design standpoint is how consistently teams turned an atmospheric theme into an actual mechanic rather than just window dressing. Light became a resource to manage, a weapon, a timer, or a stealth tool. Time compression and dilation showed up frequently too — some games squeezed an entire day-night cycle into a five-minute play session, forcing players to make fast decisions as shadows visibly crept across the map in real time. This is a common jam trick: constraints breed creativity. When a 48- or 72-hour deadline collides with a theme built around a literal clock, developers naturally start

wa.me/username doesn't work yet — I verified it two ways, here's what to use instead If you've tried to build a "share my WhatsApp" link using a @username instead of a phone number, you've probably assumed wa.me/username (or wa.me/u/username ) works the same way wa.me/15551234567 does. It doesn't — at least not yet, as of writing this. I wanted a definitive answer instead of trusting blog posts or AI chatbot answers (more on that below), so I tested it two independent ways. Test 1: server response curl -I https://wa.me/u/some_real_reserved_username Every username path I tried — including a certified-real, currently-reserved username — 302-redirects to: api.whatsapp.com/resolve/?deeplink=...&not_found=1 Compare that to the phone-number path, which redirects to: api.whatsapp.com/send/?phone=...&type=phone_number Different resolver, different outcome. The server-side route for usernames exists, but every lookup currently resolves as "not found" — even for real, live usernames. Test 2: real device Server response alone doesn't rule out Universal Links / App Links intercepting the URL client-side before it ever hits a server — curl can't see that. So I also opened all three link variants ( wa.me/username , wa.me/u/username , and a redirect through my own domain) on a real phone with WhatsApp installed. None of them opened a chat. Why this matters if you're building anything around WhatsApp usernames WhatsApp has rolled out @username handles as a real, user-facing feature — but it hasn't published a public deep-link spec for opening a chat from one, the way it has for phone numbers for years. If you're building a tool, a profile page, a business card generator, anything that assumes wa.me/username "just works," it doesn't, for anyone. One more data point: I asked Meta AI directly about this, with the counter-evidence above in hand. It kept asserting the link already works and didn't engage with the evidence when pushed. That's a useful reminder that chatbot answers about

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. Every CS program hammers the same seven into you. Arrays, linked lists, hash tables, stacks, queues, graphs, trees. You could probably recite their Big O complexities in your sleep at this point, and honestly, for 90% of the code you'll ever write, that's plenty. But every now and then a system hits a wall that none of the seven basics can handle gracefully, and someone had to invent a weirder tool to patch the gap. I went down a rabbit hole recently looking at a handful of these, and I liked them enough that I wanted to write them up properly instead of just leaving forty open tabs to rot. Fair warning, there is some depth here. Get a drink. When your hash table can't promise you a fast answer: Bloom filters Normal hash tables are great until you need to ask "have I possibly seen this before" across a dataset way too big to store in memory. Think a crawler checking billions of URLs, or a database deciding whether it's even worth going to disk to look for a row. A Bloom filter solves this by giving up on certainty in one direction. It's a fixed array of bits, plus a small handful of independent hash functions. Adding an item flips a handful of bits on. Checking for an item hashes it the same way and checks whether those same bits are on. If any single bit is off, that item was never added, full stop, no ambiguity. If they're all on, the item was probably added, but two unrelated items can accidentally light up the same bits, so you might get a false alarm. The asymmetry is the entire design. Zero false negatives, occasional false positives. It's the data structure equivalent of a metal detector at a stadium gate. It'll never wave through someone with a knife, but it might beep at your belt buckle and make you empty your pockets for nothing.

TLDR: The most powerful AI on the planet, only a few days of access. Maximize it. I'd first like to give credit where it's due: @trickell - Thank you for sharing Network Chuck's youtube video with me. The reference video is found here guys if you missed it: Network Chuck's Video on Fable I first started by creating a nice template for tech documentation for personal use. It created a beautiful piece of work in about 5 minutes - something I could easily expand on in the future. Here is what it generated for me with after a one or two careful prompts: Clean UI, Easy Navigation! Created this personal reference guide for studying for CCNA (Network Chucks Summer of CCNA) Wanna see it? It lives here: Techdocs But after learning about the true span of Fable's power, I started asking the serious questions, the ones that are life-changing. How can I increase my quality of life based on my resume, experience, and current life circumstances? I wrote about 2 pages of life issues that needed fixing - you know the stuff that slowly eats away at your soul, like student loan debt and people that are challenging to work with? Yes - I told it my biggest issues and instructed it to give me actionable plans that are free or low-cost. Even fable told me that this was a lot. 😅 Getting Organized Knowing the scope of my own problems I knew that my thoughts and processes had to be organized. Luckily for me, I remembered I had a good place to do that. A place that Fable could connect to and place documentation in place for me with checklists, notes, summaries and actionable plans. That app is called Notion, and some of you may have heard of it. No one is going to organize your life for you, no one, except for AI I couldn’t think of a better place for lightning fast critical life-admin documentation on the spot. And I can tell you, this integration works like a charm, and I highly recommend it. For a busy person with a million ideas, this is great. Anxiety Relief I had a tremendous amount of

Is Your Unity Game's Physics a Hidden Bottleneck? Unlock CPU Power with Jobs and Burst Introduction It's 2026, and player expectations for high-fidelity, responsive game worlds have never been higher. Yet, for many Unity developers, the pursuit of complex physics, intricate AI, or large-scale simulations often runs headlong into a critical bottleneck: the main thread. If your Unity game still relies primarily on MonoBehaviour.Update() for computationally heavy tasks like custom collision detection, advanced pathfinding, or sophisticated flocking behaviors, you're inadvertently sacrificing precious frames and player experience. The sequential nature of Update() becomes a severe limitation, preventing your game from fully utilizing modern multi-core CPUs. The solution isn't just an optimization; it's a fundamental architectural shift. Unity's Jobs System and Burst Compiler are no longer esoteric tools reserved for DOTS (Data-Oriented Technology Stack) purists. They are immediate, essential allies for extracting raw, predictable, and highly performant power from your CPU cores. By embracing these systems, you can transform your game's performance, delivering unparalleled fluidity and scalability. Code Layout and Walkthrough: Embracing Parallelism The core problem with MonoBehaviour.Update() is that it executes serially on the main thread. While fine for simple per-frame logic, complex calculations involving many entities quickly become a single-threaded choke point. The Jobs System, coupled with the Burst Compiler, offers a robust alternative. 1. The Power Duo: Jobs System and Burst Compiler Jobs System: This framework allows you to break down heavy computations into small, independent units of work (Jobs) that can be scheduled to run in parallel across multiple CPU cores. It handles the complexities of thread management, allowing you to focus on the logic. Burst Compiler: This incredible technology takes your C# code written for Jobs and compiles it into highly optimi