Larry Hosken: New

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.

chart showing three San Francisco COVID measurements over the last couple of months. The line of New Cases is low, but rising. The Wastewater line has been above the pretty-safe level for a while now. The Test Positivity% line has crossed the pretty-safe level, recently going from pretty-safe to not-so-safe

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

sidewalk decoration in the form of a miniature beach shack sidewalk decoration in the form of two miniature beach shacks

(4233 Kirkham)



Milestone: 42 Million Hits

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: - - [20/Nov/2023:23:17:39 +0000] "GET /wp-content/plugins/core-plugin/include.php HTTP/1.1" 404 1441 "" "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.

nighttime (well, dawn-ish) photo of San Francisco's “Painted Ladies” houses but with light beams visible behind them

In tangentially-related news, there was a coyote hanging out in Alamo Square park this morning.



Book Report: Software Engineering at Google

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 some well. 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 organization.

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.)

elaborate macrame picture. theoretically a public picture from the Rijksmuseum, but I had no luck tracking down the original

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 more. 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.

graph charting three measurements described by preceding paragraph

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 invitations.



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.)
screen shot of gofundme page



Oh cool: 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.

I helped 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.



RSV Vaccine at NorCal Kaiser? Maybe? Or maybe not?

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.

wow that green line is up there

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.




1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023