今日已更新 88 条资讯 | 累计 40862 条内容
关于我们

标签:#ast

找到 376 篇相关文章

AI 资讯

Dr. Jill Lepore on why AI backlash is vital for the future

Today, I’m talking with Harvard professor and New Yorker staff writer Dr. Jill Lepore about her new book, The Rise and Fall of the Artificial State, which comes out on August 25. Jill is one of the best writers there is at identifying institutional patterns in history, and Decoder is a show about systems, so […]

2026-07-20 原文 →
AI 资讯

Presentation: Platform Engineering for Everyone - Success Can’t Be Coded

Max Korbacher explains why successful internal development platforms cannot be built on tech alone. He discusses the pitfalls of infrastructure-first thinking, the importance of a clear product mindset, and how to measure real value using DevEx and SPACE metrics. Learn how to align your team, manage tech debt, and foster a thriving community to ensure lasting platform adoption. By Max Körbächer

2026-07-20 原文 →
AI 资讯

Podcast: Strands Agents with Clare Liguori

Thomas Betts talks with Clare Liguori, the technical lead on the open source Strands Agents SDK. The conversation covers how Strands Agents has grown from a Python SDK to a full agent harness running in production. Clare shares some lessons learned from building agents at scale, shifting to a model-driven architecture, and what comes next as the LLMs that underpin agents continue to improve. By Clare Liguori

2026-07-20 原文 →
AI 资讯

One Bucket, Two Terraform Owners - the Last apply Wins

Originally published at blog.whynext.app . It started as an ordinary cleanup problem. Users upload media files (recordings and images) through presigned URLs. The server issues an upload URL, the client uploads straight to S3, then calls a commit API to say "register this key as a real asset." The problem is what happens when someone gets a presign but never commits. The app crashes, the network drops, the user leaves the screen, and the bucket is left with an object that isn't registered anywhere. I wanted a lifecycle rule to clean these up, but there was no way to write one. Committed and uncommitted objects were mixed under the same prefix, so any rule that says "delete old things" would delete real assets too. A daily upload quota kept the pile from growing fast, but the fact remained: there was no path to reclaim the space. The design: what isn't committed lives in tmp The backbone of the fix is key namespace separation. presign issues a temporary key under the tmp/ prefix. When commit passes validation (existence check via HEAD, Content-Type, size limit), it promotes the object to its final key with CopyObject and deletes the tmp original. Objects whose commit never arrives stay in tmp/ , and a lifecycle rule expires them after 7 days. Now the lifecycle rule only has to look at tmp/ . Real assets are outside its blast radius from the start. The clients didn't need to change. I read all three upload flows to confirm this: every one of them uses the key returned in the commit response for its follow-up calls, so the server can change the key shape without them noticing. Commits for old-format keys already in flight at deploy time still go through the existing path. One trap here. This bucket has versioning enabled. On a versioned bucket, expiration doesn't delete an object. It only adds a delete marker, and the original bytes stay behind as a noncurrent version. Without a paired noncurrent_version_expiration (1 day), the cleanup runs and not a single byte is rec

2026-07-19 原文 →
AI 资讯

A Book of Wrong Answers

There is a note in my runbooks that says the Enter key works. That is almost the whole note. Press Enter and the prompt submits. I wrote it in bold, with sources and a date, because one of my AI agents once fixed the Enter key. The fix was the bug. The Fix Was the Bug I run a fleet of Claude Code agents in tmux panes. An orchestrator script types a prompt into a pane and presses Enter for it. One day an agent decided the submissions were not going through, and it knew the fix: send a backslash before the Enter. That sounds plausible if you have ever fought a terminal. It is also exactly backwards. In Claude Code, backslash plus Enter inserts a newline. It is the multiline key. So the fix turned every prompt into a draft that quietly grew longer and never sent. The panes looked busy. Nothing was happening. The submissions had been fine all along. The agent just had not waited for the reply. What broke: An agent changed Enter to backslash-Enter to repair prompt submission. Backslash-Enter creates a newline, so the repair silently stopped every prompt from sending. The system it fixed had never been broken. There is a second note in the same genre. My monitoring dashboard answers its health check with a 302 redirect to the login page. That is what healthy looks like there. But a 302 looks like trouble if you are hunting for outages, and agents kept trying to repair it. So the runbook now says, more or less: the redirect is normal, do not fix the healthy system. Human teams do not write notes like these. Nobody pins "the Enter key works" to the wall of an office. A New Hire Every Session Why did I have to? Because a human hits a dead end once. The wince is the documentation. Whoever broke a build by fixing the Enter key would remember it for years, tell the story at lunch, and the whole team would absorb it without anyone writing a word. An agent has none of that. It has no episodic memory. Every fresh context window is a new hire: smart, fast, and seeing your system fo

