Computer Science and Programming

A developer replaced six paid subscriptions (Plex Pass, UptimeRobot Pro, NextDNS, and others) totaling ~$400/year by running self-hosted alternatives on an old business laptop using Debian and Docker. The stack includes Jellyfin for media, Uptime Kuma for monitoring, Pi-hole with dnscrypt-proxy for network-wide DNS blocking, and more. The post covers both the practical benefits — built-in UPS via laptop battery, low power draw, portability — and honest trade-offs like initial setup time, occasional maintenance, and polish gaps in some open-source mobile apps compared to paid services.

C# 15 (shipping with .NET 11) introduces native union types, closing a long-standing gap in the language. Previously developers relied on workarounds like marker interfaces, abstract base classes, nullable returns, or the OneOf library to express 'this returns one of several types'. The new syntax is concise: `public union Result<T>(T, Exception);` declares a closed set of types. Implicit conversions allow direct assignment, and pattern matching gains compiler-enforced exhaustiveness checks — if a switch expression doesn't handle all union cases, the compiler warns. This means method signatures can truthfully express all possible return shapes without exceptions for control flow. The feature is currently experimental in .NET 11 Preview 4, compiled to a struct internally, and covers type unions (not yet full discriminated unions with named cases).

Gradle is aggressively adopting newer JDK releases to improve build performance, a strategy they call 'Javamaxxing.' Gradle 9.0 raised the minimum daemon JVM to Java 17, and Gradle 10 will require Java 21. Newer JDKs bring free performance gains through better GC, JIT compilation, and new APIs like Compact Object Headers (JEP 519) and the Class-File API (JEP 484). Critically, upgrading the JDK that runs Gradle does not force projects to target newer Java versions — JVM toolchains fully decouple the daemon JVM from the compilation and test JVMs, so you can run Gradle on JDK 26 while still producing Java 8 bytecode. About 80% of Gradle 9 users are already on Java 21+, making it a reasonable new minimum floor.

A software engineer reflects on a moment where they let Claude handle an entire bug investigation and fix end-to-end — without ever reading the Sentry issue, the code, or the diff — and only realized it after merging. Claude happened to be correct, but the workflow would have looked identical if it had been wrong. The post argues that AI tools are valuable when they sharpen your thinking, but dangerous when they become a way to skip the cognitive work entirely. The author's new rule: if you can't explain the change, you can't ship it.

Mozilla is rolling out a major Firefox redesign codenamed Project Nova, focused on making the browser feel cleaner, warmer, and faster. Key changes include updated tab shapes with subtle gradients, a refreshed color palette inspired by fire, more rounded and consistent UI components, rebalanced spacing, and updated icons. Privacy features are being surfaced more prominently, including easier access to the built-in VPN, private browsing, and redesigned Settings with plainer language. Performance improvements include a 9% reduction in key page content load times. Productivity features like tab groups, split view, and vertical tabs are more accessible, and compact mode is returning by popular demand. The redesign extends to mobile for cross-device consistency, and new themes and wallpapers are being added. Accessibility — contrast, readability, keyboard behavior, and dark mode — is a core design consideration throughout.

Storybook 10.4 ships several notable features: AI agents can now automatically configure Storybook in complex apps by analyzing project structure, generating mocks, and writing stories; a new sidebar change detection filter highlights stories affected by recent code changes; a quick-share button publishes Storybook to Chromatic for instant teammate review without needing a PR or CI run. The release also adds first-class TanStack React framework support via @storybook/tanstack-react with zero-config routing and server functions, an improved opinionated React Native setup using a standalone entry point, and an experimental react-component-meta docgen analyzer powered by Volar and the TypeScript Language Server for faster, higher-quality MCP metadata.

But still, I did not expect a text editor to knock down my system like that. I still do not know exactly what happened. Maybe it was a Zed issue. Maybe it was a Linux graphics issue. Maybe it was related to the editor trying to index or analyze the project. Maybe it was some unlucky combination of my system, drivers, and the application. But from a user’s perspective, the result was simple: I clicked something in a text editor, my laptop froze, restarted, and then failed to boot normally. That is enough for me. Reliability beats speed After that experience, I uninstalled Zed. This is not a statement that Zed is a bad editor. Many developers clearly like it. Maybe on another machine, another OS, or another project, it works beautifully. But for me, the trust was gone. A developer tool can be experimental. It can have a different interface. It can require some learning. I am fine with that. But it cannot make me worry about whether my operating system will boot after using it. That is where I draw the line. The irony is that one of the arguments against VS Code is often that it uses Chromium. And yes, Chromium is not the lightest possible foundation. It may not be the fastest choice in every benchmark. But Chromium is battle-tested. It is used everywhere, on many systems, by many users, every day. It may have overhead, but it is reliable. And for my day-to-day work, I choose reliability over speed every time. A fast editor that I cannot trust is not faster in practice. What I learned This short experiment reminded me that developer tools are not only about speed. For me, a good editor needs to be: fast enough stable predictable easy to navigate comfortable with large codebases reliable when jumping through functions and files VS Code may not be perfect, and it may not be the most lightweight editor in the world, but it gives me a workflow I can trust. Zed may be faster in some benchmarks, and the Rust/native approach is interesting. But in my real-world test, it did not give me enough benefit to justify the friction. And after the system freeze, the decision was easy. Final thought Trying new tools is important. I installed Zed with genuine curiosity, not with the intention to criticize it. I wanted to see whether the hype around a fast, Rust-based, non-Chromium editor would translate into a better real-world workflow for me. It did not. But the bigger lesson for me was not only about Zed. This experience also made me question Ubuntu on my laptop. I am still a relatively new Linux user, but I have already experienced system crashes more often than I used to on Windows. That surprised me, because I expected Ubuntu to feel more stable and more secure. Maybe the issue was Zed. Maybe it was Ubuntu. Maybe it was a graphics driver, hardware compatibility, or some unlucky combination of all of them. I do not know yet. What I do know is that I do not want to judge the whole Linux experience from one installation. So I will probably create another partition, install another Linux distro, and make Zed one of the first applications I test there. Then I will see how it behaves in a different environment.

