标签：#programming

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

I am a solo learner. I started coding last year with the help of AI and sometimes without any tutorials or courses. At first, I thought this journey would be easier. But soon I realized something important — no AI or tool can fully solve the real problems I was facing as a developer. I used AI a lot. It explained things with confidence and even provided code. But when I ran that code in my terminal, many times it didn’t work. That’s when I understood something important: AI can guide, but it cannot replace understanding. After facing these issues, I changed my way of learning. Instead of blindly trusting AI, I started: Finding real open-source projects Studying how they were built Listing important topics from those projects Reading documentation carefully Asking AI to explain specific lines of code This helped me understand real-world code better. From this learning journey, I realized something: I should also build my own open-source projects. At first, I believed that creating a powerful project could automatically bring attention and users. But I was wrong. I made a mistake — I was not active on any platform. I was just coding inside VS Code, without communication or sharing my work anywhere. Then I realized: Being a developer is not only about coding. Visibility and communication are also important. After that realization, I started being active on platforms like Dev.to, LinkedIn, and other developer communities. I started posting my work and sharing my progress. Even though I didn’t get many comments, I started getting reactions and engagement. That small feedback gave me motivation. From this journey, I learned something important: Open source is not only about code. It is about helping other developers, sharing knowledge, and being consistent and visible. A developer should not only code silently but also participate in the community. Now I understand that coding is only one part of being a developer. Community, communication, and consistency are equally imp

Few lines of code look more innocent than this: retry ( 3 ) It feels responsible. Professional. Resilient. After all, networks fail. Servers become unavailable. Databases occasionally time out. Retrying seems like the obvious solution. And sometimes it is. But after enough years building production systems, I've become convinced of something: Retry is one of the most dangerous keywords in software. Not because retries are bad. Because retries amplify everything. Good systems become more reliable. Bad systems become disasters. The problem is that many developers treat retries as a reliability feature when they're actually a distributed systems feature. And distributed systems are where simple ideas go to become complicated. Why Retries Exist Imagine: await fetch ( " /api/users " ); The request fails. Maybe: Network hiccup Temporary database issue Load balancer restart Service deployment The operation might succeed if attempted again. So we write: retry ( 3 ) Seems reasonable. And in many cases: It Works Which is why retries become popular. The Dangerous Assumption Most developers unconsciously assume: Failure = Operation Did Not Execute Unfortunately that's not always true. A request can: Execute Successfully ↓ Response Never Arrives From the client's perspective: Failure From the server's perspective: Success Now a retry becomes dangerous. The Double Payment Problem Imagine a payment service. await chargeCard ( order ); The card processor successfully charges: $100 The response is lost due to a network issue. Client sees: Request Failed and retries. await chargeCard ( order ); again. Now: Charge #1 = Success Charge #2 = Success The customer paid twice. Nobody wrote bad logic. The retry created the bug. The Email Storm Problem Consider: await sendWelcomeEmail ( user ); Email provider accepts the message. Response times out. Application retries. await sendWelcomeEmail ( user ); again. Customer receives: Welcome! Welcome! Welcome! Welcome! Support ticket created. Marke

I left a multi-agent refactor running overnight. By morning the model was gone, pulled out from under me by a government I don't even vote for, on the other side of an ocean. This isn't really a story about Anthropic. It's a story about who's actually holding the off-switch, and right now it probably isn't you. So here's how my morning went. I had a job running. Not a toy, a proper codebase-wide refactor that had been grinding away continuously for the best part of two days. Multi-agent setup, left to run overnight, the kind of long, messy, long-horizon task that every model before this one just fell over on. Claude Fable 5 was handling it like it was nothing. Anthropic's own launch notes talk about it compressing months of work into days, and honestly, on my own codebase, that wasn't marketing. It was just what was happening. Then I woke up. And the model was gone. Not rate-limited. Not having a wobble. Gone. The thing I'd built two days of momentum on simply did not exist any more. Turns out that on the 12th of June the US government issued an export-control directive telling Anthropic to cut off all access to Fable 5 and Mythos 5 for any foreign national. And because you can't exactly sort a global user base by passport in real time, that meant pulling it for everyone. Including me, sat in Tyrol, watching my overnight run go cold. Anthropic did the right things, for what it's worth. They complied fast, they said out loud that they disagreed, and they're fighting to get it back. About as well as a vendor can behave in that situation. (As I write this it's still down. Anthropic reckon it's a misunderstanding and they're trying to get it restored, so maybe by the time you read this it's back up. Doesn't change a single thing about the point I'm making.) And it made absolutely no difference to me. That, right there, is the whole point of this post. The offer was the trap Wind back a few days. Fable 5 dropped as the best model anyone had shipped, and the offer was lov