2026-07-18 原文 →
开发者

Source View Technology: Combining the Strengths of APT and AST

Background Take Lombok as an example: at compile time, it reads annotations like @Getter and @Setter through an Annotation Processor (APT, Annotation Processing Tool), then directly modifies the AST (Abstract Syntax Tree) in memory, injecting getter/setter methods for fields. Developers only need to annotate fields, and the compiled .class files automatically include these methods. Advantages of APT APT is an extension mechanism natively supported by the Java compiler. Annotation processors run at compile time and can read annotation information from source code to generate new source files. Its advantages are: Standardized — Simply implement the Processor interface; no need to hack the compiler Composable — Multiple annotation processors can work together in the same compilation process Generated code is visible — Source files generated through the Filer API are located in the build/generated/ directory, and IDEs can navigate to them after configuring the source path Disadvantages of APT APT has a fundamental limitation: it cannot generate a class with the same fully qualified name as the source code. The Java compiler explicitly specifies that two classes with the same fully qualified name are not allowed in the same compilation unit. Source code generated by APT participates in the same round of compilation as the original source code, so it can never generate a class with the same fully qualified name as the original class. This means APT cannot truly "modify" a class; it can only generate new classes (such as Builder, Factory, etc.). Advantages of AST Tools like Lombok bypass the APT limitation by directly modifying the AST in the compiler's memory — injecting methods for fields, injecting constructors for classes, etc. The advantages of AST modification are: Can modify existing classes — Methods are added directly to the AST in memory, breaking through the limitation that APT cannot generate Same-Name Classes Zero intrusion — Classes written by developers rema

2026-07-18 原文 →
AI 资讯

Apple’s plot to crush OpenAI

Apple is suing OpenAI. The complaint is readable and intense, as these things often are, though many experts seem to think many of the allegations are just the ways things are done. So what does Apple really want here, and why is it picking such a public fight with OpenAI? On this episode of The […]

2026-07-18 原文 →
AI 资讯

A FastAPI Agent Template Is Not Production-Ready Until Task Ownership Crosses Every Layer

Vercel published an OpenAI Agents SDK with FastAPI template on July 17, 2026. A template can remove setup work, but successful generation is not the production boundary that usually breaks. Task ownership is. Primary source: Vercel template, “OpenAI Agents SDK with FastAPI” . Before adopting any agent starter, I would add one vertical test: Alice must be able to create and cancel her task; Bob must not be able to read, stream, or cancel it—even if he guesses the task ID. State the cross-layer contract UI -> POST /tasks -> ownership row -> worker UI <- GET /tasks/:id <- authorization <- state UI <- event stream <- authorization <- events UI -> POST /tasks/:id/cancel -> authorization -> cancellation Use explicit states: queued -> running -> succeeded -> failed queued|running -> cancelling -> cancelled The database, API response, stream, and UI must agree on the same task and owner. Minimal schema create table tasks ( id text primary key , owner_id text not null , state text not null check ( state in ( 'queued' , 'running' , 'succeeded' , 'failed' , 'cancelling' , 'cancelled' )), created_at text not null , updated_at text not null , revision integer not null default 0 ); create table task_events ( task_id text not null , revision integer not null , kind text not null , payload text not null , primary key ( task_id , revision ) ); Do not derive ownership from a browser-supplied field. Resolve the authenticated principal on the server and store it when creating the task. FastAPI authorization seam from fastapi import Depends , FastAPI , HTTPException app = FastAPI () def current_user (): # Replace with verified session/JWT middleware. return { " id " : " alice " } def load_owned_task ( task_id : str , user = Depends ( current_user )): task = db_get_task ( task_id ) # application function if task is None or task [ " owner_id " ] != user [ " id " ]: # Avoid revealing whether another user's task exists. raise HTTPException ( status_code = 404 , detail = " task not found " )

2026-07-17 原文 →
AI 资讯

GDPR Compliance Fails When It Exists Only in Policy Documents

