标签：#dev

Every inventory tool says real-time. Every single one. Open the settings. Find the sync frequency configuration. It says 15 minutes. Or 10. Or 30 on the cheaper plan. That's not real-time. That's a cron job. There's a meaningful architectural difference and the industry has collectively decided to pretend there isn't. I want to make the technical case for why this matters — and ask why so few tools have actually fixed it. What "real-time" actually means technically Real-time in distributed systems has a specific meaning. It means the system responds to events within a bounded, predictable latency — not on a schedule. javascript// This is NOT real-time — this is scheduled // Latency: up to 15 minutes (the full interval) setInterval(async () => { const stock = await getSourceOfTruth(); await syncToAllChannels(stock); }, 15 * 60 * 1000); // This IS real-time — event-driven // Latency: network round-trip (~milliseconds) orderEventBus.on('order.confirmed', async (event) => { const updated = await decrementStock(event.sku, event.qty); await propagateToAllChannels(updated); }); The first example responds to state changes on a schedule. The second responds to events as they happen. These are fundamentally different architectures with fundamentally different latency guarantees. Calling the first one "real-time" is technically incorrect. It's scheduled sync. The schedule is just short enough that most users don't notice — until they do. When users notice The failure mode is predictable and well documented: javascript// Flash sale scenario — 10x normal velocity const normalOrdersPerWindow = 500 / ((24 * 60) / 15); // ~5.2 const flashSaleOrdersPerWindow = normalOrdersPerWindow * 10; // ~52 // 52 orders processed against potentially stale stock // per 15-minute window // across multiple channels simultaneously // none of which know what the others have sold 52 orders per window. At 2% oversell rate — just over 1 oversell per window. Across 96 windows per day — nearly 100 oversel

OpenTelemetry has introduced a new "Blueprints" initiative aimed at reducing the growing complexity of deploying and operating observability systems at scale. By Craig Risi

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

Introduction Managed Kubernetes platforms such as Amazon EKS, Google Kubernetes Engine (GKE), and Azure Kubernetes Service (AKS) abstract away much of the operational complexity involved in running Kubernetes clusters. While this significantly improves developer productivity, it also hides many of the internal systems responsible for cluster orchestration, networking, node registration, and workload scheduling. As a result, many engineers interact with Kubernetes daily without fully understanding the components that keep a cluster operational behind the scenes. To better understand Kubernetes from an operational perspective, I set out to build and operate a self-managed Kubernetes platform on AWS using kubeadm. Unlike lightweight local environments such as Minikube or kind, kubeadm bootstraps Kubernetes in a way that closely resembles how real-world self-managed clusters are provisioned and operated. The objective of this project was not simply to install Kubernetes, but to explore: How the control plane components interact. How worker nodes register with the cluster. How Kubernetes networking behaves. How cloud integrations work. How traffic reaches workloads running inside the cluster. How operational failures surface during deployment and runtime. How production-style systems behave beneath managed abstractions. This article documents the architecture, implementation process, engineering decisions, operational lessons, and troubleshooting insights encountered during the effort to bring the platform to a healthy operational state. Project Objectives The primary objectives of this project were to: Provision infrastructure on AWS using Terraform. Bootstrap a self-managed Kubernetes cluster using kubeadm. Configure Kubernetes networking using Calico. Integrate Gateway API with AWS Load Balancer Controller. Expose workloads externally using AWS Application Load Balancers. Validate cluster functionality through application deployment. Understand the operational mechani

