标签：#m

Over three posts I built three fine-tuned models for the same banking-intent task — full fine-tuning a 270M model , LoRA on 1.5B , QLoRA on 7B . They all landed around the same accuracy. Which raises an honest, slightly uncomfortable question: if a 270M model on my laptop already worked, why reach for a 7B model at all? The answer most "bigger is better" content skips For this task — you wouldn't. A good engineer picks the smallest model that clears the bar , not the biggest one available. The small model is cheaper to serve, runs in milliseconds, and you fully own it. Choosing the 7B here would be over-engineering. Reaching for a bigger model isn't a flex. It's a response to a requirement the small one can't meet. Here are the four cases where small stops being enough: 1. The task is genuinely hard Banking77 is easy — 77 fixed labels, short clean queries. Small models saturate it. But ask for reasoning ("which of these three issues is the primary one?"), open-ended generation (write the reply, don't just classify), or real nuance, and there's a capability floor that more parameters buy. No amount of fine-tuning gives a 270M model abilities it doesn't have. 2. You have little data I had ~10,000 labeled examples — plenty for a small model. With 50, a small model can't learn the task, but a 7B model already "knows" banking concepts from pretraining and only needs a nudge. Bigger models need less task data because they bring more prior knowledge. 3. You need one model for many tasks This is the quiet superpower of LoRA/QLoRA. A single frozen 7B base can host dozens of swappable adapters — intent classifier, reply writer, summarizer, sentiment — all from one ~5GB footprint in memory. The 270M is single-purpose. This is why companies serve hundreds of fine-tunes from one base model. 4. Accuracy compounds at scale 93% means 7 in 100 queries misrouted. At 10M queries/month, that's 700,000 mistakes. If each costs a support escalation, the 2–3 points a bigger model buys can

Why a simple string match beat Apple's NLEmbedding for local RAG how apple's nlembedding drove me crazy and how i built my own hybrid search engine recently, while working on my personal ai agent (pheronagent), i was focused on perfecting its memory and retrieval system. everyone is talking about that famous acronym: rag (retrieval-augmented generation). the system is simple: i feed the agent my documents, it converts them into vectors (embeddings), and when i ask a question, it finds the most similar vectors and answers me. sounds perfect on paper, right? so, like any loyal apple ecosystem developer, instead of downloading massive models from external sources (or burning money on apis), i decided to use nlembedding—the native capability of the operating system that runs directly on-device. after all, apple had embedded this into the os; it was both fast and privacy-focused. but real life, as it turns out, doesn't progress as smoothly as wwdc presentations... where have i worked? - the first explosion it all started with a very innocent question. i had uploaded my cv to the system. while chatting with my agent, i casually asked: "where have i worked?" i expected the agent to fire up the metal cores in the background within seconds, find my cv, and list the companies for me. instead, the agent stared blankly. i opened the logs to see what the hell the search engine was doing behind the scenes. the shocking scenario was exactly this: cosine similarity between the query and my actual cv text: 0.587 the threshold i set for relevance: 0.60 it missed it by a hair! "no worries," i thought. "we can just lower the threshold a bit, make it 0.55, and call it a day." but then i saw the truly terrifying thing just one line below. for the exact same query, guess what score a completely irrelevant, junk record in the system—a list of files containing .ds_store—got? 0.59 - 0.60! wait a minute... my detailed, multi-page resume gets a score of 0.587 just because it doesn't contain th

In Part 2 , LoRA let me fine-tune a 1.5B model by freezing it and training tiny adapters. But the frozen base still sat in memory in 16-bit (~3GB). Now I wanted to go to Qwen2.5-7B — and hit a wall that LoRA alone doesn't solve. The problem A 7B model is ~15GB in 16-bit precision. A free-tier T4 GPU has 16GB. It would barely load, with no room left to actually train. The QLoRA insight QLoRA asks the question that naturally follows from LoRA: the base is frozen and only ever read — so why store it in full precision? So you quantize the frozen base to 4-bit (NF4, a format tuned for how neural-net weights are distributed) and run the LoRA adapters on top in normal precision. The base shrinks dramatically; the trainable part stays small and precise. from transformers import BitsAndBytesConfig bnb_config = BitsAndBytesConfig ( load_in_4bit = True , bnb_4bit_quant_type = " nf4 " , # NormalFloat4 bnb_4bit_use_double_quant = True , # quantize the quant constants too bnb_4bit_compute_dtype = torch . float16 , # dequantize to fp16 for the matmuls ) model = AutoModelForCausalLM . from_pretrained ( MODEL_ID , quantization_config = bnb_config , device_map = " auto " ) Each flag earns its place: load_in_4bit — store frozen weights in 4 bits instead of 16. nf4 — a 4-bit type matched to the bell-curve distribution of neural-net weights (better than plain int4). double_quant — quantize the quantization constants too, for a bit more savings. compute_dtype — dequantize to fp16 for the actual matmuls, so storage is 4-bit but compute stays precise. The moment it clicked One line of output: loaded in 4-bit. footprint: 5.44 GB I downloaded 15.2GB of weights and they sat in memory as 5.44GB. A model that couldn't be loaded for full fine-tuning was now training on a single consumer GPU — with room to spare. (The download is still 15GB; bitsandbytes quantizes on the fly during load.) The QLoRA-standard recipe Two more pieces beyond Part 2's LoRA setup: prepare the quantized model for trainin

Organizing notes by topic sounds logical until you have notes on PostgreSQL in five different folders and cannot find the one that matters for today's problem. The issue is not discipline. The issue is that topic-based organization asks the wrong question. "What is this about?" is useful for libraries. For engineers, the better question is "What am I doing with this?" That is the premise of PARA. PARA is a simple four-bucket system created by Tiago Forte as the organizational backbone of his Building a Second Brain framework. The idea is that all information can be sorted into four categories: Projects, Areas, Resources, and Archives. Each category represents a different level of actionability, and that distinction drives where every note lives. This guide applies PARA to engineering work specifically — codebases, documentation, learning material, and the tension between active project work and long-term reference. The Problem With Topic-Based Organization Most engineers organize knowledge the way they organize code: by domain. databases/ postgresql/ redis/ api/ rest/ graphql/ devops/ kubernetes/ terraform/ That structure makes sense when you are browsing. It breaks down when you need something for a specific task. You remember a useful note about database migration safety, but it could be in databases/postgresql/ , devops/deployments/ , api/versioning/ , or nowhere because you saved it somewhere temporary. Topic folders force you to decide where knowledge belongs before you understand its context. PARA delays that decision — instead of asking what something is about, it asks what you are currently doing with it. The Four Buckets Projects A project is active, time-bound work with a defined outcome. For engineers, projects are things like: Migrate billing service to queue v2 Upgrade PostgreSQL from 14 to 16 Write architecture decision record for auth service redesign Implement rate limiting on public API Publish article about distributed tracing Every project has a c

This is The Stepback, a weekly newsletter breaking down one essential story from the tech world. For more on aviation, air taxis, and Wi-Fi speeds at 30,000 feet, follow Andrew J. Hawkins. The Stepback arrives in our subscribers' inboxes on Sunday at 8AM ET. Opt in for The Stepback here. How it started Last year, […]

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

Wooting’s 60HE v2 isn’t just a terrific Hall Effect keyboard. It’s a fantastic keyboard period.

The Xperia 1 VIII marks an attempt at a step change for Sony's flagship phone line. Not only has it had an aesthetic overhaul, but Sony has also revamped the camera system, dropping the continuous optical zoom telephoto that's defined the last four generations of Xperia phone. It's not all different. Sony staples like a […]

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

Network-attached storage (NAS) provides accessible shared space on your home network. After testing, these are my favorite NAS devices.

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

An eminently binge-able series that honors classic horror tropes while reinventing them in surprising ways

Error Handling — Learning to Love if err != nil In part 3 I covered goroutines and channels, and how Go's concurrency model sidesteps a lot of the ceremony I was used to from the JVM. This time I'm tackling the thing I complained about in part 1 of this series before I'd even really tried it: error handling. I called if err != nil repetitive back then. A few weeks and a lot of real code later, I owe Go a partial apology. No Exceptions, On Purpose Coming from Java, the absence of try / catch is the first thing that feels like a missing feature. It isn't — it's a deliberate design choice. In Go, errors are just values. A function that can fail returns an error as its last return value, and the caller decides what to do with it, right there, inline: func divide ( a , b float64 ) ( float64 , error ) { if b == 0 { return 0 , errors . New ( "division by zero" ) } return a / b , nil } func main () { result , err := divide ( 10 , 0 ) if err != nil { fmt . Println ( "error:" , err ) return } fmt . Println ( "result:" , result ) } That's the pattern you'll write hundreds of times in Go: call a function, check err , handle it or bail out, move on. No hidden control flow jumping up the call stack to whichever catch block happens to match. No checked-exception signatures cluttering method declarations. No RuntimeException quietly skipping past five layers of code that had no idea it could happen. Whatever can fail is sitting right there in the function signature, and you're forced to look at it. Why the Repetition Is the Point My part 1 complaint was that if err != nil everywhere feels manual. It is manual — and that's exactly the trade Go is making. In Java, an exception thrown deep in a call stack can silently propagate through layers of code that never declared they might fail, and you only find out where things actually break by reading a stack trace after the fact. In Go, every single point where something can go wrong is visible in the source, in order, as you read top to

I spent the last several months solo-building Tuneline , a cross-platform media player, from a single Flutter codebase that ships native apps to macOS, Windows, Linux, Android, Google TV, and iOS . No Electron. Here is the stack and a few things that bit me. The stack Flutter 3.38 / Dart 3.10 — one codebase, six targets. media_kit for playback — libmpv on desktop, ExoPlayer on Android. Avoiding per-platform video plugins was the single biggest sanity win. Riverpod for state, Hive for local storage, Dio for HTTP. Node.js + Prisma backend for the cloud-sync layer, so your library, favorites, and settings replicate across devices. GoRouter with a single-route, tab-driven shell so the same layout reflows from a phone to a 10-foot TV UI. Things that bit me TV is its own design language. A 10-foot, focus-based UI is not a big phone. D-pad focus traversal, larger hit targets, and a separate Google TV store listing were all non-trivial. Per-platform video quirks. Desktop (libmpv) and mobile (ExoPlayer) disagree on enough edge cases that a shared abstraction over media_kit earned its keep. Sync is a distributed-systems problem in disguise. "Set up once, never rebuild it" sounds simple until two devices edit the same data offline. Keeping one canonical decoder for both the socket sync-down and the REST pull saved me from a whole class of drift bugs. One codebase is not one design. Window management on desktop, picture-in-picture per platform, and safe-area handling on mobile each needed platform-specific care even with a shared core. The product Tuneline is a bring-your-own-content player, like VLC — you supply your own playlists and it does not host anything. Every viewing feature is free on one device, and the only paid tier is cloud sync plus multi-device. No subscriptions. Site: https://tuneline.app — happy to answer any Flutter or cross-platform questions in the comments.

Gelişmiş Veri İşleme (Python) Sıralama, Filtreleme ve Arama – Profesyonel Veri Manipülasyonu Rehberi Python’da veri işleme, sadece döngülerden ibaret değildir. Modern Python yaklaşımı; fonksiyonel programlama araçları , yüksek seviyeli built-in fonksiyonlar ve lambda ifadeleri ile daha kısa, daha okunabilir ve daha performanslı çözümler üretmeyi hedefler. Bu bölümde dört kritik alanı derinlemesine inceleyeceğiz: sorted() ile gelişmiş sıralama lambda ile karmaşık veri yapıları üzerinde sıralama filter() ve map() ile fonksiyonel veri dönüşümü any() ve all() ile toplu doğrulama (validation) Her bölümde gerçek dünya senaryoları ve hands-on örnekler olacak. 1. sorted() Fonksiyonu — Gelişmiş Sıralama Motoru 1.1 Temel Yapı sorted ( iterable , key = None , reverse = False ) Parametreler: iterable: Liste, tuple, set vb. key: Sıralama kriteri (fonksiyon) reverse: True → büyükten küçüğe 1.2 Basit Sıralama ```python id="s1" sayilar = [5, 1, 9, 3, 7] sonuc = sorted(sayilar) print(sonuc) --- ## 1.3 Ters Sıralama ```python id="s2" sayilar = [5, 1, 9, 3, 7] print(sorted(sayilar, reverse=True)) 1.4 Tuple Sıralama ```python id="s3" veri = (10, 5, 20, 15) print(sorted(veri)) --- ## 1.5 String Sıralama (ASCII mantığı) ```python id="s4" kelimeler = ["python", "ai", "data", "backend"] print(sorted(kelimeler)) 2. key Parametresi — Sıralamanın Beyni sorted() fonksiyonunun gerçek gücü burada başlar. 2.1 String Uzunluğuna Göre Sıralama ```python id="k1" kelimeler = ["python", "ai", "veri", "makineöğrenmesi"] sonuc = sorted(kelimeler, key=len) print(sonuc) --- ## 2.2 Sayıların Moduna Göre Sıralama ```python id="k2" sayilar = [10, 3, 7, 21, 14, 9] sonuc = sorted(sayilar, key=lambda x: x % 5) print(sonuc) 2.3 Tuple Sıralama (Gerçek Dünya) ```python id="k3" urunler = [ ("Laptop", 45000), ("Mouse", 500), ("Monitör", 12000) ] sonuc = sorted(urunler, key=lambda x: x[1]) print(sonuc) --- ## 2.4 Çok Katmanlı Sıralama Fiyat → sonra isim ```python id="k4" urunler = [ ("Laptop", 45000), ("Mouse", 500),

The cryptographic keys that secure your computer's boot sequence will start to expire on June 24. Here's what that means for you.

I bombed a system design interview last year — not because I didn't know the architecture, but because I spent the first 5 minutes fighting Excalidraw. So I built SystemDesignBoard — a free, keyboard-first whiteboard specifically for system design interviews. What it does You open it, press a key, and start drawing. No account, no onboarding, no drag-from-a-sidebar friction. R → place a Service node C → place a Database/Cache/Queue A → connect two nodes N → open the scratchpad for scale math The features I'm most proud of Animated connectors that show communication type Instead of just drawing arrows, connectors visually encode how services talk: ⇄ sync — paired dashes (request + ACK) ≋ stream — near-solid fast line with glow (continuous pipeline) This matters in interviews — your interviewer can glance at your diagram and immediately understand the communication pattern. Cloud provider badges Tag any node as AWS (EC2, Lambda, RDS, S3), GCP (GKE, Cloud Run, Firestore), or Azure. Each subtype has its own icon. Trade-off logging Right-click any node → Log Trade-offs → attach your CAP theorem stance, consistency level, and scaling strategy directly to the component. Diagram-as-Code Type: [Mobile App] -> [API Gateway] [API Gateway] -> [Auth Service] [Auth Service] -> [Users DB] [Feed Service] -> [Posts DB x3] [Feed Service] -> [Redis Cache] Hit Apply — it auto-lays out the whole architecture in seconds. Export to animated GIF Export your diagram as a GIF that shows live traffic flow animations. Great for sharing after an interview or in a design doc. Tech stack React + TypeScript + Vite @xyflow/react (ReactFlow v12) for the canvas Zustand + Immer for state with full undo/redo html-to-image + gifshot for PNG/GIF export It's free and open No signup required. Works entirely in the browser. Free during beta. 👉 systemdesignboard.com Would love feedback — especially from anyone who's done system design interviews recently. What's missing? What's annoying? Drop a comment below

This is a submission for the June Solstice Game Jam Solstice Arcade: Festival of Light – Submission for June Solstice Game Jam 2026 Play Solstice Arcade Now! setuju / Solstice-Arcade-Festival-of-Light Game Solstice Arcade Solstice Arcade: Festival of Light A highly polished, multi-genre retro web game built for the June Solstice Game Jam 2026 . Experience interactive themes combining Solstice, Pride Month, Juneteenth, Alan Turing's cipher heritage, World Cup football soccer, and international Sushi Day. Collect all 14 Starlight Fragments , solve hidden ciphers, and challenge other operands in the global leaderboard! 🎮 Game Modes 1. Spectrum Architect (Solstice + Pride + Turing) Unravel ciphers using an interactive enigma-like rotor device. Experience high-fidelity color spectrum mappings where cryptography meets chromatic light calibration. Goal: Uncover 30 distinct color-clue riddles. 2. Solstice Sumo (Pride + World Cup) A hyper-fast physics canvas battle in a vibrant circle. Push your opponent out of bounds or secure celestial light balls. Goal: Outmaneuver opponents, maintain circular leverage, and trigger high-speed dashes. 3. Echoes of Galveston (Juneteenth + Rhythm) An interactive synchronized Web Audio beat-tapping rhythm game commemorating emancipation. High-density audio… View on GitHub 🎮 Game Description "Solstice Arcade: Festival of Light" is an interactive web experience celebrating humanity's diversity under the light of the longest day. Serving as an anthology of 5 mini-games, users solve puzzles and complete challenges honoring distinct cultural, historical, and mathematical milestones around the solstice, including Juneteenth, international sushi day, the World Cup, and Alan Turing's monumental contributions. ✨ Key Features 5 unique mini-games (Spectrum, Galveston, Sumo, ShadowChef, LongestSecond). Cinematic historical intros preceding each game mode. Hidden tasks & Starlight Fragments designed to reward exploratory interactions. Easter egg "The Shad

In the earlier posts of this series, we looked at practical query tuning tips and how to read and interpret query plans . A recurring theme in both was: "add an index here." But "add an index" is a bit like saying "use the right tool" — the interesting part is which one. PostgreSQL ships with several index types, each tuned for a different kind of data and query. Picking the wrong one means PostgreSQL quietly ignores your index and goes back to a sequential scan. In this post, we'll walk through the main index types, when each shines, and the special index variations (composite, partial, covering, expression) that often matter more than the type itself. Setting the Scene: Schema and Sample Data We'll reuse the same schema from the previous posts, with one small addition — a metadata JSONB column and a tags array on orders , so we can explore the more exotic index types. CREATE TABLE customers ( id SERIAL PRIMARY KEY , customer_name VARCHAR ( 255 ), email VARCHAR ( 255 ), created_at TIMESTAMPTZ DEFAULT NOW () ); CREATE TABLE orders ( id SERIAL PRIMARY KEY , customer_id INT REFERENCES customers ( id ), order_date TIMESTAMPTZ DEFAULT NOW (), total_amount NUMERIC ( 10 , 2 ), status VARCHAR ( 20 ), tags TEXT [], metadata JSONB ); -- Insert sample customers INSERT INTO customers ( customer_name , email ) SELECT 'Customer ' || i , 'customer' || i || '@example.com' FROM generate_series ( 1 , 1000000 ) AS s ( i ); -- Insert sample orders INSERT INTO orders ( customer_id , order_date , total_amount , status , tags , metadata ) SELECT ( RANDOM () * 1000000 ):: INT , NOW () - interval '1 day' * ( RANDOM () * 365 ):: int , ( RANDOM () * 500 + 20 ), ( ARRAY [ 'pending' , 'shipped' , 'delivered' , 'cancelled' ])[ FLOOR ( RANDOM () * 4 + 1 )], ARRAY [( ARRAY [ 'gift' , 'priority' , 'fragile' , 'bulk' ])[ FLOOR ( RANDOM () * 4 + 1 )]], jsonb_build_object ( 'channel' , ( ARRAY [ 'web' , 'mobile' , 'store' ])[ FLOOR ( RANDOM () * 3 + 1 )]) FROM generate_series ( 1 , 1000000 ) AS s ( i

The Playwright Playbook — Part 7: The CI/CD Setup Nobody Shows You "A test suite that only runs on your laptop isn't a test suite. It's a hobby." Six parts in, we have a serious framework. POM-based UI tests. Network interception. Multi-user contexts. A full API testing layer. Visual regression across four viewports. A complete debugging toolkit. Now it needs to run automatically. On every pull request. On every merge. On every deployment. Without you touching it. Most CI/CD tutorials for Playwright show you this: # The "tutorial" version everyone copies - run : npx playwright test That's not a CI setup. That's a shell command in a YAML file. A real production CI/CD pipeline for Playwright has: Sharding — split tests across multiple machines and finish in a fraction of the time Browser matrix — Chromium, Firefox, WebKit in parallel Docker — identical environment on every machine, every time Artifacts — HTML report, traces, screenshots, videos — downloadable from every run Failure notifications — your team knows within seconds, not the next morning Separate VRT workflow — visual regression on its own cadence, not blocking every PR Environment-specific pipelines — staging vs production, different configurations Let's build all of it. 🎯 🏗️ Where We Left Off After Part 6, our full project structure is: playwright-playbook/ ├── tests/ │ ├── auth/login.spec.ts ✅ Part 1 │ ├── tasks/task-management.spec.ts ✅ Part 1 │ ├── network/ ✅ Part 2 │ ├── multi-user/ ✅ Part 3 │ ├── multi-tab/ ✅ Part 3 │ ├── api/ ✅ Part 4 │ ├── visual/ ✅ Part 5 │ └── debug/trace-examples.spec.ts ✅ Part 6 ├── pages/ │ ├── LoginPage.ts ✅ Part 1 │ ├── TaskPage.ts ✅ Part 1 │ └── DashboardPage.ts ✅ Part 3 ├── api/ │ ├── TaskApiClient.ts ✅ Part 4 │ └── AuthApiClient.ts ✅ Part 4 ├── fixtures/ │ ├── auth.fixture.ts ✅ Part 1 │ ├── tasks.json ✅ Part 2 │ ├── empty-tasks.json ✅ Part 2 │ ├── tasks-har.har ✅ Part 2 │ ├── multi-user.fixture.ts ✅ Part 3 │ └── api.fixture.ts ✅ Part 4 ├── scripts/ │ └── record-har.ts ✅