GDPR Compliance Fails When It Exists Only in Policy Documents Many organizations can produce a privacy policy, a data processing register, and a set of security procedures. The harder question is whether their infrastructure can actually protect, recover, trace, and report personal data when something goes wrong. GDPR compliance is often discussed as a legal project. In practice, many of its most difficult requirements depend on everyday IT operations. Can the organization recover personal data after a destructive incident? Can it identify who restored, copied, accessed, or deleted a backup? Can it detect suspicious activity quickly enough to support an investigation? Can it demonstrate that protection controls are applied across on premises, cloud, and hybrid environments? Policies explain intent. Operational controls provide evidence. Availability Is a Privacy Requirement Too Privacy discussions often focus on unauthorized access and disclosure. Data loss and prolonged unavailability matter as well. Personal data may become unavailable because of ransomware, storage failure, accidental deletion, database corruption, software defects, or a regional outage. If the organization cannot restore that data, it may be unable to serve customers, respond to data subject requests, or maintain essential business processes. A GDPR aligned protection strategy should therefore include reliable backup, offsite copies, tested recovery, and resilience across multiple failure scenarios. The backup architecture should support the systems that actually contain personal data, including databases, virtual machines, file servers, object storage, cloud workloads, and large data platforms. Protecting only the most visible applications leaves hidden gaps. Encryption Is Necessary, but It Is Not the Whole Answer Encryption protects data during transmission and storage, especially when backup copies move across networks or are stored outside the production environment. However, encrypted data

2026-07-16 原文 →
AI 资讯

What Is My IP Address? IPv4 vs IPv6 Explained for DevelopersPublished

What Is My IP Address? IPv4 vs IPv6 Explained for Developers If you've ever debugged a CORS error, set up an IP allowlist, or wondered why req.ip returned something weird in your Express logs, you've run into the same question from a different angle: what actually is an IP address, and which one is "mine"? fastestchecker.com This post breaks down IPv4 vs IPv6, public vs private IPs, and how to reliably detect a user's IP address in your own code — plus a fast way to check yours right now. fastestchecker.com TL;DR IPv4 addresses look like 192.168.1.1 — four numbers, 0-255, separated by dots. There are about 4.3 billion of them, and we've run out. IPv6 addresses look like 2001:0db8:85a3::8a2e:0370:7334 — a much larger address space designed to replace IPv4. Your device usually has a private IP (local network) and shares a public IP (internet-facing) with everyone else on your router. You can check your current public IP instantly with a tool like FastestChecker's IP Checker — useful for confirming what your server or API actually sees. > IPv4 vs IPv6 : What's the Actual Difference IPv4 IPv4 has been the backbone of the internet since the 1980s. It's a 32-bit address, which caps the total number of unique addresses at roughly 4.3 billion. Given how many devices are online today, that pool has been effectively exhausted for years — which is why NAT (Network Address Translation) exists: it lets an entire household or office share one public IPv4 address. Example IPv4: 203.0.113.42 IPv6 IPv6 uses 128-bit addresses, which gives it an address space so large it's effectively unlimited for practical purposes (2^128 addresses). It was designed specifically to solve IPv4 exhaustion, and adoption has been climbing steadily — most major cloud providers and mobile carriers support it by default now. ** Example IPv6:** 2001:0db8:85a3:0000:0000:8a2e:0370:7334 Quick Comparison IPv4IPv6Address length32-bit128-bitFormatDotted decimal (192.168.1.1)Hexadecimal, colon-separatedTotal addre

2026-07-16 原文 →
AI 资讯

Scale Is a Design, Not a Dial

The dashboard says forty instances, up from twelve this morning. The autoscaler did its job: it saw latency climb and threw hardware at it. And latency got worse. Not flat. Worse. You're paying for three times the compute to serve a slower product. Somewhere under all forty of those boxes is a single thing they're all waiting in line for, and every instance you add makes the line longer. Horizontal scaling multiplies work that doesn't have to coordinate. The instant the work does have to coordinate, more instances make it slower. Amdahl wrote this down in 1967: the serial fraction of a job sets a hard ceiling on how much faster you can go, no matter how much hardware you throw at the parallel part. Neil Gunther's Universal Scalability Law goes further: past a certain point, the cost of nodes coordinating with each other bends the curve back down. Add capacity, get less throughput. That ceiling was not set by the autoscaler, and it will not be moved by the autoscaler. It was set a long time before this morning, in a room, by whoever decided where the state lives and who has to touch it at the same instant. Now hand the service to a fleet of agents. It writes you something that looks built to scale: stateless handlers, a tidy repo, green tests, a canary that bakes fine at 1% traffic. Every gate you trust says ship it. And the bottleneck is sitting right there in the design, invisible to all of it, because the mistake isn't in the lines, it's in the shape. You cannot catch a shape problem by reading a diff. Name the hot state before you pick a framework. Where does the contended state live, and which requests touch it at the same instant? Answer that out loud, before anyone opens an editor. The tool is downstream of that answer, every time. Originally published at https://imacto.com/writing/scale-is-a-design-not-a-dial . Written with Claude Opus 4.8.

2026-07-15 原文 →