Before I fell asleep last night, I was mulling over the options I've been considering for writing a blog. I've been using Ghost for most of last year, but Write.as, Plume, Scuttlebutt and TiddlyWiki are starting to look like better options. The Ghost editor is not very mobile-friendly, and I'd also rather support a platform that better aligns with my values.
It seems that if I want to use my phone or iPad to write, using Write.as is a no-brainer. ScuttleButt is awesome, but the barrier of entry for non-technical users is still too high. It can take a long time to get everything installed and set up correctly. It also takes some getting used to.
Compare that with the peer-to-peer Beaker browser, which works very similar to any other web browser, even allowing you to browse regular web sites. Maybe Beaker is a better gateway drug into the P2P world? TiddlyWiki works great on Beaker browser, but cannot be accessed from a mobile device. Then again, there is nothing that prevents me from having both a blog and a personal wiki.
I guess I can just experiment with all of them for a couple of weeks and see how it goes.
Update 12 March 2019: I've decided to give write.as a try!
The house we recently moved into has a built-in dishwasher. This is the first time I've owned a dishwasher in all my adult life. I remember that as a kid it was still a lot of work loading and unloading the dishwasher, so I always figured I might as well wash and dry them myself. What I now realise is that they do have several advantages:
You can use them to store unwashed dishes so that they don't clutter up the counter top.
If you pack things into the dishwasher immediately after you use them, loading the dishwasher doesn't feel like work.
Unloading a dishwasher when the plates are still slightly warm is strangely satisfying.
Unloading a dishwasher takes a lot less time than washing the dishes, and can be done at your convenience.
If you're doing a couple of dishes that don't go in the dishwasher, and you have the dishwasher running at the same time, it feels like you have a little robot helping you out.
It also helps having a small dishwasher, so that you don't have to wait until you've used every plate and cup in the cupboard before you can turn it on.
I have owned this multi-meter for over ten years, always storing it in the cardboard box that it came in to keep the wires from getting tangled or losing the test leads. Today for the first time I noticed there are slots on the back for storing the test leads. It turns out with the right technique it's possible to neatly wrap the wires around the meter and then tuck the test leads into the slots. Nice!
I'm taking the afternoon off today to take my son to forest school. I have never been there before, but it sounds like fun. Apparently we will be making Christmas wreaths, and there will be a fire with (non-alcoholic) mulled wine and mince pies. I know they usually make and eat soup when he's there, and there's also a mud kitchen for him to play in. The only thing I know for sure is that we'll be getting dirty!
So the double-decker bus I mentioned yesterday is a success! It printed without any issues, and the trickiest part was to find the right diameter metal pins to use as axles for the wheels. I ended up using a couple of nails that I shortened a bit, and then used a gel-based super glue to hold them in place. I think it looks pretty good!
So far they've been single prints. I want to try something a little bit more ambitious. My son's really into buses at the moment, and I just came across this double-decker bus with a separate shell, chassis and wheels. I'm busy printing the bus shell in blue PLA at the moment, and will switch to grey PLA for the chassis and the wheels. Then I'll have to assemble it and will let you know how it turns out in another post.
I figured out the issue I was experiencing yesterday! It turns out WebUSB works just fine 😅. The problem was that in my last USB packet I specified the length to be 24 bytes long, when in actual fact it was only 20 bytes long. That confused the meter a bit, so it returned an error message instead of the actual data. After changing the length of my USB packet, I suddenly started receiving my first data packets from the device. Success! 👌
After my promising start last week in reading data from a blood glucose meter using the IEEE 11073 standard, I've come across my first hurdle. I can read the Medical Device System (MDS) attributes just fine, as well as details of the PM (Persistent Metric) store. Basically, when data is stored on the device to be retrieved at a later date, it is placed in the PM store. I'm now trying to read data form the PM store, but it's not going as planned.
It took me a while to realize that I should be reading from the PM store's segment ID 0 instead of 1. You know, the classic off-by-one issue. Now it's telling me that the meter data is being sent, but I'm not receiving it as expected. My current guess is that the issue may be with WebUSB itself after looking at this Stack Overflow thread. Basically I'm thinking that I should use an event listener to read data from a bulk endpoint, rather than polling it as I'm doing at the moment. The thing is, I'm not sure if WebUSB supports using event listeners for reading data, so now I'm reimplementing everything in regular node-usb.
This year Spotify's summary of the music you listened to over the year is called Spotify Wrapped. By far my favourite feature is them creating a playlist called “Your Top Songs of 2018” as part of it. When you've listened to thousands of songs, having an automated way of surfacing the songs that you enjoyed the most, is pretty sweet!
One thing that is a bit funny is that the “artist” that comes in third in terms of how much I listened to them, is Sleep Baby Sleep. Yes, in the first half of the year there has been a lot of music played to get the baby (now toddler) to sleep.
I have been having a fun couple of days trawling through the IEEE 11073 specs (no, really!) to implement a new USB driver for a Roche blood glucose meter. This is the first meter I've worked with that fully adheres to the standards on all the protocol layers, from using the USB Personal Healthcare Device Class specification on the transport layer, to using the ISO/IEEE 11073-20601 and 11073-10417 standards that describe the data model.
So far I'm quite impressed with the IEEE 11073 standard. Instead of forcing a manufacturer to use a specific format to describe blood glucose readings, it allows for the device to specify an extended configuration. Such a configuration, sent by the device, describes the format in which to expect the readings, for example a timestamps of eight bytes followed by an observation value of two bytes and measurement status of two bytes.
I've just parsed the Roche meter's extended configuration by hand and it goes into a lot of detail, even describing if a measurement is measured (e.g. blood glucose) or manual (e.g. meal context).
On the transport layer, there was a small hiccup as I realised two different Roche glucose meters use different USB endpoints. I then discovered that you can actually find out what the endpoint numbers are for the device you're connected to by looking at the configuration descriptor. The trick is that you needs to look in alternates:
