Swoop is owned by WestJet, it's just their discount brand. Flair's actually independent and used to be based in Kelowna but is now based in Edmonton – they're probably who GP is thinking of.
12,236 karma · joined April 12, 2010
Well, the differentiation is between strings which are dev-authored and parsed during compilation/boot time – which are trusted (untainted) and thus may contain HTML that's rendered directly – and tainted strings which come in at runtime either from user input or from via the translations lookup (among other things), and which can never be rendered without fully HTML escaping (without the code explicitly untainting them, at least, but that would never survive code review because it's profoundly unsafe to do this).
click_here isn't a "real" variable in the source language, it's just something that the translation API can replace during the translation load. To the extent that it can contain HTML, it can do so if and only if it is bound to an untainted string instance during the translation load – binding it to a tainted instance would cause any HTML that gets inserted into there to get fully escaped. "link" being dev-controlled produces untainted strings, but might itself consume a tainted string for its title (and thus escape that while rendering the title as part of outputing its untainted string), etc.
> how you differentiate between potential HTML in the translation
it's very simple: the translation is not trusted and thus can't contain HTML that gets rendered without being fully escaped, and thus looking like garbage. If you really wanted to style something in the middle of the paragraph (which again, effectively never really comes up in my experience) you would have to split the paragraph into 3 keys: everything leading up to the start of a tag, whatever's inside the tag, and everything after the tag.
I don't know what to tell you other than that it is not my experience at all that translation services offer or even accept HTML as a source-format, and if they did they would no doubt command a significant premium over translators who know the languages but lack such tech skills.
And I absolutely wouldn't trust a third party to directly author HTML we were serving anyways. Manual audits of 3rd-party input aren't enough – your tooling should be automatically protecting you from 3rd parties inserting unsanitized HTML (as below)
> I'm not sure I understand how your example prevents that HTML threat model you mention, unless the "link" function generates some kinds of magic placeholders that you then replace with HTML in another step you did not mention. If "link" generates an A tag, then you're already trusting the translation with HTML powers anyway
Good lord, no – you should never be rendering externally controlled strings directly as unescaped HTML, and that includes strings from 3rd party translators.
The lookup function for translation keys produces instances of an "unsanitized" (tainted) string class which is escaped on rendering, so if "link" in this case takes two arguments (the URL, which will become the href, and the text that will get wrapped in the A tag – the text argument will be completely escaped such that attempting to embed HTML in the translation key .a.fancy.link.name would result in mangled output, eg)
translation file:
a.fancy.link.name: <script src="some-evil-bitcoin-miner-script.js"></script>Click Here!
<%= link(foo_service_url, t(.a.fancy.link.name)) %>
<a href="http://www.foo.com"><script src="some-evil-script.js"></script>Click Here!</a>
That's... hardly the only threat you face if you have a translator feeding you malicious strings
You give them some context, and let them ask you questions if they feel things are too ambiguous for them to produce an accurate translation for the context it will be used in. In some cases we will include a screenshot of the rendered English page/component/etc so that the translator can map the key values they're seeing to the presentation context.
I can only tell you that this process has scaled to 10s of millions in sales in foreign languages, and that the translation services we use absolutely do not have any time or interest in signing additional NDAs around source code, in getting their employees set up with bespoke code and dev environments, etc. It would be a gigantic drag on their business model.
> I absolutely think the right way is to have translations be HTML fragments.
These translators do not know HTML and are not going to be able to work with it in any way – again, this would require the services to totally overhaul their business model, and spend a bunch of money/time on training or hiring more specialized translators with HTML/CSS skills, which they have no interest in doing.
It would also open up a threat model that's currently non-existent for us. Total non-starter.
> How else would you know what part of the sentence should be italic or contain a hyperlink?
Translation keys contain a simple substitutional form that can be replaced on key lookup, so
some.introductory.paragraph: Call to action: %{click_here}
a.fancy.link.name: Click to purchase!
t('.some.introductory.paragraph', click_here: link(target_url, t('.a.fancy.link.name'))
Maybe this is shocking but I'm fluent in a language that is sometimes written veritcally.
"You can't have one single common presentation for every translation" is true in an absolute sense but often not true in practice – eg) we hit most of Europe and North, Central, and South America with ~10 static translations rendered into one common presentational template, none of which run into any of the truly complex layout differences that right-to-left or vertical presentations would bring. We extensively QA all of the languages we do support, and presentation issues are truly pretty damn rare. It's your classic "80% of the result for 20% of the effort" tradeoff.
Now, if you truly do need to localize in every language under the sun then yeah, something like this can make sense, as it gives you maximum flexibility wrt to varying your layout alongside the translation.
But if you have any simpler use-case (eg. supporting just English, Spanish, French and Portuguese will give you an enormous chunk of the planet with minimal overhead, as they have very similar word lengths and presentation requirements) then the approach here is just taking on all of the effort and maintenance overhead of the maximally-complex case when you have absolutely no need to.
For one thing, we get our translations by handing a yaml file to external contractors. They don't need to squint at a file full of code to distinguish the bits of english that need translating from the bits that don't – they just have to translate the right side of every key, and there's specialized tooling to help them with this.
And for another, even in your toy example in the readme you've now lost a Single Source of Truth for certain presentation decisions. So now when some stakeholder comes to you and says they hate the italicization in the intro paragraph and to lose it ASAP, instead of taking the markup out of a common template that different data gets inserted into, you have to edit each language's version of the code to remove the markup (with all of the attendant ease of making errors that comes along when you lack a SPOT – easy to miss one language, etc). I'd expect these kinds of multiplication-of-edit problems to grow increasingly complex when you scale this approach beyond toy examples.
Basically this seems really hard to scale to large products, and doesn't play well with division of labour.
Absolutely, although in modern orgs I'd expect this to be the domain of backend engineers rather than "a DBA", a mythical creature I've never actually seen in real life.
It also pays 2x what I’d make locally.
Just to say that fully remote is by no means necessarily a stealth sweatshop.
Are you seriously claiming that you expect a single node shrink from Intel 10nm (roughly equivalent to TSMC 7nm) to Intel 7nm (equivalent TSMC 5nm, the M1’s node) to give Intel an enormous 75% increase in IPC such that they’d be able to compete on performance per watt by not having to clock so stratospherically high (with the attendant voltage penalties) to compensate for their low IPC?
That would be an unprecedented outcome for several node shrinks, let alone a single one. It’s Apple’s super-wide design that’s the primary factor in the IPC here. To pin it all on a single node shrink is magical thinking.
Again, not really. They wanted to put more efficient engines on the 737 to compete with the A320Neo, but keep the 737’s basic height in order to be compatible with the huge number of gates at old regional airports that are essentially built for the exceptionally low shape of the 737. Compatibility with those airports is essentially a competitive advantage for Boeing, as it’s what’s been keeping Airbus from eating their lunch with more efficient planes.
But the new engines were essentially too big for the low slung 737, so they moved them super far out from under the wing, making the plane basically unstable. Yeah, if they’d solved this by redesigning the plane to have more room under the wings it would have moved them out from under the 737’s grandfathered approval and thus required a lot more certification certainty and new training – but it would also have messed up the fundamental sales pitch of “buy this instead of the A320 Neo so that you don’t have to renovate your gates at every regional airport you fly to”.
the big engines moved so far forward creates the inverted stick forces that aren’t a training issue – no amount of training would have permitted them. It’s a Fundamental Airworthiness Requirement that they not occur, and the MCAS exists explicitly to make them not occur.
eg)
> Engineers observed a tendency for the plane’s nose to pitch upward during a specific extreme maneuver. After other efforts to fix the problem failed, the solution they arrived at was a piece of software — the Maneuvering Characteristics Augmentation System (MCAS) — that would move a powerful control surface at the tail to push the airplane’s nose down.
Again, that “tendency for the plane’s nose to pitch upward” isn’t a training issue – it’s flat out illegal for commercial planes to have that characteristic:
https://www.law.cornell.edu/cfr/text/14/25.175
So the MCAS is just an airworthiness issue caused by the legacy market Boeing was trying to continue to be compatible with. They were careful not to call attention to the MCAS to avoid the FAA adding training requirements that would have upset Southwest, is the main thing where that factors in.
This is somewhat inaccurate (and appears to trade on the oft-repeated but completely incorrect misunderstanding that the MCAS acts as a sort of “normal 737 emulator”).
In fact, the MCAS exists because without it the MAX would be 100% uncertifiable for commercial flight.
The central problem is that, due to the lopsided aerodynamics of the MAX, as the nose of the MAX moves up and approaches a stall, the forces on the pilot’s stick “invert” such that it becomes easier to continue to pull into the stall than push away from the stall.
Commercial aircraft are not allowed to have inverted stick forces at any angle. When Boeing realized this, they decided to implement a kind of hack that would use the trim to put pressure on the nose downwards to counteract the forces on the stick such that they never invert. The MCAS is the system that commands this downwards trim.
The desire to avoid retraining led Boeing to conceal the existence of the MCAS, but it is not why it exists. The plane flatly is uncertifiable without it. No amount of training would change this, as inverted stick forces are a failure of fundamental airworthiness requirements.
Instead of making assumptions, you could easily just find the facts: https://en.wikipedia.org/wiki/List_of_Boeing_737_MAX_orders_...
There are over 4000 orders still outstanding. Hence the ABC investigation repeatedly finding engineers on the project citing time pressure in the manufacturing process: they’ve got a huge backlog of orders.
> More than 42 incidents involved equipment malfunctions, and on more than 40 occasions, flight crews chose to ground the affected aircraft while problems were fixed.
> …
> In one incident on an American Airlines flight in April last year, multiple systems including both autopilot functions stopped working soon after take-off. On landing, the crew found the backup power unit, considered vital for safe flight, had failed and was emitting a strong electrical smell.
>…
> He said some other reports raised by the ABC were bizarre, such as an incident involving a United Airlines flight last August where fuel was found leaking into an overhead passenger bin. Fuel reserves are located in the wings.
>…
> One mechanic said they observed sub-standard manufacturing and testing of the planes, which resulted in wires being left exposed and debris such as rubbish, metal slivers and washers lodging itself inside various parts of the plane, which could lead to electrical short circuits or fires.
>…
> Griffith University's Dr Carim Jr reviewed several incidents from last year involving malfunctions with the MAX's stabiliser trim and said failures involving the component were "quite concerning".
etc
What on earth are you talking about. Pizza and Chinese restaurants have been profitably delivering food for decades.
The UberEats model in particular may be unprofitable, but there are absolutely profitable models that have existed for far longer than I’ve been alive.
Yeah and? How do you think IPv6 works, it’s exactly the same.
My router’s firewall’s ipv6 section help: “All outbound traffic coming from IPv6 hosts on your LAN is allowed, as well as related inbound traffic. Any other inbound traffic must be specifically allowed here.”
Longitudinal studies observing that teenage circadian rhythms shift towards sleeping in later long predate "online behavior".
IME your top performers are generally less compensation motivated than "interesting problem and interesting environment" motivated. Many companies will bend over backwards to give a top performer from a FAANG as much autonomy and interesting work as they want, for compensation differences that aren't that major anymore.
I was exceeding expectations, and given a big promotion in the middle of it. But people I worked with and interacted with every day were feeling extremely stressed and worried about their ability to meet the new bar. Now, in many cases, they didn't need to be worried, but it's natural to question these things in an environment where you're seeing people get PIP'd and unceremoniously shitcanned regularly.
Morale was through the floor, it was an absolutely miserable environment to work in – even though I was personally doing quite well. So I said "fuck this" and was the first person out the door on my team. The second highest performer quit a week later.
The least technically capable person on the team was there for another year.
First-hand, what I've seen happen is that your most talented people, who are the most in demand, leave the organization quite quickly because they correctly realize they don't have to put up with this bullshit. It's the coasters who fear they'll never land an equally cushy job who attempt to ride out the heat as long as they can.
Humans are odd in that we harvest milk for consumption at all beyond our own mother's, which is probably why we're the only species with a notable population with the genetic mutation that allows some of us to digest it – there's no competitive advantage to that mutation in most other mammals, because where would they even obtain milk?
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6669050/
> Studies that have measured changes in endogenous lactase activity after an intervention period consistently show a lack of enzyme induction, suggesting that lactose intake does not affect an individual's lactase activity. Although these studies are scarce and have relatively few subjects, data from cross-sectional studies support the theory of purely genetic regulation
This isn't new, and certainly isn't some crisis of the last 100 years. Historically only a minority of the planet has ever been lactase persistent into adulthood. It's a well-understood genetic trait, not some product of gut microbes.
Yeah, the OS matters, but it isn’t the only thing that matters to most people (and with the web, the loss-of-applications cost of switching your OS is a lot lower than it used to be).
How you communicate where a customer’s urgent request falls on the roadmap may change, but it’s never a smart move to upend the roadmap just because the customer thinks something is urgent.
In practice, declaratively creating data constraints at schema-creation time has a much much higher success rate than trying to imperatively enforce data constraints at write time, in my experience. The missed cases and bugs always come back to haunt you.