Hacker Newsnew | past | comments | ask | show | jobs | submit | soanvig's commentslogin

Oh, that must be fun to be hired by the client directly... I wish each my programming job was not an ivory tower :(

I think the ivory towers because managers mostly manage by how much of the plan can we ship. It is too radical to have developers take time from that to talk to customers which is a shame for the developer, customer and business.

> much longer than the lifespan of websites

But browsers (and browser technologies) have documented track of being fully backward compatible up to the beginnings of WWW, and it's not going to change.

Which actually is much much better than any other environment you can imagine - unless of course you use (and want to use) that one frozen in time 25 year old PC. And pray nothing breaks (y2k bugs and whatnot).

If the software is open source (and works offline) you can have it functional in 10 or 20 more years. And it will be "locally-installed software you own" you want.


> But browsers (and browser technologies) have documented track of being fully backward compatible up to the beginnings of WWW, and it's not going to change.

That can however be undermined if web apps are poorly built and depend on quirks and behaviors specific to a particular engine (or in some cases, even particular versions of a particular engine) in order to function.

So I would say this benefit applies specifically to web apps that thoroughly apply KISS — that is, using only the most boring, solidified, widely supported APIs and favoring robustness over bells and whistles — and make a point of testing against all three major engines. Those apps will likely stand the test of time and run even under future new engines. On the other hand, the ones with severe shiny API syndrome that only ever get tested against the latest Chrome are probably much more brittle and more likely to be broken N years after abandonment.


"Fully backwards compatible" isn't really true, and even if it were, then you're stuck using browser-based software and its myriad of inherent downsides.

People (generally) use web-based apps that are good enough in spite of the web stack -- not because of it.


But you have to get the software somehow? Once you get it, it works offline. The same here I guess: once you download the source code/binaries into browser's cache (that can store things indefinitely) it's offline.

True, but you are at the whims of the browser cache, and how long it wants to keep it around.

If you are worried, download and self host. As suggested on the website (when discussing trust and PII).

> But you have to get the software somehow?

We call this: download. Usually better than RCE.


Wonderful comment.

Graphic cards prices normalized quite quickly after crypto boom. Before going nuts for AI training of course.

Those were driven up by scalpers during the crypto stuff. The manufacturers were still selling their cards for a reasonable amount, you just couldn't get one because scalpers and crypto farmers had bot armies gobbling up supplies.

The ram pricing is coming directly from manufacturers.


>Graphic cards prices normalized quite quickly after crypto boom

Eh, I don't think we were on the same planet then. Even post crypto pre-AI GPUs were far more expensive than they were before said crypto. We just got used to paying $1000 for a mid tier cards.


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.


Sometimes "branded" names are a good thing.

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)


I think because it's 10% income before cost deduction


> 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


The article touches on this:

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.


Very Inefficient But Entertaining coding


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: