标签：#dev

DevSecOps Pipeline — Completion Runbook All code is written and pushed to GitHub. This runbook covers the remaining operational steps: Terraform applies, GitOps ARN updates, and ArgoCD deployment. Prerequisites Install these tools if not already present: # AWS CLI v2 winget install Amazon.AWSCLI # Terraform 1.6+ winget install HashiCorp.Terraform # Terragrunt # Download from https://github.com/gruntwork-io/terragrunt/releases # Place in C:\Windows\System32\ or add to PATH # kubectl winget install Kubernetes.kubectl # ArgoCD CLI winget install argoproj.argocd AWS Profile Setup The root terragrunt.hcl uses profiles named myapp-{env}-{region_alias} . Configure them in ~/.aws/config : [profile myapp-production-use1] region = us-east-1 role_arn = arn:aws:iam::591120834781:role/AdministratorAccess source_profile = default [profile myapp-production-usw2] region = us-west-2 role_arn = arn:aws:iam::591120834781:role/AdministratorAccess source_profile = default [profile myapp-staging-use1] region = us-east-1 role_arn = arn:aws:iam::690687753178:role/AdministratorAccess source_profile = default [profile myapp-staging-usw2] region = us-west-2 role_arn = arn:aws:iam::690687753178:role/AdministratorAccess source_profile = default [profile myapp-dev-use1] region = us-east-1 role_arn = arn:aws:iam::557702566877:role/AdministratorAccess source_profile = default [profile myapp-dev-usw2] region = us-west-2 role_arn = arn:aws:iam::557702566877:role/AdministratorAccess source_profile = default PHASE 1 — Terraform Applies Work from the myapp-infra/ directory. Run in the order shown — capture outputs for updating GitOps files in Phase 2. 1.1 WAF (production + staging) # Production us-east-1 terragrunt apply --terragrunt-working-dir live/production/us-east-1/waf # Output → webacl_arn (copy this value) # Production us-west-2 terragrunt apply --terragrunt-working-dir live/production/us-west-2/waf # Output → webacl_arn (copy this value) # Staging (no GitOps ARN needed, but good to have) terra

Author's note: In the spirit of fairly critiquing AI and practicing a suggestion I end the article with, this article and the accompanying illustration were created entirely without AI assistance. Agentic coding AI is here, and it’s transforming the software industry. But with agentic coding out now for over a year, has it felt like the software industry has really transformed? From my from vantage point, although there are some really cool projects that have been built only because of new agentic coding tools, it generally feels like we’re awash in a sea of software slop. Tim Kadlec wrote a great article, “Losing Focus” , that really resonated with me, especially this quote: “I don’t think the quality of software has increased all that much in in the past 12 months. I think maybe the amount of software has, but it’s very, very hard to find software that’s reliable.” - Max Scoening, Head of Product at Notion I’ve been hearing loads of stories and murmurs about AI from the people I know in tech, and I think there’s a lot being lost in the binary divide that a lot of people seem to fall into - either AI is bad and can do nothing right, or AI is the new future of engineering, and every company should have all their code written by AI today . I want to posit that right now we’re in the messy middle. An era of hype and grifters that want to sell you an AI fantasy that hasn’t been reached, which obscures the real present - powerful AI tools that can speed up professional developers, but can lure non-developers into shipping products that aren’t nearly ready for prime-time. My Background But first, if you don’t know me, let me explain why you should listen to my perspective. I’ve been working professionally in software (specifically web development, focused on the frontend), for over ten years. In that time I’ve worked at a non-profit, a for-profit, led a small startup, freelanced, and have led a number of open-source volunteer teams at Chi Hack Night , including right now

