标签：#java

In the previous article , we briefly discussed the relationship between Cookies and CORS . In this article, we'll take a closer look at how browsers decide whether a Cookie should be included in a Cross-Origin request. One of the most common misconceptions is that once CORS is configured correctly, Cookies are automatically sent with every request. In reality, that's not how browsers work. 📌 Default Browser Behavior When a Cross-Origin request is made using fetch() or XMLHttpRequest , browsers do not send Cookies, Authorization headers, or other credentials by default. For example: fetch ( " https://api.example.com/profile " ) Even if the user is already logged into api.example.com , the browser will not include any Cookies with this request. This default behavior helps prevent authentication data from being unintentionally leaked across different Origins. 📌 How Can We Send Cookies? If you want the browser to include Cookies in a Cross-Origin request, you must explicitly use the credentials option. For example: fetch ( " https://api.example.com/profile " , { credentials : " include " }) Using credentials: "include" does not guarantee that Cookies will be sent. Instead, it tells the browser: "If there are any Cookies that are eligible to be sent with this request, include them." 📌 What Makes a Cookie Eligible? Even with credentials: "include" , the browser still evaluates the Cookie before sending it. Some of the most important checks include: Domain Path SameSite For example: If the Cookie's Domain doesn't match the request destination, it won't be sent. If the request path doesn't satisfy the Cookie's Path attribute, it won't be sent. If the Cookie's SameSite policy blocks Cross-Site requests, it won't be sent. In other words, credentials is only the first requirement , not the final decision. 📌 Server Configuration Matters Too If your application expects JavaScript to access the response while using Cookies, the server must also be configured correctly. For exampl

In the previous article , we learned that an Origin consists of three components: Scheme (Protocol) Host Port Browsers use these three components to determine whether a request is Same-Origin or Cross-Origin . Whenever a web page attempts to access resources from a different Origin, a security mechanism called CORS (Cross-Origin Resource Sharing) comes into play. 📌 Why Does a CORS Error Occur? Suppose your web application is running at: https://app.example.com Now it tries to fetch data from: https://api.example.com Although both URLs belong to example.com , their Hosts are different. That means they have different Origins. As a result, the browser treats this as a Cross-Origin request. If the destination server does not explicitly allow this Origin, the browser prevents JavaScript from accessing the response, resulting in what we commonly call a CORS Error . 💡 Important: CORS is a browser security mechanism , not a server security mechanism. ⚠️ A Common Misconception About CORS Many developers believe that a CORS error means the request never reached the server. In most cases, that's simply not true. Typically: ✅ The browser sends the request. ✅ The server receives it. ✅ The server generates and returns a response. ❌ The browser blocks JavaScript from accessing that response. In other words, the request was successful—the browser simply refuses to expose the response to your application because the CORS policy was not satisfied. This is why sending the exact same request using tools like Postman or curl usually works without any problems. Those tools are not browsers, so they do not enforce browser security policies like CORS. 📦 How Does the Server Handle CORS? To allow JavaScript to access the response, the server must include the appropriate CORS headers. The most important one is: Access-Control-Allow-Origin: https://app.example.com This header tells the browser that JavaScript running on https://app.example.com is allowed to read the response. ✅ Examples Suppos

You've written setTimeout(fn, 0) expecting it to run "immediately." It didn't. A Promise.then() you scheduled a line later ran first, and somewhere a for loop of 50,000 iterations froze your UI for a full second despite every function being "async." None of this is a bug. It's the JavaScript event loop doing exactly what it always does — you just haven't seen the mechanism yet. What you'll learn By the end of this guide you'll be able to: Explain, precisely, why microtasks (Promises) always run before macrotasks ( setTimeout , setInterval ) — even at a zero delay Predict the exact console output order of any mix of synchronous code, setTimeout , and await Diagnose a frozen UI as a blocked call stack, not a "slow async function" Choose correctly between queueMicrotask , setTimeout(fn, 0) , and requestAnimationFrame for a given timing need Avoid the two most common event-loop bugs: microtask starvation and accidental serial await s in a loop Who this is for: you've written async / await and used setTimeout , but you want the model that makes their interaction predictable instead of memorized. Contents Why the JavaScript event loop exists The mental model Stage 1: the call stack and blocking code Stage 2: Web APIs and the macrotask queue Stage 3: Promises and the microtask queue Stage 4: async/await is sugar, not magic Stage 5: rendering, and Node's extra queues Edge cases and gotchas Best practices FAQ Cheat sheet Key takeaways Why the JavaScript event loop exists JavaScript runs on a single thread. One call stack, one thing executing at a time, no parallel function calls in the same realm. That's a deliberate design — it means you never need locks or mutexes to protect a shared variable — but it creates an obvious problem: how does a single-threaded language do anything concurrent, like waiting on a network response, without freezing the entire page while it waits? Here's the naive expectation, and why it would be a disaster if JavaScript worked this way: console . l

