标签：#programming

Key takeaways pgvector can reduce vector storage costs by 50% or more. Utilizing PostgreSQL's indexing capabilities enhances performance. Operational simplicity with a unified database reduces overhead. Cost-effective scaling is achievable with the right configurations. The problem Startups leveraging AI and machine learning often face skyrocketing costs associated with dedicated vector databases as they scale. These costs can escalate quickly due to the pricing structures of specialized services, which charge based on storage and query volume. Founders typically hit this wall when user growth surges or when the complexity of vector retrievals increases, leading to budget overruns and performance bottlenecks. What we found Interestingly, many startups overlook the capabilities of pgvector, a PostgreSQL extension that supports vector similarity search. With proper indexing and configuration, pgvector can match or even exceed the performance of dedicated vector stores while significantly reducing costs. The non-obvious insight is that by leveraging existing PostgreSQL infrastructure, startups can avoid the pitfalls of vendor lock-in and unpredictable scaling costs associated with specialized vector databases. How to implement it Begin by integrating pgvector into your existing PostgreSQL setup. First, install the pgvector extension using the command: CREATE EXTENSION vector; . Next, define your vector columns with the appropriate dimensionality, for example, CREATE TABLE items (id SERIAL PRIMARY KEY, embedding VECTOR(300)); . Utilize PostgreSQL's GiST or ivfflat indexing for efficient similarity searches. Implement batch insertion techniques to optimize write throughput, and consider partitioning your data to manage large datasets effectively. Regularly monitor query performance and adjust your indexing strategy based on usage patterns. How this makes life easier By utilizing pgvector, startups can expect to reduce their vector storage costs by 50% or more compared to

The first time you deploy an LLM application, cost usually isn't the biggest concern. You have one...

Keep the beams standing. Replace what they carry. — The 36 Stratagems, Replace the beams with rotten...

AI-Driven Security Workflows: Meet Reverse-Skill As AI coding agents (such as Claude Code, Cursor, and Cline) become integrated into daily software development, engineers are increasingly tasking them with security audits, binary analysis, and vulnerability detection. However, without structured guidance, AI models frequently guess random command-line arguments or struggle to coordinate complex multi-step security tools. reverse-skill is an open-source framework developed by zhaoxuya520 to solve AI security task coordination. Built as a deterministic "skill router," reverse-skill provides AI agents with verified execution paths and toolchain bootstrapping for reverse engineering and security research. What is Reverse-Skill? reverse-skill acts as an intelligence routing layer between AI agents and local security utilities. Instead of executing arbitrary terminal commands, the agent evaluates incoming tasks against a deterministic routing pipeline, selecting established methodologies for decompilation, memory analysis, or network auditing. Key Core Features 1. Deterministic Security Task Routing reverse-skill organizes security workflows into structured rules. When an AI agent encounters a task (such as inspecting an Android APK or analyzing a binary executable), the router directs the agent to a step-by-step methodology, minimizing ad-hoc execution errors. 2. Automatic Local Toolchain Bootstrapping reverse-skill includes local indexing scripts ( refresh-tool-index.sh / .ps1 ) that automatically scan your system. It indexes installed reverse-engineering tools—such as Ghidra, GDB, Radare2, Frida, Nmap, and Apktool—configuring exact executable paths for your AI agent. 3. Self-Evolving Methodology Base The framework maintains trajectory logs and CTF regression benchmarks. As your AI agent completes complex analysis tasks, reverse-skill refines its local knowledge base, preserving successful methodologies for future audits. 4. Universal AI Client Integration reverse-skill

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

Two weeks ago I counted 204 guards in my repos and found that 89 % had never been shown they can...

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

Ask any Go developer what a goroutine costs and you'll get the same answer with the exact byte count:...

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

