Greg Hurrell [Sun, 5 Jun 2022 13:39:48 +0000 (15:39 +0200)]
chore: update "Programming languages" and "Tools" sections
- Reorder some things based on relevance/recency.
- Drop ReasonML, add Go; I don't have any significant projects released
in the former, and I should probably mention the latter because GitHub
itself uses it and I have a couple of projects in it.
Greg Hurrell [Thu, 25 Nov 2021 18:51:33 +0000 (19:51 +0100)]
refactor: apply one more tweak to silence ajv
Drop the problematic "date" format which only leads ajv to complain
about the input document not conforming, if we follow it's advice to set
the type to "number,string".
Now we have only one remaining warning:
strict mode: missing type "number,string" for keyword "format" at "#/properties/version" (strictTypes)
Greg Hurrell [Thu, 25 Nov 2021 18:31:30 +0000 (19:31 +0100)]
chore: fix most of the new strict mode warnings produced by ajv
Before:
strict mode: missing type "object" for keyword "properties" at "#" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#/properties/version" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#/properties/identity/properties/email" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#/properties/presence/properties/facebook" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#/properties/presence/properties/github" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#/properties/presence/properties/keybase" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#/properties/presence/properties/linkedin" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#/properties/presence/properties/stackoverflow" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#/properties/presence/properties/twitter" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#/properties/presence/properties/website" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#dateish/anyOf/0" (strictTypes)
strict mode: missing type "string" for keyword "pattern" at "#dateish/anyOf/1" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#dateish/anyOf/0" (strictTypes)
strict mode: missing type "string" for keyword "pattern" at "#dateish/anyOf/1" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#dateish/anyOf/0" (strictTypes)
strict mode: missing type "string" for keyword "pattern" at "#dateish/anyOf/1" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#/properties/publications/properties/items/items/properties/link" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#dateish/anyOf/0" (strictTypes)
strict mode: missing type "string" for keyword "pattern" at "#dateish/anyOf/1" (strictTypes)
strict mode: missing type "object" for keyword "required" at "#" (strictTypes)
strict mode: missing type "object" for keyword "additionalProperties" at "#" (strictTypes)
strict mode: missing type "object" for keyword "properties" at "#" (strictTypes)
After:
strict mode: missing type "number,string" for keyword "format" at "#/properties/version" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#dateish/anyOf/0" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#dateish/anyOf/0" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#dateish/anyOf/0" (strictTypes)
strict mode: missing type "number,string" for keyword "format" at "#dateish/anyOf/0" (strictTypes)
I'm not going to fix the last ones because doing so would definitely
make my life worse. In my YAML I have date-ish items like:
version: 2021-05-07
from: 2021-06
to: 2011
ajv says these aren't strings but numbers (and fair enough for the last
one, but the first two look like they could be strings). So, I can say
that version must always be `"type": "string"` and that works fine if I
enclose it in quotes in the YAML file (although it seems needlessly
ugly), but otherwise causes a runtime error with:
Input YAML does not conform to the schema
Further trouble starts if I say the date-ish things should be numbers or
strings; then I get a litany of warnings that I can't be bothered sorting
through right now:
strict mode: use allowUnionTypes to allow union type keyword at "#dateish/anyOf/0" (strictTypes)
... repeated once for each place that I use date-ish ...
And I certainly don't want to go sprinkling quotes all through the YAML
to force them all to be strings (for reference, Ruby's YAML parses
things like `2021-05-07` as a string automatically, and my JS is already
calling `toString()` on these things).
So, I'm just going to tolerate the noise. I will turn off strict mode if
the complaining annoys me. I usually don't mind strictness (I am using
JSON Schema, after all), but here it just seems uselessly bothersome. Oh
well.
Greg Hurrell [Thu, 25 Nov 2021 18:09:21 +0000 (19:09 +0100)]
fix: make JSON schema validation work again
OK, so I lied a couple of commits ago (97ecf43) when I said I didn't
think I would be affected by breaking changes in the ajv package.
According to the docs here:
https://ajv.js.org/guide/formats.html
you now need to install a separate package.
> From version 7 Ajv does not include formats defined by JSON Schema
> specification - these and several other formats are provided by
> ajv-formats plugin.
Another glorious triumph of modularization! My life is better for this
change.
With this change, all my `"format": "date"` and `"format": "email"`
(etc) schema elements work again, and we don't see this error during
build:
Error: unknown format "date" ignored in schema at path "#/properties/version"
Still spewing out a bunch of warnings because "strict mode" is on by
default now, but the build still works, and I can deal with the errors
in a separate commit.
Pleasantly surprised by how easy this it: "anyOf" in the JSON schema
allows us to have uniform or localized items, and our `localize()`
helper transforms the data structure for us so that we only have to
worry about strings.
Greg Hurrell [Sun, 14 Oct 2018 19:39:12 +0000 (21:39 +0200)]
Move progress printing down into main build loop
This keeps the printing calls closer to each other, and makes the
`build()` function have a single purpose (writing built output) instead
of two (writing built output and printing progress).
Greg Hurrell [Sat, 13 Oct 2018 15:31:31 +0000 (17:31 +0200)]
Fix mangled display in "Awards" section
The extra positional argument to the `forEach` function evidently was
changing the behavior of the underlying `text` function when it got
passed through as options.
Greg Hurrell [Sat, 13 Oct 2018 08:19:46 +0000 (10:19 +0200)]
Remove manual "collapse" hack
In writing the code to rollback unwanted pagebreaks (which involves
keeping a journal of all "commands" issued to build up the document), I
noticed I could get rid of the ugly manual "collapse" hack.
Whenever we emit a subheading, we can now automatically slurp up
preceding whitespace if the previous item was a heading.
The `args` property in the command journal isn't used in this
commit, but it will be in the future, when we use it to replay commands
after "rewinding" the output and inserting a page break in a better
place.
Greg Hurrell [Fri, 12 Oct 2018 21:35:08 +0000 (23:35 +0200)]
Add "full" output variants
This one includes, for now, a new "Awards" section. I'm not going to
link to this from anywhere because I don't think the section is very
useful, and it also pushes the PDF version onto two pages (in the
"private" variants, which have a taller header, and also in the Spanhish
"public" variant), which I'll need to address.
Greg Hurrell [Tue, 2 Oct 2018 20:23:39 +0000 (22:23 +0200)]
publish: warn if publishing an empty commit
As noted in the parent commit, there *may* be reasons why you would want
to do this, but it is more likely a mistake, so print a big red warning
out along with instructions on how to undo the commit if desired.
Greg Hurrell [Tue, 2 Oct 2018 20:08:55 +0000 (22:08 +0200)]
publish: properly show empty commits
When you create an empty commit on the gh-pages branch (for example, by
running `npm run publish` twice in a row, or by forgetting to run `npm
run build`), `git whatchanged` misbehaves (maybe, depending on your
point of view) compared to `git log`: the former skips the empty commit
and shows the parent commit instead, but `git log` will dutifully show
the empty commit.
Swap out `git whatchanged` for `git log --raw`, which has basically the
same output but doesn't skip empty commits. It's important that we show
empty commits because to give the user a chance to see and correct their
mistake (if it is a mistake; I can imagine you might want to push an
empty gh-pages commit to force a rebuild on the GitHub side). Ideally,
we would explode loudly for empty commits (the user could always just do
`git commit --allow-empty` if they really wanted), but I don't think
there is a built-in way to do that with `git-commit-tree`; to add such a
check I think I'd need to construct an explicit `git diff --quiet` test,
but I am not sure I can be bothered with that for now.
(Discovered this issue while testing changes to the `publish` script.)
Greg Hurrell [Tue, 2 Oct 2018 19:55:44 +0000 (21:55 +0200)]
gh-pages: note source commit hash probably* used to build
Only "probably" used, because there are no guarantees that the person
who invokes `npm run publish` didn't change the work-tree and checked
out revision after running `npm run build`. Still, the odds are pretty
good.
if you have been naughty and are publishing without committing first.
Otherwise it will just output a hash (because there are no tags in this
repo for `git describe` to find).
Note one bit of trickiness here: the file doesn't define "languages"
like the cv.yml file does; we copy that over at runtime, and we rely on
it in the schema to ensure that we are validating against the same set
of languages in both files.
Works around: https://github.com/foliojs/pdfkit/issues/868
As described in that issue, if you generate the same PDF twice in a row
you'll get two different docs, and in my use case here (writing PDFs to
the "gh-pages" branch) that can produce noisy diffs.
Work around it by (gasp) replacing `Math.random` with something
deterministic.
Now, we'll only get a different output when I change something that
affects the output. This means that to bump the "release version" of the
PDF (ie. the `ModDate`), I have to update the `version` property in the
YAML. I'm ok with that.
Make header() method non-destructive in all renderers
Calling it more than once, or calling it in the HTML renderer after
emitting something else, would still be a bad idea, but the mistake
would be easily noticed in the output.
This brings the remaining renderers into line with the behavior of the
PDF renderer.