Programming

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

More npm fun.

I'm at a relatively stable point in my life (working part time, financially stable), so I'm thinking about trying out as a freelancer, but just casually to start out and see if I like it. I'm curious how people get started - primarily, how to find work and connect with people who have available work and are willing to hire.

Other things to have in place before getting started (professional website, portfolio, other things) would also be helpful to know, but since I'm pretty casual about trying this out, I would hesitate to do additional stuff unless it's really important and makes a serious difference in obtaining potential clients.

Thanks in advance!

Soo I'm working on a database that needs to support multiple languages (two for now, but who knows). I stumbled across this blog post that explains how to develop what it calls a "translation subschema" (haven't seen it called like this anywhere else so I don't know if it's actually how you'd call it), which seems like a very nice way of dealing with things.

I'm not very experienced with DB stuff, so it took me a while to fully understand what it was doing, but now that (I think) I do, I'm wondering if I could just ignore the Languages table, and just use a language field in the tables TextContent and Translations, without loosing any functionality. (except of course having a table listing the available languages, which is not however something I'm interested in)

In my head everything would still work, I'd insert stuff with

INSERT INTO TextContent (OriginalText, OriginalLanguage)
VALUES ("Ciao", "it");

DECLARE TextContentId INT = SCOPE_IDENTITY();

INSERT INTO Translations (TextContentId, Language, Translation)
VALUES (@TextContentId, "it", "Ciao");
INSERT INTO Translations (TextContentId, Language, Translation)
VALUES (@TextContentId, "en", "Hello");

and given a TextContentId, i'd retrieve the correct translation with

SELECT Translation FROM Translations WHERE TextContentId = TCId AND Language = "en"

At this point, I'm thinking I could drop TextContent too, and just have a Translations table with TextContentId, Language, and Translation, with (TextContentId, Language) as primary key.

Am I missing something? I'm trying to simplify this solution but I don't want to risk making random errors.

Edit: translations on the DB are for user inserted text, which will also provide translations. The client then will only receive text it the correct language.