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

标签:#att

找到 194 篇相关文章

AI 资讯

Presentation: A Few Predicted Talks From QConAI 2030

Meryem Arik discusses her predictions for software engineering in 2030. She explains how token spend management, parallel agent infrastructure, and non-technical builders will reshape IT. She shares insights on agent-driven vendor decisions, upcoming regulatory hurdles, and why software engineers must pivot from pure coding skills toward product leadership and multi-agent coordination. By Meryem Arik

2026-09-05 原文 →
AI 资讯

Why My React App Still Runs on Singleton Classes

React spent the last decade training developers that a class is a code smell. Class components got deprecated, hooks won, and "just write a function" became the default advice for almost everything. That advice runs into a wall the moment a piece of code has to run outside a component: an HTTP interceptor, an event listener, a background task, a deep-link handler. None of those have a render tree to sit inside, which means none of them can call a hook. That's not a style opinion. It's a hard constraint. It's also the reason core pieces of infrastructure in most non-trivial React codebases — auth tokens, feature flags, routing rules, device identity, analytics — end up as classes, usually singletons, imported directly instead of consumed through a hook or a context provider. The render-tree boundary problem A hook only exists while its component exists. useState allocates memory tied to a place in React's tree; the moment that component unmounts, the state is gone, and before it mounts, the state isn't reachable at all. That's fine for almost everything a component owns. It stops being fine the moment something outside the tree needs the same piece of state. Authentication is the clearest version of this. A typical setup keeps the access token in a hook, refreshed on a timer, exposed to whatever component needs it: export const useSessionTokens = (): UseSessionTokens => { const [ tokens , setTokens ] = React . useState < AuthTokens | null > ( null ); const refreshAccessToken = async () => { if ( ! tokens ?. refreshToken ) return ; const newTokens = await refreshAndSetTokens ({ refreshToken : tokens . refreshToken }); setTokens ( newTokens ); return newTokens ; }; // ... return { tokens , refreshAccessToken , /* ... */ }; }; Perfectly normal hook. The problem shows up one layer down: an HTTP client's request interceptor is a plain function, registered once at app boot, running completely outside React's render tree. It can't call useSessionTokens() — it isn't a compon

2026-09-01 原文 →
AI 资讯

Mastering the Adapter Pattern in Java: Bridging Modern Architectures and Legacy Systems

1. Fundamental Base: The Problem and the Theory 1.1 Introduction The Adapter Pattern (also widely known by its alias, Wrapper ) belongs to the Structural Design Patterns category. Structural patterns deal with object composition, establishing clean relationships and interfaces across disparate classes to form larger, flexible structures without introducing tight coupling. According to the canonical definition by the Gang of Four (GoF): "Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces." (Gamma et al., 1994). In enterprise Java ecosystems, the Adapter pattern serves as an indispensable architectural bridge whenever we need to integrate legacy components, proprietary third-party SDKs, or external services whose contracts diverge from our core domain model. 1.2 The Problem: Architectural Friction with Incompatible Interfaces In day-to-day software engineering, teams frequently encounter highly stable, battle-tested utilities, mainframe integrations, or third-party libraries whose public interfaces do not match the domain interface required by the consuming system. When this structural friction occurs, developers often face three problematic alternatives: Modifying the existing class/service ( Adaptee ): Often impossible when consuming compiled third-party JARs or closed-source code. Even if the source code is available, forcing low-level infrastructure or external utilities to adopt domain-specific contracts violates the Single Responsibility Principle (SRP). Polluting the client code: Littering domain services with primitive type conversions, legacy status parsing, and foreign dependencies introduces tight coupling and tech debt. Rewriting the component from scratch: Incurs massive engineering costs, delivery delays, and high regression risks in critical, already-validated business logic. The core problem the Adapter pattern solves is: how can we enable

2026-08-31 原文 →
AI 资讯

The State Pattern Trap: Why GoF Is Not Always the Best Choice

Have you ever tried to use the classic Gang of Four (GoF) State Pattern in real code? You might have hit a wall. You might have thought, "Wait, this feels way too connected." You are not wrong about that. In school and many engineering interviews, the GoF State Pattern looks great. It promises to fix big, ugly switch statements. But real business rules are hard. When you use this pattern in real life, it can become a huge mess. Every state knows too much about the other states. Let us look at why this happens. We will learn the difference between the GoF pattern and a Finite State Machine (FSM). We will also learn when to use each one. The False Promise of the GoF State Pattern The main idea of the GoF State Pattern is to spread out the work. The main object gives its work to state objects. But there is a catch. The state classes themselves must trigger the change to the next state. Example: The Traffic Light Think about a simple traffic light. It goes Red to Green to Yellow to Red. It does this forever. class RedState implements TrafficLightState { change ( context : TrafficLight ): void { console . log ( " RED light, Stop " ); context . setState ( new GreenState ()); // Very connected! } } The Problem: RedState is forced to know about GreenState . This is fine for a simple traffic light. It is a closed loop. The rules will never change. But what happens when business rules change? Imagine the city council makes a new rule. From midnight to 5:00 AM, the light must flash yellow. Now, you must open your RedState and YellowState classes. You have to add new time checks. You have to add the new flashing state. The more states you add, the messier your code gets. The Better Choice: The Central FSM In the real world, things do not always happen in a straight line. An online order does not just go from Pending to Shipped to Delivered. It can jump from Pending to Cancelled. It can go from Shipped to Returned. If you use GoF here, your PendingState needs to know about many

2026-08-26 原文 →
AI 资讯

Dictionary Pattern Matching in Some Languages Ignores Unspecified Keys, Risks Unexpected Bugs

Introduction Pattern matching, a powerful feature in many programming languages, allows developers to deconstruct complex data structures with elegance and precision. However, when it comes to dictionaries , this elegance can mask a critical issue: non-strict shape matching . Unlike sequence patterns, which demand an exact match, dictionary pattern matching in certain languages silently ignores unspecified keys. This behavior, while seemingly flexible, can lead to unexpected bugs and security vulnerabilities if developers assume strict shape enforcement. To illustrate, consider a dictionary pattern match in a language like Python or Rust. If you write a pattern to match a dictionary with keys {'a', 'b'} , and the actual dictionary contains {'a', 'b', 'c'} , the match will succeed, and the key 'c' will be ignored. This might seem harmless, but it violates the developer’s expectation of a strict shape match, akin to what sequence patterns provide. The causal chain here is straightforward: impact (developer assumes strict matching) → internal process (language ignores unspecified keys) → observable effect (unexpected behavior or bugs). The root of this issue lies in the design choice of prioritizing flexibility over strictness. Languages often default to this behavior to accommodate varying data shapes, but this comes at the cost of clarity and predictability. Compounding the problem is the lack of clear documentation or understanding of this behavior, leading developers to make incorrect assumptions based on their experience with sequence patterns. For instance, in a system where data integrity is critical, such as financial transactions or security protocols, silently ignoring keys could lead to data corruption or unauthorized access . If a developer expects a dictionary to have exactly three keys but the pattern matches a dictionary with four, the extra key might contain malicious data or disrupt downstream logic. The mechanism of risk formation here is the mismatch

2026-08-25 原文 →