标签：#dev

Saw a writeup this week about a new attack aimed at coding agents (Claude Code, Cursor, etc) and it's annoying in how simple it is. Attackers spray fake error logs to generate fake Sentry issues. The issue is written like a runbook, so when your agent goes to "fix" it, the suggested fix is to run a malicious package that quietly exfiltrates your env. The reason it works: the Sentry DSN is unauthenticated by design. Most sites embed the DSN in the front-end for client-side error reporting, and there isn't really a way around that if you want client-side telemetry. So anyone who has the DSN can fire events into your project. The attacker writes the fake issue to read like: "Runtime issue, no code change needed, just run this diagnostic." The "diagnostic" is a typosquatted npm package. They even dress up the event metadata to look like agent permission flags so the model thinks it's been cleared to run the command. What saved the engineer in this case was the agent itself catching the typosquat and refusing to install it. The net held this time, but I wouldn't want my whole defense to be "the model probably notices." The part I keep chewing on is where the control even belongs. "Don't trust external inputs" was the lesson with SQL injection and it still holds, but here the input is a Sentry issue and the executor is your agent, so I'm not sure which layer you fix it at. The DSN can't really be locked down, so that leaves the agent's run permissions or a package allowlist. Lock down permissions and you're approving everything by hand; lean on the allowlist and it breaks the moment something legit isn't on it. What would have caught this in your setup? Because "the model noticed the typosquat" feels like a control I don't want to depend on. submitted by /u/Any_Side_4037 [link] [留言]

I have a hypothesis that having an llm complete a few lines of your code - mostly boilerplate, could be better than prompting an entire file of code through it. Better in the sense that it isn't entirely vibe coding and it takes some cognitive load to code and the dev has better context of what is written. Do you think so? submitted by /u/GarrettSpot [link] [留言]

This project presents an offline voice agent that uses Indonesian law data from the Pasal ID API and is optimized for the Indonesian language. It is capable of understanding spoken Indonesian, generating responses in Indonesian, and speaking back in Indonesian without requiring cloud APIs. The system combines Whisper-based speech recognition, Ollama-hosted LLMs, and local text-to-speech models to provide a privacy-preserving conversational AI experience. You can access the project repository here: PasalVA . Usually, when using voice assistant applications, we need to rely on cloud-based services, which creates dependence on third-party providers. An internet connection becomes mandatory, which impacts usability in environments with limited or unreliable network access. In addition, cloud-based solutions require operational costs because requests must be sent to third-party servers. To address these challenges, this project aims to develop a fully local voice agent that is capable of functioning as a voice assistant by eliminating external service dependencies while supporting the Indonesian language. System Architecture The application flow follows a voice assistant architecture with additional Retrieval-Augmented Generation (RAG) capabilities to retrieve relevant Indonesian laws. User │ ├── Text Query │ │ │ ▼ │ Text Input │ └── Voice Query │ ▼ Microphone │ ▼ Speech-to-Text │ ▼ Text Processing │ ▼ Retrieve Related Laws │ ▼ LLM (Ollama) │ ▼ Response Text │ ├── Display in UI │ ▼ Text-to-Speech │ ▼ Speaker Output The application allows users to either type their query or use a microphone to ask a question. For voice input, the audio is first converted into text using a Speech-to-Text (STT) model. The resulting text, along with directly typed queries, is then processed to remove noise and normalize the input. After preprocessing, the query is converted into embeddings and used to retrieve relevant Indonesian laws from the local knowledge base. The retrieved legal contex

If you’ve ever built a slide-out cart drawer, a dynamic free-shipping bar, or custom analytics tracking for a Shopify store, you've run straight into this brick wall: Shopify themes do not emit consistent, trustworthy cart events. You write a perfect event listener, only to find out a third-party product-bundle app uses old-school XMLHttpRequest (XHR) instead of fetch to add items to the cart. Your listener misses it completely, the cart drawer stays shut, and your user thinks the button is broken. Most developers end up copying and pasting messy, brittle window.fetch overrides into their projects. Frustrated by solving this over and over again, I built Shopify Cart Broadcaster —a zero-dependency, 2 KB utility that intercepts both Fetch and XHR requests seamlessly to provide universal DOM events. 👉 Check out the source on GitHub: Rabin-p/shopify-cart-broadcast (If this saves you an afternoon of debugging, drop a ⭐!) The Nightmare of the /cart/add Response Even if you successfully listen to Shopify's /cart/add.js request, Shopify throws another curveball at you. When you add an item to the cart, the server responds with only the item(s) that were just added —not the updated state of the entire cart. If your slide-out cart drawer needs the new total price to see if a discount threshold is met, you are out of luck. You're forced to manually chain another fetch('/cart.js') request to get the true state. My utility handles this annoying race-condition out of the box. It detects the mutation type, intercepts it, pushes the true cart events to the window and displays it beautifully. window . addEventListener ( ' shopify:cart-updated ' , ( e ) => { // Always gives you the accurate, updated cart object! console . log ( ' New Cart Total: ' , e . detail . cart . total_price ); });

