标签：#programming

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

What do you think about the new HTTP Query method? submitted by /u/Perfect-Scale902 [link] [留言]

One of the most confusing errors you can face while deploying a Node.js or Docker-based application is: fatal: Need to specify how to reconcile divergent branches At first glance, it looks like a Git bug. In reality, it is Git doing exactly what it should do, protecting you from overwriting history. In this article, I’ll break down a real production incident where a deployment failed due to divergent Git branches, how we diagnosed it, and the correct DevOps fix. The Problem A simple deployment script was running: git pull docker compose down --remove-orphans docker compose up --build -d But it failed with: fatal: Need to specify how to reconcile divergent branches This stopped deployment completely. What Git Was Telling Us To understand the issue, we ran: git rev-list --left-right --count HEAD...origin/main Output: 1 16 This means: 1 commit exists locally on the server 16 commits exist on GitHub So the branches had diverged. Why This Happens (Important) This usually happens when: Someone runs git commit directly on a server A previous deployment used git pull with merge commits History between local and remote is no longer linear Git refuses to guess whether you want to: Merge Rebase Or reject changes So it throws an error. Deep Diagnosis We inspected the commits: git log --oneline origin/main..HEAD Result: 6d9046b Merge pull request #222 Then: git log --oneline HEAD..origin/main Showed multiple new GitHub PR merges. Conclusion: The server was behind GitHub The “local commit” was already part of repo history No real production changes existed on server The Real Fix (Production Safe) For deployment servers, you should NEVER rely on git pull . Instead, use a deterministic reset: git fetch origin git reset --hard origin/main Then redeploy: docker compose down --remove-orphans docker compose up --build -d Why This Works This approach ensures: Server always matches GitHub exactly No merge conflicts in production No accidental local commits survive Fully reproducible depl

Hi there, im currently coding a datapack for minecraft, combining BlazeandCave's Advancements pack with my own datapack for a series I want to start, but I cant figure out how to code what I want exactly, since it seems like it never works. If anyone knows how to help me, heres what I was thinking of coding: Information: BlazeandCave's Advancements is a pack that adds more advancements to the game. I want every advancement to expand a starting border of 16 blocks every time by: Task: 1 Goal: 2 Challenge: 5 Super challenge: 20 I also don't want it so that if I get an achievement, my friends cant expand the border with that achievement no more. I also want to add a daily challenge of obtaining certain items, and gives me 3 lucky blocks on completion, but Im working on that later, rn im just stuck on the Achievement part. Im currently using https://code.visualstudio.com/ for all my coding. Help is appreciated My code: -datapack --data ---border\function ----check_adv.mcfunction: execute as u/a store result score u/s adv_now run scoreboard players get u/s bac_statistics execute as u/a if score u/s adv_now > u/s adv_old run worldborder add 1 execute as u/a if score u/s adv_now > u/s adv_old run scoreboard players operation u/s adv_old = u/s adv_now ----load.mcfunction: scoreboard objectives add adv_now dummy scoreboard objectives add adv_old dummy worldborder set 16 worldborder center 0 0 ----reward.mcfunction: scoreboard players add #adv adv_count 1 ----tick.mcfunction: function border:check_adv ---minecraft\tags\functions: ----load.json: {"values":["border:load"]} ----tick.json: {"values":["border:tick"]} --pack.mcmeta: { "pack": { "pack_format": 18, "description": "Border SMP datapack" } } -BlazeandCave's Advancements pack 1.20.2.zip submitted by /u/Initial-Honey-9865 [link] [留言]

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

The Quest Begins (The "Why") Honestly, I still remember the first time I stared at the Daily Temperatures problem on LeetCode and felt like I was trying to crack a vault with a toothpick. The brute‑force solution — two nested loops, checking every future day for a warmer temperature — was simple to write, but it timed out on the larger test cases. I spent an hour tweaking loops, adding early breaks, and even trying to memoize results, only to watch the same red “Time Limit Exceeded” banner flash again. I was frustrated, but more than that, I was curious. Why did this problem feel so repetitive ? Every element seemed to be asking the same question: “What’s the next greater value to my right?” If I could answer that for each index in a single pass, the whole thing would collapse into O(n). That’s when I remembered a weird little data structure I’d seen in a textbook — the monotonic stack — and realized it might be the magic wand I needed. The Revelation (The Insight) Here’s the thing: a monotonic stack isn’t just a stack with a funny name; it’s a way to capture relationships between elements without ever looking backward more than once . Imagine you’re walking through a line of people sorted by height, and you want to know, for each person, who is the first taller person standing ahead of them. If you keep a stack of people whose heights are strictly decreasing as you move from left to right, then whenever you see a new person taller than the one on top of the stack, you’ve just found the answer for that stacked person: the current person is their “next greater.” You pop them off, record the distance, and keep going. Because each index is pushed once and popped at most once , the total work is linear. The same idea works for “next smaller,” “previous greater,” or any problem where you need the nearest element that satisfies a monotonic condition. The stack does the heavy lifting of remembering candidates that could still be relevant, discarding the ones that are alrea