The same agent, same prompts, did markedly different work on two codebases I work in. One has a test suite that runs in eight seconds. The other takes twelve minutes. The eight-second project gets a careful, iterative collaborator. The twelve-minute project gets a confident guesser. I noticed it first as a vibe. The agent in the slow codebase would write five files at once, then announce the task complete without having run anything end to end. The agent in the fast codebase would write one function, run the tests, react to the failure, fix it, run them again. Same model. Same configuration. The only difference was how expensive it was to learn whether the previous step was right. That is the whole post in one sentence. An agent's effective intelligence is bounded by how fast it can verify its hypotheses. Cut the verification cost and you raise the agent's apparent IQ. Raise it and you lower the agent's apparent IQ. The model in the middle is unchanged. Why this binds harder for agents than for humans A human engineer can hold a hypothesis in their head. "I think this works. I will check it later." The cost of holding the hypothesis is roughly free; the human has institutional memory, intuition, a sense of what the code does that does not require running the code to confirm. They can defer verification without losing fidelity. An agent cannot. It has no intuition about your codebase. The only ground truth it has access to is what the tests say, what the type checker says, what the build says. When those signals are cheap, the agent uses them constantly. When they are expensive, the agent stops using them and starts speculating. Speculation by an agent looks plausible. It produces code that compiles, follows the patterns it has seen in your repository, names things sensibly. The problem is that plausible is not the same as correct. The agent that speculates is shipping a guess; the agent that iterates is shipping a tested answer. From the diff alone, they can be hard

Everyone is adding AI to their product right now. Most of them are doing it wrong. Not because they chose the wrong model. Not because they used the wrong library. But because they treated AI integration like a regular feature and skipped all the engineering discipline that production systems require. I have integrated LLMs into multiple production applications. This is what I wish I had known before I started. The Mental Model Shift You Need First A traditional API call is deterministic. You send a request, you get a predictable response. You can write tests against it. You can cache it. You can reason about it. An LLM call is not deterministic. The same input can produce different outputs on different runs. The model can refuse, hallucinate, or return output in a format you did not expect. Your system needs to be designed around this reality, not in spite of it. This means defensive parsing, fallback logic, output validation, and graceful degradation are not optional extras. They are the core of the feature. Choosing the Right Model for the Right Job The biggest LLMs are not always the right choice. I learned this building EditDeck Pro, an AI creative platform for music. Some tasks needed a large frontier model for nuanced creative output. Others needed a fast, cheap model that could run many times per session without accumulating significant latency or cost. The pattern that works: Use a lighter model for classification, extraction, and short structured outputs. Use a larger model for generation tasks where quality matters more than speed. Route dynamically between them based on the task type. This can reduce your inference costs by 60 to 80 percent on workloads that mix simple and complex tasks. Prompt Engineering Is Software Engineering Prompts are code. They should be versioned, tested, and reviewed like code. I store prompts in a dedicated module with version numbers. When I change a prompt I run it against a fixed evaluation set of inputs and compare the out

For a long time, I thought productivity was about effort. Work harder. Focus more. Stay disciplined. Manage time better. Most productivity advice is built around some version of this idea. Then I noticed something strange. Some days I could spend ten hours at a desk and accomplish almost nothing. Other days I could spend three hours working and make more progress than I had all week. The difference wasn't effort. The difference was context. The Most Expensive Thing Is Not Time Ask people what their most limited resource is and most will answer: Time. But for knowledge workers, engineers, researchers, writers, and designers, I think the scarcer resource is often something else. Mental state. The ability to hold a problem in your head. The ability to remember why a decision was made. The ability to see connections between ideas. The ability to continue a train of thought without interruption. That's the state where meaningful work happens. And it's surprisingly fragile. Every Context Switch Has a Cost Imagine you're debugging a difficult issue. You've already: read the logs inspected the code traced the requests formed a hypothesis You're finally starting to see the shape of the problem. Then: a Slack notification arrives someone schedules a meeting an email requires attention a different task becomes urgent The interruption itself might only take two minutes. The real cost is what disappears. The mental model. The momentum. The partially constructed map inside your head. The next time you return to the task, you don't continue where you left off. You rebuild. Software Often Creates The Problem It Tries To Solve One thing that surprised me after building products for years is how much software exists primarily because other software creates friction. A note-taking application exists because memory is limited. A task manager exists because priorities change. A research assistant exists because information is fragmented. Many tools are not solving fundamental problems.