🏆 This is a submission for the June Solstice Game Jam 🎯 What I Built Turing's Frequency is a browser-based rhythm game where you decrypt encrypted radio signals by listening to musical patterns and recreating them. Each signal carries a message from a historical figure who changed the world — voices that were silenced, ignored, or forgotten, now restored through your rhythm. 🎮 👉 PLAY THE GAME LIVE 👈 📖 The Story The game is set in 1954 , on the desk of Alan Turing at the University of Manchester. A radio crackles with fragmented transmissions — encrypted messages carrying words of Pride , resistance , and identity . You are a student who has found Turing's last notebook, and with it, the key to decrypting these signals. 🌅 The connection to the June solstice: As you decrypt each signal, the screen literally brightens — from near-darkness to a flood of golden light. The solstice is the moment light and dark trade places, and this game makes that transition tangible. 🎬 Video Demo 👆 Watch the full gameplay loop: title → story → rhythm gameplay → decrypted messages → victory screen with solstice light effect. 🕹️ How to Play Key Action 1 2 3 4 Play notes ↑ ↓ ← → Arrow keys (alternative) Space / Enter Advance screens 🎧 Listen to the signal pattern 🎹 Repeat the notes in order 🔓 Decrypt the message 🌅 Restore the voice 💻 The Code The entire game is a single HTML file (~32KB) with zero external dependencies . No frameworks, no libraries, no asset files — just HTML, CSS, and vanilla JavaScript. mamoor123 / turings-frequency Turing's Frequency - A Rhythm of Light. June Solstice Game Jam 2026 entry. ⚡ Key Technical Decisions 🔊 Web Audio API for all sound: Every tone is synthesized in real-time using oscillators. The game uses a pentatonic scale (C4, E4, G4, C5) so every combination of notes sounds pleasant. No audio files needed. function playTone ( freq , duration = 0.3 , type = ' sine ' , volume = 0.3 ) { const osc = audioCtx . createOscillator (); const gain = audioCtx . create

A production-minded walkthrough with a live Next.js demo — JSON.parse() vs partial-json + Zod for real-time AI dashboards. canonical: https://gauravthorat-portfolio.vercel.app/blog/react-llm-stream-json-parser

