标签：#dev

zarazhangrui/follow-builders is gaining attention for a simple reason: it focuses on the people building AI systems, not just the influencers discussing them. With 84 new stars today, the project is positioned as an AI builders digest that monitors notable creators across X and YouTube podcasts, then remixes their ideas into shorter, easier-to-scan summaries. That workflow addresses a real productivity problem. AI research and engineering conversations are scattered across long videos, fast-moving social feeds, and repeated announcements. A focused digest can reduce the time spent collecting links while preserving the practical signal: architectural decisions, implementation lessons, tools, and emerging patterns. A sensible first step is to inspect the repository locally before deciding how deeply it fits your workflow: git clone https://github.com/zarazhangrui/follow-builders.git cd follow-builders # Inspect the setup instructions and available scripts ls -la find . -maxdepth 2 -type f | sort | head -80 For an AI-assisted workflow, I would pair the project with a small review loop: Collect the generated digest. Extract claims, links, and mentioned tools. Open the original source before acting on important technical advice. Save durable findings in a project notes file or knowledge base. This keeps summaries useful without treating them as authoritative research. It also makes the tool a good companion for developers using Cursor or another AI IDE: the digest supplies discovery, while the IDE helps turn validated ideas into experiments and code. Before production use, watch for two trade-offs: Summary fidelity: compressed content can lose context, caveats, or disagreements from the original conversation. Source coverage: ranking “top builders” may introduce selection bias, so important perspectives can be missed. The strongest use case is not replacing primary sources. It is building a high-signal starting queue for developers who want to follow AI progress without

Hello, I'm Shrijith Venkatramana, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product. A modern LLM can contain hundreds of billions of parameters, run on extremely expensive accelerators, and still spend most of its inference time doing something that looks embarrassingly sequential: token 1 -> token 2 -> token 3 -> token 4 -> token 5 -> ... That is the awkward part of autoregressive generation. The model may process a whole prompt in parallel during the initial prefill, but once generation starts, the next token depends on the previous token. So generating 100 tokens looks conceptually like running the model 100 times. And for many serving workloads, that is exactly where the money goes. A family of techniques tries to break this bottleneck by asking a deceptively simple question: What if the model could predict several future tokens at once, then verify them in parallel? That idea leads to speculative decoding, Medusa-style multiple decoding heads, and the broader multi-token prediction approach used during training. The interesting part is that these are not merely "optimization tricks." They change the computational structure of decoding. This article develops that idea from first principles and then gets into the engineering details. 1. The problem: your GPU is doing an expensive sequential loop Consider ordinary autoregressive decoding. Given a prompt: The capital of France is the model predicts: Paris Then it feeds the new sequence back through the model: The capital of France is Paris and predicts the next token. Then again: The capital of France is Paris . and so on. Formally, the model factorizes the probability of a sequence as: P(x1, x2, ..., xT) = product over t of P(xt | x1, ..., x(t-1)) That conditional dependence is what makes language modeling so useful. It is also what makes decoding

I ship Codenames AI, a web game. Each game mode keeps its own save in localStorage. Reload the tab,...

Originally published at nlocoding.com 92%of IT leaders say legacy systems slow digital transformation (IBM, 2026) Every minute, a bank somewhere spends $1,200 just keeping 1970s code alive. Not replacing it, just making sure it doesn’t explode. A senior developer at Citi told McKinsey in January 2026: “We spend 53% of our engineering budget patching COBOL.” Legacy code isn’t a quirky artifact anymore. It’s a financial anchor chained to your cloud ambitions... Why AI Code Tools for Legacy System Modernization Matter in 2026 AI code tools have redefined how companies approach system upgrades. In 2026, 61% of modernization projects fail due to manual errors or missed dependencies (Gartner, 2026). You can’t afford human error when one typo in ancient assembler code can cost $500,000 in downtime. The rise of generative AI for code refactoring is the only thing standing between you and a multi-million dollar rewrite. AI Code Tools Are Slashing Modernization Timelines by 63% AI code tools for legacy system modernization have cut modernization project timelines by 63% on average (Accenture, 2026). Manual migration can take 18 months—AI-powered tools like IBM watsonx Code Assistant and Google Gemini Advanced do it in under 7 months. This isn’t a hypothetical. Banco do Brasil migrated 2.8 million lines of COBOL to Java in 2025 with Cognizant’s AI tool; downtime: 14 hours. Average cost per line dropped from $3.60 (human) to $1.15 (AI-assisted). 💡 Pro Tip: Start with small pilot modules (1000-5000 lines). Measure defect rates before scaling. AI-Assisted Code Understanding Reduces Failure Rates Code comprehension is the single biggest risk in legacy system modernization. 47% of failures in 2026 were due to “unknown dependencies” (Forrester, 2026). AI code tools now map data flows, detect dead code, and generate architectural diagrams from raw source. Microsoft’s Copilot for Azure can parse 1.5 million lines in two days and flag 96% of “code rot” blocks. One insurance company in

