Reading the article I got the impression the big challenge is doing "personalzation" of the content at scale.
If it were "just" static pages, served the same to everyone, then it's pretty straightforward to implement even at the >300m users scale Netflix operates at. If you need to serve >300m _different_ pages, each built in real-time with a high-bar p95 SLO then I can see it getting complicated pretty quickly in a way that could conceivably justify this level of "over engineering".
To be honest though, I know very little about this problem beyond my intuition, so someone could tell me the above is super easy!
In a previous role we used their (first party) physical transfer appliances to upload ~600PB of video into S3. It was a complex logistical exercise to take it from the physical SANs, but the AWS specialists we worked with were great and it went without a hitch.
I don't want to be too negative, I generally agree with and am aligned with the content of the article, but this struck me as a really bad take:
> In my experience, “show me the data” is often a tactic employed by weak managers who don’t know how to hang as part of a design process.
I really don't understand how asking to see data and talk in facts, rather than opinions, is a bad thing? This take seems to be implying the "design process" is just a giant, strictly qualitative "appeal to authority" fallacy and anyone who doesn't "get it" is some kind of naive rube?
In my experience, a lot of the motivating factors for large enterprises mandating encryption at rest aren't about specific security controls. They will often hand wave in that direction, but as as the OP says in their post, without being able to describe a coherent threat model.
Instead a lot of motivating factors I've seen are about preventing various paths for "legitimate" data disclosure to third parties. For example, when data at rest is combined with additional requirements like "bring your own key" it means a subpoena or NSL needs to be served on the _first party who owns the data_ (as they need to provide the keys) and can't be served on just the cloud provider without the first party having at least visibility of it.
The "template" use case was a very common one from iframes/framesets in the early 2000s, and the markup often looked a lot like your desired example.
My memory's hazy, but I remember it becoming more and more complex to maintain as the web's security and performance model evolved, as you needed to manage and secure all of these disparate, discrete DOM trees in the same page context.
Wouldn't what you suggested just been "reinventing" frames/framesets if you added the ability to arbitrarily pull in templates via the network?
"Hard to write but easy for customers to deploy" is my guess. There are a bunch of very high-performance computing use-cases in finance (quant, HFT) that Java gets used for pretty routinely. That's a very attractive market to build primitives like databases for, they have very deep pockets, but you need to play in their ecosystem.
I've seen this "GC-less" Java in those use-cases quite a bit. From a conceptual design POV it's likely not the best approach, but there's a lot of sunk cost in that eco-system and a lot of trust and expertise where "Choosing a better language" is often several orders of magnitude more expensive.
> in my experience you provide the debt collections agency all supporting contracts and account documents for each loan
This might be true for first party lender to first party debt buyer, but it often falls apart after that first step.
The article mentioned the chain of debt ownership and that, in my experience, is where contracts and supporting docs are lost. Once you're buying debt 3 or 4 steps removed from the primary lender the documentation becomes sparser and sparser, which is why as the article rightly said, most of these "last mile" agencies rely on people's ignorance and use a "spray and pray" strategy for debt collection.
My experience, from a large primary card issuer in the US, was that most of the major, reputable debt purchasing agencies would only buy primary debt portfolios that had _contractual guarantees_ about the accuracy of the supporting contracts and docs. They'd spend a lot of time and effort reviewing them, but they would in turn outright _refuse_ any such provisions when THEY sold their debt to smaller agencies!
I'm interested in this line "Many media outlets are increasingly reliant on money from betting companies" as I'd be interested to know how reliant the Guardian was on this revenue. Is stopping this type of advertising a big impact on their top line?
I applaud the move either way, but stopping doing something that's 0.1% of your revenue vs something that is 25% are two very different things.
I visited Chittagong a decade or so ago (as part of a non-profit working with child workers) and I can only emphasise what a visceral and horrifying thing this kind of ship breaking is to witness. 10,000's of people (as young as 6/7) working 24/7 in conditions that bear absolutely no respect for their health or safety.
One of the most morally repugnant parts of the Western legal system is the creation of the labyrinthine corporate structures used to to protect the ship owners for any liability as part of their ships being broken.
I can second fly.io, I moved a bunch of personal (but "production") projects from Heroku to it recently (Node, Rust, Rails) and the experience has been great. I can also second their Heroku migrator, worked pretty flawlessly.
Overall, my pricing has been about the same or 5-10% less per month.
It doesn't have the same "Click this button to add this third-party service to your dynos, with billing included" eco-system that Heroku has (had?) but my Heroku usage was pretty vanilla so it wasn't an issue for me.
I do a fair amount of pre-seed and angel investing and I've seen a _massive_ increase in the number of very early businesses that have a "product" that they've been able to build with no/low code tools. It gives non-tech founders a set of options they've never had before, in my experience.
That obviously isn't viable for all early businesses and even the ones it is viable for eventually need to hire engineering teams to build their products, but I love how much more accessible these tools have made shipping something basic.
This is a really interesting point and it resonates with my experience. When I moved to the US from Europe I was suddenly in a world where people had enormous fridges and freezers and could buy a massive amount of food at a time. They would never have fit in dinky little European apartment before!
This is also my experience for folks that live in NY.
They put all kinds of locks on the account but they never worked, my assumption was that people who worked at the provider (who could unlock anything) were the ones stealing it!
I had a UK mobile number that had seven consecutive digits (e.g. 079* 444 4444). I got it through a friend who worked in provisioning at a new mobile operator that had just been assigned its new number blocks.
The problem was people would constantly try to "steal" the number. Four or five times a year my phone would just stop working because someone had "persuaded" a call-centre worker at my provider to assign the number to a new SIM they could sell on eBay. Apparently people pay a LOT of money for vanity numbers.
No matter what additional "security locks" they put on my account it kept getting hijacked, so eventually I just got a new (much less interesting) number.
I like the blog post and broadly agree with the conclusions, but I want to double down on something in the article:
> Shared pain
I've worked in some orgs with very large monorepos (1000s of developers working in a single repo) and broadly have had positive experiences with them, but this 'shared pain' was by FAR the biggest drawback I experienced. When things went wrong with the monorepos they tended to go VERY wrong and effect EVERYONE. Multiple incidents of the monorepo just crushing productivity for 1000 person engineering orgs, for a period of time.
That's not to say I think monorepos are bad, it's 100% context dependent whether they make sense for your org in my experience, but I learned that the same tradeoffs you get with architectural monoliths/distributed systems often apply to multi/mono repos as well.
This is much less of an issue for Sweden and Finland than other non-NATO members, as we're an EU state and article 42.7 of the Lisbon treaty obligates other EU members to assist in case of military attack.
So any Russian military retaliation that occurred between Sweden announcing they intended to join NATO but before they officially did would, in effect, be an attack on the whole EU block. Which is tantamount to a direct attack on NATO.
Finally, Sweden has several bi-lateral defence agreements with countries like the UK and US. It's obviously not technically the same as being a NATO member, but many people in the Swedish defence establishment regard it as closely equivalent.
I led a lot of data and analytics work for pharma companies on clinic trials and the point about complexity is hard to overestimate. A pretty good analogy for bringing a major new drug to market is comparing it to building a new space flight system, individually it might have one less zero on total cost, but that's more of a factor of humans bringing dozens of drugs to market at any one point so there are economies of scale rather than it being any less complex.
Also, the article does a good job of describing one side of clinical trial complexity, finding participants and getting them through the funnel, but there's a whole other source of complexity in clinical trials that mean you need massive global efforts: different global regulators have different criteria for 'approving' clinical trials. An indicative example, the Japanese regulator needs to see evidence that the drug was tested in Japan during a trial. They're one of _many_ national regulators that say that.
So even if you _could_ find all a trials participants in one country you likely wouldn't be able to get it approved by many national regulators.
There are 100% valid epidemiological reasons, but often these differing national rules are there for policy purposes outside of drug safety, for example, if you mandate trials need to take place in your country it provides a nice investment in biotech for your economy or by creating specific rules as a lever to control cost in your national healthcare system (e.g. NICE in the UK).
Sort of similar to the above, will rule you out of certain roles with certain businesses but if you're open and honest about it you'll be able to find something. The OP having computer hacking (and more importantly, fraud) on their record will make it harder than a DWI, as a DWI isn't something 'work related' (unless you drive for a living, obviously).
The amount of time passed is also something I've seen have an impact (e.g. if you had a DWI 20 years ago vs one 6 weeks ago)
I've hired quite a few security folks in my time (some with criminal convictions) but my answer is an unhelpful one: it depends.
If you have a criminal conviction it's unlikely you'll get through the screening process with a regulated business (like banking, insurance, pharma etc) due to some 'out of the hiring managers hands' constraints those industries have. I've seen exceptions to this in the past, where a senior manager strongly advocated for the exception, but it's _very_ rare.
I've worked with several security people with criminal convictions in the past at non-regulated, FAANG and FAANG-like tech companies. They also usually have policies in place to prevent hires with criminal convictions, but the exception process there is easier, particularly in security teams where these convictions are more likely to occur in strong candidates.
The biggest concentration of folks with backgrounds like yours have been at security consultancies, in my experience. Combined with the experience you mentioned with bounties, that would be the place I'd spend most time looking. You might still get rejected from some, for example those with customers that require criminal background checks for employees or security clearance you couldn't get, but there are still quite a large percentage where you could find work. Personally, I've had conversations with external consultancies who say things like "I know you require criminal records checks on all our employees, which we're happy to do, but I want you know >50% of my team will fail them".
A couple of other things:
- No matter where you work, with your background there might be some kind of 'restriction' placed on what you work on and/or how you work (e.g. can't work on project Type X or must work from Office Y). If you do get through a process, ask about this before joining, as it might have an impact on how much you'd enjoy the role.
- Be open about your background. You sound like you would do that anyway, but the more open you are the better, you don't want this to be a surprise to people. What you're looking for is a strong advocate on the hiring team, so building trusting relationships with people will be important.
Don't be too down on yourself, you might have made some bad decisions, but you sound like a talented professional. The criminal justice system exists for people to serve their punishment and then move on with their lives. There are companies that will be delighted to hire you because of your skills. Your road may be a little tougher than for others, but that doesn't mean you can't end up professionally happy, fulfilled and well compensated.
If it were "just" static pages, served the same to everyone, then it's pretty straightforward to implement even at the >300m users scale Netflix operates at. If you need to serve >300m _different_ pages, each built in real-time with a high-bar p95 SLO then I can see it getting complicated pretty quickly in a way that could conceivably justify this level of "over engineering".
To be honest though, I know very little about this problem beyond my intuition, so someone could tell me the above is super easy!