A receiver pulling a UDP feed was missing roughly 30% of its messages. No errors, no exceptions, no stack traces — just gaps in the sequence numbers. The first suspect is always the network: a flaky switch, a saturated link, a tired NIC. The network was innocent. The packets were being dropped on the receiving host , after they'd already arrived. Here's how to tell the difference, and why it matters. Why UDP makes this sneaky UDP has no retransmission and no backpressure. When a datagram is lost, nobody is notified — not the sender, not the receiver. The packet simply isn't there. That means two completely different failures look identical from the application's point of view: The network dropped the packet before it reached your machine. Your own host accepted the packet and then threw it away after it arrived. The application sees the same thing in both cases: a missing sequence number. But the fix is in a different building depending on which one it is. Where the packets actually go The receive path is: NIC → kernel socket receive buffer → your recv() call. The kernel parks incoming datagrams in a per-socket buffer until your code reads them. If your code doesn't drain that buffer fast enough, it fills, and the kernel drops the overflow. Crucially, the kernel counts those drops. On Linux: # Per-protocol summary — look for "receive buffer errors" netstat -su # Or straight from the kernel counters cat /proc/net/snmp | grep -A1 Udp # InDatagrams ... InErrors RcvbufErrors ... If RcvbufErrors is climbing, the network did its job and your host discarded the datagrams. That single counter collapses a week of "is it the switch?" into about ten seconds of certainty. The actual cause In this case the socket receive buffer was sitting at the default (~208 KB). The sender burst faster than a single receive thread could call recv() . Average throughput looked fine on every dashboard — but the bursts filled the buffer in milliseconds, and everything past the brim was dropped.

How I Fixed Bugs in 30+ Open Source Projects (And What I Learned) Over the past few months, I've been contributing to open source as an independent developer. No big company backing, no team — just me, a laptop, and a lot of caffeine. Along the way, I've submitted pull requests to 30+ repositories across the Python, JavaScript, TypeScript, and Rust ecosystems. Here's what I learned from the process — the good, the bad, and the "I wish someone told me this earlier." Why Contribute to Open Source? Let's get the obvious out of the way: it's not about the money (at least not directly). Most bounties pay $50-$500, and you'll spend 10-20 hours on a single PR if it involves deep codebase exploration. The real value is: Reputation — Each merged PR is a public signal that you can read, understand, and improve other people's code Learning — You'll see how major projects are structured, tested, and maintained Network — Maintainers remember helpful contributors. Jobs come from these relationships Scratching your own itch — Fix a bug that annoys you? Everyone benefits My Process: Finding Good Issues Step 1: Pick the Right Projects Not all projects are equally welcoming to new contributors. Here's my filter: Signal Good ✅ Bad ❌ Response time < 7 days > 30 days or never Issue labels good first issue , help wanted None CI/CD Green, fast builds Broken, 30min+ builds PR merge rate > 60% of open PRs merge < 20% merge Step 2: Find Issues You Can Actually Fix I look for: Bug reports with clear reproduction steps — Someone already did the hard work of identifying what's wrong Issues labeled easy-fix or similar — The maintainer thinks it's approachable Issues in domains I know — Don't pick a C++ compiler bug if you've never written C++ Step 3: Before Writing Code This is where most beginners fail. Don't start coding yet! Read the CONTRIBUTING.md — Every project has different style, commit message format, and PR requirements Look at recent merged PRs — What do good PRs in this project look

