标签：#p

The problem In 2026, devs spend 11.4 hours a week reviewing AI-generated code — more time than they spend writing it. We're burning cycles fixing bugs our own AI tools wrote. I started calling this "AI debt": the maintainability tax that piles up when nobody's actually reading the code the assistant just spat out. I wanted a fast, brutal way to see how much debt was hiding in a file before I even opened a PR. What I built Roast My Code — paste a code snippet, get an AI Debt Score (0–100) and get roasted for your sins. 118 regex patterns across 8 languages (JS/TS, Python, Go, Rust, Java, PHP, C++) Scores broken into Readability, Structure, Error Handling, Safety, and Style Code metrics: nesting depth, duplication %, comment ratio, avg line length Three brutal one-liner roasts + concrete fixes for each issue found The twist: zero AI. No API calls, no LLM, no backend. Everything runs client-side with regex pattern matching. Your code never leaves your browser. Why regex, not AI Honestly — irony. A tool built to call out AI slop shouldn't itself be another wrapper around GPT. Regex is also just... faster. No API latency, no cost, no rate limits, no "please wait while I analyze your code" spinner. You paste, you get roasted in under a second. It's not going to catch everything a proper linter or an LLM code reviewer would. That's not the point — it's a gut-check, not a static analysis suite. A taste of the roasts javascript var API_KEY = "sk_live_51H8xJ2kL9mNpQrStUvWxYz..."; if (a == 1) { if (b == 2) { if (c == 3) { x = eval(a + b + c); } } } 🔒 is that a hardcoded credential? in 2026? we need to talk. your teammate rewrote this on a Sunday. FIX: Move it to an environment variable or secret store, then rotate the credential. 🎆 eval(). we don't need to say more. you know what you did. this is the part reviewers skim past. FIX: Replace eval with a lookup table, JSON.parse, or an explicit parser. Try it 🔗 Live app 💻 Source on GitHub — MIT licensed, PRs welcome Paste your wor

When Anthropic introduced the Model Context Protocol on November 25, 2024, it got everyone's eyes on it, including Christy, who was Appwrite's Engineering Lead back then. I had just started my role as an "Engineering Intern" and had no idea what a whole new protocol meant, or why it was such a big deal. Looking at the surface, I wasn't entirely wrong. MCP is JSON-RPC with a schema and a handshake stapled on. What took us sixteen months was everything stapled around it. Streamable HTTP did not exist when MCP launched. It replaced HTTP+SSE in the 2025-03-26 revision. The stdio years Christy had a working stdio server in the repo by February 26, 2025. We already had API keys, so the wiring was simple: claude mcp add appwrite \ --env APPWRITE_PROJECT_ID = <YOUR_PROJECT_ID> \ --env APPWRITE_API_KEY = <YOUR_API_KEY> \ --env APPWRITE_ENDPOINT = https://cloud.appwrite.io/v1 \ -- uvx mcp-server-appwrite An API key is scoped to exactly one project by design, so the ceiling was baked into the credential. Switching projects meant editing your editor config. Creating a project was impossible. So was anything at the organization level. The credential is the whole difference between the two transports, and everything hard about the hosted version follows from swapping it for a token that belongs to the user instead of the project. Authorization ate the schedule By the spec, authorization is genuinely optional: Authorization is OPTIONAL for MCP implementations. [...] Implementations using an HTTP-based transport SHOULD conform to this specification. For a service where one tool call can drop a database, we weren't comfortable treating it as optional. If you use Auth0 or WorkOS, this is a config screen. Appwrite keeps everything in-house, so Matej built the authorization server itself, and I built the resource server plus whatever Cloud was still missing before real clients would work. Steps 2 through 6 are the part that makes "just paste this URL" work. Nothing is pre-provisioned.

Classic Machine Learning Through the Eyes of an SRE — Part 2 The second algorithm I studied broke everything I'd just learned from the first. Logistic regression taught me that training means gradient descent: guess, measure error, adjust the weights, repeat until convergence. So when I opened decision trees, I went looking for the optimizer. There wasn't one. A decision tree isn't optimized the way I expected. It's grown. At each step it finds the locally best split, commits to it, and recursively repeats the process. No backtracking. No second chances. There is optimization happening — each split minimizes impurity — but only locally, one step at a time. Finding the globally optimal tree is NP-hard, so the algorithm doesn't even try. That felt surprisingly familiar. In incident response or capacity planning, we rarely know the perfect answer. We make the best decision with the information we have, knowing a different first choice might have led somewhere else. Decision trees simply turn that idea into an algorithm. The bet a tree makes Every machine learning algorithm makes a different bet about the world. Logistic regression assumes relationships are smooth. Risk gradually increases as signals change. Decision trees make the opposite assumption. They assume the world is made of boxes. A project isn't slightly riskier because velocity drops. It's risky when several conditions happen together: a fixed-price contract, a new account manager, and a month-end delivery. Inside that box, projects fail. Outside it, they're usually fine. This is exactly how many operational systems work. Severity matrices, routing rules, escalation policies, approval workflows — they're all collections of decision boxes. That's why trees immediately felt intuitive to me. The hidden cost of flexibility Trees make very few assumptions about the data. That sounds like an advantage. The price is instability. Change a small part of the training data and the first split can change. Since every l

