mmcclimon

Cold ketchup on hot french fries is one of life's great joys, though.

You can invoke git-who as git who by setting up an alias in your global Git config

This works even without the alias, by the way: by default `git whatever` will search your path for `git-whatever` and execute it.

FWIW, the latest stable release is 7.0.12, released a week or so ago: https://www.mongodb.com/docs/upcoming/release-notes/7.0/. (I'm not sure why the URL has /upcoming/ in it, actually: 7.0 is definitely the stable release.)

Field size for American football is definitely standardized: 100 yards between goal lines and 160 feet wide. Lots of Americans will have an intuitive sense for how long something like "three football fields" is.

Man with PhD in subject is pedantic about that subject on Hacker News, film at 11. ;)

There are, of course, stylistic norms, and a lot of those norms are shared across lots of kinds of Western music. The thing I'm pushing back against is a misconception I see a lot that people who teach music theory are arbiters of quality in music, and that music that doesn't "follow Bach's rules" is somehow less good than music that does. (That misconception is probably well deserved, because that is how music theory was presented for a long time. I think that has changed, though, and that you'd be hard-pressed to find someone in the field that holds that position these days.)

I'm not sure what your dissent is, so I'm not sure how to respond to it. I think you're saying that you had a good experience in your music theory classes, which used Bach chorales, and you wouldn't want to discard that experience in favor of a shallower, broader curriculum.

If so: that's not really what I'm saying at all! Even in courses that focus primarily on, say, Western common-practice harmony (as many basic undergrad theory courses do), you're likely to find a much broader variety of music being taught than just the Bach chorales. That's partly because the field as a whole has been moving away from strict adherence to the traditional canon, but also more basically it's just good pedagogy. That is: most music that students play isn't going to be four-part homophony, and so learning to do harmonic analysis of string quintets or saxophone quartets or lead sheets provides a much stronger grounding about how harmony works in real music -- even if you circumscribe harmony quite strictly as "harmony as deployed in Western common-practice music betwen 1700 and 1850."

Disclaimer: I left the field and have been employed full-time as a software developer for more than 5 years, and pedagogy isn't an area of the field I follow closely. A good recent example is the open-access textbook Open Music Theory (https://viva.pressbooks.pub/openmusictheory/); perusing the examples there I think will be a good demonstration of the breadth of both styles and composers that's pretty representative of current pedagogy, even without radically altering the aims of the undergraduate music theory curriculum (which is also happening).

What I mean when I say that music theory is a descriptive enterprise is quite literal: the research that professional music theorists do is designing theories to describe music we see and hear in the real world. So yes, composers (now and in the past) do learn music theory, and do write music with stylistic norms in mind, as well as adding their own spin on things. That work, in my reading, is not music theory, it's composition! The act of "inventing music theory" is something done by music theorists (writ large), not by people writing music.

To use your analogy: composers are inventing music in the same way that normal speakers invent language. I don't think I'd describe new variations on language as "inventing linguistics," though, as linguistics is the in-depth study of language (and as such, "inventing linguistics" is something done by linguists, not by language speakers). But language is not linguistics, in the same way that music is not music theory.

Fair point; that's partly my own bias (I know basically nothing about non-Western musics), and partly because of the article I'm responding to ("Bach doesn't tell us anything about gamelan music" isn't an interesting observation).

But also: the majority of academic music theory at the moment does focus broadly on the Western tradition. That's changing, I think, but a quick scan of recent articles in Music Theory Online (https://www.mtosmt.org/issues/issues.php) reveals quite a broad spectrum of music, most (not all!) of it is from the Western tradition.

We know quite a lot about Greek music theory (Thomas Mathiesen's Apollo's Lyre: Greek Music and Music Theory in Antiquity in the Middle Ages is the go-to source here: https://archive.org/details/mathiesen-1999-apollos-lyre/page...). Of course we don't have recordings, but we do have a solid understanding of the theory, and some very good guesses as to the scales and intervals.

Oh boy. Music theory, as such, has no "rules," and so of course Bach did not invent them. Music theory is a descriptive enterprise, which aims to make sense of music as composed/performed/enacted by humans. (I have a PhD in music theory.)

Bach's chorales were functional music for the Lutheran church, and to the extent that they form any sort of "rules" in music theory, it comes from the fact that they have been used to teach harmony for a long time (since at least the 1940s, as evidenced by this article). The reason for that isn't so much that they're prime examples of Western common-practice harmony, but rather that they have a homogeneous texture that's easy to use in classrooms, because they're easy for one person to play at the piano or for students to sing.

Recent music theory pedagogy has largely been moving away from the reliance on Bach chorales to teach harmony, especially as music theory has taken a broader perspective on what music we should be studying anyway. Studying the Bach chorales is just fine if you want to know about how Bach used harmony, but there's a whole lot of music in the world, and there's no meaningful sense in which Bach's music intrinsically defines a set of rules any more than Mozart's or Clara Schumann's or AC/DC's or Meredith Monk's defines a set of rules.

While acknowledging that git's CLI is often unintuitive: `git tag` lists tags, `git branch` lists branches, and `git remote` lists remotes, so I don't think I understand this particular objection.

The current version of perl is 5.36 (it's a really good perl). The language formerly known as Perl 6 is now called Raku. The "Perl 7 initiative" referred to in the grandparent is the idea that at some point, the 5.x series (i.e., the language you know as Perl) will accrue enough features and deprecate enough very old behavior that it'll get rebadged as Perl 7.

There's not a timeline for that right now, nor clear consensus on what exactly will be worth a version bump or how much backcompat between 5.x and 7.x there will be going forward. It's being actively discussed, though; the Perl Steering Committee (formed a couple of years ago) meets weekly, and discussion on p5p (the language development mailing list) is still fairly active, though admittedly much less so than in years gone by.

Very little of git as used by most people is Perl these days; almost everything has been rewritten in C by now. A few things remain, but they're pretty niche: git-send-email, the git-cvs tools (!), git-svn, and git-fast-import (maintained in the contrib/ tree) look to be the only top-level perl things left, at a glance.

Perl may or may not be relevant in 2022 (it's certainly relevant to me), but this article does not do a great job at explaining Perl's merits. The example code, in particular, is certainly not what I'd expect to see in a modern Perl shop. They don't use warnings or strict, which the author cites as a benefit of Perl over Python, and which is the bare minimum for maintainable perl these days. The examples also use CGI.pm, which was removed from the core Perl distribution as of perl 5.22, which was released in June 2015! (Nowadays you'd use a framework for that; there are lots to choose from.)

Many of the things the author cites are good about Perl are, in fact, good about Perl. But if you're writing new software in 2022, you should probably pick a language with a future, and that language is probably not Perl.

Yeah, `git log --format=%ae | sed s/.*@//` will get you most of the way there, and then it’s down to how you want to deal with the domains themselves, as you say!

The rule we have is that anything that is not idempotent and not run as a matter of daily routine must dry-run by default, and not take action unless you pass --really. This has saved my bacon many times!

Yeah, that seems to be the case (confirmed with their little example at https://github.com/mdn/dom-examples/tree/master/server-sent-...). Once the connection is closed you can see things, but that's not particularly useful for debugging!

Hmm! You're right that I hadn't looked it a while, so I checked before making the comment above. I'm still seeing the same thing I always have, which is "No response data available for this request". Possibly something is slightly wrong somewhere (though Chrome dev tools seem fine on the same), but you've given me something to look into, thanks!

SSEs are one of the standard push mechanisms in JMAP [1], and they're part of what make the Fastmail UI so fast. They're straightforward to implement, for both server and client, and the only thing I don't like about them is that Firefox dev tools make them totally impossible to debug.

1. https://jmap.io/spec-core.html#event-source

Just to second this…Joe has done lots of great work at Fastmail, but ‘vesta show’ might be my favorite.

Oh yeah, our support team is worth their weight in gold. They're all real people who know an awful lot of arcana about the nuts and bolts of email, and much more friendly and helpful than if I needed to talk to our customers on a regular basis!

And in times like today, it's so nice to be able to say "hey, $person_working_now, could you deal with fastmailstatus.com and Twitter please?" and the engineering staff don't even have to think about it!

For what it's worth: as a Fastmail employee, it's also extremely irritating for us!

(I work for Fastmail.) One of our attempts at doing some mitigation of the attack caused this; we fixed it about 16:00 US Eastern this afternoon. Sorry about that!

Without getting into too much detail: we were limiting some HTTP methods, but unintentionally blocked REPORT, which DAV clients use to see what’s changed.

Yeah, for sure! Outlook is also very bad about this, and usually when we see it people have added include:spf.messagignengine.com (Fastmail's SPF, which is all IP addresses) and one other include, which does a bunch of recursive lookups. This is often very difficult to explain to people, and there's not even really a way to work around it, short of using different domains for different sending needs (which many people are unwilling or unequipped to do).

Normally, this means that spf.messagingengine.com has its own SPF DNS record, which will probably list some valid IP addresses that emails can be sent from. There's also one for Mandrill, for transactional emails. You can have as many of these as you want.

This isn't strictly true (that you can have as many as you want), because SPF has a (IMO) very silly hard limit of 10 DNS lookups per record. From RFC 7208:

Some mechanisms and modifiers (collectively, "terms") cause DNS queries at the time of evaluation, and some do not. The following terms cause DNS queries: the "include", "a", "mx", "ptr", and "exists" mechanisms, and the "redirect" modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".

We see this not infrequently at Fastmail, when customers report DMARC validation problems, and the answer turns out to be that they've got too many includes in their SPF records, so SPF always fails.

I would add "Traits: Composable Units of Behavior" (http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pd...), which is good if you're interested in OO at all but also if you want to know more about traits in Rust (or roles in Perl).

I work for Fastmail, and helped write Topicbox, the backend of which is entirely written in modern Perl. The frontend obviously uses JavaScript, and talks to the backend using JMAP (RFC 8620), which we helped to develop; Topicbox was using 100% JMAP well before Fastmail itself did.

Nearly everything at Fastmail is in Perl. Cyrus, which is the mail storage engine, is in C (and open-source), but everything else is Perl.

I noticed recently that all the API responses from Twilio have an X-Shenanigans: none header.

(I work for Fastmail, but am not really involved with the teams that have done most of the work on labels.)

In the backend, there is no difference between labels mode and folders mode; all of the changes are in the UI. There are no IMAP attributes or keywords (they're poorly supported by third-party clients); any email message can appear in more than one mailbox, where "mailbox" means "folder" or "label".

On disk, mailboxes are stored as UNIX directories: all copies of the message (i.e., in all folders/labels) are hard links to the same inode. Over IMAP, each can have its own metadata (\Seen and \Flagged, for example), and they'll probably appear as separate copies (depending on how your client decides to do things).

As you say, JMAP has this built in: each Email object has a MailboxIds property. When the web client (or your own bespoke JMAP client!) fetches emails for one folder/label, and then you click to a different folder/label, the client doesn't have to download that message again, because it already has it in its local cache.