submitted by /u/Efficient-Public-551 [link] [留言]

There's a moment in every ambitious AI engineering project where you convince yourself that more agents means more power. I hit that moment early in building my Python orchestration framework — and I spent several painful weeks learning exactly why that intuition is wrong. The seductive pitch: decompose complex tasks into specialized sub-agents, run them in parallel, let them coordinate. What actually happened was a reliability nightmare that taught me more about agentic architecture than any framework documentation ever could. The Problem I Actually Built My Python orchestration system was designed to automate complex, multi-step workflows — the kind that require planning, research, code generation, and validation to happen in a coherent sequence. Early on, I structured it as a web of parallel agents: a planner, several workers, a validator, and a synthesizer, all exchanging structured messages. On paper it was elegant. In practice, it had three failure modes I couldn't engineer away: Context drift. Each agent only saw the slice of information it was handed. The worker writing one module couldn't see what the worker writing another module had decided. By the time the synthesizer tried to combine outputs, I had conflicting assumptions baked into the results — variable names that clashed, patterns that contradicted each other, interfaces that didn't align. Cascading partial failures. When one agent produced ambiguous output, every downstream agent amplified the ambiguity. A planner that returned a slightly underspecified task description produced workers that each interpreted it differently. Nothing failed loudly. Everything just drifted, quietly, until the final output was incoherent. Debugging opacity. When something went wrong in a parallel multi-agent system, tracing the failure was miserable. Was it the planner? One of the workers? The message-passing layer? I'd rebuilt the worst parts of distributed systems debugging inside a single Python process. The Architec

submitted by /u/Dear-Economics-315 [link] [留言]

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

Beyond the Prototype: Why Teams Need More Than Vibe Coding Over the last year, AI coding tools such as Lovable, Bolt.new, v0, Base44, and others have fundamentally changed how software gets created. A single founder or developer can now go from a rough idea to a working prototype in hours rather than weeks. That kind of acceleration is genuinely exciting, and it has opened software creation to far more people. That democratization is a good thing. Rapid experimentation, faster feedback loops, and lower barriers to entry are changing how products get started. Many successful companies and ideas will emerge because these tools made building more accessible. As I've followed the conversations happening around these tools—through reviews, articles, community discussions, and the experiences being shared by founders and engineering leaders—I've noticed an interesting pattern. The challenge is no longer getting to the first version. The challenge begins after. The Prototype Was Never the Finish Line The prototype works. Stakeholders become excited. Customers show interest. Momentum builds. Then a different set of questions starts to emerge. How do we align everyone on what we're building? How do we evolve an existing application instead of starting over? How do we maintain quality as complexity increases? How do multiple people collaborate without losing context? How do we know whether we're delivering the outcomes we intended? And how do we continuously improve without creating chaos? These aren't failures of AI coding tools. They're simply different problems. Many of today's AI builders are optimized for individual acceleration and rapid exploration. But once a promising idea becomes a product that teams must own, maintain, and evolve together, different requirements naturally emerge. What works for one person experimenting is not always enough for a group of people building something intended to last. Building Software Is More Than Generating Code Software development

Disclosure: This post includes affiliate links; I may receive compensation if you purchase products or services from the different links provided in this article. Hello friends, System design ** and ** Software design are two important topics for tech interviews and two important skills for Software developers. Without knowing how to design a system, you cannot create new software, and it will also be difficult to learn and understand existing software and systems. That's why big tech companies like FAANG/MAANG pay special attention to System design skills and test candidates thoroughly. Earlier, I have shared system design interview questions like API Gateway vs Load Balancer , Horizontal vs Vertical Scaling , Forward proxy vs reverse proxy , and common System design concepts , and in this article, I am going to share with you the best System design books to learn Software design. Whether you are a beginner or an experienced developer, you can read these books, as you will definitely find valuable stuff. I have read them, and even though I have been doing Software development for more than 15 years, I have learned a lot. System design ** is a complex process, and you need to know a lot of stuff to actually design a system that can withstand the test of time in production. Software architecture is another field where you are expected to learn a lot of things. It's simply impossible to become a software architect by reading a few books, but if you have experience and a hunger to learn, then these books can be a gold mine. These books allow you to learn from other people's experiences. You can read these books to find what challenges they face when they design a real-world system like Spotify, Google, or Amazon, and how they overcome. Each story is a journey in itself, and you will learn a thing or two by reading and then relating with your own experience. I love to read books, and they are my primary source of learning, along with online courses nowadays. In this art

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

submitted by /u/goto-con [link] [留言]

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

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

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

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

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

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