The 0.5.4 release notes carried an unusual section: Known issue shipped with 0.5.4 . We had spent that whole release fixing the first minute of using the CLI — twelve corrections to help text, exit codes, path handling, and MCP behaviour — and in the middle of it we found one more that did not make the cut. mendapi scan -h did not print help. It ran a scan. Every other subcommand normalized -h to --help before dispatching. scan did not, so the short flag fell through to the scanner, which happily ignored an unrecognized argument and started working. Nobody loses data over this. But it is exactly the kind of thing that makes a first-time user close the terminal, and we had just shipped a release about first impressions. We wrote it down rather than quietly patching over it, because a tool whose entire premise is upstream changes should be visible before they surprise you does not get to hide its own. What 0.5.5 does One change. -h is normalized to --help before any subcommand spawns, so all nine subcommands behave identically: $ npx mendapi@0.5.5 scan -h Usage: mendapi scan --repo <path> --provider <name> --change-id <id> --out <file.json> --json --quiet --include-prereleases The regression gate that covers this now asserts on all nine subcommands, plus a negative control that fails if the assertion ever becomes vacuously true. That second part matters more than the fix: a test that passes because it stopped testing anything is worse than no test. Also in this release The MCP registry entry has been refreshed. com.mendapi/mendapi now carries an icon set and a website URL alongside the package metadata, so clients that render a server picker have something to render. Nothing else changed. scan , fix , deps , review , and pr still run entirely on your machine. No network primitives exist in those files at all, and the build fails if any appear. Install npx mendapi@latest scan Or wire it into an agent: claude mcp add mendapi \ -- npx mendapi mcp Requires Node.js 22.13 o

Introduction Telegram has become one of the most popular platforms for sharing files, videos, images, and other media. However, when using Telegram Web, I found that saving media files was not always convenient. For example: downloading videos from channels saving multiple images managing large files The process usually requires several manual steps. So I decided to build a Chrome Extension to make Telegram media downloads easier. The project is called TGVideoDown. Website: https://tgvideodown.com Why build a Chrome Extension? At first, I considered building a standalone desktop application. But I realized that many Telegram users already use Telegram Web inside their browsers. A browser extension provides a simpler workflow: Open Telegram Web ↓ Find the media file ↓ Click download ↓ Save directly Users don't need: additional software complicated setup third-party upload services Technical implementation TGVideoDown is built with Chrome Extension APIs. Main technologies include: Content Script Used to interact with Telegram Web pages. Because Telegram Web is a dynamic application, the extension needs to handle: dynamic DOM updates asynchronous loading user interactions Chrome Downloads API Used to manage browser downloads. Example: chrome.downloads.download({ url: fileUrl, filename: fileName }) Storage API Used for storing user preferences and extension settings. Features Currently TGVideoDown supports: Telegram video downloads Telegram image downloads Telegram audio downloads Telegram GIF downloads Telegram file downloads Large file downloads Batch media downloading Challenges during development Handling dynamic pages Telegram Web uses a highly dynamic frontend. Traditional HTML parsing is not enough. The extension needs to monitor page changes and react when new media elements appear. Download experience Large media files require a smoother download process. The goal was to make downloading as simple as possible: Click → Download → Save Current sta