A couple of years ago, I built a custom flashcard app. I had a huge list of words and sentences in Japanese that I collected in an Excel file. I wanted an app that could easily take them and display them on flashcards. The flashcard app was useful, but the main issue was that I could only use it on my laptop. This meant that when I wasn't home, I had no access to it. I made some updates so that I could deploy it to Azure and now I can use it on the train or at the park. I wanted to share the app and lessons learned during development. What It Does The app is a straightforward spaced repetition flashcard tool. You create collections, fill them with cards (front/back/optional notes), and review them. After each card you rate your recall: Button Meaning Easy Remembered without effort Good Remembered correctly Hard Remembered with difficulty Again Forgot (resets to day 1) Ratings feed the SM-2 algorithm, which is the same algorithm as other popular spaced repetition apps like Anki. Cards that are easy get pushed further and further into the future. Cards that are difficult will come back sooner. After a while, you're just reviewing what you actually need to review. There's also a 45-second timer per card. If it expires before you complete the card, it automatically counts as Again (Resets to day 1). Before the timer, I found it easy to lose focus or open another tab and forget about the current card. This has helped me stay focused for longer and stay on this task. The CSS is specifically designed to be mobile friendly. The Tech Stack Frontend: Blazor WebAssembly (.NET 10) Backend: ASP.NET Core minimal API (.NET 10) Database: Azure SQL (Basic DTU tier) Hosting: Azure Static Web Apps (frontend) + Azure App Service F1 free tier (backend) I mostly use C# at work, so Blazor WASM was a natural fit. The whole app shares models and flows together without jumping between languages. Importing Cards from Excel This Excel import function is one of the main reasons I made this app.

I have been making a bowling alley operating system and for some reason my kernel wont boot --BOOT-- [BITS 16] [ORG 0x7C00] start: mov si, msg .print: lodsb or al, al jz .kernel mov ah, 0x0E int 0x10 jmp .print .kernel: jmp 0x0000:0x7E00 msg db "BOOT OK - BowlingOS", 13, 10, 0 times 510-($-$$) db 0 dw 0xAA55 --Kernel-- [BITS 16] [ORG 0x7E00] start: mov si, msg .print: lodsb or al, al jz .hang mov ah, 0x0E int 0x10 jmp .print .hang: jmp .hang msg db "KERNEL LOADED SUCCESSFULLY", 13, 10, 0 submitted by /u/guyriy [link] [留言]

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

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

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion. After 7 Tauri apps, I type the same commands constantly. Here's the reference I wish existed when I started. Project setup # New project npm create tauri-app@latest # Add to existing project npm install --save-dev @tauri-apps/cli npx tauri init Development # Dev mode (hot reload) npm run tauri dev # Dev with specific log level RUST_LOG = debug npm run tauri dev # Dev with backend logs visible npm run tauri dev 2>&1 | grep -v "^$" Building # Standard build npm run tauri build # Universal binary (Intel + Apple Silicon) npm run tauri build -- --target universal-apple-darwin # Debug build (faster, no optimization) npm run tauri build -- --debug Plugins npm run tauri add global-shortcut npm run tauri add fs npm run tauri add shell npm run tauri add notification This updates both Cargo.toml and the plugin registration. Faster than doing it manually. Permissions (tauri.conf.json) { "app" : { "security" : { "capabilities" : [ { "identifier" : "main-capability" , "description" : "Main window capabilities" , "windows" : [ "main" ], "permissions" : [ "fs:read-all" , "fs:write-all" , "shell:execute" , "global-shortcut:allow-register" ] } ] } } } Tauri v2 requires explicit permission declarations. If a command silently does nothing, check permissions first. Common Rust patterns // Get app data directory let data_dir = app .path () .app_data_dir () .unwrap (); // Emit event to frontend app_handle .emit ( "event-name" , payload ) .ok (); // Get window let window = app .get_webview_window ( "main" ) .unwrap (); // App state app .manage ( MyState :: new ()); let state = app .state :: < MyState > (); Notarization (macOS) # Submit for notarization xcrun notarytool submit app.dmg \ --apple-id YOUR_APPLE_ID \ --team-id YOUR_TEAM_ID \ --password YOUR_APP_PASSWORD \ --wait # Staple after notarization xcrun stapler staple app.dmg Debugging # Check what's in the bundle

I've been writing about AI coding tools for months here on Dev.to. Comparisons, benchmarks, tutorials on how to squeeze the most out of Claude Code, Cursor, and the rest. And I do use them. Every single day. But last week I tried something that surprised even me. I turned them off completely. For an entire week, no AI-generated code, no autocomplete suggestions, no "explain this function" prompts. Just me, my editor, and a blinking cursor. Here's what actually happened. The First Few Days Were Rough Day one was humbling. My output dropped by maybe half. What normally took 15 minutes stretched to 40. I found myself reaching for the Cmd+K shortcut out of muscle memory half a dozen times. But somewhere around day three, something shifted. I started reading source code instead of asking for summaries. I traced through execution paths instead of having the LLM walk me through them. I caught a subtle race condition that Claude Code had confidently dismissed as "not an issue" in the same codebase two weeks prior. That moment stuck with me. The Code Was Cleaner Here's the part I didn't expect. By day five, my code was noticeably simpler. Not because an LLM optimized it, but because I actually understood the problem well enough to keep it simple. AI-generated code often over-engineers. It adds abstractions for scenarios that don't exist. It writes defensive checks for edge cases that don't apply to your use case. It looks professional but carries unnecessary complexity. When you write it yourself, you stop at the simplest working solution because you know when you're done. An LLM doesn't know when you're done. It just keeps going until the context window runs out. The Real Cost of Productivity This is the part I've been thinking about most. AI tools remove friction. That's their superpower. But friction isn't always bad. The struggle of debugging your own code is how you learn a codebase. The effort of designing an API is how you develop taste for what makes a good one. If y

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

