Too bad Pixel support for factory-broken screens sucks so my "well designed" Pixel has green vertical line in the middle of the screen. So detrimental to my sense of aesthetics.
For example, naming some application modules strictly after what they do is super tedious, and uses words that are already reserved, therefore creating ambiguous nomenclature. Maybe I have various sort of permissions in my system but naming that particular permission system some greek god name creates a clear and shared meaning across the team (both business and technical), and mind you that that's what communication is all about - a shared meaning. Nothing else.
P.S. (I'm deliberately not going into discussion about bad things with that approach)
> Dollar General’s lawyers argued that “it is virtually impossible for a retailer to match shelf pricing and scanned pricing 100% of the time for all items. Perfection in this regard is neither plausible nor expected under the law.”
Can you explain to me how USA is called civilized? How somebody can say things like that, and how a shop is even allowed to have an error margin
All told, 69 of the 300 items came up higher at the register: a 23% error rate that exceeded the state’s limit by more than tenfold.
This implies that an error rate of perhaps 2% would be legal. I haven't checked, but I guess Europe has something similar even though I'm quite certain that retailers have to sell things at the posted price if there's a mistake.
Part of the problem seems to be that the maximum fine (at least in the state in the article) is "too low", so retailers don't have an incentive to keep price tags correct since they profit from the error and even if they're fined it's still better (economically) for them to charge more than the price tag. I wonder how much lobbying has happened to keep fines low ...
The interesting question would be how many products came in lower, but sadly the article doesn't include that.
If 23% were higher and 23% were lower then you could make a reasonable argument that it's just incompetence from the store.
But if 23% are higher and none are lower, then that looks a lot more like malice - because the odds of you happening to have a 23% error rate than just happens to always work out in the retailer's favour are basically zero.
I worked in retail for a few years. A very large part of my job was simply keeping physical paper price tags in sync with the database. Minimum wage employees in a back office manually keying in UPCs, etc. The claim is extremely accurate in my experience.
Expecting physical reality to synchronously conform to a policy in an information system is pretty silly.
You have it backwards. Building a flexible system and constantly changing pricing database without regard to how to physically update prices in the store is the silly thing.
And when the mismatch tends to be in the stores favor, then maybe it isn’t silly but malicious.
> Building a flexible system and constantly changing pricing database without regard to how to physically update prices in the store is the silly thing.
If corporate had to wait until every store signaled "all clear" on paper tags, most retail businesses would go bankrupt in record time. The margins are not fat enough to run things this slowly.
What's the point of bundling libraries? Bundling applications, ok, but libraries? Unless they are dynamically imported straight into browser, then it doesn't matter for any use case I can figure.
For node applications, startup time is impacted by IO a many files is less nice for IO wait times. So bundling does make a material impact for non-bundled backend applications and large libraries. I do agree, most impact is had when using bundling at a moment closer to the deployment.
Print regular map in a design you like and hang it upside down. It's literally that. Or if you want to be strict you can use "flip" function in image editing tool. You can compensate me for saving your money
Coming from a different ground (TypeScript) I agree, in a sense that there is a line where apparent convenience because a trouble. JS ecosystem is known for its hype for build tools. Long term all of them become a problem due to trying to be more convenient, leading to more and more abstractions and hidden behaviors, which turns into a mess impossible to debug or solve when user diverges from author's happy path. Thus I promote using only the necessities, and gluing them together by yourself. Even if something doesn't work, at least it can be tracked down and solved.