A single LINE Official Account can use multiple Messaging API tools. For example, one account might connect: A customer-support platform A campaign sender A rich-menu manager An analytics service An internal automation system But these tools do not receive isolated LINE channels. They share one Messaging API channel, one webhook URL, channel access-token limits, API rate limits, and feature-specific quotas. That makes adding another tool an architecture change—not just another OAuth or API-key setup step. This guide explains how to share the channel without accidentally disabling an existing tool or losing inbound messages. Understand the shared boundary LINE's official multiple-tools guidance confirms that multiple tools can call the Messaging API through one LINE Official Account. However, only one Messaging API channel can be linked to the account. Shared resource LINE constraint Operational risk Messaging API channel One channel per Official Account All tools share configuration Webhook URL One URL per channel A new tool can replace the existing receiver Channel access tokens Issuance limits vary by token type Rotation can disable another tool API rate limits Applied per endpoint and channel One tool can throttle another Messaging quota Shared by the account and plan Campaign traffic can affect support traffic Rich menus and audiences Channel-level limits Tools can overwrite or exhaust shared resources Before connecting another tool, identify exactly which shared resources it needs. Create an integration inventory Maintain a manifest for every system using the channel. tools : - name : support-platform owner : customer-support-team features : - receive-webhooks - reply-messages - push-messages token_type : v2.1 owns_webhook : true - name : campaign-service owner : marketing-operations features : - broadcast-messages - audience-management token_type : v2.1 owns_webhook : false - name : rich-menu-manager owner : product-team features : - rich-menu-management token

Since Lakebase uses a decoupled storage and compute architecture, the synchronous WAL flushes have to travel over the network to the distributed storage layer. How is Databricks Lakebase avoiding the standard network round-trip penalty per transaction commit? submitted by /u/Alternative-Fig-6465 [link] [留言]

submitted by /u/Strong-Seaweed8991 [link] [留言]

WordPress's plugin and theme update screens both have a "select all" checkbox. Calling check() on it with Playwright succeeds — no error, no exception. But look at the individual checkboxes afterward, and sometimes none of them are actually checked. Note: Playwright's check() ticks a checkbox. The click itself can succeed even if the page's JavaScript handler never fires, leaving what the form actually submits out of sync with what the screen visually shows. What actually happens The "select all" checkbox is usually wired up with a JavaScript handler: clicking it is supposed to check every individual checkbox underneath it. Playwright's check(force=True) can force the DOM state of that one checkbox — but that only changes that checkbox's own state . It doesn't guarantee the JavaScript handler that's supposed to propagate the change to the individual checkboxes actually fires. # Looks like it worked, but the individual checkboxes are still unchecked select_all . first . check ( force = True ) page . click ( ' input[type= " submit " ][name= " upgrade " ] ' ) Clicking the update button submits whatever the form's actual state is — which is "nothing checked." Nothing updates. No error is thrown, so on the surface it looks like the run completed normally. The fix — verify right after checking, every time Right after checking "select all," confirm that the individual checkboxes underneath are actually checked. If they aren't, fall back to checking each one individually. sel_all_sel = ' input[type= " checkbox " ][id^= " plugins-select-all " ] ' select_all = plugin_form . locator ( sel_all_sel ) if select_all . count () > 0 : select_all . first . check ( force = True ) page . wait_for_timeout ( 500 ) # Verification step — confirm checkboxes are actually checked chk_sel_check = ' input[type= " checkbox " ][name= " checked[] " ]:checked ' any_checked = plugin_form . locator ( chk_sel_check ). count () > 0 if not any_checked : # Select-all had no effect; switch to individual s

When you open a long page — a news feed, an admin table, a documentation article — the browser lays...

Part 1 : Understanding Token Economics, Hidden Costs, and the Fundamentals Every AI Engineer Must Know Table of Contents Introduction Why Token Cost Optimization Matters More Than Ever Understanding What a Token Really Is How LLM Providers Charge for Tokens Input Tokens vs Output Tokens Why "Cheap Prompts" Can Become Expensive Hidden Sources of Token Costs The Real Cost of Production AI Systems How Token Costs Scale with Users The Cost Optimization Mindset Key Takeaways Introduction If you have ever built an AI application using GPT, Claude, Gemini, Llama, or another large language model, you've probably celebrated the moment your first prompt worked. The model answered intelligently, users loved the experience, and everything seemed perfect. Then came the cloud bill. What initially looked inexpensive suddenly became one of the largest operational costs in your application. Many developers assume AI infrastructure is expensive because of GPUs. Surprisingly, for many production applications, tokens—not GPUs—become the biggest recurring expense . Every prompt, every response, every retrieved document, every conversation history, and every AI agent interaction consumes tokens. Those tokens translate directly into cost. Imagine building an AI customer support chatbot. It serves 500 users during testing, and costs seem negligible. After launch, the application attracts 50,000 daily users. Each interaction now includes system prompts, conversation history, retrieved documents, tool outputs, and generated responses. Without careful optimization, token usage grows exponentially—and so does your bill. This is why token cost optimization is no longer just a performance concern. It has become a core engineering discipline. Just as software engineers optimize CPU and memory, AI engineers must optimize tokens. This guide is designed to help you understand the economics behind token usage before diving into optimization techniques. By mastering these fundamentals, you'll be able

