Now if only I had the motivation and commitment to create something similar!

Godot is certainly the easiest and simplest to install in terms of full engine and game dev IDE.

Whether they wanted to showcase or deliberately chose it for how it looks or not, I think the simple install onto a presentation desk/PC/Steam Machine may have been a reason as well.

I regularly write code.

My customer gave the go-ahead to use LLM in our project very recently. We’ll be trying it out. I’m interested to scope out its use and limitations especially. I’m skeptical it will increase efficiency for me overall. The project is too complex, my/our requirement on quality too high, and I’m thorough to the last var name and code formatting for readability and obviousness. I’m not sure whether I could find it acceptable to compromise on those.

Between customer communication, planning, review-prep, guiding and helping my team members, and doing reviews, and other tasks within the company, time for my own work can be reduced by a lot. Still, I have tasks I work on, and that includes coding.

Microsoft pushes cloud and AI with increasingly negative side-effects. Eventually, EU regulation steps in to require offline-capable OS with fair and obvious choice. Microsoft tries to argue security, but ultimately fails.

Microsoft continues to push and connect their services as one, with synergy effects. Eventually EU regulation and prosecution steps in, requiring a neutral OS that must not pre-install software or point to other products in OS settings and apps, etc. Integrations must be openly standardized first, before implementing their own.

Despite all this, and despite a move from EU and EU-national institutions to sovereignty through shared open source solutions, Microsoft retains their strong/prevalent market position because the market as a whole is not as strategic and concerned, and Microsoft products like office, onedrive, Teams, and their other business software and services remain a predominant and grab-first choice, and the security promise of big enterprise software, battle-tested, with strong established auth etc remains a big selling point for them.

At work, I set up convco for automated commit checks and changelog generation with custom/slightly adjusted configuration of conventional commits (types) and changelog template.

Does it float because it’s a balloon cat or because of the jetpacks? 😸

A lot of them look (very) interesting. Now I have a bunch of tabs open to sift through.

How does JPlus handle compile time null checks against Java library interfaces? Does it consider them all nullable and to be handled as nullable?

If nullability information is a type metadata extension for compile-time checking, does that inevitably break on library interfaces when I create both library and consuming app with JPlus?

That’s wild

😏

The plan is to eventually make it incremental, however that isn’t yet implemented. It is however already pretty fast even without incremental linking.

Not stable yet, either:

The following is working with the caveat that there may be bugs:

I prefer round[ed].

Think of it as a rounded square with a unique, pleasant shape.

I don’t find them pleasant. I find them irritating.

Rounded square makes use of the space it reserves/square-fills. Squircles seem wasteful and confusing. They do not represent any common physical shapes, and waste/discard space they could use. They look like an old CRT.

R1dacted: Investigating Local Censorship in DeepSeek’s R1 Language Model

Quoting from the abstract:

While existing LLMs often implement safeguards to avoid generating harmful or offensive outputs, R1 represents a notable shift—exhibiting censorship-like behavior on politically charged queries. […]

Our findings reveal possible additional censorship integration likely shaped by design choices during training or alignment, raising concerns about transparency, bias, and governance in language model deployment.

Invidious says video unavailable

I use GitLab diffs in single-file-view mode, TortoiseGit Merge when it exceeds what GitLab can reasonably display (including block indent changes I can ignore in TortoiseGit Merge or moves I can better track), and WinMerge (previously I used KDiff) for manual copy-paste text diffing (like copying blocks from the code change diff to compare similar, categorically similar code, or code moves, etc)

I prefer this one from two months ago https://www.youtube.com/watch?v=HkgV_-nJOuE

What kind of tech and project did or do you use it on?

The section in question: Method Length

Dependency injection has significant upsides, but the indirection also has significant downsides for direct readability and traceability. Suddenly, you separated definition and call into distanced registration and use, with magic indirection that may or may not use various lifetime behaviors or proxying and wrapping or later replacement on types.

I’ve tried reading (and fixing) a library that made excessive use of DI, and it was very hard to follow or get into.

I created a Nushell plugin in Rust that merely converts between Nushell and BSON data formats.

It works, but I still have a fundamental lack of understanding of the magic abstract generalized data transformation framework/interface.

I wish there were fewer magic conversions and transformations, and less required knowledge of them and calling or knowing the correct ones. Magic traits leading to magic conversions for magic reasons. Or something.

While I agree with the later (or middle?) points, maybe for different reasons or maybe I would have reasoned differently, I mostly disagree with the earlier points.

Any really important comments get lost in the noise

What kind of comments are they using?

When I leave comments on GitLab they’re threads that get resolved explicitly. GitHub also uses resolvable threads. The assignee/creator goes through them one by one, and marks them as resolved when they feel they’re done with them. Nothing gets lost like that.

I also make use of ‘⚠’ to mark significant/blocking comments and bullet points. Other labels, like or similar to conventional comment prefixes, like “thought:” or “note:”, can indicate other priorities and significance of comments.

Instead of leaving twenty comments, I’d suggest leaving a single comment explaining the stylistic change you’d like to make, and asking the engineer you’re reviewing to make the correct line-level changes themselves.

I kinda agree, but I often leave the comment on the/a code in question, and often add a code change suggestion to visualize/indicate what I mean. This comment may stand in and refer to all other occurrences of this kind of thing. It doesn’t have to apply exclusively on those lines.

Otherwise you’re putting your colleagues in an awkward position. They can either accept all your comments to avoid conflict, adding needless time and setting you up as the de facto gatekeeper for all changes to the codebase, or they can push back and argue on each trivial point, which will take even more time. Code review is not the time for you to impose your personal taste on a colleague.

I make sure that my team has a common understanding of, and the comments adding sufficient context/pretext to make it clear, that code change suggestions and “I would have [because]” are usually or in general can be freely rejected, unless specified otherwise. Often, comments include information of how important or not changes are to me, in comments themselves, and/or comments summarizing a review iteration (with a set of comments). The comments can also serve as a spark for discussion about solutions and approaches, common goals or eventual goals of the changed code that may be targeted after the code changes currently under review.

Review with a “will this work” filter, not with a “is this exactly how I would have done it” filter

I wouldn’t want to do it like that, specifically. It’s a question of weighing risks and medium and long term maintainability vs delivery, work, changeset, and review complexity and delay. Rather than “will this work”, I ask my self, “is this good enough [within context]”.

Leave a small number of well-thought-out comments, instead of dashing off line comments as you go and ending up with a hundred of them

Maybe I’ve had too many juniors to get into this mindset. But I’ve definitely had numerous times where I did many comments on reviews, even again on successive iterations. Besides reviewing the code technically, the review can also serve as a form of communication, assimilation, and teaching (project an codebase at hand, work style, and other things).

It’s good to talk about concerns, issues, and frustrations, as well as upsides of doing so and working like that. Retrospectives and personal talks or discussions can help with that. Apart from other discussion, planing, and support meetings, the review is the interface between people and a great way to communicate.