OpenHabitTracker is a free, open source habit tracker that also holds your notes and tasks. It runs on Windows, Linux, macOS, iOS, Android and in a browser, with no ads and no account. Filtering and sorting habits A habit here is not measured by a streak. It is measured by how much of its interval has gone by. A habit you want to do every ten days, two days late, is at 120%. A habit you want to do every four days, also two days late, is at 150%. Because that is a number, you can filter on a range of it: only habits above 50%, only habits below 150%, or only the ones in between. That last one is everything neither freshly done nor badly overdue. You can sort by it as well, and the sort takes the repeat count into account, so a habit done three times a day and one done weekly are compared against each other rather than the daily ones always sitting on top. There are other ways to sort habits by time: how long you want between repeats, how long it has actually been averaging, how long since the last one, and how much time you have spent on it in total or per completion. Notes and tasks sort by the plain things, category, priority and title, and tasks also by their planned date and duration. Each of the three keeps its own sort order. Filtering by date Tasks have a planned date. Tasks and habits have the dates they were completed on. Both are filtered separately, each before, on, after or not on a date you pick. A filter can also take a number of days from today instead of a date. Minus seven to plus seven is the week either side of now, and it still means that in a month, because the days are counted at the moment you look rather than the moment you set it. Showing what was not done The completed-date filter has a switch next to it. Turned on, the range shows what you finished in those days. Turned off, the same range shows what you did not. Searching notes, tasks and habits Searching a note searches the whole note, not just its title. Searching tasks and habits search

We're back with another DEV Weekend Challenge, a short bite-sized challenge planned to fit into your...

Refactoring Safely: A Step-by-Step Guide We all know that feeling: a function that's 200 lines long, a class that does too many things, or a variable named data2 . Refactoring is the cure, but doing it recklessly can break your app and your confidence. Here's how I approach refactoring safely, step by step. 1. Start with a Safety Net Before touching any code, make sure you have tests. If your project lacks tests, write a few key ones first. Focus on the behavior you're about to change. The goal is to have a safety net that tells you when you've broken something. # example test for a function we'll refactor import unittest from mymodule import calculate_total class TestCalculateTotal ( unittest . TestCase ): def test_with_discount ( self ): self . assertEqual ( calculate_total ( 100 , discount = 0.1 ), 90 ) If tests aren't feasible, at least have a manual checklist. But automated tests are worth the effort. 2. Make Small, Atomic Changes Don't try to refactor everything at once. Pick one logical change. For instance, extract a method or rename a variable. Each change should be small enough that if it breaks, you know exactly what caused it. // before function processOrder ( order ) { const total = order . items . reduce (( sum , item ) => sum + item . price , 0 ); const tax = total * 0.08 ; const final = total + tax ; return final ; } // after step 1: extract tax calculation function processOrder ( order ) { const total = order . items . reduce (( sum , item ) => sum + item . price , 0 ); const final = total + calculateTax ( total ); return final ; } function calculateTax ( amount ) { return amount * 0.08 ; } Run your tests after each tiny step. If they pass, move on. If they fail, you know the last change caused it. 3. Use Your IDE's Refactoring Tools Modern IDEs can rename variables, extract methods, and change signatures safely. They update all references automatically. This reduces human error. For example, in VS Code, right-click a function and choose "Extract to

