I've had the thing nearly a month, and haven't had to charge it since initially charging it. I charged the Bangle and my Watchy in unison to compare them. I really thought the Watchy would win, but that died a few days ago and my Bangle still had about a third of it's battery left - that said, I am only using it for the time and step counting, I've turned the heart rate monitor and Bluetooth off. Still, for doing the same tasks as the Watchy, in terms of battery it would seem as though the Bangle 2 JS was an upgrade for battery life.

I adjusted the flags on Chromium to allow Web Bluetooth and added a few new watch faces. Namely a Pebble style watch face, and the same analogue face I was using on the Watchy (it was my favourite face). I had set up the Watchy to scroll through modes: analogue, digital with date, and a step counter. The Pebble watch face I went with (a non-customisable one) actually shows that's date and steps, so the two birds with one stone (or should I say one pebble?). I looked at a multi watch face that I might be able to use to scroll between the two faces without opening up the settings menu - I had used the same method on the Watchy, using someones multi face code, someone elses analogue face, and a few faces I made myself for the remaining modes. For now I've uninstalled the multi face app as it comes with a load of faces that I didn't really want.

I think next I will explore the Espruino environment and see if I can make the adjustments I want, and explore a bit of the watches inner workings. I'm hoping I can set up a travel mode, that will adjust the time based on a user provided time offset for different timezones, which I had planned to add to my Watchy as a fourth mode before one of it's buttons broke. Watchy will live in a drawer for now, in case something goes wrong with my Bangle, at which point I will try to adjust the firmware so that it can run on the 3 remaining buttons without issue.

I'm at my computer now (obviously) as I write this. But it's taken a bit of willpower to get here. I tend to guilt myself over not finding time for my hobbies. But when I actually think about it, I've been pretty busy, and considerably tired when I'm not busy. Work had a busy period and I have also being doing lot's of going out things around that.

I spent yesterday avoiding my computer to get some much needed chores done, and even when they were ticked off I kept going to either my TV or my eBook reader. I had decided that the next day would be the safer option. It was raining yesterday, and today the weather is beautiful - it felt like it would be a shame to miss the weather. I took myself for a walk, and had coding on my mind, so I'm back home now. I might take myself out again later for a stroll, or even just go out out if I feel like I've accomplished a good amount at some point throughout the day.

Anyway, I'm here now, and ready. With any luck a blog entry in which I offload my qualms should be all that is required to clear my head and get going. I have a few things I want to try and do, so I'll try work through some of those and see where it goes.

This is exactly the kind of content that goes on my other website, but there's a reason it's here instead, and that reason might disappoint you. I tried a few times to compile the new Bigscreen software with KDE Builder, and when I got stuck, searching for solutions to certain issues often returned the advice "I gave up with Debian and just went back to [Arch/Fedora/OpenSuse]". The guy who originally began the undergoing rejuvenation efforts for Bigscreen got it working on a Pi 5, but with Postmarket OS. It's worth noting at this point, Bigscreen is not available in the Debian 13 Trixie repositories.

For a few reasons, I am too heavily invested in Raspberry Pi's variant of Debian. The first being that it has the best streaming performance of all the operating system's currently available for the Raspberry Pi (at least according to the YouTubers who can be bothered to actually sit and test out each one in sequence). The second being that I use an Argon V3 case with IR remote so I can turn the thing on and off from my couch without having to get up - TV is suppose to be a passive activity.

With everything as it currently is, I see three ways to get Plasma Bigscreen running on a Raspberry Pi 5:

1. Use an alternative OS (I have already ruled this out for my own use case)
2. Use Debian 13 Trixie, and add the Bookworm repositories
3. Use Debian 12 Bookworm

Adding the Bookworm repositories to a Trixie installation is certainly a plausible solution. You would end up with KDE Plasma being installed from the Trixie repo, so Plasma 6, with a 5 Bigscreen package out of the Bookworm repo. Despite some possible QT clash, this should, in theory, work fine. Before I set up my Raspberry Pi 4 Bigscreen installation, I was using a Small Form Factor Dell Optiplex, with an Arch based distribution, and this is exactly the pairing I ended up with, Plasma 6 with Bigscreen 5. It worked fine, and it even fixed a few bugs with opening the settings app's that are specific to the Bigscreen UI. However, I want to watch my TV, not tinker with it. So, for now, I have opted to just use Debian 12 Bookworm, as it leaves me with the exact same set up I've been using, just a little more powerful and therefore able to run 1080.

So, if you would like to set up Plasma Bigscreen on a Raspberry Pi 5, you can follow this guide I have done previously for setting it up on the Raspberry Pi 4. Everything should land the same. Hint: to get the lighter install of KDE Plasma, install the gldriver-test package before enabling SDDM login manager.

sudo apt install kde-plasma-desktop gldriver-test