HEY, so im trying to connect my chatbot (Custom Coded) to instagram API using webhooks but im unable to test it my pm2 logs shows (second image) and in my first image, i feel like the AI is just completly lying because i have been trying this for 2 days and he keeps on adding stuff and stuff now its just saying you cant test in development at ALL my facebook and instagram is connected facebook account is also connected to developers facebook and i believe so everything is enabled from my side My thought process is that im using wrong APP_SECRET and ACCESS_TOKEN combo because there are like 4 places that can be used to generate access token and ID and app secret and its so badly designed that i cant figure out what is what. very frustrated honestly. submitted by /u/Jumpy_Paramedic2552 [link] [留言]

I want to create a website in a couple of days. It's main purpose is to offer a free digital download. I want to capture email in the process, to provide follow-up guidance to using the product. There's no e-commerce involved and few pages (4-5). Analytics and domain registration would be a bonus. I want it to look nice - I'd like to have flexible visual design options or be able to adapt a template. I'm comfortable with the likes of WordPress, Wix, Squarespace, Shopify, Canva but not so much using code. In this situation, what would people recommend? 🙏 submitted by /u/jahwinnie [link] [留言]

I'm not sure if I'm in the right place to ask this, but I need to create a web application, and am looking forwhat stack might be best suited.. So far, SurveyJS seems to tick all the boxes, but I have zero experience with the stack. Another one is Flask/Waitress and JS. Ultimately, this will all have to run off a docker host.. I need it save form data, ideally in something like MariaDB, so the user can pick a form the previously filled out and edit it. Multiple users will be using it, authentication is being handled elsewhere, but everyone should be able to see/edit everyone elses' data.. This is a "nice to have", but is there a functionality to export the form data to XML? The app we're looking at building needs to be able to as a question like "How many cars have you driven", and then from that answer create a section or a sub-form for each car that would ask other questions about the cars. I don't mind throwing a bit of money at this, looking at all-in-one options like FluentForm if that ticks all the boxes Thanks so much! submitted by /u/the_zipadillo_people [link] [留言]

OpenSparrow v2.6 is out. This one's a big step forward — RAG (Retrieval-Augmented Generation) integration, bulk grid operations, and a whole new UX layer. RAG & AI integration You can now upload documents and let users ask questions against them. The system retrieves relevant sections and generates answers using an LLM (supports Ollama locally or any OpenAI-compatible API). What's new: RAG Statistics tab in admin — tracks query tokens, response times, document matches, and recent queries Multilingual auto-response — user questions are answered in their own UI language, no schema changes needed 20-language support — "Ask AI" panel fully translated, plus language dropdown in the test interface Good for things like: knowledge base Q&A, customer support automation, or letting internal teams ask questions about their own data. Grid & bulk operations Mass Edit module — select rows via checkboxes, bulk edit fields, change owners, duplicate, or delete with one click Keyboard shortcuts — arrow keys to navigate, Tab, Ctrl+C to copy, Ctrl+F to search, Ctrl-hold for help modal — works across all 20 languages Quick Data Cleanup toolbar — find & replace with live preview, case sensitivity, accent-ignore. Editor-gated with audit trail. Admin improvements Renamed "RAG Knowledge Base" to "Centrum AI" (heading is translatable) Migration Manager — tracks pending cleanup tasks after version upgrades, with automatic backups and audit trail FK columns render as dropdowns in forms by default Security & Quality All bulk operations (mass edit, cleanup, delete) are editor-role gated CSRF protection on every operation Full audit trail — every change is logged 20 languages fully supported across all new modules Fixed regressions in RAG API and CSV import Following this series? OpenSparrow v2.3 – visual admin panel, zero dependencies, now with ERD and M2M support OpenSparrow – open-source admin panel builder, zero dependencies, v2.1 just dropped Websites opensparrow.org github.com/wrobeltomasz/