After covering the foundational building blocks in Session 1, the next step is one of the most important problem-solving techniques in all of programming: recursion . And once recursion feels comfortable, it unlocks a powerful search strategy called backtracking . These two concepts appear everywhere in competitive programming — Fibonacci, binary search, tree traversal, merge sort, dynamic programming, N-Queens, and more. They deserve their own spotlight. 🌟 What Is Recursion? A function is recursive if it calls itself. Instead of solving a problem in one go, a recursive function breaks it into a smaller version of the same problem, solves that, and repeats — until the problem becomes simple enough to answer directly. Three things define every recursive solution: The problem is expressed in terms of a smaller instance of itself Each call reduces the problem size There is a point where the problem becomes trivial and no further calls are needed — this is the base case The Nested Box Analogy Think of recursion like opening nested boxes. A big box contains a smaller box, which contains another, and so on. Eventually you find the item you were looking for. That innermost box is the base case. Without it, you would keep opening boxes forever — which is how you get a stack overflow, not a solution. Base Case and Recursive Case Every recursive function has exactly two parts: Recursive case — the problem is reduced in size and the function calls itself again. Base case — the terminating condition. No further recursive call is made. The function returns a direct answer. Both are non-negotiable. A function without a base case will keep calling itself, consuming stack memory until the program crashes. Example: Factorial 5! = 5 × 4! 4! = 4 × 3! 3! = 3 × 2! 2! = 2 × 1! 1! = 1 ← base case Each step reduces the problem by one. When the function hits 1! = 1 , it stops, and the results unwind back up the call stack. In pseudocode: function factorial(n): if n == 1: return 1 # base cas

Competitive programming often looks like a race to write code as fast as possible. But the real secret is simpler: the best competitive programmers are not just faster typists — they are better at choosing the right data structure, the right algorithm, and the right complexity level for the job. Before we jump into recursion, dynamic programming, graphs, or those problems that make your brain do backflips, we need a solid base. This first session is exactly that. Let's begin. 🚀 1. Data Types: What Kind of Data Are You Storing? A data type tells a programming language what kind of value a variable holds and what operations are valid on it. Primitive Data Types The basic building blocks provided by the language itself: Integer — whole numbers: 5 , 100 , -3 Float / Double — decimal values: 3.14 , 99.5 Character — a single symbol: 'A' , 'z' Boolean — true or false User-Defined Data Types When primitive types are not enough, programmers define their own: Structs — group related fields under one name Classes — structs with behaviour (methods) attached Enums — a fixed set of named constants Typedefs / Aliases — rename existing types for clarity A Real-World Example Imagine building a food delivery app: An integer stores the number of items in the cart A float stores the total bill amount A boolean tracks whether the order has been delivered A class represents an entire Order — customer name, address, items, payment status Data types are essentially the labels on your containers. Without them, chaos begins early. 2. Data Structures: How Do You Organise Data? If data types answer what a value is, data structures answer how to organise many values efficiently. This is where competitive programming starts to get interesting. Linear Data Structures Elements arranged one after another, like people queuing at a ticket counter: Arrays — fixed-size, indexed, fast random access Linked Lists — dynamic size, efficient insertions and deletions Stacks — last in, first out (LIFO) Queues

