Ephera

I write sheet music with Lilypond: https://lilypond.org/text-input.html

Apparently, the whole argumentation is kind of daft and making wrong assumptions: https://programming.dev/post/57383912/26317185

Yeah, I always tell people the fundamental problem with comments is that they’re only visible in one place. Method/variable name, log outputs, error messages, docstrings all show up in at least two places, which makes them more valuable in general, but also makes it more likely for them to be read+updated.

Yeah, I was gonna say, just a bunch of Markdown files would probably be fine. Use e.g. mdBook if you want a static webpage with search.

A dedicated service might have some advantages, but personally, I’d care much more about having my recipe collection in a format that I can access without specific software.

I’ve never seen any search engine officially confirm this, but search across all search engines became terrible just a few months after the release of ChatGPT.
Which is why my assumption is that LLMs are being used to generate heaps of credible-looking, but ultimately worthless webpages. And search engines have to try to filter those out or their results would be even worse.

But then there’s no obvious distinction between a human-crafted blog and some spam webpage, which means the human-crafted blog is likely to be caught in the crossfire and get filtered as well.

Well, and on top of that, search engines presumably got hit by AI scrapers looking for training data, so that’s why I would assume, they now limit the search results to one page…

Ah yeah, that makes more sense, thanks!

Anyone using the national domain registrar? Does it only resolve nationally, if you buy from there, as the article implies…?

But you want your domain over the world. Cool, do you have enough clients to need this? Then you can hire a person in each country to buy you a domain from the local registry.

I’ve been interested in getting a domain name, but it always just felt like a scam to pay a monthly fee for an entry in a database. If the national registrar is good enough, that would be cool.

Although, I guess, if it is not, I’d at least still be somewhat more at peace with that, since it would mean the intermediate company actually does something…

Depends on the data you want to store and what you want to do with it. I haven’t used either MongoDB or Redis in particular, but MongoDB (or e.g. CouchDB) is a document-oriented database, whereas Redis/Valkey is a key-value store.

Superficially, these are similar kinds of databases, in that you have a key and store a value. But document-oriented typically enforces the format somewhat, like e.g. some JSON format, which is then used for doing indexing, aggregation, search or whatever in the database.

Meanwhile, a key-value store does not care what data is actually stored inside. It can literally be just some bytes. You tell it the key and it tells you the data you previously stored, and that’s all you do with it.
I wouldn’t be surprised, though, if Redis doesn’t fit that definition 100% and actually has some optional document-oriented features as well.

From your very short description of what you want to do, my intuition would be more towards document-oriented, because the indexing is presumably essential for a search engine.

But as someone else already said, MongoDB is proprietary now, so probably want to look for an alternative. Selecting the database is worth spending some time on, since the right database might already bring along the search capabilities you want.

I also want to throw in a third type of database that you should probably look into: https://en.wikipedia.org/wiki/Graph_database

Graph databases are good at storing relationships between entries, which you will have a lot of, given each webpage links to other webpages. I believe, the big-boy search engines do use graph databases.

Redis is apparently open-source again, now under AGPL (and two other proprietary licenses). But yeah, can also recommend the fork that spawned when they went proprietary: https://en.wikipedia.org/wiki/Valkey

And not just thinking, it actively imposes an architecture onto your codebase. It pretty much forces a CRUD API, which only really works well for a client-server structure. And it forces you to break up your data structures and introduce IDs to a degree that you would simply not do while programming normally.

I mean, I can see the appeal. If these constraints are fine for you and you don’t have other constraints, like sparse data, then building your whole application on top of SQL gives you clear answers for how to architect that.

But yeah, I also really resent this idea that it should be the default, because when it does not match the problem domain, you spend a lot of time working around the architecture that it imposes.

Yeah, it sounds really abstract until you see that summation example. Then it’s suddenly really obvious…

I feel like a big problem is that LLMs only produce previously learned logical patterns, they don’t do logical reasoning of their own. And code review was always bad at catching logic bugs as well.

As a result, even with us diligently doing code reviews at $DAYJOB, we have more logic bugs than I have ever seen in any codebase before.

I’ll spend three weeks discussing an existing feature with other devs and fixing up logic bugs before we realize that the entire feature is conceptually illogical and needs to be removed/replaced.
This has happened twice for me in the past three months, which should tell you a lot about how much time is wasted here.

TL;DR: I feel like we need something different than code review to catch these logic bugs. Maybe more of a presentation of the feature implementation to the other devs, and then a discussion of that.

Yeah, I didn’t even include technical debt into my list, but it comes up so often as well. Chances are someone else already saw the problem, considered fixing it, then saw the mountain of technical debt blocking a fix, and decided to ignore the problem in the end.

For me, thankfully, folks have been understanding so far, when a bug fix takes significantly longer than expected.
But we also explicitly don’t estimate bug fixes upfront, because of what you say. You have to diagnose the bug to figure out what solution is required. And the solution can range from a one-line-change to a refactoring of half the codebase. Good luck estimating that…

I feel like many bugs in the wild just come from business processes slowing everything down, especially in larger companies. It might seem like a bug that can be fixed in half an hour, if anyone spotted it, but instead:

1. they need to file a ticket
2. it gets discussed in planning, but postponed because there’s an extremely important™ deadline (repeat this step like 5 times)
3. someone from upper management notices the problem and sends an angry mail; it is finally included into the sprint
4. they implement the change
5. it gets rejected in code review due to some nitpick
6. they fix that nitpick
7. it passes code review and is merged onto main
8. it gets discussed again in sprint review
9. it gets shipped two months later
10. ah crap, something broke; need to bisect a few hundred commits to find out it was this change that broke it
11. spend half a day preparing and testing a hotfix release, because the next proper release is months away
12. it gets rejected in code review due to some nitpick
13. …you get the idea.

You go through that slew of bullshit exactly once before you learn to turn a blind eye to anything that looks easy to fix.

I always have to open catbox.moe videos in the browser. For whatever reason, they won’t play in the app (Jerboa in my case).

Hehe:

Not hehe:

Yeah, computationally intensive stuff is going to be slow when implemented in Python. You will find lots of data science libraries for Python that do computationally intensive stuff, but they’re then generally implemented in C/C++ or Rust, with only a thin API layer written in Python.

“Oven is going to be a grind, especially the first nine months or so. If work-life balance means a lot of time spent not working, it’s probably not a good fit.”

Oh man, someone here recently shared a blog post on startup culture in software companies, which likened software to an oven, where you’d add a specific button for a customer and that fucks up your whole architecture for years to come etc…

For just a moment, I thought this was a direct quote from that blog post.

Looks like a typo: !datahoarder@selfhosted.forum

df only shows partitions, whereas du adds up the file sizes in the directory you specify.

So, in particular, if you want to find out what’s taking up so much space, you can repeatedly run du -sh * and cd into the largest directory.