标签：#EV

This is a submission for Weekend Challenge: Generosity Edition What I Built Handover takes a plain description of what is going wrong inside a small charity and works out the role that would fix it. Not the role they asked for. The one they actually need. You type something like "our books are a mess, and we have missed two filing deadlines". It comes back with a full trustee role: the diagnosis, what the person would do, a deliberately short list of essential skills, an honest time commitment, and an advert you can paste straight into your newsletter. Then a volunteer pastes their CV, badly, and gets scored against every open role with a reason and an honest note on where the fit is thin. Why A couple of days ago I got an email saying Reach Volunteering is closing after 45 years. It genuinely hurt to read. Reach connected small UK charities with people who wanted to give them professional skills. Last year it placed 5,996 volunteers and trustees across 2,440 organisations. The people it placed contributed around £60 million in expertise. Ninety-six per cent of those organisations ran on under £1 million a year, and nearly half on under £50,000. It is not closing because the work stopped mattering. It is closing because funding for the infrastructure that helps small charities build capacity has dried up. Reach was the largest single source of trustees in the sector, and it is shutting at the peak of its impact. I volunteer as a digital navigator, which mostly means sitting with people who have been handed a system that assumes a confidence nobody ever gave them. You watch someone decide they are the problem, when the thing in front of them was just badly built. Reach existed to stop small charities from feeling like that about their own gaps, and now it is shutting down. I cannot rebuild 45 years of relationships in a weekend. So I picked the one piece of what Reach did that was pure expertise rather than headcount, and rebuilt that. The thing everyone gets wrong E

This is a submission for Weekend Challenge: Generosity Edition What I Built Karibu Give (Swahili for Welcome, Give ) is a USSD micro-donation platform that works on a kabambe phone(feature phone) with no data, no app, no account , just a phone number and a mobile-money PIN. Built for the International Day of Charity. Two things stop generosity from scaling in Kenya and across Africa: You need a smartphone to give. Most donation platforms are web-forms that assume Chrome, data bundles, and card rails. 40% of Kenyan adults still use feature phones. You need trust to give again. Donations disappear into a black box. Donors never see where 50 KES actually went. Karibu Give attacks both: Dial *384*6120# → 1. Donate → Pick a cause → Enter 50 → Confirm → M-Pesa STK prompt in 2 seconds. No internet, no app store, no signup. Session state is managed server-side via sessionId (Africa's Talking USSD callback at POST /ussd ). Real M-Pesa money movement — STK Push is triggered via my dedicated M-Pesa Service https://mpesa-service-3s2d.onrender.com/stkpush , which wraps Daraja API ( POST {phone:"2547...", amount} → CheckoutRequestID:"ws_CO_..." ). SQLite = source of truth, Snowflake = audit trail — every pending → completed/failed transition via POST /payment-callback ( Body.stkCallback.CheckoutRequestID Daraja shape + AT shape) is synced to DONATIONS_ANALYTICS in Snowflake with phone_hash = SHA256(phone).slice(0,16) , never raw PII. POST /admin/sync-snowflake batch-retries unsynced rows. Only 3 causes can be active at a time — admin ( /admin behind ADMIN_USER/PASSWORD Basic Auth) creates charities ( name, emoji, target_amount, description ), toggles active, edits, deletes (blocked if donations exist). USSD and landing page render only active causes , so the choice stays focused. The limit is enforced in SQLite ( countActive()<3 ) and in the UI ( Activate disables at 3/3). Two separate AI cards — not one bolted-on feature: ✨ Google AI Impact Summary (Gemini 1.5 Flash via @google/

