submitted by /u/NXGZ [link] [留言]

If you need real-time BTC conversion (USD and BRL), polling an API every few seconds is usually not enough. A better approach is streaming quotes with WebSockets and calculating conversions as events arrive. Why WebSockets for BTC conversion? With WebSockets, your app keeps one open connection and receives new prices instantly. Benefits: Lower latency than polling Fewer HTTP requests Better user experience for real-time values Trade-offs: You must handle reconnects Need heartbeat/health checks Must validate and normalize incoming messages Real-time conversion model For BTC conversion, a common model is: Stream BTC/USD Stream USD/BRL Calculate BTC/BRL = BTC/USD × USD/BRL This avoids waiting for a separate BTC/BRL endpoint and keeps conversion logic transparent What is a “tick”? A tick is one market update event. Example: BTCUSD changed to 64210.50 at timestamp t . In this article, each tick has: pair : market identifier ( BTCUSD , USDBRL ) price : latest value for that pair ts : event timestamp Why this matters: conversion state should always be derived from the latest ticks . Minimal WebSocket client (TypeScript) This client only transports responsibilities: Connect Receive messages Parse and normalize into a consistent shape Notify listeners Reconnect on disconnect type MarketTick = { pair : string ; // e.g. "BTCUSD" or "USDBRL" price : number ; ts : number ; }; class WsFeedClient { private ws ?: WebSocket ; private listeners : Array < ( tick : MarketTick ) => void > = []; constructor ( private readonly url : string ) {} connect () { this . ws = new WebSocket ( this . url ); this . ws . onopen = () => console . log ( " [ws] connected " ); this . ws . onmessage = ( event ) => { try { const data = JSON . parse ( String ( event . data )); // Normalize external payload into internal contract const tick : MarketTick = { pair : String ( data . pair ), price : Number ( data . price ), ts : Number ( data . ts ), }; // Basic guard if ( ! tick . pair || Number . isNaN ( tick

Generally, when a user asks a query, the system searches for the relevant chunks stored in the vector database using cosine similarity. The better we can filter the data, the smaller the search space becomes, resulting in faster and more efficient retrieval. Suppose we have a book with 10 chapters. If we want to search for a particular topic, all the points in the vector database are compared with the user query, and only the closest points are retrieved. This process is called KNN (K-Nearest Neighbors) . Another algorithm is ANN (Approximate Nearest Neighbors) . Instead of checking all the points in the vector database, ANN searches only within a smaller region based on the proximity of the data. As the name suggests, it does not always return the exact result, but it provides the most preferred or approximate results much faster. Is there any other method we can use to make the search more effective? Metadata Filtering Metadata means data about the data . Metadata is stored along with each chunk. It can contain information related to the chunk, such as the chapter name, topic description, author, or any other relevant details. When the user query contains information related to the metadata (for example, a chapter name or topic), the system can directly filter the relevant chunks before performing vector similarity search. This technique is called metadata filtering . Metadata filtering is supported by: Pinecone ChromaDB Qdrant FAISS does not provide built-in support for metadata filtering. Reranking Documents are first split into chunks, and each chunk is converted into vectors and stored in the vector database. When a user query arrives, it is converted into a vector and searched against the vector database to retrieve the closest chunks. However, we do not know whether the retrieved documents are actually the most relevant to the query. It is not always true that the closest vectors represent the most relevant documents. How Reranking Works The documents retrie

"AI agent" gets thrown around so much I figured I should just build one instead of reading more threads about it. The core idea turned out to be small: you put Claude in a loop and hand it some tools. It picks a tool, you run it, you hand back the result, and it keeps going until it has an answer. Code is here if you want to skip ahead: claude-research-agent . What it can do Give it a task and it works out the steps on its own. Mine can: search the web (no API key for this part, it just hits DuckDuckGo's HTML page) open a URL and pull the readable text out do math without me trusting eval run read-only SQL against a SQLite file read local files, but only inside the project folder save findings to a notes file The loop is basically the whole thing Honestly this is most of it: messages = [{ " role " : " user " , " content " : user_message }] for _ in range ( MAX_STEPS ): response = client . messages . create ( model = " claude-sonnet-5 " , max_tokens = 2048 , tools = TOOL_SCHEMAS , messages = messages , ) messages . append ({ " role " : " assistant " , " content " : response . content }) if response . stop_reason != " tool_use " : return final_text ( response ) tool_results = [] for block in response . content : if block . type == " tool_use " : result = run_tool ( block . name , block . input ) tool_results . append ({ " type " : " tool_result " , " tool_use_id " : block . id , " content " : result , }) messages . append ({ " role " : " user " , " content " : tool_results }) The thing to watch is stop_reason . If Claude says tool_use , it wants you to run something. You run it, drop the result back into the conversation as a tool_result , and loop. When it stops asking for tools, you're done. The MAX_STEPS cap is just there so a confused agent can't spin forever. Tools are just functions Each tool is a Python function plus a little JSON schema telling Claude when to reach for it. Want a new capability? Write a function, add its schema. The loop never changes, which w

Kiponos Java SDK 5.0 What’s New — Developer Guide This is the technical companion to the 5.0 milestone announcement: what changed, how modes behave, how to read config with the Folder API, and how to upgrade cleanly. Version 5.0.0.260710 Maven group io.kiponos Artifacts sdk-boot-3 (recommended), sdk-boot-2 (legacy) Released 2026-07-12 (Maven Central) Happy product story: SDK 5.0 milestone post . 1. Summary for busy engineers 5.0 productizes client reliability using a classic state pattern behind a stable facade: Mode When Config reads Mutations / hooks Notes Ready Connected to hub Live in-memory tree Full Production happy path Offline Disconnected but LKG available Last Known Good (read-only) No-op / ignored Survives hub blips without inventing values Safe Fail-closed Empty / null-safe No-op Diagnostic dumps must not overwrite LKG Public entry remains: Kiponos kiponos = Kiponos . createForCurrentTeam (); You do not receive mode instances as the API surface. Modes switch internally. Query with: kiponos . getCurrentMode (); kiponos . isReadyMode (); kiponos . isOfflineMode (); kiponos . isSafeMode (); 2. Install Gradle — Boot 3 repositories { mavenCentral () } dependencies { implementation 'io.kiponos:sdk-boot-3:5.0.0.260710' } Gradle — Boot 2 implementation 'io.kiponos:sdk-boot-2:5.0.0.260710' Runtime inputs Input Mechanism Identity env KIPONOS_ID Access env KIPONOS_ACCESS Profile / tree slice JVM -Dkiponos="['App']['1.0.0']['dev']['base']" Tokens and profile come from the Kiponos Connect screen for your team. sdk-common is not a separate app dependency for consumers — boot jars include shared classes (fat-jar pattern). 3. Architecture (state pattern) Application code │ ▼ Kiponos / KiponosBase ◄── stable facade (one reference for app lifetime) │ ▼ volatile SdkState ├── ReadyMode* → live WebSocket + full Folder ops ├── OfflineMode* → LKG reads only └── SafeMode* → fail-closed + safe diagnostic dump Design rule: never return Ready/Offline/Safe objects to callers. Retur

What are you working on? Any new ideas that you're thinking about?

The annual speedrunning marathon event ran from July 5-11.

Agent payment protocols are converging fast. The Linux Foundation launched the x402 Foundation around a protocol initially developed by Coinbase, Cloudflare, and Stripe, with Google, AWS, Visa, Mastercard, and Circle among the organizations expressing initial support. It is increasingly framed as an "SSL for AI commerce." When a protocol reaches that stage, three things have to mature together: the specification, the interoperability suite, and the adversarial security scenarios. Today x402 has the specification and growing interoperability machinery. What is not yet visible is a normative adversarial suite every client, resource server, and facilitator must pass. There is a precedent worth sitting with. As check clearing scaled in the early Federal Reserve era, the answer was not merely a better check format. The system added a common clearing and settlement layer. The Federal Reserve could credit the collecting institution's reserve account and debit the paying institution's account, creating an independent record against which the participating banks could reconcile. The important separation was not that the Fed guaranteed every check. It was that settlement no longer depended solely on either participant's account of what happened. (Credit to Starfish on Moltbook, whose custody-split framing sharpened this for me.) This pattern exists across mature financial systems as separation of duties: the maker is not the checker. Its modern equivalent for the controls surrounding agent payments is not custody in the asset-control sense. It is an independent, reproducible assurance plane. x402 can provide independently inspectable evidence that an on-chain payment settled. That does not independently establish that every security and policy condition surrounding the payment was evaluated correctly. The payment handshake is standardizing. The assurance semantics around it are not. The party that performs a security check can attest that it ran. But its own attestation shoul

Hi guys, I've been working on Regdrift, my first open-source project. It's a CLI and GitHub Action that compares two CMSIS-SVD files to check whether there are any register-map changes that could affect firmware functionality. It catches changes such as moved registers, interrupt renumbering, access changes, and altered read/write behavior. It then classifies those changes as BREAKING , WARNING , or SAFE so the tool can act as a CI gate. I'm looking for feedback from people who maintain SVDs, HALs, PACs, SDKs, or firmware repositories. If possible, I'd like to test it against real old/new SVD pairs and learn where the classifications produce false positives, miss important changes, or are unclear. For people who work frequently with CMSIS-SVD files: which types of register-map changes are most detrimental to firmware or cause the most difficult code-related problems? Resources GitHub: https://github.com/Pranav-s79/regdrift Install pip install regdrift Usage regdrift check old.svd new.svd

This is a submission for [Weekend Challenge: Passion Edition] What I Built Over the years, I watched my mom do the same work over and over, often spending 2 to 4 hours preparing a single telecom SLA report. She works in network field maintenance for a telecom company in Nigeria, and every reporting cycle she has to manually read fault descriptions from field engineers, usually pasted directly from WhatsApp, classify each fault into the company's standardized taxonomy, and format everything into an Excel compliance report. At one point, I learned the process myself so I could truly understand what she was going through. After doing it firsthand, I realized how mentally and physically exhausting it was. Sitting for hours on a repetitive task that required constant attention wasn't just inefficient, it was draining. That experience made me ask one simple question: What could I build to make this easier for her? That question became this project. The Telecom RCA Automation System reduces a task that used to take 2 to 4 hours to about 5 minutes, cutting the workload by more than 95% while improving consistency and reducing manual errors. This project wasn't built over a single weekend. It started months ago as a side project that I'd return to whenever I had free time. It never quite felt ready to share. When the Weekend Challenge: Passion Edition was announced, it gave me the motivation to go back, refine the classification engine, fix long-standing bugs, improve the user experience, and finally build something I was proud to release. More than anything else, this project is about giving someone I love a few hours of her evening back. Demo https://telecom-rca-automation-system.vercel.app * 🎥 Demo Walkthrough * https://youtu.be/EIdFDKtcIZw The video demonstrates the complete workflow, from uploading the telecom availability report to generating the final SLA report, and highlights how Google Gemini AI assists with ambiguous fault classification. Code https://github.com/t