Imagine you're loading a dashboard. Four widgets, four APIs, fire them all at once: const [ users , revenue , alerts , activity ] = await Promise . all ([ fetchUsers (), fetchRevenue (), fetchAlerts (), fetchActivity (), ]); The alerts API is occasionally slow and sometimes returns a 500. When it does, your entire dashboard fails. Not one broken widget — four broken widgets. Promise.all rejects on the first failure and takes the other three successful results with it into the void. You reached for the right primitive for concurrency, but the wrong one for this use case. The four methods and what they actually do JavaScript gives you four ways to run promises concurrently. They differ in one thing: what happens when a promise fails or resolves first. Method Resolves when Rejects when Promise.all All succeed Any one fails Promise.allSettled All finish (success or failure) Never Promise.any Any one succeeds All fail Promise.race Any one finishes Any one fails first The instinct to reach for Promise.all is understandable — it returns all the values in a single array and feels like the obvious way to "do these things at the same time." But concurrency and failure handling are two separate questions. Promise.all answers both at once, and the answer to the second one is often wrong for the situation you're in. 🎮 Try it yourself ▶️ Open the interactive playground → Runs right in your browser — poke at it and watch the concept react live. Promise.allSettled — partial success Promise.allSettled waits for every promise to settle — resolve or reject — and returns a result array describing what happened to each one: const results = await Promise . allSettled ([ fetchUsers (), fetchRevenue (), fetchAlerts (), fetchActivity (), ]); for ( const result of results ) { if ( result . status === ' fulfilled ' ) { console . log ( ' got data: ' , result . value ); } else { console . error ( ' failed: ' , result . reason ); } } Each element has a status of 'fulfilled' (with a value ) or 'r

Videos are one of the heaviest assets you can add to a web page. Loading videos too early can significantly impact your application's performance. The good news is that modern browsers are starting to support lazy loading for video elements , allowing you to defer loading until users are likely to watch them. However, there's one important thing to know: 👉 This feature is not yet part of the Baseline web platform , so browser support is still limited. At the time of writing, lazy loading for <video> elements is supported in Chromium-based browsers such as Google Chrome , Microsoft Edge , and Opera , while browsers like Firefox and Safari do not yet support it natively. In this article, we'll explore: What lazy loading videos is Why it's important for web performance How to implement it Browser support considerations Best practices for optimizing video loading Let's dive in. 🤔 What Is Lazy Loading for Videos? Lazy loading means delaying the loading of a resource until it's actually needed. Instead of downloading every video immediately during page load, the browser waits until the video is close to entering the viewport. This helps reduce: initial network requests bandwidth usage page load time memory consumption Especially on pages with multiple videos, the difference can be significant. 🟢 What Problem Does It Solve? Imagine an e-commerce page with several product videos. Without lazy loading: every video starts downloading immediately bandwidth is consumed even for videos users never watch page rendering may become slower This negatively impacts; Largest Contentful Paint (LCP), Time to Interactive (TTI), and overall user experience. Most visitors won't watch every video on the page. So why load them all? Lazy loading ensures videos are fetched only when they're actually needed. 🟢 How to Lazy Load a Video The easiest approach is using the loading="lazy" attribute. Example: <video controls loading= "lazy" poster= "/preview.jpg" > <source src= "/video.mp4" type= "vide

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

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