This is a submission for Weekend Challenge: Generosity Edition What I Built GlassPocket — a tool that argues against the "overhead ratio," the dominant heuristic people use to judge charities (what % of donations go to "programs" vs. "overhead" like staff and infrastructure). That heuristic punishes exactly the investment that makes a charity effective, and it drives what nonprofit finance people call the "starvation cycle" — orgs under pressure to look lean end up under-staffed and under-resourced. You search a US 501(c)(3), and instead of a single overhead percentage, GlassPocket pulls their IRS Form 990 history (via ProPublica's Nonprofit Explorer API) and shows: Reserve months — how long the org could run on savings alone (low reserves = fragile, not "lean") Operating margin trends across up to 13 years of filings Staff-investment share — reframed as capacity, not waste Fundraising cost per dollar raised — a narrower, more honest efficiency metric than the classic ratio A peer-percentile chart against ~70 similar organizations in the same category A Gemini-written "myth-buster" card pairing each overhead-ratio assumption with what the numbers actually show A grounded chat box — ask follow-up questions about that specific org's finances, answered only from its own filing data Demo Live app: https://glasspocket.vercel.app/ Code hassan-2050 / glasspocket Overhead-ratio myth buster for US charities — Form 990 data via ProPublica, Gemini narrative generator GlassPocket — Overhead Myth Buster Live: glasspocket.vercel.app Category: Overall Winner + Best Use of Google AI (Gemini-powered narrative generator and chat) The Hook Most charity-rating tools reinforce the harmful "overhead ratio" myth. This contrarian tool argues against that dominant heuristic by reframing efficiency around outcomes and reserves. What It Does You search a US charity by name, and it pulls their IRS Form 990 history to generate a plain-English context-aware financial explainer that debunks the o

Hi, my name is Yaniv Morozovsky, and I have worked in the radio industry for more than three decades. Most of that on SAM Broadcaster and, lately, AzuraCast. On 13 July I did something I had wanted to try for a long time: I handed one of my internet stations to automation completely, with nobody in the studio, and did not touch it. It is still on air today: https://ystream.live Some honest notes for anyone who runs a station and has wondered about the same. Segues are the whole game. The thing that makes automation sound like a jukebox is the fade timer. Every song fading at the same point, every cold ending faded when it should stop dead. What fixed it was analysing every song once (intro end, vocal entry, outro, the real ending) and crossing on those points per song. Once that was in, listeners stopped noticing there was no one there. Making an automated station sound like a DJ is mostly making the crossfades right, and that was our biggest achievement from day one. The voice matters less than where it lands. I cloned my own voice for the breaks, and honestly the voice itself is not what people comment on. What they hear is whether the talk-up ends before the vocal. When it lands, it sounds like radio. I let the AI DJ open every hour, read the weather, and in the last week also read a short news segment when the hour begins. Scheduling by rules beats scheduling by clocks, most of the time. Key, tempo, energy, era, genre, artist separation, and a few written rules like "start every hour with an international song". The hour writes itself and I stopped building clocks. What I gave up was the twenty years of Clockwheel habits, and there were days I missed them. Some of the most annoying bugs of automation software, like repeating the same song over and over, or playing the same artist twice in the same hour, are all gone. The boring parts decide whether you can actually broadcast. Royalty reports, listener stats per song, loudness that holds across a 1975 master and

Originally published on angeo.dev . Full tables, p-values and the sealed plan are there. Most claims about AI visibility are untestable by design: publish the signals, wait, attribute anything good that happens to the signals. I wanted a version I could not fudge, so I wrote the analysis plan first, hashed it, and sent the hash to the other party before I had any data. The question Do businesses AI assistants name repeatedly differ, on observable technical signals, from businesses the same assistants name once ? Every business in the corpus was named at least once, so this says nothing about how to enter an answer. It compares repeat against one-off mentions inside a named-business corpus. Four signals, all externally observable: Signal Check Crawler access Does robots.txt block any of 8 AI crawlers Content map Does the site serve /llms.txt Structured data Does a product page emit JSON-LD Product Buyability Does that node carry offers.availability Study setup The answers came from a partner (connexion.me), who ran 44 product-level home-decor buying questions across ChatGPT, Gemini and Perplexity, twice, in two arms — 264 answers per arm. Blinding was deliberate. I did not write the questions and did not see their store list until my plan was sealed; they never saw my frame, my scan results or my thresholds. Roster rows 669 no resolvable domain -186 resolved to a different company -3 marketplaces and listing surfaces -12 duplicate rows collapsed -10 Unique domains analysed 458 scanned successfully 455 Cases: 3+ mentions across both runs and present in both. Controls: exactly one mention across both runs. Head excluded first — anything in 53+ of 264 answers (Amazon, Etsy, Wayfair, Target, Home Depot). The pre-registration Sealed 10 August, SHA-256 9b4ccf12629e… : Under 15% of named businesses would be Magento No signal would separate the groups by more than 15 points Refutation condition: any signal differing by 20+ points with the named group higher Result — generic

This is a submission for Weekend Challenge: Generosity Edition What I Built I grew up teaching myself to code in Pakistan on hardware that struggled to run modern dev tools. GPU hours on Lambda Labs cost $0.50–$3/hr. For a student trying to fine-tune a model or run a training job, that's not accessible. OpenRig is a peer-to-peer compute sharing platform. Donors register their idle hardware and run a lightweight agent binary. Recipients describe what they need in plain English, get matched to the best available rig via Google Gemini AI, and receive SSH access — time-limited, isolated, and without ever touching the donor's actual machine. No money changes hands. You're donating the thing that actually matters: compute. Demo Here is the video link Full flow: Donor registers their rig → copies agent token → runs the agent binary Recipient browses available hardware → submits a request explaining why they need it Gemini scores the request 1–10 for social/educational impact Donor sees the impact score and reason → clicks Approve Agent spins up an isolated Docker container with SSH, starts a bore tunnel, reports the public connection command back to the backend Recipient gets an SSH command and password in their dashboard → connects Donor can revoke access at any time → container and tunnel torn down automatically Code Here is the code: OpenRig How I Built It The stack Backend: Go + Fiber v3, SQLite (GORM) Frontend: SvelteKit + Tailwind CSS Auth: Supabase (JWT verified on the backend via JWKS) AI matching: Google Gemini 3.6 Flash via Google Gen AI Golang sdk Tunneling: bore (open source TCP tunnel) Isolation: Docker with hardened security flags The hardest problem: giving strangers SSH access without exposing the donor's IP The naive approach — direct SSH — exposes the donor's home IP to whoever connects. That's a non-starter. The solution is a relay architecture. The donor's agent binary runs on their machine and maintains a persistent poll loop against the backend. When

## Why I built this Checking URLs one at a time during a site migration or relaunch is tedious, and the tools that do it in bulk for free — Ahrefs, SEMrush, Screaming Frog — gate that behind a paid plan. So I built Bulk URL Checker for ForgePlug : a free batch URL checker that handles up to 100 URLs per run, no account required. What it does Check status codes, full redirect chains, and response latency for up to 100 URLs at once Three ways to feed it URLs: paste directly, upload a CSV (auto-detects the URL column), or parse a sitemap Follows up to 20 redirect hops, recording the status code and Location header at each step Streams results in real time as each URL finishes, instead of making you wait for the whole batch Export as a formatted text report or properly-escaped CSV Built with SSRF protection from the ground up Since it fetches arbitrary URLs server-side, every redirect destination is validated against private IP ranges (10.x.x.x, 192.168.x.x, 169.254.169.254) before it's followed — so it can't be tricked into hitting internal infrastructure. No URLs are stored; everything lives only for the active session. Details Runs server-side (Node.js) with a concurrency pool of 10 simultaneous requests. Free tier caps at 100 URLs per run — a commercial plan is planned for unlimited batches, scheduled re-checks, and branded reporting. Try it: https://www.forgeplug.com/tools/bulk-url-checker Would love feedback, especially from anyone running site migrations or link audits.

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 language model can write Python, explain quantum mechanics, and imitate Shakespeare. Show it a screenshot of a production dashboard, however, and suddenly the central question becomes: How does a transformer that was trained on text learn what a pixel means? The naïve answer is: “Give the image to the LLM.” That description hides almost all of the interesting engineering. Modern multimodal systems are usually compositions of several models: a vision encoder turns pixels into vectors, a connector translates those vectors into something the language model understands, and the LLM then reasons over the resulting representation alongside ordinary text tokens. That architectural trick has turned the transformer from a language architecture into something much closer to a general-purpose interface for heterogeneous data. The evolution is worth understanding because it reveals a useful engineering pattern: you often do not need to retrain a giant model to give it a new sensory modality. You need a good representation and a sufficiently expressive interface between representations. 1. The basic mental model: pixels become tokens Start with an ordinary LLM. Its input looks conceptually like: "The server returned HTTP 500. What should I check?" | v tokenizer | v [t1, t2, t3, ..., tn] | v Transformer | v answer Everything is eventually represented as vectors. Multimodal transformers exploit this fact. An image is first converted into a sequence of vectors: image | v vision encoder | v [v1, v2, v3, ..., vm] | v multimodal connector | v [z1, z2, z3, ..., zk] | +------ text tokens [t1, t2, ...] | v LLM | v answer The important conceptual shift is this: The LLM does not have to understand pixels directly. It only has to understand

The cloud bill is the only number in most companies that nobody on the team owns until it's already a problem. Engineering owns latency. It owns error rates, p99, uptime, the whole observability wall. Finance owns the invoice. And between those two ownerships there's a gap wide enough to drive a fifth to a third of your cloud spend straight into a wall — which, across the industry, is roughly what happens. The fix isn't a smarter spreadsheet at month-end. Real cloud cost management isn't an accounting function at all — the fix is to stop treating the bill as accounting and start treating it as a product metric: cost per request, cost per tenant, cost per feature, sitting on the same dashboard as latency and error rate, owned by the same people who own those numbers. That's the whole argument. The rest of this post is why it's true and how it's done. The bill is a lagging accounting artifact, and that's the bug Here's how cloud cost is treated almost everywhere. A bill arrives. Someone in finance reconciles it against a budget. If it's higher than expected, a thread gets opened, an engineer gets pulled in, and everyone spends a week spelunking through Cost Explorer trying to reconstruct why a number that's already been spent is what it is. Then it happens again next month. Every part of that loop is broken. The signal arrives weeks after the decision that caused it. The person reading the signal can't act on it. The person who can act on it never sees it. And the unit of measurement — total dollars — tells you nothing about whether the spend was good . A bill that doubled because you doubled revenue is a triumph. A bill that doubled because someone left a debug log streaming to an expensive tier is a fire. Total dollars can't tell those two apart. They look identical on the invoice. This is the same mistake we'd never make with any other production signal. Nobody reviews latency once a month from a PDF. Nobody waits for finance to tell engineering that p99 regressed.

Most S3 bills are wrong, and the fix takes an afternoon. The data sits in the most expensive class AWS offers (S3 Standard, $0.023/GB-month), nobody set a lifecycle policy, incomplete multipart uploads are silently billing for storage you can't even see in the console, and every byte your EC2 fleet pulls from S3 is routed out through a NAT Gateway when a free VPC Gateway Endpoint would do the same job for $0. None of this needs an architecture rewrite. It needs a checklist run in the right order. Here is the order. The savings depend entirely on your access pattern — I will not promise you a number I can't see — but the mistakes below are so common that the question is usually how much , not whether . One number is just arithmetic: cold data that moves from S3 Standard ($0.023/GB-month) to Glacier Deep Archive ($0.00099/GB-month) drops about 96% on the storage line for those bytes, and on an observability platform I ran — logs aged past 90 days into Deep Archive — that is exactly the lever that did the work. S3 cost optimization is the same boring discipline as the rest of the bill: see it, then decide what each byte should actually cost. First, see the bill before you touch it You cannot optimize what you cannot measure, and S3's default billing view tells you nearly nothing useful. Turn on S3 Storage Lens before anything else. The free tier gives you 62 metrics at the bucket level with 14 days of history, and crucially it includes cost-optimization metrics out of the box — including "Incomplete multipart upload bytes greater than 7 days old," which is the single most common source of money disappearing into storage nobody knows exists ( AWS S3 Storage Lens docs , accessed 2026-06-18). Storage Lens free metrics answer the three questions that decide everything that follows: Which buckets hold the most bytes? What storage class is that data sitting in right now? Where are the incomplete multipart uploads? For deeper per-prefix analysis or a longer history, Advanced

If your AWS bill has a NAT Gateway line, you are paying twice for the same packet: once for the gateway to merely exist, and again for every gigabyte it carries. The fix for most teams is dull and free. Add an S3 and a DynamoDB gateway endpoint, route the heavy traffic away from NAT, and only then argue about anything fancier. That single change is free to turn on, takes minutes, and stops the most expensive traffic from ever touching the meter. This is a playbook, not a lecture. The trick with NAT Gateway pricing is that the two charges hide in different places on the bill, so most teams only ever see half of it. Numbers first, then the fixes, in the order I would actually do them. What you are actually being charged for NAT Gateway has two charges, and people forget the second one until they read the bill closely. Hourly charge — you pay for every hour the gateway is provisioned and available, whether or not a single byte moves through it. In us-east-1 (N. Virginia) and us-east-2 (Ohio) this is $0.045 per NAT Gateway-hour . That is roughly $32.85 a month per gateway just to keep the lights on. Partial hours bill as full hours. Data processing charge — you pay $0.045 per GB processed through the gateway, in the same region, on top of the hourly charge. This applies to every gigabyte, inbound or outbound, regardless of source or destination. And then there is the part the pricing page mentions almost in passing: standard AWS data transfer charges still apply on top. NAT processing is an extra meter on traffic you were already paying to move. The hourly charge is fixed and visible. The per-GB charge is the one that catches teams out, because it scales with traffic you mostly cannot see: package installs, container image pulls, S3 reads from private subnets, telemetry shipped out, cross-region calls. The rate varies by region (it runs higher in places like São Paulo, where both the hourly and per-GB rates sit around $0.093), so check your own region rather than trusti

Give me read access to a $50,000/month AWS account and I will tell you within a day where the first 20-30% is hiding, because on a mid-size bill it is almost always hiding in the same four places, in the same order: data transfer you can't see in the console, instances sized for a load test that ran two years ago, on-demand pricing on a baseline that never moves, and storage rotting in the most expensive class AWS sells. None of this needs an architecture rewrite. AWS cost optimization, at least the first and biggest pass of it, is just the bill read in the right order by someone who knows where AWS buries the meter. This is the order I work. It is the same audit I run on every account I'm handed, and it is the offer — if you want me to run it on yours, the post ends with how. But you can run most of it yourself today, and you should, because nobody is going to care about your bill as much as you do. A note before the recipe: I deal in ranges, not promises. The exact saving on your account depends on what you've built. What I can promise is that the mistakes below are common enough that the question is usually how much , not whether . Hour zero: get the real bill, not the dashboard Before touching a single resource, I want the granular data. The AWS console's cost dashboard rounds, groups, and hides the things that matter. Two tools give you the truth. Cost Explorer , with rightsizing recommendations turned on, is the fast view — group by service, then by usage type, and the bill stops being one big number and starts being a list of decisions. Resource-level and hourly granularity costs extra ($0.01 per 1,000 usage records per month), but for one audit pass it's worth pennies. The Cost and Usage Report (CUR) is the ground truth — line-item, hourly, every charge AWS makes, delivered to your own S3 bucket. Generating it is free; you pay only the few cents of S3 storage. If you're going to do this seriously, set up CUR (now delivered via AWS Data Exports) on day one. E

I'm 12 years old. I build websites and full-stack apps. And recently, I decided to test something I've never seriously tried before: Can I actually make money from coding? Not from ads. Not from selling a course. Not from some complicated SaaS business model. Just by making a simple website for a local business. So I started looking for businesses that could use a better online presence. And then I sent my first message. The idea I noticed that a lot of local businesses have good services and good customer reviews, but their online presence isn't always great. Some don't have a website. Some have an old website. Some mostly depend on WhatsApp and Google Maps. So I thought: «What if I make a simple website demo and show them what their business could look like online?» I already had a generic demo website that I could use to show the idea. It wasn't supposed to be a huge SaaS product. It was just a simple website that looked professional enough to make a business owner say: "Okay, I can see how this could help my business." Then I started messaging businesses I searched for local businesses and looked at what they offered. Electrical shops. Car washes. CCTV companies. Painting contractors. Home service businesses. I didn't send the exact same message to everyone. I tried to mention their actual business and services. Then I waited. And waited. Most of the messages weren't even seen. That's when I learned something important: Building the product is only half the problem. You also have to get someone to care about it. Then one business replied I contacted a local business called DHARSHINI CCTV SURVEILLANCE. I told them I was making simple, modern websites for local businesses and showed them my demo. Then I asked: «"Would you like me to show you?"» A while later, they replied with: "💐" I thanked them and offered to make a free sample specifically for their business. And then they said: "Send" That one word made me ridiculously happy. 😂 Because this wasn't just someone

I rent six dedicated servers from a company in Germany. Together they have more cores, more memory, and more SSD than most production clusters I worked on a decade ago. I run my own Kubernetes on them. Not managed. Not EKS. Not GKE. The whole stack, from the immutable OS up to the workloads. People who hear this ask me why, and the question usually arrives in one of two tones. The dangerous tone is "that's amazing, how do I do it" . The responsible tone is "why on earth would you do that to yourself" . This post is for the second group. Why the cloud is the right answer for almost everyone Let me get this out of the way honestly: by every conventional metric, I should be using the cloud. Managed Kubernetes has become genuinely good. EKS has dramatically improved over the last three years. GKE has always been better than people gave it credit for. The serverless options are mature. The serverless databases are mature. The observability is mature. The bill is predictable in the way a Tuesday is predictable. Self-hosting violates almost every assumption that makes a startup productive. Time is the most expensive resource you have. The cloud sells you abstractions that turn that time into product. Running your own substrate means the time goes into the substrate. If you are trying to ship a product to customers — go use the cloud. Stop reading this post. It will only confuse you. What the cloud does not sell you Here is what the cloud will not sell you, even if you are willing to pay extra: control over your own roadmap. The cloud's roadmap is the cloud's. They decide which APIs deprecate. They decide which regions get the new feature. They decide what your egress bill looks like. They decide whether your monitoring vendor — sitting on top of their infrastructure — is allowed to charge you eight times what it would cost you to host the same software yourself. They decide whether the small ML company hosting your fine-tuned model gets acquired by someone with very differ

DevTools responsive mode has one limitation that's never been fixed: you see one device at a time. You check iPhone. Looks fine. Switch to iPad. Fix padding. Switch back to iPhone. Was the header already broken or did you just break it? I got tired of holding layouts in my head, so I built a tool that shows all three at once. Responsive Tool — free, no signup Paste a URL → phone, tablet, and desktop load at one time. That's it. A few things that make it actually useful day to day: Swap one pane to a different device without losing the other two Refresh one pane after a code push — no need to reload everything Share your exact setup via URL — a teammate sees the same device comparison you do Sync scroll across all panes with a one-line script snippet Every viewport is a real verified CSS size , not a guess No account. No extension. No download. Runs in the browser. I don't see or store the URLs you test. Also: way more sites block iframes via X-Frame-Options than you'd think. I tested ~60 real sites — 93% of developer portfolios loaded fine, but only 44% of framework/marketing sites did. If your site doesn't load, that's the server blocking iframes, not a bug in the tool. Stack Next.js 16 · React 19 · TypeScript · Tailwind v4 · Cloudflare Workers Bonus I also built a CSS breakpoints reference that maps common breakpoints to real device viewports. Handy even without the tool. 👉 responsivetool.com What do you use for responsive checking? Still just DevTools? I want to know what I'm up against.

The bill that started this I was paying $40/month for a PDF generation API to power a tiny internal invoicing tool for a client project. Forty bucks a month to convert some JSON into a PDF. That's it. That's the whole service. I finally sat down on a Saturday to see if I could kill that subscription. Three weekends later, not only did I kill it — the replacement is faster than the API ever was, because there's no network round-trip at all. This post is the log of how it went, in the order I actually hit the problems, not the order that makes me look competent. Attempt #1: jsPDF on the main thread (it worked, until it didn't) First pass was the obvious one — jsPDF running directly in the click handler: function generateInvoice ( data ) { const doc = new jsPDF (); doc . text ( data . clientName , 20 , 20 ); data . lineItems . forEach (( item , i ) => { doc . text ( ` ${ item . description } — $ ${ item . amount } ` , 20 , 40 + i * 10 ); }); doc . save ( ' invoice.pdf ' ); } Fine for a 3-line invoice. Once I tested with a 40-line-item invoice (a real client sent me one to test against), the tab froze for almost two full seconds. Not crashed — frozen. Scroll didn't work, buttons didn't respond, and on a mid-range Android phone it was closer to five seconds. The main thread doing synchronous PDF math while also being responsible for painting the UI is exactly the kind of thing that looks fine in a demo and falls apart the moment a real user pastes in real data. Attempt #2: move it to a Web Worker Web Workers get talked about like they're this exotic tool for WASM and video processing. They're also just... a really good fit for "expensive synchronous work that a user is waiting on." I'd never reached for one before this project, mostly out of habit. The tricky part isn't the worker itself, it's that jsPDF assumes it has access to document and window in a couple of code paths (font metrics, mostly), which don't exist inside a worker. I ended up switching to pdfkit compiled

