标签：#AR

I had twenty-two passing tests and two separate reviewers on a piece of code. None of it objected. Then I pointed it at a real API owned by somebody else and it broke on the first live read. The mismatch fit in one sentence: my parser required ISO 8601, the documented API returned Unix seconds. The repair was not one line. It touched five files, 74 lines of parser and 52 lines of tests. The assumption was small; making it safe was not. Here is why nothing caught it, and it is the part worth keeping: My tests used ISO because my code used ISO, so they agreed with each other and never checked reality. The fixtures were written by the person who wrote the parser. They encoded the same assumption. The suite confirmed internal behaviour without ever challenging the ISO assumption, because both halves of it came from one head. Internally consistent is not the same claim as right, and nothing in that suite could tell the difference. Two separate reviewers missed it too. I cannot prove why, and I am not going to invent a reason. What I can show is that the parser and every fixture encoded the same ISO assumption, so none of the artifacts in front of anyone supplied the live contract that contradicted it. The second one was worse Working against a real system made redirect containment matter, so an independent breaker went at it. In Python 3.13 the default redirect handler rebuilds the redirected request from req.headers , dropping only content length and type. My X-API-Key sat in that header set, so the redirected request inherited it. Python has Request.add_unredirected_header() for exactly this, which marks a header as one that will not be added to a redirected request. I was not using it. The breaker reproduced it offline with a sentinel value and a cross-origin Location , and the sentinel crossed. No live FIPSign credential was ever shown to have crossed an origin. The defect was real and unshipped. I did not find it by auditing my own code, and I did not find it myself

After spending the past two weeks redoing all the models around the house, I realized it might make a good topic to chat about. I know that everyone and their brother has their own way to figure out what models they want to run on their hardware, but I figure that my own criteria might help some of the Mac users out there, so I'm tossing it into the mix as well. Picking which models to even compare When a new model comes out, the first thing I always do is check what folks are saying: huggingface discussions, reddit comments, etc. Benchmarks are useful, but I want to know what happens when people actually use the thing. Is the tokenizer broken or llama.cpp/mlx implementation bugged? Does it follow instructions? Overthink? Hallucinate a bunch? Discussion comment sections are a treasure trove of info. After that, I go peek at the model on Artificial Analysis. I know AA isn't everybody's favorite way to judge models, but honestly it has a pretty solid litmus test for whether the model will be good for me or not. In particular, there are a specific few benchmarks there which line up really well with what I need: strong context reasoning hallucination rate how many output tokens the model used to get its scores That last one is one of the most important. Combined with the "Humanity's Last Exam" score and overall intelligence, it gives me an idea of how much output the model had to produce to actually land on its current spot on the leaderboard. On a Mac, I really care about that. Remember: our compromise with Macs is getting stupidly large amounts of VRAM at the price of everything being a lot slower than NVidia GPUs, especially as context and token generation sizes increase. So if one model gets a slightly better score by generating dramatically more tokens, you gotta keep that in mind. Really long-winded thinking sessions could make a model almost unusable. You might think "I don't mind waiting for quality", but then suddenly find yourself just going to ChatGPT because

First of all, I warmly welcome everyone out there in the DEV Community. [Completely open for discussion — drop your thoughts below.] From my perspective, it feels like everyone is racing towards AI/ML. The moment someone says they want to become an AI/ML Engineer, the conversation immediately shifts towards: Python → ML → Deep Learning → LLMs → Latest AI Tools And thinking about it, well, it’s quite understandable too. AI is one of the most exciting areas in technology right now. BUT, I have a question… Why are we starting to treat AI/ML Engineering as something completely different from Software Engineering? I often see people following an extremely narrow path towards AI/ML while completely skipping the fundamentals of Software Engineering. Backend development gets ignored. Databases, networking, operating systems, system design — all of them get ignored. And afterwards: APIs, deployment, testing, distributed systems… All of these seem quite trivial, right? Because the end goal is simply to create or automate something with AI. But it’s quite clear to me that AI can’t possibly live by itself. For any AI model to thrive, we need data. That data needs storage and pipelines. A model needs an application around it. That application needs APIs. Those APIs need backend infrastructure. And now we have an actual system. That system needs to be monitored for bugs, optimized for CPU and memory efficiency, refactored when necessary, maintained over time, and tested against new use cases. So thinking about all of this: How does one even fathom becoming an AI/ML “Engineer” without understanding what they are actually engineering into and working on? Maybe AI/ML Engineering and Software Engineering aren’t two completely different entities. Maybe they are different components of the same system. Now, I’m not saying: “You should become an expert in everything.” Specialization is indeed important. But specialization doesn’t necessarily mean abandoning the fundamentals that the spe