This is a submission for the GitHub Finish-Up-A-Thon Challenge The Project That Got Away Three months ago, I started building something I was genuinely excited about: devto-mcp — a Model Context Protocol (MCP) server that would let AI agents interact with Dev.to's API natively. No more cobbling together curl commands. No more writing custom wrapper scripts for every AI tool. Just a clean, standards-compliant MCP server that any AI agent could plug into. I had a vision: an AI agent that could autonomously research trending topics, draft articles, publish them, track engagement, and iterate — all through a single protocol. The kind of thing that sounds simple until you actually sit down to build it. I got about 40% of the way through. Then life happened. A client project deadline. A cross-country move. A laptop that decided to corrupt its SSD at the worst possible time. The repo sat there on GitHub, collecting digital dust, with half-implemented tool functions and a README that promised way more than the code delivered. Sound familiar? If you've been a developer for more than a year, you have at least one of these ghost repos. That ambitious side project you were so sure you'd finish "next weekend." The one with the clever name and the detailed architecture doc but barely functional code. Two weeks ago, I saw the GitHub Finish-Up-A-Thon announcement. I looked at my list of abandoned repos. And I thought: it's time. What I Built: devto-mcp devto-mcp is a Model Context Protocol server that exposes Dev.to's entire API as MCP-compatible tools. If you're not familiar with MCP, it's the protocol that lets AI assistants like Claude, Cursor, and other coding agents interact with external tools in a standardized way. Think of it as a universal adapter between AI models and the services developers actually use. Here's the problem it solves: Every time you want an AI agent to interact with Dev.to — whether it's searching for articles, publishing a post, checking analytics, or ma

Server-side tracking on Shopify Plus is no longer optional in 2026. Browser-side analytics tags now miss around 30-40% of conversion events on Safari, Firefox, and ad-blocked sessions when ITP, consent rejection, and ad-blockers combine, and the server-side fix — a GTM server container or an equivalent gateway — is the difference between a usable Meta CAPI feed and a reporting hole that quietly tanks your paid-media ROAS. Why browser-side pixels broke first The structural decay started years ago and accelerated through 2025. Safari's Intelligent Tracking Prevention caps JavaScript-set first-party cookies (anything set via document.cookie ) at 7 days, and 24 hours when the URL carries a tracking parameter like fbclid or gclid . Server-set first-party cookies sent via the HTTPS Set-Cookie header can still persist up to 400 days, unless the cookie's host resolves through a CNAME to a third-party — then ITP collapses that lifetime back to 7 days. Combine that with Firefox Enhanced Tracking Protection (around 5-8% of UK desktop traffic), ad-blockers (around 30-35% adoption on desktop), and consent-management platform rejection (typically 20-40% of EU sessions), and a typical Shopify Plus storefront ships measurable signal for only 60-70% of real purchase events. We have audited stores where a server-side migration recovered around 28% of attributed purchases inside the first 7 days of switchover — not because the conversions stopped happening, but because the browser layer stopped reliably reporting them. What a server-side gateway actually does A server-side tracking gateway intercepts the event between the storefront and the destination platform (Meta, Google Ads, TikTok, etc.) and re-emits it from your domain. The browser still fires a lightweight web-side ping, but the heavy payload — order ID, customer hash, line items, value — travels server-to-server. Cookies stay first-party because the request originates from your own subdomain. The destination platform sees a c

The problem Every time I started a session with Claude Code I had to re-explain my entire project. What framework I use. How my folders are structured. What naming conventions I follow. What decisions I have already made. Every. Single. Session. It was slowing me down and I knew there had to be a better way. What I built I built stackbrief. One command scans your repo and opens a local visual dashboard showing your full codebase intelligence. npx stackbrief scan It opens a dashboard at localhost:3000 showing: Interactive code map of your architecture Dependency version comparison against npm Convention detection (naming, async patterns, error handling) Context health score MCP server so Claude Code pulls context automatically How it works stackbrief reads every file in your project and builds a structured understanding of it. It detects your framework, architecture pattern, modules, dependencies, and coding conventions. It then writes a CLAUDE.md file to your project and starts an MCP server on port 3001. Claude Code picks this up automatically before every session. No more explaining your project from scratch. AI chat that actually knows your code The dashboard has an Ask your codebase section. Unlike generic AI chat, this assistant has read every file in your project. Ask it about your own architecture and get answers specific to your code. Works with Ollama (free, fully local), Claude, OpenAI, or any OpenAI-compatible provider including Groq, Mistral, and local runners like LM Studio and AnythingLLM. Zero config, fully local No cloud. No telemetry. No account required. Everything runs on your machine. npx stackbrief scan That is it. The dashboard opens automatically. Try it GitHub: https://github.com/ragavtech/stackbrief Built with Node.js and TypeScript. Open source, MIT license. Would love to hear what you think.