I would also go straight for firefox after logging in to the KDE Desktop, as Chromium has since switched to Web V3 which has affected UBlock Origin. Firefox ESR may or not be installed along with KDE, in which case it will be IceWeasel (Extended Support Version). Raspberry Pi's mods are for the standard Firefox. The mods package adds UBlock Origin as well as the H264ify extension.

sudo apt purge firefox-esr
sudo apt install firefox rpi-firefox-mods

It arrived the next day, much faster than I was expecting. In between ordering it I had a mere 24 hours to doubt my purchase. I began to wonder if it might have been feasible to instead rewrite the existing Watchy firmware to run on 3 buttons instead of 4, by adjusting some functionality and adding a back option to the settings menu. That may indeed be possible, and I may still try that just for fun.

But the BangleJS 2 arrived, and any doubts I had about my choice were quickly replaced with awe over my shiny new toy. You can't build it and change the case like you can a Watchy, but the trade off is a waterproof case. I haven't had a chance to sit down and reprogram it, but on the surface of it, the process looks to be a good one. It seems a little clunky compared to the typical experience of programming micro controllers, but when you consider that it is a small indie project and the challenge of serial connection to a watertight enclosure, you can begin to understand the novel approach to developing on the board.

Even though I haven't had a chance to tinker with it, I have charged it up and have been wearing it for the better half of a week now. The battery seems good, I've used about 25% according to the battery indicator over 3-4 days. That said, I have disabled the heart rate monitor and am only counting my steps. I haven't had a chance to explore the various sensors or applications, but step counting appears to be accurate, and there has been no clock drift at all since I set the time initially.

The V3's ESP32s3 board does not keep time correctly. For a watch, that's undoubtedly not ideal. I'm not exactly experienced enough in micro controllers to figure out why, or to make my own firmware. There is other, apparently better firmware, but I like simple things, I don't want to connect to wifi.

I did also notice that the V3 burns through the battery a lot quicker. My options were:

• (Easiest) Figure out the time drift and correct it, but this could be inaccurate over time
• (Harder) Remove a button from the V3 board, and use it to repair my V1 or V2 board, whichever it is, I don't know, I run V1 firmware on it so maybe it's that

The project looks like it may be abandoned by SQFMI. I'm not sure. If they ever release a V4 and it looks as though the V3's issues have been addressed, I'll probably buy it. But for the time being, I decided I will try use a V3 button to replace the broken one on my old board. The old board keeps time impeccably, and the battery lasts for weeks at a time, easily over a month on one charge for my use case.

I haven't done a lot of soldering. I used to repair my electric guitar, which was just soldering wires together, no printed circuit boards there. Soldering the tiny connection points on Watchy's PCB was scary, but I managed it. Unfortunately, you need a pin to pop the button off of the board from underneath, and once that's off, I'm not really sure about how to secure it again. Nonetheless, I tried, and it worked. I had 4 working buttons on my (maybe) V1 again.

But, the solder wasn't enough on it's own to secure to the button well enough. After putting it all back on the case I got about 50 button clicks before the new button broke off. It has only disconnected, and not fully broken like the button that originally begun this roundabout saga. I will try to figure out a way to secure the button, because I liked my Watchy - but I have ordered a Bangle 2 JS. It's not as down and dirty as the Watchy, but the build quality looks promising, and I suppose I can make it as smart, or in my case, dumb as I want it to be.

I'm chalking this one down as a loss, and maybe the most expensive button replacement I will ever do. Annoyingly, I opted for a new board when I ordered the chronologically impaired V3 instead of a replacement button because I was nervous about what might happen if I attempted the repair. And now I have two Watchy boards with 3 buttons each instead of 4. I might make use of what remains of them and maybe make some mini E-Ink displays. A simple web request is built into the firmware, so maybe I could tweak the existing firmware or strip it down to do something interesting. Waste not want not.

When I was learning JavaScript, OOP, or Object Oriented Programming, was all the rage. I'm not sure if it still is. I feel like I used to see articles about it every other day, and now I don't. I'm not sure if that's because React switched to function components, or that everyone found a new trend to obsess over, or if I just stopped frequenting the kind of spaces where people talk about it a lot.

I wasn't really a fan. I wasn't against it, I could understand the philosophy and how it might be useful. Like how I feel about React, I didn't feel that I would really be working on projects big enough to benefit from the advantages of OOP. And also, while I was learning, it was difficult to figure out. I'm not sure why, but classes just didn't click for me. It was hard to get my head around it while I was still learning all of JavaScripts traits and querks. And also, I don't think that tidily, my work tends to be messy and is likely a reflection of my mind.

I did however find a legitimate use for classes in a smaller project. I set up an application that needed to define functionality based on data it received from an API. Roughly what data is coming is known, but only roughly. The logic would need to change depending on exactly what data was received.