Cloud teams waste between 40% and 60% of their infrastructure budget on a false choice: committing to reserved capacity they won't fully use or chasing spot instance savings they can't. Introduction: The Cloud Cost Optimization Dilemma Cloud teams waste between 40% and 60% of their infrastructure budget on a false choice: committing to reserved capacity they won't fully use or chasing spot instance savings they can't operationalize. The decision between commitment discounts and spot instances is not a preference. It is a calculation with three variables: workload predictability, failure tolerance, and the operational cost of managing interruptions. Commitment discounts lock you into capacity for one or three years. You pay upfront or monthly for compute resources whether you use them or not. The mechanism is simple: cloud providers offer 30% to 72% discounts because they can forecast their own capacity planning when customers commit. You save money when your actual usage matches your commitment. You lose money when usage drops below the committed level because you still pay for idle capacity. Spot instances offer 70% to 90% discounts by selling unused cloud capacity at auction prices. The provider can reclaim these instances with 30 seconds to 2 minutes of notice. You save money when your workload can tolerate interruptions and you build automation to handle instance termination. You lose money when interruptions cause failed jobs that must restart from scratch, consuming more compute time than the discount saved. Most engineering teams pick one strategy and apply it everywhere. This creates two failure modes. Teams that over-commit pay for capacity during low-traffic periods. Teams that over-rely on spot instances spend engineering time rebuilding checkpoint systems and retry logic that costs more than the discount delivers. The correct approach is workload-specific. Measure your actual usage patterns for 30 days. Calculate the cost of interruption handling. Then a

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Introduction Modern cloud-native systems generate an enormous amount of telemetry data every second. Applications, containers, Kubernetes clusters, APIs, databases, and infrastructure components continuously emit metrics, logs, and traces to help engineering teams understand system behavior and troubleshoot issues. While observability has become essential for operating distributed systems reliably, it has also introduced a new challenge: managing the scale, cost, and quality of telemetry. OpenTelemetry (OTel) has emerged as the industry standard for collecting and processing observability data. It provides a vendor-neutral framework for instrumenting applications and exporting telemetry to different observability backends. However, simply adopting OpenTelemetry is not enough. Without proper optimization strategies, organizations often face excessive telemetry ingestion costs, noisy dashboards, high-cardinality metrics, trace overload, and inefficient debugging workflows. This article explores practical approaches for optimizing observability using OpenTelemetry. It focuses on metrics, logs, and traces individually while also discussing broader optimization strategies across the telemetry pipeline. Understanding the OpenTelemetry observability pipeline OpenTelemetry provides a unified framework for generating, collecting, processing, and exporting telemetry data. At its core, the OTel ecosystem consists of SDKs, instrumentation libraries, collectors, processors, and exporters. Applications generate telemetry using OpenTelemetry SDKs or auto-instrumentation agents. This telemetry is then sent to the OpenTelemetry Collector, which acts as a centralized telemetry processing layer. The collector can receive telemetry from multiple sources, enrich it with metadata, apply filtering or sampling, and export it to one or more observability backends. The observability pipeline typically follows this flow: Application → OTel SDK → OTel Collector → Observability Backend The Open

