Programming

cross-posted from: https://lemmy.zip/post/49954591

"No Duh," say senior developers everywhere.

The article explains that vibe code often is close, but not quite, functional, requiring developers to go in and find where the problems are - resulting in a net slowdown of development rather than productivity gains.

Then there’s the issue of finding an agreed-upon way of tracking productivity gains, a glaring omission given the billions of dollars being invested in AI.

To Bain & Company, companies will need to fully commit themselves to realize the gains they’ve been promised.

"Fully commit" to see the light? That.... sounds more like a kind of religion, not like critical or even rational thinking.

cross-posted from: https://feddit.org/post/19584461

This might not be obvious at first, but it is not only relevant for individual open source contributors, but highly relevant for any companies which sell open-source based software, or any other software, or software-based devices to with in the European Union: In future, they will have to guarantee the security of their products, regardless of which software supplies they use.

As long as a project is not organized as a legal or commercial entity, the CRA requires only a basic "readme" with a security contact. There is no legal risk for individual contributors simply sharing code online or in publications, even when they receive payment for writing an article, as long as the software itself is not monetized or organized.

[ ...] the CRA's focus is on commercial manufacturers and distributors. That means businesses that integrate open source code into EU products must fully comply with documentation, incident response, and lifecycle management requirements. This includes publishing Software Bills Of Materials (SBOMs), patching vulnerabilities within regulated timeframes, and responding proactively to security incident reports.

[...] manufacturers must act on vulnerabilities, even if the upstream maintainer does not fix the issue. Manufacturers selecting open source code for their products must understand the code, support it, and respond to regulatory reporting requirements. This may, Kroah-Hartman observed, increase pressure on companies to use actively supported open source projects or stick closer to mainstream, well-resourced communities."

[...] it's coming soon for companies. Manufacturers are going to care in September of next year. They're going to start panicking in the summer of next year, and things are going to start hitting the fan."

They'll want developers to shoulder the burden the CRA will place on them. But you don't have to do that. It's their problem, not yours as a programmer.

The overworked maintainers of Libxml2, ImageMagick, or contributors to such industry-wise important things as the real-time kernel patches, might enjoy to read this.

Practical example: Libxml2 is not a for-profit project with a sole unpaid developer as a maintainer. Its future license is GPLv3, so it is free to use for Linux users. But if, say, Apple continues to use libxml2 in products they sell, they have to provide security fixes (and, because of the license, they have to provide the fixes back to the project because it is GPLv3). It is not the responsibility of the libxml2 project to develop the fixes, because they are not selling a commercial product: The buck stops at the companies using it.

What are you working on? Any new ideas that you're thinking about?

https://archive.ph/2025.09.29-131013/https://www.404media.co/how-ruby-went-off-the-rails/

Context: Searching for a new senior level software development job over a 9 week period in summer 2025.

• Focused mostly on data engineering and backend roles that are in-person or hybrid in the SF Bay Area.
• Leads from recruiters on LinkedIn were much more likely to lead to interviews+offers.
• The winning offer came through my personal network.
• I mostly used Hiring.cafe for prospecting. They're a scraper with an interface I didn't hate.

Found this article interesting. Some (technological) highlights for me:

She initially wrote simple Python scripts to help with chain-of-custody problems. Those scripts worked on her machine, but she had trouble delivering the software to the people who actually need it.

Yeah, Python, Java etc. are quite portable in theory, but we also always ship the runtime along with it at $DAYJOB, because we don't want to deal with different runtime versions and users failing to install them properly. And since the runtime is compiled for specific platforms, we effectively have non-portable artifacts anyways.

Deuson's first attempt at distributing her software was to bundle it using Kubernetes. That sort of worked, but it turned out to be hard to get it installed in police departments. Opening ports in the firewall is also often prohibitively hard. "Getting software into these environments is really difficult."

Eventually, she decided that the only way to make this work would be to write a single, standalone executable that does everything locally. It would need to be able to run on ancient desktop computers, in a variety of environments, without external dependencies. That's why she ultimately chose Rust to write FolSum.

I feel like our industry poured tons of effort into making things deployable via Kubernetes, but there's still an absurd amount of niches, where this just does not make sense. Always interesting to hear about yet another such niche...

