开发者

The day before Father's Day, my daughter walked into her first swimming lesson like she owned the place. She'd been dreaming about water for as long as I can remember. Barely gets exposure to it. Walked in, took to her teacher without hesitation, spent thirty minutes in an environment she loves, had a blast the entire time. All the worry I'd carried into that morning dissolved in about four seconds. Father's Day itself was quiet after that. Easy. The kind of day where you have space to pick up something you've been thinking about and actually finish it. I shipped rfd-logging to PyPI. It's a logging standard. One get_logger call. Structured JSON output. Ten megabyte rotation, five backups, stdout capture for NSSM services. Zero runtime dependencies — pure Python standard library. Forty-six tests. The kind of thing that takes an afternoon to build once you know what you want, and takes two years of building other things before you know what you want. That's the honest timeline. Over a hundred projects. Probably closer to five hundred if you count everything back far enough. Logging handled differently in every one — sometimes print statements, sometimes a library, sometimes nothing at all. Each project reinventing the same wheel slightly differently. The friction was always there. It took two years to feel it clearly enough to do something permanent about it. My second PyPI release. The first was openagent-directive — a different kind of primitive, built for a different problem. This one is smaller and more universal. Every project needs logging. Not every project needs an agent directive system. rfd-logging is the kind of package that belongs in every RFD service from day one, and eventually in anything I build regardless of context. That's what shipping to PyPI teaches that shipping locally doesn't. The question stops being "does this work for this project" and becomes "would someone else find this useful." Building with reusability in mind from the start changes th

"Prop drilling is bad, use Context" is repeated everywhere — but the actual cost stays abstract. So I put the two approaches side by side with live render counters. Click one button and the difference is impossible to miss. ▶ Live demo: https://context-vs-props-drilling.vercel.app/ Source (React 19 + TS): https://github.com/dev48v/context-vs-props-drilling Two identical 4-level trees, both React.memo 'd. One threads a value down as a prop through every level; the other provides it once via Context and reads it only at the leaf. Change the value: Prop drilling → 4 components re-render. Every component on the path receives the changed prop, so all of them re-render — and each intermediate is cluttered with a value it does nothing with except pass along. Context → 1 component re-renders. The intermediates take no value prop, so they're skipped (memoized, props unchanged). Only the consumer leaf re-renders. The summary tallies it on every click: 4 vs 1 . Why Context skips the middle This is the part that surprises people: with Context, an intermediate component can be skipped even though a descendant re-renders . < ThemeCtx . Provider value = { val } > < A /> { /* memo, no props → skipped on value change */ } </ ThemeCtx . Provider > const A = memo (() => < B />); // skipped const B = memo (() => < C />); // skipped const C = memo (() => < Leaf />); // skipped const Leaf = () => { const value = useContext ( ThemeCtx ); // ← re-renders on context change return < div > { value } </ div >; }; React re-renders context consumers directly when the provider value changes — it doesn't need to re-render the components in between. With prop drilling there's no such shortcut: the only way the value reaches the leaf is through every parent, so every parent must re-render. The catch — Context isn't a free lunch Context isn't a "no re-renders" button. Every consumer re-renders whenever the provider value changes — there's no built-in selective subscription. One big, chatty context ca

submitted by /u/Important-Addition79 [link] [留言]

submitted by /u/HHalo6 [link] [留言]

Most teams reach for Temporal when they need coordination guarantees.The tradeoff is rewriting your entire codebase to be deterministic and learning a new programming paradigm. Redis SETNX wasn't giving me correctness guarantees. You can make your own coordination primitive on postgres Like I did for my payments service Full writeup: https://statecraft.hashnode.dev/you-don-t-need-temporal-you-need-postgres Edit: i formatted poorly and the bracket became a part of the link it's fixed submitted by /u/munch_muffin_solas [link] [留言]

Why console.log() can be misleading in browser DevTools: live object references, promises that look different when expanded later, logs changing timing-sensitive behavior, stale React state after updates, and source maps pointing at surprising line numbers. submitted by /u/OtherwisePush6424 [link] [留言]