Most WooCommerce product pages still show the same thing stores have shown for 20 years: a handful of flat photos. I spent the last few months building Noorifa, a plugin that replaces that with an interactive Three.js viewer — customers rotate the model, zoom in, and switch colors/materials on specific meshes in real time, synced to the store's actual WooCommerce variations. The 3D rendering part was the easy 20%. The other 80% was a series of small, specific problems that don't show up in a Three.js tutorial. Here are four of them. 1. A directional light rig can't light a face it can't see Early on, customers rotating a table model would find the underside of the tabletop rendering near-black — no matter how far I pushed the light intensity. The rig at the time was a single key light plus a hemisphere ambient: scene . add ( new THREE . HemisphereLight ( 0xffffff , 0x444444 , 1.2 ) ); const keyLight = new THREE . DirectionalLight ( 0xffffff , 1.2 ); keyLight . position . set ( 3 , 5 , 4 ); scene . add ( keyLight ); The bug was geometric, not a brightness problem: keyLight sits above the model, so its light direction only reaches surfaces whose normal faces back toward it. A downward-facing surface — the underside of an overhanging tabletop — can't receive any direct contribution from a light positioned above it, at any intensity. Cranking the brightness slider was scaling a number that was multiplying against zero. The fix was closer to actual three-point studio lighting: key, fill, and rim from above for shape and separation, plus a dedicated light from below, and a brighter hemisphere ground color to approximate bounced light: scene.add( new THREE.HemisphereLight( 0xffffff, 0x888888, 1.1 * brightness ) ); const keyLight = new THREE.DirectionalLight( 0xffffff, 1.1 * brightness ); keyLight.position.set( 3, 5, 4 ); const fillLight = new THREE.DirectionalLight( 0xffffff, 0.5 * brightness ); fillLight.position.set( -4, 2, 3 ); const rimLight = new THREE.DirectionalLigh

What’s up everyone! Back again for my daily drop. We talk a lot about deployment frequency and lead time for changes, but if you're a solo dev or part of a small team building something like LaunchAlly , there’s one metric that rules them all: Time to Recovery (TTR) from a bad push. When you're marketing, coding, and handling support all at once, a broken main branch is a massive bottleneck. Here is my quick tip for today: Invest 20 minutes into setting up strict automated rollbacks . If a deployment fails health checks, let the system revert it instantly without your intervention. Spend lots of hours working today...happy to go to bed now:) What’s your go-to strategy for handling failed deployments on the fly?

Disallow: GPTBot is a wall. Walls don't pay rent, and the crawlers that matter most either ignore them or route around them. If your content is worth training on, the interesting question isn't "how do I keep the bots out" — it's "what do they owe me, and how do I say so in a way a machine can read." That's what RSL (Really Simple Licensing) is for. It shipped 1.0 in December 2025 with around 1,500 publishers behind it — Reddit, Yahoo, Quora, O'Reilly, Medium, Vox. This post is a from-scratch walkthrough of what the format actually is, the six places you can put it, the one mistake that makes crawlers silently ignore your terms, and where the declaration stops and enforcement begins. No tooling required to follow along — it's all plain XML and HTTP. The format is an XML vocabulary, not a config file An RSL document says: for this content, here's what's permitted, what's prohibited, and what it costs. Minimal example: <?xml version="1.0" encoding="UTF-8"?> <rsl xmlns= "https://rslstandard.org/rsl" max-age= "7" > <content url= "/" > <license> <permits type= "usage" > search </permits> <prohibits type= "usage" > ai-train </prohibits> <payment type= "crawl" > <amount currency= "USD" > 0.015 </amount> </payment> </license> </content> </rsl> Read it out loud: search engines may index this; training on it is prohibited; if you want to crawl it anyway, the rate is $0.015. usage tokens include search , ai-train , ai-use (inference/grounding), and a few more. You can scope rules by user and geo too. One rule that trips people up: prohibition wins . If the same token shows up under both permits and prohibits , the content is prohibited. Don't try to express "allowed except for X" by listing X in both — just prohibit X. The namespace is the thing crawlers actually key on The single most common way to publish RSL that quietly does nothing: getting the namespace wrong. It must be exactly: xmlns="https://rslstandard.org/rsl" http instead of https , a trailing slash, or a plausible

GitHub热门项目 | Pure Javascript OCR for more than 100 Languages 📖🎉🖥 | Stars: 38,359 | 167 stars today | 语言: JavaScript