A tool claiming "up to 15x faster than cdk deploy" showed up in my feed a while back. Drop-in replacement, it said: keep your CDK app exactly as it is, just swap cdk deploy for cdkd deploy . I've learned to be skeptical of "Nx faster" claims. So I actually deployed something real to AWS with both tools and timed it. Short version: it really is that fast. What cdkd actually is cdkd deploys an existing AWS CDK app without going through CloudFormation. It calls the AWS SDK directly instead. It's built by go-to-k (Kenta Goto), an AWS DevTools Hero and CDK top contributor who also maintains cls3 (a fast S3 bucket emptier) and delstack (for cleaning up stuck CloudFormation/CDK stacks) — tools that quietly fix the annoying parts of working with AWS. cdkd feels like the biggest one yet, and I mean that as a compliment grounded in actually using it, not a throwaway one. The mechanism is straightforward. cdkd runs the exact same CDK synth step as the CDK CLI, producing the same CloudFormation template. What changes is everything after that: instead of handing the template to CloudFormation, cdkd's own engine reads the resource dependency graph ( Ref , Fn::GetAtt ), builds a DAG, and fires AWS SDK / Cloud Control API calls directly, in parallel, as soon as each resource's dependencies are satisfied. Worth saying up front: cdkd calls itself not production-ready, dev/test only. This isn't a "replace CloudFormation in prod" pitch. I actually ran both, on real AWS cdkd's own README backs up the 15x number with a VPC + Lambda + SQS + CloudFront benchmark. So I wrote that same stack as a CDK app and deployed it twice — DeployRaceCfn via cdk deploy , DeployRaceCdkd via cdkd deploy — to the same AWS account, same region (ap-northeast-1). The stack: VPC (2 AZ + NAT Gateway) with a Lambda inside it, fronted by a Function URL CloudFront, origin set to that Function URL SQS + EventSourceMapping + a consumer Lambda First attempt failed. The account had hit its VPC limit (five, the default)

A green required check is not a merge decision. It is a signal that one job graph finished without a red X. If a pre-push hook was skipped, or a snapshot fixture was regenerated without a reason, you can still ship a lie. This article walks through a merge packet: a small JSON artifact your CI publishes next to the check. The packet records hook results, fixture drift, and required-job status. A model may write the eight-line brief. It does not get a vote. Why green still lies CI dashboards collapse many facts into one glyph. You see green. You click merge. You miss three common failures. First, someone pushed with --no-verify and skipped the hook that keeps fixture hashes honest. Second, a test helper rewrote golden files because a serializer added a field. Third, a retry job went green on the second attempt and nobody recorded that the first attempt failed. You do not need a platform rewrite to catch this. You need a contract the merge button cannot ignore. Cheap code generation makes the second failure more common. When it is easy to regenerate tests, it is easy to regenerate the fixtures those tests pin. The pin becomes a moving target. Treat unexplained fixture diffs as merge blockers, the same way you treat a failed unit job. What the merge packet contains Keep the packet boring. One file. One schema. Commit it as a CI artifact, not as a comment that can be edited after the fact. { "commit" : "REPLACE_WITH_SHA" , "generated_at" : "2026-09-03T00:00:00Z" , "hooks" : { "pre_push_fixture_guard" : "passed" }, "fixtures" : { "manifest_path" : "tests/fixtures.sha256" , "changed_paths" : [], "unexplained_paths" : [] }, "required_jobs" : [ { "name" : "unit" , "conclusion" : "success" }, { "name" : "contract" , "conclusion" : "success" } ], "merge_ready" : false , "brief" : null } merge_ready is computed by a script you own. Not by a prompt. The brief is optional prose for humans who will not open the JSON. Step 1: Pin fixtures with a manifest Pick a directory you alrea