Modern backend applications handle thousands or even millions of requests every second. Users perform actions simultaneously: buying products, transferring money, updating profiles, sending messages, and more. But what happens when two requests try to modify the same data at the same time? This is where race conditions appear — one of the most subtle and dangerous problems in backend development. A race condition can cause incorrect data, security issues, financial losses, and unpredictable application behavior. Understanding how race conditions happen and how to prevent them is an essential skill for backend developers. What Is a Race Condition? A race condition occurs when multiple processes or requests access and modify shared data at the same time, and the final result depends on the order in which those operations execute. The problem is that the developer expects operations to happen in a specific sequence, but the computer executes them based on timing, network delays, database speed, and system load. Simple Example: Bank Account Withdrawal Imagine a user has: Account Balance: $100 Two withdrawal requests arrive at the same time: Request A: Withdraw $80 Request B: Withdraw $50 The backend checks the balance: Request A: Balance >= 80? Yes Request B: Balance >= 50? Yes Both requests continue because they saw the original balance of $100. The system processes: $100 - $80 = $20 $100 - $50 = $50 The final balance might become: $50 instead of: -$30 (which should have been rejected) The application has allowed money to be withdrawn that does not exist. This is a race condition. How Race Conditions Happen in Express.js Express.js applications are often built around asynchronous operations: Database queries API calls File operations Background jobs Message queues Consider this simple inventory system: app . post ( " /purchase " , async ( req , res ) => { const product = await Product . findById ( req . body . productId ); if ( product . stock > 0 ) { product . stock -

In an era where privacy is the ultimate luxury, our most sensitive data—heart rates, sleep cycles, and activity levels—is often shipped off to black-box cloud servers for "analysis." But what if you could keep that data strictly on your local machine? Today, we are building a Private Health Brain . By leveraging the MLX framework (Apple's dedicated machine learning library) and Llama-3 , we will transform raw XML exports from Apple HealthKit into actionable health insights—all running locally on your MacBook. We’ll cover everything from parsing messy XML with Pandas to running high-performance local AI inference without an internet connection. If you are interested in privacy-preserving AI , Edge computing , or just want to squeeze every bit of power out of your Apple Silicon chip, this guide is for you. The Architecture: Local Data Flow To ensure 100% privacy, the data never leaves your local environment. Here is how the pipeline works: graph TD A[Apple Health Export.zip] -->|Extract| B(export.xml) B -->|Python + Pandas| C{Data Cleaning} C -->|Structured JSON/CSV| D[Local Context Window] E[MLX Framework] -->|Load Weights| F[Llama-3 Model] D -->|RAG / Prompt Injection| G[Inference Engine] F --> G G -->|Result| H[Private Health Insights] style H fill:#f96,stroke:#333,stroke-width:2px Prerequisites 🛠️ Before we dive in, ensure you have an Apple Silicon (M1/M2/M3) Mac . MLX : Apple’s framework for machine learning on Apple Silicon. Llama-3 : We’ll use the 8B-Instruct version for a balance of speed and intelligence. Python 3.10+ Pandas : For data manipulation. Install the necessary libraries: pip install mlx-lm pandas lxml Step 1: Parsing the HealthKit XML Monster Apple Health exports data in a massive export.xml file. It’s nested, verbose, and a nightmare to read manually. We’ll use Python to extract specific metrics like Step Count or Heart Rate Variablity (HRV) . import pandas as pd import xml.etree.ElementTree as ET def parse_health_data ( xml_path ): print ( " 🚀 Pa

Every once in a while an AI announcement lands that isn't about a chat UI or a new benchmark, but about the actual substance of what these systems can now do. OpenAI's announcement of ten new results in mathematics and theoretical computer science — produced by an internal version of Astra, their next major model — is one of those moments. Here's what happened, why it matters beyond the math community, and where the honest caveats are. The results The ten problems span high-dimensional geometry, coding theory, arithmetic circuit complexity, group theory, operator algebras, quantum complexity, lattice cryptography, and extremal combinatorics. Highlights include: Non-sofic groups — a construction establishing their existence, addressing a central open question in group theory. Connes's rigidity conjecture — a disproof of a longstanding conjecture about von Neumann algebras. Quantum parallel repetition — an exponential parallel repetition theorem for general two-player quantum games. Multicolor Ramsey numbers — a superexponential lower bound, resolving Erdős problem 183. Closest vector problem — polynomial-factor hardness of approximation, a foundational lattice question tied to post-quantum cryptography. Each argument was prepared into a manuscript by humans working with the model, then formalized by the model into a Lean certificate (the proofs are public on GitHub). OpenAI also released the model's narration of its own thinking process for each solution. The price tag that reframes everything The most striking number in the announcement isn't the math — it's the cost. The total tokens needed to find these solutions would cost roughly $2,000 at Sol API rates . Think about that for a second. Two thousand dollars of compute to resolve open problems that mathematicians have worked on for decades. Some of these (like non-sofic groups) have been open for over a decade of intense effort. We're not talking about a moonshot lab budget — we're talking about the price of a mid

The first time we deployed Celery to production on a client project, we thought we had done everything right. We had workers running, tasks queuing, and Redis as the broker. Six weeks later, the task queue was backed up with 40,000 unprocessed jobs, the workers had silently died, nobody knew, and a batch of client invoices had not been generated for two weeks. That was four years ago. Since then we have deployed Celery on dozens of projects and we have learned what actually goes wrong — not in development, where everything works, but in production, where things fail in ways you do not anticipate. This post covers the configuration and operational patterns we now use on every Celery deployment. Why tasks fail silently (and how to stop it) The most dangerous thing about Celery is how quietly it can fail. A worker process dies, the task queue fills up, and your application keeps accepting work and sending it to a queue that nobody is processing. No exception is raised. No alert fires. Users notice eventually, or you notice when a daily report does not arrive. The fix has two parts: monitoring and task acknowledgement configuration. Task acknowledgement By default, Celery acknowledges a task (removes it from the queue) as soon as a worker picks it up, before the task runs. If the worker dies mid-task, the task is lost. # celery.py app = Celery ( ' myproject ' ) app . conf . update ( # Only acknowledge after the task completes successfully task_acks_late = True , # If a worker dies, reject the task back to the queue task_reject_on_worker_lost = True , # Limit memory — workers that leak memory will restart cleanly worker_max_memory_per_child = 200_000 , # 200MB in KB # Limit tasks per child process to prevent long-running workers # from accumulating state worker_max_tasks_per_child = 1000 , ) With task_acks_late=True , a task that is picked up by a dying worker will be requeued and picked up by another worker. The task might run twice (more on that shortly), but it will n

Explore new education plugins for ChatGPT Work and Codex that help K–12 teachers, college educators, and students learn, teach, research, and build.

After a quarter that delivered $1 billion in profit, Palantir CEO Alex Karp on Monday once again warned that AI frontier labs are too untrustworthy for enterprises.

When asked about product-market fit, Spiegel said he believes mass-market consumer adoption won't occur until the end of the decade.

OpenAI addresses Apple’s baseless lawsuit, corrects claims about its employees, and shares messages documenting what happened.

Sololearn’s Introduction to Python course is wrapping up today with a brand new topic. Today’s post is wrapping up module four by introducing. You’ll learn what slicing is and how to slice a list in Python. Sequences like lists and strings are ordered content. Ordered content is great for indexing and slicing. In addition to learning about slicing, Sololearn shares some advanced slicing and indexing tips to help you with your code. Slicing Slicing lets developers take portions from a list that they need. You’ll be slicing lists all the time in your Python code. At Coding with Kids, the students were slicing lists as they were building games. To slice a list, put the variable name of list followed by an opening square bracket. Put the index you want to start slicing at. Place a colon (:) after this. Put the index when you want to stop slicing at then place the closing square brackets. Here’s an example of slicing in action. I created a variable called pizza_toppings with a list of strings assigned to them. The starting index is inclusive while the stopping index is exclusive. pizza_toppings = [ " pepperoni " , " mushrooms " , " onions " , " peppers " , " broccoli " , " sausage " ] print ( pizza_toppings [ 0 : 3 ]) # print pepperoni, mushrooms, and onions The line underneath the list is slicing the first 3 toppings from the list. I’m printing them to the console to make sure these three are displaying. If you see the wrong toppings or too many items, double check the index you are starting and ending with. Slicing a String Strings can be sliced to in the same way we did the example above. Here’s a variable with a string assigned to it. If I want to slice certain letters in the string, I will put the indexes where I should start and stop at. pizza = " pepperoni " print ( pizza [ 0 : 6 ]) # print pepper When I sliced this string, I was able to move data from a sequence. In this example, I’m able to create a brand new string. If you look at the the pizza topping example