标签：#programming

I came across this on Hacker News and felt like I needed to share it with the dev community. The main point is simple: a lot of teams reach for extra databases, queues, search engines, caches, and services before they actually need them. This page lays out where Postgres is usually enough, and where you may actually need something else: https://postgresisenough.dev/ Postgres is not perfect for everything, but it is good enough for a surprising amount of real-world work. The more I build and maintain systems, the more I appreciate boring infrastructure that is easy to debug, monitor, back up, and reason about. This hit a nerve for me because I have seen stacks become harder to operate not because the product needed that complexity, but because the architecture was designed for future scale that never arrived. Curious how others here think about this. Where do you draw the line between “Postgres is enough” and falling into the sprawl trap? submitted by /u/danieltabrizian [link] [留言]

Passei os últimos dias construindo o HookSafe, uma camada que fica entre a plataforma de pagamento e o servidor do cliente para garantir que nenhum webhook se perca. A promessa do produto é uma só: se o seu servidor cair, eu seguro o evento e insisto até entregar. Cometi três bugs no caminho. O que me fez escrever este texto não foi a burrice de cada um, foi perceber, depois, que os três tinham a mesma forma: todos faziam uma falha parecer um sucesso. Num sistema cujo produto é confiabilidade, é difícil imaginar categoria de bug mais cruel. Bug 1: engoli o erro, e o sistema jurou que tinha entregue A função que entrega o evento no servidor do cliente ficou assim: go resposta, err := clienteHTTP.Do(requisicao) if err != nil { return "", nil // <- olhe com carinho } Eu quis escrever return "", err . Escrevi nil . O efeito: apontei o destino para uma porta onde não havia nada escutando. O Do devolveu um belo connection refused . E a minha função respondeu ao worker: "sem erro, chefe". O worker, obediente, marcou o evento como entregue , com o status da resposta vazio, e seguiu a vida. No banco: id | pedido_id | status | tentativas | resposta ----+-----------+----------+------------+---------- 6 | 9002 | entregue | 0 | Um evento que nunca saiu do lugar, registrado como entregue. Se isso estivesse em produção, um cliente teria pagado, não receberia nada, e o meu painel mostraria, orgulhoso, que a entrega foi um sucesso. Aquele if err != nil { return err } que a gente reclama de repetir em Go existe exatamente por isso. A linguagem te obriga a decidir o que fazer com a falha, toda vez. O preço da verbosidade é que ninguém engole um erro sem querer... a menos que digite nil . Bug 2: o log mentiu Corrigi o primeiro bug, rodei de novo, e o worker começou a cuspir isto, a cada cinco segundos, para sempre: worker: erro ao marcar morto 7: ERROR: column "reposta" does not exist worker: evento 7 esgotou as tentativas, marcado como MORTO Leia as duas linhas de novo. A primeira diz

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

"Show a smile, hide the blade." — The 36 Stratagems, Conceal a Dagger in a Smile Previously on...

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

I asked AI to help me write this article. Then I sat there for a second, thinking about how ironic...

It only took ten days to develop the language that powers the web. This article tells the story of JavaScript and the tools that helped shape it. 1995. The birth of a legend The idea for JavaScript was born at Netscape. At the time, web pages consisted almost entirely of HTML, and Netscape wanted to make them more interactive. The first step in that direction was licensing Java for use in the Netscape browser. However, Java's complexity proved challenging for web designers. Brendan Eich was then tasked with creating a programming language that wasn't too complex and could be embedded directly into HTML pages. Eventually, Marc Andreessen, co-founder of Netscape Communications, and Bill Joy, co-founder of Sun Microsystems, also contributed to the language development. To meet the deadline for the Netscape browser release, the companies agreed to collaborate on the language. During its development, the language changed its name several times. For example, the first version Eich created in just ten days was called Mocha. It was then renamed to LiveScript. The final name was chosen because the word Java was already popular and well-known. JavaScript was first announced shortly before the second beta release of Netscape Navigator. Meanwhile, Netscape announced that 28 leading IT companies planned to incorporate JavaScript into their future products. JavaScript 1.0 was released in 1996 alongside Netscape Navigator 2. 1997-1999. ECMAScript In 1996, Microsoft also released JScript as part of Internet Explorer 3, which was an open-source implementation of JavaScript for Windows. By the way, the name was changed to avoid negotiating trademark rights for Java with Sun Microsystems. To eliminate browser incompatibilities caused by different implementations, Netscape handed the JavaScript specification over to the ECMA international organization. So, the ECMA-262 specification was created. The language got the name ECMAScript because JavaScript was already trademarked. Around the

When people picture "coding," they picture fast typing and features coming to life. Nobody pictures the real majority of the job: staring at a stack trace or lets say a particular project trying to figure out why something that should work, isn't. Here's what nobody tells you starting out — getting good at debugging has almost nothing to do with how well you write code, and everything to do with how well you read. The real difference between beginners and experienced devs isn't complex knowledge — it's that experienced devs read carefully and form a hypothesis before touching anything. Beginners (me included) tend to skip straight to changing code and hoping. It feels faster. It rarely is. One thing i'd like to advise other fellow beginner devs is ....Slow down, read the error properly, and follow the stack trace to where it actually starts — not where it ends up. What's a bug that taught you this the hard way?

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

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

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

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

On July 8, 2026 I looked up a barcode that does not exist. Eight zeros. I sent them to Open Food Facts, the largest open nutrition database on the web, and it answered HTTP 200. Green light. Then I read the body: "status":0 , "status_verbose":"no code or invalid code" . A success code wrapped around a total miss. Ten seconds of trusting the status line and I would have written that empty result into a calorie tracker as if it were food. That is the whole post. The list of APIs is the easy part. The hard part is that a keyless food API hands you a clean 200 and a wrong answer, and it does it a slightly different way on almost every endpoint. A free food API here means a public nutrition, ingredient, or recipe endpoint that returns JSON with no API key, no signup, and no card. Not a CSV dump, not a partner form, not a portal from 2012. A real REST call you can paste into a terminal right now. I found eight that clear that bar, plus three worth knowing that quietly lean on a shared key. I re-verified every one with a live curl on July 8, 2026 (real HTTP code, real body, trimmed but never paraphrased). If you build calorie trackers, meal planners, grocery tools, or an AI agent that answers "how much sugar is in this," these are the lookups you reach for. Every one of them can lie to you with a 200. Here is the uncomfortable finding before the list. Keyless nutrition data in 2026 is mostly one project. Open Food Facts and its sibling databases (Pet Food, Products, Beauty, Prices) are six of the eight entries below: five distinct databases on one shared engine, with Open Food Facts itself showing up twice because it fails two different ways. Only two entries, Fruityvice and Wger, are independent, and Wger re-imports its data from Open Food Facts anyway. That concentration is not a weakness of the roundup. It is the point. Because it is one engine, the data-quality traps below are systemic, not one-offs. Learn them once and they repeat across the whole family. Let me be st

The biggest losses in software history were, with one deliberate exception, not attacks. They were silent, correlated, self-inflicted — and they teach the exact risk autonomous AI agents are about to make expensive again. At 9:30 in the morning on August 1, 2012, Knight Capital Group was one of the largest trading firms in the United States, executing a sixth of all the volume on the New York Stock Exchange. By 10:15 it was, for practical purposes, finished. In those forty-five minutes a piece of its own trading software (not a hacker's, its own) fired more than four million unwanted orders into the market, accumulating roughly $7 billion in positions the firm never meant to hold and a loss of about $440 million by the time humans understood what their machine was doing. The cause, documented in the SEC's administrative proceeding, was almost insultingly small: a deployment that updated seven of eight servers. The eighth still carried a dormant piece of code called Power Peg, retired years earlier, and the new release reused the old feature flag that woke it up. No one attacked Knight Capital. The market data was accurate, the exchange functioned perfectly, and every system reported itself healthy while the company bled ten million dollars a minute. That shape (no adversary, no alarm, one change propagating everywhere at once) turns out to be the shape of almost every entry on the list below. We've written before about the biggest bug-bounty payouts in history , the ledger of what it costs when someone does attack. This is the other ledger, the bigger one: what software has cost when nobody attacked at all. Every figure below states what it counts, and comes from a primary or authoritative source (inquiry boards, SEC filings, statutory inquiries) linked at the end. The ledger 1. CrowdStrike outage (2024) — roughly $5.4 billion in direct losses to Fortune 500 companies alone (estimate). One faulty content update to the Falcon Sensor security agent blue-screened Windo

Everyone talks about the build. Nobody talks about what happens the week after, when you go to actually tell people it exists and discover every distribution channel has its own quiet gatekeeping you didn't know about until you hit it. Hacker News flagged my Show HN before it ever reached the front page. Not rejected — flagged, silently, likely because the account posting it was brand new with a self-promotional link and zero history. No warning, no explanation, just gone from /newest for anyone not specifically looking. Reddit was worse in a different way. r/webdev's AutoMod rejects any submission from an account under three months old with low karma — a hard gate, not a soft one, and it doesn't care which day you post or how you phrase it. r/SideProject let the post through technically, but Reddit's own spam filter quietly removed it minutes later, invisible to everyone except me looking at my own profile. X was just silence. Zero followers means the algorithm has no graph to push the post into. Four views, three of which were probably me refreshing. The one channel that actually worked was the one with the lowest bar to entry: writing. dev.to doesn't gate you behind account age or karma. You write something, it's live, and if it's genuinely useful, people find it — slowly, but for real. That's where actual engagement happened. The pattern underneath all of this: almost every high-leverage distribution channel is, by design, hostile to accounts with no history. That's not a bug — it's the exact mechanism that keeps those platforms usable, and it exists specifically to stop people doing exactly what I was trying to do: show up once with a link and leave. The system is working as intended. It just doesn't feel that way when you're the one hitting the wall. What's actually working, three weeks in, isn't a growth hack — it's writing things people search for, verbatim, and being patient about everything else building account history the boring way: showing up, commenti

Shared tool configurations drift when developers run local agents. Adding a new MCP server to a team setup usually fails to reach existing local configurations, leaving developers with outdated toolsets. We resolved this in our latest CLI release by introducing stateful configuration back-filling. The update merges new servers into local environments while preserving custom developer adjustments. What's new Angular stack integration : Added frontend domain detection for angular.json and @angular/* packages in the /stack-set command. The oma-frontend skill now includes angular-rules.md to enforce standalone components, OnPush change detection, and signals. API evolution patterns : Added API lifecycle patterns based on the MAP framework to oma-architecture . This includes Sajaniemi's 11 variable-role taxonomy to guide naming rules in oma-refactor . Windows scheduling updates : The schtasks adapter now maps weekly cron ranges like 1-5 or lists like 1,3,5 directly to Windows task scheduler formats. Model validation : Added vendor validation to the schedule:add command. The CLI now rejects unknown models at registration time rather than failing during execution. Keeping local environments synchronized across diverse OS targets requires strict validation. These fixes ensure configuration changes flow correctly without disrupting developer-specific settings. What's fixed MCP server synchronization : Fixed an issue where SSOT servers added to .agents/mcp.json were only copied if .mcp.json was entirely absent. The CLI now reads the source of truth on every run and merges missing entries. Test execution reliability : Restructured the project root resolution tests to mock the filesystem walk. This isolates test runs from ambient files on CI runners and avoids false failures. Market diversity flags : Corrected the --diversity-threshold flag documentation to reflect that the default threshold is not enforced unless the flag is explicitly set. Cleaning up obsolete protocols reduc

Yo! what's up guys 👋🏻 Every developer👩🏻‍💻 has a different environment where ideas turn into...

Quick note before we dive in — I know I've been off track from the iOS/Swift series lately. I just...

The problem Doc references to a line number or function name break the moment code gets refactored. You write "see line 142 of foo.py " or "see calculateRefund() " in a design doc, then six months later the line has shifted or the function got renamed, and the reference just quietly points at the wrong thing (or nothing). Nobody notices until someone follows it and lands in the wrong place. The fix Anchor Pointing is a tiny text convention that swaps the location for a fixed ID. You drop an ID at the destination you want to be a durable reference target: ap.<21-char-base62-id>.E and reference it from anywhere else, docs, other code, tickets, with: ap.ref.<21-char-base62-id>.E Both are just literal strings, so resolving a reference is a plain text search: grep , ripgrep , GitHub code search, Sourcegraph, your IDE, whatever you already use. The ap.ref. prefix exists specifically so a search for the anchor itself never also matches its own references. Rules One anchor per ID (a single, unambiguous destination) Unlimited references pointing at that ID ID is 21-char base62, making collisions a non-issue with no central coordination Spec: https://github.com/nickolay-kondratyev/anchor-points/blob/main/ANCHOR_POINTS_SPEC.md Feedback welcome, especially if this already exists under another name and I've reinvented something. submitted by /u/ThorgBuilder [link] [留言]

Every API request needs to answer: who is this, and are they allowed? Session auth answers it by having the server remember every login. JWT answers it by making the client carry its own proof — no server memory needed. What's inside a token Header . Payload . Signature. Header and payload are just base64-encoded — readable by anyone, not encrypted. The signature is what matters: a hash of the header + payload, made with a secret key only the server knows. Change one character of the payload, the signature breaks, the server rejects it. Trust comes from the math, not from hiding the data. Client logs in with credentials Server verifies them, signs a token, sends it back Client attaches the token to every future request Server checks the signature — no database lookup Valid + not expired → request proceeds No session table anywhere. The auth state lives inside the token itself. The trade-off Can't instantly revoke a token — it's valid until it expires. Fix: short-lived access tokens + a revocable refresh token. Payload is readable, so never put sensitive data in it. Security comes from HTTPS + safe client-side storage, not secrecy. One-liner to remember it by Session auth: remember who logged in, check memory each time. JWT: remember nothing, verify the proof each time.