标签：#programming

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

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

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

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

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

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

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),

May 29 I wrote my first AI trainwreck story. June 18 I finished #15. People keep asking if this was...

📖 Originally published on my blog . Part of a series on building with Claude Code. For a while I'd watch the AI work and quietly grumble: a fairly big task, and it would finish one module before starting the next, while I just sat there waiting for it to clear one before the other's turn came up. The work itself was fine—it was just slow. Slow because it was stuck in a queue. Then it clicked: a lot of these modules have nothing to do with each other, so why make them go one after another? Split them up, let several agents work at the same time, done. What I want, and where it stops What I want is simple: the same work, for roughly the same tokens, with the wall-clock time cut way down. But let me put the boundary up front— not every task can be split this way . This is just an approach I've worked out for myself; take what's useful. The prerequisite: a clean architecture For several agents to work at once without stepping on each other, the prerequisite isn't the AI—it's your architecture . That task of mine could be split because it was already several modules, talking to each other through interfaces, with internal implementations that don't affect one another—as long as each one honors the interface contract, it can be built independently. Loosely coupled, highly cohesive, in other words. And I'd nailed that design down together with opus before writing a line: opus helps me think it through and lays out options, but I'm the one who decides . You can't cut corners here. Forcing parallelism onto an architecture you haven't cleanly split is like cutting a tangle of yarn into a few pieces that are all still knotted together—it only gets messier. Who runs the show, who plans, who does the work With the design settled, it's time to assign roles. The split I tend to use: opus runs the show —holds the big picture, hands out work, does the final check; sonnet does the TDD planning —per the design, it lays out how each module gets tested and implemented; haiku writes the

AI Coding Agents Need a Control Layer AI coding agents are getting good enough that the problem is changing. A year ago, the question was mostly: Can this thing write useful code? Now, for a lot of builders, the better question is: How do I supervise this thing once it is actually doing work? That shift feels important. Claude Code, Cursor, Codex, and similar tools are not just autocomplete anymore. They can plan, edit files, run commands, review code, and work across larger chunks of a project. That is powerful. It also gets messy fast. The bottleneck is moving The hard part is no longer just picking the best coding agent. It is figuring out how to manage agent work once multiple tools or sessions are active. Questions start showing up: What is each agent doing right now? What changed? What still needs human review? Where did approval happen? Which agent owns which task? Did two agents touch the same part of the codebase? What should be paused, redirected, or stopped? What happened while I was focused somewhere else? That is not really a prompting problem. It is a control problem. The current workflow is mostly duct tape A lot of agent workflows seem to rely on some combination of: terminal tabs tmux sessions git branches git worktrees editor diffs notes issue trackers rules files memory vibes That works for a while. But once agents become more autonomous, or once a builder runs more than one agent at a time, the workflow starts to need a real operating layer around it. Not because the agents are bad. Because the agents are getting useful enough to need supervision. The missing layer The layer I keep thinking about has a few jobs. State What is running? What is paused? What needs attention? Ownership Which agent owns which task, branch, file, or objective? Review What changed, and what still needs a human to look at it? Approval Where should the human say yes before work continues? Intervention When should a builder pause, redirect, compare, or stop an agent? Memor

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion. I built Hiyoko PDF Vault — a macOS PDF tool — in Rust. Choosing the right PDF library was the first real decision. lopdf or pdfium. Here's what I found. lopdf: pure Rust, no dependencies lopdf is pure Rust. No C bindings, no system libraries, no bundling headaches. What it does well: Merge, split, rotate pages Read and write PDF structure Metadata manipulation Bates numbering Works well for structural PDF operations What it struggles with: Rendering PDFs to images (not its job) Complex font handling Malformed PDFs — lopdf is strict; real-world PDFs often aren't For a tool that manipulates PDF structure without rendering — merge, split, encrypt, add watermarks, strip metadata — lopdf is the right choice. Pure Rust means easy cross-compilation and universal binaries with no extra work. pdfium: full rendering, C dependency pdfium is Google's PDF engine (from Chromium). The pdfium-render crate wraps it for Rust. What it does well: Accurate PDF rendering to images Handles malformed PDFs that lopdf rejects Text extraction from complex layouts Full PDF spec compliance What it requires: Bundling the pdfium binary with your app (~20MB) Architecture-specific binaries (x86_64 and aarch64 for universal binary) More complex build setup For a tool that needs to display PDFs or extract text from complex documents, pdfium is the right choice. You pay for it in bundle size and build complexity. What I actually use lopdf for structural operations: merge, split, encrypt, watermark, metadata, Bates numbering. Apple Vision Framework (via Tauri shell commands) for OCR — it's already on the user's Mac and handles Japanese text better than anything I could bundle. I avoided pdfium because the bundle size increase wasn't worth it for my use case. If I needed accurate rendering, that calculation would change. The honest recommendation Start with lopdf. It covers most PD

I thought DEV Challenges were about winning. What participating in DEV Challenges taught me. A few months ago, I joined DEV. I didn't know many people. I wasn't well known. I simply wanted to become a better developer. Like many newcomers, I believed something very simple. "If I can win a challenge, maybe that means I'm becoming a real developer." So I kept participating. Sometimes I built retro games. Sometimes I experimented with AI. Sometimes I simply challenged myself to finish something before the deadline. Every challenge taught me something. Every badge made me smile. But after several months, I realized something unexpected. The biggest prize wasn't the badge. I started asking myself... What happens after the contest ends? The badge stays on my profile. The project goes to GitHub. Then... What's next? That question stayed with me for a long time. Then I realized something. I had been focusing on the contest. But the real value wasn't the contest. It was the community. Without DEV... I would never have discussed ideas with developers from around the world. I would never have received reactions from people I had admired. I would never have met developers with completely different ways of thinking. The challenge wasn't just building software. The challenge was becoming part of a community. Something I had rarely experienced before. Most communication happens inside companies. DEV felt different. It gave me a place to keep showing up. To keep learning. To keep improving. That matters more than I realized. The hardest part isn't building software. This surprised me. As I kept building apps, I realized something. Building an app is difficult. But building a place where people discover that app... is much harder. That's when I started appreciating communities like DEV even more. Someone had to build this place. Someone had to create a market where beginners and experienced developers could stand on the same stage. That's an incredible achievement. My goal changed.

I've wanted easy trunk-based development for Salesforce for years. Short-lived branches, frequent merges, small pull requests, and CI fast enough that developers aren't afraid to commit. The same practices that engineering teams use everywhere else. Every time I tried to make it work, I hit the same wall: Apex tests require an org. That single dependency turns every validation run into an infrastructure problem. Before a test can execute, you need authentication, environment provisioning, metadata deployment, test execution, and cleanup. The result is feedback loops measured in minutes instead of seconds. I got tired of waiting and built Nimbus, a local Apex runtime that executes Apex tests without an org. This is what I learned while trying to make trunk-based development actually work for Salesforce. Why trunk-based development is hard in Salesforce Trunk-based development depends on fast feedback. If validation takes seconds, developers make smaller changes, merge more frequently, and keep branches short-lived. If validation takes fifteen minutes, behavior changes. Pull requests get larger, unrelated work gets batched together, and validation stops happening continuously because validation itself becomes expensive. Salesforce has always had a structural challenge here because Apex only runs inside Salesforce. A typical validation pipeline looks something like this: sf org login jwt sf org create scratch sf project deploy start sf apex run test sf org delete scratch There is nothing inherently wrong with these steps. The problem is that most of them have nothing to do with testing. They're infrastructure management. The actual validation of business logic is only one part of the process. The longer I worked with Salesforce CI, the more obvious it became that the bottleneck wasn't Apex itself. The bottleneck was everything required to create an environment where Apex could run. The solutions I tried first Before building a local runtime, I tried solving the problem

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

Day 9. Template matching works. But screen sizes, resolutions, and Android versions might break everything. Eight days ago, the agent was an idea. Now it can read text, handle interruptions, and find icons on a screen. But there's a question I've been avoiding: does it work on any phone other than mine? The Cross-Device Problem Every screenshot I've taken, every icon I've cropped, every coordinate I've mapped—it's all on one device. My phone. Same screen size. Same resolution. Same Android version. Same DPI. Template matching relies on reference images that look exactly like the target on screen. Change the screen density, change the icon size, change the font scaling, and the match confidence drops. Suddenly "send_button.png" doesn't match anymore, and the agent can't press send. This isn't a bug in my code. It's a fundamental challenge in computer vision: reference-based matching breaks when the visual context changes. Today's Experiment I tested the same agent on a friend's phone—different manufacturer, different Android version, slightly larger screen. The results were humbling. Task My Phone Friend's Phone OCR (text recognition) ✅ 95% accuracy ✅ ~90% accuracy Find "Mom" in contacts ✅ Found ✅ Found Template match: send button ✅ 94% confidence ❌ 62% confidence Template match: back button ✅ 91% confidence ❌ 58% confidence OCR held up reasonably well because text is text. Fonts might change slightly, but the characters are the same. But the icons—the send button, the back arrow—were rendered at a different size and slightly different pixel arrangement on my friend's device. The agent failed to send the message. Why This Matters An AI agent that only works on one phone isn't an agent. It's a script. If I want this to be useful to anyone else—or even to myself if I change phones—it needs to be device-agnostic. Possible Solutions I'm Exploring Solution Pros Cons Multi-resolution icon library Simple. Just crop icons at different DPIs. Tedious. How many variants are eno