I had achieved this already with generic JavaScript code and no clear paradigms to hand. But it was messy. It wasn't spaghetti, it was spaghetti soup. And it had been served on a spinning plate. I was having to define an object to contain data then adding data and functions to that object on the fly. It was all over the place.

But then I remembered what classes in JavaScript were. I could define as much as I needed about the data before it arrived, and simply initialise it when I had the data. No errors. Clean. Easy to write. Really easy to write. I was actually surprised how little beyond basic syntax I needed to research now that I've played around with JavaScript long enough to have gained an understanding of scope and this.

Watchy is a wristwatch for hobbyists that runs on an ESP32 microcontroller. It's described as "smart", and has wifi capability, although the default firmware's smartest trait is performing a web request to collect weather information. It's a development board so users can modify the existing firmware, or even create their own. It also has a gyrometer that counts steps, and a motor that adds vibration.

It's not incredibly advanced out of the box. But that's fine by me. I like simple things. I'm not a fan of smart watches, I don't want another channel into my phone - phones already have enough ways of drawing in attention. I don't want my watch telling me that something is happening on my phone. For my Watchy, I took someones code that allowed them to change between multiple watch faces on the fly, and adapted it to run modes for my Watchy; I have an analogue face mode, a digital mode that includes day of the week and date, and a steps mode that just shows my step count so far for the current day. I did plan to make a travel mode, that allows you to set a time offset, and will display the adjusted time for when you are in a different time zone, to save having to change settings if I am travelling.

But yesterday, one of my buttons stopped working. I took my Watchy apart, and after inspection I saw that a tiny piece of plastic had snapped off, that secures the button mechanism in place on the board. I couldn't find a way to secure it. Darn. It still works, but to set the year I will have to scroll down to go up - assuming that it even cycles once it reaches the end. No thanks.

It looks like you can only get them in the full kits now, so I've had to order the entire starter kit for about £50. I had read online in forums that a button breaking is a common issue. My Watchy didn't get the easiest start. I'm a youth worker and I also skate. It's been dropped, whacked, and had footballs kicked in to it. Once a ball hit it while I was still using the plastic case, the whole thing exploded, and the board flew out - and to my amazement it just keep running like nothing had happened. I have since switched to the gun metal alloy case with fastening screws. I've had mine nearly 2 years so I just assumed it would keep going. Bad luck.

I did look at the BangleJS 2, from Espruino, which retails for around £100. It looks good, but seems a fair bit smarter than I actually want my watch to be. The battery life is apparently quite good at 4 days between charges. But my Watchy, with it's e-ink display, and with me removing any functionality that relied on wifi, was lasting about 2 months between charges (no joke!). I like simplicity, and I like having a watch that is just a watch, and not a portal to my phone. Counting my steps? Yeah sure, nice to have, not invasive. But I don't want my watch flashing or vibrating whenever my phone demands my attention.

Anyway, I've opted to go for a replacement Watchy. If the button breaks on the new one, I'm hoping my hand is steady enough to solder one from the old board. That should give my next Watchy about 3 extra lives if they're needed.

I have 2 main websites currently, my blog (this one), and my main website. They are similar in the respect that they are both blog-format websites centred around my hobbies and interests, and that they are static websites using only HTML, CSS and JavaScript. But they are made quite differently.

My main site is built and maintained using a CMS (Content Management System) module I made myself in Python. My blog is made using a proper CMS (publii). I began using Publii through curiosity, and I like the experience. While my main website satisfies an urge to get stuck in to the technical details, Publii allows me to just blog with ease. I would highly recommend the software for anyone who wants to write a blog quickly and efficiently, and has a little technical understanding when it comes to computers and the web.

The different approaches mean my websites are quite distinctly different from each other. No brand. But I like it. I could make a CSS plugin for my blog, or make my main sites CSS a closer match. But they are different websites. I like them both, I like that they are different. I don't care about having a brand; I'm a hobbyist, I'm here for fun.

Nonetheless, I wanted the sites to link to each other. And to link to any future projects I might come up with. And I don't want to be pinned down to branding when I come to create those other projects. So I decided to just link from my websites to a site directory: sites.aaronwatts.dev.

I thought the tree structure, with the site directory acting as a root, was fun. And decided to design the site like it was documentation, or a man page in a UNIX terminal. I was researching ARIA patterns at the time, so while the site may look like just a lot of monospace text, if you view the page source, you'll see that it's a proper website. It even has a script that parses the XML feeds of my websites and creates links to the most recent articles for each category. There is rational use of semantic HTML, and while the typographical hierarchy leaves a bit to be desired, the document is as easy to figure out as a man page. Ironically, I struggle with to man pages myself, and rely on the zsh plugin colored-man-pages to be able to read them - but I feel like the vertical space between elements on my site aids readability in this sense.

