It needs to be closer to where the acronym is first introduced. The definition, on my screen, is below the fold so it can not be seen in context of where the acronym is first introduced. If it was defined below the title, I would understand.
This is a somewhat useful feedback, however I am not too sure how this can be fixed given the structure of my blog post. Do you think if I just add a line `*WSC is short for Windows Security Center` in the first paragraph this will be enough?
In this post I will briefly describe the journey I went through while implementing defendnot, a tool that disables Windows Defender by using the Windows Security Center (WSC) service API directly.
Or use the abbr (and its title attribute) that was designed for that purpose; no extraneous "flow" breaking required. Mobile people can long press on the indicator to read more, everyone who magically knew what WSC gets to continue to know what WSC means
The typical solution, is to include the expansion in brackets after the first use.
Simple rule I learned on my Electronic Engineering degree (where we're guilty of many, many acronyms): When you write an acronym/initialism in a paper (or anywhere for others to read reall), assume the reader doesn't know what it stands for and include the expansion in brackets immediately after the first use.
EDIT: As my sibling comment also suggests, writing it in full the first time, and using the acronym/initialism in brackets is also acceptable.
I hope articles like this can at least provide some hints when the size of a flatpak store grows without bound. It is definitely more involved than "it bundles everything like a node_modules directory hence..."
> Even when a cartridge does contain data on day one of release, games are so often patched, updated and expanded through downloads that the cart very often loses its connection to the game, and functions more like a physical copy protection dongle for a digital object
From preservation's perspective even the day-one release, no matter how buggy it is, is worth preserved. The speedrun community, for instance, often need to fix on an exact version of the game to compete, and a physical copy (implying a pinned revision) is often easier to agree on.
There are exceptions to this, when the day-one release is not playable. It is the trend happening in the software industry -- release early, even if it is literally unusable, because we can push a patch via the network -- that is disheartening.
This was the one I was taught in my high school. It has some cleverness (e.g., some trig. transformations) but looks less like coming out of nowhere than the original.
In the scenario I propose, 200 is less than the 400 requested, so it's incomplete. The cache is permitted to retain the smaller request, and return bytes that fall exclusively within, but like I said, I don't think it's free return 200 octets when 400 are requested. If it was why would it make the other statements?
I do think the cache is allowed to retain, and respond for the 200 bytes. I don't think it's free to ignore the header updates, nor do I think it's free to return half the requested bytes in lieu of extending the existing cache.
That's irrelevant. Otherwise, requests for 400 bytes against a resource that is actually only 200 bytes long would never be considered complete and would be disallowed to be cached.
That's the Go approach, where every value is zeroed so it makes sense for enum values to have a 'none' or 'other' or 'unknown' value as the first value.
(note that Go doesn't have enums as a language feature, but you can use its const declaration to create enum-like constants)
It is, but that's the reality of today - auto-updates, "evergreen" releases. This was popularised by Chrome, and IMO fixed a LOT of headaches and allowed for much faster and more agile release cycles - the reality before was that a company like Microsoft would have to provide support for older versions of their software for X years and deal with the fallout of security issues with remaining older versions. (Web) developers had to be careful about adopting newer features because X% of their user base would still be on older versions of the runtime, leading to the invention of transpilers and the start of what is still a very complicated system in web front-end world.