For Job Postings please use this template Hiring: [Location], Salary:[], [Remote | Relocation], [Full Time | Contract | Part Time] and [Brief overview, what you're looking for] For Those looking for jobs please use this template Want to be Hired: [Location], Salary Expectation:[], [Remote | Relocation], [Full Time | Contract | Part Time] Resume: [Link to resume] and [Brief overview, what you're looking for] ​ Please remember that this community is geared towards those with experience. submitted by /u/AutoModerator [link] [留言]

You've probably seen the term RAG everywhere lately — "RAG pipeline," "RAG chatbot," "build your own RAG app." It sounds complicated, but the idea behind it is actually pretty simple. In this article, I'll explain RAG in plain language, then walk through how it works using a real project I built: Guidely , an internal knowledge assistant that answers questions using a company's own documents. The Problem RAG Solves Large language models (like GPT or Claude) are trained on a huge amount of general knowledge, but they don't know about your specific data — your company's internal docs, your product manuals, your onboarding guides. They also can't be retrained every time a document changes; that's slow and expensive. RAG solves this without retraining the model at all. Basically: RAG means: before answering a question, first go find the relevant pieces of your own documents, and hand those to the AI along with the question. That's it. "Retrieval" (finding the right information) + "Augmented Generation" (the AI answers using that information). Instead of the AI answering from memory alone, it answers using facts you hand it in the moment. The Three Core Pieces Let's break down the three things you need to make this work: chunking , embeddings , and vector search . 1. Chunking — Breaking Documents Into Pieces You can't hand an AI model an entire 200-page document and ask it to search through it efficiently. So the first step is splitting documents into smaller, manageable pieces called chunks . In Guidely, I used a token-window chunker — it splits text based on a fixed number of tokens (roughly, pieces of words) per chunk, rather than just splitting by paragraph or sentence. This matters because: Chunks that are too big waste space and slow things down. Chunks that are too small lose context and produce confusing answers. A token-window approach gives you consistent, predictable chunk sizes, which makes the next steps more reliable. 2. Embeddings — Turning Text Into Numbe

Third-year PhD student, NLP / interpretability. I want a reality check from people doing similar work. I started using Claude Code for the boring parts: argparse boilerplate, plotting, config wrangling. Over the last few months the scope has crept. It now writes most of my experiment scaffolding, refactors my dataloaders, does first-pass debugging on training runs, and drafts the analysis scripts. I mostly read diffs and say yes. The output is fine. My throughput is up. The thing bothering me is that I no longer hold my own codebase in my head. When a result looks off, I used to have an instinct about which line was lying to me. Now I go hunting like it’s someone else’s repo. I catch bugs later than I used to, and I catch them by reasoning about the numbers rather than by knowing the code. I don’t think the tool is the problem. I think I delegated a layer that was doing more for my understanding than I gave it credit for. Questions for people further along or in the same spot: Roughly what fraction of your research code do you write yourself now? Is there anything you deliberately refuse to hand off? (For me I think the eval harness and anything defining a metric should stay mine, but I keep breaking my own rule.) Does anyone have a workflow that keeps the speedup without the detachment? Reading the diff line by line is not cutting it. Not looking for a “tools are just tools” answer. I’m asking about the specific feeling of not owning your own experiments anymore. submitted by /u/NeatFox5866 [link] [留言]

Is your iPhone acting up? Let's walk through the different kinds of resets, what they do and how to perform them.

