标签：#programming

A story about knowledge extraction, Kafka consumer rebalance, and what happens when a company...

The way developers write software has genuinely changed. Not incrementally — fundamentally. A year...

I built a flashcard app for interview prep and wanted to share some of the more interesting technical problems I ran into. The app has 1500+ questions across DSA and System Design, and the core challenge was: how do you order cards intelligently without it feeling robotic? Problem 1: Slot Assignment for Spaced Repetition Standard SR (like Anki) just shows the most overdue card next. That works for vocabulary but feels terrible for algorithms because you get 3 Hard questions in a row and want to quit. My approach: generate a target difficulty pattern (Easy, Medium, Easy, Medium, Hard, repeat) based on a 40/40/20 distribution, then assign due cards to matching-difficulty slots. Most-overdue cards get placed first within their tier. Unseen cards fill remaining slots. This means a Hard card that's overdue still lands in a Hard slot, not position 1. You get difficulty variety while still seeing overdue cards at the right time. fun assignSlots(pool: List<Question>, dueCards: List<ProgressEntity>): List<Question> { val pattern = generatePattern(size = pool.size, distribution = "40/40/20") val dueByDifficulty = dueCards.groupBy { it.difficulty } val result = Array<Question?>(pattern.size) { null } // Place due cards in matching slots, most overdue first for ((difficulty, cards) in dueByDifficulty) { val sorted = cards.sortedBy { it.nextReviewDate } val availableSlots = pattern.indices.filter { pattern[it] == difficulty && result[it] == null } sorted.zip(availableSlots).forEach { (card, slot) -> result[slot] = findQuestion(card, pool) } } // Fill remaining with unseen // ... } Problem 2: Re-ranking after every swipe without jank After each swipe, the deck needs to re-rank. But the top visible card (position 0) is already animating into view, so you can't move it. Solution: lock position 0, re-rank positions 1+, then check for constraint violations across the boundary (e.g., if locked card is Hard and new position 1 is also Hard, swap position 1 with the first non-Hard card d

I had 4 Chrome windows with ~80 tabs each, mostly duplicates of the same Stack Overflow page. Tried OneTab (saves to a list - not what I wanted) and Workona (cloud sync, overkill). So I wrote ~50 lines of vanilla JS. Click the toolbar icon → every duplicate tab across every window is removed (matched by URL) → survivors merge into one window → remaining tabs auto-group by hostname (collapsed). Two permissions: tabs, tabGroups. No background activity, no server, no analytics. Whole source is in the README so you can audit it before installing. Chrome Web Store: https://chromewebstore.google.com/detail/tab-vacuum/apdjhdjcejehjiomcolfgfgjhaedoieb GitHub: https://github.com/mayhsundar/tab-vacuum Please give your comments submitted by /u/mayhsundar [link] [留言]

Let me start with a confession: I have been writing concurrent code since the only tool in the box was a mutex and a prayer. After a decade of Swift I feel suspicion of any code that touches two threads and claims to be fine. So when Swift 6 showed up promising to prove my concurrency correct at compile time, I had two reactions at once. The grizzled half of me said "sure, kid." The other half — the half that has spent actual weekends chasing a heisenbug that only reproduced on a customer's M1 under sync load — said "...please. Please be real." This is the story of moving Ditto Edge Studio — a SwiftUI debug-and-query tool for the Ditto edge database — to Swift 6's strict concurrency mode. It's a real app: SQLCipher persistence, an embedded MCP server, a SpriteKit presence graph, live sync over Bluetooth and WebSocket. Not a to-do list. The kind of app where concurrency bugs hide in the cracks and wait for a demo. Spoiler: it was worth it. It was also more work than the WWDC talk implied, and the most valuable thing the compiler did happened in the one place I told it to stop looking. Let me show you. First, the Wall: A Dependency That Wasn't Coming to Swift 6 Here's the thing nobody warns you about. Swift 6 language mode isn't really a per-file setting. Your code can be immaculate — every actor isolated, every Sendable accounted for — and you'll still be stuck, because one dependency that isn't Swift 6-ready can hold your entire module hostage. Mine was a code editor. I'd been using a popular SwiftUI editor package for the DQL query editor, and it transitively pulled in a syntax-highlighting library. Both were lovely. Both were also written for a more innocent time, and neither was going to compile under Swift 6 strict concurrency without upstream changes that weren't happening on my timeline. I had the usual three options, and I want to be honest about how tempting the cowardly ones were: Pin the dependency and leave the whole app at Swift 5. Free today, expensive

Last week I did something dumb: I sat down and wrote 50 Claude Code prompts in one sitting. Halfway through I was sure most of them would never get used. But I finished, pushed them to GitHub, and made myself use them for an entire week -- no ad-hoc prompting allowed. The result surprised me. Some skills were life-changing. Others were useless. Here is the honest breakdown. The Methodology I categorized the 50 skills into 5 types: Analysis (12), Generation (14), Debugging (8), Planning (10), Maintenance (6). Rule: every time I hit a task, I must use a skill file or admit I did not have one. The 7 That Actually Saved Me Hours 1. Code Review Assistant (saved ~3h) This was the biggest surprise. I usually review PRs by gut feel -- scan the diff, look for obvious bugs, approve. The Code Review skill forced me to be systematic: On a 400-line PR it caught 2 security issues I would have missed. That alone justified the experiment. 2. Bug Investigator (saved ~2h) Instead of pasting errors and asking "why?", this skill forces you to provide: error message, file context, hypothesis. 3. Dependency Audit (saved ~1h) Scanned a 3-year old Node project. Found 2 CVEs, 8 unused devDependencies (21 MB). 4. Auto Commit Messages (saved ~30m) Saves 2 minutes per commit. Over 15 commits in a week that is 30 minutes. 5. Test Generator (saved ~2h) Generates 5-8 test cases per function in seconds. 6. Refactoring Planner (saved ~1h) Reads the function, identifies extraction candidates, outputs a dependency-ordered plan. 7. Performance Audit (saved ~30m) Found an unoptimized 3 MB hero image and a render-blocking script. The Ones I Never Touched About 8 out of 50 were "not this week" -- Database Migrations, API Documentation, CI/CD Pipeline. What I Learned The ROI is in the analysis skills. Code review, bug investigation, dependency audit -- these are high-judgment tasks where Claude thoroughness beats speed. Skills are habit, not technology. The hardest part was not writing the prompts -- it w

A lot of supply-chain attacks have taken place in the last year. Altough I don't think NeoVim itself has been mentioned so far, I was concerned about my setup, especially the one on my office laptop. I think this is a good opportunity to learn how to write plugins ourselves, but I also know that writing everything on my own is not ideal. At this rate, might as well write my own kernel and operating system because sudo pacman -Syu also carries supply-chain risks. What are the ways which you are dealing with this? submitted by /u/Full-Ad4541 [link] [留言]

🌐 Read this post in Bahasa Indonesia here . 📝 A note on this article This post is based on my personal study notes on version control and Git collaboration. To make these notes more readable and useful — for myself and for others — I worked with AI to help expand and structure them into a proper blog format. The ideas, learning journey, and understanding are mine; the AI helped with the writing and presentation. Learning Git doesn't have to be intimidating. In this article, I'll break down the essential concepts of version control and collaboration — using simple analogies that anyone can understand. What Is Git? Git is a version control system . Think of it as a save system for your code — like save points in a video game. Every time you save (commit), Git remembers the state of your project at that moment. If something goes wrong, you can always go back. Repository: Your Project's Warehouse A repository (or "repo") is the folder that Git watches. There are two types: Local repository : lives on your computer. Your personal workspace. Remote repository : lives on a server (GitHub, GitLab, Bitbucket). The "official" shared copy your team can access. They stay connected through a Remote URL, so you can push your local changes up and pull others' changes down. git init # Start tracking a folder git remote add origin <url> # Connect to a remote repo git push origin main # Send commits to remote git pull origin main # Get latest from remote Commit: Your Project's Save Point A commit is a snapshot of your project at a specific moment. Each commit has: A message describing what changed A unique ID (hash) A timestamp git add . # Stage all changes git commit -m "Add homepage layout" # Save a snapshot git log --oneline # View commit history Write meaningful commit messages. Future you will thank present you. Checkout, Reset, Revert: Traveling Through Time These three commands all interact with your commit history — but in very different ways: git checkout — Visit the Past (T

🌐 Baca artikel ini dalam Bahasa Inggris di sini . 📝 Catatan tentang artikel ini Artikel ini dibuat berdasarkan catatan belajar pribadi saya tentang version control dan Git kolaborasi. Untuk membuat catatan tersebut lebih mudah dibaca dan bermanfaat — bagi saya dan orang lain — saya menggunakan bantuan AI untuk mengembangkan dan menyusunnya menjadi artikel blog. Ide, perjalanan belajar, dan pemahamannya adalah milik saya; AI membantu di bagian penulisan dan penyajiannya. Belajar Git itu tidak harus membingungkan. Di artikel ini, saya akan menjelaskan konsep-konsep penting dalam version control dan kolaborasi menggunakan bahasa yang sederhana — bahkan dengan analogi yang bisa dipahami anak kecil sekalipun. Apa Itu Git? Git adalah version control system — sistem yang merekam setiap perubahan yang kamu lakukan pada file-file proyekmu. Bayangkan Git seperti fitur save point di video game. Setiap kali kamu menyimpan (commit), Git mengambil "foto" dari kondisi proyekmu saat itu. Kalau ada yang salah, kamu bisa kembali ke foto sebelumnya. Repository: Gudang Proyekmu Repository (atau "repo") adalah folder yang diawasi oleh Git. Ada dua jenisnya: Local repository : ada di komputermu sendiri. Ruang kerja pribadimu. Remote repository : ada di server (GitHub, GitLab, Bitbucket). Salinan "resmi" yang bisa diakses seluruh tim. Keduanya terhubung lewat Remote URL, sehingga kamu bisa mengirim perubahan ke remote ( push ) atau mengambil perubahan terbaru dari sana ( pull ). git init # Mulai memantau sebuah folder git remote add origin <url> # Hubungkan ke remote repo git push origin main # Kirim commit ke remote git pull origin main # Ambil update terbaru dari remote Analogi: Local repo adalah buku sketsamu di rumah. Remote repo adalah papan pengumuman kelas — semua orang bisa melihat dan mengaksesnya. Commit: Save Point Proyekmu Commit adalah snapshot dari kondisi proyekmu pada satu titik waktu. Setiap commit berisi: Pesan yang menjelaskan apa yang berubah ID unik (hash) Timestamp g

I haven't written articles in quite a while and I recently decided to come back to it. At work I use AI daily, so a big part of my coding tasks are delegated to agents. I try not to do the same when it comes to writing text but I don't have a clear reason for that (or maybe I do and I don't want to admit it). I am sure people can take advantage of generating text with the help of AI but at the moment I feel like prompting would not save me any time and writing the text myself would be faster. What about you? Are you using AI to write your articles? Image credit - jessica olivella, on pexels

Using it daily for work. submitted by /u/Medium_Potato3703 [link] [留言]

There is a class of projects that teaches you more about a language than any tutorial ever could. Building a PDF engine from scratch in Go is one of them. It is not glamorous. It is not trendy. But it forces you to confront memory management, binary serialization, concurrency safety, interface design, and performance profiling all at once, in a domain where correctness is non-negotiable. This article walks through the lessons learned building GoPdfSuit (~500 Github ⭐), a production PDF engine written in Go that generates 1.5 million financial PDFs in roughly 45 minutes on a single node, achieves PDF/A-4 and PDF/UA-2 compliance, and exposes itself as a REST API, a Go library, and Python CGO bindings simultaneously. Note : While I have six years of overall experience including two years working specifically with Go, I rarely encountered these types of challenges in my day-to-day work, as my role focused primarily on implementing new features within an existing architecture. Working on gopdfsuit was an excellent learning experience; it allowed me to dive deep into performance optimization and taught me a great deal. Below are some of the key takeaways. Building GoPdfSuit from a blank editor to a production-grade PDF engine-one that ships PDF 2.0 , PDF/A-4 , PDF/UA-2 , PKCS#7 signing, merge/split, XFDF fill, secure redaction, and a public gopdflib API-forced a shift from “business logic” to “systems engineering.” When you chase ~2,000+ aggregate ops/s on a mixed financial workload (48 workers, PDF/A on) and sub ~10 ms PDF generation, you stop debating frameworks and start fighting the allocator, cache lines, and ISO 32000 semantics. These fifty lessons are drawn from the actual codebase ( internal/pdf , pkg/gopdflib , benchmark harnesses under sampledata/ , and documented optimization passes in guides/cursor/ ). They mix specification pain with Go runtime craft and production reality-not generic blog advice. Part 1: Structural Hurdles & PDF Specification Nightmares Deco

If you’ve been following my previous posts, you know I’m a big advocate for Trunk-Based Development and shrinking your pull requests until they almost feel too small. In a perfect world, developers merge code directly into the main branch multiple times a day, everything flows smoothly, and production remains rock solid. But let’s be honest. When you actually try to pitch this to a backend team working on a core system, you almost always hit the exact same wall of resistance. Someone in the back of the room will inevitably raise their hand and ask: “That sounds great in theory, but I’m currently refactoring our legacy checkout service. It’s going to take me four days of deep architectural changes. Are you seriously telling me I should merge half-baked, broken code into the main trunk and push it straight to production where real customers are buying our products?” It’s a completely valid objection. If your only tool for hiding uncompleted work is holding onto a massive, long-lived feature branch, then trunk-based development breaks down immediately. You end up with the exact nightmare we talked about earlier: huge code reviews, painful merge conflicts, and code that rots before it ever sees a live environment. To make continuous delivery actually work without causing catastrophic production outages every single afternoon, you need to decouple two concepts that most engineering teams mistakenly treat as the exact same thing: Deployment and Release . Last article in this category is focused on Trunk-Based Development: https://codecraftdiary.com/2026/05/18/trunk-based-development-roadmap/ The Core Concept: Shifting Left by Decoupling In traditional development setups, deploying code and releasing a feature happen simultaneously. You merge your giant feature branch, the CI/CD pipeline runs, the code hits the live servers, and boom—your users immediately see the new functionality. This model is incredibly high-stakes. If something goes wrong, your only options are rollin

Most side projects start with a simple frustration. Mine started with a banking app. One of my banks had a feature I really liked. It automatically categorized transactions and showed spending breakdowns in graphs and charts. For the first time, I could easily see how much I spent on restaurants, groceries, transport, subscriptions, and other categories. The problem was that only one of my banks offered this feature. Like many people, I use multiple bank accounts, credit cards, and savings accounts. Two of my other banks provided little more than a long list of transactions. If I wanted a complete picture of my finances, I had to switch between apps and manually piece everything together. As a software engineer, my first instinct was obvious: "Why don't I just build this myself?" That idea eventually became MyVault . The Original Goal The first version of the project was surprisingly simple. I wanted users to: Upload bank statements Extract transaction data Automatically categorize spending View useful charts and reports The goal wasn't budgeting. It wasn't investment tracking. It wasn't accounting. I simply wanted a single place where I could see spending across all of my bank accounts. Once I started building, however, I realized there was a much more interesting opportunity. If all transaction data was already extracted and structured, why not allow users to ask questions about their finances? Instead of searching through transactions manually, users could simply ask: How much did I spend on restaurants last year? What subscriptions am I paying for? Which categories increased the most this month? How much did I spend while traveling? That's when MyVault started evolving from a reporting tool into an AI-powered financial assistant. Building as a Solo Developer One of the biggest challenges wasn't technology. It was building everything alone. When you're working on a side project, you don't just write code. You become responsible for everything: Product decisions B

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

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

Over the past few months I built an AI-assisted delivery framework — not to write code faster, but to eliminate ambiguity across the entire software development lifecycle. The result completely changed how I think about AI in engineering. The problem I kept hitting Every time I used AI to generate architecture docs, API contracts, or implementation plans across separate sessions, the outputs looked great in isolation. But viewed together? They were broken. A pivot in the system architecture was never reflected in the API contracts. Frontend assumptions silently diverged from backend data models. AI wasn't the problem. Treating it as a collection of disconnected prompt sessions was. What I built instead A governance-driven framework built on three layers: Prompt → Agent → Skill The Prompt captures intent only — lightweight, declarative The Agent orchestrates execution and decides which capabilities to invoke The Skill is a reusable, schema-validated execution block with hardcoded governance rules This connects every delivery artifact into a sequential dependency chain: Business Requirements ↓ System Architecture ↓ Data Architecture ↓ Event Architecture ↓ API Contracts ↓ Implementation Plans ↓ Backend / Frontend Implementation Each artifact consumes the one before it. Upstream changes automatically propagate downstream. Governance is enforced at the Skill layer — not buried in fragile prompts. The finding that surprised me most The highest-leverage use of AI wasn't code generation. It was context generation . When engineers — or downstream agentic workflows — were given a governed, unambiguous spec, implementation quality was consistently higher than any raw AI-generated code output. The context was the unlock, not the syntax. What failed I'm including this because most write-ups skip it: Over-orchestrating everything (not every workflow needs an agent loop) Prompt bloat as a substitute for real architecture Severely underestimating token costs at scale Believing full

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

If you have ever submitted an iOS application to Apple's App Store and received a cryptic rejection notice about icon specifications, you are not alone. Apple's human interface guidelines for icons are extraordinarily precise — and for good reason. The iOS ecosystem spans devices from the tiny Apple Watch to the expansive iPad Pro, each requiring icons at exact pixel dimensions to render correctly across Retina, Super Retina XDR, and ProMotion displays. Understanding iOS icon sizes is not optional. It is a prerequisite for shipping. Every pixel dimension you provide must match Apple's specifications exactly, must use lossless PNG format, must not include transparency, and must be delivered with the exact filename that Xcode expects. One missed size, one wrong filename, and your project fails to build correctly. Precision is not a suggestion — it is a hard requirement enforced by Xcode's build system. iPhone Icon Sizes For iPhone applications, the required icon sizes span multiple uses within the operating system. The App Store listing requires a 1024×1024 pixel icon. The home screen displays icons at different sizes depending on device generation and display density. Notification icons, Spotlight search results, and Settings app icons all require their own specific dimensions. Usage Scale Size (px) Filename Convention App Store 1× 1024×1024 Icon-1024.png Home Screen 2× 120×120 Icon-60@2x.png Home Screen 3× 180×180 Icon-60@3x.png Spotlight 2× 80×80 Icon-40@2x.png Spotlight 3× 120×120 Icon-40@3x.png Settings 2× 58×58 Icon-29@2x.png Settings 3× 87×87 Icon-29@3x.png Notification 2× 40×40 Icon-20@2x.png Notification 3× 60×60 Icon-20@3x.png iPad Icon Sizes iPad adds its own set of required sizes, particularly because of the larger screen real estate and different display densities. Xcode's asset catalog system requires each icon to be placed in the correct slot, and any missing slot will prevent archiving for App Store submission. This makes completeness not just a best p

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