This is a submission for Weekend Challenge: Passion Edition What I Built I built Origin —...

Earn $100K+ in weekly rewards for hacking AI agents. Discussion | Link

npx codebase-posters inside any git repo opens a local exhibition: 18 pieces painted live from your commit history. everything renders from git log, nothing leaves your machine.

Cargar 112.647 filas en una tabla de hechos debería tardar segundos. A mí me tardaba más de 25 minutos, y acababa cancelando la query. Los datos estaban bien, el SQL estaba bien, las dimensiones se poblaban sin problema. El culpable era otro, y descubrirlo fue la parte más instructiva de todo el proyecto. Todo esto surgió construyendo un Data Warehouse en estrella sobre datos reales de e-commerce: no una tabla bonita para hacer un SELECT * , sino un modelo dimensional completo, reproducible desde cero, capaz de responder preguntas de negocio de verdad. El dataset Trabajé con el Brazilian E-Commerce Public Dataset by Olist : pedidos reales de un marketplace brasileño entre septiembre de 2016 y octubre de 2018. Son 9 CSV relacionados entre sí: 99.441 pedidos y 112.650 líneas de venta 103.886 pagos y 104.719 reseñas 32.951 productos, 3.095 vendedores 1.000.163 registros de geolocalización Y con trampas de datos reales que hay que ver antes de que te muerdan: Un pedido puede tener varios pagos y varias reseñas. Si los unes tal cual a la tabla de hechos, duplicas ventas . Es el error clásico y silencioso: los totales salen inflados y nadie se entera. customer_id no es un cliente. Olist crea uno por cada pedido; la persona real es customer_unique_id . Contar mal aquí te cambia el KPI: hay 99.441 cuentas frente a 96.096 personas. El CSV de productos trae una errata en la cabecera ( product_name_lenght , con "lenght"). Si tu esquema la escribe bien y cargas por interfaz gráfica (que empareja por nombre ), esas columnas se quedan vacías sin que nadie avise. El proceso Monté una arquitectura en capas: CSV → staging → modelo dimensional → vistas → análisis , todo en cuatro scripts ejecutables en orden y idempotentes (el esquema se recrea desde cero, se puede relanzar mil veces). El modelo es un star schema : una tabla de hechos fact_sales al grano de línea de producto dentro de un pedido , y cinco dimensiones (cliente, producto, vendedor, pago y fecha), con claves sustitutas,

Python is an excellent language for automating cloud infrastructure, but the official Kubernetes Python client leaves developers with an important architectural decision: Where should Kubernetes manifests live? Should they be constructed directly with Python objects? Embedded as multiline strings? Or stored as external files and rendered at runtime? Each approach works, but they have very different implications for readability, maintainability, and long-term operational cost. The key is recognizing that deployment logic and platform configuration evolve on different lifecycles. Your deployment code, the part that authenticates to Kubernetes, renders templates, and applies resources, may remain unchanged for months. Your manifests, however, often change weekly as applications evolve, resource limits are tuned, cloud-provider annotations are added, or networking requirements change. When those two concerns are tightly coupled, even a configuration, only change forces you to modify, test, and redeploy the delivery or application code itself. Over time, this increases maintenance costs, slows platform changes, and makes configuration drift and production mistakes more likely. This is a familiar software engineering principle: separate concerns that evolve independently. The same thinking that keeps application configuration separate from executable code also applies to Kubernetes manifests. Treating manifests as first-class configuration artifacts allows them to evolve independently from the Python code that delivers them. In this article we'll compare three ways of deploying Kubernetes resources with the official kubernetes-python-client , ranging from tightly coupled implementations to a design that cleanly separates deployment logic from platform configuration. The Landscape at a Glance The comparison below assumes a common application deployment scenario, where the desired state is largely known ahead of time. Controllers and Operators have fundamentally different r

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