Given that for a good chunk of this year I've been a bit lax about writing here, there's a couple or so coding projects I've not written about (well, not on here anyway -- I have spoken lots about them over on Fosstodon). One such project is textual-canvas.

As the name might suggest, it's a "canvas" for Textual applications, which provides a pretty basic interface for drawing pixels, lines and circles -- and of course any other shape you are able to build up from those basics.

I've just released a quick update after it was requested that I add a clear method to the Canvas widget; a request that makes perfect sense.

This week, on Monday gone in fact, we moved office. We've now got a bigger space and, as part of that, bigger desks. Somewhat (but not entirely) coincidentally the work desk will also convert into a standing desk¹. Also also... I inherited a second screen for the desk too. Ever since the days of CRTs and video cards that supported it, I've been a fan of having at least a couple of screens in front of me, and now at my work desk I've got 3 (two external displays and the display of the MacBook Pro itself).

This caused a slight problem though: horizontally there's quite the spread of things to look at. This is fine, mostly I'm looking at the screen that's in front of me; the MacBook is to the left and the "second" screen is to the right, both with "other" stuff on them. In front of me is Emacs and my browser, which I flip between lots.

The problem is this: the MacBook needs to go to the left (because of physical layout), which means that despite me setting the screen in front of me as the "main" screen, the Cmd-Tab display (you know the thing: when you hit Cmd-Tab you see the icons of all your active applications) appears on the left-most display, which is the MacBook.

Not great. If I'm looking at the right-most display, and want to switch using the keyboard, I've got to look over to the left, as a worst case. That makes for a lot of unnecessary head-swivelling.

One quick Google later and Today I Learnt that the following pretty much solves the problem:

$ defaults write com.apple.Dock appswitcher-all-displays -bool true
$ killall Dock

As the name of the setting would suggest: once done, the switcher appears on all displays.

That's perfect.

While I'm still in blog-tinkering mode (long may it last!), I thought it might be handy to keep a page kicking around that has links to the small collection of "dot file" repositories I have.

Like many people, I keep these in a central location (in my case up on GitHub) so that I can very quickly spin up a familiar work environment on a new machine (new machines are something that doesn't happen too often, but it's always good to be able to get going quickly when it does).

So, depending on browser type/size, either above here or off to the side, there should now be a permanent link to a page of links to those repositories.

As I look at it now it's actually surprising to me how much of my "comfortable" environment is encapsulated in so few tools, and configured with so few collections of files. There are other tools I use a lot too, but most of them either have their own sync systems, or they have so few configuration options (and are likely in a format that isn't easy to grab/store) that it's not worth the bother.

This feels like a good thing, really.

One thing that's not amongst all of this, partly because it's not that interesting, but also partly because the repository is private, is a single bash script called myenv. On a new machine, once I've got enough of a setup that I can clone from GitHub, I drag this down and run the script and most of the rest of the environment follows.

It's quite satisfying when I need to use it.

I moved into my current place back in August 2019, bringing with me a fairly small desk. Originally, many years back, I'd had a pretty big office with lots of office space but, upon moving up to Scotland back in 2016, I needed to go with something a lot smaller.

Which was perfectly fine. Me and that desk wrote a lot of code. Me and that desk transitioned from one job to another, and then another. Me and that desk made it through the pandemic.

It's been a good desk.

But it was small. I'm in a place where I could spread out a fair bit again, but I also kept putting it off and putting it off.

Earlier this year I decided that it was high time I actually upgraded; I also promised the desk to someone else who I know will get a lot of good use out of it; so finally earlier this week I put in the order for something bigger and fancier.

Yesterday, with the help of a very good friend (thanks Mariëlle!), I got the desk built and roughly in place, and then today I've been putting the desktop back together and adding extra bits.

It's so nice to have more space to spread out, it's also nice to have a black desk again! (the last one was white because... reasons) But what's really exciting is that it transforms into a standing desk at the touch of a button.

I've been trying it in the standing configuration today and, while I doubt I could do a whole day of coding with it like that, I'm already really liking it as a way of breaking up the time at the keyboard. On the days I work from home, or the days of my own where I get sucked into a personal project, I can absolutely see me swapping between the two states.