I recently built a complete IT ticket management system in Power Apps — 9 screens, role-based access, live SLA tracking, and automatic email notifications. The part I want to actually talk about here isn't the UI, it's the SLA engine, because I built it to work without Power Automate , and the trick is simpler than it looks. The problem SLA tracking normally means: a ticket is "Critical" → 60 minute target → somebody needs to know if it's about to breach or already has. The obvious way to do this is a scheduled Power Automate flow that checks every ticket on a timer and flags the ones in trouble. I wanted this app to run on Power Apps collections only — no flow, no external data source — so a scheduled flow wasn't an option. The question was: can you get "live" SLA status without a background job? The trick: recalculate on every read, not on a timer Instead of a flow updating a SLAStatus field periodically, I recalculate it every time the app or a screen is opened, using Now() against the stored due date: \ UpdateIf( colTickets, Status <> "Resolved" && Status <> "Closed", { SLAStatus: If( Now() > DueDate, "Breached", DateDiff(Now(), DueDate, TimeUnit.Minutes) <= SLAMinutes * 0.2, "At Risk", "On Track" ) } ); UpdateIf(colTickets, Status = "Resolved" || Status = "Closed", {SLAStatus: "Met"}) \ \ This runs in App.OnStart , at the top of every screen's OnVisible , and behind a manual "Refresh SLA" button. The At Risk threshold is 20% of the SLA window remaining — so a Critical ticket (60 min target) goes At Risk with 12 minutes left; a Low ticket (1440 min / 24 hrs) goes At Risk with 4.8 hours left. The honest tradeoff: this only updates when someone has the app open. A ticket breaching at 2am with nobody looking won't trigger anything until the next visit. For a real production deployment I'd pair this with a scheduled flow for after-hours detection — but for a demo, an internal tool with regular traffic, or anything where "eventually consistent within the next visit"

Design engineers increasingly work across two systems: the visual language of a product and the implementation details that make it usable. Skills for Design Engineers from ibelick focuses on that overlap, packaging practical guidance for building interfaces with stronger visual quality, clearer interaction patterns, and more consistent engineering decisions. The project is attracting attention, with +46 stars today . That momentum makes sense: design-focused AI workflows are moving quickly, but many generated interfaces still need human judgment around spacing, typography, responsive behavior, accessibility, and component reuse. The useful way to approach this project is not as a drop-in framework. Treat it as a reference layer for your development workflow. Read the relevant skill instructions, adapt them to your stack, and keep the resulting guidance close to the codebase so it can be applied consistently during implementation and review. A lightweight local setup might look like this: mkdir -p .ai/skills/design-engineering curl -L https://github.com/sponsors/ibelick \ -o .ai/skills/design-engineering/reference.html For a real team workflow, I would convert the useful parts into a checked-in Markdown file: .ai/ └── skills/ └── design-engineering/ ├── interface-quality.md ├── responsive-layouts.md └── review-checklist.md This keeps the process portable across editors and AI assistants instead of tying it to one tool. It also makes design decisions reviewable in pull requests, which is more valuable than keeping them inside an undocumented prompt. Before using the approach in production, watch for: Context drift: generic design guidance can conflict with an existing design system, so define project-specific tokens and component rules first. AI overconfidence: generated UI still requires manual checks for accessibility, keyboard navigation, mobile behavior, and performance. The strongest ROI comes from using these skills as repeatable engineering standards—not as a

Most hackathons ask you to build whatever you want. Dogfood 2026 does the opposite. Everyone builds the same thing: a submission and judging platform for hackathons. The challenge is simple: Build the platform that will judge you. And there is a reason this is more interesting than it sounds. Hackathon Raptors has run 35 hackathons across 85+ countries since 2023. They have seen the same problems appear again and again: registrations, teams, submissions, judge assignments, scoring, normalization, results, certificates, and exports all becoming separate pieces of an increasingly messy workflow. Now they want to build the platform they actually wish they had. That is what Dogfood is about. About the Hackathon Dogfood 2026 is a 72-hour online hackathon organized by Hackathon Raptors . The event runs from September 25 to September 28, 2026 . At a glance 🌍 Online and global ⏳ 72 hours 💰 $2,500 prize pool 👥 Solo or teams of up to 4 💸 Free to participate 🔓 Open source 🐳 Self-hosted 🛠️ Build with the stack of your choice But this is not a normal platform-building challenge. The winning project is intended to be forked, self-hosted, and used for actual Hackathon Raptors events. So instead of building a demo that gets abandoned after the weekend, you are building something that could become real infrastructure. Why Build Another Hackathon Platform? Hackathon platforms already have most of the features organizers expect. Registration. Team formation. Project submissions. Public galleries. Judge scoring. Community voting. Organizer dashboards. CSV exports. So what is missing? The difficult part is not building another CRUD application. The difficult part is making the entire system reliable when real people start using it. Consider judging. Two judges can look at the same project and give completely different scores. One might give almost everything a 4 or 5. Another might rarely give anything above a 3. Simply averaging those scores can produce a ranking that reflects the judg

