jgraham

I'm not really sure I follow your complaint, so I wonder if there's a point of misunderstanding. The tests written for DOM APIs certainly require running javascript to execute the test — that's a given — but most of the rendering tests are reftests. These consist of two files, one using the feature under test and one avoiding that feature [1]. The test passes when the two renderings are identical. That does make these tests difficult to run "by hand", but in terms of implementation it's possible to automate in anything that's capable of rendering to an image. Reftests are preferred over comparing rendering to a fixed image because fixed images tend to be invalidated due to unrelated/permitted changes in the rendering (e.g. a different font or different antialiasing choices). These will typically apply to both test and reference and so are handled automatically.

Reftests obviously aren't suitable to bootstrap getting very basic things working, so there are some manual tests; I suppose one could hope to avoid that by inventing a special kind of output inspection automation just for those basic tests, but it's hard to justify.

IN general, however, the "the ability to point my software at some .html files, get some failures, add more implementation, get less failures, and repeat" is exactly what wpt offers. There is some work required to stand up the necessary infrastructure to run the tests automatically, but it's common for new implementations of the platform to make use of web-platform-tests (e.g. Servo and Flow have both made use of wpt).

In terms of coverage it's very difficult to demonstrate that all the requirements of a spec, and all its interactions with other specs, are completely covered. There have been various proposals for adding test metadata to try to measure coverage, but these have largely proved impractical. Nevertheless some CSS specs have links from the spec to the relevant test cases. And if you find cases that aren't covered by exisitng tests it would be great to get a PR to add new tests [2]

[1] https://web-platform-tests.org/writing-tests/reftests.html [2] https://github.com/web-platform-tests/wpt

A workaround would be to use Firefox directly from upstream instead of the distro packaged version (I understand some people are not happy with this tradeoff).

Except they're not. They're (often) packfiles, which are a delta encoding i.e. a diff. It's not necessarily the same as a specific commit, but appealing to "the bits on disk" is wrong.

It is certainly true that the git object model each commit object refers to a tree that represents the complete state of the repository at that commit.

It is also true that many git commands implictly treat a commit as being the diff between the state of the tree in that commit and the state in the parent. For example git show, git rebase and git cherry-pick.

It is simultaneously true that the on-disk storage system is optimised for performance and so doesn't map onto the object model in a trivial way.

For any project where performance or correctness are significant concerns I'd much rather use Rust than Python. It provides a lot more tools to help you write correct code, and express invariants in a machine-checkable way. This means that they are maintained when the code changes, even when multiple contributors are involved. I'm must more confident in my ability to ship correct code in Rust and maintain that correctness over time.

Rust also doesn't have the performance ceiling (floor?) of Python, either for single threaded programs, or — especially — for those that benefit from concurrency or parallelism. Of course for some progames there's a clear hot loop that you could implement as a native extension in Python, but other workloads have relatively flat profiles where the performance bottlenecks are making allocations or similar.

As well as the actual language features, the commitment to backward compatibility from the Rust authors means that you don't get regular breakage simply from updating to a newer version of the language. I think Python 2 being 2.7 for such a long time gave people a false impression of how stable a foundation Python provides and the fact that point releases of 3.x often cause problems feels like it causes a lot of unnecessary makework for Pyton users and is rather offputting.

That doesn't mean I'd always choose Rust of course. You do require more upfront design to get something that works at all. Some projects also benefit greatly from not requiring a compile step and making use of the ubiquity of a Python interpreter. And I think I'd find it difficult to justify using Rust for a typical web backend that's mostly composing together various well-tested libraries to provide an API on top of a database.

Overall I didn't really love mypy; the type system it implements seems relatively simplistic and it was frequently easier to change the code rather than work out how to write working annotations for the existing code. The lack of support for decorated property setters in particular was a big problem; this particular codebase makes extensive use of those to annotate methods that require mutable access to the underlying data. Nevertheless I'm convinced that this approach to the migration was much faster and less painful than it would have been to try and figure out all the string/bytes differences without any tooling support except for the tests. And post migration the code seems overall somewhat higher quality than at the start.

