Who is this particular developer

As far as I understand from the discussions about the topic, Maxim Dounin was one of the few core developers of nginx. Looks like Wikipedia has already been updated.

I know you said “self hosted”, but if you are interested in an Android app, Google Play Books does most of what you want, I think. You can upload your books, and read them on any device (with offline capabilities). But this is the Self Hosted community, so I will show myself out.

Possibly. My point is: despite having a common subset Pkl and JSON schema doesn’t seem to be solving the same problems. But, I’m just learning about it, so I may just be wrong.

I just learned about Pkl, so take this with a grain of salt. JSON Schema and Pkl seem to have some overlap. But JSON schema is not specifically designed for handling configuration and Pkl supports other formats like YAML.

This looks really interesting. Getting type safety and editor support to configuration may change quite a bit of how things are done. I don’t know if it will gain traction, but if it does, it may really help bringing some long awaited structure to all those YAML files. There appears to be examples specifically for Kubernetes (https://github.com/apple/pkl-k8s-examples).

I wasn’t aware of that. I guess it was thought to be a mod driven community. Anyway… Cool question. I hope we will see some creative solutions here.

Please also consider posting to !challenges@programming.dev

Please consider posting language specific questions to language specific communities in the future. For example, !c_lang@programming.dev

I would add Ars Technica to that list and call it a day.

For programming I follow YouTube channels of the conferences relevant for my tech stack (YouTube natively supports RSS). They are generally 1 hour talks but it’s a great way to stay up to date.

Thanks for sharing. This looks really low level. The advantage of PlantUml and Mermaid is that they are supported by many systems. So, integration is a non-issue.

I agree that this is a challenge. One needs to slice the domain such that it can be covered this way. But this also means more people. In my experience, moving from “activity oriented” teams to “business centric” teams require an increase of the headcount.

Yeah, I don’t know if it’s a bug or a feature. I got a similar problem before with one of my posts. I think a workaround would be to post it as a link and paste the image in the Body.

https://observablehq.com/@ayhanfuat/the-fall-of-stack-overflow

-1 is what you get back from fork() when it fails. Normally, it returns a pid_t which is positive if you’re the parent, or zero if you’re the child.

-1, when handed to kill() on Linux, means “target every process but myself and init”. Therefore, when you take the return value from fork(), fail to check for an error, and later hand that value to kill(), you might just kill everything else on the machine.

Great story.

In 2014 Robert Martin claimed that number of developers doubles every 5 years and says:

As long as that growth curve continues there will not be enough teachers, role models, and leaders. It means that most software teams will remain relatively unguided, unsupervised, and inexperienced. […] It means that the industry as a whole will remain dominated by novices, and exist in a state of perpetual immaturity.

Not sure if the data can be confirmed or not, but if that’s the case it will be difficult to maintain the best practices in our industry.

And because Windows and it’s eco system of applications he listed gets worse, he extrapolates this to all software.

They admit that bias in the article:

[…] since I’ve always been working in the Microsoft tech stack, I use a lot of it. Thus, selection bias clearly is at work here.

Now, I mentioned free software as the exception. I don’t have any data as to how big free software vs proprietary software. But I think his points extends at least to other proprietary software and is not limited to Windows.

Some software get better, some get worse.

I can agree with that.

I’m not sure it’s that simple, really. And I definitely don’t think this is limited to Windows. I agree with other comments that this is mostly related to complexity. The more complex the domain the more difficult it is to implement/maintain a good solution. Delivering the new shiny feature is more exciting for all people (product management, development, users, etc.) than to fix bugs. And if you don’t have the resources/maturity to keep technical debt under control, the software quality will suffer over time. Free software may be the exception here as profit is not always the primary concern.

I no longer look forward to updates.
[…]
It seems to me that some software is actually getting worse, and that this is a more recent trend.
[…]
Why does this happen? I don’t know, but my own bias suggests that it’s because there’s less focus on regression testing. Many of the problems I see look like regression bugs to me. A good engineering team could have caught them with automated regression tests, but these days, it seems as though many teams rely on releasing often and then letting users do the testing.

The problem with that approach, however, is that if you don’t have good automated tests, fixing one regression may resurrect another.

Every time I see a new update, I think: “I wonder what will break after this update” and postpone them as much as I can. Software updates shouldn’t cause anxiety. But they do these days…

What microservices offers is loosely coupled services with very limited responsibilities and can be replaced easily and without any impact on a running service.

We only get this if we do microservices correctly. That’s more or less the whole point of my comment. In many cases, teams rush into splitting their monolith into smaller chunks and call it a day. Without proper monitoring, orchestration/choreography, service boundaries, tooling, etc. microservices will drag a team into territories where they will lose control.

Unless you somehow believe that the same people writing both a monolith and microservices would opt to write spaghetti code […]

No, I don’t believe that. However, I also don’t believe people who write spaghetti code will start writing better code just because now they are writing smaller components. If the team has good coding hygiene, they will produce good code whether it’s monolith or microservices. But you have a point. If we are talking about components that are 200LoC, it’s more difficult to produce spaghetti (or easier to recover from it). I’m not sure that’s the norm, though.

As a final note: I’m not saying microservices are bad, or monolith is better than microservices. I’m just trying to introduce some nuance. I have been part of a microservices transformation and I think it was successful. But we met with many challenges along the way that were not immediately obvious from the beginning. To quote one of the pioneers of microservices architecture:

Don’t think of adopting microservices as flipping a switch; think about it as turning a dial. As you turn that dial, and have more services, you’ll hopefully have more opportunity to get the good stuff out of microservices. But as you turn up that dial, you’ll hit different pain points as you go. (Sam Newman, Monolith To Microservices)

• Linus Torvalds
• Kent Beck
• Dylan Beattie
• Ian Cooper
• Simon Brown
• Martin Fowler
• Daniel Terhorst-North
• Sam Newman
• Andy Hunt

I think this is a good rule-of-thumb in general. But I think the best way to decide on the correct coverage is to go through uncovered code and make a conscious decision about it. In some classes it may be OK to have 30%, in others one wants to go all the way up to 100%. That’s why I’m against having a coverage percentage as a build/deployment gate.

Most of the time 100% code coverage is just a waste of time.

Good code is code that is easier to change, and microservices are that by design. No wonder microservices end up being better code.

Microservices architecture by itself doesn’t guarantee making anything better. Making services smaller doesn’t automatically make easy-to-understand code. That’s why a lot of companies that didn’t pay attention to what they are doing went from monolithic architecture to “distributed big ball of mud” or “distributed monolith”. Just like any other architecture pattern, for microservices to work, the team needs to make conscious decisions to overcome the challenges specific to their architecture.

We also have a !sql@programming.dev community. Please also consider cross posting it there.

Did you take a look at write freely or other blogging software with native ActivityPub support?

Thanks for sharing this talk. I watched it a few day ago and thought of sharing, but then forgot about it. As pointed out in the video description: “Email is too big to change, too broken to fix… and too important to ignore.” The bit about the first marketing email was interesting (video timestamp) and is relevant for our times.

Recently, I have seen web apps that requires an email address, then does the validation by sending an email to that address and only then allows the user to proceed with registration. That’s probably the only sure way of validating an email. Users may still use disposable email addresses or short-lived aliases. But I think that’s acceptable.

I don’t know what the mods think about your arguments, but I agree that posts that already have a community should be posted on their respective communities and not here. There may be exceptions where certain language/tool related thing may be relevant for a larger audience, but those are probably rare cases.

I use InoReader. Most of the sources I want/need has RSS feeds. For the rest I create feeds using Feed43. I use it daily and that’s how I get news, YouTube videos, Twitter feeds (via Nitter), Reddit/Lemmy posts.

I was upset when Reader was killed. But looking back and seeing what Google has become over time, I think it was for the best. Now we have entire companies that only do one thing: RSS, and they are good at it. If Reader was still a thing, I’m afraid it would have extinguished RSS.

Names matter, and Reader told everyone that it was for reading when it could have been for so much more. “If Google made the iPod,” he says, “they would have called it the Google Hardware MP3 Player For Music, you know?”

This is funny, but I think Reader was a good name. At least it reflected what I want to do with the product.

And it all depends on the problem at hand. Any of those solutions can be acceptable as long as you have a well thought out model.

Good point. However, approaching this problem from “YAGNI” point of view is a bit misleading, I think. If you are not going to need the timestamp, you shouldn’t add it to your code base.

In my opinion, hastiness is the culprit. When a property appears to be a binary one, we jump to the conclusion to use a boolean way too quickly. We should instead stop and ask ourselves if we are really dealing with a situation that can be reduced to a single bit. The point raised by the article is a good example: you may want to record the state change as timestamp. Moreover, in a lot of the cases, the answer is not even binary. The values for is_published may be, “Yes”, “No” or “I don’t know” (and then we will be too quick to assign null to “I don’t know”). Underlying problem is that we don’t spend enough time when modeling our problems. And this is a sure way of accumulating technical debt.

Exactly. Even though one doesn’t need it often, it’s an important tool.

This is how I used it too. Write a test that fails with the “bad” version. Use a script to cherry-pick and run the test. It’s fun to watch it find the first bad commit even though what git bisect does is quite simple.

No, it’s not cheating (unless you are using it to do your homework, I guess). It’s a tool and like any other we learn how to use it appropriately.

But one needs to be aware of other ethical concerns related to using AI generated code. The discussion revolves around companies (OpenAI, Github, etc.) training their models using the code written by people who have not consented use of their code as training data. In some cases, licensing is clear and allows for such use, but in some cases it’s debatable (I’m not that much involved in those discussions, so I cannot provide more details).

When creating software, the value we bring is the understanding of a problem and the ability to ask the correct questions that will bring us to a good solution. In simple scenarios, even a machine can do what we do and we should definitely use the machine instead of spending time on that.

Community is much smaller on this side of the fence, though.

I mostly agree, but there is a risk of overwhelming the new and relatively small communities of fediverse with a lot of links without any comments/discussion. Is there a way to filter the content according to their reddit ratings. That would help fetching more interesting stuff.