For 4 years, I lived in the world of IT Operations. My days were spent handling incident response, managing data lifecycles, and making sure systems stayed online. I learned how to troubleshoot under pressure, talk to frustrated users, and keep the business running. But I had a lingering frustration: I was always fixing other people's code. I never got to build it. And more importantly, I was fixing problems manually that I knew could be automated. So, I decided to make a massive pivot. I went back to university (VILNIUS TECH) and recently started a Java Engineering internship at Coherent Solutions. My goal isn't just to become a Java developer. My goal is to bridge the gap between Development and Operations- DevOps . In my first few weeks at Coherent, we started learning about enterprise architecture. But the moment that truly clicked for me was when I built my first Docker image for our project. In my past IT life, deploying an app was a nightmare. "It works on my machine!" was a constant joke (and a constant headache for the Ops team). Setting up environments, installing the right Java version, configuring databases—it was manual, error-prone, and boring. Then I wrote a Dockerfile . I packaged our Java application and its dependencies into a single, isolated container. Suddenly, I realized: This is how you solve the "works on my machine" problem forever. As someone who used to be the guy manually fixing those environment issues, writing a few lines of code to completely automate that process felt like a superpower. I'm starting this blog to document my journey in real-time. I'm currently diving deep into: 🔹 Java 21 (the newest LTS—highly recommend checking out Virtual Threads!) 🔹 Spring Boot & enterprise backend architecture 🔹 Docker & containerization 🔹 Next up: CI/CD pipelines and Infrastructure as Code (Terraform) If you are currently stuck in IT Support or SysAdmin roles and dreaming of becoming a DevOps or Software Engineer—you aren't alone. Let's learn toge

Playing the game of writing technical post was funny two years ago. Now, I am a mod and it is...

Many developers still rely on heavy, third-party JavaScript frameworks or external UI libraries just to create simple popups and modal windows. This introduces bloated bundle sizes, slows down page speed, and often ruins accessibility (a11y) for keyboard users and screen readers. Fortunately, you can build an accessible, highly interactive modal window completely natively using the modern HTML5 <dialog> element. The Code Setup Here is how simple it is to build a native modal with semantic HTML, minimal JavaScript, and a touch of modern CSS styling. 1. The Markup (index.html) <main> <h1> Native HTML5 Dialog Element </h1> <p> Click the button below to open a completely native, accessible popup modal. </p> <button id= "openModalBtn" > Open Modal Window </button> </main> <dialog id= "myModal" > <h2> Native Modal Title </h2> <p> This modal is rendered natively by the browser. Focus is trapped automatically! </p> <button id= "closeModalBtn" > Close Modal </button> </dialog> ### 2. The Logic (script.js) Instead of manually managing visibility states or toggle classes, the browser gives us built-in `.showModal()` and `.close()` methods: javascript const modal = document.getElementById('myModal'); const openBtn = document.getElementById('openModalBtn'); const closeBtn = document.getElementById('closeModalBtn'); openBtn.addEventListener('click', () => { modal.showModal(); }); closeBtn.addEventListener('click', () => { modal.close(); }); dialog ::backdrop { background-color : rgba ( 0 , 0 , 0 , 0.6 ); backdrop-filter : blur ( 4px ); } dialog { border : none ; border-radius : 8px ; padding : 2rem ; box-shadow : 0 4px 12px rgba ( 0 , 0 , 0 , 0.15 ); } Interactive Demos & Source Code Working Live Code Demo: ( https://codepen.io/editor/CoderDecoding/pen/019f5548-f0cb-75f8-b915-b9fdb33e92d1 ) Public Code Repository: ( https://github.com/CoderDecoding/native-dialog-demo )