Analytics is often treated as a reporting feature: a dashboard added after the product already exists. That is usually too late. For software operators, analytics is closer to infrastructure. It is the layer that makes the state of the product visible. Without it, a team cannot evaluate the situation, understand whether the product creates value, or know whether a workflow is improving. That is the reason WebmasterID is built around privacy-first analytics. The goal is not to collect more data than necessary. The goal is to preserve enough signal to make practical decisions without turning measurement into surveillance. Analytics answers operational questions Good analytics starts with plain questions. What happened? Which workflow changed? Which part of the product is used? Where do people leave? Which system events matter? What evidence supports the conclusion? Those questions sound simple, but they are the foundation of product judgment. If the data model cannot answer them, the team is forced to reason from anecdotes, support messages, and internal opinion. Those inputs still matter, but they are not enough on their own. Analytics gives operators a way to compare the current state with the previous state. It makes change visible. It also makes uncertainty visible when the evidence is incomplete. Product value needs evidence A product can look polished and still fail to create value. It can also look unfinished while solving a real operational problem. The difference is usually visible in behavior. Do users return? Do they complete the workflow? Do they avoid a manual step? Does the product reduce confusion? Does it make a business process easier to operate? Privacy-first analytics should help answer those questions without building a profile of every person. In many cases, first-party events, coarse context, workflow state, and careful retention rules are enough. The system does not need to know everything about a user to show whether a product path is working.

In 1994, Peter Deutsch published the Fallacies of Distributed Computing — eight assumptions that every developer building distributed systems makes, discovers are wrong, and pays for in production. The network is reliable. Latency is zero. Bandwidth is infinite. Each assumption sounds true. Each leads to system failures that could have been avoided. Thirty years later, we're making the same category of mistakes with generative AI. The trough of disillusionment for AI-assisted development has begun. Byron Cook, VP and Distinguished Scientist at Amazon, founder of AWS's Automated Reasoning Group (300+ scientists, 15+ teams), says it plainly: "Generative AI is sliding into the trough of disillusionment." The headlines are shifting. The "summer of vibe coding" is over. The disillusionment isn't caused by AI being useless. AI-assisted coding delivers real productivity gains. The disillusionment is caused by false assumptions about WHERE the gains come from and WHAT changes when generation gets fast. Teams expected 10x engineering. They got 10x code generation and 1x everything else. The gap between expectation and reality is the trough. This series names the eight assumptions, explains why each one fails, and presents the resolution — not from theory, but from domains that hit the same wall and climbed out. The Eight Fallacies 1. Faster code generation means faster engineering. You made one sub-system 10x faster. Seven others didn't change. The system doesn't get faster — it breaks at the interfaces. The CPU-memory wall tells you exactly what happens and what fixes it. 2. If the output looks correct, it is correct. AI-generated code is optimized for plausibility, not correctness. It compiles, passes tests, and reads well — while violating properties nobody tested. Plausible is not correct. The gap is where production failures live. 3. You can verify AI output with another AI. Guardrails, LLM-as-judge, AI code review — the verifier has the same failure modes as the thing

I use "what is my IP" sites maybe once a month. Every time I end up on something covered in ads, calling three different tracking APIs, and showing me results I don't fully understand. So I spent a weekend building whatsmy.fyi. The thing I didn't expect: you don't need an IP geolocation API at all if you're on Cloudflare Workers. Every request comes with a cf object that already has your city, country, ISP, TLS version, HTTP protocol, and RTT. Free. Zero latency. The part I enjoyed most was the WebRTC leak test. It checks whether your browser is exposing your real IP through RTCPeerConnection even when you're on a VPN. I ran it on my own setup. It was leaking. Zero logs. Zero storage. Just your data, shown to you. https://whatsmy.fyi

So im working on a saas and am wondering how most of you all handle ToS, liability, and where you get them from? Ill be storing customer data like addresses, emails, phone numbers in a db. Stripe for payment processing. I want to make sure i have a solid tos. To cover refunds, chargebacks, data stored in a db, etc… Should i just find a lawyer or are there resources online i can use? submitted by /u/spacedublin [link] [留言]