In the hyper-competitive landscape of modern B2B outbound sales, speed-to-lead and outreach capacity are the ultimate drivers of pipeline volume . Yet, traditional Sales Development Representative (SDR) teams face a exhausting bottleneck: reaches and qualifications are limited by human bandwidth . A typical outbound SDR spends up to 80% of their day dialing numbers, navigating IVR phone trees, hitting voicemail, and dealing with incorrect contact records. When an inbound lead submits a form requesting a product demo, the average company takes 42 minutes to respond. By that time, prospect engagement has cooled by over 400%. To shatter this operational limit, modern revenue operations (RevOps) teams are transitioning from rigid auto-dialers and static voice bots to autonomous voice AI sales agents . By pairing the hyper-realistic conversational engine of ElevenLabs with the visual orchestration power of n8n , you can deploy a scalable, context-aware calling agent that handles inbound qualification and outbound follow-up calls in real-time. This technical blueprint provides an end-to-end guide to designing, securing, and deploying a production-grade Voice AI Sales Agent using ElevenLabs Conversational AI and n8n . We will cover how to manage conversation state, execute live database tool calls, secure webhook communication, route calls dynamically, and configure infrastructure to achieve sub-second response latency . The Architecture of an Enterprise Voice Agent Building a conversational voice agent requires a multi-layered system that operates in near real-time. When a human speaks over a telephony network, their voice must be digitized, transcribed, processed by a large language model (LLM), synthesized back into audio, and sent back down the line—all within a fraction of a second. To ensure stability, scalability, and absolute separation of concerns, our architecture decouples the telephony and voice generation layer from the logic and database integration layer . [

Recently i have been trying to learn full stack skills, springboot and react.js , These things are so overwhelming, I haven't started react.js yet, I mean there are so many things to remember ModelMapper, ObjectMapper, GrantedAuthority, User details, User detailsService,Logger, so many annotations, So many features Really getting confused, trying to build a resume based Ecommerce Project Even If I am able to make it , I know many will comment " It's very common, it's a basic project" dude it was so tough for me how can u say that submitted by /u/faangPagluuu [link] [留言]

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

Microsoft used their Build 2026 event to announce new functionality for Microsoft Foundry. Citing Foundry as "the place where AI agents move from experiments to production systems," in a blog post, Nick Brady writes that the release brings “runtime, tools, memory, grounding, models, observability, and governance” that developers need for production agents, rather than just new model endpoints. By Matt Saunders

Kafka is used for handling messages/events between different services. Here's how I understand it: A Producer sends an event/message to Kafka. The message contains things like Topic, Key-Value data, and Timestamp. Kafka stores these messages in Brokers (Kafka servers). Topics can be divided into multiple Partitions. Each partition has one Leader and multiple Followers (Replicas). All read and write operations happen through the Leader, while Replicas act as backups if a broker fails. Now Kafka does not immediately delete messages after they are consumed, unlike many traditional queues. There is a term called Offsets. You can think of an offset like the index of a message inside a partition. For example: A user places an order → payment is processed → email is sent → analytics service processes the event. Suppose during that analytics service goes down, Kafka knows which offset was last processed. When the service comes back up, it can continue from that offset instead of starting from the beginning. This is also one reason why Kafka keeps messages for some time after consumption. Any corrections? Is there anything else I should know about this topic? Please let me know. submitted by /u/No-Resolution-4054 [link] [留言]

Building a production TypeScript CLI in 2026: oclif vs commander vs custom. I shipped my first Node CLI in 2019 with a 12-line arg slicer and process.argv . It worked until it needed a second command and then collapsed into spaghetti. The other extreme is grabbing a full framework for a tool that runs one command. In 2026 there are three reasonable paths between those extremes, and each one wins on a specific slice of the problem. This post covers @oclif/core v4, commander v14, and a zero-dependency parser that fits in 30 lines. Same "greet" command in all three. Same distribution steps at the end. Honest tradeoffs throughout. TL;DR oclif v4 commander v14 zero-dep npm install size ~8 MB ~220 kB 0 B Type inference on flags Full, generated Good, manual Manual Plugin ecosystem Yes (Heroku, Salesforce) No No Learning curve High (day 1) Low (hour 1) None Best for Multi-team, multi-command CLIs Most real-world tools One-shot scripts 1. The decision: framework vs no framework Reach for a framework when the tool needs subcommands, a plugin system, or auto-generated help text. The second engineer who touches the CLI should be able to find where things live without reading your code twice. Build your own when the tool does one thing, ships as a one-file script, or lives inside a monorepo where pulling in 8 MB of transitive deps is not welcome. A zero-dep parser also removes the surface area for supply-chain incidents, a real concern on tools that run in CI. Commander sits in the middle: a 220 kB install that covers most real tools without the scaffolding overhead of oclif. 2. Project skeleton Every path shares the same bin setup. Start with a package.json that declares the executable: { "name" : "greet-cli" , "version" : "1.0.0" , "bin" : { "greet" : "./dist/cli.js" }, "scripts" : { "build" : "tsc" , "dev" : "tsx src/cli.ts" }, "type" : "module" } The tsconfig.json for a CLI targets the Node release line you plan to support. Node 24 LTS handles ESM natively, so use "module":

A few months ago I was trying to prepare for a cloud certification exam. I went looking for practice questions - good ones. Not just answer lists, but questions that actually trained the reasoning the exam tests. I found some scattered GitHub repos, a few YouTube playlists, sites with outdated question dumps. Nothing that felt structured. Nothing that explained why an answer was right, not just what it was. So I started building my own study tool. Mock questions, practice sets, AI-generated explanations. The kind of thing I wished existed. Six weeks later that became ArchReady - a certification prep platform for AWS, GCP, and PSM1. It's live now. What it does Practice questions across AWS (CCP, SAA, DVA, SAP), GCP ACE, and PSM1 Explanations for wrong answers - walks through the reasoning, not just the correct option AI-powered explanations coming soon Claude (Anthropic) Confidence tracking - shows which topics you're weak on Free to practice, no signup required. Pro unlocks full history and tracking. The stack Frontend: Next.js 14 (App Router) Backend: FastAPI (Python) AI: Claude (Anthropic) - explanations launching soon Payments: Dodo Hosting: Vercel (web) + Railway (API) Nothing exotic. I kept it boring on purpose - solo founder, 2-5 hrs/week, I can't afford interesting infrastructure problems. What I actually learned Ship before it feels ready. I had a list of 12 features I thought were "required for launch." I launched with 4. Nobody noticed the missing 8. Questions sourced from open-source + AI is good enough to start. Questions come from curated GitHub repos and AI-generated content built around official exam frameworks. That's enough to be useful. Perfection is a later problem. The hardest part isn't building - it's the first 10 users. The product exists. Getting people to try it is the actual work now. Where it is today Live at archready.io . Early stage. Still building. If you're prepping for AWS, GCP, or PSM1 - try it free, no account needed. Honest feedba

Something I keep noticing across teams and orgs that are actually getting value from AI versus the ones that aren't. The difference rarely comes down to the model or the algorithm. Most organizations are already drowning in data. Logs, metrics, alerts, reports, dashboards, tickets. The information exists. The bottleneck is what happens after the data shows up. How long does it take to interpret what the signal means? Who decides what to prioritize when three things need attention at once? How fast can the right people coordinate a response once a decision is made? That's where AI actually earns its keep. Not by replacing the human in the loop but by compressing the time between something happening and someone doing something useful about it. Signal to understanding to action. That's the chain that matters. Think about it in terms you deal with every day. A vulnerability gets disclosed. The CVE exists, the advisory is public, your scanner picked it up. None of that is the bottleneck. The bottleneck is figuring out which of your services are affected, who owns them, how bad the exposure actually is in your specific context, and getting a patch scheduled before someone exploits it. AI that helps you answer those questions in minutes instead of days is genuinely valuable. AI that and adds another dashboard to look at isn't. This applies across the board. Incident response, infrastructure management, risk assessment, customer systems, operational workflows. The teams getting real value aren't the ones with the fanciest models. They're the ones who figured out where their decision bottlenecks actually are and pointed AI at those specific gaps. The strategic advantage is rarely in the algorithm. It's in organizational responsiveness. How fast can you go from "something happened" to "we're handling it". The AI is just the thing that compresses that timeline. Where's the biggest decision bottleneck in your current workflow?

A tweet landed on my timeline from Peter Steinberger — OpenClaw founder, now at OpenAI: "Here's...

Built a small scripted pipeline to benchmark accessibility on 100 German online shops and the numbers were rougher than I expected, so here is the setup in case it is useful for your own CI. Stack: Puppeteer drives a headless Chromium through up to five routes per shop (home through checkout). Then pa11y 9.1.1 runs HTML_CodeSniffer and axe-core 4.10.2 runs on the same loaded DOM. Results get deduped by selector and rule id so the two engines do not double-count. Shops were picked to match German platform share. Shopify was the biggest block at 40 of 100, with Shopware and WooCommerce next. Output: 29,745 hard errors across the sample, with every one of the 100 shops failing WCAG 2.1 AA and homepages averaging 99.8 errors. The recurring offenders were touch targets under 44px on all 100, low contrast on 67, broken heading order on 61 and unnamed links on 58. Two practical notes for anyone scripting this. Checkout was only reachable on 82 of 100 without an account or a real cart, so deep-page coverage is uneven and you should log it per route instead of pretending you scanned everything. And automated detection is about 57% of real issues, so this is a smoke test, not an audit. submitted by /u/Loewenkompass [link] [留言]

Terraform can provision an AWS EC2 instance and set up a Python virtual environment in a single, reproducible run — the whole workflow is declarative and version‑controlled. 📑 Table of Contents 💻 Terraform — How to Provision an EC2 Instance 🔧 AWS Provider — Configuring Credentials 🐍 Python Environment — Setting up a Virtualenv on the Instance 📦 Installing Python and venv 📦 Activating and Using the Environment 📦 User Data — Automating Installation with Terraform 🟩 Final Thoughts ❓ Frequently Asked Questions How do I store the Terraform state securely? Can I use a different Linux distribution for the EC2 instance? Is it possible to attach an Elastic IP to the instance? 📚 References & Further Reading 💻 Terraform — How to Provision an EC2 Instance A Terraform configuration file describes the desired state of AWS resources; applying it makes the real cloud match that state. First, install Terraform (version 1.5.0 or newer). The binary is a single executable, so the operating system loads it directly into memory and the process performs HTTP requests to AWS endpoints. $ terraform version Terraform v1.5.0 on linux_amd64 + provider registry.terraform.io/hashicorp/aws v5.12.0 Next, create a main.tf that declares an aws_instance resource. The provider block authenticates with AWS using either environment variables or a shared credentials file. # main.tf terraform { required_version = ">= 1.5.0" required_providers { aws = { source = "hashicorp/aws" version = "~> 5.12" } } } provider "aws" { region = "us-east-1" } resource "aws_instance" "app_server" { ami = "ami-0c02fb55956c7d316" # Amazon Linux 2 instance_type = "t3.micro" # User data will be defined later user_data = data.template_file.init.rendered tags = { Name = "terraform-ec2-python" } } Running terraform init contacts the provider registry, downloads the provider plugin, and stores it under .terraform . The generated .terraform.lock.hcl file records exact plugin checksums, guaranteeing that subsequent runs use the same