标签：#todayilearned

TIL: Streaming Data in Go with iter and yield While building RagPack , a library that chunks files for embedding, I needed a common way to stream parsed content from multiple file formats. RagPack supports CSV, PDF, DOCX, HTML, XLSX, Markdown, JSON and more. Each format has its own parser, but the ingester that consumes them should not care which one it is talking to. I needed a shared contract. In Java I would have reached for an Iterator<T> or an InputStream , but in Go the answer turned out to be the iter package, introduced in Go 1.23. The Parser interface The iter package introduces two types. Seq[V] yields a single value at a time, and Seq2[K, V] yields a pair: type Seq [ V any ] func ( yield func ( V ) bool ) type Seq2 [ K , V any ] func ( yield func ( K , V ) bool ) Seq2 is the right fit here because each iteration naturally produces two things: a parsed unit and any read error. This matches Go's standard (value, error) convention and lets the caller handle errors inline without wrapping them in a struct. That made iter.Seq2[Unit, error] a natural return type for the Parser interface: type Parser interface { Parse ( ctx context . Context , r io . ReadCloser ) iter . Seq2 [ Unit , error ] } Every sub-parser, CSVParser , PDFParser , DocxParser , HTMLParser and so on, implements this one method. The ingester does not need to know which format it is dealing with. Implementing a parser Here is what a parser implementation looks like: func ( p * Parser ) Parse ( _ context . Context , r io . ReadCloser ) iter . Seq2 [ Unit , error ] { return func ( yield func ( Unit , error ) bool ) { defer r . Close () reader := bufio . NewReader ( r ) for { line , err := reader . ReadString ( '\n' ) if err == io . EOF { break } if err != nil { yield ( Unit {}, err ) return } if ! yield ( Unit { Text : strings . TrimRight ( line , " \n " )}, nil ) { return } } } } The if !yield(...) { return } part is the key. If the caller breaks out of the loop early, yield returns false and we

Remote File Inclusion (RFI) is a web vulnerability where an application accepts a URL from user input, fetches the file at that URL, and executes it. When there is no validation on what URLs are allowed, an attacker can point the application to a malicious script on their own server and get it executed remotely. This pattern shows up in automation tools, plugin systems, and CI/CD pipelines. The idea of loading scripts from a URL seems useful, but without strict controls, it becomes a direct path to remote code execution. Here is a simplified example of vulnerable server-side code: // Vulnerable automation runner - DO NOT USE IN PRODUCTION const express = require ( ' express ' ); const http = require ( ' http ' ); const https = require ( ' https ' ); const app = express (); app . get ( ' /api/automation/run ' , ( req , res ) => { const scriptUrl = req . query . scriptUrl ; const startTime = Date . now (); const parsedUrl = new URL ( scriptUrl ); const client = parsedUrl . protocol === ' https: ' ? https : http ; client . get ( scriptUrl , ( response ) => { let data = '' ; response . on ( ' data ' , ( chunk ) => { data += chunk ; }); response . on ( ' end ' , () => { // VULNERABLE: executes fetched script without sandboxing or validation const output = eval ( data ); const executionTime = Date . now () - startTime ; res . json ({ status : ' success ' , output : output , executionTimeMs : executionTime }); }); }); }); app . listen ( 8080 , () => { console . log ( ' Server running on port 8080 ' ); }); The core problem with the code above: It accepts any URL from user input without validation It fetches and runs that URL's content using eval() There is no sandboxing or restriction on what the script can do The code runs with the same privileges as the application itself Ethical Considerations This is for educational purposes only. You should only test for RFI on systems you own or have explicit permission to test. Unauthorized testing is illegal and can lead to serious

