Many OSS licenses are also free software licenses, even if they are not viral and don't impose severe restrictions on the licensee in the way the GPL does. The MIT license, for example. "Free software" and "GPL" are not synonymous, even GNU doesn't say so. See https://www.gnu.org/licenses/license-list.html#SoftwareLicen...
It's his first marathon ever, but he's a very experienced runner. It would be hard to find a better prospect for a good first marathon. He's a multiple (former) world record holder and medalist at shorter distances from the mile up to half marathon. His half marathon is still 2nd all time.
I wouldn't have predicted this out of nowhere, but if you told me a marathon debut went this well and asked me to guess whose it was, I like to think I'd have come up with Kejelcha in my top few picks.
That said, great 5000/10000 athletes don't always have great marathon careers. An example from this race is the world record holder at both those distances, Joshua Cheptegei. He's run several marathons but none spectacular by his standards. He was in this race too but 7 minutes back.
I've read that even if you absorb it all, there's some question about whether it's useful. This Alex Hutchinson article suggests, among other things, that it may spare your fat stores rather than your muscle glycogen:
> Even if you can absorb 120 grams per hour, it might not make you faster. In Podlogar’s study, cyclists burned more exogenous carbs when they consumed 120 rather than 90 grams per hour, but that didn’t reduce their rate of endogenous carb-burning—that is, they were still depleting the glycogen stores in their muscles just as quickly.
What is wrong in that quoted sentence? Do you mean "articulacy" should instead be "articulateness"? "Articulacy" is also a word, and correct in this context.
Regarding the noise you mention, I wonder if memento's use of the git 'notes' feature is an acceptable way to contain or quarantine that noise. It might still not add much value, but at least it would live in a separate place that is easily filtered out when the user judges it irrelevant. Per the README of the linked repo,
> It runs a commit and then stores a cleaned markdown conversation as a git note on the new commit.
So it doesn't seem that normal commit history is affected - git stores notes specially, outside of the commit (https://git-scm.com/docs/git-notes).
In fact github doesn't even display them, according to some (two-year-old) blog posts I'm seeing. Not sure about other interfaces to git (magit, other forges), but git log is definitely able to ignore them (https://git-scm.com/docs/git-log#Documentation/git-log.txt--...).
This doesn't mean the saved artifacts would necessarily be valuable - just that, unlike a more naive solution (saving in commit messages or in some directory of tracked files) they may not get in the way of ordinary workflows aside from maybe bloating the repo to some degree.
One nice way to do things, if you can get away with it, is to model the actions your application takes explicitly, and pass them to a central thing that actually handles them. Then there can be one place in your code that actually needs to understand whether it's doing a dry run or not. Ideally this would be just returning them from your core logic, "functional core, imperative shell" style.
There is some prior work on mitigating the performance cost of immutability that you might be interested in. For example, Clojure's persistent vectors allow fast modifications without destroying the original vector, because internally they're wide trees rather than just linear arrays of memory. This allows for assignments to be implemented without a copy of the full vector. https://hypirion.com/musings/understanding-persistent-vector...
It's certainly possible that what I encountered, labeled as an 'icicle graph', is a nonstandard usage of the term. But if so, that's a shame. I don't think inverting the y-axis is useful by itself, the different bucketing is what makes for an actually useful change.
I also like icicle graphs for this. They're flamegraphs, but aggregated in the reverse order. (I.e. if you have calls A->B->C and D->E->C, then both calls to C are aggregated together, rather than being stacked on top of B and E respectively. It can make it easier to see what's wrong when you have a bunch of distinct codepaths that all invoke a common library where you're spending too much time.)
Regular flamegraphs are good too, icicle graphs are just another tool in the toolbox.
A more common alternative to counting divs would be CSS classnames or (for unique elements on the page) IDs. You'd do `document.querySelector('.my-class')` to locate `<div class="my-class">` or similar, rather than using the fact that e.g. something is nested 3 divs inside <body>.
Even if this custom element trick didn't work, I don't see why one would need to count divs (at least if you control the markup, but if not then made-up tags aren't an option anyway). The article even mentions using class names as an option.