Reddit Programming
208 subscribers
1.22K photos
123K links
I will send you newest post from subreddit /r/programming
Download Telegram
AWS Bedrock Agent Tutorial: Shopping & Flights Demo
https://www.reddit.com/r/programming/comments/1msvhsd/aws_bedrock_agent_tutorial_shopping_flights_demo/

<!-- SC_OFF -->Most “AI agent” posts are hand-wavy. Lots of theory, not much code. So I decided to actually build one — using AWS Bedrock Agents. Specifically, I put together a two-agent system where: One agent fetches data from APIs Another transforms and validates it before storing Along the way I hit interesting challenges: How to structure the agent workflows What Bedrock really gives you out of the box (vs. what you still need to code) Guardrails and observability when agents call external services I wrote up the full walkthrough and published a repo so you can try it yourself - Curious what others think: do multi-agent setups make sense for production today? <!-- SC_ON --> submitted by /u/skenklok (https://www.reddit.com/user/skenklok)
[link] (https://www.tostring.ai/p/hands-on-bedrock-agents-build-a-two?r=clbp9) [comments] (https://www.reddit.com/r/programming/comments/1msvhsd/aws_bedrock_agent_tutorial_shopping_flights_demo/)
Documenting Code is boring ….but it doesn’t have to be
https://www.reddit.com/r/programming/comments/1mt6zy1/documenting_code_is_boring_but_it_doesnt_have_to/

<!-- SC_OFF -->This article got me thinking about the fundamental paradox in our industry - we all desperately need good documentation, but most of us hate creating it. The piece talks about making docs “less boring” through better design and structure, but I’m more curious about the underlying problem: is the pain of writing documentation actually worth solving, or do most developers just accept it as a necessary evil? In my experience, there are roughly three camps: 1. The sufferers - Write docs because they have to, hate every minute of it 2. The skippers - Just don’t document and hope someone else deals with it later 3. The rare unicorns - Actually enjoy writing documentation (do these people exist?) What’s your honest approach? Do you: • Power through the tedium because you know it’s important? • Use any tools/automation to make it less painful? • Just… not do it unless absolutely forced? I’m particularly interested in whether people think this is a problem worth solving with better tooling, or if it’s just an inherent part of development that we need to accept. <!-- SC_ON --> submitted by /u/Ok-Ad7050 (https://www.reddit.com/user/Ok-Ad7050)
[link] (https://medium.com/steeple-product/how-to-make-documentation-less-boring-ea50fcfa56fb) [comments] (https://www.reddit.com/r/programming/comments/1mt6zy1/documenting_code_is_boring_but_it_doesnt_have_to/)
NUMA Is the New Network: How Per-Socket Memory Models Are Reshaping Microservice Placement
https://www.reddit.com/r/programming/comments/1mt8qjj/numa_is_the_new_network_how_persocket_memory/

<!-- SC_OFF -->Explores how Non-Uniform Memory Access (NUMA) is reshaping microservice placement. <!-- SC_ON --> submitted by /u/mqian41 (https://www.reddit.com/user/mqian41)
[link] (https://codemia.io/blog/path/NUMA-Is-the-New-Network-How-Per-Socket-Memory-Models-Are-Reshaping-Microservice-Placement) [comments] (https://www.reddit.com/r/programming/comments/1mt8qjj/numa_is_the_new_network_how_persocket_memory/)
Kanban board TUI in go
https://www.reddit.com/r/programming/comments/1mtc89w/kanban_board_tui_in_go/

<!-- SC_OFF -->A kanban board implement in go. vim like motion undo and redo. the board are based on a list of markdown files I will implement the obsidian and nelvim plugin for this little tui. I just suffer from slow workspace switching in obsidian, use tmux session to manage workspace is much smoother to me. Because I can't escape terminal workflow which make me feel pain sometimes <!-- SC_ON --> submitted by /u/Remarkable-Hunt6309 (https://www.reddit.com/user/Remarkable-Hunt6309)
[link] (https://github.com/sokinpui/kanban-tui) [comments] (https://www.reddit.com/r/programming/comments/1mtc89w/kanban_board_tui_in_go/)
Benchmarking Frontends in 2025
https://www.reddit.com/r/programming/comments/1mti1m8/benchmarking_frontends_in_2025/

<!-- SC_OFF -->Hey r/programming (https://www.reddit.com/r/programming), For a while now, I've felt that our standard frontend benchmarks don't tell the whole story for the kind of complex, data-heavy apps many of us spend our days building. Core Web Vitals are great for initial load, and the popular js-framework-benchmark is useful, but it has two major limitations for testing at-scale apps: it forbids virtualization/buffered rendering, and it doesn't simulate real-world concurrent stress (e.g., a user scrolling during a heavy background task). This means we're often flying blind when it comes to the resilience of our applications. To address this, I spent the last 10 days building a new benchmarking harness from the ground up using Playwright. The goal was to create something that could provide credible, high-precision measurements of UI performance under sustained, concurrent duress. Building it was a serious engineering challenge in itself, and I wanted to share three key lessons learned: The Parallelism Trap: My first instinct was to run tests in parallel. This was a disaster. The CPU contention between maxed-out browser instances skewed the results by up to 50%. Lesson: Accurate performance benchmarking must be run serially (--workers=1). The Latency Chasm: The back-and-forth between the Node.js test runner and the browser introduced too much noise. Lesson: Measurements must be atomic. I had to wrap the entire test logic (trigger action -> wait for condition -> measure time) in a single page.evaluate() call, executing it entirely within the browser's context to eliminate test runner latency. The Polling Fallacy: Playwright's waitFor functions (like most) use long-polling, which is not precise enough for performance measurement. You can't measure a 20ms event with a 30ms polling interval. Lesson: Don't trust polling. I had to build a custom wait mechanism using a MutationObserver to stop the timer at the exact moment the DOM reached the desired state. Why do this? This project started as a response to skepticism about claims I've made regarding the performance of a worker-based UI framework I created (neo.mjs). I claimed that offloading logic from the main thread could solve major performance bottlenecks, and the community rightly asked for proof. This benchmark is that proof. The Results The most interesting test so far pits a new neo.mjs grid against the industry-leading AG Grid (in a React app). When performing heavy operations like resizing the viewport from 50 to 200 columns with 100,000 rows, the results were stark: React + AG Grid: ~3,000-5,500ms UI update time. neo.mjs: ~400ms UI update time. That's a 7-11x performance difference, depending on the browser. This isn't an indictment of AG Grid, which is a fantastic piece of engineering. It's a powerful data point showing the architectural ceiling imposed by a single-threaded paradigm. Even a best-in-class component is ultimately limited by a blocked main thread. This is an open-source project, and I'm hoping to start a conversation about how we can better measure and build for the "lived-in" web. I'd love to get your feedback on the methodology and the results. Full Article (The "Why"): https://tobiasuhlig.medium.com/benchmarking-frontends-in-2025-f6bbf43b7721?source=friends_link&sk=af0f2c6745a7ca4993bc0ae60ad0ebb4 GitHub Repo (The "How" - code, methodology, results): https://github.com/neomjs/benchmarks Live Demo (See for yourself): https://neomjs.com/dist/production/examples/grid/bigData/index.html Thanks for reading, Tobias <!-- SC_ON --> submitted by /u/TobiasUhlig (https://www.reddit.com/user/TobiasUhlig)
Dumper App
https://www.reddit.com/r/programming/comments/1mtir04/dumper_app/

<!-- SC_OFF -->Dumper — This is a CLI utility for creating backups databases of various types (PostgreSQL, MySQL and etc.) with flexible connection and storage settings. Today the first version this app https://github.com/elkirrs/dumper There are many ideas for adding new features. I will be grateful for every advice and feedback. <!-- SC_ON --> submitted by /u/elkirrs (https://www.reddit.com/user/elkirrs)
[link] (https://github.com/elkirrs/dumper) [comments] (https://www.reddit.com/r/programming/comments/1mtir04/dumper_app/)