Because of this, I decided that:

1. Any text heavy apps I use, such as Mastodon or my RSS feed reader, will be switched to light mode.
2. My website needs light mode

I remember there being a trend of JavaScript switches for light/dark mode toggles. I have already made a conscious choice to avoid unnecessary JavaScript on my main website, so I opted to let the user, or the browser if the user hasn't bothered to adjust settings, make the decision whether to use light or dark mode.

I doubt this is news to most people, but CSS has a media query for that. As I've kept the design of my site fairly simple, it was as straightforward as just inverting the colours for my variables. After that, I only had to hard code colours I didn't want to change (my faux-Excel spreadsheet style tables, and my pre and code elements), tweak a few colours to optimise contrast, and use an inverted filter for an SVG in my footer. I did also reduce the glare effect on my terminal style hero header, as it didn't work quite as well for light mode as it did for dark.

@media (prefers-color-scheme: dark) {
  :root {
    --bg-color: #222;
    --bg-color-dark: #f5f2f0;
    --color: #ddd;
    --color-dark: #bbb;
    --color-light: #444;
    --border-color: #777;
    --accent-primary: #44a0eb;
    --accent-primary-light: #55b1fc;
    --accent-secondary: #be8ae9;
    --accent-secondary-light: #d7a6ff;
    --accent-mono: #aaa;
    --accent-bg-mono-light: #333;
    --accent-mono-light: #ccc;
    --topic-selected: #666;
  }      

  .hero {
    text-shadow:
      0 0 .23vw currentColor,
      0 0 1.2vw currentColor;
    }

  footer img {
    filter: invert(100%);
  }
}

While doing this I realised that I am quite pleased with the design of my website; not only because the choices I've made make potentially big changes quite straightforward, but also because I'm quite proud of how its grown so far. Naturally, some things are never finished, and there are clearly spots here and there where I quite obviously haven't sat down to consider properly and solve. But otherwise I think the design is a good reflection of my tastes and personality when it comes to computing.

I like to stick to defaults nowadays. Ricing can be fun on occasion, but lately I prefer to just get going, and for now it seems to be working for me. There is a terminal theme, but not too much - only the breadcrumb navigation and the hero header on the home page. It says a bit about the type of content to be found on the website, without forcing a users eyes to have to parse heavy text in a mono font. Some people may like that, but not me. It also celebrates HTML defaults, while making a few tweaks to improve readability and to ever so slightly modernise the page design.

I feel like I've really proven to myself here, that less can be more. The light mode design in particular, compliments what HTML already provides out of the box, and I love that.

I got back from a holiday today, updated Chromium on my Raspberry Pi, and now my XML documents fail to load in Chromium. They are still working in Firefox and Epiphany, so I checked on my laptop that hadn't had the update yet, and confirmed it was indeed occurring only after the update. It doesn't appear to fit in with Chromium's deprecation roadmap, as I'm still on v144.x, and it says deprecation won't begin proper until v145.x. I checked this site's sitemap.xml, which uses XSLT, and that still works, so perhaps something that I was using might have stopped it working earlier, be it XPath or XQuery?

That's fine. It's a shame, but whatever: I can deal with it. It was nice to have XML pages conform to the sites overall design, including headers and footers. But I guess I can get it to conform, albeit a little less, using just CSS. Since implementing XLST, my site went from having 1 RSS feed to having 3, so the feed link now directs to an rss.html, where a user can make an informed choice of what feed to follow. I had some RSS instructions included in the XSL template, but I guess it makes more sense to move all that backwards to the rss.html page anyway - to reduce duplication, and it is a more intuitive place for it now that I have an intentional bottleneck there. Maybe I won't even bother with CSS now that the instructions are falling back a step.

My sitemap was helpful to include as a link in my 404 page. I suppose I can make a sitemap-for-humans.html to compliment my sitemap.xml. Or just action the user back to the home page as my site is designed to be easy to navigate from there.

I had hoped to do a guide for XSLT, and indeed had started one when I caught wind of the news that it was to be deprecated. They are still usable with a Web Assembly Module, but that's not really worth considering unless you're relying on XLST for your websites functionality - which some corporate software indeed does. I try not to do guides where guides already exist, as was the case here. But I thought it was a worthwhile way for a beginner at web development to get to grips with the basics of templating, without having to learn nodeJS, PHP, or anything else that can be a bit cumbersome to get started.

My XSL templates are still working in 2 out 3 browser engines, and likely still working in a lot a Chromium forks. Nevertheless I think I'll begin getting things ready for an internet without XLST soon. I have a short list of things I might tidy up first, and I still haven't written an article for my site in a while, so maybe I'll do those first. But soon my XML may just be back to looking like, well, XML.