Ever wondered what's happening right now on a beach in Mexico, in Red Square, or at a harbor in Norway? I run Cam-World — a free live webcam aggregator that pulls together 7,000+ public streams from 100+ countries into one searchable place. No registration, no paywall. Here's a tour of what's inside and a few things I learned along the way. 🗺 The world map is the product The heart of the site is a dark globe where every green dot is a live camera. Click a cluster, zoom into a city, open a stream — you never leave the map. Watching it for a while teaches you something: the planet has a rhythm. Webcams go online with the morning sun, and the "online" wave rolls west around the clock. 📊 Honest uptime — you can tell a dead cam from a live one Aggregators usually show you a thumbnail and pray. We check every camera automatically and show a statistics widget: the last 24 hours and 30 days as color-coded slots (online / outage / offline / no data) plus an uptime percentage. The lesson here: webcams are ephemeral. Streams die, hotels turn off cameras, storms break them. Honest stats became our most-loved feature — users check reliability before clicking play. 🔎 Search, cities, collections Search works by name, city, country and tags. There are dedicated hubs for countries and cities, and themed collections: beaches, traffic, mountains, northern lights. 🌙 Small things that matter Dark & light themes (night couch-travel vs daytime browsing), 20 interface languages, "Near me" sorting by distance, live online/offline badges on every card. Try it 🗺 World map — pick a dot, watch live 🔎 Search — find a place you love 🏠 Home feed — a rotating mix of live cameras It's free, works on mobile, and there's always something happening somewhere. What would you check first — a beach, a mountain, or your own hometown square? 👇

Dynamic rendering in Angular sounds like a fairly narrow technical problem: “I don't know which component I need until runtime.” Angular already gives us several good tools for that. But there is a big difference between dynamically choosing a component and dynamically constructing an entire UI from a runtime specification. And that difference becomes especially important with Server-Driven UI and Generative UI. 1. ngComponentOutlet : when the problem is really just component selection For simple cases Angular already gives us: <ng-container *ngComponentOutlet= "componentType" /> This works very well when the application already knows its possible components and runtime logic only decides which one to display. componentType = condition ? UserCardComponent : AdminCardComponent ; The advantages are obvious: very little infrastructure, normal Angular lifecycle, AOT-compatible components and a relatively declarative template. But this approach starts becoming uncomfortable when the runtime input is no longer: UserCardComponent and instead becomes: { "type" : "Card" , "children" : [ { "type" : "Input" , "props" : { "label" : "Name" } } ] } Now we are no longer selecting a component. We are interpreting a UI description. 2. ViewContainerRef.createComponent() : more control, more responsibility Angular also allows components to be instantiated programmatically: const ref = viewContainerRef . createComponent ( componentType ); ref . setInput ( ' label ' , ' Name ' ); This is a powerful primitive. We control where the component is created, which component is used, how inputs are assigned and when the component is destroyed. For relatively contained dynamic behavior, this can be exactly what we need. But once a runtime specification controls many components, application code often starts evolving into something like: switch ( node . type ) { case ' input ' : ... case ' select ' : ... case ' button ' : ... case ' dialog ' : ... } Then we add input mapping. Then events. Then ne