Last Friday at 4:30 PM, my product manager walked over: "Hey, can you grab the titles from the Hacker News homepage and send me an Excel file?" I thought: That's it? Five minutes tops. Two hours later, I was still debugging CSS selectors. How Things Spiraled Out of Control Step 1: Initialize the Project mkdir hacker-news-scraper && cd hacker-news-scraper npm init -y npm install puppeteer Hit enter, waited three minutes. Puppeteer needs to download a full Chromium browser — over 200 MB. I stared at the progress bar and started questioning my life choices. Step 2: Write the Code "It's just a document.querySelectorAll , right?" That's what I thought. Then I opened my editor: const puppeteer = require ( ' puppeteer ' ); ( async () => { const browser = await puppeteer . launch ({ headless : true , args : [ ' --no-sandbox ' , ' --disable-setuid-sandbox ' ] }); const page = await browser . newPage (); try { await page . goto ( ' https://news.ycombinator.com ' , { waitUntil : ' networkidle2 ' , timeout : 30000 }); await page . waitForSelector ( ' .titleline > a ' , { timeout : 10000 }); const titles = await page . evaluate (() => { const items = document . querySelectorAll ( ' .titleline > a ' ); return Array . from ( items ). map ( el => ({ title : el . textContent , url : el . href })); }); console . log ( JSON . stringify ( titles , null , 2 )); } catch ( err ) { console . error ( ' Scraping failed: ' , err . message ); } finally { await browser . close (); } })(); I counted: 27 lines. And this is the minimal version — no User-Agent spoofing, no retry logic, no proxy support, no concurrency control. Add all of that and you're well past 50 lines. Step 3: Run It node index.js Error: Navigation timeout of 30000 ms exceeded . Switched to domcontentloaded , got past that. But then waitForSelector timed out — because .titleline was a relatively new class name. Hacker News had silently changed it from .storylink at some point, and nobody sent me the memo. Step 4: Debug Set head