I installed Zed because it had been on my radar for a while. There is a lot of hype around it, especially around performance. Zed is supposed to be special because it is written in Rust and does not use Chromium. That sounds attractive, especially when compared with Electron-based editors like VS Code. In theory, it should mean lower overhead, better responsiveness, and a cleaner native experience. So when I came across a larger codebase that I wanted to skim through quickly, I thought this was the right moment to give Zed a try. I was not planning to replace VS Code immediately. I just wanted to test whether Zed could give me a noticeably better experience when browsing through unfamiliar code. After about 20 minutes, I uninstalled it.First impression: yes, it felt fast To be fair, Zed did feel quite fast. I was running my laptop in power saver mode, so I was not even using the full performance my machine could offer. Even then, the editor felt responsive enough. But I did not see any dramatic improvement compared to VS Code Studio. That was my first small disappointment. Not because Zed was slow, but because the performance difference was not big enough to justify the change in workflow. When a tool is promoted heavily around speed, I expect that speed to be obvious immediately. In my case, it was not.I struggled to orient myself The next issue was navigation. When I opened the project, I expected the file structure to be visible and immediately usable. In VS Code, I am used to seeing the project tree clearly, opening files quickly, and understanding where I am in the codebase. In Zed, individual files were not available to me right away in the way I expected. I had to scan the interface and search for where the files were. Eventually, I found a very small icon in the corner that revealed the file view. Maybe this is just a matter of getting used to Zed’s interface, but for me, that first moment matters. When I open a code editor, especially for a large codebase, I want orientation to be instant. I do not want to hunt for the file explorer. Jumping through code did not work Once I managed to open some files, I wanted to move through the codebase. In VS Code, I often use F12 to jump to a function definition. This is one of those basic developer features that becomes part of muscle memory. When you are exploring a large project, this matters a lot. In Zed, I right-clicked on a function and saw the option to go to definition. The menu even displayed F12 as the shortcut for that action. But it never worked. This was not a case where I expected a feature that was not visible. Zed itself showed me that the feature existed and that F12 was the right key to use. But when I tried it, nothing useful happened. Maybe it required additional configuration. Maybe the language server was not ready. Maybe something about the project was not detected correctly. But from my perspective, I installed the editor, opened a codebase, saw the correct command in the menu, pressed the shortcut Zed showed me, and it did not work At that point, the editor was already slowing me down instead of helping me. Then my computer froze After that, I started looking through the menus to understand what else was available. I noticed something that looked related to agentic or AI-assisted work. I clicked on one file, and at that moment my computer froze. Not just Zed. The whole computer froze. I am using Ubuntu 24.04, and the system stayed frozen for around two or three minutes. I could not do anything. Then the computer restarted itself. After the restart, Ubuntu did not boot properly. It started booting, but it never reached the password screen. I had to physically power off the laptop and turn it back on again. Only after that did Ubuntu finally boot. That shocked me. I am a relatively new Ubuntu and Linux user. Coming from Windows, I had assumed Linux would be more stable in this kind of situation. Maybe that assumption was too optimistic.

A veteran software engineer draws parallels between the Extreme Programming movement of the late 1990s and today's generative AI era, arguing that both represent 'rigor relocation' rather than loss of discipline. Just as XP replaced heavyweight processes with tighter feedback loops, and dynamic languages replaced static types with test-enforced correctness, AI-assisted development demands stricter specification of intent and ruthless evaluation of outputs. The core thesis: probabilistic code generation only works when deterministic constraints exist at the edges. Engineers who thrive will treat generation as a capability requiring more precision in specification, not less, and will build evaluation systems that fail loudly when code drifts from intent.

A practical guide on when to use CSS shorthand properties versus longhand equivalents. The core argument is that readability and intent should drive the decision, not brevity. Covers specific properties like background, padding, margin, animation, transition, grid, border, font, and text-decoration, with concrete examples showing when shorthand helps versus when it obscures meaning. Also introduces CSS logical properties as a more resilient alternative to directional shorthands for internationalization support.

A developer explains their migration from GitHub to a self-hosted Forgejo instance, driven by concerns about digital sovereignty rather than reliability. Key reasons include GitHub's absorption into Microsoft's CoreAI division (losing independent leadership), the April 2026 opt-out flip for Copilot training data, and unresolvable US jurisdictional risk under FISA 702 and the CLOUD Act. The post details the technical architecture: Forgejo v15 LTS on a single NUC with Postgres and Traefik, plus a hardened CI runner using KVM isolation, gVisor, weekly destructive rebuilds, nftables egress filtering, and scope-bound tokens. The Dutch government's choice of Forgejo for code.overheid.nl is cited as institutional validation. Honest trade-offs are covered: loss of GitHub's social graph, Actions ecosystem friction, no Dependabot (replaced by Renovate), and lack of enterprise support.