There is a strange contradiction happening in software engineering right now. A lot of developers are worried that AI is going to make them obsolete. At the same time, the people building the most capable AI coding tools are demonstrating something that should probably make us rethink what being a software engineer actually means. I don't think the future is one where nobody understands software anymore. I think it is one where writing the software becomes dramatically cheaper. And if that happens, the thing that makes an engineer valuable has to move. That is what I mean by career safety. Career safety isn't about making yourself impossible to replace. It is about making your value portable. We've always resisted giving up the code Developers have a long history of being suspicious of abstractions that take work away from us. We went from machine code to assembly, from assembly to higher-level languages, from manually managing memory to garbage collection, from building everything ourselves to libraries and frameworks, and from text editors to IDEs. We even had entire categories of tools, such as CASE tools, designed to automate parts of software development. And every time, there was resistance. Because programmers don't just use code. We build our identities around it. John Carmack captured this unusually well when he wrote: “Coding” was never the source of value, and people shouldn’t get overly attached to it. — John Carmack He followed that with the more important point: Problem solving is the core skill. — John Carmack That is a difficult idea for developers to internalize because coding is tangible. You can point at the repository. You can point at the pull request. You can count the commits. You can say, "I wrote this." But the business doesn't ultimately pay you for the number of lines you wrote. It pays you for what those lines accomplish. The business never really bought the code A company doesn't wake up in the morning thinking: "We need 14,000 more line

Moving a Next.js app off Vercel and onto a plain Ubuntu VPS usually starts with a painful realization: either your serverless functions are timing out on background jobs, or your client just handed you a strict "you must host this on our infrastructure" requirement. Deploying the app itself is easy. What trips people up (and what cost me hours of debugging and locking myself out of my own server) is everything around the app. Here are the 12 things that actually break when you leave the serverless ecosystem, in the order you'll hit them. 1. Next.js needs a process manager, not just npm start Running npm start in a terminal dies the moment you disconnect. You need something that keeps the process alive, restarts it on crash, and survives a reboot. PM2 is the simplest option for a single-server Node deploy. npm install -g pm2 // ecosystem.config.js module . exports = { apps : [{ name : " my-app " , script : " node_modules/.bin/next " , args : " start " , cwd : " /var/www/my-app " , instances : 1 , exec_mode : " fork " , autorestart : true , max_memory_restart : " 512M " , env : { NODE_ENV : " production " , PORT : 3000 }, }], }; cd /var/www/my-app && pm2 start ecosystem.config.js pm2 save pm2 startup systemd -u YOUR_USER --hp /home/YOUR_USER That last line is the one people forget - without it, PM2's process list doesn't survive a server reboot. 2. Nginx needs to proxy to the port, not serve the files Next.js is not a static site (unless you've explicitly exported it as one). Nginx's job is to forward requests to the Node process, not serve files from disk: upstream nextjs_upstream { server 127.0.0.1 : 3000 ; keepalive 64 ; } server { listen 80 ; server_name example.com www.example.com ; location / { proxy_pass http://nextjs_upstream ; proxy_set_header Host $host ; proxy_set_header X-Real-IP $remote_addr ; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ; proxy_set_header X-Forwarded-Proto $scheme ; # WebSocket support - required for HMR and any realtime f

pnpm 12 has transitioned to a native Rust implementation, maintaining compatibility with pnpm 11 commands, flags, and formats. This update enhances startup and filesystem performance, particularly when using existing caches. Community feedback highlights the performance gains while noting some trade-offs in larger artifact sizes. By Daniel Curtis

