chriskrycho.com
The fifth version of chriskrycho.com, built in Eleventy.
a11y of `note` sections.
I'd like to iterate on this by adding a "block" which just does this!
+48
-51
+2
-2
alternative formats/Ember Template Imports/Part 0.md
+2
-2
alternative formats/Ember Template Imports/Part 0.md
···
24
24
[eti]: https://github.com/ember-template-imports/ember-template-imports
25
25
[strict]: https://emberjs.github.io/rfcs/0496-handlebars-strict-mode.html
26
26
27
-
<div class='note'>
27
+
<section class='note' aria-label='note' aria-role='note'>
28
28
29
29
It’s important to say before I jump in: these are *my* opinions. They’re *not* official LinkedIn positions, and in fact I have a number of colleagues who disagree with me about some of these things! I’m writing this series to persuade any and all members of the Ember community, including other people at LinkedIn.
30
30
31
-
</div>
31
+
</section>
32
32
33
33
While each of these has its own upsides and downsides, I believe `<template>` is far and away the best choice, because of its wins for teaching and understanding, scaling, and testing. In this series, I will do my best to present an even-handed analysis that shows how and why I came to that conclusion over the last few years of thinking about it.
34
34
+1
-1
alternative formats/Ember Template Imports/Part 1.md
+1
-1
alternative formats/Ember Template Imports/Part 1.md
···
11
11
12
12
In this first post, I will introduce each of the options and give a high-level overview of what I take the tradeoffs in the design space to be. In the following posts, I will cover **Teaching and Understanding**, **Tooling**, and **Testing**. In a final post, I will summarize the tradeoffs once more.
13
13
14
-
<section class="note" aria-label="note">
14
+
<section class='note' aria-label='note' aria-role='note'>
15
15
16
16
It’s important to say before I jump in: these are *my opinions*. They’re *not* official LinkedIn positions, and in fact I have a number of colleagues who disagree with me about some of these things! I’m writing this series to persuade any and all members of the Ember community, including other people at LinkedIn.
17
17
+1
-1
alternative formats/Ember Template Imports/Part 2.md
+1
-1
alternative formats/Ember Template Imports/Part 2.md
···
61
61
62
62
So: which of the template import designs is the best move for us in terms of teaching and learning, especially when keeping in mind the idea of progressive disclosure of complexity and the principle of least astonishment?
63
63
64
-
<section class="note" aria-label="note">
64
+
<section class='note' aria-label='note' aria-role='note'>
65
65
66
66
In the discussion which follows, I’m using `.js` in every import, and I’ll be going back to update part 1 in the post to do this as well. This might be surprising, but there’s a reason for it: this matches the <abbr title="ECMAScript">ES</abbr> Modules spec as implemented in Node 12+, and is therefore what ecosystem tooling (including the TypeScript Language Server) expects. We may choose as a community to layer on custom tooling to reinterpret other extensions to resolve and therefore be less surprising! However, that carries some risks as well as additional implementation effort, and this also serves to highlight some of the tradeoffs in this space nicely.
67
67
+1
-1
alternative formats/Ember Template Imports/Part 3.md
+1
-1
alternative formats/Ember Template Imports/Part 3.md
···
18
18
- something like Svelte’s and Vue’s SFC format
19
19
- an imports-only extension of the current format
20
20
21
-
<section class="note" aria-label="Note">
21
+
<section class='note' aria-label='note' aria-role='note'>
22
22
23
23
In those previous posts, I said Part 3 was going to be about **Scaling**. However, I think it’s more useful to talk about **Tooling** here. As I have kept working on this series, I’m not actually persuaded that there are particularly meaningful differences between these approaches for scaling codebases which aren’t subsumed in the other topics—especially teaching and testing. So: tooling it is!
24
24
+1
-1
alternative formats/Ember Template Imports/Part 5.md
+1
-1
alternative formats/Ember Template Imports/Part 5.md
···
26
26
27
27
***All of these work perfectly well with any of the template imports proposals.*** This is the reason I originally left this aside, and it’s also the reason this is the shortest of the posts. The templating layer is a fundamental part of a front-end framework: it is *the* thing a front-end framework *must* do. By contrast, a framework can be styling-method-agnostic. Frameworks certainly can provide first-class primitives for it—as Vue and Svelte do—but it is not a necessary constraint for the integration of *state change* with *<abbr title="document object model">DOM</abbr> updates*, unlike templating.
28
28
29
-
<section class='note' aria-label="Note">
29
+
<section class='note' aria-label='note' aria-role='note'>
30
30
31
31
This is by no means to diminish the importance of styling, which I take to be an under-appreciated element of truly great web applications. It is rather to make clear and explicit what constraints it does and doesn’t face compared to templates.
32
32
+2
-2
site/journal/2019/twitter-bots-and-decline.md
+2
-2
site/journal/2019/twitter-bots-and-decline.md
···
33
33
34
34
What is more, though: I do not think those attendant ills, real and serious though they are, represent the full extent of the outcome of Twitter bots. Neither do I think that Twitter bots have created, undirected, out of the air, the malaise so many people feel. Insofar as some of these problems are “only perception,” that remains a real problem; but more than that, the bots are amplifying pre-existing problems, at the behest of their makers. We owe it to each other to say this clearly and truthfully—to hold accountable those who make and employ these technologies, and to counter their effects.
35
35
36
-
<div class=note>
36
+
<section class='note' aria-label='note' aria-role='note'>
37
37
38
38
Stephen has since responded with a very thoughtful piece: [On Twitter Bots and the Presence of Disinformation][response]. This paragraph in particular gets quite clearly at both what I aimed to get at on the episode and what I gestured at a bit above:
39
39
···
41
41
42
42
I commend [the whole post][response] to you.
43
43
44
-
</div>
44
+
</section>
45
45
46
46
[Winning Slowly 7.13]: https://www.winningslowly.org/7.13/
47
47
[Stephen]: https://stephencarradini.com
+2
-2
site/journal/2020/Async Data and Autotracking in Ember Octane.md
+2
-2
site/journal/2020/Async Data and Autotracking in Ember Octane.md
···
65
65
66
66
It’s important particularly—though not only!—in dealing with user interfaces that we account for *all* of these scenarios. If we don’t, we might end up assuming that our data is always in a loaded state, and fail to show anything meaningful while it’s loading, or if there’s an error. At *best* this makes for a poor user experience. At worst, the result can be outright buggy! So this implementation exposes (and encourages you to think in terms of!) those states: `loading`, `loaded`, and `error`.[^1]
67
67
68
-
<section class="note" aria-label="note">
68
+
<section class='note' aria-label='note' aria-role='note'>
69
69
70
70
This idea is far from original to me or my colleagues. I learned it from a series of talks and blog posts around the idea of “making illegal states impossible,” an idea which has a lot of traction in the typed functional programming community.
71
71
···
732
732
733
733
As long-time readers of this blog (and many folks in the Ember community) know, I’m a huge advocate of TypeScript. I’m particularly a fan of using types to guarantee that our data is *always* in a valid state. In the implementation of `AsyncData` as we have it, we *do* always have data in a valid state—but that’s just because we’ve been careful, and our end users can pretty easily interact with `AsyncData` in unsafe ways. What might it look like to make it so that we can never *construct* invalid data, and so that our end users need to interact more safely with the data?
734
734
735
-
<section class="note" aria-label="note">
735
+
<section class='note' aria-label='note' aria-role='note'>
736
736
737
737
For this example, I am *assuming* rather than *explaining* the TypeScript features in use.
738
738
+3
-3
site/journal/2020/Data Constructors Part 1 Understanding by Implementing.md
+3
-3
site/journal/2020/Data Constructors Part 1 Understanding by Implementing.md
···
144
144
145
145
People with backgrounds in languages like Java, C^♯^, or TypeScript often find it hard to translate the syntax we’ve just walked through into concepts they know. That’s totally fair: it’s pretty different, and it’s not *just* new syntax, it’s also new language features tied to that syntax. In this section, we’ll see how we could implement the exact same semantics in a language that’s more familiar, and hopefully that will help make sense of things.
146
146
147
-
<section class="note" aria-label="note">
147
+
<section class='note' aria-label='note' aria-role='note'>
148
148
149
149
I’m using TypeScript here because it’s the language in this family I’m most familiar with, but I’m going to keep it to a minimal subset of TypeScript that is extremely close to what you might see in Java or C^♯^. I’ll be using footnotes here to talk about some details around TypeScript itself, where Typescript can let us more directly approximate the things happening in languages like Grain, Elm, etc. However, those are footnotes for a reason: you don’t *need* to read or understand them to get the point of the rest of this post!
150
150
···
262
262
263
263
We can solve this problem *and* get ourselves to something that looks a lot more like the syntax we’re aiming for in one fell swoop: by making our constructor `private` and providing other ways to create a `Veggie` which are guaranteed to be safe.
264
264
265
-
<section class="note" aria-label="note">
265
+
<section class='note' aria-label='note' aria-role='note'>
266
266
267
267
This is the part where people who are already familiar TypeScript with have to wait for the next post. There are ways we can make this *much* more type-safe. That's not the point of *this* post, though! Here, we’re intentionally sticking to a “lowest common denominator” implementation to get at how we can do this in *any* class-based language.
268
268
···
451
451
452
452
*All* we’ve done here is require the caller to pass us an object with names which match the names of the `VeggieKind` variants. The values on that object are either values of the desired resulting type `T` in the case of `Squash` and `Broccoli`, or a function which takes a `CabbageColor` and returns that same resulting type of `T`. Within the body of the `match` method, we return whichever one corresponds to `this.kind`.
453
453
454
-
<section class="note" aria-label="note">
454
+
<section class='note' aria-label='note' aria-role='note'>
455
455
456
456
Notice the `// SAFETY: ...` comment I added when using the non-null assertion operator `!` with `this.color`. I borrowed this idea from the Rust community, which marks all uses of `unsafe` with these kinds of comments. I use it *any time* I write a cast in TypeScript, for the sake of whoever is maintaining the code in the future… including future *me*. It’s important to know what might make a cast unsafe! For a way to not need this comment at all by having better safety, you’ll want to read the *next* post.
457
457
+1
-1
site/journal/2020/Data Constructors Part 2 Better TypeScript.md
+1
-1
site/journal/2020/Data Constructors Part 2 Better TypeScript.md
···
420
420
421
421
*[JS]: JavaScript
422
422
423
-
<section class="note" aria-label="note">
423
+
<section class='note' aria-label='note' aria-role='note'>
424
424
425
425
It’s important to understand what types do *not* (and cannot!) buy us here as well as what they *do* buy us. They’ve helped us guarantee that we always have a valid shape to our data. But if we wire up our static constructors incorrectly, we will still end up with broken code. Nothing about our types here stops us from writing this horribly broken implementation, after all:
426
426
+1
-1
site/journal/2020/Ember Octane is a New Mental Model.md
+1
-1
site/journal/2020/Ember Octane is a New Mental Model.md
···
22
22
23
23
---
24
24
25
-
<section class="note" aria-label="note">
25
+
<section class='note' aria-label='note' aria-role='note'>
26
26
27
27
Over the weekend I wrote up the following on [an Ember RFC discussion](https://github.com/emberjs/rfcs/pull/669#issuecomment-739320902). Since it’s intentionally *not* specific to that RFC, I’m republishing it here for the broader Ember community to see, with only the slightest tweak to the intro to give more context. (It might be a bit less polished than usual, as a result!)
28
28
+1
-1
site/journal/2020/Git Workflow for Managing Long-Running Upgrades A.md
+1
-1
site/journal/2020/Git Workflow for Managing Long-Running Upgrades A.md
···
343
343
344
344
—but sometimes this kind of thing is out of your control, as it was out of mine last year. I hope if you find yourselves in the same spot I found myself last August, you now have a good handle on some of the ways you can manage this kind of large, long-running task effectively!
345
345
346
-
<section class="note" aria-label="note">
346
+
<section class='note' aria-label='note' aria-role='note'>
347
347
348
348
Two addenda:
349
349
+1
-1
site/journal/2020/Initializing Class Fields in Ember Octane.md
+1
-1
site/journal/2020/Initializing Class Fields in Ember Octane.md
+3
-3
site/journal/2020/Making Illegal States Unrepresentable in TS.md
+3
-3
site/journal/2020/Making Illegal States Unrepresentable in TS.md
···
48
48
};
49
49
```
50
50
51
-
<section class="note" aria-label="note">
51
+
<section class='note' aria-label='note' aria-role='note'>
52
52
53
53
For scenarios like this where the `constructor` does nothing but set up some properties with values passed in, TypeScript provides a constructor-only shorthand which looks like this:
54
54
···
116
116
}
117
117
```
118
118
119
-
<section class="note" aria-label="note">
119
+
<section class='note' aria-label='note' aria-role='note'>
120
120
121
121
That’s not an *especially* robust validation of emails, but it’s sufficient for the rest of this example.
122
122
···
265
265
266
266
We can add a method to the `Contact` type which does this correctly.
267
267
268
-
<section class="note" aria-label="note">
268
+
<section class='note' aria-label='note' aria-role='note'>
269
269
270
270
There are two ways we could make this method work: it could change the item it’s working with, or it could return a new copy of the item instead. In this example, I’m treating classes not as bundles of self-contained mutable state, but as lightweight records, so I’m going to return a fresh copy. Maybe [someday][proposal-record-tuple] JavaScript will actually get native records (and tuples)!
271
271
+1
-1
site/journal/2020/Migrating Off of PromiseProxyMixin in Ember Octane.md
+1
-1
site/journal/2020/Migrating Off of PromiseProxyMixin in Ember Octane.md
···
64
64
}
65
65
```
66
66
67
-
<section class="note" aria-label="note">
67
+
<section class='note' aria-label='note' aria-role='note'>
68
68
69
69
Here we’re relying on the fact that `args` are auto-tracked: this getter consumes `this.args.id`, so it’ll rerun any time the component is invoked with a new `id`. In a classic Ember component, you might see `@computed('id')` to update whenever the `id` argument updated.
70
70
+1
-1
site/journal/2020/On Saints.md
+1
-1
site/journal/2020/On Saints.md
···
15
15
16
16
---
17
17
18
-
<section class="note" aria-label="note">
18
+
<section class='note' aria-label='note' aria-role='note'>
19
19
20
20
With this post I’m starting something new: whenever someone asks me a question—in email, in Slack, etc.—which I think might be interesting to readers, I’ll make a point to share it here as well; you’ll find them all under the [Q & A topic][Q&A]. I may of course tweak the content from my response to that person—elaborating on a point that requires more context, eliding personal details, etc. Enjoy!
21
21
+1
-1
site/journal/2020/Superscript and Subscript Line Heights.md
+1
-1
site/journal/2020/Superscript and Subscript Line Heights.md
+1
-1
site/journal/2020/Ulysses Publishing With WordPress on Linode.md
+1
-1
site/journal/2020/Ulysses Publishing With WordPress on Linode.md
···
45
45
46
46
[^xml-rpc-api]: If you’re thinking that it would be really nice if WordPress offered a modern JSON API instead of being stuck with XML-RPC, well… I’m with you.
47
47
48
-
<section class="note" aria-label="note">
48
+
<section class='note' aria-label='note' aria-role='note'>
49
49
50
50
A correction from [a reader][jws]! WordPress [*does* have a JSON API][wp-api], and has for almost half a decade now! I have *no idea* why Ulysses is using XML-RPC instead of that API; at first blush [it certainly looks like it could][wp-api-post]. My bad for not checking this and just assuming the problem was on WordPress’ end rather than Ulysses’.
51
51
+1
-1
site/journal/2020/find grep xargs newlines null.md
+1
-1
site/journal/2020/find grep xargs newlines null.md
···
18
18
19
19
---
20
20
21
-
<section class="note" aria-label="note">
21
+
<section class='note' aria-label='note' aria-role='note'>
22
22
23
23
See [the follow-up](/journal/follow-up-on-command-line-finding-and-filtering/) post, in which I show an easier and faster way of doing this… as long as you have the GNU versions of the utilities, or alternatives like [ripgrep].
24
24
+1
-1
site/journal/2021/2022 Colfax Half Plan.md
+1
-1
site/journal/2021/2022 Colfax Half Plan.md
···
24
24
25
25
I mapped out my rough plan for the season while on an easy aerobic run earlier, and figured I’d share it here, as being of potential interest for other runners out there.
26
26
27
-
<section class="note" aria-label="Note">
27
+
<section class='note' aria-label='note' aria-role='note'>
28
28
29
29
This is a *serious-but-amateur* training plan for a half marathon. If you’ve never run a half marathon before, I highly recommend finding a different plan. You can train up to a half reasonably well in 3 months, with a much lower work load than this. The point of *this* plan is for me to perform well enough to get another top-50 finish. It is *hard*. By the end of the season, I will be running \~45 miles/week, with about a third of that being hard speed and tempo work.
30
30
+2
-2
site/journal/2022 in Review/The Rest of Life.md
+2
-2
site/journal/2022 in Review/The Rest of Life.md
···
83
83
84
84
I haven’t talked a lot about finances publicly in the past, because I haven’t really been sure *how* to do so in a way that does not seem boastful or risk making others feel bad, but I *want* to start doing so in a measured and hopefully helpful way in the future. I was able to have a couple good conversations with other folks in tech in particular because of my role as a well-compensated senior engineer, and I think it’s valuable for a host of reasons to talk about finances in a Christian way—especially in the context of helping others think about their own finances, opportunities and challenges presented by financial “success” of whatever degree, and so on.
85
85
86
-
<div class=note>
86
+
<section class='note' aria-label='note' aria-role='note'>
87
87
88
88
I am not currently at a point where I want to broadcast my finances here—that is just deeply fraught in a host of ways—but I am very glad to have *very* frank conversations about compensation and how we think about money and how we are trying to manage a modicum of wealth in a God-honoring way; feel free to get in touch.
89
89
90
-
</div>
90
+
</section>
91
91
92
92
The big thing for us this year was that we paid off our house, exactly four years after we bought it, courtesy of the aforementioned excellent compensation from LinkedIn. I continue to find that astonishing. I do not take it for granted for one second, and I do not necessarily expect the market for software engineers to stay this hot long-term or even medium-term. Indeed, my expectation of *some* sort of shift around software compensation is one reason we prioritized paying it off so quickly.
93
93
+2
-2
site/journal/2022/Dorico Tip – solo parts in string sections.md
+2
-2
site/journal/2022/Dorico Tip – solo parts in string sections.md
···
44
44
[d]: https://www.steinberg.net/dorico/
45
45
[dd]: https://steinberg.help/dorico_pro/v4/en/dorico/topics/notation_reference/notation_reference_divisi/notation_reference_divisi_c.html
46
46
47
-
<div class='note'>
47
+
<section class='note' aria-label='note' aria-role='note'>
48
48
49
49
It is important to make sure **View** > **Signposts** > **Divisi** is selected before starting this process. In my experience, it is not possible to do the rest of this sequence successfully otherwise!
50
50
51
-
</div>
51
+
</section>
52
52
53
53
1. Add a new *divisi* section where you want the solo to start, with **Edit** > **Notations** > **Staff** > **Change Divisi** (or trigger the [Jump Bar][j] and type “Change Divisi”).
54
54
+2
-2
site/journal/2022/Patterns for Smart Components in Ember.md
+2
-2
site/journal/2022/Patterns for Smart Components in Ember.md
···
16
16
17
17
---
18
18
19
-
<div class=note>
19
+
<section class='note' aria-label='note' aria-role='note'>
20
20
21
21
I’m experimenting with just publishing things I write up for work with only a minimum of extra context and editing so they live *somewhere* outside our work Slack account and have a chance of being useful to others. Expect these to be extra off-the-cuff!
22
22
23
-
</div>
23
+
</seciton>
24
24
25
25
There is a lot of legacy Ember Classic code out there which used “smart” components for data loading. In many cases, that initialization ran in an old `init` hook, or sometimes a `didReceiveAttrs` or similar hook. In all cases, this model is incompatible with the Ember Octane programming model (and with any strict “data down, actions up” or one-way data flow paradigm).
26
26
+2
-7
site/journal/2022/creation incarnation art vocation.md
+2
-7
site/journal/2022/creation incarnation art vocation.md
···
11
11
Theologically-orthodox Christians, or at least folks interested in things that theologically-orthodox Christians think; and specifically those interested in.
12
12
epistemic: >
13
13
Still mulling, 6 years later.
14
-
14
+
context: >
15
+
I came across this in my notes by hitting the “show me a random note” button in [Obsidian](https://obsidian.md) this evening, and I was glad to come back across it; I’m sharing it straight out of my notes (unedited save to add a link to the book it references) in the hope it may be thought-provoking to you as well.
15
16
---
16
-
17
-
<div class="note">
18
-
19
-
I came across this in my notes by hitting the “show me a random note” button in [Obsidian](https://obsidian.md) this evening, and I was glad to come back across it; I’m sharing it straight out of my notes (unedited save to add a link to the book it references) in the hope it may be thought-provoking to you as well.
20
-
21
-
</div>
22
17
23
18
Stealing a page from Torrance’s [<cite>The Trinitarian Faith</cite>](https://bookshop.org/a/21126/9780567292193), p. 102: with creation and incarnation as two parts of a whole, how do we reflect *rightly* on the nature of vocation and especially creative action (including but not limited to what we call ‘art’)?
24
19
+1
-1
site/journal/Ember Template Imports/Part 1.md
+1
-1
site/journal/Ember Template Imports/Part 1.md
···
21
21
22
22
In this first post, I will introduce each of the options and give a high-level overview of what I take the tradeoffs in the design space to be. In the following posts, I will cover **Teaching and Understanding**, **Tooling**, and **Testing**. In a final post, I will summarize the tradeoffs once more.
23
23
24
-
<section class="note" aria-label="note">
24
+
<section class='note' aria-label='note' aria-role='note'>
25
25
26
26
It’s important to say before I jump in: these are *my opinions*. They’re *not* official LinkedIn positions, and in fact I have a number of colleagues who disagree with me about some of these things! I’m writing this series to persuade any and all members of the Ember community, including other people at LinkedIn.
27
27
+1
-1
site/journal/Ember Template Imports/Part 2.md
+1
-1
site/journal/Ember Template Imports/Part 2.md
···
89
89
90
90
So: which of the template import designs is the best move for us in terms of teaching and learning, especially when keeping in mind the idea of progressive disclosure of complexity and the principle of least astonishment?
91
91
92
-
<section class="note" aria-label="note">
92
+
<section class='note' aria-label='note' aria-role='note'>
93
93
94
94
In the discussion which follows, I’m using `.js` in every import, and I’ll be going back to update part 1 in the post to do this as well. This might be surprising, but there’s a reason for it: this matches the <abbr title="ECMAScript">ES</abbr> Modules spec as implemented in Node 12+, and is therefore what ecosystem tooling (including the TypeScript Language Server) expects. We may choose as a community to layer on custom tooling to reinterpret other extensions to resolve and therefore be less surprising! However, that carries some risks as well as additional implementation effort, and this also serves to highlight some of the tradeoffs in this space nicely.
95
95
+1
-1
site/journal/Ember Template Imports/Part 3.md
+1
-1
site/journal/Ember Template Imports/Part 3.md
···
41
41
- something like Svelte’s and Vue’s SFC format
42
42
- an imports-only extension of the current format
43
43
44
-
<section class="note" aria-label="Note">
44
+
<section class='note' aria-label='note' aria-role='note'>
45
45
46
46
In those previous posts, I said Part 3 was going to be about **Scaling**. However, I think it’s more useful to talk about **Tooling** here. As I have kept working on this series, I’m not actually persuaded that there are particularly meaningful differences between these approaches for scaling codebases which aren’t subsumed in the other topics—especially teaching and testing. So: tooling it is!
47
47
+2
-2
site/journal/Ember Template Imports/_index.md
+2
-2
site/journal/Ember Template Imports/_index.md
···
19
19
[eti]: https://github.com/ember-template-imports/ember-template-imports
20
20
[strict]: https://emberjs.github.io/rfcs/0496-handlebars-strict-mode.html
21
21
22
-
<div class='note'>
22
+
<section class='note' aria-label='note' aria-role='note'>
23
23
24
24
It’s important to say before I jump in: these are *my* opinions. They’re *not* official LinkedIn positions, and in fact I have a number of colleagues who disagree with me about some of these things! I’m writing this series to persuade any and all members of the Ember community, including other people at LinkedIn.
25
25
26
-
</div>
26
+
</section>
27
27
28
28
While each of these has its own upsides and downsides, I believe `<template>` is far and away the best choice, because of its wins for teaching and understanding, scaling, and testing. In this series, I will do my best to present an even-handed analysis that shows how and why I came to that conclusion over the last few years of thinking about it.
29
29
+1
-1
site/journal/Fanfare for a New Era of American Spaceflight/day-5.md
+1
-1
site/journal/Fanfare for a New Era of American Spaceflight/day-5.md
···
26
26
27
27
That’s for another time, though. For now, I’ve contented myself with just making *some* progress on this next section. I had, frankly, a pretty bad day personally today—but I refuse to let that be the final note (no pun intended) for this project, and hammered away at getting some of the ideas I was working with last night and today into Dorico. It’s nothing great, but it’s *something*, and I'll take that.
28
28
29
-
<section class="note" aria-label="note">
29
+
<section class='note' aria-label='note' aria-role='note'>
30
30
31
31
I wrote the next two paragraphs… and then ended up making more progress. Read these for context, because the point of this whole series is that it’s capturing how works-in-progress work—and then jump down past the break to see what happened later in the day!
32
32
+3
-1
site/journal/content-test.md
+3
-1
site/journal/content-test.md
···
51
51
52
52
An armchair is an armchair from the right perspective. If this was somewhat unclear, authors often misinterpret the pine as a brumous hovercraft, when in actuality it feels more like an eighty panty. A colt is an adapter's inventory.
53
53
54
-
<section class="note" aria-label="note">
54
+
<section class='note' aria-label='note' aria-role='note'>
55
+
55
56
‘A believe can hardly be considered a `beamish windchime` without also being a boot. However, few can name a hateful flight that isn't a jetty digestion. They were lost without the prolate bumper that composed their panty.’
57
+
56
58
</section>
57
59
58
60
```python
+1
-1
site/journal/rewrite/003.md
+1
-1
site/journal/rewrite/003.md
···
16
16
17
17
---
18
18
19
-
<section class="note" aria-label="note">
19
+
<section class='note' aria-label='note' aria-role='note'>
20
20
21
21
You may notice in the URL that this is entry `003`. That’s because I [started this back on v4][v4] of this site. Previous entries (retroactively numbered):
22
22
+1
-1
site/library/Eccentric Existence/Tell Me Your Priors.md
+1
-1
site/library/Eccentric Existence/Tell Me Your Priors.md
···
17
17
18
18
---
19
19
20
-
<section class="note" aria-label="note">
20
+
<section class='note' aria-label='note' aria-role='note'>
21
21
22
22
I’m starting something new with this post: public reflections and commentary on the things I’m reading. The idea here is to model and encourage a more readerly, more thoughtful, more research-oriented world, to whatever small degree and in whatever small way I can—as well as to expose those of you out there following along to the more interesting things I come across. These kinds of posts are far from the totality of my notes on whatever I’m reading; they’re a carefully-chosen selection of my thoughts and comments that are designed to be *publicly fruitful*. (My notes in general ramble and dither and are just generally not at all worth publishing!) As with my writing in general, I’m under no illusions that I’m going to change the world with this. Perhaps, however, I can make some corner of it a *little* bit better.
23
23
+1
-1
site/library/Politics and the Order of Love/_index.md
+1
-1
site/library/Politics and the Order of Love/_index.md
···
8
8
9
9
---
10
10
11
-
<section class="note" arial-label="note">
11
+
<section class='note' aria-label='note' aria-role='note'>
12
12
13
13
[Cool <abbr title="universal resource identifier">URI</abbr>s don’t change][uris], but in this case I *did* (sadly) have to relocate one file to make this collection work. The review of the book now lives [here][review], and I’ve changed how I approach these things so it won’t happen in the future!
14
14
+1
-1
site/library/Tiamats Wrath.md
+1
-1
site/library/Tiamats Wrath.md
···
31
31
32
32
On this read-through, a couple things caught my attention—little notes about the way the world is built and the story told that I hadn’t noticed on previous reads.
33
33
34
-
<section class="note" aria-label="note">
34
+
<section class='note' aria-label='note' aria-role='note'>
35
35
36
36
Minor spoilers for the series up through <cite>Tiamat’s Wrath</cite> follow, inevitably. Don’t read this if you want to read the series and don’t want to be spoiled.
37
37
+1
-1
site/pages/cv.md
+1
-1
site/pages/cv.md
···
9
9
10
10
Even the best résumés leave a lot to be desired: they lack context and narrative. If you’d like a better idea of how I work, I think you’ll find the rest of this page a lot more helpful.
11
11
12
-
<section class="note" aria-label="note">
12
+
<section class='note' aria-label='note' aria-role='note'>
13
13
14
14
I’m not looking to change jobs at this point—but you’re still welcome to [say hello][email]!
15
15