martius

While it's probably easy to land on your feet and find something with a good pay in SV or London, it's probably not the case everywhere.

4 months of pay for this kind of trouble doesn't look like a good deal to me.

Actually, I think we're more on the level of "threat employees with basic decency".

The recommendation for interviewers is to select a mix between past stories and hypothetical scenarios.

I'm sure there are plenty of candidates giving up because they received a competing offer and wouldn't wait, but I think it's reasonable to expect a hiring process to take a month, even in small companies.

Edit: I also have anecdotal evidence of cases where an offer would be made withing 2-3 business days after the interviews at both Google a Facebook.

It's as easy as saying like "I just got an offer from $competitor".

The process may take months because candidates usually ask for time to prepare, and some latency once the offer is accepted (background check, etc). If you are actively looking for a job, you are most likely already prepared.

> An App password is a 16-digit passcode that gives a non-Google app or device permission to access your Google Account. Learn more about how to sign in using App Passwords.

Maybe I misunderstand the announcement, but it looks to me that this feature will still be a valid alternative when Oauth can't be used.

I've been learning German 2 hours a week + homework for 2 years and I'm not yet B1 in German. We are 4 students with one teacher and, from what I understand, we are not particularly slow.

Maybe German is really harder to learn than other languages, but probably not 2x or 4x as French (I'm French).

It strikes me as a misunderstanding on how career evolution works in these companies (and, I believe, most tech companies). A senior eng will focus less on the pure technical aspects (language, framework, etc), but rather will have the soft skills allowing them to carry larger projects/impact.

For instance, with experience, a senior can identify design mistakes early, can weight the value of different solutions based on aspects like time/eng-cost, tech debt, complexity, risk.

In a company of the size of Shopify, shifting away from "Rails ERB templates" to a more modern solution definitely require these skills (and also probably way more than 6 months of tenure). They could have proposed this project, tried to get some buy-in and learn new "frontend skills".

Assuming they really set this project in motion, there's plenty of time for the next government to cancel it.

I'm not saying they are doing a bad job, but I really can't say if they've been doing a good job either.

> During the current FLoC origin trial, a page will also be included in the calculation if Chrome detects that the page load ads or ads-related resources. (Ad Tagging in Chromium explains how Chrome's ad detection mechanism works.)

Ad tagging? https://chromium.googlesource.com/chromium/src/+/master/docs...

> Ad Tagging works by matching resource requests against a filter list (...) to determine if they’re ad requests. Any requests matching the filter are tagged as ads. Further, requests (and some DOM elements such as iframes) made on behalf of previously tagged scripts are also tagged as ads by the AdTracker. An iframe will be marked as an ad iframe if its url matches the filter list, if tagged script is involved in the creation of the iframe, or if its parent frame is an ad iframe. The main frame of a page will never be tagged as an ad. Any request made within an ad iframe is considered an ad resource request.

I can't find what is included in this filter list, I'm not sure it's open source.

(mandatory disclaimer: I work at Google, not on Chrome nor ads)

It has a lot of benefits:

* we have an influence on the priorities of the project, and make sure our issues are prioritized. You can't be sure of the evolution of an open-source project.

* continuous rollouts. In my previous job each major version bump of Kafka or Hadoop could become a complex migration to plan a long time in advance. Now, we still have migrations to do, but often the scope is smaller and the transition smoother.

* strong culture and policies. We hold ourselves accountable. In my previous job, we would often mitigate incidents and forget about them, not write the post mortem or really root cause the incident. Usually because we knew/believed it would not be solved anytime soon (conflicting priorities, or whatever else). I've never seen an incident swept under the rug at Google.

In my case:

* I have a good in-depth knowledge of one product I'm oncall for. My team may implement some design changes required (ex: for scaling) and I contribute code to this project.

* I have shallow knowledge of 2 other products, I'm trained at identifying a trigger that causes an outage and mitigate it (common mitigations are: move traffic, increase quota temporarily, rollback a release). If I can't solve an incident without in-depth knowledge of these products, I escalate to the devteam, and they will be responsible for root-causing.

A mitigation that requires a patch, cherry pick and rollout would be a terrible (and risky) thing to do, so I'd rather find any alternative first.

While there is more structure at Google, it's basically the same job :)

The implementation varies between companies, and I understand this is what these articles try to capture. My point is that as an individual contributor in an organization where "SRE" is really a thing, I believe that the role is often quite well defined.

"a pool of servers that route traffic to application backends crashed"

It's not the only one implemented by tools that extend Git (Phabricator and Gerrit, for instance, support pre-commit workflow).

Github also brings a bug tracker (albeit a simple one), discoverability, hosting (obviously) and integration with many useful tools (CI, documentation generators, etc). All of this is easy to use.

These pieces greatly contribute to the success of many open-source projects (of various sizes). Github "extinguishes" alternative because of this, not because it designed an alternative to email-based workflows.

I suppose that many projects (open-source or not) want to use tools that extends Git. Maybe what we need is a standard making these tools interoperable and open.

Edit: I've been downvoted so I'll add a precision: Usually, it is believed that async shines against other models once you reach a certain scale (https://en.wikipedia.org/wiki/C10k_problem). This benchmark shows than async app frameworks are slower than the sync ones when running at a given scale, and since the article doesn't give many details on the incomming traffic, I can only assume that it's low, since it saturates 4 cores.

I believe that your conclusion that "Async python is not faster" is an over generalization of your use case.

I'm not saying that the configuration in your benchmark is not correct, I am saying that this benchmark may not yield the same results if you try to scale it on bigger hardware.

I believe that scheduler overhead can't be ruled out (not for python nor any other program) on a server since we've sometimes observed that the scheduler could be the bottleneck under some circumstances. For instance, some Linux schedulers used to show poor perfs when using nested cgroups with resources quota enabled.

Also, I'd like to state my first point again: you need to see how the number of workers will influence the memory usage on your system. Especially with python, if you've got a lot of workers, you can expect some memory fragmentation that can impact the perf of your system.

16 workers is not that much considering that modern servers can have a lot of cores available, and I expect that the more workers you need the more likely you'll hit other bottlenecks:

* the more workers you need, the more memory you consume (workers are processes, not threads),

* I don't know how OS scheduler behave these days, but the general-purpose OS scheduler may consume some CPU time you'd rather give to your app.

I understand the point on latency variation though: preemptive multitasking will slice the CPU time "fairly" between workers, while in a cooperative multitasking situation, it would be the job of the programmer to yield after some time.

With a sync server, a worker is inactive as long as it is waiting on IO, so you need enough workers to maximize the chance that all workers are busy, else, some clients are waiting even if you've got the CPU to deal with them.

With an async server, a single worker handles many clients simultaneously, in theory, a single worker per core is sufficient to eat all the CPU available.

What surprises me is that these companies seem to either hide their French roots, and are often ignored by the academic world. When I was student in engineering school, the only companies we would hear from where the big French corps like Orange, Cap Gemini, Thales and co.

I'm sad to see that these French companies don't get the support and publicity they deserve. I hoped that the French tech thing would help these companies, but I only ever hear about startup with vague pitches founded by business school graduates which don't know a thing nor care about any "tech".

This doesn't make sense.