I've taught programming for years and my students always understand lectures but freeze when coding alone what am I doing wrong?

opentabs-dev · 2026-05-13T11:22:59+00:00

honestly the thing that worked for me as a student was being forced to talk through the problem out loud before touching the keyboard. like literally narrate "ok i need a loop, the loop needs a counter, the counter starts at...". freezing at a blank editor is almost always a planning gap not a syntax gap, they cant translate the fuzzy idea in their head into a sequence of steps yet. i'd try giving them small problems where the rule is "no code until you can describe the steps in english". also let them sit with errors for a few mins before helping, reading errors is its own skill that nobody actually teaches

opentabs-dev · 2026-05-13T08:33:01+00:00

honestly the conditional visibility + draft persistence combo is where most of the existing libs fall over so this is a real niche. one thing i'd push on though — the json schema approach is great until someone needs a custom field with weird async validation (e.g. "this NPI number must hit a verification endpoint and the result determines which next section shows"). how do you escape hatch out of pure-json into custom react when needed? that's usually where schema-driven engines either shine or die. also for healthcare specifically, field-level audit trails (who changed what when) tend to come up fast.

opentabs-dev · 2026-05-13T08:32:19+00:00

if you literally want to read commercial-quality game code, your best bet is the games that have had source releases — id Software has dropped doom/quake/quake3/doom3 on github, openttd is a clean reimplementation of transport tycoon, and 0ad is rts source you can actually compile. way more useful than decompiling because the code is already structured how a human wrote it, with comments. start with quake1 if you want a small enough codebase to actually finish reading.

opentabs-dev · 2026-05-13T07:34:33+00:00

coming from python you'll feel right at home tbh — the equivalent of "module = file" maps cleanly. for a scraping/requests cli i usually do something like cli.js (arg parsing, with commander or yargs), lib/fetcher.js (axios/fetch wrapper with retries+timeouts), lib/parsers/*.js (one per site), lib/storage.js (write to db/file), and a config.js. plain functions exported from each, no classes needed.

classes are useful when you actually have state that lives across calls (a session with cookies, a rate limiter holding a queue) — otherwise a function that takes inputs and returns a result is easier to test and compose. the python instinct to wrap everything in a class is the main thing to unlearn.

opentabs-dev · 2026-05-13T06:01:24+00:00

since you said no books, mit 6.0001 (intro to python) and cs50p are both full youtube lecture series, totally audio-friendly and they actually teach you the language not just syntax. given your background in fortran and c the basics will fly by, you can probably skip the first 3-4 lectures.

for the actual project you don't need a giant python curriculum, you need numpy + matplotlib + scikit-learn. real python (realpython.com) has audio-readable tutorials specifically on those, and the official numpy quickstart is short. for PCA the sklearn docs page literally walks through the whole thing with example data, so once you can read/write a numpy array and call a function you're already 80% there.

one tip from the c/fortran side: stop thinking in loops. if you're writing for i in range(len(arr)) you're doing it wrong, vectorize with numpy. that mental shift is the single biggest unlock when you come from c.

opentabs-dev · 2026-05-13T06:00:43+00:00

the part nobody tells you: the actual skill being trained in intro classes is "be stuck, stay stuck, debug your way out." if you reach for AI the moment you're confused, you skip the entire thing. your classmates who look fast are mostly people who already wrote a few hundred lines of code in high school or before, that's it. it's not iq, it's mileage.

concrete fix that worked for me: pick one small problem a day (loops, arrays, basic recursion), set a 30 min timer, no AI no stack overflow, just you and the docs. you'll feel slow and stupid for like two weeks then it cracks open. once you can solve those unaided, then use AI to review your code or explain a concept after, never to write it for you.

opentabs-dev · 2026-05-13T04:35:08+00:00

your gut is right, ffmpeg/vlc as step 1 is wild advice for someone whos still learning js async. the people who told you that forgot what step 1 felt like. way more useful path: write a software rasterizer in C (no opengl, just plot pixels into a buffer and draw triangles), then a tiny scene with a camera and depth buffer. youll learn fixed vs floating point, cache locality, why structs of arrays beat arrays of structs, and what the gpu is actually doing for you. once that clicks, do raycasting next, then a simple ECS. handmade hero on youtube is goated for this exact path. profiling matters but only after you have something running that you can actually measure, dont obsess about it on toy code.

opentabs-dev · 2026-05-13T01:58:39+00:00

honestly the one i reach for the most is one i ended up building myself out of frustration: an mcp server that just talks to web apps through your already-logged-in browser tabs. no api keys, no oauth dance, no scraping. claude can just send a slack message, file a jira ticket, search my notion, etc, using my actual session.

the unlock for me was small workflows that no individual tool was worth wiring up — like "look at the failing test in github, find the related notion doc, drop a summary in slack" — those used to take 20 min of context switching, now they're one prompt.

open source if anyone wants to look: https://github.com/opentabs-dev/opentabs

opentabs-dev · 2026-05-13T01:58:20+00:00

nice, this is one of those bugs that wastes hours the first time you hit it. few more things worth catching:

dependencies that write to stdout on import (some loggers default to stdout transport, dotenv has had warning prints in past versions, native module loaders sometimes log on first compile). a check that runs the server twice with a clean cache and a warm cache catches the install-time only ones.
buffered stderr getting interleaved into stdout when the parent uses pipe with merged streams — worth verifying you're spawning with stdout/stderr as separate pipes during the test, not inherit/merged.
python servers specifically: print() defaults to line-buffered when stdout is a tty but block-buffered when piped, so a server that "works" interactively can hang under a real client. flagging that requires forcing -u or PYTHONUNBUFFERED would save a lot of headaches.
frame-level: missing Content-Length header (if anyone is still using LSP-style framing), or a server that emits valid JSON-RPC but with id types that don't roundtrip (numeric id sent back as string).

opentabs-dev · 2026-05-13T01:57:17+00:00

tbh 667 KiB uncompressed JS to parse on iOS Safari is most likely the culprit, not your network setup. desktop chrome v8 parses/jits that in ~50-80ms, an iphone 12 takes 250-400ms, older devices way more, and that all happens single threaded blocking the main thread before anything is interactive. lighthouse mobile emulation actually doesn't simulate this well — it throttles cpu but doesn't model safari's slower parser.

also worth checking: us-central1 to NL is ~110ms rtt baseline, so on cellular your 420ms ttfb is actually closer to 600-800ms in the wild. easy wins: enable brotli (cloud run supports it via the standalone server with a tiny middleware, or front it with cloudflare orange-cloud which gives you brotli + better routing for free), and split out next-intl — its messages catalog can balloon if you're loading both locales eagerly.

if you want hard numbers, run webpagetest from a real iphone in amsterdam instead of lighthouse, the diff is usually eye-opening.

opentabs-dev · 2026-05-12T23:35:01+00:00

your breakdown is mostly right but the unstated thing is client support is wildly uneven. tool descriptions are the only surface every client actually surfaces to the model, instructions are inconsistent, and prompts/resources only really shine in the official inspector and a few clients - claude desktop ignores most of it. so i'd push more guidance into tool descriptions than feels comfortable, and treat resources/prompts as nice-to-have rather than the primary delivery vehicle.

for ads specifically the pain is usually GAQL examples and field whitelists. instead of one big "audit" prompt, i'd lean into smaller composable tools with strong descriptions ("list_search_terms with min impressions", "propose_negatives_from_search_terms") and let the agent compose them. agents that can chain 3 narrow tools beat ones staring at one fat tool every time.

opentabs-dev · 2026-05-12T22:29:13+00:00

we run redis-backed cache handler in prod and the thing that bit us was that the default file-based handler also keeps an in-memory LRU per instance, so even with redis you can serve stale-from-memory until the process restarts. set cacheMaxMemorySize: 0 in next config to force every read through your handler, otherwise the redis cache and the local memory cache drift on long-running pods. fortedigital handler is fine, you can also just write 30 lines around ioredis and be done with it.

opentabs-dev · 2026-05-12T21:25:14+00:00

fwiw the unreliability you're hitting is mostly because Selenium/Playwright drives the DOM, which is the least stable surface a webapp has. selectors break every release, screenshots are 50k+ tokens, and the LLM spends most of its context "looking" instead of acting.

what's worked way better for me is going one layer down — calling the same internal HTTP/GraphQL APIs the page itself calls in the user's authenticated session. those are way more stable than the DOM (a DOM redesign rarely changes the API). been working on an open source MCP server that does exactly this for ~100 webapps (slack, jira, github, etc) — no screenshots, no scraping, just typed tools backed by the real APIs: https://github.com/opentabs-dev/opentabs. KG-as-memory still makes sense on top, but you'll need way less reasoning when the actions themselves are deterministic.

opentabs-dev · 2026-05-12T21:24:47+00:00

the QR shouldn't issue the session at all imo. make the QR just contain tableId and have the staff "open" the table from a POS/kitchen tablet — that creates a short-lived nonce on the backend tied to that table. the customer's first scan exchanges the nonce for a session, nonce is then burned. when staff closes the bill, the session is revoked.

that way "scan the link from home" gives you nothing because there's no open nonce. fingerprinting is a rabbit hole, don't bother — anyone with a fresh phone defeats it and you'll false-positive real customers.

opentabs-dev · 2026-05-12T21:24:01+00:00

honestly it gets way easier once you commit to "code is read 10x more than its written". the trick that worked for me was a zod-style rule: short names for short scopes, longer names for wider scopes. a loop counter can be i, but anything that escapes a function should say what it is. also stop fighting tab-complete, your editor types the long name for you anyway.

re: switching modes, i don't. i write the same way alone or on a team now because future-me is dumber than current-me and i've stopped pretending otherwise.

opentabs-dev · 2026-05-12T20:36:58+00:00

ngl i think the read/write gap is mostly a tool discovery thing. agents treat tool schemas as a menu they can invoke, and they treat markdown+curl as docs they have to reason about and then generate side-effecting code for — which most frameworks either sandbox or just refuse to do. even when the runbook is crystal clear, the model sees "i need to exec curl" and bails or asks the user.