When Mozilla shut down Pocket in July 2025, I lost my favorite tool. Worse, none of the English alternatives (Instapaper, Readwise, Matter, Raindrop) had Japanese UI, and their article extraction was mediocre on Japanese pages. So I built one. It's called Readbox — Japanese-first, English-too, read-later as a PWA. Here's what I learned shipping it. The stack Next.js 15 App Router + TypeScript strict (no any ) Supabase (Postgres + Auth + RLS) Stripe (JPY + USD prices, locale-routed) Tailwind CSS Service Worker for PWA install + offline read Three things that bit me 1. Article extraction on Vercel serverless First attempt: Mozilla Readability + jsdom. Doesn't bundle on Vercel because of ESM compatibility issues and the 50MB serverless function size limit. I tried 6 approaches — Webpack externals, dynamic imports, edge runtime — none worked cleanly. Ended up using Jina Reader , which returns clean Markdown/HTML from any URL. Trade-off: third-party dependency, rate limits at scale. But it works today, and it's free. 2. Storing article body on-device I didn't want to host millions of articles' worth of HTML on Supabase (cost + privacy). Solution: extracted HTML lives in the browser's IndexedDB only (via Dexie); only metadata (URL, title, tags, read status) syncs to the server. Trade-off: cross-device sync of body content doesn't work seamlessly. Acceptable for a "read it later" workflow where you usually read on the device you saved on. 3. i18n routing — the silent sitemap killer For Japanese + English from one codebase: app/[locale]/ segment with /en prefix for English (default Japanese has no prefix, to preserve old URLs). Middleware detects cookie / Accept-Language and redirects accordingly. The gotcha (cost me a launch-day hour): middleware matcher excludes _next , api , image extensions — but if you forget .xml/.txt/.webmanifest , sitemap.xml and robots.txt get rewritten to /ja/sitemap.xml (which doesn't exist as a route → 404). Fix: export const config = { matcher

I got tired of explaining to people why their "simple weather widget" needed an API key, a signup form, and a credit card. So I built a weather API that doesn't need any of that. Here's how you can add live weather to your personal website, portfolio, or side project in about 60 seconds. The old way (painful) Most weather APIs make you: Create an account Verify your email Generate an API key Paste that key into your code Worry about rate limits Get an email when your "free tier" expires For a weather widget on a personal site? That's overkill. The Nimbus way (one fetch, done) I made a public API that doesn't need keys. Just call it. fetch ( ' https://nimbus-api-gxuc.onrender.com/api/v1/weather?city=Berlin ' ) . then ( response => response . json ()) . then ( data => { console . log ( data ); }); That's it. No headers. No tokens. No signup. Real example: Put it on your site Here's a working snippet you can drop into any HTML page right now: <div id= "weather-widget" > <p> Loading weather... </p> </div> <script> fetch ( ' https://nimbus-api-gxuc.onrender.com/api/v1/weather?city=Berlin ' ) . then ( res => res . json ()) . then ( data => { const weatherHtml = data . temp_celsius + ' °C • ' + data . description + ' <br>Wind: ' + data . wind_speed_kmh + ' km/h • Humidity: ' + data . humidity_percent + ' % ' ; document . getElementById ( ' weather-widget ' ). innerHTML = ' <strong> ' + data . location + ' </strong><br> ' + weatherHtml ; }) . catch ( function () { document . getElementById ( ' weather-widget ' ). innerHTML = ' <p>Weather not available right now</p> ' ; }); </script> Change Berlin to any city. It works. Why did I build this? Because I got tired of closed source APIs that change their pricing every 6 months. Nimbus is open source. The code is on GitHub. You can read it, fork it, or run your own version if you don't trust me. The API is free because hosting a weather endpoint costs me almost nothing, and I'd rather lose money than put up a paywall. Try it righ

I recently started using NewsAPI for scraping news articles online but this only works in your localhost, can anyone recommend any free APIs that work in production too (especially when deploying with Vercel)🙏 submitted by /u/Expensive_Bank9080 [link] [留言]

Hi, I was working on extension that has an end-to-end encrypted sync, and when user first time install the extension on a browser where it needs to download all the data (can be a few hundreds or thousands), then it was taking a huge amount of time in the first place then I spend some time researching and found that using workers with a worker pool is the best thing I can do to improve the performance, now it's significantly faster as compared to previous encryption/decryption approach where everything was inside the main thread and being done one by one. but, it's still not like the protonmail inbox where I never see any decryption progress when I login and open the inbox, so, how does that work and how can I make my tool work like that? and as I can't explicitly set that how many workers will actually work in parallel during runtime, as it's up-to the browser based on the available resource, so, is there any other way to get the most out of the workers to make the encryption decryption even faster? btw, I'm currently using the same salt per batch of 100 items, salt, iv, derived keys are generated once and passed to those workers for batches, so, workers are not doing same thing again for common tasks, decreased iteration from 600K to 400K for faster performance. so, if anyone can help me understanding how these works, and how can I make it even better, I'll really appreciate that :) submitted by /u/nhrtrix [link] [留言]

This is only for freelancers who build websites in the EU/UK. What headless cms do you use, as some don’t allow you to choose server location? How do you store your clients websites? Do you self host using gitea? submitted by /u/Fine-Market9841 [link] [留言]

I'm working on a few client sites where translation costs are getting ridiculous. I started looking into whether we can do more on the client side and came across someone or a company? experimenting with Chromium's built-in translation neural net instead of calling external APIs. Has anyone here tried building around window.translation yet? How flaky is the model loading? What kind of fallback are you using when the browser hasn't downloaded the language pack? Mostly curious about the architecture, especially around handling the initial load and performance on lower end devices. (I apologize if links are not allowed, not use to posting much) submitted by /u/Old_Acanthisitta1396 [link] [留言]