vibe citing: how KPMG used AI to write a report about AI and AI made them look like fools by t474-r0b07 There are companies that charge you to tell you how to use AI responsibly. KPMG is one of them. 250,000 employees. 138 countries. Decades advising governments and corporations on how to avoid costly mistakes. In October 2025 they published a report titled "Total Experience: Redefining Excellence in the Age of Agentic AI" . They wrote it with AI. The AI invented 88% of the sources. Nobody verified anything. They published it anyway. // what is "agentic AI" — because the title matters An agentic AI is not a chatbot. Not the assistant that answers your questions. It's a system that makes decisions and executes actions on its own, without a human approving each step. You give it an objective and it acts, corrects, moves forward. It's the product everyone in the tech sector was selling in 2025. KPMG was selling it too. That's why they needed a report proving their clients were already using it. Spoiler: they weren't. And the report invented it anyway. // the forensic analysis GPTZero — a company specialized in detecting AI-generated content — ran a full audit on the report. First: what is an AI hallucination, because the term is going to come up a lot. When a language model doesn't have the information you ask for, it doesn't say "I don't know." It generates a response that sounds correct. It invents with the same confidence it would use if it actually knew the truth. Perfect format. False content. No warning. That's a hallucination. Now the numbers from the KPMG report: TOTAL CITATIONS: 45 REAL CITATIONS: 5 INVENTED CITATIONS: 40 ACCURACY RATE: 11.1% 40 of 45 citations have invented titles, authors that don't exist, or sources that don't say what KPMG claimed they said. Half of the factual claims in the report are false or misattributed. A firm that charges for intellectual rigor published a document with 11% accuracy. // the organizations that read the report and sai

JSON and GraphQL dominate modern web development, but XML (eXtensible Markup Language) is far from obsolete. Enterprise integrations, legacy systems, healthcare standards, and financial protocols still rely heavily on XML. If you work across diverse stacks, understanding XML is a skill that pays dividends. This guide covers the core syntax, validation techniques, parsing approaches, and best practices - with code you can put to work right away. Why XML Still Matters in 2026 XML has been around since 1996 and continues to thrive in specific domains. It handles deeply nested hierarchical data well, supports robust native schema validation, and manages mixed document-oriented content better than most alternatives. If you're dealing with SOAP APIs, Android layouts, SVG, DOCX/XLSX files, HL7 healthcare records, or FIX financial protocols, you're already in XML territory. The Core Building Blocks of an XML Document At its core, XML is a tree of nodes serialized as text. Every well-formed document starts with a declaration that tells the parser the version and character encoding - UTF-8 is the standard choice. From there, the document is composed of nested elements, attributes, and optionally text content. Elements - The Tree Nodes Elements are the primary structural unit in XML. They wrap your data in opening and closing tags. XML is case-sensitive, so a tag and a tag are treated as two completely different elements. Every opened element must have a corresponding closing tag to keep the document well-formed. Attributes - Metadata on Elements Attributes sit inside an opening tag and carry metadata about the element rather than the primary data itself. A good rule of thumb: use attributes for identifiers, types, or units (like currency), and use child elements for the actual payload data. This separation keeps your parsers predictable and your document structure clean. Self-Closing Elements When an element has no content or child nodes, you can collapse the open and close t

Since mid-March 2026, a significant chunk of Claude users have been hitting this error whenever Claude tries to render an inline diagram, chart, or interactive widget: Failed to set up MCP app for "visualize". Check that claudemcpcontent.com is not blocked by your network or browser. The instinct is to blame your network. I went through the same cycle — switched DNS to Cloudflare 1.1.1.1, tried Google 8.8.8.8, disabled browser extensions, tested across browsers. Nothing worked. Then I ran a direct DNS lookup: nslookup claudemcpcontent.com 1.1.1.1 Output: Server: 1.1.1.1 Address: 1.1.1.1# 53 *** Can't find claudemcpcontent.com: No answer Same result with 8.8.8.8. The domain doesn't resolve — at all, from any resolver. Not a user-side issue. What's Actually Happening Claude's visualize feature depends on an external domain — claudemcpcontent.com — to serve the MCP app that renders inline SVG/HTML widgets. When that domain goes down, the feature breaks silently with a misleading error that makes it look like a local network problem. There's an open GitHub issue tracking this (#34820 on anthropics/claude-code) filed March 16, 2026. It has 50+ affected users, no official fix, and was labeled invalid because it was filed on the wrong repo. Anthropic hasn't responded substantively. The visualize infrastructure had multiple incidents throughout April 2026. The Workaround Instead of asking Claude to generate a diagram or chart (which triggers the broken MCP visualizer), ask it to generate a PNG file using Pillow. Instead of: "Create a bar chart showing X" Say: "Create a bar chart showing X as a PNG file using Pillow" Claude writes Python, executes it via its bash tool, and drops a downloadable PNG in the outputs directory. No MCP dependency. No claudemcpcontent.com . Completely different rendering pipeline. Works for bar charts, line graphs, flowcharts, architecture diagrams — anything you'd normally visualize inline. TIL Claude's inline visualizer depends on an external dom