Flying in a window seat offers opportunities for serendipitous aerial photography. You don't get to choose what is going to be within view of the window, but when there's something interesting it can be fun to try and get a good picture. There are a few I've taken that I like:

Our neighborhood, with Powderhouse Park in the lower right, Davis in the middle right, Porter in the middle top, Trum Field in the lower left, and the bike path running horizontally across the middle:

When you share a link on social media the platform fetches the page and includes a preview with your post:

Even though this happens automatically the system doesn't obey the robots.txt exclusion rules (RFC 3909): I have /test/no-robots excluded in my robots.txt but that doesn't stop it:

I don't even see a request for robots.txt in my logs. But that's actually ok! The robots exclusion standard is for "crawlers", or automated agents. When I share a link I want the preview to be included, and so the bot fetching the page is acting as my agent. This is the same reason why it's fine that WebPageTest and PageSpeed Insights also ignore robots.txt: they're fetching specific pages at the user s request so they can measure performance.

This puts Mastodon in an awkward situation. They do want to include previews, because they're trying to do all the standard social network things, and if they respected robots.txt many sites you'd want to be able to preview won't work. They also don't want the originating instance to generate the preview and include it in the post, because it's open to abuse:

You can trust mastodon.mit.edu about what @jefftk@mastodon.mit.edu says, but not about what newyorktimes.com says.

The approach Mastodon has gone with is to have each instance generate link previews for each incoming link. This means that while having a link shared on Twitter or Facebook might give you one automated pageview for the preview, on Mastodon it gives you one for each instance the link is federated to. For a link shared by a widely-followed account this might mean thousands of link-preview requests hitting a server, and I'd also now consider this traffic to be from an automated agent.

I'm not sure what the right approach is for Mastodon. Making the link preview fetcher respect robots.txt (Issue 21738) would be a good start. [1] Longer term I think including link previews when composing a post and handling abuse with defederation seems like it should work as well as the rest of Mastodon's abuse handling.

(context)

[1] Wouldn't that just add an extra request and increase the load on sites even more? No: everyone builds sites to make serving robots.txt very cheaply. Serving HTML, however, often involves scripting languages, DB lookups, and other slow operations.

When I was little we would go to the NEFFA festival every year. I loved seeing the dancing: contra dance, international, dance performances. I loved listening to the music: bands, performances, hallway jamming. I loved eating the cake the Lithuanian booth would sell. My cousins would come up from Philadelphia, and it was one of my favorite weekends of the year.

Those early experiences at NEFFA got me into an activity and a community that has been a huge part of my life ever since. I've been a dancer, musician, caller, and helped organize a dance series and weekend. I've been bringing my kids with me when I go early to set up for the dance and when I travel to play dances elsewhere, and I'm glad they're getting to enjoy something that's been so important to me.

Which is why I was so disappointed to learn that the first in-person NEFFA since 2019 has chosen a covid policy that excludes small children.

Regrettably, out of concern for everyone's safety, children who for whatever reason are unable to remain appropriately masked as described above, including those two years of age or younger, are not permitted to attend this year's Festival.

When I described this policy to my cousin their response was "I guess that means we won't be able to go this year." I think this will likely be a common response among families with small children, and an unfortunate one.

How seriously organizers and individuals should be trying to limit covid spread is something there's a lot of disagreement on, mostly tracing back to different interpretations of the limited amount we know about the long-term impacts of getting sick. If the NEFFA organizers want to put on a very covid-cautious event that's not something I think people should give them grief over, and I'd rather see an in-person NEFFA for part of the community than no in-person event at all. But while if the precautions under which they were able to hold the event were uniformly strict I could see excluding people to young to mask, they aren't uniformly strict:

• There will be indoor dining, people eating and talking with masks off.

• Wind instruments are (likely—there's a case-by-case component) allowed with same-day testing.

• Despite rapid tests now being cheap and widely available, they don't require them.

• They have an exception process for adults who are unable to be vaccinated for medical reasons.

I don't think these policy choices are terrible, but I also don't see how they're compatible with a view that small children are too risky to allow. I would like to encourage the NEFFA organizers to rethink their decisions here, and figure out whether there's a way to include them safely. For example, allowing them to attend with same-day rapid testing, perhaps combined with distancing restrictions, like no baby-in-carrier contra dancing?

Putting on a festival like NEFFA is a massive amount of work, and it's impressive that NEFFA has managed this while continuing to be an all-volunteer organization. There are a huge number of decisions involved in putting on an event of this scale, especially while organizing the first one in four years and at a new venue, and I don't expect I'm going to agree with every single one. Still, I think the effect this has on who can attend the festival is large enough and uneven enough that more discussion and consideration are needed.

A few weeks ago I made some boiled apple cider. It was tasty, and after eating most of it I decided to make more. This time I used a gallon of cider, and it wasn't done after a day so I turned the slow cooker to "low" and left it overnight. Turns out that was too much! It had reduced to about 1/10 its original volume (1gal to 12oz), which wouldn't be too bad if I ended up with caramel. Except that it also has a decidedly burnt flavor, probably from getting too hot at the end. I like dark caramel, but this is past dark.

On the plus side, it's fun to play with, a bit like silly putty:

When I started at Google about ten years ago I was surprised to learn that image macros ("memes") were very popular internally. There was a page for creating, sharing, voting on, and discussing them, "Memegen" [1], and it was rare for someone to give a presentation without including some. My initial reaction was pretty negative: my earlier exposure to memes has been low-quality jokes in places where they tended to crowd out better discussion. In this context, however, they weren't actually crowding other things out, and instead Memegen's listing for highly-upvoted memes provided one of the best overviews of company-internal news.

Memes often make heavy use of shared context. Initially this was broader culture, but well-known previous memes feed back into cultural references available to draw on, and you get the beginnings of a language. For example, an image of a guy with an ugly brown cap became a standard way of talking about a particular kind of selfish or unreliable behavior. Each meme using that image reinforces and expands the association, increasing how much you can communicate by using it as the background for another meme. The hat is recognizable enough on its own that people will draw on those associations by pasting the hat in other contexts.

With tens of thousands of people creating and sharing Google-internal memes for over a decade, the internal associations from past memes diverged from external ones. Not entirely, since people weren't cut off from the outside world, but in a way much like a dialect. As someone who's read ~hundreds more Google-dialect memes than general-internet ones, this is something I need to think about when I (as I very occasionally do) make memes.

When you see contra dance tunes or other similar music written down there are usually chords along with the tune, but I rarely like them. Some of this is aesthetic differences, where the chords are often written in a style where you switch chords rapidly to closely follow the melody, but the real problem is that writing the chords for a tune isn't really possible. That is, there isn't a single set of chords you that will stay interesting as you play it ten times in a row for dancing. If you listen to great rhythm players they'll often pick different chords every time through the tune!

I was thinking about this with Amy in the context of rhythm for open bands and one idea we had was to get around this by writing several sets of chords for a tune. In an open band context the leader can say "next time, variation (b)!", or if you're playing rhythm on your own you can make your own choices. This still isn't perfect—it's often good to be even more free with choosing chords that fit in the moment than this implies—but I think it's a good step up from the current situation.

I sat down at the piano and wrote a few variations for tunes the way I'd likely play them. With each variation (a) is usually a good place to start, and some of the later ones you wouldn't want to do over and over or the novelty would wear off. The notation has each chord as two beats unless they're squished together, and "/" means to keep playing the same chord (more). I've put a few chords in bold to clarify that I really would play that chord, despite the dissonance.