标签：#programming

Pressing enter to accept model suggestions now takes less effort than scrolling past it. One keystroke, and the code is yours. Reading it, understanding it, deciding if it's actually right, that part hasn't gotten any faster. That gap, between how fast we can accept code and how fast we can actually understand it, is where things start to go wrong. The new shape of technical debt We used to know where technical debt came from. Tight deadline, cut corner, # TODO: comment that nobody ever revisits. Rushing was the cause, and we could at least point to it. Now you can build up the same kind of debt on a calm Tuesday afternoon, no deadline in sight, just six suggestions in a row accepted because they looked fine and the flow felt good. Nobody rushed you, and the code still ended up just as unexamined. Same debt, just a different excuse. "It works" is not the same as "I understand why it works" Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? — Brian Kernighan, 1974 Fifty years later, the gap got wider. Kernighan was talking about code you wrote. At least you understood it once. A suggestion that compiles, passes the linter, survives code review and even comes with passing tests can still be standing on a wrong assumption that nobody caught, because nobody was reading it as code. They were reading it as output, and output that makes sense tends to get approved. Compiling is a low bar. Passing tests is a slightly higher one, depending on whether you wrote the tests, or its suggestion shaped or created those too. If it's the second, it's like grading its homework with its own answers. None of it tells you the logic is sound, that the edge cases are covered, or that it does what you actually needed, something we already learned every time we trusted code we didn't write. Somehow it's easy to forget it the moment the code appears inline, in our own edito

Opening hook It happened during a quiet afternoon at the mosque. The imam was mid-sentence when a rhythmic, high-pitched ringtone cut through the silence like a knife. Every head turned. It was my phone. My heart sank as I scrambled to silence it, only to realize I had forgotten to flip the physical toggle before walking in. That moment of collective, disappointed glares burned. It wasn't just an annoyance; it was a total breakdown of my focus and a social failure I had accidentally caused because my phone couldn't manage itself. The problem We live in an era where our devices are supposedly 'smart,' yet they are remarkably bad at knowing when to keep quiet. We carry computers in our pockets that can calculate the exact position of the moon or stream 4K video, but they cannot inherently tell that we are in a meeting, a lecture, or a place of worship. You could argue that setting a manual schedule works, but life isn't static. Meetings run over, prayer times shift by a minute each day based on astronomical calculations, and spontaneous plans happen. I found myself constantly juggling the physical volume buttons. If I remembered to mute it, I inevitably forgot to unmute it afterward, missing urgent calls from family. If I didn't mute it, I was the person disrupting the room. I wanted a solution that respected the context of my location and the specific time of day without requiring me to touch my screen. The core friction is that Android is designed to restrict background processes to save battery, which is exactly what a silent-automation app needs to thrive. Getting the app to reliably trigger a volume change while the phone is sitting in a pocket, deep in Doze mode, became my primary development hurdle. The technical decision / implementation When I started building Muffle, I initially tried a standard Service with a Handler loop to check conditions. It worked fine while the screen was on, but as soon as the phone entered Doze mode, the OS aggressively throttled my

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

AI is great at writing tests fast, and good at writing tests that look real but verify the wrong...

AI is great at writing tests fast, and good at writing tests that look real but verify the wrong...

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

I wrote a detailed comparison of GitHub Actions vs Jenkins after working with both while learning DevOps. Instead of focusing on "which one is better," I looked at questions like: When does GitHub Actions become enough? When is Jenkins still the right choice? Performance and scalability Security and maintenance Cost Real-world use cases I'd love to hear where you disagree or what your production experience has been. Article: actions vs jenkins submitted by /u/ganeshak11 [link] [留言]

submitted by /u/Dear-Economics-315 [link] [留言]

I’ve been experimenting with local AI setups for a while, and honestly, most guides online are either too complicated or miss key steps. I recently set up Open WebUI with Docker and Ollama , and once it clicked, it actually felt pretty straightforward. Here’s a simple breakdown of what worked for me: Used Docker to avoid dependency issues (this saved a lot of time) Connected Open WebUI to Ollama local models Accessed everything through browser (ChatGPT-like interface) Tested basic prompts + API flow Played around with pipelines for structured outputs The biggest confusion I had was around connection between Open WebUI and Ollama, but once the API endpoint was correct, everything just worked. I also documented the full step-by-step setup, errors I faced (like 500 errors), and fixes here if anyone’s interested: 👉 Build your own ChatGPT locally in minutes If anyone else has tried similar local LLM setups, curious what stack you’re using or if there’s a better workflow. submitted by /u/thecoode [link] [留言]

