Day One and Project Jurassic
So, Day One is in danger of being sherlocked by rumor’s of Apple’s upcoming journaling app:
Mayne echoes the sentiment of several app developers who have been frustrated when Apple launched in-house competitors to the apps they have introduced to the ecosystem, often copying features those apps innovated and adding functionality that only Apple can offer, per the iPhone’s privacy and security policies and APIs.
I’m a user of Day One and I have my doubts that Apple’s app would be a drop-in replacement for my journaling needs. And I think the reasons why Day One works for me — and could be made to work better — are also opportunities for Auttomatic to differentiate Day One from project Jurassic.
The first is access to user’s data. If Apple’s going to leverage the data it has access to on the phone, then Auttomatic should go the other way, making it dead easy for services outside Apples ecosystem to add stuff to people’s journal. Have a blog? Post photos to Flickr? Track movies in Letterboxd? Wouldn’t it be nice to get this into your Day One journal, safe and secure? A public API that these services can use to add posts to user’s journal would go a long way here. These services can offer an export option straight from the app, and Day One can be the private collection of all things a user does on the web, sort of like a private blog.
And yes, I know there’s that IFTTT integration, but I found it to be pretty crummy (all the post formatting was stripped and images were not uploaded). And it would be a pretty ordinary user experience to have these services say to their users “hey, if you want the stuff you track here in your journal, you have to create an account at this other service.” I guess all these services could publish this information as RSS feeds, and I would settle for that, if the IFTTT integration is actually working.
But arguments about IFTTT aside, the point is that Day One should fully embrace other services getting user’s data into their journal, and the best way to do this is with a public API. I know it won’t work for all their journals (one’s encrypted E2E should remain so) but the user’s should have that option, and services should be empowered to allow this.
And let’s not forget the largest trump card Automattic has over Apple: an Android app and web app. I haven’t used the web app but I use the Android app all the time. I can’t imagine Apple releasing an Android version of their journalling app, particularly if they’re gearing it towards health and leveraging all the private data people have on their iPhones. Automattic should keep working on both the Android and web app, so that users not completely in Apple’s ecosystem can keep journals.
So I don’t think Auttomatic has much to fear about project Jurassic. But they can’t rest on their laurels. They should embrace the platforms outside of Apple and iOS to really differentiate Day One, and keep it a favourite of mine for journaling.
Nerd Counterflex
You know that Washington Post article that has the list of websites Google used to train Bard? I been seeing people post screenshots of their sites in the training set on their blogs and Mastodon. This morning I read a post from Chris Coyier about it:
My largest corpus of writing to date is on the web at css-tricks.com (along with many other writers), so naturally, I’m interested in seeing if it was used. (Plus, I’ve been seeing people post their rank as a weird nerd flex, so I’m following suit.)
I’d suggest reading it. The post is more than just him flexing his ranking in the training set.
Well, I got curious to see if any of my writing was there. Here’s the result:
I guess you can call this a form of a nerd counterflex?
None of my other sites were there either. There was “lmika.com”, but that’s not me. Maybe having that was good enough for Google.
So yeah, you won’t be seeing Bard sharing any of my… “insightful” thoughts about code reviews anytime soon. 😄
Options For Self-Hosting Code Repositories
I’m considering something that some might say is stupid: I’m looking at options for self-hosting my personal code repositories.
I’m coming around to the idea of having my own domain for things like Go packages. It’ll provide more opportunities for adding some structure to my repos, rather than having them all hang off a single github.com/lmika namespace. Plus, my personal code management system is reasonably good at the moment so, naturally, the time has come to change all that 😛.
One option is to setup something myself. An idea I have is to get Forgejo running in a VPS managed by Hetzner. I had a go setting up Forgejo up to run on an empty Ubuntu server with PostgreSQL, but I didn’t get very far as I’d also have to setup things like a non-root user account, Nginx reverse proxies, and SSL certificate provisioning — stuff I can do, but all very tedious. Also, Forgejo’s installation guide is pretty incomplete. Good instructions for download it and setting up the database, but very little after that (where were the instructions about requiring a non-root account? That would have been nice to tell me).
I also tried getting the Docker image running it with Dokku. That took care of the reverse proxy and user account, and I managed to log into the frontend, but I couldn’t get Git to checkout a test repo using SSH. I suspect the SSH listener in the Docker container will need to be on a separate port to the SSH listener on the host; and both the container and host will need separate domain names, since I’d probably need to setup different SSH configs to use Git for both of them. Anyway, I haven’t completely written this approach off, and I may have another go at it if I want to host it myself.
One other thing I’d like to get working is a CI/CD pipeline. I got quite used to having GitHub Actions run the tests when I push commits, and having something similar would be really nice. It looks like Forgeio is building an integrated CI/CD pipeline which is exciting. But the question becomes where the runners should go. Separate host? That’ll start to make things a little expensive. I guess I can start without them, at least for the moment.
Another option is Gna, which offers managed instances of Forgejo and Woodpecker CI. It’s €10.00 /month, which is a decent price for something managed. But I do have questions about the company. Not that I’m worried about them snooping or anything, and the fact that they’re charging me means they have a business plan. But will they be around in 5 years? Granted these feelings are coming from visiting their website, but it does feel a little slapped together. Hmm.
The third option is going with GitLab. Hetzner seems to offer that as a one-click option, as does Digital Ocean (well, the Enterprise edition), and yeah that might work. I did create a GitLab instance for a hackathon once, so it’s something I could probably manage. But I don’t really love GitLab’s UI. I don’t know why I’m put off by it; after all, it’s not like Gitea’s UI is particularly special (I’m sorry, but everything looks so amateur. Please work on the padding of your elements). Maybe I can learn to love it if it means administering the thing would be easier.
Anyway, that’s the current feeling. We’ll see if I go through with any of this.
It’s always fun playing the “which faraway land is closer to me” geography puzzle when setting up an online services that doesn’t have a presence in Australia.
The answer is Hillsboro, OR — 13,021 KM from Melbourne.
Dear The Economist,
Please restore the witty headlines you use for your articles to the digital edition. That’s one of the reasons why I read you. I know you include them as postscripts at the bottom, but it’s not the same.
Sincerily,
Me
Sunny day today, yet a bit chilly. So the hat and jacket ensemble is out at the moment.
Adding a new feature to dynamo-browse and now I’m beginning to wonder if this is why JavaScript has both a null and undefined type. In short: dealing with null pointers suck. They suck in Go and I’d imagine they’d suck a million times more in C. Better to have a dedicated type representing an undefined value, with all the associated methods to simplify the code.
The thing is: JavaScript should’ve not exposed this to the user. Do they really care that nil and undefined are two separate things? Was it worth the added confusion. Hmm. I’ll try not to make the same mistake.
Got to use one of the software tools we build and sell at work for a “real” purpose today, as in not just to test something. Felt good. Don’t get to do that super often.
Maybe, before AI swallows our careers to the point where we’re little more than glorified prompt engineers, they’ll be a brief period of time where AI does the boring things in software engineering. Leave us to do the fun stuff like write the code. They can review it for us, like some fancy linter.
🎵 Going Home: Theme from Local Hero
This week’s earworm. Apparently I loved this track when I was a little kid. Well, apart from the very 80’s sound (not a criticism), I’d say the younger me had great taste.
This teeny tiny lizard made its way into my house somehow. I’ve seen it on and off over the last week, but I managed to catch it and put it outside. There’s another one running around that I’ll also need to find and rescue.
There is no way to turn this news feed off. The best you can do is “manage interests” which kicks you out to msn.com to have you tell it what topics you prefer.
Definitely not trying Windows 11. I hate software that pushes news onto you, unsolicited and with no easy way to turn off! I’ve have my news sources that I read and trust. I don’t want things pushed to me from sources with some commercial agreement that doesn’t have my interests in mind.
I’d argue that Google Reader shutting down was probably one of the best things that could happen to RSS. It might’ve been bad at the time, but it gave way to services like Feedbin that respect open standards and bring new users to the format, like myself. Having a large company like Google suck up all the oxygen in the room can’t have been good for RSS long term.
My Pinboard subscription has expired today. I don’t think I’ll be renewing it. Might be time to look for another way to manage my bookmarks.
I think GitLab wasted their effort building their “queued” MR comment feature, in which comments added to code lines are not seen by the submitter until you click “Finish Review” at the bottom of the page. I’ve never concerned myself with the feeling that I need all my comments sent to the submitter at once.
Oh sure, I’ve written a comment and then deleted it minutes later after going a bit further in the code, and I can see the benefit of this feature catching those. But I’ve trained myself to avoid doing that by simply reading ahead. I try not to raise a comment if there’s a chance that I’ll need to go back and modify/delete it. Saving the effort from catching these before the submitter sees them doesn’t seem like it’s worth the complexity of this feature, especially considering that other code review tools I usually used (which is really only GitHub) doesn’t work like that.
No, what I really want GitLab to do is hide/auto-approve files matching a certain pattern. This would be perfect for ignoring generated code changes. I don’t care if generated code changes. I really don’t. And I hate scrolling past these in MRs I need to review, especially when they take up a significant proportion of the changes. It looks like GitLab has an open issue to address this. It’s a shame that it hasn’t been addressed sooner, before this queued MR comment feature was shipped.
Yes, I’m complaining about this because I’m in a mood and I don’t like reviewing code. I blame the fact that it’s a Monday for that.
Wow, some serious work’s happening on the overhead wires of the train line. Looks like they’re replacing these old stanchions. I guess they’ve reached their end of life. Not sure how long they’ve been in service but they look quite old. Certainly older than me at the very least.
Building F5 To Run
At the risk of talking about something that I’ve only just started, I’d thought today I write about what I’m working on right now.
I’ve been going through my digital archives this weekend, trying to get it into something more permenant than the portable USB drives it’s currently stored on. Amongst all that stuff is a bunch of QBasic apps and games I wrote way back when I was a kid. Over the years it’s laid dormant but I do like revising them from time to time.
Is it a form of nostalgia? An attempts to live past glories? Maybe? I was pretty proud of them at the time, much like anyone else that’s proud of their early stuff while they’re leaning to code. And I know about the risk of living in the past at the expense of the present. But I also know that if I get rid of them, I’d regret it. I already regret loosing the things from the archive so far, due to bad disks or just missing things while copying them from portable hard-drive to portable hard-drive. I don’t want to loose any more.
So in an act of posterity, I’d figured it’s time to coat them in amber and put them online. So that’s what I’m doing now.
These apps run without issue in DosBox, and hearing about how the Wayback Machine has managed to make a bunch of DOS games playable within the browser, I wondered if I could do something similar. Anything that deals with virtualisation is always going to be a little bit involved. I guess one thing going for these is that they were written for a pretty slow machine and a pretty thin OS that would be trivial for modern hardware to emulate. The apps themselves, even compiled to an EXE file, are not very taxing on the hardware back then either. But I still expected to do a bit of heavy lifting myself.
How wrong I was! After a tiny bit of research — and by tiny I mean one Ecosia search — I managed to find a JavaScript library called JS-Dos which provides a DosBox emulator that’s runnable from a browser. All I need to do is prepare a bundle on what I want to run (more on that below) and with a bit of JavaScript, I can start a DosBox machine in the browser and mount it to a HTML element. The library does all the work.
How To Use JS-Dos
It’s still early days, but here’s what I learnt about using the library so far.
First, the library comes as a NPM package, or can be loaded from their CDN in the form of a <script> import.
I first tried using the NPM package, but I didn’t know the appropriate import statement to use, and the documentation was not forthcoming on this front.
So I went with the CDN approach. I’m using Hugo Pipes to fetch the remote JavaScript file and make a local bundle so I can host it from the site itself. It comes with some CSS which I also need to get (note, I’m using parenthesis instead of curly braces here as I’m not sure how to include two curly braces in a code-block).
(( $jsDosCSS := resources.GetRemote "https://js-dos.com/v7/build/releases/latest/js-dos/js-dos.css" ))
<link rel="stylesheet" href="(( $jsDosCSS.RelPermalink ))">
(( $jsDosJS := resources.GetRemote "https://js-dos.com/v7/build/releases/latest/js-dos/js-dos.js" ))
<script src="(( $jsDosJS.RelPermalink ))" defer></script>
I also needed to get an appropriate wdosbox emulator. This comes in the form of a WASM file, plus a small JavaScript file which
I assume is some simple bootstrapper. I’ve downloaded these and stored them in the static/emulators directory of my Hugo project.
The JSDos library loads them on demand and I needed to set the URL path prefix for these two files so that JSDos knows where to get them:
emulators.pathPrefix = '/emulators/';
Next, I needed to build a bundle. These are the DOS programs that are launched with DosBox. They’re effectively just Zip files holding some metadata, the DOS executable, and any files needed for the program to run. There’s some basic information about how to make them, and there’s even an online tool which will take on a lot of the tedious work. I’ve used it to make a couple of test bundles and it works quite well. I’d like to eventually make my bundles myself but I’ll stick with the tool for the time being, at least until I’ve got a DosBox configuration that I’m happy with. One thing the tool does is give you the ability to define an overlay so that these DOS apps are usable from within a mobile browsers. I’ll see if I can get away from needing these overlays at this stage. I’m not expecting anyone with a mobile app to try these out.
The contents of .jsdos/dosbox.conf for the test bundle `logo-2.jsdos`
[sdl]
autolock=false
fullscreen=false
fulldouble=false
fullresolution=original
windowresolution=original
output=surface
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-jsdos.map
usescancodes=true
vsync=false
[dosbox]
machine=svga_s3
language=
captures=capture
memsize=16
[cpu]
core=auto
cputype=auto
cycles=max
cycleup=10
cycledown=20
[mixer]
nosound=false
rate=44100
blocksize=1024
prebuffer=20
[render]
# frameskip: How many frames DOSBox skips before drawing one.
# aspect: Do aspect correction, if your output method doesn't support scaling this can slow things down!.
# scaler: Scaler used to enlarge/enhance low resolution modes.
# If 'forced' is appended, then the scaler will be used even if the result might not be desired.
# Possible values: none, normal2x, normal3x, advmame2x, advmame3x, advinterp2x, advinterp3x, hq2x, hq3x, 2xsai, super2xsai, supereagle, tv2x, tv3x, rgb2x, rgb3x, scan2x, scan3x.
frameskip=0
aspect=false
scaler=none
[midi]
# mpu401: Type of MPU-401 to emulate.
# Possible values: intelligent, uart, none.
# mididevice: Device that will receive the MIDI data from MPU-401.
# Possible values: default, win32, alsa, oss, coreaudio, coremidi, none.
# midiconfig: Special configuration options for the device driver. This is usually the id of the device you want to use.
# See the README/Manual for more details.
mpu401=intelligent
mididevice=default
midiconfig=
[sblaster]
# sbtype: Type of Soundblaster to emulate. gb is Gameblaster.
# Possible values: sb1, sb2, sbpro1, sbpro2, sb16, gb, none.
# sbbase: The IO address of the soundblaster.
# Possible values: 220, 240, 260, 280, 2a0, 2c0, 2e0, 300.
# irq: The IRQ number of the soundblaster.
# Possible values: 7, 5, 3, 9, 10, 11, 12.
# dma: The DMA number of the soundblaster.
# Possible values: 1, 5, 0, 3, 6, 7.
# hdma: The High DMA number of the soundblaster.
# Possible values: 1, 5, 0, 3, 6, 7.
# sbmixer: Allow the soundblaster mixer to modify the DOSBox mixer.
# oplmode: Type of OPL emulation. On 'auto' the mode is determined by sblaster type. All OPL modes are Adlib-compatible, except for 'cms'.
# Possible values: auto, cms, opl2, dualopl2, opl3, none.
# oplemu: Provider for the OPL emulation. compat might provide better quality (see oplrate as well).
# Possible values: default, compat, fast.
# oplrate: Sample rate of OPL music emulation. Use 49716 for highest quality (set the mixer rate accordingly).
# Possible values: 44100, 49716, 48000, 32000, 22050, 16000, 11025, 8000.
sbtype=sb16
sbbase=220
irq=7
dma=1
hdma=5
sbmixer=true
oplmode=auto
oplemu=default
oplrate=44100
[gus]
# gus: Enable the Gravis Ultrasound emulation.
# gusrate: Sample rate of Ultrasound emulation.
# Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
# gusbase: The IO base address of the Gravis Ultrasound.
# Possible values: 240, 220, 260, 280, 2a0, 2c0, 2e0, 300.
# gusirq: The IRQ number of the Gravis Ultrasound.
# Possible values: 5, 3, 7, 9, 10, 11, 12.
# gusdma: The DMA channel of the Gravis Ultrasound.
# Possible values: 3, 0, 1, 5, 6, 7.
# ultradir: Path to Ultrasound directory. In this directory
# there should be a MIDI directory that contains
# the patch files for GUS playback. Patch sets used
# with Timidity should work fine.
gus=false
gusrate=44100
gusbase=240
gusirq=5
gusdma=3
ultradir=C:\ULTRASND
[speaker]
# pcspeaker: Enable PC-Speaker emulation.
# pcrate: Sample rate of the PC-Speaker sound generation.
# Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
# tandy: Enable Tandy Sound System emulation. For 'auto', emulation is present only if machine is set to 'tandy'.
# Possible values: auto, on, off.
# tandyrate: Sample rate of the Tandy 3-Voice generation.
# Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
# disney: Enable Disney Sound Source emulation. (Covox Voice Master and Speech Thing compatible).
pcspeaker=true
pcrate=44100
tandy=auto
tandyrate=44100
disney=true
[joystick]
# joysticktype: Type of joystick to emulate: auto (default), none,
# 2axis (supports two joysticks),
# 4axis (supports one joystick, first joystick used),
# 4axis_2 (supports one joystick, second joystick used),
# fcs (Thrustmaster), ch (CH Flightstick).
# none disables joystick emulation.
# auto chooses emulation depending on real joystick(s).
# (Remember to reset dosbox's mapperfile if you saved it earlier)
# Possible values: auto, 2axis, 4axis, 4axis_2, fcs, ch, none.
# timed: enable timed intervals for axis. Experiment with this option, if your joystick drifts (away).
# autofire: continuously fires as long as you keep the button pressed.
# swap34: swap the 3rd and the 4th axis. can be useful for certain joysticks.
# buttonwrap: enable button wrapping at the number of emulated buttons.
joysticktype=auto
timed=true
autofire=false
swap34=false
buttonwrap=false
[serial]
# serial1: set type of device connected to com port.
# Can be disabled, dummy, modem, nullmodem, directserial.
# Additional parameters must be in the same line in the form of
# parameter:value. Parameter for all types is irq (optional).
# for directserial: realport (required), rxdelay (optional).
# (realport:COM1 realport:ttyS0).
# for modem: listenport (optional).
# for nullmodem: server, rxdelay, txdelay, telnet, usedtr,
# transparent, port, inhsocket (all optional).
# Example: serial1=modem listenport:5000
# Possible values: dummy, disabled, modem, nullmodem, directserial.
# serial2: see serial1
# Possible values: dummy, disabled, modem, nullmodem, directserial.
# serial3: see serial1
# Possible values: dummy, disabled, modem, nullmodem, directserial.
# serial4: see serial1
# Possible values: dummy, disabled, modem, nullmodem, directserial.
serial1=dummy
serial2=dummy
serial3=disabled
serial4=disabled
[dos]
# xms: Enable XMS support.
# ems: Enable EMS support.
# umb: Enable UMB support.
# keyboardlayout: Language code of the keyboard layout (or none).
xms=true
ems=true
umb=true
keyboardlayout=auto
[ipx]
# ipx: Enable ipx over UDP/IP emulation.
ipx=true
[autoexec]
echo off
mount c .
c:
type jsdos~1/readme.txt
echo on
LOGO.EXE
I’m keeping the bundles in the static/bundles directory, which sits alongside the emulator WASM file. They’re not huge binaries but I’m still using git lfs to manage them. Best to keep the the Git repository relatively sane.
Finally, it’s just a matter of adding some JavaScript to start DosBox, load the bundle, and mount it onto a HTML element:
Dos(document.querySelector("#element-to-mount")).run("/bundles/bundle-to-load.jsdos");
And that’s pretty much it.
After a few hours, I’ve managed to get a test version of this working. There are a few things that need working on: the app I’m trying require the Alt key, which is not readily available of Apple keyboards, so I may need to do something about that (JSDos comes with a virtual keyboard with Ctrl and Alt so it’s not a complete show-stopper)1. And I’ll need to get styling and more maintainable JavaScript written for this (I’m using StimulusJS for the JavaScript2). But I’m impressed by how well this works, given the minimal amount of effort from my part. Shoulders of giants and all that.
Tending to the archive of all my old projects, documents, music, etc. that have survived the many machine transfers over the years. It wasn’t the original plan for this morning, but I think it’s best I work on this now. Not sure the portable drives they’re currently on will last much longer.
Finally got my Twitter archive and uploaded it to Micro.blog (thanks @manton for the awesome feature). Happy that I’ve got an archive of them now, but if I’m honest, there’s only one tweet that I really want to keep.
I realise now the problem I have with Twitter’s request archive settings pane. It’s prompting for a password when I open the pane, not when I request the archive. I want to make sure that my request is still ongoing and I haven’t missed the “in-app notification” or it hasn’t fallen on the floor due to some queue that was backed up or no longer running or goodness knows whatever else is going on over there.
So visiting this settings pane and seeing this:
provides a good indicating that the request is still in progress.
But refreshing the page is showing the password prompt that I complained about yesterday. I completely understand getting the password challenge when I request an archive, but when I want to simply open the settings pane? Is knowing that I’ve got a pending archive request considered sensitive enough to require a password check?
Anyway, once I get the archive, I hope never to open settings again (except to eventually close my account). And just as well. I can’t say that it’s a good looking settings page. Everything looks so dull and samey.
P.S. It’s been over 24 hours, what the heck is going on over there? I have so few tweets it would’ve been quicker for me to type them out by hand.