The first message ever sent across the network that became the internet was not "Hello, world." It was not a grand declaration. It was two letters, transmitted by accident, before the system fell over: LO . That two-letter packet is the ancestor of every connected device, every IoT sensor, and every web request running today. The story of how it happened is also a surprisingly useful lesson for anyone building embedded systems and connected hardware right now. What actually happened on October 29, 1969 On the evening of October 29, 1969, a programmer named Charley Kline sat at a terminal in Leonard Kleinrock's lab at UCLA. His job was simple on paper: log in to a remote computer at the Stanford Research Institute (SRI), roughly 350 miles away, over a brand-new experimental network called ARPANET. The plan was to type the command LOGIN . The remote machine at SRI was set up to auto-complete the rest once it saw the first few characters, so Kline only needed to start typing. He had a colleague on the phone at the Stanford end to confirm each letter arrived. He typed L . Stanford confirmed: "Got the L." He typed O . Stanford confirmed: "Got the O." He typed G - and the SRI system crashed. So the first message ever transmitted over ARPANET was "LO." As Kleinrock later liked to point out, it was an accidental but fitting first word: "LO" as in "lo and behold." About an hour later they fixed the bug and completed the full login, but the historic first packet had already gone out, two letters at a time. Why a crash is the perfect origin story It is tempting to read this as a cute footnote. It is more than that. The very first thing the internet ever did was fail partway through a transaction - and the system was built well enough that the humans on both ends knew exactly how far it had gotten before it died. That is the entire discipline of networked systems in miniature. Connections drop. Remote machines crash mid-request. Packets arrive out of order, or not at all. The n

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

JSON and GraphQL dominate modern web development, but XML (eXtensible Markup Language) is far from obsolete. Enterprise integrations, legacy systems, healthcare standards, and financial protocols still rely heavily on XML. If you work across diverse stacks, understanding XML is a skill that pays dividends. This guide covers the core syntax, validation techniques, parsing approaches, and best practices - with code you can put to work right away. Why XML Still Matters in 2026 XML has been around since 1996 and continues to thrive in specific domains. It handles deeply nested hierarchical data well, supports robust native schema validation, and manages mixed document-oriented content better than most alternatives. If you're dealing with SOAP APIs, Android layouts, SVG, DOCX/XLSX files, HL7 healthcare records, or FIX financial protocols, you're already in XML territory. The Core Building Blocks of an XML Document At its core, XML is a tree of nodes serialized as text. Every well-formed document starts with a declaration that tells the parser the version and character encoding - UTF-8 is the standard choice. From there, the document is composed of nested elements, attributes, and optionally text content. Elements - The Tree Nodes Elements are the primary structural unit in XML. They wrap your data in opening and closing tags. XML is case-sensitive, so a tag and a tag are treated as two completely different elements. Every opened element must have a corresponding closing tag to keep the document well-formed. Attributes - Metadata on Elements Attributes sit inside an opening tag and carry metadata about the element rather than the primary data itself. A good rule of thumb: use attributes for identifiers, types, or units (like currency), and use child elements for the actual payload data. This separation keeps your parsers predictable and your document structure clean. Self-Closing Elements When an element has no content or child nodes, you can collapse the open and close t

TL;DR: Your AI coding assistant is a generalist. It writes Flutter that looks right but quietly reaches for 2022 patterns. Agent Skills are a new, official way (from the Dart and Flutter teams) to hand your agent task-specific, battle-tested workflows it loads on demand. Two repos, flutter/skills and dart-lang/skills , ship ready-to-use skills for responsive layouts, routing, testing, localization, static analysis, and more. Install in one command: npx skills add flutter/skills --skill '*' --agent universal npx skills add dart-lang/skills --skill '*' --agent universal This post breaks down what they are, how they differ from rules files and MCP, the full catalog, what a real skill looks like under the hood, and whether they actually move the needle. (Spoiler: mostly yes, with one honest caveat.) Let me tell you about a fight I have almost every day. I ask my AI agent to make a screen adapt to tablets. It confidently hands me code that switches layout based on MediaQuery.orientationOf(context) . It looks clean. It compiles. It even runs . And it's wrong, because device orientation has nothing to do with how much window space your app actually has on a foldable, in split-screen, or in a resizable desktop window. The model isn't dumb. It's a generalist trained on a giant pile of Flutter code, much of it old. And here's the uncomfortable truth the Flutter team said out loud when they launched this feature: Flutter and Dart ship new features faster than LLMs can update their training data. That lag has a name, the knowledge gap , and it's why your agent keeps writing rookie Flutter with a straight face. Agent Skills are the Flutter team's answer to that gap. I've been running them on real projects, and they're one of the few "AI workflow" things in 2026 that earned the hype instead of borrowing it. Let's get into it. Table of Contents The real problem: your AI is a generalist What are Agent Skills, exactly? Skills vs Rules vs MCP: who does what The full catalog: every of

I was lurking around dev.to because I was bored and I saw a post made by @sylwia-lask on the...