I’m building an experimental HTML-to-PDF engine in Rust and would like technical feedback from people who understand browser engines, PDF generation, rendering, or high-volume document systems. The goal is to build a very low-RAM, highly parallel HTML-to-PDF engine for server workloads. Think invoices, reports, tables, receipts, business templates, generated dashboards, and API-based PDF rendering. The motivation is that Chromium/Puppeteer is very compatible, but expensive for high-volume PDF generation because each render can involve a heavy browser process/runtime. I want to explore whether a dedicated engine can cover common server-side HTML-to-PDF use cases with much lower memory and better multi-core scaling. Current architecture: HTML -> html5ever parser -> compact arena DOM -> cssparser stylesheet parsing -> cascade + computed styles -> box tree -> layout / pagination -> display list -> compressed PDF writer Some current design choices: Rust implementation no Chromium or browser subprocess compact arena-based DOM instead of pointer-heavy node graph independent render jobs so many PDFs can render in parallel across worker threads display-list boundary so layout is separate from PDF writing optional bounded pre-layout JavaScript stage behind a trait PDF backend supports compressed streams, selectable text, embedded fonts, Unicode/ToUnicode, and font subsetting work The long-term ambition is “lean and fast HTML-to-PDF with broad CSS and controlled JS support,” but I’m trying to be realistic. I know “full CSS/JS” is basically browser-engine territory, so I’m thinking the practical first target should be server-generated documents rather than arbitrary websites. Questions for the community: Is this technically realistic if the scope starts with business/document HTML rather than full browser compatibility? What are the hardest parts I’m likely underestimating? Which CSS/layout features are absolutely necessary for real-world adoption? Is pre-layout deterministic J

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

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

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

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

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

Exhaust the enemy's strength without fighting. Weaken the strong by nurturing the soft. — The 36 Stratagems, " Wait at Leisure While the Enemy Labors " P flipped the business card over and wrote one letter on the back: P . Then P walked into the conference room. P didn't do opening lines. P doesn't have a name — not yet, not in this series anyway. But if you've read the earlier stories, you'd recognize the signature. The first story — P's own article got flagged as "low quality" by the company's AI moderation system. P dug into the internal API, pulled 347 flagged records — effective accuracy came out to 38%. More false positives than correct identifications. The second story — an AI payment gateway processing $2.8 billion. The CTO backed it with formal verification, claimed it was "mathematically bulletproof." P spent eight months quietly building an adversarial testing pipeline, and proved the gateway would approve illegal transactions. P won both times. P left zero fingerprints both times. After those two jobs, P stopped working for other people. This time, P got brought in as an independent evaluator. Two Companies, One Customer, Zero Questions The customer was a mid-sized industrial IoT firm called FirmCore . Their production-line gear had been running for almost a decade. The monitoring system was going down once a month, and management had finally had enough. They decided to bring in an AI monitoring platform. A good call — right up until they decided to run two vendors through POC at the same time and pick a winner. "We want to see who can actually cover our failure modes," the VP said in the meeting. "We've also brought in an independent evaluator." P was that evaluator. The two AI monitoring companies were MonitorAI and SentryWave . MonitorAI's pre-sales team went first, slides blazing with "99.3% fault coverage, validated across 3 manufacturing customers." SentryWave followed right behind: "99.7% coverage, 7-day deployment" — bigger numbers, bolder font.

In this talk, Trisha identifies issues that slow down developers when writing, running and debugging tests, and look at tools that can help developers with each of these problems. There's live coding, analysis of social media poll results, an overview of solutions in this space, "best practice" recommendations, and machine learning will be mentioned at some point. submitted by /u/goto-con [link] [留言]

Most teams still suffer from a classic disconnect: the gap between what a developer is actually doing in their local Git repo and what Jira shows to the rest of the team. Developers forget (or delay) updating tickets not because they're lazy, but because switching context to Jira breaks flow. This leads to stale Jira boards, painful standups full of status checks, and poor visibility for PMs and Scrum Masters. I decided to close this gap with a tool called Jitly . The Core Idea Instead of manually doing: git pull origin main git checkout -b feature/ABC-123-xyz Go to Jira → Move ticket to In Progress Jitly lets you run jitly start ABC-123 and it handles everything automatically — including respecting team-specific branch naming conventions and commit message formats. Technical Implementation Highlights Jira Integration : Supports both Jira Cloud (SSO/OAuth2) and Jira Server/Data Center (PAT). Uses atlassian-python-api under the hood with proper session management. Git Operations : Uses GitPython + subprocess for safe operations. Handles dirty working tree by offering stash/push/discard choices. Workflow Hooks : Detects ticket status change (via manual command for now) and triggers git + Jira actions. Configuration : Team-level config for branch patterns (e.g. {type}/{ticket}-{slug}) and commit templates using Jinja2-style formatting. Idempotency : If a branch already exists for a ticket, it intelligently checks out and continues work instead of failing. Single binary-like experience via pip install with entry point. It's currently focused on the most painful part of the developer workflow — starting and finishing work — while keeping the tool lightweight. Would be interesting to hear how others are solving this Jira-Git synchronization problem in their teams. What tools/workflows do you use today? Download link: https://pypi.org/project/jitly/ Demo Video: https://www.youtube.com/watch?v=_czVTfqGKGY submitted by /u/Direct_Holiday_5934 [link] [留言]

I saw an issue today on a fairly popular project (better-auth, see the link to the issue attached). No repro, no context, just a wall of caps and profanity ending in "fuck you". The maintainers ship this for free. People run production businesses on top of it, for free. And the thanks is someone raging into a text box because a minor bump cost them an afternoon. I maintain and contribute to a few projects myself, so this hits a nerve a bit. Something people don't see from the outside: it's not enough to know how to build the thing. You also have to know how to defuse a thread where someone's insulting you and not fire back, even though most of us aren't paid for any of it, let alone the work of staying civil while being told to get fucked. I'm not pretending breaking changes don't cause real pain (that's what the issue is about). But I keep coming back to a boundary question: if you're not paying for it, do you actually get to demand anything? (Obviously yes, but we still need some boundaries) submitted by /u/swithek [link] [留言]

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