For over a decade, we religiously used the well architected framework (WAF) in design reviews. Objective assessment with clear guidance from WAF made our designs risk free (or risk managed) with ambiguities and gaps called out. With agentic AI, there is always a little extra ambiguity. The rhythm of WAF does not strictly match one particular assumption underneath agentic AI: that we can diagram the execution path before the request arrives. All new ambiguities generally stem from this one root. I’ve run design reviews for more than a decade now. Amazon retail first, then AWS, then my own startup, and now healthcare. The rhythm never varied much. Scrutinize the design against the WAF pillars, weigh it against the alternatives, name the gaps and the risks and the open questions, turn the trade-offs into decisions, then move and manage what’s left in the risks. Whether we follow AWS’s six pillars, Google’s, or Microsoft’s four, the content is close enough that the muscle memory transfers. We are answering one question in six different registers: is this system built well enough to trust? And every design I reviewed in those years shared a property so basic that stating it sounds silly. We could enforce the execution path in advance. A single user request might fan out across dozens of services (or a few hundred in retail), queues, and databases, but an engineer could still draw the expected sequence diagram, project TPS for every service, point out the failure modes (and single points of failure), and estimate how much system stress one request would generate. Our early ML workloads (or traditional ML) fit that mold too. Request comes in, features go into a model, inference comes out, and the surrounding application decides what happens next. The model was a component with a latency budget, not a decision-maker. What actually broke, or started to smell Let me be precise about what did not break, because this gets muddled and debated constantly. The wire protocols are f

NoRespawn — Gaming Community Forum Join No Respawn — a community built for gamers to share their best clips, swap strategies, get help, discover new tricks, and talk about the games they love across every genre. norespawn.space

The Networking Architecture Dilemma in Production Flutter If you survey ten seasoned Flutter developers about how they structure networking in production, you will almost certainly see the same multi-tiered pipeline: ┌────────────────────────────────────────────────────────────────────────┐ │ Traditional Flutter Networking Pipeline │ ├────────────────────────────────────────────────────────────────────────┤ │ [Dio / HTTP Client] ─▶ [API Service] ─▶ [Repository Layer] ─▶ │ │ [Cubit / BLoC] ─▶ [UI Builders & Banners] │ └────────────────────────────────────────────────────────────────────────┘ The underlying architectural principles are sound: separation of concerns, testability, and isolating network transport details from UI widgets. However, in practice, this classical layered stack demands an enormous amount of repetitive boilerplate: Async State Union Ceremony : Defining four separate state classes ( Initial , Loading , Success(data) , Failure(error) ) or union types for every single API endpoint. Race Conditions & In-Flight Cancellation : When users type queries or switch tabs rapidly, requests finish out of order. Preventing stale responses requires complex Dio CancelToken plumbing or heavy rxdart switchMap streams. Offline Caching & "Stale-While-Revalidate" : Showing cached data on Frame 1 while fetching fresh updates in the background usually requires database synchronization and stream merging logic. The Repository vs. Controller Divide : Repositories hold data and caching logic, while BLoCs or Cubits hold reactive state. Because Dart only allows single inheritance, developers end up maintaining two separate class hierarchies connected by verbose dependency injection glue. With bloc_signals , we can preserve complete separation of concerns while eliminating 70% of the friction. Let us examine how to architect a modern, clean, production-ready networking layer using CubitSignalMixin , HydratedMixin , and .toAsyncBlocSignal() . ⚡ 1. Symmetrical Async Projection

In the last two blogs, I shared how AI failed to solve a few issues in programming and the value of self-search; today, I am going to share the opposite. The main goal is to show how you can learn from AI and use it as effectively as possible. This all started when I was using trigger.dev and got the following error: Node.js 21 detected without native WebSocket support. Suggested solution: For Node.js < 22, install "ws" package and provide it via the transport option: import ws from "ws" new RealtimeClient(url, { transport: ws }) using trigger.dev The error clearly asks me to either install the ws package or update Node.js. But since I did not have a full experience with trigger.dev I could not figure out how to do that. My approach to debugging is based on methods: Checking resources (AI and Google) Following instincts With this error, I went with AI first, asking ChatGPT about it; then I tried Googling it (which used to work before the AI age), but I could not find any data. With ChatGPT, I gave it two extra points to help it get the right answer; I shared that I am using trigger.dev, added the web resources, and asked for a solution based on my tech stack. By giving ChatGPT context and a web search, it was able to find the config page on trigger.dev and get the results I wanted. With this experience and the ones I had before, the most important thing when using AI was the context and knowledge I had to provide. The in-depth knowledge can help the user and AI to find the optimal solution, yet going blindly might lead you to a black hole without knowing how to return.