All that's left now is to get used to it. The screens are ever so slightly further away, the height is ever so slightly different (although I can adjust it, of course, but what I've done is adjust the sitting position to a nicer one and that's going to take some getting used to), my iPad and Stream Desk are in just a slightly different location, etc, etc... So I'm sure there'll be a few days of sitting here and making small tweaks to the spot where things live.

Before I know it I'll be used to it. It'll be "my spot".

More than ever I'm listening to music while I work. Despite having grown up in the 80s, and so having a good vinyl collection, and then having got into buying all the CDs in the 90s and 00s, these days I have managed to embrace the "just stream all the things" approach. After a long time using Spotify I finally ended up migrating to Apple Music.

One of the things I do find Apple Music does well is the whole "you seem to like this, have you tried this?" thing; which on occasion has resulted in a pretty neat rabbit hole of discovery.

Earlier this year this happened with female-fronted Dutch goth/rock type bands. I don't even remember how that happened, but it's a thing that happened and I gleefully dived right in. I came away with a few names I didn't know before, but one album has really stuck in my head and, now that we're just over 1/2 way through the year, I feel it's the one that gets played more than anything else.

This keeps creeping back to the top of things I'm playing; sometimes when I'm in "bang on the keyboard lots" coding mode (you know the sort of coding mode: where you don't have to think too much because you have a good plan for what you're doing, but you've got a lot of tapping away to do), plus also often while I'm in the car.

I won't be the least bit surprised to find that this ends up being my most-played album this year. According to last.fm it's at the top of the albums I've played (in places where I have scrobbling set up) in the last 365 days.

Well, it didn't take as long as I expected it to. Just yesterday morning I was giving Pelican a look over as a possible engine for generating my blog, having wanted to move away from Jekyll for a while now. Having tried it and liked what I saw to start with, I wrote about how I liked it and wondered how long it would take me to make the switch.

By the evening I was making a proper effort to get the switchover started, and just a wee while earlier, before writing this post, the switch was made!

The process of making the switch was roughly this (and keep in mind I'm coming from using Jekyll):

1. Made a branch in the repo to work in.
2. Removed all of the Jekyll-oriented files.
3. Decided to set up Pelican and related tools in a virtual environment, managed using pipenv.
4. Ran pelican-quickstart to kick things off and give me a framework to start with.
5. Renamed the old _posts directory to content.
6. Kept tweaking the hell out of the Pelican config file until it started to look "just so" (this is a process that has been ongoing, and doubtless will keep happening for some time to come).
7. Tried out a few themes and settled on Flex; while not exactly what I wanted, it was close enough to help keep me motivated (while rolling my own theme from scratch would seem fun, I just know it would mean the work would never get done, or at least finished).
8. Did a mass tidy up of all the tags in all the posts; something I'd never really paid too much attention to as the Jekyll-based blog never actually allowed for following tags.
9. Went though all the posts and removed double quotes from a lot of the titles in the frontmatter (something Jekyll seems to have stripped, but which Pelican doesn't).
10. Tweaked the FILE_METADATA to ensure that the slugs for the URLs came from the filenames -- by default Pelican seems to slugify the title of a post and this meant that some of the URLs were changing.

All in all I probably spent 6 or 7 hours on making the move; a lot of that involving reading up on how to configure Pelican and researching themes. The rest of it was a lot of repetitive work to fix or tidy things.

The most important aspect of this was keeping the post URLs the same all the way back to the first post; as best as I can tell I've managed that.

So far I'm pleased with the result. I'm going to live with the look/theme for a wee while and see how it sits for me. I'm sure I'll tweak it a bit as time goes on, but at the moment I'm comfortable with how it looks.

Since getting my blog editing environment set up on the "new" machine a couple of days back I've been thinking some more about moving away from Jekyll. Jekyll itself has served me well since I started this blog back in 2015, but I was reminded again when installing it on the Mac Mini that it's Ruby-based and I have very little understanding of how to get a good Ruby experience on macOS¹.

Having mentioned on Mastodon that I was thinking about finally looking at moving my blog management/generation to something new, and specifically something Python-based and ideally some sort of site generator, I got a few suggestions.

One that looks promising so far is Pelican. At first glance it seems to tick a few boxes for me:

• Python-based (so easy for me to grok in terms of installing, and also more chance of being hackable).
• Uses Markdown (curiously as an alternative, to reStructuredText, which looks to be the default).
• Does article-based stuff as well as page-based stuff.
• Lots of themes, and themes are Jinja2-based (I'm pretty familiar with Jinja thanks to my Django days and also using the library when kicking off ng2web).
• RSS feed generation.
• Syntax-highlighted code blocks.

While I'm not quite ready to dive in and make the move just yet (I am on a "muck about at home" holiday this week, but I've got enough planned without losing a day to rebooting my blog), I did do a quick experiment to see if Pelican would work for me.

Key to this is can I keep the URLs for all the posts the same? If I can't that's a non-starter.

Things got off to a good start with an easy install:

$ pipx install "pelican[markdown]"

I then used the pelican-quickstart to kick off a test site, copied in my existing Markdown files, dived into the docs and found how to configure the generated URLs and... yeah, within like 10 minutes I had a very rough version of my blog up and going.

It looked like garbage, the theme really wasn't to my taste at all, but the core of the blog was working.

I've nuked it all for now but a more considered evaluation is now on my TODO list. Things I'll need to drive into properly are:

• Find a base theme that's to my taste.
• Get Disqus working it so that any old comments remain in place.
• Get my image/attachment layout back in place.
• Go through and tidy up all the tagging (which has been a mess with this blog because I never did get round to getting Jekyll to actually use tags).
• Figure out the best way to do the publishing to GitHub pages.
• Likely a bunch of other stuff I've not thought about yet.

But, yeah, for a brief "over first coffee of the day" tinker to see if I like it... I like!

Let's see how long it takes me to actually get around to making the switch. ;-)

Ever since GitHub introduced the profile README¹ I've had a massively low-effort one in place. I made the repo, quickly wrote the file, and then sort of forgot about it. Well, I didn't so much forget as just keep looking at it and thinking "I should do something better with that one day".

Thing is, while there are lots of fancy approaches out there, and lots of neat generator tools and the like... they just weren't for me.

Then yesterday, over my second morning coffee, after getting my blog environment up and going again, I had an idea. It could be cool to use Textual's screenshot facility to make something terminal-themed! I mean, while it's not all I am these days, so much of what I'm doing right now is aimed at the terminal.

So... what to do? Then I thought it could be cool to knock up some sort of login screen type thing; with a banner. One visit to an online large terminal text generator site later, I had some banner text. All that was left was to write a simple Textual application to create the "screen".

The main layout is simple enough:

def compose(self) -> ComposeResult:
    yield Label(NAME, classes="banner")
    yield Label(PRATTLE)
    yield Label("github.com/davep login: [reverse] [/]")

where NAME contains the banner and PRATTLE contains the "login message". With some Textual CSS sprinkled over it to give the exact layout and colour I wanted, all that was left was to make the snapshot. This was easy enough too.

While the whole thing isn't fully documented just yet, Textual does have a great tool for automatically running an application and interacting with it; that meant I could easily write a function to load up my app and save the screenshot:

async def make_banner() -> None:
    async with GitHubBannerApp().run_test() as pilot:
        pilot.app.save_screenshot("davep.svg")

Of course, that needs running async, but that's simple enough:

if __name__ == "__main__":
    asyncio.run(make_banner())

Throw in a Makefile so I don't forget what I'm supposed to run:

.PHONY: all
all:
    pipenv run python make_banner.py

and that's it! Job done!

From here onward I guess I could have some real fun with this. It would be simple enough I guess to modify the code so that it changes what's displayed over time; perhaps show a "last login" value that relates to recently activity or something; any number of things; and then run it in a cron job and update the repository.

For now though... I'll stick with keeping things nice and simple.

So... erm... yeah... I did it again. I looked away for a moment and somehow almost 7 months passed without a post! It's so easily done too isn't it? While, when I revived this blog last year, I didn't make a point of intending to write lots and often, I had hope that I'd manage something at least once a week; perhaps at least once a month.

Ahh well.

There's been two main reasons why it's been quiet around here. The first is that my (now not so) new job keeps me busy (in a good way). It involves a reasonable amount of trekking into town and back (which I don't mind on the whole), and once I'm home in the evening I'm generally (but not always) done with the keyboard and desk.

The second reason, which is probably the dafter one, is that a bit earlier this year I finally upgraded my desktop setup from the 2019 Intel MacBook Pro I was using to a recently-released M2Pro Mac Mini (and what an upgrade!). How this plays into blogging being even more quiet is... I needed to set up jekyll again, and I'd forgotten how I got it running in the first place, so I kept putting off getting it going, and...

Well, this morning, I sat down with coffee, grepped the history on my previous machine, and got it running in like 5 minutes (of course).

So, here I am, back adding another blog post. I'm writing this as much to test that the setup works as anything else.

But also, this time, I'm going to try and make a promise to myself: I'm going to try and write more. I can and should write about anything. I can and should write short things as well as long things. I can and should remember that it's not about writing things that are going to be super important or anything like that, it's about just getting stuff down and creating and recording.

Note of course I said "try" and make a promise.

We'll see. ;-)

Another little thing that's up on PyPi now, which is the final bit of fallout from the Textual dogfooding sessions, is a little project I'm calling OIDIA.

The application is a streak tracker. I'm quite the fan of streak trackers. I've used a few over the years, both to help keep me motivated and honest, and also to help me track that I've avoided unhelpful things too. Now, most of the apps I've used, and use now, tend to have reminders and counts and stats and are all about "DO NOT BREAK THE STREAK OR ELSE" and that's mostly fine, but...

To keep things simple and to purely concentrate on how to build Textual apps, I made this a "non-judgement" streak tracker. It's designed to be really simple: you add a streak, you bump up/down the number of times you did (or didn't do) the thing related to that streak, for each day, and that's it.

No totals. No stats. No reminders and bugging. No judgement.

Here it is in action:

When I started it, I wasn't quite sure how I wanted to store the data. Throwing it in a SQLite database held some appeal, but that also felt like a lot of faff for something so simple. Also, I wanted to make the data as easy to get at, to use elsewhere, and to hack on, as possible. So in the end I went with a simple JSON file.

On macOS and GNU/Linux streaks.json lives in ~/.local/share/oidia, on Windows it'll be in... I'm not sure off the top of my head actually; it'll be in whatever directory the handy xdg library has chosen. and because it's JSON that means that something like this:

ends up looking like this:

[
    {
        "title": "Hack some Python",
        "days": {
            "2022-12-02": 1,
            "2022-12-03": 1,
            "2022-12-04": 1,
            "2022-12-05": 1,
            "2022-12-06": 1,
            "2022-12-07": 1,
            "2022-12-08": 1,
            "2022-12-01": 1,
            "2022-11-30": 1,
            "2022-11-29": 1,
            "2022-11-28": 1
        }
    },
    {
        "title": "Brush my teeth",
        "days": {
            "2022-12-02": 2,
            "2022-12-03": 2,
            "2022-12-04": 2,
            "2022-12-05": 2,
            "2022-12-06": 2,
            "2022-12-07": 2,
            "2022-12-08": 1,
            "2022-12-01": 2,
            "2022-11-30": 2,
            "2022-11-29": 2,
            "2022-11-28": 2
        }
    },
    {
        "title": "Walk",
        "days": {
            "2022-12-02": 1,
            "2022-12-03": 1,
            "2022-12-04": 1,
            "2022-12-05": 1,
            "2022-12-06": 1,
            "2022-12-07": 1,
            "2022-12-08": 1,
            "2022-12-01": 1,
            "2022-11-30": 1,
            "2022-11-29": 1,
            "2022-11-28": 1
        }
    },
    {
        "title": "Run 5k",
        "days": {
            "2022-12-03": 2,
            "2022-12-05": 1,
            "2022-11-30": 1,
            "2022-11-28": 2
        }
    },
    {
        "title": "Run 10k",
        "days": {
            "2022-12-03": 1,
            "2022-11-28": 1
        }
    }
]

Of course, it remains to be seen how well that actually scales; possibly not so well over a long period of time, but this was written more as another way to explore Textual than anything else. Even then, it would be pretty trivial to update to something better for holding the data.

If this seems like your thing (and I will be supporting it and onward developing it) you can find it over on PyPi, which means it can be installed with pip or the ever-handy pipx:

$ pipx install oidia