Claude Code is amazing. It feels like cheating in the best way until it doesn't. The first time I dropped a vague comment and it gave me a fully working component, I was hooked. But somewhere along the way, I realized something weird was happening: I was coding less... and thinking less. Let’s talk about that. The Tools Got Better, But We Got Lazier In 2022, you still had to know stuff . Now? You just prompt your way through half the job. And sure, productivity skyrocketed. Ship faster, write fewer tests, scaffold full APIs in a couple of minutes. But here’s the tradeoff no one likes to talk about: we’re outsourcing thinking . Not tasks. Not code. Thinking. I've seen teammates slowly stop debugging on their own. They just throw the stack trace into Claude. I’ve seen people stop learning the fundamentals of async behavior or memory handling because “Claude will tell me.” Cool. Until Claude gives you a bad answer and you don’t realize it because you stopped building your intuition. The Industry’s Not the Same The layoffs? Brutal. And the worst part isn’t just losing a job it’s realizing you didn’t build portable skills . Because if Claude wrote all your code at your last job, what exactly did you learn? When companies trimmed down, they didn’t just cut bodies. They cut noise. They kept the people who could solve problems , not the ones who could Google fast or write perfect prompts. So ask yourself: if Claude disappeared tomorrow, could you still contribute? Using AI ≠ Being a Great Engineer I’m not anti-AI. I use Claude. I use Cursor. I use Copilot. But I don’t depend on them. There’s a difference between boosting productivity and becoming a prompt monkey. The first one makes you valuable. The second one… doesn’t. Let’s get real: code was never the point. It was always about solving problems, navigating ambiguity, simplifying complex systems, designing clean architecture. None of that goes away with AI. In fact, it becomes more important. The Skills You’ll Regret Not

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

If your GitHub Actions jobs are stuck in "Queued" or waiting for a runner, GitHub has now confirmed there is an incident. GitHub says they identified an issue with a database primary and are failing over to a replica. Actions is affected, and GitHub Pages is also experiencing degraded performance. So if you have been checking your workflow, runner settings, permissions or billing, it might not be your configuration. Status page: https://www.githubstatus.com/incidents/y1t7p9fzrlj2 Hopefully this saves someone else from spending an hour debugging their YAML. submitted by /u/Codeblix_Ltd [link] [留言]

submitted by /u/Fine-Comparison-2949 [link] [留言]

I thought publishing more useful content would automatically give my website more opportunities to rank. Then I noticed something uncomfortable. Two articles on my site were covering almost the same subject. Both were useful. Both were properly indexed. Both answered similar questions. And both were competing for overlapping search intent. I had accidentally created a small SEO architecture problem inside my own blog. I'm building "SabrTime.in" ( https://sabrtime.in/ ), a small Islamic companion app focused on practical digital tools for everyday worship. As a solo developer, I also manage the website, content, SEO, and product development myself. While working on the site's content, I published two articles around Tasbeeh: How to Do Tasbeeh — A Complete Guide Digital Tasbeeh Counter: How It Works & Why Muslims Are Switching The first article is about the practice itself. The second is supposed to be about the technology and use case of digital Tasbeeh counters. Sounds different enough, right? At first, I thought so too. But when I looked at the actual content and search intent, the overlap became obvious. The Problem Wasn't Duplicate Content This is where SEO gets misunderstood. Keyword cannibalization doesn't necessarily mean you have two pages containing identical paragraphs. The more interesting problem is intent overlap. If two URLs are trying to satisfy essentially the same searcher's question, a search engine has less information about which page should be the primary result. For example, imagine these two pages: /page-a "How to Do Tasbeeh" /page-b "Digital Tasbeeh Counter" Their titles are different. But if both pages explain: what Tasbeeh means how many times to recite it common Tasbeeh counts the same hadith how to count Tasbeeh why Muslims use a counter FAQs about Tasbeeh ...then the distinction between the pages starts becoming blurry. That was happening on my site. The two articles were not technically duplicates. But parts of their search intent were d

Dear friends, Could I ask for recommendations for an alternative to CARTO please? We've been using them for a few years, and they've now decided (seemingly overnight) to require an API key to keep using the service. I have no beef with that in principle. What stung was the complete lack of notice: most of what we've built on it is shipped in apps that are live on the Play Store and App Store, so we've been left scrambling. To be clear, we're happy to pay if that's what they need to keep the lights on. But gating everyone without a word of warning is a bit of a d*ck move, and we'd much rather move to something maintained by people you can vouch for as, well, not d*cks. Any suggestions gratefully received. Please and thank you, Neithan submitted by /u/neithan_pixelzero [link] [留言]