A random game is easier to debug when the same inputs produce the same result. In HoopTrait, a browser basketball project, the Lab mode combines eight selected traits and generates a fictional career. The interesting engineering problem is keeping replay, sharing and validation consistent. This is a technical development note, not a claim that a game score predicts an athlete's real performance. Store the decisions, not just the result The Lab state records a seed, a dataset version and an ordered list of actions. An action is a pick or a reroll. Replaying those actions reconstructs the build. A seed alone is not a complete replay contract: changing the player pool or its order can change a seeded draw. A dataset version therefore matters alongside the random seed. For a future release, the same principle should apply to changes in the rules themselves. Test invariants across many runs The Lab test suite iterates through 1,000 seeds. For each seed it shuffles the order of the eight skills, uses the two allowed rerolls, and completes a build. It checks that: Eight distinct players were selected. All eight traits are present, and no player remains to be drawn after completion. The overall game score stays between 0 and 99 and matches the shared rating function. Packing and unpacking the share state returns the original state. Recomputing the fictional career returns the same output. The ten simulated seasons sum to the displayed career earnings. Those assertions catch different problems. A stable score does not prove that a shared link reproduces the same selections. A complete build does not prove that its season totals add up. Reject impossible histories A share payload is untrusted input, even in a client-side game. Negative or fractional seeds, duplicate skill picks, a third reroll, unknown action types, a mismatched dataset version and actions after completion are rejected. The tests also cover malformed encoded payloads and unexpected fields. Local state is usef