On balance, I think the lesson was actually that Python isn't a great choice for this kind of project. When you are depending on external services the ability to unit test everything is greatly diminished, but the ability to make type assertions is not. So for correctness you want the latter to do as much lifting as possible. That suggests that other langauges such as typescript (if you still want a language in vaugely the same category as Python), or Rust (if you don't), which come with more expressive, better integrated, type systems, might be superior options.

* It's clear which states master has actually been in, without having to resort to squashing each merge into a single commit. This means that you know which commits actually passed CI and are therefore good rebase targets. People often claim that when merging multiple commits each commit should individually pass CI, but that's almost impossible to achieve in practice.

* Development can split single features into multiple commits for easier review and understanding later. This can be particuarly important if the changes depend on each other, but different people need to review different parts of the overall change. That's another thing that most tooling is really bad at.

* The history is basically linear. The merge commits are all empty, and there is one linear history for all the states of master (the first parent of each merge commit) and one linear history for all the individual commits (the second parent of each merge commit and only parent of each non-merge commit).

Of course this approach isn't well supported by mainstream tooling (e.g. GitHub) and probably requires a custom bot to do all the rebase-and-merge operations. It is pretty well supported by git itself, however.

Back in the dim and distant past when XHTML was a fashionable term to throw around, Evan Goer did a study of whether sites claiming to serve XHTML were actually doing so. The results were not pretty [1]. Some people took the results as a challenge and tried to ensure they were sending valid XHTML with the correct mime type so that browsers would catch fire in the case of a parsing failure. In almost every case it turned out to be possible to get their sites to break with user generated content (e.g. searchng for XML-invalid characters which were then echoed back onto the page).

So I contend we ran the XHTML experiment pretty thoroughly 15 years ago, and it turns out that it doesn't really work. Once you accept that parsing errors being fatal isn't viable for publishing, you have to have some kind of error recovery system. The one in HTML isn't ideal since it's basically just the codification of many years of improvisation and reverse engineering. Maybe something like XML5 [2] would be better. But figuring out how to move the world in that direction is an unsolved problem. Meanwhile HTML Just Works for most of the people most of the time.

[1] https://goer.org/Journal/2003/04/the_xhtml_100.html [2] https://github.com/annevk/xml5

This isn't just an apriori fact of the culture, but an intentional result of the structure of the leave.