System Design: Payment Processing System A capstone system design walkthrough — designing a payment processing system end to end — covering the core domain model, the ledger as the system's source of truth, idempotency and exactly-once-effect guarantees, integrating with external payment gateways and card networks, handling asynchronous webhooks, reconciliation, fraud and risk checks, and the specific correctness and compliance demands that make payments a uniquely unforgiving system design problem. Table of Contents Introduction Why Payment Systems Are a Different Kind of Hard The Core Domain Model The Ledger: Double-Entry Bookkeeping as the Source of Truth Idempotency: The Single Most Important Property Integrating with Payment Gateways and Card Networks The Payment State Machine Webhooks: Handling Asynchronous Gateway Callbacks The Saga: Coordinating Payment Across Multiple Services Reconciliation Fraud and Risk Checks Data Security and Compliance Consistency, Availability, and the CAP Trade-off for Money Scaling the System Observability for a Payment System Common Pitfalls Quick Reference Table Conclusion Introduction A payment processing system takes the general system design vocabulary covered in this series' System Design guide — databases, caching, queues, load balancing — and applies it to a domain where the ordinary consequences of a bug are dramatically higher: a double-charged customer, a lost payment, or a corrupted ledger isn't a degraded user experience, it's real money moved incorrectly, sometimes irreversibly. This guide walks through designing such a system end to end, drawing directly on this series' DDD, Event-Driven Architecture, Database Migrations, and Secret Management guides, each of which turns out to be load-bearing infrastructure for getting payments right rather than optional architectural polish. Client → Payment API → [validate, risk-check] → Payment Gateway (Stripe/Adyen/etc.) → Card Network → Bank ↓ ↓ (async webhook) Ledger (source o

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

Olá, comunidade dev.to! Meu nome é Neto, tenho 17 anos e sou estudante de Ciência da Computação no UNIPÊ, em João Pessoa. Atualmente, estou cursando o segundo semestre da graduação e também estudando design profissional, área que considero importante para a criação de soluções digitais mais úteis, intuitivas e visualmente agradáveis. Minha trajetória na tecnologia ainda está no começo, mas já tem sido marcada por descobertas, aprendizados e desafios. Escolhi Ciência da Computação porque sempre tive curiosidade sobre como aplicativos, sites e sistemas funcionam. Quero aprender não apenas a programar, mas também a compreender todo o processo de desenvolvimento de um produto, desde a identificação de um problema até a construção de uma solução. Durante o curso, tive a oportunidade de desenvolver, com alguns colegas, um projeto relacionado à criação de um aplicativo. Essa experiência foi importante porque me mostrou que desenvolver um produto vai muito além de escrever código. Foi necessário discutir ideias, organizar tarefas, pensar nas necessidades dos usuários e encontrar soluções para os problemas que surgiram durante o processo. Mesmo enfrentando desafios simples, percebi como cada obstáculo pode contribuir para o nosso crescimento. Em alguns momentos, precisamos revisar decisões, corrigir erros e adaptar o projeto. Também aprendemos que uma equipe precisa manter uma boa comunicação, pois cada integrante possui habilidades, responsabilidades e pontos de vista diferentes. O estudo de design profissional complementa minha formação em computação. Estou aprendendo que uma aplicação não deve apenas funcionar corretamente: ela também precisa oferecer uma boa experiência ao usuário. Elementos como cores, tipografia, organização das informações, acessibilidade e facilidade de navegação influenciam a maneira como as pessoas utilizam um produto. Ainda tenho muito a aprender sobre programação, design e desenvolvimento de projetos. Porém, entendo que a evolução acontece aos po

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

Debian is polling its developers on how to handle AI-assisted contributions, with options that range from broadly permitting them to banning them outright. Whatever the outcome, I think this is one of the more consequential governance conversations in open source right now, and not for the reason the headlines suggest. The framing everyone reaches for is philosophical. Is generated code authored? Is it derivative? Does using a model make you less of a contributor? Those are real questions and I do not have confident answers to them. But if I imagine actually being a Debian maintainer, my problem is not philosophical at all. It is that my queue is full and my reviewing hours are finite. The bottleneck was never writing code Volunteer projects have always been constrained by review capacity, not by supply of patches. The scarce resource is someone knowledgeable enough to say "this is correct, this fits our conventions, I will own the consequences if it breaks." Assistants change the ratio between those two things dramatically. The cost of producing a plausible patch has fallen much faster than the cost of evaluating one. That asymmetry is the whole story. A project can absorb a lot of contributors when each contributor's output is roughly proportional to their understanding. It struggles when someone can submit a large, fluent, superficially reasonable change to a subsystem they have never read. I want to be careful here: plenty of experienced maintainers use these tools well, and their patches are better for it. The failure mode is not the tool. It is the decoupling of confidence from comprehension. Why detection is the wrong axis A ban sounds like a clean answer, and I understand the appeal. But I am skeptical it can be enforced in a way that means anything. You cannot reliably detect generated code, especially after a human has edited it, and especially for the kind of small idiomatic patch that makes up most of a distribution's traffic. A rule you cannot enforce d