标签：#programming

Yesterday, I published a post titled "My Book 'AI, Ego & Regret' Paperback Is Live. Kindle Is...

Intro There's a pitch behind every AI coding assistant: it makes you faster. Fewer keystrokes, less boilerplate, more shipped features per sprint. The pitch is half true. What it leaves out is the gap between a tutorial demo and a real codebase under real pressure. In a demo, every suggestion is correct because the demo was built to make the suggestion look correct. In production, the assistant doesn't know your architecture, your team's conventions, or the ticket you're actually trying to close. It just knows what tends to come next in code that looks like yours. That gap is where the noise lives. The instant-accept trap Say a developer is mid-flow, wiring up a new endpoint. The assistant suggests a validation helper that looks reasonable, so they hit tab. It compiles, tests pass, they move on. Three weeks later a teammate finds two nearly identical validation helpers in the codebase: one written by a human eight months ago, one autocompleted last sprint. Nobody meant to duplicate logic. The suggestion was locally correct and globally redundant, and nothing about "correct code that compiles" caught that. (This is an illustrative scenario, not a specific incident, but most teams running Copilot or similar tools for more than a few months will recognize the shape of it.) Architecture creep, one suggestion at a time No single autocompleted line breaks your architecture. That's exactly the problem. An assistant trained on generic patterns will happily suggest a new abstraction, a new dependency, a new way of doing something you already do three other ways elsewhere in the codebase, because it has no visibility into "elsewhere." Accept enough of these one at a time and the codebase drifts into a dozen small dialects of the same idea, none of them wrong in isolation. The review tax The real cost isn't the code that's obviously bad, that gets caught. It's the code that's plausible enough to pass a quick glance and wrong enough to need real review time later. If you accept

Hey everyone! I bring you my development journey on what I have discovered, accomplishments for this...

I recently built and open-sourced Flaky HTTP , a small Java 11 library for deliberately making HTTP calls less reliable. That may sound like an unusual goal. Most of the time, we work hard to make HTTP calls reliable. We add retries, timeouts, circuit breakers, fallbacks, caches, and monitoring. But eventually we need to answer a more difficult question: How do we know any of that behavior actually works? The original idea was simple: wrap Java's standard HttpClient , add controlled latency or synthetic HTTP errors to selected requests, and leave the rest of the application unchanged. That simple idea led to a few interesting decisions around API design, asynchronous cancellation, response body handling, deterministic testing, and the boundary between application-level failure injection and real network chaos. This article goes beyond a launch announcement. I want to explain why I built the library, how it works internally, where it is useful, and where it is deliberately limited. TL;DR Flaky HTTP is a lightweight wrapper around Java 11's java.net.http.HttpClient . It can: add fixed or random latency; return synthetic HTTP errors with a configurable probability; target requests using a full-URI regular expression; handle synchronous and asynchronous calls; propagate cancellation for delayed asynchronous work; and run without runtime dependencies beyond Java 11. The Maven coordinate is com.tapadyuti:flaky-http:1.0.0 . The shortest useful test setup is a deterministic failure: FlakyConfig config = FlakyConfig . builder () . failureRate ( 1.0 ) . errorStatus ( 503 ) . build (); Every targeted call now returns an empty synthetic 503 response without reaching the network. Replace 1.0 with 0.0 and add LatencyStrategy.fixed(500) when the test should exercise slowness without an HTTP error. It is intended for integration tests, resilience tests, local development, and controlled demonstrations. It is not a replacement for a network proxy or a full chaos-engineering platform

Designing Systems That Contain Failure — CS Week Perú 2026 On August 13, 2026, I had the opportunity to speak at CS Week Perú 2026 , an event organized by IEEE Computer Society student chapters across Peru. My session was: “Isolation and Trust Boundaries in Production: Designing Systems That Contain Failure” The talk explored how production systems can be designed to limit the impact of failures through explicit trust boundaries, architectural invariants, and evidence-based validation. The central idea was simple: The goal isn't to prevent every failure. The goal is to control its blast radius. Production systems fail. Requests overlap, processes crash, memory is exhausted, credentials can be compromised, and dependencies can become unavailable. Reliable engineering is not about assuming that none of these things will happen. It is about deciding what can be affected when they do . From Unit Tests to System Properties A green unit-test suite demonstrates that the tested units behave correctly under the conditions we defined. But it does not necessarily demonstrate that the system as a whole preserves its architectural properties under concurrency, multiple tenants, resource exhaustion, or real deployment conditions. A function can be correct in isolation while the system still violates an important invariant. That led to one of the central questions of the talk: What properties must never be violated? Trust Boundaries I used the concept of a Trust Boundary to make architectural assumptions explicit. For each boundary, we can ask three questions: What are we protecting? What is allowed to cross the boundary? What happens if the condition is violated? From there, we can define invariants : properties that the system must preserve under the conditions established by its design. In the architecture discussed during the session, three dimensions were particularly important: Context → Logical isolation Identity → Cryptographic isolation Execution → Physical/process isolat

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

Background The site edit modal kept accumulating fields — site name, category, SSH connection details, WordPress install location — until editing anything meant scrolling up and down a single long form to find the right field. To clean this up, we split it into three tabs: "Registration info," "SSH," and "WordPress info." That change broke form submission itself, in a way that was hard to spot at first. What tabbing broke The tab implementation itself is straightforward. Each tab's fields live in a <div class="site-tab-content" data-tab="..."> , and CSS toggles which one is visible. .site-tab-content { display : none ; } .site-tab-content.active { display : block ; } An inactive tab is hidden with display: none . Nothing unusual so far, and visually it worked fine. The problem showed up when a required field sat in a tab that was not currently active, and the user left it empty while saving from a different tab. Clicking the save button did nothing . No error message appeared. The form just looked stuck. Root cause: a browser cannot report an error on a field it cannot show HTML5 form validation works by having the browser automatically block the submit event whenever a constrained field (like required ) fails, then focusing that field and showing its standard validation bubble (equivalent to calling reportValidity() ). Note: reportValidity() is a method from the HTML5 Constraint Validation API. It checks whether a form element's value satisfies its constraints (required, pattern, etc.) and, if not, displays the browser's standard error bubble. But when the failing field sits inside a tab hidden with display: none , the browser has nowhere to anchor that error bubble. It still faithfully blocks the submit — but it cannot visualize the error, so it simply stops without any visible feedback. From the user's side, this looks exactly like a button that does not respond. Before tabbing, every field lived on the same screen, so this never surfaced. Introducing tabs — a UI

Last post, I said "the book is under review." Now the paperback is live. The Kindle edition is...

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

Last week, it came to light Cursor had mostly finished migrating from SolidJS to React . This migration happened about seven months ago. But it became a central focus of discussion following the Solid 2.0 RC release . Then yesterday, a week later, it came to my attention that the Anthropic docs example command for their large-scale migration feature is: I admit that my gut reaction was not great. Out of all the examples they could have chosen... Years of my work became a canonical example of the thing you migrate away from — in the same week we shipped the biggest release in the project's history — stung in a way I won't pretend it didn't. My second reaction was to assume that, like the other trickle-down posts I'd seen this week, this rode the same week-old news cycle. Then I checked the Internet Archive and realized this has been there since at least April 2026 . Four months before the Cursor story broke. At this point, the whole public footprint was a mention of an experiment sandwiched between bigger updates in a Cursor blog post posted in January. The kind of thing that no one outside the industry would even really pick up on. No reasoning, no benchmarks, no argument. Stop to think about what that means. I should be careful here because I can't prove anyone at Anthropic ever read that Cursor post. Nobody can. Maybe a docs writer saw the experiment. Maybe Claude drafted its own example. But think it through. Either it traveled from a buried line in one company's release notes into another company's official docs, or it needed no origin at all. It was already assumed before any public migration existed. Our industry has quietly started broadcasting conclusions where it used to transmit arguments. We couldn't have picked a worse time, because — as I'll get to — arguments are the only source that still matters. Why This Matters More Than It Used To It would be fair to ask, hasn't it always been like this? Teams cargo cult large players. Netflix or Facebook uses thi

Originally published at parvejshah.com/blog/why-browser-agents-fail-in-production-without-semantic-layers by Parvej Shah . The Fragility of Machine Vision in Modern DOMs Maybe the next evolution of frontend engineering isn't just designing interfaces for humans. It is designing interfaces that machines can reliably understand too. Browser agents don't always fail because the AI model is bad. Often, the web page itself is fundamentally hostile to machine parsers. Modern single-page applications (SPAs) render deeply nested <div> trees with ephemeral, auto-generated class names (such as Tailwind or CSS-in-JS hashes). While this provides fluid visual rendering for human users, it strips away semantic meaning for automated agents. graph TD A[AI Browser Agent] -->|Fragile Visual OCR / Coordinate Guessing| B[Opaque Div Hierarchy] B -->|Frontend Code Deploy / CSS Hash Shift| C[Broken Automation & Flaky Selectors] A -->|Direct Deterministic Query| D[Semantic Schema & data-agent Attributes] D -->|Refactor-Proof Contract| E[Deterministic Task Execution] Moving Beyond Ephemeral Selectors We already treat accessibility (a11y) as a non-negotiable contract between the frontend and assistive technologies through ARIA attributes. Why not extend that exact engineering rigor to AI agents? Imagine components exposing explicit, stable machine intent: // The machine contract: deterministic, testable, refactor-proof < button data - agent = " checkout-submit-button " data - agent - action = " complete-transaction " className = " btn-primary " > Confirm & Pay < /button > With explicit semantic attributes: Zero Layout Guesswork: The agent does not need to guess which button to click based on pixel coordinates or fragile CSS selectors. Deterministic Interaction Paths: Continuous integration (CI) test suites can validate machine contracts alongside accessibility audits. Reduced Latency & Token Costs: Vision-language models (VLMs) introduce non-deterministic latency and high token costs when in