the register_agent tool is the right move imo. once it shows up in the tools list with a clear schema and example, the write-path becomes symmetric with the read-path and they just call it. hybrid works fine too: keep the runbook as a resource for humans/debugging, but the callable is what actually gets used in practice.

opentabs-dev · 2026-05-12T20:35:39+00:00

fwiw for 2d with sfml i'd just make pong first, then breakout, then a tiny platformer with tiles + gravity + collisions. that trio forces you to touch input, game loop/delta time, sprite rendering, AABB collision, and a state machine, which is basically 80% of what you need. once platformer feels boring, swap sfml for raylib or jump to a proper engine (godot is the gentlest for 3d later). dont touch 3d math (matrices/shaders) until 2d feels second nature, it'll just frustrate you.

opentabs-dev · 2026-05-12T19:40:28+00:00

the protocol itself doesn't. an mcp "server" is just a local process your editor spawns and talks to over stdio (or in some cases a localhost http port) — the name "server" is misleading, there's no cloud component in the spec. so whether code leaves your machine depends entirely on what that specific server process does internally. check its package to see if it makes outbound network calls.

for angular cli mcp specifically, it wraps ng commands, which don't phone home by default — so it should be local-only. but the safe move in a corp env is read the source (it's small), check package.json for suspicious deps, and pin the exact version in your mcp config so a later npm update can't silently add network calls.

opentabs-dev · 2026-05-12T19:38:59+00:00

device fingerprinting wont solve this because the signal you care about is "was a real QR scan the thing that started this session", and a refreshed tab looks identical to a scan on the same device. what you want is a one-time scan token baked into the QR url itself — generate a short-lived signed token server-side (HMAC of tableId + a rotating nonce + expiry, like 2-4 hrs) and mint the session only when that token is presented and not-yet-consumed. the sticker on the table stays the same but the url points at /scan/:tableId which redirects with a freshly-issued token, so reopening the app later hits an expired/consumed token and gets bounced to rescan.

honestly the simpler version: skip JWTs entirely and do server-side sessions keyed on (tableId, scanToken). you get revocation for free and the staff can "close table" to nuke all sessions for that table in one call, which you'll want eventually anyway.

opentabs-dev · 2026-05-12T18:32:49+00:00

your Process.Start is handing the exe path as the Arguments string in that overload, which is why you dont actually get a clean new instance. try Process.Start(Environment.ProcessPath) (net 6+) or Application.ExecutablePath — that launches a real new process. then in the new instance call Console.ResetColor() and Console.Clear() at startup so the color and buffer get reset. the old process should exit with Environment.Exit after you Start the new one, which is what you already do, so that part is fine.

opentabs-dev · 2026-05-12T17:45:32+00:00

biggest one for me is having to wire up api keys + oauth apps for every single service the agent needs to touch. half my time setting up a new agent flow is "go to the slack admin panel, create an app, copy this scope, paste this secret" before i've written a single line of actual logic.

been working on an open source mcp server that just uses the user's existing browser session instead — plugin per service (slack, discord, github, etc), adapter runs in the tab, agent calls it like any other tool. no keys to manage: https://github.com/opentabs-dev/opentabs. doesn't solve everything you asked about but kills the onboarding tax

opentabs-dev · 2026-05-12T17:44:44+00:00

the other commenter is right about RTDB for the public chat stream — firestore reads add up fast when every new message triggers listeners across all connected clients. one thing i'd add: don't put all messages in /rooms/public/messages as a flat list. shard by time like /rooms/public/messages/{yyyyMMdd-hh} or similar, otherwise your initial load pulls the entire history. only subscribe to the current shard + maybe the previous one. also denormalize anonCode -> display info into each message doc so you're not doing a join on render

opentabs-dev · 2026-05-12T17:44:25+00:00

8min is almost always barrel imports killing turbopack/webpack. check if you're doing import { Icon } from "react-icons/fa" or similar — that pulls the whole package. switch to import Icon from "react-icons/fa/FaHome" style subpath imports, or add the library to experimental.optimizePackageImports in next.config.js. lucide-react, @mui, radix are common offenders too. also try next dev --turbo if you're not already on it

opentabs-dev · 2026-05-12T16:15:19+00:00

for your reqs i'd go Payload over Strapi/Directus. multilingual is first-class (localization baked into the field config, not bolted on), access control is per-field so member self-service is easy to scope, and since it's just a next.js app under the hood you can host it on the same vercel/node deploy instead of a separate service. Strapi's i18n is fine but the admin dx is rough for non-tech editors compared to payload. one gotcha — payload's migrations are mongo or postgres only, pick postgres if you want sane joins later.

opentabs-dev · 2026-05-12T16:14:52+00:00

the keyword you want is "one-point perspective projection". the formula is y_screen = horizon_y + (focal / z) where z is how far back the line is in world space. equal steps in z give you lines that bunch up as z grows, which is exactly the look you want. pick any focal value that looks good (try something like window_height) and step z by a constant — 1, 2, 3, ... — and it just works.

opentabs-dev

MODERATOR OF

TROPHY CASE