spent most of my career either in kernel land where you account for every byte yourself, or in nodejs/nestjs world where you just throw objects around and let the runtime sort it out. Monkey C is neither and it kept messing with my instincts. the lead dev once described the goal as wanting something that looked like javascript but with no features that waste memory, basically "syntactic splenda" instead of sugar. so you get this language that reads like JS but the second you write JS-brained code it punishes you. the part that actually got me was memory. everything ran perfect in the simulator and then crashed on the actual watch with out of memory. turns out watch faces get a tiny slice of RAM compared to full apps and the older devices are brutal about it, were talking double digit KB for the whole thing. coming from a runtime where I never think about allocation it was kind of humbling to go back to counting objects like its an embedded target again, because it is one. other thing nobody warns you about is theres almost no ecosystem outside garmins own forums. stack overflow is basically empty so you end up digging through old firmware bug threads to figure out why something behaves diferently on device vs sim. weirdly I enjoyed it more than I expected. it scratched the same itch as kernel work, real constraints and no abstraction to hide behind. would not want it as a day job but as a side thing its a nice reset. submitted by /u/Robservant [link] [留言]

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

If you’ve spent any time working with autonomous AI coding agents recently, you know the drill. You give the agent a straightforward task: "Add a user profile page and link it to the navbar." The agent says, "I've got this." It writes some code. You run it, and it throws an import error. You paste the error back. The agent apologizes, rewrites the file, and now your routing is broken. You paste that error back. Ten iterations later, your config is mysteriously deleted, the navbar is entirely missing, and the agent is trying to install a deprecated version of React. This is the AI Agent Doom Loop. It happens because current agent frameworks mistake intelligence for discipline. We dump a 10,000-token SYSTEM_PROMPT.txt telling the agent everything about our project, hoping it remembers the architecture constraints on step 45 of its execution loop. It rarely does. I built Agent Rigor because I got tired of babysitting agents that code themselves into corners. The Root Cause: Context Rot When an agent starts a task, its context is pristine. But as it reads files, executes commands, and hits errors, its context window fills up with junk stack traces and previous failed attempts. By the time it's 20 steps deep, the original system prompt you carefully crafted is buried. The agent forgets the architecture guidelines. It starts prioritizing the immediate error in front of it over the overall goal. This is when it starts guessing, hallucinating, and making things worse. The Solution: Progressive Disclosure and Empirical Discipline Agent Rigor isn't a new LLM or a magic prompt wrapper. It's an operating system for agents that enforces strict empirical discipline . Instead of one massive prompt, Agent Rigor uses a 3-tier hierarchy: L1 (Apex Kernel): The absolute, non-negotiable laws. (e.g., "Never guess an API signature. Always grep or read the file first.") L2 (Phase Directors): Orchestration that only loads when the agent enters a specific phase (Planning, Execution, Verifica

🌍🚀 Project Showcase: Carbon Footprint Tracker I'm excited to share one of my recent projects — a Carbon Footprint Tracker designed to help users better understand their environmental impact and encourage more sustainable lifestyle choices. As developers, we have the opportunity to build technology that not only solves problems but also creates awareness about important global challenges. This project was a great experience in combining technology, user experience, and sustainability into a single application. ✨ Key Features: • Carbon footprint calculation system • Clean and intuitive user interface • Responsive design for all devices • Real-time user interaction • Environmental awareness focused experience • Modern frontend architecture 🛠️ Technologies Used: • React • JavaScript • HTML5 • CSS3 • Git & GitHub 💡 What I Learned: • Building interactive user interfaces • State management and user input handling • Creating responsive layouts • Writing cleaner and more maintainable code • Designing applications around real-world problems 🔗 GitHub Repository: https://github.com/Prem759-0/Challenge-3-Carbon-Footprint 🔗 Live Demo: https://challenge-3-carbon-footprint.vercel.app/ I am continuously improving my skills through hands-on projects and exploring how technology can create meaningful impact. Every project teaches me something new and pushes me one step closer toward becoming a professional Full-Stack Developer. Feedback and suggestions are always welcome! 🙌

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