Originally published at parvejshah.com/blog/why-browser-agents-fail-in-production-without-semantic-layers-test by Parvej Shah . The Semantic Contract Modern web applications optimize DOM trees for human eyes with nested divs... graph TD A[Vision Model] -->|Fragile OCR| B[DOM Tree] C[Semantic Layer] -->|Deterministic Contract| B const button = document . querySelector ( " [data-agent=submit] " ); Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com .

I want to become a platform engineer, but I don't have experience on my resume. If you have a medium sized workload you want to deploy on my AWS account, I can do it for free for you because I want to gain some troubleshooting experience that I can mention in interviews. I am RHCSA certified and I am going to get my CKA certification in September. I am very interested and well versed in Kubernetes and Linux internals. Please contact me if you are interested. I'm also available for DevOps roles. submitted by /u/acompleteunknownnn [link] [留言]

I like Jekyll a lot. Hope you find it useful. If you notice any errors or have thoughts to share, don't hold back in the comments or DMs. All feedback is genuinely welcome 🙂. submitted by /u/sarans22 [link] [留言]

When designing AI-powered financial or analytics pipelines, developers frequently run into two major failure modes: Tight Coupling: LLM orchestration logic is directly bound to external market APIs. Any breaking change from a data vendor breaks the entire agent pipeline. Fragile Outputs: Relying on raw text generation for deterministic indicators creates hallucinated figures and pipeline crashes downstream. To solve this in Trading-research-assistant , the system applies Hexagonal Architecture (Ports and Adapters) , strict schema validation with Pydantic, and decoupled inference routing. High-Level Architecture (Ports & Adapters) The core domain layer remains completely isolated from external HTTP clients, third-party market APIs, and specific inference engines. +---------------------------------------------+ | User / CLI / API | +---------------------------------------------+ | v +---------------------------------------------+ | Application Layer | | (ResearchCoordinator, AnalysisOrchestrator) | +---------------------------------------------+ | | v v [ MarketDataPort ] [ LLMInferencePort ] ^ ^ | (implements) | (implements) +------------------------+ +------------------------+ | Adapters: | | Adapters: | | - OandaAdapter | | - OllamaAdapter | | - TwelveDataAdapter | | - OpenRouterAdapter | | - MockDataAdapter | | - ClaudeAdapter | +------------------------+ +------------------------+ Key Architectural Benefits Zero-Cost Unit Testing: Fast mock adapters allow full integration tests without consuming rate limits or paid API credits. Resilient Failovers: If a primary provider hits rate limits (HTTP 429) or service outages, the orchestrator switches to a fallback adapter implementing the identical port contract. Strict Interface Contracts Data boundaries between adapters and application services are enforced using typing.Protocol and immutable Pydantic schemas. from datetime import datetime from typing import Protocol , Sequence from pydantic import BaseModel , Field cl

What Clip Architect Actually Changes About Local AI Video Generation Here's what people get wrong about a tool like this. The hard part was never really the AI writing the script. It's the plumbing around it, the part nobody photographs for the landing page. Clip Architect is a Windows desktop application that wraps the open-source MoneyPrinterTurbo pipeline (the one that turns a topic into a scripted, narrated, subtitled short video) inside a Tauri 2 shell, with a React 19 interface and a Python backend running underneath as a private local service. You give it a topic, you get an MP4 sized for TikTok, Reels or Shorts, and nothing in between gets uploaded anywhere except to whichever provider you configured, with the key you supplied yourself. No account, no subscription, no cloud render queue. Once you get that one distinction, wrapper versus engine, the rest of this holds together on its own. Why the Terminal Step Was the Real Barrier Let's look at where the friction actually sat. Upstream MoneyPrinterTurbo is a Python web app built on FastAPI with a Streamlit interface: you start it from a terminal and use it in a browser . Fine for a developer. It stops being fine the moment the person who wants the video has never opened a terminal in their life, and most people who want a video have never opened a terminal in their life. Closing that gap is the whole reason Clip Architect exists: a Tauri shell owns the window and the process lifecycle, a React frontend replaces Streamlit, and the Python backend starts and stops with the app itself, quietly, in the background. You install it, you open it, and a command line never comes up. The chain underneath doesn't change. Give it a subject, an LLM writes the script and the search keywords, stock footage or your own files supply the picture, a text-to-speech engine speaks the narration, and FFmpeg cuts the clips to the voice track, burns in subtitles, mixes background music and writes the final MP4. Every one of those stage

