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?
Actually, avoid using PNGs at all if you can.
👀
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.
When PRs begin with a headline and checklist the GitHub hover-preview becomes useless. When the PR description begins with the summation of the change, it is very useful.
Most of the time I see headlines and check lists in tickets I create or contributions I create PRs for, I feel stifled and like I have to produce something very inefficient or convoluted.
The worst I have seen is when, at work, I had to create bug tickets for a new system in a service desk to a third party, and they had a very excessive, guided, formalized submission form [for dumb users]. More than once, I wrote the exact same thing three times into three separate text boxes that required input. (Something like “describe what is wrong”, “describe what happens”, “describe how to reproduce”.) Something that I could have described well, concise, fully and correctly in one or two sentences or paragraphs became an excessively spread, formalized mess. I’m certainly not your average end user, but man that annoyed me. And the response of “we found this necessary” was certainly not for my kind of users, maybe not even experience with IT personnel.
At work, I’m glad I have a small and close enough team where I can guide colleagues and new team members into good or at least decent practice.
Checklists can be a good thing, if processes can be formalized, can serve as guidance for the developer, and proof of consideration for the reviewer. At the same time, they can feel inappropriate and like noise in other cases.
I’ve been using horizontal line separators to separate description from test description and aside/scoping/wider context and considerations - maybe I will start adding headlines on those to be more explicit.
I’m a bit confused, because MDN ::after says in the accessibility section:
Using an ::after pseudo-element to add content is discouraged, as it is not reliably accessible to screen readers.
which contradicts the article saying ::after content gets included as per spec. They conclude though with
While it’s good and certainly useful that we can now provide alt text for CSS generated content, I do not recommend using CSS to insert meaningful content into the page.
Not only will some of your screen reader users miss meaningful information when the alt text is not announced by their screen reader (looking at NVDA with Chrome 👀), but there are also other reasons why inserting meaningful content in CSS is not yet recommended…
so I assume it’s a spec vs real world thing.
If you want a teaser what this is about, the / content syntax for screen read representation (to evade misrepresentative emoji translations, for example).
::after {
content: " \2197" / "Opens in a New Window" ;
}
They also talk about image alt text and ::after url.
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 don’t know what you’re looking for, and what your “not super simple” is, but baseline browser tech provides various controls, layout mechanisms, styling, interactivity, etc.
Do you have a concrete idea of what and where specifically you hope for gains by using frameworks? Do you plan to hold a lot of state on the client that needs state separated from the DOM and its mechanisms? Do you want a standard library of styled components instead of using the native ones or styling them yourself? Do you want more robust JavaScript? Those are all very different concerns and requirements.
I like the low complexity, low barrier, low requirements of baseline web tech. The native html form controls may arguably look “ugly”, but those can be styled, individually or through a style-only CSS lib.
The most future proof web tech is not using frameworks and libraries at all.
Render native HTML controls.
I also assume it’s lower barrier than any of the libs and frameworks you could use, which is always a subset of web tech with the addition of their own concepts.
Tailwind is an example of those frameworks fighting against/crossing the native web technologies referenced further up with the links to webdev posts.
The idea of shifting CSS declaration into the DOM element class attribute seems flawed to me. You lose what CSS provides natively.
If you don’t care too much and don’t have experience yet, why not go for native browser and HTML/CSS/JavaScript?
Even if you eventually migrate to other web UI libs and frameworks, the foundations knowledge will be useful.
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?
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.
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.
That webpage certainly blinds me like a surgeon’s light would /s 😏
This service has been suspended by its owner.
This is all I see on the linked webpage.
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.