One thing that users really liked about the Rust version of the application was that it starts quickly, she said. Lots of commercial software is big and bulky, and takes a while to start up, leaving users staring at splash screens. FolSum starts up almost as soon as the user releases the mouse button.

Yep, I never quite buy it when this is deemed unimportant in commercial software development. The chance of your software running all the time is really low. And if it's not running all the time, I need to start it before I can use it. If I need to wait a minute for that, that takes me out of my workflow and I'll kind of hate your software for it.

It turns out that non-technical users like the approach that she has called "GUI as docs", where the application puts the explanation of what it does right next to the individual buttons that do those things. Several users have told her that they wished other software was written like this, to her bafflement. For-profit software is often a forest of features, which makes it hard to find the specific thing one needs, especially if the tool is only rarely used, she said.

I've been looking to take that kind of approach for our GUI at $DAYJOB, too. Our software is not either something that users use all the time. They might not look at it for months at a time. It's ridiculous to assume that they will remember all the concepts, just as ridiculous as it is to expect them to look at a completely separate manual every time. So, just dotting help texts around the place seems like a good idea.

This video complements the text tutorial at https://trevors-tutorials.com/0011-creating-and-loading-tilemaps-using-ebitengine/

Trevors-Tutorials.com is where you can find free programming tutorials. The focus is on Go and Ebitengine game development. Watch the channel introduction for more info.

cross-posted from: https://piefed.social/post/1302658

PostgreSQL 18.0 Released With Async I/O, Performance Improvements - Phoronix

I found the https://jeffhuang.com/designed_to_last/ also good. Wondering what can auto-create the different formats for long form blog posts?

CLI Workout logger.

Features:

• Track exercises with customizable types (weight, time, bodyweight)
• Log workouts with sets, reps, weight, time, and notes
• View workout history by date range or specific criteria
• Use shortcuts for quick and efficient workout logging
• Remove or update exercise and workout entries
• Display workout data in clean, tabular format
• Configuration management
• Import and export your fitlog data

A learning project created to lean the basics of C language.

I’ve been working full time as a frontend developer for about 3 years now. I also have a bachelors degree in computer science.

I really feel like I leveled up this past year, and I wanted to share two things that stand out to me that I learned.

Keeping git work organized

It doesn’t really matter how small/large your commits are, but what matters is keeping it focused. Write a good description for your commit and don’t make unnecessary changes that aren’t related to the commit message. If you see something unrelated that needs fixing, don’t mix it in with your current work. Same goes for pull requests, which I always squash commit.

The goal is if you want to revert your commit/squashed pr later, it should only revert what’s described in the commit message. It will cause problems if the revert also brings a bunch of unrelated changes.

When to abstract

There’s a lot of opinions about DRY or WET code bases, but I think that’s confusing. When you have A and B, and you’re wondering if you should bract the shared code (let’s call this shared abstraction C), ask yourself this. Do I want it so a change to C affects A and B, or do I want changes to A to not affect B and B not to affect A?

It’s like your building knobs/dials into your codebase, and it’s up to you if you want a single dial to affect one thing or multiple things. You know you built the right dials when product asks for something later, and it’s as simple as turning the dial you created.

On the other hand, if you build something as two dials that should have been one, you may find you turn dial A and forget to turn dial B. This sounds simple, but your codebase may have thousands and thousands of dials, so the right consolidation can help with managing large projects.

In summary

Idk if that made any sense, but as I progress in my career, I’m finding I’m able to manage larger projects with less overwhelm.

Pijul is a free and open source (GPL2) distributed version control system. Its distinctive feature is to be based on a theory of patches, while still being fast and scalable. This makes it easy to learn and use, without any compromise on power or features.

Why Pijul

Pijul is the first distributed version control system to be based on a sound mathematical theory of changes. It is inspired by Darcs, but aims at solving the soundness and perfor>mance issues of Darcs.

Pijul has a number of features that allow it to scale to very large repositories and fast-paced workflows. In particular, change commutation means that changes written independently can be applied in any order, without changing the result. This property simplifies workflows, allowing Pijul to:

• clone sub-parts of repositories
• solve conflicts reliably
• easily combine different versions.

The main difference between Pijul and Git (and related systems) is that Pijul stores changes (or patches), whereas Git deals only with snapshots (or versions).