This is probably not the correct place to as this and I don't know the inner workings of Lemmy, so forgive the stupid question. Does that mean, for an external post to get a programming.dev ID does someone in programming.dev instance to have been subscribed to the community the post was originally shared? Is that why I don't see any posts at for example https://programming.dev/c/testbot42@voyager.lemmy.ml even though I see them at https://voyager.lemmy.ml/c/testbot42? If that's the case, it sounds like an important limitation.

That's a great idea.

I meant using the debugger.

Well... I didn't say "you shouldn't debug", I said "[i]f you find yourself debugging a lot [...]". Debugging is a tool in our toolbox and we should use it whenever it's necessary. But if it's something we do too often, it may be an indication of a code quality problem (a bad smell, if you like).

I think the video description does a good job of summarizing it.

In Object-Oriented Programming, objects are instances of classes and they encapsulate behavior and state - that is what every textbook on OOP is teaching. However, there's a subtle limitation in OOP when it comes to dealing with changes in the state of these objects. We often try to mitigate that limitation by applying the State design pattern, but that adds extra complexity and potential confusion to downstream components, especially when using Object-Relational Mappers (ORMs).

In this video, you will learn to recognize the fundamental limitation of Object-Oriented Programming and how Functional Programming (FP) offers an inverse perspective. Through immutability and transformations of values, FP tends to make state transitions explicit and predictable, leading to a more straightforward way of handling the issues that would otherwise be too large a burden for a corresponding object-oriented model. This requires a shift in thinking and can introduce its own challenges and learning curves. It is a fascinating topic, shedding light on the fundamental underpinnings of OOP and FP, and their practical implications in software development.

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.

Aaaaand that was the end of it:

Thanks. That helped. I got Paul now. The suspense is killing me :D

It's correct that rebase rewrites history, but it's important to identify when it's not acceptable. If you are working on a branch that is shared by others (typically main), you should never use rebase. But it's an acceptable practice when used properly. I use rebase on my feature branches whenever necessary. If it fell behind the main branch I do git fetch followed by git rebase origin/main, resolve the merge conflicts and keep coding. I also use interactive rebase when I need to tidy things up before merging the feature branch to main.

In this conference talk, Evans explains some of the most important concepts related to Domain-Driven Design while taking a critical look at how we traditionally think about models. Suggests asking "which model would be more useful to solve this problem" instead of relying on our understanding of objects "in real world". He also emphasizes the importance of communication with domain experts an use of ubiquitous language.

Yeah, I use that one as well.