This is true, and in principle a good thing, but in the time since Parquet and ORC were created GDPR and CCPA are things that have come to exist. Any format we build in that space, today, needs to support in-place record-level deletion.
Yea so the thing you do for this is called "compaction", where you effectively merge the original + edits/deletes into a new immutable file. You then change your table metadata pointer to point at the new compacted file, and delete the old files from S3.
Due to the way S3 and the ilk are structured as globally replicated KV stores, you're not likely to get in-place edits anytime soon, and until the cost structure incentivizes otherwise you're going to continue to see data systems that preference immutable cloud storage.
You can avoid that if you save only per-user encrypted content (expensive, I know). That way you just should have to revoke that key to remove access to the data. Advantage is you cannot forget any old backup etc.
OK, based on your link the answer to my question seems to be: it's not a tracking pixel, but the "Meta Pixel", which the documentation describes as "a snippet of JavaScript code".
Welcome to the wonderful world of affiliate marketing, adtech, and tag management.
In that world, third party ‘tags’ that are included in a page are generally referred to as ‘pixels’. Sometimes they are single pixel img tags. Frequently they are scripts. But the industry calls them ‘pixels’ anyway.
It is, surprisingly, not a terribly honest industry.
I don't know why you're being downvoted, calling full access javascript embedded into a page a 'tracking pixel' is a total lie. Then again 'serverless' is where you use a server, so the track record isn't great.
I guess most people reading this already knew that the term 'tracking pixel' has evolved beyond its original meaning, and is now commonly understood to include all sorts of tracking code.
I did not, but now I know :)
(And although serverless doesn't mean 'no server', we know what the word means and it doesn't cause confusion.)
Not sure about the goal of providing a hosted service cheaper than SQS. SQS is already one of the cheapest services on Earth. It's pretty hard to spend more than a few bucks a month, even if you really try!
What is your target market? Cloud-native is, like the commenter said, going to be difficult to differentiate based on cost. I can see this being useful for hybrid cloud (onprem instances), functional or local testing, “localfirst” workloads, enthusiasts etc.
My own vision is to take a queue that is relatively dumb and make it smarter. I want it to be able to, for example, allow you to rate limit workers without needing to implement this client side. And so on for all of the other bits that one needs to implement in the course of distributed processing.
I’m still figuring out the market. Very large firms spending thousands of queues? Or developers who want a one stop solution built on familiar tech? Or hosting companies who want to offer their own queue as a service?
I've heard this use case come up in hybrid new/legacy products where there is a chasm between legacy scalability (probably a monolith in the compute or storage layer, or both). The "new" side needs to be able to self-regulate and if you can put that into the service-side it would it would be a helpful transition enabler (and, let's face it, given these transitions often never finish your product would be effectively sticky).
I don't think the cost of queues is a problem anywhere (I'm sure it is somewhere, but not a market's worth). The problems created by queues, on the other hand, are myriad and expensive.
ORMs are such a toxic idea, we'd be better off if we could un-invent them. Look how thoroughly this poor author's mind has been poisoned by long-term exposure.
Please get out there and write some SQL. I promise it won't hurt you.
You absolutely 1000% do not need an ORM to prevent SQL injection. You just need to Not Be Flagrantly Incompetent. As the psycopg2 docs say: never use string concatenation, not even at gunpoint.
You and I may not be, but, not to besmirch coding bootcamps, there are some great employees coming out of them, but not all of them are great. Some of them don't even know SQL, and training them up on it would take an inordinate amount of time, given their background. So it's a lot of trust to put in a team of building the hottest new CRUD app, when "use an ORM" is an easy enough answer.
For queries in the hot path, you can apply a senior dev to optimize, but their time is limited and wants to be used most effectively. From the pushback I've received, this isn't a universally held belief, but the right tool in the right place, there are places for it. You're absolutely right that you don't need one to prevent SQL injection, but just like using Rust simply avoids a class of memory access bugs compared to C++, ORMs just avoid the problem from happening in the first place.
Those aren't the filters being used, not when there are hundreds of applications for a role.
You could be the platonic ideal candidate yet be screened out in the 0th round because you didn't go to a fancy school or you're missing one keyword from an irrelevant list.
Getting past the resume screening to a recruiter call is always worth it. Always.
You really think The New Guy can change an entire corporate culture through sheer force of will? You are literally the lowest person on the totem pole. You have ZERO social status, ZERO influence. If the rest of the org/company is culturally aligned around seriously bad practices, you are going to sound like an crazy person, even if you are the only sane one in the room. You are simultaneously Sisyphus and Cassandra.
"The very people who comply with and execute the GDPR consider it to be positive for their company, positive for privacy and not a pointless, bureaucratic regulation."
I have been involved in multiple GDPR compliance pushes and I want to emphatically state the opposite position. It is not worth it. It is not worth ANYTHING. It should be destroyed.
