> The post literally says that they could hit only 5% of the expected workload with their server less architecture, so IMO it is still quite negative.
Emphasis on "their server less architecture". Sometimes good tools are used poorly.
For example they describe a high throughout workload, and each workload spread through a bunch of lambdas that handled bite size bits of the workflow. Also, they managed the workflow with step functions. Just imagine the number of network calls involved to run a single job, let alone all the work pulling data to/from a data store like S3 into/out of a lambda. I'd guess the bulk of their wall time was IO to setup the computation.
Of course you get far better performance if you get rid of all these interfaces.
> I'd be surprised if this doesn't get taken down as it casts AWS lambda in an unfavorable light (and rightly so).
The article mostly lays the blame on step functions. Also, lambdas are portrayed as event handlers that don't run relatively often. This means long running tasks that are ran occasionally, or events that don't fire that often. Once throughout needs go up or your invocation frequency comes closer to the millisecond then the rule of thumb is that you are already requiring a dedicated service.
> (...) but languages with a better standard library seem less affected by dependency hell.
Let's ignore the hand-waving over what "better standard library" means.
Dependency hell has zero to do with standard libraries, and is exclusively related to modularity. If your language supports third party modules that can depend on third party modules, you have dependency management. Managing dependencies so far is hell, no matter how you go about it.
At face value they claim it's designed to eliminate tracking techniques like fingerprinting, it's actually a system explicitly designed to collect the users' private information. From the horse's mouth.
"To provide this free resource without relying on intrusive tracking, publishers and developers need privacy-preserving alternatives for their key business needs, including serving relevant content and ads."
The proposals involve reducing UA data, ip tracking, etc.
But still allows for some amount of targeting. From my understanding instead of you being an identifiable individual via fingerprinting, the aim is to make you "probably one in [large group] of technology people".
I'm not saying I think it's a good thing, but on the surface it does appear _better_.
Does Privacy sandbox prevent fingerprinting completely (for example, canvas fingerprinting, WebGL fingerprinting, audio fingerprinting)? Or the advertisers would be able to use both fingerprinting and newly provided data?
I don't understand why we need to trade here. Just block figerprinting and do not provide any alternatives for advertisers. This is the best for users.
You can't block fingerprinting completely without breaking a ton of useful features. But the sandbox has a concept called the privacy budget which tries to determine if a site is collecting too much information. It should allow sites that actually use some of these features to continue to work.
The idea is that if sites that query fonts, engage canvas, read the user agent information, etc, they are likely trying to build a fingerprint, so the browser will start to return generic data.
Presumably - hopefully - it would allow users to set their own privacy budgets. Even better if it supports granular per-site control, which may be needed for certain specialized websites.
> You can't block fingerprinting completely without breaking a ton of useful features.
Many of those features are not so useful and their main use is fingerprinting, for example:
- WebGL is mostly used for fingerprinting
- enumerating installed fonts is mostly used for fingerprinting
They should be put behind a permission popup, so that only those sites that really need them (e.g. graphic editors, text editors) can use them. So nothing gets broken.
Put WebGL, enumerating installed fonts, web audio, etc. behind a permission. In rare cases when they are really needed not for fingerprinting, the user will grant a permission and nothing gets broken.
Have you been around for the past 10-15 years of Android? Manual permissions don't solve the problem. People will just say why yes, I do indeed want to read this clickbait article/use this flashlight app, go ahead and give the server my GPS location so it can follow me around. The only reason you don't get much of this anymore is the limits the app stores enforce these days.
> The fix? as simple as changing the browser's user agent to look like Android/Chrome.
I'm not defending Google here, but once I worked for a company whose web support strategy consisted of explicitly supporting a specific subset of browsers, and have a user-agent allowlist to pick if a request loaded the current version of the page or a legacy, feature incomplete but broadly supported version. The guiding principle was that we would have to draw the line in the sand regarding which browsers we'd cover in our test matrix, and instead of risking subjecting users who used unsupported browser to broken experiences then it was preferable that we assured they would experience an old but bulletproof version of it.
We started off by showing a "this browser is not supported, please upgrade" page, until some other department in our company complained up and down the org tree because they used thin clients with outdated browsers. Thus instead of showing a "please upgrade" page we fed the old version, and everyone was happy.
I see how this looks like intentionally feeding a degraded experience to subsets of users, but having been in a decision-making process that led to the same outcome, let me assure you there are real-world scenarios where this outcome does not originate in malice or any ulterior motive.
The users affected by this case were at the tip of a very long tail of unsupported user agents. Those who want to circumvent the issue can either upgrade or resort to tricks like faking user agents. The key take here is that we could not possibly support all browsers or the old version, so for the very rare cases we kept the lights on in a very old and unmaintained version of the app. In my company there was no sneaky ulterior motive, it was just that we couldn't afford maintaining obscure platforms that, even if we really wanted to, we couldn't possibly test.
> I think ORMs fit that bill. For some reason they were (are?) incredibly popular, but I don't think they stood the test of time.
I don't think there is any truth at all to this personal belief. In some domains it's unthinkable to use anything other than the standard ORM. In C# you'd need to be nuts to roll SQL by hand instead of using Entity Framework, and Django speaks for itself.
The only drawback of ORMs is that their promise is that developers don't need to learn the intricacies of SQL and SQL-related design patterns, but in practice developers need to learn the intricacies of SQL, the ORM framework, and the SQL generated by the ORM. Naive developers might believe they are better off reinventing the wheel with ad-hoc SQL stuff, but that's another problem.
I am nuts! I often work on two main C# projects. One uses a data adapter with data table objects. The other, is about to have EntityFramework completely removed. Reduced it to only handling database connections.
Original developers used code first. Looked into the dynamic SQL created by the framework and it was overly complex statements. Replaced with simple hand crafted SQL and Dapper, used just to bind the results to objects. This cut transaction time down dramatically, about 30 seconds down to less than two. I could still cut that down further with batch transactions that are no longer logically grouped.
Simply combining SQL, CSS, and HTML with a custom DSL allows for creating interlinked reporting. Did this on a microC II OS embedded system with SQLite running on hardware with 8mb flash and 64mb RAM. Port the DSL, keep the same table structure, and the same reports can be used in a new environment with new hardware or different database backend.
EntityFramework might be useful in some places. I have yet to work in a domain where it is.
> The wrong abstractions can lead to coupling and complexity.
This comes to the old quote:
* "Make everything as simple as possible, but not simpler.” Albert Einstein.
Abstractions undoubtedly add complexity that quickly becomes unmanageable. By now everyone is already aware of the horror that's the enterprise version of Hello World, and YAGNI/gold plating are renowned antipatterns. Many codebases have already succumbed to the perils of premature generalization, where the good old rule of 3 of refactoring serves as a shield against it.
But still some developers succumb to the siren song of abstracting away things.
Extracting two subobjects from an object to feed them back to the same very object is not an abstraction, it's merely adding a bunch of public methods (and interfaces) to the object. That may or may not help in abstracting things: and usually, the more handles and bells and whistles are available to pull and play with, the less abstracted the code actually is.
There's using "abstraction" in the classical sense of "harder to understand", as in "abstract painting". In today's world, good abstractions are the exception.
> it's merely adding a bunch of public methods (and interfaces) to the object
The object is the abstraction they're complaining about. Why have an object to begin with?
In this case, nothing particularly meaningful or useful, they mostly just shrink wrap the underlying (single) implementation's details and re-expose them as-is for the caller to cope with. Some people also think that that somehow helps with encapsulation too.
> In this case, nothing particularly meaningful or useful
You're either playing dumb or weren't able to understand what was in the code. IHelloWorldString is an abstraction over the way the string was implemented, IPrintStrategy is a strategy pattern that abstracts away how the abstract hello world string is supposed to be printed, and finally IStatusCode is an abstraction over how a status code is implemented.
> they mostly just shrink wrap the underlying (single) implementation's details and re-expose them as-is for the caller to cope with.
No, not really. Their purpose is to abstract away implementations. Just because there's a single implementation that does not mean this wasn't abstracted away.
I worked at a place where the former employee had engineered his whole S3 to files synchroniztion layer. We never needed that. That's YAGNI. (And if we did, the library already has it!)
Choosing crappy overly-simple ideas for abstraction is not what YAGNI is all about. It's about pulling in overhead+complexity when it's justified, and only then.
Packrat parsers make a very compelling case. I'm not sure the debate is over.