Searches for it fell 71% this year. Here’s what people are searching for instead. Every list of dying businesses says the same thing. AI is coming for the boring work. Bookkeepers, translators, copywriters, support reps. Learn to prompt or get replaced. I run a database that pulls business ideas from Reddit complaints and App Store reviews, then checks real search-volume data behind each one. 1,416 scored threads. 192 published ideas. 941 companies with revenue verified straight from Stripe. When I sorted those 192 ideas by year-over-year search growth, the bottom of the list was not what I expected. At a glance Searches for “ai writing tool” fell 71% year over year. “ai agent” fell 46%. “ai detector” fell 19%. Meanwhile “fleet management software” rose 50%, “route planner” rose 50%, and “invoice reminder software for contractors” rose 45%. Of 941 Stripe-verified companies, the 37 in Services average $22,457 MRR. The 129 mobile apps average $4,387. The dying category is not boring work. It is the tool layer built on top of a model anyone can call. Demand did not disappear. It moved to the industries nobody wants to write a Medium post about. Where these numbers come from Search volume and year-over-year growth come from DataForSEO, the same keyword source most SEO tools resell. Revenue comes from TrustMRR, which reads a company’s actual Stripe account rather than asking the founder what they make. That second part matters for this piece. Most “here is what’s growing” articles quote founders. Founders round up. Stripe does not. The categories that are shrinking Keyword: cloud storage Monthly searches: 60,500 Year over year: -99% Keyword: tax preparation software Monthly searches: 6,600 Year over year: -75% Keyword: ai writing tool Monthly searches: 8,100 Year over year: -71% Keyword: church management software Monthly searches: 4,400 Year over year: -57% Keyword: ai agent Monthly searches: 18,100 Year over year: -46% Keyword: 3d printing software Monthly searches: 9,

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

I found this GitHub link, and the HTML file contains ~7k papers. Some are anonymized, and the details seem pretty accurate. It looks like these might actually be the accepted papers. https://github.com/xll0328/NIPS26- Can someone confirm whether this list is legit? I’m hoping it’s just a coincidence since it seems way too early. submitted by /u/Feuilius [link] [留言]

Cloudflare AI Search is a built-in search and retrieval service designed to give AI agents and applications a ready-to-use search engine over custom data. It supports agent integration, multimodal search, and seamless integration with other Cloudflare tools. By Sergio De Simone

Part 4 covered how this platform actually ships — scaffolding, CI/CD, and the two deployment shapes. This closing part is the two things every one of the last four parts has assumed: who actually owns each piece of this, and what it takes to make this whole template yours. Who owns what Every piece of this platform belongs to exactly one team, and that split is what makes independent deploys survive contact with a real organization, not just a single-team demo: Piece Owned by Depends on Host / Shell Platform team Store, Components, the manifest, the identity provider Components MFE Platform / design-systems team Nothing (a leaf) Store MFE Platform team The identity provider Utilities MFE Platform team Nothing (a leaf) Domain MFE (×N) Domain team Components, Store, Utilities only Manifest Registry Platform team Nothing Identity provider(s) Outside the platform — whichever the deployment configures — Backend / BFF Domain team, or a shared gateway (Part 2) Each team's own data The rule underneath the table: domain teams never import from each other, only from the shared platform layer. That keeps the dependency graph a strict two-level tree — Host → platform layer → domain leaves — instead of a mesh, which is what keeps independent deployability tractable once there's more than a handful of domain teams. It's the same rule that made every part of this series possible to write in isolation: Part 3's auth flow doesn't need to know Part 4's deploy pipeline exists, and neither needs to know how many domain teams there eventually are. Making this template your own Everything organization-specific in this platform — branding, which identity provider(s) it trusts, where the manifest lives — has lived in one file across this entire series, on purpose: // platform.config.json { "orgName" : "acme-corp" , "branding" : { "primaryColor" : "#0B5FFF" , "logoUrl" : "..." }, "idp" : { "issuers" : [ { "id" : "primary" , "issuer" : "https://issuer.example.com" , "clientId" : "..." , "def

This series walks through an actual enterprise microfrontend platform, end to end: one Host shell, three shared platform microfrontends, a manifest-driven mechanism for mounting any number of independently-owned domain microfrontends, a full OIDC auth flow, and a CI/CD pipeline. Every code snippet in this series is real and traceable to the actual boilerplate it's built from, on GitHub . Part 1 is the decision everything else in this series depends on: why Module Federation , and not one of the two other credible options. The one requirement that rules everything else out Strip away the buzzwords, and an "enterprise microfrontend platform" only has to guarantee one thing: a team ships a change to their part of the app without anyone else redeploying anything. Not "in theory, with enough coordination" — actually, mechanically, true. If shipping one team's bug fix requires a platform team to cut a release, this isn't microfrontends — it's a monolith with extra steps. That single requirement rules out more than it looks like it should. It rules out compiling every team's code into one shared build (that's just a single-page app with more steps). And it rules out anything where the Host app needs to know, at its own build time, which teams' pages exist and which version of each — because "known when the Host was built" and "deployed independently of the Host" are opposites. The decision Use Webpack 5 Module Federation , in runtime-composition mode, as the platform's way of putting every team's page together into one app: The Host ships with an empty list of remote apps built in. Instead, it looks up every team's page from a small list — a manifest — that it fetches fresh every time the app loads. React, the shared state layer, and the shared design system are all declared as singletons : every team's page gets the exact same running instance of each, not its own separate copy. "Deploying" a team's page means adding or updating one entry in that manifest. The Host itself

The Liux Big microcar is made in Spain. The startup thinks it can compete in a crowded market with its tiny electric car built around sustainability.

Every lottery player knows the saying: "One line is no line, you have to play a few more to boost your chances!" That's why the average player often fills out a complete ticket with 8 lines. Sounds like a solid strategy, right? Wrong. It’s actually the fastest way to systematically burn through your cash. To prove it, we wrote a Python simulation that uses historical payout data and cold, hard combinatorics to see who actually has any money left in their account at the end. What exactly is a Monte Carlo simulation? Named after the famous casino in Monaco, the Monte Carlo simulation is basically the brute-force approach to probability theory. Usually, mathematicians use a single, elegant formula to calculate the expected value. That formula will dryly inform you: "You lose an average of 1 Euro per Eurojackpot line." That might be mathematically correct, but emotionally, it's a bit of a snooze. It doesn't capture the true pain of slowly bleeding out financially. The Monte Carlo simulation throws that elegant formula right out the window. Its core concept is pure, raw computing power. Instead of just calculating the theoretical outcome, we let the computer simply play through reality thousands of times. It’s not an equation; it’s a simulation and iteration of real events. The computer spawns 1,000 fictional players. For every player and every draw over the last 10 years, it generates a random number based on the actual Eurojackpot probabilities. It simulates the real-world winning and (mostly) losing, step by step. At the end, we aren't looking at some abstract theoretical number, but at the very real, blood-red bank accounts of 1,000 ruined clones. The Setup We're using Polars for lightning-fast data processing, NumPy to simulate millions of random draws, and Matplotlib to visualize our financial doom. First, grab our historical Eurojackpot database and drop it into the same folder. The Script Here is the complete Python code. It calculates the exact mathematical odds

Help wanted: validate a React faceted search SPFx sample in SharePoint Online A new read-only React faceted search sample is ready for the PnP SharePoint Framework webparts repository: Pull request: https://github.com/pnp/sp-dev-fx-webparts/pull/6480 Sample: https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples/react-faceted-search The web part uses SharePoint Search REST ( /_api/search/query ) to search the current site. It supports: Search terms FileType and ContentClass refiners Result counts and metadata Safe encoded query/refiner values Loading, empty, access-denied, throttling, error, and retry states Responsive, accessible Fluent UI rendering The implementation is intentionally read-only and does not use a custom backend or Microsoft Graph. Local verification completed: 4/4 Jest tests passed TypeScript and webpack build passed ESLint passed Production .sppkg packaging passed Gallery metadata validator corrected and rerun successfully Tenant validation is still needed. If you have a SharePoint Online tenant, please test search indexing, result links, refiners, permissions, empty/error states, and narrow web-part widths. Real screenshots and negative findings are welcome; no local screenshot is being presented as tenant evidence. Please share feedback on the pull request. Thank you!