Equality operators are among the most frequently used operators in Java. They allow us to compare two values and determine whether they are equal or not. Unlike relational operators ( < , > , <= , >= ), equality operators work with all primitive data types , including boolean , and they can also compare object references . However, many beginners get confused about how == behaves with objects, strings, and null . These concepts are also some of the most frequently asked Java interview questions. Let's understand them with simple explanations and practical examples. What Are Equality Operators? Java provides two equality operators. Operator Description == Equal to != Not equal to Both operators always return a boolean value. Example System . out . println ( 10 == 10 ); System . out . println ( 20 != 10 ); System . out . println ( 5 == 8 ); Output true true false Rule 1: Equality Operators Work with All Primitive Types Unlike relational operators, equality operators can be applied to every primitive type , including boolean . Supported primitive types include: byte short int long float double char boolean Numeric Examples System . out . println ( 10 == 20 ); Output false System . out . println ( 'a' == 'b' ); Output false System . out . println ( 'a' == 97 ); Output true Explanation 'a' = 97 (Unicode) 97 == 97 ↓ true System . out . println ( 'a' == 97.0 ); Output true Even though one operand is a char and the other is a double , Java performs numeric promotion before comparison. Boolean Example System . out . println ( true == false ); Output false System . out . println ( false == false ); Output true Unlike relational operators, equality operators fully support boolean values. Equality Operators vs Relational Operators Many beginners confuse these operators. Expression Result true == false ✅ Valid true != false ✅ Valid true > false ❌ Compile-time error true < false ❌ Compile-time error Remember: Equality operators work with boolean . Relational operators do not. Rul

I built a chat widget for my portfolio. One script tag, drop it on a page, and recruiters can ask questions about my projects, my AWS internship, what I actually know, and what kind of roles I'm looking for. I named the assistant Scout. <script src= "https://bradleymatera.github.io/ProjectHub/ProjectHub.js" ></script> That's the whole pitch from the outside. What it took to get there is a lot messier than one script tag suggests. The current version has a vanilla JS frontend, a Node backend on a Google Cloud e2-micro VM, a knowledge base pulled from GitHub, a network of free LLM providers, a response cache, per-tab memory, safety checks, a self-improvement loop, and an analytics dashboard. It also has six test suites and more documentation than I expected. The one rule I kept coming back to: it had to stay useful without me paying for AI traffic. Why I built this in the first place My portfolio is scattered. Projects live on GitHub, demos live on various subdomains, blog posts are on the site, certifications are listed somewhere, and my actual AWS internship experience is explained in a few different places. A motivated recruiter could piece it all together, but most recruiters are not motivated. They are busy. I realized I was asking them to do homework. That seemed backwards. So I thought, what if they could just ask? Scout is supposed to answer straight questions like "What is Bradley's strongest project?" or "Does he actually have production AWS experience?" or "What does he want to be paid?" It doesn't pretend to be me, doesn't inflate my title, and doesn't try to sell me as a senior engineer when I'm not one. It just answers from verified stuff. The architecture Three layers. Site loads one script. The script hits the backend. The backend either answers from the knowledge base or falls through to free LLM providers. flowchart TD A[Website or portfolio] -->|loads one script| B[ProjectHub widget on GitHub Pages] B -->|POST /api/chat| C[Node.js API on a GCP e2-mi

Introduction I'm the author of TrulyFreeOCR, an open-source OCR pipeline that turns scanned PDFs into searchable, highly-compressed PDFs. Everything is Apache 2.0 / MIT / BSD — no GPL, no AGPL, no proprietary model weights. Why I built it: I needed an OCR pipeline for a document processing system where: Every dependency had to be business-friendly (no GPL/AGPL) Deployment required zero admin rights (no sudo, no brew, no apt-get) MRC compression was needed to hit 5-10x file size reduction vs JPEG-only Everything had to run offline on CPU — no cloud APIs, no GPU I surveyed 20+ existing tools (full comparison in the repo's docs) and none fit all requirements. OCRmyPDF is closest but needs Python + Ghostscript + Tesseract as system deps, and MPL-2.0 requires publishing modifications. The VLM models (DeepSeek-OCR, GLM-OCR, etc.) produce better text extraction but need GPUs and don't output PDFs at all. What it does: Input: any PDF (scanned, born-digital, or mixed) Output: searchable PDF with invisible text layer + MRC compression (JBIG2/CCITT foreground + JPEG background) Single fat JAR — one file to copy, one command to run Bootstrap script downloads everything (JDK, Gradle, Tesseract, Leptonica, jbig2enc) into project subdirs Fully offline, CPU-only PDF/A-2b output available 7 bundled language models, 100+ more downloadable Concurrent OCR (configurable thread pool) Try it in 3 commands: $ git clone https://github.com/msmarkgu/TrulyFreeOCR.git $ cd TrulyFreeOCR $ ./bootstrap.sh ./run.sh tests/simple-text.pdf -o output.pdf Limitations (being upfront): Tesseract-based accuracy — good for clean scans, not SOTA for noisy/photographed docs No table/formula extraction yet No handwriting recognition CPU-only is slower than GPU backends for high volume Would love feedback — especially from anyone who's tried to deploy OCR in an enterprise environment. https://github.com/msmarkgu/TrulyFreeOCR

