I’ve also used .local but .local could imply a local neighborhood. The word itself is based on “location”. Maybe a campus could be .local but the smaller networks would be .internal
Or, maybe they want to not confuse it with link-local or unique local addresses. Though, maybe all .internal networks should be using local (private) addresses?
I just recently started working with ImGui. Rewrite compiled game engines to add support for HDR into games that never supported it? Sure, easy. I can mod most games in an hour if not minutes.
Make the UI respond like any modern flexible-width UI in the past 15 years? It’s still taking me days. All of the ImGui documentation is hidden behind closed GitHub issues. Like, the expected user experience is to bash your head against something for hours, then submit your very specific issue and wait for the author to tell you what to do if you’re lucky, or link to another issue that vaguely resembles your issue.
I know some projects, WhatWG for one, follow the convention of, if something is unclear in the documentation, the issue does not get closed until that documentation gets updated so there’s no longer any ambiguity or lack of clarity.
My open-source, zero dependency JS library for requesting and generating certs with dns01: https://github.com/clshortfuse/acmejs
I only coded for name.com but it is compatible with anything really. Also can run in the browser, which could be useful in a pinch.
Wow, you think Teslas are “Chinese EVs”. You’re literally the first person I’ve encountered to think so. Also why lead into an article with a graphic of the least selling vehicle?
Doesn’t stop it from being misleading.
It’s called “burying the lede”.
In China. But the majority of Teslas are manufactured are in China, and no one really considers Teslas “Chinese cars” or “Chinese EVs”.
Well, I feel misled. The graphic shows a Volvo as a Chinese manufactured vehicle.
Sales of Chinese made EVs in Australia
- Tesla - 46,116
- BYD - 12,438
- MG - 5,928
- Volvo - 3,949
They’re counting Tesla as a Chinese EV.
Pravo
The entire Material Design framework in JS and Web Components in 80kb
https://clshortfuse.github.io/materialdesignweb/components/buttons.html
JS and Web Components are not the problem. Poor design is.
Years (decades) ago it wasn’t uncommon to create self-signed/local CAs for active directory, but it’s really uncommon today since everything is internet facing and we have things like Let’s Encrypt.
It’s so old, the “What’s New” article from Microsoft references Windows Server 2012 which is around when I stopped working on Windows Server. I kinda remember it, and you needing to add the server’s cert to your trusted roots. (I don’t know about Linux, but the concept is the same, I’m sure. I never tried generating certificates, but know all the other client -side stuff. Basically you need a way to fulfill CSRs.)
https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/
What you’d want to do it in Windows is all there, and Microsoft made that pretty easy back then to integrate with all their platforms and services, but I’d caution, do you really want to implement 10+ year old tech?
According to Route Note, which appears to offer a middle-man service for artists, their ranking, as of November 2023, is:
Betrayal implies loyalty.
People actually use Arch, and it’s that popular? TIL.
You wrote:
To mitigate problems caused by DRY fundamentalisms, the “write everything twice” (WET) principle was coined.
I’m listing when and how it was coined with the article that coined it. If you have another source to claim it wasn’t in the fashion I’ve described feel free to provide sources to the contrary. I even sources it from the very Wikipedia entry you shared.
WET is a clear guideline
Again, feel free to provide sources to back up your claim.
Your comment sounds like a weak attempt at revisionism.
Again. Feel free to back up your claims with actual sources. The concept of AHA by Kent C Dobbs, of Angular fame says:
There’s another concept that people have referred to as WET programming which stands for “Write Everything Twice.” That’s similarly dogmatic and over prescriptive. Conlin Durbin has defined this as […]
https://kentcdodds.com/blog/aha-programming
He then goes on to link to the article/blog I mentioned where Durbin states:
Instead, I propose WET programming.
And he goes on to explain this new concept of Write Everything Twice.
If you actually interested in discussion about the debate of DRY/WET/AHA, I’m all for it. But don’t misinterpret or try to change what is already well-written.
Also, don’t throw accusations at people who provide you documentation and proof and then contest while providing absolutely none yourself. That doesn’t sound like any earnest interest in discussion.
WET is not what you think it is, or at least not originally. It’s not some alternative to DRY. It didn’t stand for Write Everything Twice. It stands for Write Every Time. It’s supposed to be a negative way to describe code that isn’t DRY. It’s also abbreviated as “Waste Everyone’s Time”.
Much, much, much later somebody tried to reuse the term for “Write Everything Twice” but talking specifically about the benefits of singular, repeated templating because the abstraction needed to refactor code into “Write-Once” can make things harder to understand. In other words, it creates a chain of pre-required knowledge of how the abstraction works well before you can even work with it.
The irony here is that DRY is not really about code duplication. It’s actually about system knowledge (structures and processes) being clear and unambiguous. Or, applied, you, as a person, not having to repeat yourself when it comes to sharing knowledge. It lends to simpler constructs that don’t need much explanation. The example given of Write Everything Twice is actually being DRY, but they don’t realize it.
Bill Venners: What’s the DRY principle?
Dave Thomas: Don’t Repeat Yourself (or DRY) is probably one of the most misunderstood parts of the book.
Bill Venners: How is DRY misunderstood and what is the correct way to understand it?
Dave Thomas: Most people take DRY to mean you shouldn’t duplicate code. That’s not its intention. The idea behind DRY is far grander than that.
DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system’s knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.
https://www.artima.com/articles/orthogonality-and-the-dry-principle
The article/interview explains more about how DRY is meant to work and even talks about the pitfalls of code generators, which the WET article complains about (React).
The misunderstanding since DRY’s coining is probably because, like natural language, we change meanings we with our environment. DRY became a term people use to blast too much abstraction. But noisy abstractions are not DRY. In response we have a new term card AHA (Avoid Hasty Abstractions), which exists as a counter to what people think DRY is.
The TL;DR is DRY is meant to mean your code should be unambiguous, not some sort of mantra to deduplify your code. Apply its original principles, and follow AHA which should be a clearer safeguard to avoid your abstractions not following DRY.
I think it’s the junior dev blog spam and search results putting them higher.
People who fail to understand the value of peer-reviewed code are just going to copy/paste bad, but popular, code practices.
There irony here is that Stackoverflow was considered a common source of copy/pasted code.
You can use SharedArrayBuffer but honestly it feels like something engineered for one specific purpose (OpenGL).
It would be nice to have shared objects and strings with whatever syntax helps sync locks. You can technically use UTF8 with helpers like TextDecoder, and I could probably sit and write all that logic using Promises, but I’d imagine the amount of data conversion to make it happen would negate the performance gains from multithreading in the first place.
Don’t use JSON for the response unless you include the response header to specify it’s
application/json. You’re better off with regular plaintext unless the request header Accept asked for JSON and you respond with the right header.That also means you can send a response based on what the request asked for.
403 Forbidden (not Unauthorized) is usually enough most of the time. Most of those errors are not meant for consumption by an application because it’s rare for 4xx codes to have a contract. They tend to go to a log and output for human readers later, so I’d lean on text as default.