Most "AI coding" products still put a chat window next to your editor and call it a day. I wanted something closer to what Claude Code already does well on a server: give it a real computer and let it drive. Superagent is a Mac app that gives Claude Code (or any agent you point it at) an actual environment to work in, not just a text box. Concretely: A real browser it can navigate, click, type into, and read the DOM of, not screenshots and guesses. An iOS Simulator window it can install apps into, tap through, and screenshot to verify UI changes. A relay that pairs your Mac with your phone, so the agent can keep working (and you can keep watching) from your pocket. The core idea is boring on purpose: don't build a smarter chat window, build a better place for the agent to act. Most of the interesting failures I hit while building this weren't in the model, they were in the environment: synthetic file inputs that don't persist through a web form's upload component, elements that exist in the DOM but aren't in the accessibility tree, simulator state that drifts from what a screenshot shows. Fixing those is what actually makes an agent reliable to hand a task to. It's built as three pieces: an Electron desktop app, a SwiftUI iOS companion, and a small Cloudflare Worker relay that pairs the two with per-address rate limits so a lost phone can't be used to spam a stranger's Mac. If you want to see it: https://peerlist.io/pungme/project/superagent-for-mac Happy to answer questions about the browser automation approach, the simulator driving, or the relay's pairing/security model in the comments.

The idea Every OS ships a calculator. Every one of them looks the same, feels the same, and disappears from memory the moment you close it. So I built ACALCU v3 — an Akhouri Systems product — a scientific calculator that's absurdly, unnecessarily customizable. Not because a calculator needs 30+ themes and per-button styling, but because it was a fun constraint to design around: how far can you push a "boring" utility app before it becomes something people actually enjoy using? What it does At its core, ACALCU is a standard scientific calculator: basic arithmetic, sin, cos, tan, log, √, π, percentages, and a running expression engine built on Python's math module. On top of that core, it layers: 30+ built-in themes — Royal, Liquid Glass, Wild, Cyberpunk, Dracula, Nord, Solarized, Monokai, Windows 7 / Vista / 10, OneUI 8.0, Matrix, Rose Gold, Galaxy, Fire, Ice, Neon, Vintage, Sakura, Midnight, Forest, Candy, Terminal, Gold Dark, and more. Per-button customization — right-click any button to change its color, font, or set a custom image/video as its background. Every button on the grid is independently styleable. A live "Wild" theme — a small animated plant widget that visibly grows every time you run a calculation. Calculation history — a scrollable dialog of your last 50 calculations. Persistent config — every customization is saved to a local JSON file and reloaded on next launch. Full keyboard support — number keys, operators, Enter/Escape, all mapped to the same input pipeline the buttons use. Architecture The whole thing is a single-file PyQt6 desktop app, structured around a few core pieces: python THEMES = { "DEFAULT": { "app_bg": "#0a0a0a", "display_bg": "#111111", ... }, "ROYAL": { "app_bg": "#0a0800", "display_fg": "#ffd700", ... }, "LIQUID_GLASS": { "app_bg": "transparent", ... , "transparent": True }, # ...30+ more } Each theme is just a dict of colors, font, corner radius, and optional flags (transparent, wild). The Config class resolves the active theme

There is a category of defect that cannot appear in your acceptance criteria. Not because nobody thought of it, but because the shape of a requirement has no room for it. A requirement describes a state and a rule. A customer can apply a valid promo code at checkout. State: the code is valid. Rule: it is accepted. Both are evaluated at a single instant, because a sentence has one tense. Real systems do not have one instant. They have two, and sometimes a lot more. The gap between checking and using Take that promo code. The system validates it when the customer types it into the basket. The system commits it when the customer pays. Between those two events sits an unbounded amount of time — thirty seconds if they have their card handy, three days if they leave the tab open on a laptop lid. If the code expires in that gap, what happens? The requirement cannot tell you. It never contemplated a gap, because it was written as one sentence about one moment. And a test written by hand almost certainly cannot tell you either, because a person writing a test naturally writes it the way they would perform it: enter code, assert accepted, pay, assert charged. Three lines, one instant, no gap. This is time-of-check to time-of-use. Most developers first meet it as a security problem — access() then open() , and a symlink swapped in between. The same shape appears at business timescale, and there it is far more common and far less discussed: Stock is reserved at basket, decremented at dispatch. Someone else buys the last one. A permission is checked when the page loads, enforced when the action fires. The role changed. A price is quoted at quote time, charged at renewal. The tariff moved. A rate limit is checked at admission, consumed at execution. The window rolled over. A feature flag is read at session start, branched on at submit. Someone flipped it. A token is validated at the gateway, used by a downstream call. It expired in flight. Every one of those is a real defect clas