Stanford Just Published Rules for AI Coding Agents — What Devs Should Know Stanford dropped a document last week that every developer using AI coding tools should read. It's called CLAUDE.md , it's part of CS336 (Language Modeling from Scratch), and it's a brutally honest set of rules for how AI agents should — and shouldn't — help students write code. The document hit #1 on Hacker News for good reason. It doesn't just apply to students. If you use Claude Code, Cursor, Copilot, or any AI coding assistant, these rules expose the uncomfortable gap between what these tools can do and what they should do. GitHub just rolled out token-based billing for Copilot, and developers are furious. The tension is the same: when does AI assistance stop helping and start hurting? The Core Principle: Teaching Assistant, Not Solution Generator Stanford's position is unambiguous: "AI agents should function as teaching aids that help students learn through explanation, guidance, and feedback — not by completing assignments for them." This isn't academic hand-wringing. It's a design constraint that maps directly to professional development. The same agent that writes your PR in 30 seconds is also the one that leaves you unable to debug it when it breaks at 2 AM. The AI agent role framework from Stanford's CS336 guidelines: teaching assistant vs solution generator The document draws a hard line: What agents SHOULD do: Explain concepts by guiding toward understanding Review your code and point out areas for improvement Ask guiding questions instead of giving fixes Reference documentation, lectures, and debugging tools Suggest sanity checks, assertions, and profiler investigations What agents SHOULD NOT do: Write any Python or pseudocode Complete TODO sections in assignments Give solutions to problems Edit code in the student repo Convert requirements directly into working code Point to third-party implementations If you're a professional developer, the "SHOULD NOT" list probably looks extr

Keeping up with trending technical topics and new tools on developer forums can be time-consuming. To save time, I wanted to automate the process of finding popular articles, reading the comments to understand community sentiment, and drafting a summary. While I could write a standard Python script to scrape the dev.to API, simple scripts tend to be brittle. If an article doesn't have comments yet, a basic script will likely crash unless you write extensive error-handling logic. Instead of a rigid script, I built an Agent —a program that can dynamically reason about errors and adjust its approach. If one task fails, it can figure out the next best step. In this tutorial, I'll show you how to build a Trend-Spotting Agent using Python, the Google Agent Development Kit (ADK) , and Gemini 2.5 Flash. What We're Building We are going to write a Python application that acts as an autonomous agent. We'll give it three abilities: Search the dev.to API for rising technical articles based on specific tags. Dynamically fetch the top comments of those articles to read real community sentiment. Automatically draft a newsletter-style article on your DEV.to account summarizing its findings. Prerequisites Python 3.9+ installed on your machine. Google ADK . (Check out the Google ADK Docs if you need help installing). A DEV API Key . Grab this from your DEV.to account settings under "Extensions" and throw it in a .env file. Step 1: Giving the Agent its "Hands" (API Tools) Large Language Models (LLMs) are incredibly smart, but out of the box, they can't actually do anything on your computer. The coolest part about Google ADK is that we can write standard Python functions, hand them to the LLM as "tools", and let the AI decide how and when to use them. Let's write our API functions. Tool 1: Finding Rising Articles Here is our function to fetch rising articles. Pay close attention to the docstring ( """Fetches the top...""" ). We aren't writing this for other developers; the ADK actually