In the porting guide I wrote that the exam is built to be stolen — follow five steps and it moves to any job. So I tried being the other person. Following only what the guide says, start to finish. Where to steal it to — my own tool, of all places For the second job I picked YouTube comment classification : scraping 20,000 comments and sorting each one into "a need," "chatter," or "a signal someone would pay." Every number in the 20,000-comments post came out of this classifier. Which makes this a double-edged experiment. It tests whether the exam ports — and at the same time it tests whether the tool that produced my own published numbers can pass an exam. The twist comes first — the tool wasn't an AI Before writing a single question, I opened the classifier's code to understand what I was about to test. The thing that sorted 20,000 comments was not an AI. It was a regex — word matching: "if the comment contains this keyword, it's this category." The second line of the actual data file was already an accident. My grad-school senior bet that nobody would bother replacing humanities majors because they don't pay. He was right. Social commentary. Not a need, and certainly not about errors. The classifier had filed it as a need in the "errors & debugging" category — because the Korean phrase for "doesn't pay" contains the same two characters as the error keyword "doesn't work." With 10,000 likes, it sat near the top of the ranking. The accident showed up before the exam even existed. Then I followed the five steps exactly Step 1 — write down the worst. These classifications feed decisions about what to build and what to sell. So the worst accident is "promoting chatter into a need and manufacturing fake demand." A product decision built on fake demand burns weeks. Step 2 — the grade table. Four grades: fatal, risky, missed, harmless. In the guide I had written "only the first line, FATAL, is redefined per project; the other three read the same everywhere." Porting it,

This talk is not about C++. It is about the Seed7 programming language. The cpp usergroup vienna allowed a talk about Seed7. Properties of Seed7 are: Seed7 is an open-source general purpose programming language that can be interpreted and compiled. Seed7 is about portability , maintainability , performance and memory safety . There is an automatic memory management without a garbage collection process (which might stop the world). The templates / generics don't need syntax with angle brackets. Seed7 is an extensible programming language. The syntax and semantics of the language is not hard-coded in the compiler but defined in libraries. Seed7 checks for integer overflow . You either get the correct result or an OVERFLOW_ERROR is raised. Unlike Java Seed7 compiles to machine code ahead of time (GRAAL works ahead of time but it struggles with reflection). Unlike Java Seed7 operators can be overloaded . Unlike C, C++, Go, Zig, Odin, Nim and C3 Seed7 is a memory safe language. The standard libraries cover many application areas. Example programs are: make7 , bas7 , pv7 , tar7 , ftp7 , comanche and many more. Seed7 is based on my PHD thesis and is the result of life-long work. The project consists of more than 500k lines of manually written code, several hundred pages of documentation, a test suite to check the functionality of interpreter and compiler and much more. I give it away for free with GPL/LGPL licensing. From time to time I do talks about my project. This is my latest talk. Please let me know what you think, and consider starring the project on GitHub , thanks! submitted by /u/ThomasMertes [link] [留言]

السلام عليكم جميعاً،حابب أشارك معاكم تطبيقي الجديد Pythonize: Python Quiz الموجه خصيصاً للمبتدئين في عالم البرمجة ولغة بايثون. عن التطبيق:هو أداة تفاعلية وسهلة تساعدك على اختبار وتقييم مستواك البرمجي عبر مجموعة متنوعة من الأسئلة والاختبارات التي تغطي أساسيات اللغة، مع تقديم مراجعة فورية للإجابات لمساعدتك على التعلم وتطوير تفكيرك المنطقي. رابط التحميل من متجر جوجل بلاي: https://play.google.com/store/apps/details?id=com.elshatory.programming.pythonize يسعدني جداً تجربتكم للتطبيق ومشاركتي آرائكم وملاحظاتكم لتطويره في التحديثات القادمة! submitted by /u/PerformerOld1687 [link] [留言]

Published: 27/08/2026 The Setup I'm 16 years old and starting my coding journey in 2026. After using Twitter, GitHub, and setting up my domain ms.blurbisht.fun, I decided to commit to #100DaysOfCode. The Project: Pong Game CLI A terminal-based two-player Pong game built with Python's curses library. Demonstrates: Object-oriented programming Game loops and input handling ASCII graphics animation Score tracking # Key code snippet if key == ord ( ' w ' ): left_paddle . move_up () Why I Built It: To move beyond theory to actual shipping. My goals: learn Python → build AI agents → create multi-agent systems. What's Next: Day 2: Not Planned!! Connect: Twitter: @blurbisht GitHub: github.com/BlurBisht Portfolio: ms.blurbisht.fun