It’s Hackathon day 2, and I’ve nearly wrapped up my first draft of a pretty hacky system for editing documentation pages in ToolDocs. It’s fun learning the GitLab API, although that’s also making me question a bunch of assumptions I made about this project in the beginning! It’s seeming more like it’d be better to just build the whole thing as effectively a custom UI to GitLab. But we’ll see…
The Hackathon is starting soon.
I love the stuff about finding quiet places, in the latest #cardicast: https://newcardigan.org/cardicast-episode-87-bec-muir/
I finally installed Koreader!
Here’s some notes of what I did:
koreader-kobo-v2022.03.1.zipfrom https://github.com/koreader/koreader/releases and extracted to the root of the device.
Add the following to
Restarted, and it ended up back in the normal system. Oh, I didn’t follow the instructions… try again with downloading
OCP-KOReader-v2022.03.1.zipfrom that forum post, and extracting that to the root. Unmounted the device, and it did much more flashing and gurgling this time. When it restarted, there was a new Koreader item in the main menu! Wonderful.
To enable OPDS, go to the search menu (the magnifying glass icon) and down to “OPDS”. Then add a catalogue URL. Wikisource is https://ws-export.wmcloud.org/opds/en/Ready_for_export.xml — unfortunately, it seems the only way to get it in there is to type it in by hand, and I kept making mistakes. I tried three times before I realised that it was possible to long-press on a catalogue name to get to an edit dialogue.
Then, I had access to 45 pages of Wikisource’s works. Unfortunately, they’re in alphabetical order by title so it’s a bit weird to browse them in this way. But, still, it’s a terrific start and much easier than copying epubs from my laptop.
All in all, Koreader seems much much faster, and has many more features… and why didn’t I do this ages ago?!
I think I want a tool whereby I can compare the biography pages in ArchivesWiki with those on WikiTree and FamilySearch. Surely that wouldn’t be too hard.
The bio pages on the wiki already (mostly) have their external IDs defined. They’re in Cargo, so I think there’s probably a need for a parser function from the Genealogy extension, so these IDs can be saved as page properties and passed to the wiki-comparing code. It’d be a bit odd to have the Genealogy extension to go querying Cargo tables directly.
I’ve been wondering for a while how it’d be setting up a package on Packagist from Wikimedia’s GitLab… turns out it’s incredibly simple, and we now have wikimedia/toolforge-skeleton added and working! There’s still more to be done on it, but hopefully it’ll make it super quick to bootstrap the development of new PHP tools.
It seems to be Thursday morning again. The list of things for the week doesn’t seem to be any shorter, but there’s only one day of proper-work left! (Tomorrow begins the Wikimedia Hackathon.)
The dramas I’ve been having with my rear gear shifting have been resolved, so at least that’s good news. It seems my gut feeling was right: it felt like there was something preventing the derailleur from springing outwards, but I couldn’t figure it out. I lubed all cable sheaths, cleaned springs, pulled everything apart and put it back together clean and lubricated. But I’d underestimated the simplicity of the shifters (Microshift BS-A09 I think they are), and hadn’t realised that it’s actually perfectly correct to just loosen the bolt a bit. This frees up the mechanism, and allows the derailleur full control. Everything is nice again now.
Not that I’m particularly patriotic, but Sheldon Riley is great, and his performance for #Eurovision should get your vote.
The fediverse is a bit of a strange place: it’s like writing on one’s own site, because there’s this great culture of many small separate servers and communities, but it also is writing on someone else’s site, and with that comes a feeling of working within a community framework. That’s good, because it helps with keeping things reasonable and sometimes on-topic. But I do like the feeling of writing on my own site, where no one cares what I do (and yeah… no one reads it either!).
But still, it’s exciting that there are more and more people joining Mastodon and the others, and it’s nice to not feel like Twitter and Facebook are the extent of the web.
There was a post on Hacker News the other day about the etiquette of merging pull requests, especially ones that are maybe not as good as they could be. I really liked the idea that one should just merge work when it’s “good enough” — I think I can be a bit too nit-picking, and often leave reviews about minor stylistic concerns. Far better to merge sooner and follow up with cleanup patches. It’s only when cutting releases that the nit-picking should come out.
Of course, the counter argument is that a codebase can become more and more confused, and it be harder for people to understand what’s going on (leading to more confusing additions later, which will make the whole thing worse). I guess that’s the role of the maintainer: to reign things in, to keep the broad view, to ensure consistency across concerns. Maybe merging everything just makes that job harder, but it also encourages people to contribute, and people are more important than code.