I've been building apps with IndexedDB for years. The local part works fine — store data, query it, show it on screen. The hard part is keeping that data in sync with a server when the network comes and goes. Most tutorials show you how to build an offline app with a framework. Firebase, RxDB, WatermelonDB. Those work, but they bring their own abstractions, their own sync protocols, their own opinions. I wanted something simpler. A database with a sync API that doesn't dictate how my backend works. Here's the setup I landed on. npm: npm install ctrodb Docs: ctrodb.vercel.app/docs/sync/overview What We're Building A notes app that works offline. Create and edit notes on the train, in a tunnel, on a plane. When the network comes back, everything syncs automatically. The database is ctrodb (zero-dependency, browser-based). The backend is anything that speaks HTTP. Step 1: Database Setup import { Database , syncPlugin , HttpTransport } from " ctrodb " const db = new Database ({ name : " notes-app " , schema : { version : 1 , collections : { notes : { fields : { title : { type : " string " , required : true }, body : { type : " string " }, updatedAt : { type : " string " , default : () => new Date (). toISOString () }, }, indexes : [{ field : " updatedAt " }], }, }, }, }) await db . connect () Every collection you want to sync needs a timestamp field. The sync engine uses it to order changes and detect conflicts. Plugins are passed in the Database constructor via plugins array: const transport = new HttpTransport ({ url : " https://api.myapp.com/sync " , }) const db = new Database ({ name : " notes-app " , schema : { ... }, plugins : [ syncPlugin ({ transport })], }) await db . connect () The transport takes a single base URL and appends /push and /pull automatically. The sync plugin hooks into every write operation and records it in the change log. The plugin exposes devtools that take the database instance as their first argument: import { inspectSyncQueue , retryFaile

GitHub热门项目 | HTML is the new markdown. Lavish is the new editor for your HTML artifacts. | Stars: 1,811 | 265 stars this week | 语言: JavaScript

Ever wondered what would happen if the world's leading Large Language Models settled their benchmark disputes in a 2D cybercity arena? It's easy to look at model performance on standardized benchmarks (like MMLU, MATH, or HumanEval). It is much more fun to visualize their underlying architectures, parameter scales, and hardware constraints as a retro-cyber fighting game. So, we built Model Kombat (Mixture of Experts Edition)! 🕹️ Play Directly Here 🎮 Launch Game in Full Screen 🧬 Playable ML Concepts Explained This isn't just a basic stick-figure fighting game. Every mechanic—from rendering complexity to the speed at which characters recover—is a direct, playable representation of real-world Large Language Model engineering. 1. 📐 Parameter Scaling vs. Render Tiers A model's representation capacity (intelligence) scales with its parameter count. In Model Kombat, a fighter's visual complexity, joint detail, and rendering fidelity directly reflect its real-world parameter size: Tier 1 (< 5B Parameters - Gemma 2B, Llama 3.2 3B) - Primitive Capsules : Drawn as simple, single-color flat limbs with low joint segmentation. This visualizes the limited representation capacity and coarse output resolution of small edge models. Tier 2 (7B - 14B Parameters - Mistral 7B, Claude Haiku) - Simple Vectors : Structured as thin skeletal wireframe vectors. Tier 3 (14B - 35B Parameters - Gemini Flash, Mixtral) - Two-Tone Vectors : Rendered as dual-color, layered vector limbs. Tier 4 (35B - 100B Parameters - Llama 8B, Claude Sonnet) - Cyborg Shading : Rendered as detailed vector cylinders with dynamic code particle streams flowing along their limbs. Tier 5 (> 100B Parameters - o3, GPT-4o, Claude Opus) - Quantum Vectors : Rendered as glowing vector limbs with digital matrix code particles, soft drop-shadow depth buffers, and real-time afterimage motion trails. 2. ⚡ Reasoning Tokens & KV-Cache Overcharging Instead of arbitrary "mana" or "stamina," fighters charge a Ki bar representing interna