90 days are reserved for each parent (there's an exception for single parents) i.e. if the father doesn't take those 3 months they are lost. Apparently before this policy came into effect, fathers would typically take very little leave. But once there was an incentive to take 3 months they began to take longer periods and split the overall time more evenly.

So even though it's part of the culture, it's not impossible to understand how it came to be, and therefore not impossible to replicate elsewhere.

They have the kind of deep technical knowledge and ability to solve challenging problems you'd expect from a research group, coupled with the skills to make pragmatic tradeoffs and fix the complex real world problems needed to ship software. More than that, they are one of the most welcoming and friendly teams I ever worked with. The culture they created allowed them to take inexperienced new contributors and quickly ramp them up to a place where they were confident to solve challenging problems. Working in that environment and seeing what's possible has really raised my bar for workplace culture and mentorship.

Note that this is somewhat different from a language like Lua where it isn't necessary for all existing script to work with every new iteration of the runtime without any changes.

The fact that implementation details like GC timing have remained behind the veil of abstraction is one of the only reasons that JS engines have managed to evolve from being relatively slow interpreters to highly optimised JIT compilers.

Because if you know who's supposed to be in quarantine you can take steps to verify that they actually are. And also because people are simply less likely to comply with rules when they know no one can tell if they're following them.

> I don't understand why you think an app that can promise to keep people's personal data private would gain lower adoption than one that was explicitly collecting such data. Maybe I've misunderstood what you're trying to say here but it would make more sense to me that an app that can preserve privacy would have higher adoption, higher trust and therefore higher compliance levels.

Again, because you're comparing "opt-in and private" with "opt-in and non-private". I'm comparing "opt-in and private" with "mandatory and shares user data with the health authorities" (which is different from "[opt-in|mandatory] and public" in that in the latter case any member of the public can get information about infections; I think South Korea are/were running a system with that level of sharing).

The problem is there's likely a pretty direct tradeoff between preserving privacy and efficacy. So I think people whose main concern is privacy are taking the position that the apps can't work, without being clear about the fact that it really depends on what assumptions you make around enforcement.

Clear disclaimer: I'm not anything like an expert here. Much of what I've written below is likely wrong or misleading and I'd welcome corrections.

A simple, bad, toy model is that the fraction of infection chains you prevent is (fraction of people using the app)^2 x (fraction of transmissions detected) x (fraction of people who comply). So if your model is "app usage must be opt-in" and "it must be impossible to tell who is complying with the app's recommendations" you do indeed find that the app only detects a small fraction of transmission chains (e.g. assuming 50% of the population opts in, 80% of transmission events are detected, and there's 50% compliance rate, you only stop 10% of infection chains). But if it's mandatory to use the app, and there's a mechanism to ensure enforcement you can do much better e.g. with 80% of people using it and 95% compliance you're closer to stopping 50% of transmission chains.

Of course that model is far too simple to be correct. But https://045.medsci.ox.ac.uk/files/files/report-effective-app... models this in more detail. Their simulation finds that you can suppress the overall transmission in the UK with 80% of smartphone users using the app (56% of population, comparable to the most popular apps), 80% detection of transmission, and 2% dropout rate per day on a quarantine period for all individuals flagged as contacts, which lasts up to 2 weeks. I don't know what they used to come up with that number for dropout rate, but it seems highly optimistic if the information about who has registered as a contact is kept private. They also find that up to half the population might be in quarantine at any one time, which I suspect is higher than most people are anticipating for a post-lockdown period. To combat this, they propose various going through a process of optimising the algorithm based on feedback, but again, if the most-privacy-preserving approach is taken for the data collection, performing such optimisations may become difficult or even impossible, since you won't be able to followup on individuals.

So, my — non-expert — conclusion at this point is that privacy-preserving digital contact tracing probably isn't going to be that useful because people either won't use it or won't follow the advice when doing so is inconvenient (e.g. because it puts their employment at risk). But digital contact tracing in general seems like it can help, if you can drive both usage and compliance high enough.

So there may be a pretty direct tradeoff here between our ability to trust the health services with personal data and our ability to prevent further rounds of unchecked exponential growth of this virus. And that is worrying, because — as a British person — I'm very unexcited about giving a government that has a history of using targeted data from social media to achieve policy ends even more data to work with. But I don't know that I can construct a satisfactory argument that it's OK for people to die, or even for those that don't to suffer an additional year of economic disruption, in order to avoid the privacy implications of a system of contact-tracing-with-enforcement. And I also worry that those who would be happy to collect this data will use the launch of an initial ineffective app, and a corresponding second wave of infections, as a way to make this kind of data privacy socially unacceptable.

Maybe there's an argument that by focusing on legal limits to the use of the data rather than to technical controls on its availability, we will end up in a better position in five years time, not just on the pandemic, but also on privacy.

On March 16th there was a request to avoid "non-essential travel and contact with others", on March 20th pubs and resturants were forcibly closed, and by 23rd the restrictions on movement were being put into law.

The three-day period I was thinking of was the 20th-23rd; the number of people out and about on the weekend of 21st/22nd was widely reported as the reason for the stricter rules the following Monday e.g. https://www.theguardian.com/world/2020/mar/23/boris-johnson-...

If, however, you mean "what's the proof that people were ignoring the pre-lockdown restrictions in sufficient numbers to make the stricter provisions necessary", all I can do is point out that the people with the best access to that data did chose to require the stricter provisions in response to what they saw. For more you're going to have to wait for the inevitable public enquiry (and I am deeply deeply uninterested in having a discussion about whether lockdowns are the only or most effective policy here).

This is pretty much what I was looking for, thanks. So in their model you need 80% of smartphone users (56% of the population) to opt in to the contact tracing for it to be effective. But iiuc they also assume what — to me — looks like a really high compliance rate; it assumes that people self-isolate for up to two weeks with 2% daily drop-out rate. That seems fine for people with trivial WFH jobs, or those in industries with good job protections, but pretty unlikely for people whose choice is between ignoring the guidelines and losing their income. I imagine with the excuse of "the whole country is in lockdown" gone, employers will be less tolerant of absence, even if — as in the models — it can be a significant fraction of the country in self-isolation at any time.

My assumption was that if the R0 is 3-5, that's small compared to the total number of contacts over the infectious period. That means that the false positive rate is going to be rather high. Given a high false positive rate and some inconvenience with following up, needing to go get tested or go into isolation, either of which mean taking time off work at short notice, people will "take a chance" more often than you'd like and delay getting tested until there are symptoms. But certainly it's not a confident estimtate.

Also, Germany is likely cultrally different, but opt-in social distancing / lockdown lasted fully 3 days in the UK before it became clear that it wasn't going to have the necessary effecity. I can imagine the same thing for compliance with contact tracing recommendations.

> The proposed centralized solution would have to rely on malice to easily identify people that did not follow up correctly since there was no means to do that in it

Right, but this is (aiui) different to the systems in countries like South Korea which use location tracking to ensure that you don't break quarantine. It's a point in the possibility space that must be considered to understand tradeoffs.

> AFAIR adoption in Singapore, which is often used as a reason to use this model in the first place, so far has not been anywhere close to the 50% of 80% of phone users. Many people seem to suggest looking at WhatsApps growth rates for realistic adoption time frames.

You'd hope a massive public information campaign could speed up uptake here. I think I've heard that whatsapp is on 75% of devices in Germany (but I haven't verified that number) which if you assume 80% of the population owning a smartphone, leads to 60% of the population opting in. So that doesn't change the results of the toy model too much (if it was 75% of the population rather than 75% of smartphone owners, that would roughly double the fraction of infection chains terminated compared to the 50% assumption).

These numbers still seem pretty low to me, but again I've got precisely zero expertise here.

> Fraser et al have a few general articles and calculated through scenarios on the matter that might be interesting, maybe you get something out of those

Thanks! I'll read those.

> Many discussions w.r.t. the epidemiological impact of these trade-offs at the moment seem anecdotal because they lack proper validation.

That's worrying. I think there's a possibility here that we're in the zone where privacy-preserving contact tracing has too low effacity to be significant in saving lives, but solutions that are mandatory and come with enforcement are effective. If that turns out to be true, there's a clear tradeoff between individual privacy and saving lives / rescuing countries from economic ruin. If I were the sort of person who wanted to significantly change the narrative around privacy to make it look unacceptably selfish, this might be the sort of crisis I'd see as an oppertunity. And given that this is less information than Google and Apple can access as a mattter of course, constructing the narrative that it should be shared with the health service is easy, if people go that way.

I hope there are people thinking about the case where there's popular support for the tracking being mandatory and non-anonymous, so that there can be proper legal — rather than technical — safeguards to ensure the data is only used for its intended purpose and is destroyed promptly when it's no longer useful for that purpose. The optimistic point of view is that this process will give us the ability to shape the fuure of privacy regulation so that we accept that some entities (Google, Facebook, maybe the Government) have more personal data than we're confortable with, but there are stronger controls on how long that data can last and what it can be used for.

fraction stoppped = (usage fraction in population)2 * (fraction of infections recorded as contacts) * (fraction of detected contacts who follow up correctly)

That's obviously a massive over simplification; for example real population dynamics don't give full random mixing between all members of the population. But every factor there is potentially depressed because of opt in and anomnymity; the first obviously so, the third because people are less likely to followup correctly if there's no consequence for not doing so, and the second because it will be impossible to tune the detection parameters without any data to work from. In that — again oversimplified — model if you get 50% o the population using the app (compared to 80% smartphone usage in western Europe), it detects 80% of transmissions and (say) 50% of people follow up correctly before themselves passing the disease on, you end up with 10% of infection chains traced. That doesn't seem like it's going to have a big impact.

So assuming that model's not wildly wrong — which it could be, again, I'm really looking for a link to an expert discussion of this, I can see a few possibilities: * Digitial contract tracing doesn't have much impact on our ability to control the virus * Governments seek to outsource the privacy-invasion needed to companies by e.g. requiring evidence that people are using the contact tracing software and have followed up on potential transmission events before allowing people to buy food etc. * Ineffective opt-in contact tracing and a second wave of pandemic deaths/lockdown is used to bounce people into accepting the need for mandatory, non-anonymous contact tracing with fewer privacy concessions than you'd get right now.

To be clear I'm very concerned with the idea of govenments and in particular the current UK government having access to non-anonymised contact data; it's already being run by someone who considers population-level manipulation using data science and social media to be his core skillset. But I'd also like to understand what tradeoffs are being made in terms of disease control.

I point this out because I'm pretty sure that different techniques will suit some people better than others. Personally I'm happy to do 10 minutes of kneading at the start, but find it burdeonsome to go back and do stretch-and-fold every half an hour (or whatever schedule you're following). Similarly I've seen people claim that the only correct way to keep a sourdough starter is to feed it small amounts of flour and water multiple times a day. If I had to do that I'd never remember and so never bake bread again; the results from keeping the starter in the fridge and refreshing it 12-24 hours before baking are good enough for me, and it's a schedule I can stick to.

Sourdough seems to be one of those activities where there are a lot of people who have a way that works for them and generalise out to that being the one correct way to do things. Whilst there are definitely things that work better and things that don't work so well, the important thing is to find a method that you're able to reliably follow and that gives results you're happy with.

On Mac paths are some weird NFKD-ish thing, so equality comparisons are complicated.

As a rule, if you think that filesystem paths as easy then you're probably ignoring all the edge cases. In application where you don't deal with arbitary user files that's fine. In a programming language that's a huge design error.

[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1334394/

There is a plan to update the WebDriver standard to encompass the automation features that are currently only available via devtools protocols. There's agreement it should be possible to open up a bidirectional channel to the browser from within devtools and use it for things like listening to events, streaming logs, etc. However as so often happens reality dictates that implementing something compatible with CDP is needed today in order to interop with the range of existing tooling that's either CDP-only (e.g. Puppeteer) or WebDriver-with-CDP-extensions (e.g. SauceLabs, various WebDriver clients).

In the long term we hope that we end up with a "WebDriver 2.0" that will satisfy all the common use cases in a standard way. That bidirectional protocol will probably end up looking a lot like CDP just to ease the migration for existing implementations, but the details depend on work that hasn't yet been done.

I'm having difficulty unpacking your claim about a DTD "parsing" HTML5, but I find it hard to believe that a primarilly DTD-based parser would get all the rules right around, say, foster-parenting, or handling of -- in script elements, or pseudo-entities or any of the the other weird quirks that are specific to HTML and not shared with SGML languages. Perhaps you can link the code and details about the claimed test suite pass rate?

As a irregular hg user, I frequently run into (or help others with) issues with the ui, like "why does `hg log require `-f` to do something useful", "how do I refer to the current head commit (protip: it's not `tip`)", "how do I see changes relative to a branch (bookmark) on a remote" and "which set of commands am I supposed to use for history rewriting nowadays and how do they work?".

hg has some nice features, but the idea that it's got a fully intuitive and uniformly well designed interface is, in my experience, a total myth. Which isn't to say that git has a great CLI of course, just that the extent to which hg is better in this area is often overstated.