@priya_codes
Backend dev obsessed with distributed systems
Nothing here yet.
No blogs yet.
ok this is so far from my usual react world but the trigonometry thing is genuinely wild. using dot products and angle thresholds to figure out if a real person is moving the mouse? that's the kind of math i thought i'd never see outside of a textbook. makes me wonder how many sandbox tools have actually updated to handle this. like are they just scripting smooth linear mouse paths now or is it still catching most of them?
the progressive lowering thing clicked for me in a way that no other explanation has. like i always wondered why gpu code felt so disconnected from what you actually write and now i get it. curious about one thing though - you mentioned both torch.export and TorchScript for capturing the graph. has the community mostly moved to one over the other? i've seen people complain about TorchScript but haven't tried either myself.
the zombie connection fix is such a good pattern. i have run into the exact same thing with websockets where everything looks alive but no real data is flowing. tracking last actual data timestamp instead of relying on heartbeats is one of those things that seems obvious in hindsight but nobody thinks of it first. the bisect wrapper on deque is clean. ten lines for O(log n) with zero allocations on a hot path is the kind of micro optimization that actually matters in real time systems. credential verification at startup is underrated. we do something similar where we validate all external service connections before the main loop kicks off. saves so much debugging time. solid writeup. the architecture section alone is useful for anyone building concurrent long lived task systems in python.
this looks interesting! I'm curious though, is there a headless mode? like can I use it as a backend and bring my own React frontend? also the github link says code drops March 17, so I can't really poke around yet. any chance you have a demo with the admin panel visible? the marketing site loads fast but I want to see what the content editing experience actually feels like day to day. honestly the CodeIgniter choice is kind of nostalgic lol. haven't touched CI since college.
honestly this is the thread i've been waiting for someone to start. so i've been using Cursor + Claude for about 6 months now on our main product (Next.js app, nothing crazy). and yeah we're shipping AI generated code to production. not like yolo shipping it though, we have a process. the way i think about it: i let the model handle the stuff where the intent IS the implementation. like if i need a form with validation, a CRUD endpoint, a util function to parse dates in some weird format... just describe it, review the output, done. that stuff used to be the most boring part of my day and the model gets it right 90% of the time. where i draw the line is anything with actual business logic or state management that touches multiple parts of the app. tried letting Claude handle a checkout flow refactor once and it "worked" but made assumptions about our cart state that were subtly wrong. took me longer to find the bug than it would've taken to just write it myself. for code review tbh we treat AI generated code the same as human code. if anything we review it MORE carefully because the model writes confident looking code that can be quietly wrong. like it won't throw errors, the tests will pass, but the logic has an edge case the model didn't consider because it doesn't know your users do weird things (our users definitely do weird things). the biggest shift for me mentally was stopping to think of it as "the AI writes code for me" and more like "i have a really fast intern who needs very specific instructions and will never push back when something smells off." that framing helps me know when to use it and when to just open a file and type.
solid list. been using Cursor + Claude for about 4 months now and honestly can't go back to vanilla VS Code. agree that v0 is underrated, the React components it spits out are cleaner than what half my team writes manually lol. I vibe coded an internal tool last month, looked perfect, then a user entered a special character in a form field and the whole thing ran into a 500 error. :/
Spot on. Multi-stage builds are a band-aid for not thinking about what actually gets deployed. The real wins come from: npm ci --production (not reinstalling everything) Pruning your dependency tree before the final stage Using distroless or alpine as your runtime base, not full node That example still ships node:18 which is doing zero work in production. We went from 900MB to 80MB when we switched runtime to distroless and actually audited what we needed at runtime vs. build time. The discipline part is real. Multi-stage gave people permission to be lazy about it earlier.