This is a submission for Weekend Challenge: Generosity Edition What I Built My late...

The Fairphone 6 Plus feels like an extremely average midrange Android phone and I couldn't be more thrilled. The mission has always been admirable. Fairphone seeks out ethically sourced materials and offers a high degree of repairability for its devices. But the phones themselves required a lot of sacrifices, like putting up with underpowered processors […]

This is a submission for Weekend Challenge: Generosity Edition What I Built A donation ledger for a group too small to buy software. It is a Google Sheet, some Apps Script, and one public page a donor can open. The group I had in mind is the kind that exists on every street: a neighbourhood fund, a school parents' group, a committee that collects for winter coats. Money arrives over WhatsApp and leaves in cash, and somebody keeps it in a notebook. The arithmetic is not the hard part. The hard part arrives three months later when a donor asks where their money went, and answering needs the notebook, the person holding it, and an afternoon. Software for this exists and is priced for organisations with a finance team. So the ledger stays in a spreadsheet a volunteer already knows how to open, and the only thing added is what a spreadsheet cannot do alone: read messy human messages, refuse to trust its own reading , and publish the page that answers the question before it is asked. Demo The public page a donor opens → That page is the deployed page, byte for byte, with one line changed: where the Apps Script version writes <?= data ?> , the demo fetches the same JSON from a file so you can read it without a Google account. The JSON is produced by running the sample month through the same recordEntry() and publicView() the real script uses, so if the ledger rules change, the demo changes with them or the build fails. The sample month deliberately includes the things that go wrong: a receipt two volunteers forwarded, a donation typed with one zero too many and later corrected, and a reading the checks refused to trust. What the model read, and whether it was allowed to count → The ledger page shows the result. This one shows the part worth showing. Pick any of six real donation messages and it highlights the exact characters Gemini says it read the amount from, lists the three checks with their outcomes, and says why the row was posted or held. It is fed by a recorded run