Stuck on Meta App Review and hoping someone here has cracked it. Setup: Instagram API with Instagram Login (graph.instagram.com, v25.0), Instagram User token (IGAA...), BUSINESS account. Trying to get Advanced Access for instagram_business_manage_comments. The blocker: the "make 1 successful API call" requirement stays at "0 of 1 API call(s)" for days (past Meta's 2-day logging window), so the Request Advanced Access button stays grayed out. What I've confirmed: - The token DOES hold the scope (granted permissions list includes it). - GET /{media-id}/comments?fields=id,username,timestamp returns HTTP 200. - Rate-limit usage increases per call, so the calls are landing. - It's not the endpoint: I also tried creating a comment + replying (POST /{media-id}/comments, POST /{comment-id}/replies) — all 200, none registered. On the SAME token/path, instagram_business_manage_messages registered fine (its requirement is complete) even though ITS call (GET /me/conversations) also returns an empty array (200, "data":[]). So an empty 200 counted for manage_messages but the comments call never counts for manage_comments — looks like a tracking bug specific to the manage_comments counter. Question: has anyone gotten instagram_business_manage_comments to flip 0 -> 1 on the Instagram-Login path? What exact call/step did it, or did Meta credit it via a Platform Bug Report? Anything that worked would save me. submitted by /u/Traditional-Lake3525 [link] [留言]

Frontend automation has been getting pretty wild lately. 🫠 A few months ago, this comparison would...

I've been building out embedded reporting for b2b clients (i use next.js), and as our user base grows, the P95 latency is becoming a nightmare. Every time a user changes a date filter, it triggers a fresh compute spin-up on the warehouse. I’m currently refactoring the stack to put a universal semantic layer (in my case, cube core) between the frontend and the database. and the goal is to move all the logic, like multi-tenant row-level security (RLS) and complex joins, out of the React code itself and into a declarative modeling layer since I started, the biggest win (so far) is using pre-aggregations. now, instead of hitting raw tables, the API hits a warmed caching tier which is in the 'cubestore'. it feels more like querying a structured API than a database for those of you here who do high-concurrency analytics in SaaS, a question! are you just throwing more money at warehouse compute, are you moving toward this kind of decoupled architecture, what other best practices do you have? now trying to figure out if I should stick with this or just move everything to a huge ClickHouse instance and hope for the best submitted by /u/sivyh [link] [留言]

Inspiration Build a simple and modular technical documentation and blog. Build the website without using node/npm or any external frameworks(CSS, JS, icon, font). Only GoHugo normal binary + pageFind binary needed. Features [x] Responsive and adaptive layouts. [x] Support for light and dark modes. [x] Support for multiple documentation sets. [x] Support for a blog. [x] Implement a menu via Hugo configs. [x] Customizable sidebars using Hugo data templates. [x] Plug-and-play/ repeatable home page blocks using separate partials/ css/ data templates. [x] Integrate a search via Pagefind. [x] Inline SVG icons based on Google's Material Symbols GitHub Repo: https://github.com/dumindu/E25DX Example Docs: https://github.com/dumindu/E25DX/tree/gh-pages/example Example Live: https://dumindu.github.io/E25DX/ submitted by /u/dumindunuwan [link] [留言]

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

Google has released a new CLI for Google Workspace, offering a unified interface for various services like Drive, Gmail, and Calendar. Built in Rust, the tool dynamically adjusts to API changes and features over 100 bundled skills. It requires Node.js and a Google Cloud project for setup. Initial community feedback is mixed, highlighting both its dynamic capabilities and setup challenges. By Daniel Curtis

“Did We Already Watch This?” — Building KindaSeen with FastAPI and Next.js A few months ago, my friends and I kept running into the same question whenever we talked about movies, dramas, anime, or variety shows: “Did we already watch this before?” Sometimes we remembered the title but forgot whether we had finished it. Other times, we completely forgot we had already seen it at all. That simple problem inspired me to build KindaSeen, a full-stack personal media repository designed to help users track and organize the media they’ve consumed in one centralized platform. The goal of the project was not only to create a useful application, but also to gain hands-on experience building a real-world full-stack system with modern web technologies. What KindaSeen Currently Supports User authentication with Supabase CRUD operations for personal media records TMDB-powered search functionality Watchlist system Favorites system Persistent PostgreSQL storage Dockerized backend deployment Separate frontend/backend deployment workflow Tech Stack Frontend Next.js React Tailwind CSS Shadcn/ui Vercel deployment Backend FastAPI PostgreSQL Docker Render deployment External Services Supabase Authentication TMDB API integration One of the main goals of this project was to simulate a more realistic production workflow by using a decoupled frontend/backend architecture instead of building everything inside a single monolithic application. In this article, I’ll share: Why I chose this architecture How I integrated TMDB into the application Challenges I faced during deployment What I Learned From Building KindaSeen Why I Chose This Architecture Instead of building a monolith using Next.js API routes, I decided to decouple the application into a Next.js frontend and a FastAPI backend. This decision was driven by three main factors: AI Compatibility & Future Proofing : While researching the job market, I noticed that most companies building AI products heavily rely on Python. By choosing FastA

We talk about pagination as if it's purely a backend concern – the database does the heavy lifting, the API returns pages, and the frontend just renders them. But in 2026, that mental model is outdated. The frontend now owns more of the data-fetching lifecycle than ever: server components prefetch, client caches hydrate, optimistic updates mutate, and streaming responses trickle in chunk by chunk. The choice between cursor pagination and offset pagination has real consequences for how you write your React components, how your cache behaves, how scroll feels on the phone, and what happens when a user navigates back. This post is about those tradeoffs – from the frontend seat. The Landscape Has Changed A few things are different in 2026 that make this conversation more nuanced than it was three or four years ago: React Server Components are mainstream. Data fetching happens on the server in many apps, which shifts where pagination state lives and how navigation works. TanStack Query is the de-facto standard for client-side async state, with first-class infinite query support baked in. The "infinite scroll vs pagination" debate is mostly settled — infinite scroll wins for feeds and content-heavy apps; numbered pages win for dense data tables. Your pagination strategy should serve that decision, not fight it. LLM-powered search and filtering are becoming common, and those use cases have their own quirks around pagination stability. Edge caching and CDN-level pagination mean that certain offset-paginated responses can be cached by URL – a genuine advantage offset still holds. What Frontend Engineers Actually Care About When you strip away the SQL theory, here's what the pagination choice actually affects on the frontend: 1. Cache Key Design With offset pagination, the cache key is simple and predictable: posts?page=3&limit=20 . Every page is independently cacheable by URL — your CDN loves this. TanStack Query, SWR, and Apollo all handle this naturally. // Offset — clean,

The dominant production failure mode for LLM agents in 2026 isn't bad reasoning — it's capacity. Here's what the data shows, why nobody demos it, and the capacity-engineering patterns that actually keep agents alive under load.

You know that, right? The mobile web is completely unusable. Its garbage and it is garbage because you can't say "no" to stupid advertisers and keep putting more and more stupid popovers and sneaky links, and animations, and content obscuring crap, often not bothering to put the close box within the bounds of the screen. If you work on a mobile version of a website - shame on you. It doesn't work. I'm not kidding. I probably visited, and immediately noped out via the back button because it is just more trouble than the crappy click bait title implies it might be worth. RIP mobile web. submitted by /u/Small_Dog_8699 [link] [留言]

Ever received a WebSocket tick stream for US stocks and wondered why your indicators behave oddly outside regular hours? The raw data doesn’t tell you which session a trade belongs to, but identifying the session is crucial for signal quality. Here’s a clean, no-dependency-heavy way to do it in Python. Quick Session Reference Session US Eastern Time Data Characteristics Pre-market 04:00-09:30 Sparse trades, choppy moves Regular hours 09:30-16:00 Dense liquidity, smooth price action After-hours 16:00-20:00 Volatility often triggered by news Method 1: Timestamp Conversion Almost every API sends a UTC timestamp. Convert it to US/Eastern and classify. from datetime import datetime import pytz # US Eastern timezone et = pytz . timezone ( ' US/Eastern ' ) def get_session ( ts ): t = datetime . fromtimestamp ( ts , et ) # Check pre-market window if t . hour < 9 or ( t . hour == 9 and t . minute < 30 ): return " pre " # Regular session if t . hour < 16 : return " regular " # After-hours return " after " Method 2: Use a Session Status Field If your provider sends a field like sessionType , you can skip the timezone math. Just make sure to test edge cases at session boundaries. Live Integration Example Using a WebSocket feed (like AllTick’s market data stream) that includes a timestamp, I label ticks on the fly. import websocket import json from datetime import datetime import pytz # US Eastern timezone et = pytz . timezone ( ' US/Eastern ' ) def session ( ts ): t = datetime . fromtimestamp ( ts , et ) if t . hour < 9 or ( t . hour == 9 and t . minute < 30 ): return " pre " elif t . hour < 16 : return " regular " else : return " after " def on_message ( ws , message ): data = json . loads ( message ) s = session ( data [ " timestamp " ]) print ( f " { data [ ' symbol ' ] } | { s } | { data [ ' price ' ] } | { data [ ' volume ' ] } " ) # Open WebSocket connection ws = websocket . WebSocketApp ( " wss://ws.alltick.co/stock " , on_message = on_message ) ws . run_forever () Effic