I continue to check my little dashboard of San Francisco COVID numbers each morning to estimate risk of inessential-but-nice activities, e.g., whether I want to celebrate National Fritter Day with a fritter purchased inside or outside. Alas, San Francisco's numbers have gone up lately, so I shall settle for an outdoor pushcart fritter this year.
Looking at the graph, you might wonder what was going on in San Francisco's sewers in mid-November: the COVID-in-wastewater ~doubled, stayed high for a while, then dropped back down. This mostly overlaps with that big APEC conference, but not totally. The COVID-in-wastewater surge started kinda early and and ended kinda early compared with APEC. (Maybe each APEC VIP has an "advance" team that they send ahead of them to set things up at each place they travel? And maybe folks on such advance teams, between them, carry about as much COVID as San Francisco's population? Seems like a weird theory, but I don't have a better one.)
Anyhow, I'm taking a break from going inside public places. I mean, I like apple fritters, but it would be too embarrassing to tell the doctor I noticeably boosted my Alzheimer's risk for one.
People say that Outer Sunset NIMBYs will stymie all construction but then how do you explain
Wow, it's the site's 42 millionth hit. As usual, these "hits" aren't a measure of humans visiting pages; that count would be much lower. It's just requests to the website: every time a robot visits some page, the count goes up. If a human views a page that contains a dozen graphics, those graphics cause another dozen hits. So "a million hits" isn't as impressive as it sounds. But hits are easy to measure so that's what I measure. We can take a look at the log:
126.96.36.199 - - [20/Nov/2023:23:17:39 +0000] "GET /wp-content/plugins/core-plugin/include.php HTTP/1.1" 404 1441 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36".
This user is finding out that my web site doesn't have a /wp-content/plugins/core-plugin/include.php page. Looking through yesterday's logs, I see this user tried about 3000 pages with addresses like /wp-something/something/something.php, none of which existed.
This was an automated bot looking to hack into my site, trying various WordPress PHP pages with known security problems. This is a little silly, since my web site, like about half of all web sites, isn't a WordPress site at all.
I guess if you're a hacker writing a bot to exploit 3000 known bugs in WordPress plugins, it's easier just to try to exploit all the bugs than to figure out whether the target web site uses WordPress at all. A lot of web sites use WordPress. Pretty easy to try all 3000 exploits on all web sites; computing time is cheap these days. And if you're a hacker, you probably stole that computing time anyhow.
Hmm, bots aren't so interesting. Would you be more interested to know that some human was looking at photos
of physical tables used by actuaries that I snapped at the Smithsonian Museum of American History many years back? That human came along at about the same time as the hackerbot.
Painted Ladies with APEC LASERs. Maybe more fun to pronounce than it is to look at.
In tangentially-related news, there was a coyote hanging out in Alamo Square park this morning.
It's a pretty-good survey of important systems (technical systems and
people-systems) at Google Engineering. When I say "survey" I mean it
covers a lot of topics lightly. E.g., the chapter "How to Work
Well on Teams" is by Brian Fitzpatrick who co-wrote a
whole book about teams.
The chapter doesn't try to cover everything in the book; but it covers
Each chapter has plenty of endnotes with references so
you know where to learn more.
I bet if you're a new Google engineer, this book helps you understand
why things are the way they are.
If you're a new Google engineer who's worked in
other engineering organizations,
you absolutely want some kind of explanation for
why things are the way they are.
E.g. If you're an engineer who came from a 100-person-sized
company, you might ask "Why not use a git repository to
hold all the code? Isn't that what everybody does?
But Google has wayyyy too much code to fit
in a git repository.
If you work in smaller organizations, you don't
really think about how much code a git repo can handle.
Why would you? You're nowhere near the limit. Then you arrive at
Google and suddenly find out it's an issue; and you find out about
dozens of other "issues" that arise when thousands of nerds beaver
away on the same pile of code.
If you're an engineer not at Google, this book is probably
interesting, but I dunno how useful it is. It's good at describing
issues a growing engineering organization runs into; but the solution
that was best for Google isn't necessarily the solution best for your
Consider diamond dependencies.
That's the problem where there's
low-level utility code that two middle-level libraries use; then
some high-level application uses both middle-level libraries. You
can hit an issue where you change the low-level code; then you try
to update the middle-level libraries, and you hit a snag. Until you
work around the snag, one middle-level library only works with
the old version of the low-level code; the other middle-level library
only works with the new version of the low-level code. And now you
can't build your high-level application because there's no version
of the low-level code that works with everything.
(It feels kind of silly that we talk about "diamond dependencies".
When your tree of dependencies looks like ♢, you can fix
snags in a hurry. Maybe instead of "diamond dependencies" we should
talk about "elaborate macrame dependencies." When your
dependency graph looks less like ♢ and more like 𝍌,
those little snags turn into knotty snarls.)
It's good to know that
diamo elaborate macrame dependencies are
a real problem for big engineering organizations. If you've only worked
in more sanely-sized organizations, you might think oh diamond dependency
problems can be a hassle, but it's easy to fix each time.
Surely such an issue would never block all progress for the engineers
working on low- and mid-level code in my growing organization
for a week at a time. Ideally, you find out from
the efforts of traumatized Googlers, not from experience.
But Google's solution might not be the best one for your organization.
For many years, Google used a git-like-but-different tool
called Perforce that made it pretty easy to keep lots of code in one
big repo and work "at head". When they figured out a system to test
low-level changes against middle-level libraries, they relied on all
the relevant code being at head in one repo. When their codebase outgrew
Perforce, it seemed easiest to write a tool that was like Perforce but bigger.
Other solutions would have involved changing many, many tools.
I heard about the system Salesforce uses to solve the same problem.
It's pretty different. Instead of putting all projects in the same
repo, there's one project per repo. And there's a system that knows
which projects depend on which other projects. So if a Salesforce
engineer wants to change some low-level code in one repo, this system
knows which other repos to test. I bet Salesforce's solution is different
because their history is different.
They knew they'd run into the elaborate macrame dependencies
problem; but they came up with a solution based on where they were, not
based on what worked for Google.
It's not just dependencies and source control. There's unit tests and
big tests, release trains(‽), code review and more and yet
It was a fun read if you're into large engineering organizations'
swarming behavior and how to steer it. I enjoyed it.
I continue to check my little dashboard of San Francisco COVID numbers each morning to figure out whether meeting friends at a cafe for breakfast is a fine socializing:danger balance or an embarrassing "you risked your health so your friends could watch you eat?" trade-off.
About a month ago, I blogged with happy news: all three numbers I track were below the pretty-safe line.
Some people watch this number, some people watch that number, some people (e.g., me) watch
a few numbers; but everyone felt pretty safe then.
Alas, lately, not all three numbers are below the pretty-safe line.
COVID-in-wastewater levels have been above the pretty-safe line lately (though the most-recent numbers have been below;
this noisy number zig-zags a lot).
The %-test-positivity number has crept up. The number-of-newly-reported-cases number has stayed low, which is nice.
Personally, I'll continue going to inessential places for now. I use my
not-so-scientific-but-best-I-could-come-up-with practice of multiplying together
these measures; multiplying together pretty-safe levels for those measures; and
comparing. When I do that, I guess risks are still acceptable. But I won't
be shocked if folks who mostly look at test-positivity-% start sending their regrets to
Lovely restaurant Chang's Kitchen had a fire a couple of weeks back.
Now they have a GoFundMe fundraiser.
(When I tried to donate, gofundme seemed to be having problems; but
surely it will be working by the time you see this.)
Mike Springer, one of my Mystery Hunt teammates on Left Out,
won a prize for his team's work developing a high-throughput
COVID testing system in the early days of the pandemic.
To do this, the team worked with Richard Novak, then at the Wyss Institute, to co-create a swab that allowed for collection of samples that could be semi-automatically processed. The swab did not require liquid transport media, which simplified logistics.
In its first year of operation, the lab ran over 2.2 million COVID-19 tests at a greatly reduced cost per test.
playtest test the system. I didn't notice anything weird about the swab or whatever;
it was the early days, and it was the first COVID test I took. I didn't have anything to compare it to.
Gee, if I'd known the swab was so special, maybe I would have hung onto it as a souvenir oh wait
no the lab needed it back for their measurements never mind.
Someone asked me if Kaiser was offering RSV vaccines yet.
And thus I went down the research rabbit hole…
I found this page
...which says "The RSV vaccine is available at Kaiser Permanente for adults
over 60 who’ve discussed it with their doctor."
I'm not 100% sure that's for real, though.
I tried googling [ kaiser norcal rsv vaccine ]
and got the Washington version of that page
which has a big button to make a vaccine appointment, no
mention of 60+ age, talking to your doctor, etc.
Google didn't find the California page, just the Washington page.
So I hand-edited the address bar to see if there was a NorCal version
of the page, and there was. But when I went up to its "parent" page,
there's no mention of RSV, no link to the RSV page... So I dunno if
the NorCal page I found is for real, or some early draft thing that they
deliberately haven't linked to yet.
Today, I got yet another COVID vaccine.
Coincidentally, something strange happened to the California COVID-in-wastewater data yesterday.
When I reloaded my little dashboard this morning, the COVID-in-wastewater line jumped up.
I don't just mean that there was a high number yesterday; the historical numbers jumped up, too.
The little computer script that that computes this dashboard's data, when it grabbed data and saved it, just saved the data in the same place each time.
Thus, today's data file "clobbered" yesterday's data file on my hard drive.
In theory this is fine; because the file that gets grabbed today includes yesterday's data, too.
But what if there are a bunch of mysterious historical changes, too?
Then clobbering yesterday's file with today's file is not fine.
On a previous occasion, I emailed the California Open Data Portal people and
begged them for whatever backup data they could spare me.
This time… this time I might not bother?
I'm not going to try to debug today's weird changes.
I ?think? it also affected the data that the California Department of Public Health uses;
I bet those people know how to debug this better than I do.
But I did change my little computer script so that it doesn't "clobber" yesterday's
file with today's data. So the next time there's a mysterious change that goes back into the
historical data, maybe I'll have an easier time figuring out what changed.