Videos on Leon Mika

Thu, 07 May 2026 16:55:03 +1000

End of the path.

Tue, 17 Feb 2026 19:09:37 +1000

I remember. OS/2 may be gone, but it’s not forgotten. 🙂

Wed, 07 Jan 2026 06:42:02 +1000

I got around to putting together that walkthrough video of Alto for that person I’ve shared it with. Reposting it here for posterity and for anyone who’s curious. Fair warning: don’t expect amazing video production quality.

Fri, 02 Jan 2026 20:54:18 +1000

Making use of that animation package: test scene and interaction for something I’m putting together for my niece.

Devlog: An API For a Keyframe Animation Package

Tue, 30 Dec 2025 16:42:35 +1000

Spent the day building a key-frame animator for an Ebitengine project. All coded in Go, which should make it usable for some other projects in theory. I don’t have a lot of experience with animation frameworks — other than as an end-user of apps that consist of a timeline where I place keyframes — so I’m not aware of what constitutes best practice for a programatic API. So I set out to build one with an API that made sense to me. After one major iteration, this is the approach I came up with.

The core model type is the Var, which represents an animatable value. These are essentially handles describing the type of value the (package) user wants to animate. At the moment there is only a single type, which is a float:

xPos := animator.NewFloatVar()
yPos := animator.NewFloatVar()

To animate the value, the user will need to create an Animation and place any created Vars on a track. Tracks consist of key-frames, which is essentially a time offset, and one or more values a Var should have at that time. These values can be created from the Var itself, by calling Set(). This returns a type holding what that Var should be set to at that key-frame (“set” is probably not the best term for this):

moveDown := animator.NewAnimation()
posTrack := moveDown.NewTrack()

posTrack.KeyFrame(0.0, []animator.FloatSet{
  xPos.Set(0.0), yPos.Set(0.0),
})
posTrack.KeyFrame(3.0, []animator.FloatSet{
  xPos.Set(100.0), yPos.Set(100.0),
})

Not all Vars need to be included on a particular keyframe, but prior to animating, each of the Vars known to the track will need to be tweened if there isn’t a “set” for them on the key-frame, so it’s generally good practice to set all the Vars for each track. Different tracks can have a different of Vars, so if different keyframes are needed, it probably should exist on a separate track.

Animations are designed to be reusable and simply encode what the Animation is. The motivation here is that all the expensive work should be done once, when the Animation is created. To actually animate the Vars, the user will need to create a timeline and set it to the Animation.

tl := animator.NewTimeline()
tl.SetAnimation(moveDown)

This will initialise all the Var values to what they would be at frame 0 (at the moment, frame 0 must be a time 0, but down the line I’d like to remove this to allow for blending between Animations). The value of each Var can now be retrieved, as Vars only have a value within the scope of a Timeline.

x := xPos.Value(tl)
y := yPos.Value(tl)

// x and y == 0, as that is the value they were set to in the first frame
drawRect(x, y, 100, 100)

The Timeline clock is advanced by calling the Advance() method, which takes a delta in fractions of a second. This will tween all the Vars based on the current action, and the new value can be retrieved by calling Value() again. Thus the core use of this package is advancing the clock and querying the values for each tweened frame.

Within an Ebitengine project, this is done by calling Advance within Update function and sampling the values within Draw:

var (
  tl *animator.Timeline
  xPos *animator.FloatVar
  yPos *animator.FloatVar
)

func Update() {
  dt := 1.0 / float64(ebiten.TPS())  
  tl.Advance(dt)
}

func Draw(screen *ebiten.Image) {  
    vector.FillRect(screen,  
       float32(xPos.Value(tl)), float32(yPos.Value(tl)),  
       100, 100,  
       col, true,  
    )  
}

Here’s an test animation:

I’m quite happy with how this turns out. I like how little “magic” is involved in the API: values and clocks are not changed from underneath you: you need to explicitly advance the clock yourself, and read the values when you need them.

Obviously there’s room for improvement. Tracks and keyframes cannot be changed; only linear interpolation of float values are supported; and there’s no looping, bouncing, or reversing of animations. I’d hope to add all this in due time, probably based on the needs of the project I’m working on. There are also a few things I’m a little wary of, such as a global atomic int responsible for allocating an ID for each newly created Var. And the Timeline holds Var values in a map which I hope is fast enough for rendering on a screen.

But it’s nice to have something like this in my toolbox. It’s been something I’ve been wishing for a while.

Devlog: Godot Project - Level 3-2 And Bobbing Water

Mon, 08 Dec 2025 21:32:32 +1000

I spent a lot of time on distractions recently, so I was a little surprised to find myself wanting to get back to working on that Godot game. The level under design is going okay: it took a few attempts to find the right way to start. Turns out writing down how you want the level to progress helps, like having three “acts” where the first act consists of some jumping puzzles, then introducing one of the gimmick, than a variant of said gimmick, and so on.

Anyway, I’m working on the second “act” which will feature a low-power mechanic: there’s only so many units of power to energise the various zones, and the player needs to juggle it all to get through the act. Because power is involved, I wanted to have a generator sprite to provide some decoration. This is what I came up with:

It’s… fine. I did try to get some inspiration by uploaded the tile-set to Google Gemini and asked it to produce something that resembled a generator:

Using the tile set images uploaded, please provide some suggested designs for a tile-set representing an electric generator. The suggestion must match the style and colour scheme of the supplied image.

This helped, although what I have here is a fair bit different to what was generated. I may adjust the colours a bit (the simple colours are by design as I want to maintain the palette used by the existing tile-set) and I may need to add some wire decorations and maybe a sign that says “Generator” to make it clear that’s what it is, and that it’s not a cannon, as the alt-text generation suggests. We’ll see how it goes, I guess.

One other thing I found myself wanting to add is water that can be raised and lowered when activated. I came up with something from first principals that looks a little like this (the tile layer is hidden to show the Area2D shapes):

It consists of is a top-level Node2D which will raise and lower when triggered. This is done in code, just to allow me to configure the speed and displacement on a case-by-base basis. A child of that is a TileMapLayer containing the water tiles. It’s at Z-index 6, which is just in front of the player so that it looks like it engulfs them if they fall in. Four units below the top is the kill-plane — water is a hazard — and four units below that is the “bobbing” plane. This is a Node2D that simply oscillates up and down by 2 units every second. A child of that is an Area2D solid with allows the player to move through, but will collide with a new crate sprite, which also collides with everything else.

This has the effect of a water plane in which creates would appear buoyant yet slightly submerged, giving the player somewhere to stand. Activating the water layer will allow it to “drain,” bringing the crates down to rest on any solids. Activate it again and the water level will rise, catching any crates which will begin floating:

There’s probably better ways to do this, and there are some drawbacks. It can’t be bundled into a dedicated scene, so each instance will need to be built manually. And if more than one crate is in the scene, they will bob in unison (although that could probably be alleviated with splitting the bobbing plane into areas with distinct offsets). But for something devised from first principals, I’m quite happy with it.

Sun, 30 Nov 2025 14:24:28 +1000

Laughed out loud when I heard this as my experience with Stripe's API has been quite different. Stripe does quite well with keeping support for old versions of their API, but they're not afraid of making backwards-incompatible changes between versions. We encountered quite a few of these last time we were updating the SDK, and while I was going through their API docs a few weeks ago, I saw quite a few more that we'll need to make next go-around. I wouldn't call that "low needs" myself.

Tue, 11 Nov 2025 06:52:40 +1000

Slow strobes.

Tue, 11 Nov 2025 05:44:27 +1000

This clip made me think. Not because of anything to do with Apple, Google, and their dealings. Rather, it made me wonder if this is applicable to things like how one spends their time and effort at self improvement. Focusing more on what you know your good at, for example.

Devlog: Dynamo Browse - Item View Annotations and Asynchronous Tasks

Tue, 04 Nov 2025 20:42:40 +1000

The laundry list of things to do in Dynamo Browse has grown over the last week, as I find myself wanting using it and wanting more from it. I’ve knocked off many of the small ones: fixing bugs, making it easier to get the first item from a result set. The time has come to tackle some of the larger ones.

The first is the ability to annotate fields in the item view, as in add additional information to the right of the value. I would personally find that useful for describing the value of an other table using it’s ID. But the point is that it can be anything. I’d like users to add these annotations via extensions, using UCL. The way I’m thinking of doing this is by “installing” a field annotator, something along the lines as follows:

ui:add-item-annotator { |rs attr_path| 
    return ""
}

This will add an annotator which will take a result set, and a path to an attribute. It will return the annotated value. We’ll see how well this will work, but first I’ll need to build the Go types. Rendering the item view is done using an ItemRenderer which basically walks through the attributes of an item and renders it as a table. I think I’ll change this to take an item annotation. I also realised I need a type to represent the attribute path. I think a simple linked list would work here. Here’s what I got:

type AttrPathNode struct {  
    Name    string  
    Index   int  
    IsIndex bool  
    Parent  *AttrPathNode  
}

The trouble is representing both string attribute names and numerical indicies in the same type. Go doesn’t have a great way of doing this, so I’ve gone with something simple and added boolean which would be true if the node is actually an integer index to a list or set.

Actually, that may not be necessary. Poking around the renderer code, I found this type used to represent the sub items of an item:

type SubItem struct {  
    Key   string  
    Value Renderer  
}

So I can simply use strings for the key. Good to know. Okay, added a test annotator and gave it a quick test: Not bad, although found some glaring issues. It would be nice if the annotation was closer to the value. And laying out the annotations in a dedicated column will cause the entire column to shift as I move through the items. So instead of making it a separate column, I’ll try simply concatenating it to the end of the value. I’ll also apply the meta-info styling to dim the text a little: That’s much better. I’m banking on only a few attributes having annotations, so I’m hoping it won’t be as busy as it looks here.

Now to consider the UCL integration. Hmm, how am I going to connect the two? As expected, injecting the annotation directly into ItemRenderer would introduce a dependency loop. What I could do instead is add a setter allowing the caller of the ItemRenderer to change the annotation on the fly, and inject the ItemRenderer as a dependency of the command controller.

Implemented this, and it was actually easier than I thought. Now to test this. I settled on the following UCL command:

ui:set-item-annotator { |rs item path| 
    "annotation"
}

where:

rs is the result set
item is the item being rendered in the view
path is the attribute path, represented as a list.

The attribute path is a new proxy, just to reduce the amount of memory copying between Go and UCL. I kept the same list index semantics, where > 0 starts from the left, and < 0 starts from the right, but it was a little mind bending to reverse this for a linked list.

A simple annotator which returns the currently displayed item value as an annotation can be implemented as follows:

ui:set-item-annotator { |rs item path|
    $item.($path.(-1))
}

Here it is in action: Brilliant, it’s working! Naturally as commands are simple UCL statements, this could be entered on the command line.

One thing to consider is that unlike normal commands, the UCL block rendering the annotation is running on the UI thread. Not sure I like this, but the amount of effort required to change this would be significant. I guess I’ll just tell everyone to keep annotation rendering fast. And as it’s currently implement, it is reasonably fast. Or more accurately, it’s not noticeably slow, which is good enough.

The next feature to add to Dynamo Browse is a way to asynchronously schedule blocks. I think it may be worth tapping into the existing command looper in some way.

Commands in Dynamo Browse are invoked on a dedicated goroutine. Calling execute() will attempt to send a command via a channel. If that fails, execute() will return an error indicating that a command is currently running. This keeps running UCL code off the UI thread, and it also makes it possible to implement commands like ui:prompt synchronously from the UCL code’s perspective, when in reality it pauses this goroutine and sends a message to the UI with a callback to resume the thread:

func (m *uiModule) uiPrompt(
    ctx context.Context,
    args ucl.CallArgs,
) (any, error) {  
    var prompt string  
    if err := args.Bind(&prompt); err != nil {  
        return nil, err  
    }  
  
    resChan := make(chan string)  
    cancelChan := make(chan struct{})  
    go func() {  
        commandctrl.PostMsg(ctx, events.PromptForInputMsg{  
            Prompt: prompt,  
            OnDone: func(value string) tea.Msg {
                resChan <- value  
                return nil  
            },  
            OnCancel: func() tea.Msg {  
                cancelChan <- struct{}{}  
                return nil  
            },
        })  
    }()  
  
    select {  
    case value := <-resChan:  
        return value, nil  
    case <-cancelChan:  
        return nil, nil  
    case <-ctx.Done():  
        return nil, ctx.Err()  
    }  
}

So tapping into this event loop would be nice. But how does one do so?

I think, probably the simplest way to do so is with buffered channels. These are bounded, meaning that there will be an upper limit to the number of pending tasks, but maybe that’s not a bad thing. Having too many pending tasks crowding out the user’s ability to run commands will probably make for a poor user experience. So let’s set the limit to something quite generous, say 50, and integrate it into the event loop:

for {  
    select {  
    case cmdChan := <-c.cmdChan:  
        res, err := c.ExecuteAndWait(ctx, cmdChan.cmd)  
        if err != nil {  
            c.postMessage(events.Error(err))  
        } else if res != nil {  
            c.postMessage(events.StatusMsg(fmt.Sprint(res)))  
        }  
        if execCtx.requestRefresh {  
            c.postMessage(events.ResultSetUpdated{})  
        }  
        // New code here
    case task := <-c.pendingTaskChan:  
        if err := task.task(ctx); err != nil {  
            c.postMessage(events.Error(err))  
        }  
    }  
}

Now for the UCL API. I have an idea of adding a new async package for this, which will provide commands for running things asynchronously. It’s simplest command would be async:do, which will schedule a block when the command loop is free. So invoking the following:

ui:command testasync {  
    echo "This"
    async:do {
        echo "Other"
        async:do { echo "Sierra" }
    }
    async:do {
        echo "Romeo"
    }
    echo "That"
}

Should display:

This
That
Other
Romeo
Sierra

In the logs. Trying it out and here’s how it looks: Okay, that’s pretty good. Now to build on this. The next thing to add is a command that will schedule tasks in the future, similar to window.setTimeout(). For this, I plan to use the gocron package. Lots there, but for my purpose, I plan to use the OneTimeJob type. It does feel like bringing in a crane to lift an empty wood pallet, but the alternative is building my own scheduler (or getting AI to vibe-code one) using a heap. Maybe something for later, but I think this is fine for now.

To make use of this, I’ll add async:in, which takes a timeout in seconds, and a block to run. To test this, I’ll do the classic “count down” tests:

proc countdown { |from|
    if (le $from 0) {
        echo "Blast off!!"
        return
    }
    echo "$from"
    async:in 1 { countdown (sub $from 1) }
}

ui:testasync {
    countdown 10
}

Here it is in action:

One last thing to add to async, the ability to run a query in the background and execute a block once the results are available, keeping long running queries off the UCL goroutine. I think for this I will add another thread-pool which will execute up to two queries in the background, then schedule a task to run once the results are ready.

The API for running queries is pretty well established, to the point that I’ve actually got a helper functions which deal with the UCL side of things, so it’s just a matter of implementing an asynchronous version of this. I’m thinking of an interface along the following lines:

async:query <query> { |rs|
    # do something with the result-set $rs
}

It should also support keyword arguments too. Unfortunately, UCL requires keyword arguments to be placed after the positional arguments, so they would need to be placed after the block, which is a little yucky.

Implemented the code, now for the test. This one’s a little contrived. What it does is asynchronously run a query on startup, counting the number of opened and closed offices in the business-addresses table. Once those results are available, it will install a new column annotation, which will display the count to the right of the officeOpened fields.

proc _prep_officeCount {
    openedOffices = 0
    closedOffices = 0

    async:query 'officeOpened=true' { |rs|
        openedOffices = len $rs
        async:query 'officeOpened=false' { |rs|
            closedOffices = len $rs

            ui:set-item-annotator { |rs item path|
                if (eq $path.(-1) "officeOpened") {
                    if $item.officeOpened {
                        "Count = ${openedOffices}"
                    } else {
                        "Count = ${closedOffices}"
                    }
                } else {
                    ""
                }
            }
        } -table business-addresses
    } -table business-addresses
}

_prep_officeCount

It is contrived, but I’m hoping to use this in a real setting where I annotate ID fields with a value I retrieve from another table, so a use case like this is pretty close to why I built this feature. Because the queries are running in the background, the goal is to avoid blocking the UI thread, but since this runs on startup before the user selects a table, the table needs to be specified as part of the call. I may have to have a think of how I am to fix that.

But here it is working. Note the Count = 244 next to the officeOpened field:

Excellent. The next thing to do is try this out in a real setting. I finished off making a proper goroutine pool for the task that actually runs the query — which I’m calling the “aux task pool” — and a few other changes, like making the meta information a little easier to see.

Sun, 02 Nov 2025 11:38:44 +1000

Manage to catch a sighting of the Long Island Steel Train passing through Albury. 🚂

Devlog: Godot Game - Level 3-2 and a Rotating Platform

Tue, 28 Oct 2025 21:19:28 +1000

Okay, time to start level 3-2. This, like level 3-1, is in the mountainous regions. Except this time, the player will be a little higher. So that means jagged platforms, more verticality, lots of gaps: a real sense that care of where one steps must be taken.

Starting with some platforming to give this sense: a few narrow safe areas, separated by pits, leading into an area with platforms.

Now, I have two choices of mechanics here: I can have the rotating platform, or I can have an area of the tile map fall away when the player lands on it. I think I prefer the rotating platform for the sole reason that adding the falling away platform may be a little overwhelming for the player.

Actually, no. Danger and instability is the feeling I want to go for here. So I’ll add the falling platform, followed by a large safe area where the player can see the rotating player. Also, since this is a new mechanic, it’s only right that the player should play with it in a safe area first.

Okay, I’ve added the falling platform. Well to be honest, I designated an area of the field where the falling platform will go. This leads into a large safe area which would be an ideal place to introduce the rotating platforms I have in mind.

I’m thinking of a scene with an AnimationPlayer that will do the actual rotation animation: as in rotate the sprites from 0° to 90°. The question is, do I want the entire sequence timed using the AnimationPlayer? As in, have a single animation that will rotate the platform all 4 times, with gaps between each stage? Or should I stick with the AnimationPlayer simply animating a 90° rotation, and having another thing timing the wait time between stages?

I think I prefer the latter. That way, I have more control over the pause between stage rotations. I can do things like disable it, or making it configurable. All desirable features.

I guess the next question then is whether I want the AnimationPlayer at all. Wouldn’t it be more flexible to do the animation in code? Probably, but I’m not sure I want that flexibility, at least not yet. Maybe in time it would be needed, but I think for now, I’ll just stick with the AnimationPlayer.

So, let’s start building out the animation. I think I’ll start with four animations, each one rotate the platform from θ to θ+90°, just from different starting positions. I’ll use names that include the start and end angles, like rotate_0_to_90, to allow for bidirectional rotation, should I decided to add that. Angle 0° will be up, and rotation will be clockwise. I think each rotation will be 0.5 seconds at speed 1, just so I have a consistent speed control. I can adjust the speed of the overall playback on the AnimationPlayer itself.

Okay, animations made. Now to think of collision. I don’t like the idea of a collision box rotating along with the platforms. I’m not too certain about how well this plays with the physics engine, and even if there were no issues, non-orthogonal geometry is just not a thing in this game. So what I’m thinking of doing is adding two collision boxes, one horizontal and one vertical, and just toggling between the two as the platform moves into position. While the platform is rotating, both boxes will be turned off.

Ooh, I didn’t know the collision layer could be added as a animatable track. That’s pretty cool.

Now to add a Timer which will actually dictate the cadence. The included code is nice and neat: basically take the current rotation of the sprites in degrees, add 90 to it, and produce a string which will become the next animation to play:

func _on_timer_timeout() -> void:
	var next = _next_animation()
	animation_player.play(next)

func _next_animation() -> String:
	var rot = int(sprites.rotation * 180 / PI) % 360
	return "rotate_%s_to_%s" % [rot, rot + 90]

Added it to a test level, and I had to speed up the AnimationPlayer to 3x normal speed, just so that the movement is snappy enough to justify the loss of collision during the rotation. It may need further adjusting a little later, but so far works pretty well. Although I do think I need to telegraph when the platform is about to move.

Oh, I remember how I’m going to telegraph to the player when the platform is about to rotate! It’s to be an indicator panel mounted at the front that will rotate slowly on it’s own. When it reaches a new orientation it will pause, then the platform behind it will rotate.

Okay, new sprite. How the heck did I choose a canvas size with non-even dimensions and still end up with a sprite that doesn’t have a definitive centre line? 🤦

Turns out it was how I was removing the upper and lower circles. I was using the eraser for that, and I didn’t position it properly.

Okay, here’s the sprite:

Now to think about animating it. I’m wondering if it would be possible to simply add it to the same animation player as the platform. The thing is, I would like them to be somewhat independent. The indicator should move on it’s own accord, even when the platform sprite is rotating to a new orientation. I would also like the indicator to take on the platform rotation cadence, sending it a signal when it reaches a stop (this will remove the need for the Timer).

Can I do that all in a single scene though? Maybe with two animation players? I’ll try that and see how viable it is.

Okay, just tried that, and yes, using two AnimationPlayers is viable. Now to prepare the animation. The current rotation period is 3 seconds so I’ll start with a 6 second animation that would just rotate the indicator over 180° with a slight pause halfway to trigger the platform. One good thing about the indicator’s symmetry is that one animation can cover the full rotation. Although be sure to change the loop wrap mode to “Clamp”, otherwise you’ll see the sprite spin round to 0° when the animation repeats.

Here’s the full thing in action. And yeah, adding the indicator was pretty crucial in the end. The platform wouldn’t have been fair otherwise.

Wed, 22 Oct 2025 05:45:50 +1000

This sounds ominous. Does this mean more unsolicited push notifications in iOS or promotional crap added to Apple Maps? As someone who aims to not know when an F1 race is happening, it's a good indication that an iPhone is not for me.

Mon, 20 Oct 2025 05:54:01 +1000

It'd be amusing to ponder, given how podcasts all have a video component now, that if Apple did name their new box "Home Pod," in 5 years time, would people think the "pod" in "podcasts" refers to that? Everyone's referring to their shows as "pods" now I do wonder if they're forgetting where "pod" originated from.

Mon, 29 Sep 2025 22:31:18 +1000

A bit more work on my Godot game, mainly building out mechanic for world 3. Tonight it was building an old-style lift with a caged door that the player can use to travel between different heights. Turned out really well.

Animating the door was a slog, and if that was all I achieved this evening, I would’ve considered that a success. But I had a bit of time to code up the lift too. I was unsure of how to approach this at first: I knew I wanted to turn off player movement and collisions and move the player (and camera) along with the lift.

This turned out to be easier than I was anticipating. When the player enters the lift, all motion on the player is disabled (this was done by setting a “disable_motion” boolean which would break out of the players progress loop early if true) and the player node is reparented to the lift. The lift then moves to the target, taking the player with it. At the destination, the player’s original parent is restored and motion is enabled again, allowing the player to move freely. I also had to turn off camera motion smoothing before I reparented the player as it seems like some offset vectors were incorrect for a frame and it had the camera shoot to the right. This is done when the door closing animation plays, before the node is reparented which happens just before the lift moves.

There’s still work to do. The z-order seems to be messed up when the lift reaches it’s destination (the player appears in front of the doors as they open). And at the moment, the lift only goes in one direction. But I’m really happy with what was achieved tonight.

Sun, 14 Sep 2025 11:42:43 +1000

It’s amusing to imagine how far Apple’s bizarre, corporate-esque copywriting goes. Would one be able to go into Caffè Macs in Apple Park, pick up a packed sandwich, and see printed on the label:

With this sandwich, our focus is to maximise sustenance and nourishment so we can drive continued living in our employees.

We’ve also introduced a new ecosystem of ingredients to compliment this unique sandwich. Thanks to the incredible availability of nuts and other allergens, we’re able to create a new awareness that this sandwich may contain some of these.

😼

Tue, 09 Sep 2025 07:52:30 +1000

Really enjoyed this discussion on the latest Shoptalk show discussing why one would want a website. I disagree with the idea that restauranteurs can get away with just an Instagram. Restaurant websites generally suck, but I'm not sure what I'll do if they aren't around, and I can't see their menu.

Oh, and P.S. I don't know how to use Instagram.

Devlog: Dequoter — Something Different Today

Sat, 06 Sep 2025 16:10:04 +1000

When it comes to hobby projects, I’m trying to reduce the number of things I build for work. But I’ve decided to revisit one that I’ve abandoned, given the frequent need for this. The issue is simple: I have a JSON data structure that is quoted within a string, and I want to “unquote” it and filter the JSON so that I can read it.

So I thought I’d spend today restarting the Dequoter project. The best way to describe it is a Boop clone. I like Boop, I use Boop. And I know Boop is extendable, so I could implement any processor I need using JavaScript. But I’m not a huge fan of JavaScript, and Go has the function I need right there in the standard library. And with most things I encounter, I want to build my own. I know I shouldn’t, and I’ve been better at resisting. But I’d figured this could be a nice little distraction. And I thought I could get much of what I need done in a morning.

So I started a new Wales project and after about 3 hours, I had a scratchpad with an invokable command palette that I can use to dequote a string and format a JSON object:

Granted, it’s not much for 3 hours. While I did use Claude Code a little, much of this was hand rolled. And I spent a lot of time learning the ins and outs of Code Mirror. This is why I wanted to use Wales this time around. The previous run at this used Fyne, which was really nice to use, but the available widgets were quite limited. The nice thing about Wales is that I can build the UI in HTML and it uses the built-in HTML renderer from the OS: no need to bundle Chrome. The frontend is mainly vanilla HTML and JavaScript, although I am using Stimulus to help with some of the controls. The backend is, of course, Go.

Final build size is 8.4 MB.

By the end of this morning’s session, what I had was not pretty, but it’s functional and it already does what I need it to do. I do have some plans for integrating this with UCL, and using that to define processors. That should hopefully leave all the heavy core stuff to be built near the beginning, and that could sit pretty while the extensions are added in a nicer language. Anyway, more on this if this goes anywhere.

Wed, 03 Sep 2025 07:40:09 +1000

3.78 GHz for a phone chip! I remember getting a desktop clocked at just over 1 GHz and thinking that was the fastest computer I've ever used. These phone chips are almost 4 times faster, and there's like 7 cores here, with 5 clocked faster then 3 GHz. Absolutely crazy when you think about it.

Tue, 19 Aug 2025 07:19:41 +1000

Talk to anyone working on the Go language and they'll tell you about the JSON parser they built. Maybe the CSS designer equivalent is making their own CSS reset. 😏

Thu, 14 Aug 2025 22:14:16 +1000

Seeing some very interesting visitor pattens over the last two days. There seems to be two or three visitors from the US opening what seems to be every single page on this site. It’d be interesting to know who it is… or what it is. Maybe I should ask around.

Wed, 06 Aug 2025 07:26:57 +1000

Oh, interesting. That’s a good explanation as to why OpenAI et. al. would want to make a browser. And if they do tout it as being “AI powered”, then it kinda makes sense that Google would do likewise, as a defensive move to keep marketshare.

Sun, 03 Aug 2025 09:15:24 +1000

Enjoying listening to the latest Talk Show with LMNT (I'm about 67% through it so far). Especially liked this part about Safari, and not just because it validated my feelings about it. 😀

Fri, 01 Aug 2025 08:34:37 +1000

I wonder if the prudent course of action for iOS app developers is to hold off from releasing their redesigns on day one. I wonder if iOS’s new look will be overwhelming for users and having an app that’s unchanged for a week or a month could provide them with something familiar to them. 🤷

Sun, 27 Jul 2025 10:05:21 +1000

Making that Seinfield reference in my post on iPadOS 26 and Liquid Glass got my creative/meme-ing juices going. Opened DaVinci Resolve for this one.

Fri, 25 Jul 2025 08:52:56 +1000

If you asked me today, I’d probably call this game “rock paper scissors,” most likely due to my consumption of American media. But growing up, I do remember calling this game “paper scissors rock.”

Sat, 12 Jul 2025 13:13:16 +1000

Amazing Dithering this week. Loved the discussion on why Apple is so driven to remove all software chrome. Never considered that it was because of how the various teams are organised (spoilers in the included clip).

Thu, 19 Jun 2025 17:14:06 +1000

Found a particularly interesting bug in Safari when I tried adding a background transition to radio-button labels styled to look like regular buttons. Tapping the labels on the iPad causes the background colour to flicker:

Fixed it by working around the problem: I only need the transition when the user taps “Submit”, so I held-off from applying the transition attributes until that happens. But wow, what an weird way to fail.

Sat, 14 Jun 2025 16:25:52 +1000

Appreciate that there's someone else out there getting driven crazy by Apple throwing up permission pop-ups everywhere in MacOS. And the Terminal, of all places.

Sat, 07 Jun 2025 13:54:11 +1000

Chalk me up as one of those people that wished they could use Markdown everywhere. I use it for notes, for messaging, writing here, etc. I occasionally dabble with WYSIWYG editors but I always turn back to Markdown. Love it.

Sun, 18 May 2025 14:07:39 +1000

All the recent changes to UCL is in service of unifying the scripting within Dynamo Browse. Right now there are two scripting languages: one for the commands entered after pressing :, and one for extensions. I want to replace both of them with UCL, which will power both interactive commands, and extensions.

Most of the commands used within the in-app REPL loop has been implemented in UCL. I’m now in the process of building out the UCL extension support, start with functions for working with result sets, and pseudo-variables for modifying elements of the UI.

Here’s a demo of what I’ve got so far. This shows the user’s ability to control the current result-set, and the selected item programatically. Even after these early changes, I’m already seeing much better support for doing such things than what was there before.

Fri, 18 Apr 2025 14:30:18 +1000

Made some more progress on that Godot game. I haven’t gotten any further with the first level of world 2, so I’ve been spending much of my time making mechanics. One of them was the slow moving “level 2” mechanic that I stole wholesale from Super Mario World. That mechanic, despite it being frustrating to speed-runners, was always slightly interesting to me. To have areas of a level become accessible or hazardous just due to a layer of it oscillate up and down, it promised to make for some interesting timing challenges. At least in theory.

Portion of the new level showing all three new mechanics.

I decided to put that theory to the test, and start work on one the later levels. And despite being a little skeptical about whether the mechanic could carry through a level on it’s own, I came up with one that I’m reasonably happy with. The mechanic is introduce slowly, and in a rather non-threatening way, proving the player the means to get to higher ground. This leads into the second half, which will be a long underground section which will ramp up the difficulty by introducing the risk of getting crushed or missing platforms.

To compliment this is a new enemy that rushes the player. The player cannot do anything to defeat this enemy: combat is not really a thing in this game. All they could do is evade it before the enemy gives up. I am reusing the same “green slime” sprite for this but I’m hoping that the differing animations provide some hints of how this enemy’s behaviour differs from that of the simpler one.

Finally, it was time to consider checkpoints. While the first few levels were too short to justify adding them in, this one is just that bit too long without one. And given the difficulty ramp-up in the second half, having the player go through the slower first half every time they died would probably lead to frustration. So checkpoints are now a thing. They’re not free — costing 5 coins to activate — and they are sometimes mandatory, blocking the player from progressing until they pay the toll. But I think their presence helps with eliminating the areas of the level that would just be boring to play through again and again.

So yeah, I’m quite happy with this level. And I’m also happy in realising that I’m not bound to building this game in the same progression that the player will experience it. It’s better sometimes to just work on the areas that you’re ready to. I mean, it’s sounds obvious to say that now. Not sure why it took me this long to actually do so.

Tue, 08 Apr 2025 22:35:06 +1000

Spent some time over the last few days working on that Godot game, mainly building new mechanics. This evening I started working on an interceptor, something that would jump out of the quicksand in order to disrupt the player’s jump. Here’s an example of how they look in the test bed:

And yeah, they’re pretty much a carbon-copy of the Podoboos from Mario. But I think there’s a reason they’re still making an appearance in games, years after their debut in Super Mario Brothers. They’re quite a versatile enemy, making jumping challenges a bit more interesting than just seeing whether the player the clear a gap. Plus they’re reasonably easy to make.

Another mechanic taken from Mario was a switch that revealed coins and tiles for a limited time. Hit it once and the child nodes of this “timed_limited_visible” scene are displayed and activated for 10 seconds, before they disappear again:

Much like the blue P switch this mechanic takes inspiration from, the switch can only be activated once. So it may be only useful for bonuses and areas the player can afford to miss.

I had to do some special handling for nested TileMap nodes, since the player could still collide with them even when they’re hidden. How I solved this was nothing too spectacular: basically I just walk the child tree looking for TileMap instances, and when encountering one, just enabling or disabling the first layer:

func _show_and_activate_children():
    visible = true
    process_mode = Node.PROCESS_MODE_INHERIT
    for tm in find_children("*", "TileMap", false):
        tm.set_layer_enabled(0, true)

func _hide_and_deactivate_children():
    visible = false
    process_mode = Node.PROCESS_MODE_DISABLED
    for tm in find_children("*", "TileMap", false):
        tm.set_layer_enabled(0, false)

Building these elements was fun, but the main problem is that I’m struggling to come up with a centrepiece mechanic for level 2-1, something that defines the level in some way. I have an idea for level 2-2 — this world is set in a desert so I’m hoping to introduce a thirst mechanic — but level 2-1 I’m hoping to keep relatively plain so as to avoid overwhelming the player with too many new things. The fear is to avoid making it little more than what the player encountered in world 1: a series of jumping puzzles over pits. Sure, that’s pretty much the entire game in a way, but some variety would be nice.

I’m hoping one of these mechanics could help here. I guess I’ll find one once I’ve start seriously building the level.

Tue, 01 Apr 2025 20:52:50 +1000

Started working on world 2, and one of the main mechanics of this world: quicksand. It won’t kill the player directly, but it will make it difficult for them to manoeuvre, and getting too low could cause death. Might be one of the more annoying mechanics in the game, but that’s kind of the point.

Mon, 24 Mar 2025 21:39:10 +1000

A bit more on Godot this evening, mainly working on pausing the game, and the end-of-level sequence. Have got something pretty close to what I was looking for: a very Mario-esc sequence where the player enters a castle, it start auto-walking the character, and the level stats show up and “spin” for a bit. Not too bad, although I may need to adjust the timing and camera a little to keep the stats from being unreadable.

Adventures In Godot: Respawning A Falling Platform

Sat, 08 Mar 2025 11:35:07 +1000

My taste of going through a Godot tutorial last week has got me wanting more, so I’ve set about building a game with it. Thanks to my limited art skills, I’m using the same asset pack that was used in the video, although I am planning to add a bit of my own here and there.

But it’s the new mechanics I enjoy working on, such as adding falling platforms. If you’ve played any platformer, you know what these look like: platforms that are suspended in air, until the player lands on them, at which point gravity takes a hold and they start falling, usually into a pit killing the player in the process:

The platforms are built as a CharacterBody2D with an Area2D that will detect when a player enters the collision shape. When they do, a script will run which will have the platform “slipping” for a second, before the gravity is turned on and the platform falls under it’s own weight. The whole thing is bundled as a reusable scene which I could drag into the level I’m working on.

I got the basics of this working reasonably quickly, yet today, I had a devil of a time going beyond that. The issue was that I wanted the platform to respawn after it fell off the map, so that the player wouldn’t get soft-locked at at an area where the platform was needed to escape. After a false-start trying to reposition the platform at it’s starting point after it fell, I figured it was just easier to respawn the platform when the old one was removed. To do this I had to solve two problems:

How do I get the platform starting point?
How can I actually respawn the platform?

Getting The Starting Point

A Node2D object has the property global_position, which returns the position of the object based on the world coordinates. However, it seems like this position is not correct when the _init function of the attached script is called. I suspect this is because this function is called before the platform is added to the scene tree, when the final world coordinates are known.

Fortunately, there exists the _ready notification, which is invoked when the node is added to the scene tree. After some experimentation, I managed to confirm that global_position properly was correct. So tracking the starting point is a simple as storing that value in a variable:

var init_global_position = null

func _ready():
	init_global_position = global_position

Another option is to use the _enter_tree() notification. From the documentation, it looks like either would probably work here, with the only difference being the order in which this notification is invoked on parents and children (_enter_tree is called by the parent first, whereas _ready is called by the children first).

Respawning The Platform

The next trick was finding out how to respawn the platform. The usual technique for doing so, based on the results of my web searching, is to load the platform scene, instantiate a new instance of it, and added it to the scene tree.

@onready var FallingPlatform = preload("res://scenes/falling_platform.tscn")

func respawn():	
    var dup = FallingPlatform.instantiate()
    add_child(dup)

Many of the examples I’ve seen online added the new scene node as a child of the current node. This wouldn’t work for me as I wanted to free the current node at the same time, and doing so would free the newly instantiated child. The fix for this was easy enough: I just added the new node as a child of the current scene.

@onready var FallingPlatform = preload("res://scenes/falling_platform.tscn")


func respawn():	
    var dup = FallingPlatform.instantiate()
    get_tree().current_scene.add_child(dup)
    queue_free()

I still had to reposition the new node to the spawn point. Fortunately the global_position property is also settable, so it was simply a matter of setting that property before adding it to the tree (this is so that it’s correct when the newly instantiated node receives the _ready notification).

@onready var FallingPlatform = preload("res://scenes/falling_platform.tscn")

func respawn():	
    var dup = FallingPlatform.instantiate()
    dup.global_position = init_global_position
    get_tree().current_scene.add_child(dup)
    queue_free()

This spawned the platform at the desired positioned, but there was a huge problem: when the player jumped on the newly spawn platform, it wouldn’t fall. The Area2D connection was not invoking the script to turn on the gravity:

It took me a while to figured out what was going on, but I came to the conclusion that the packed scene was loading properly, but without the script attached. Turns out a Script is a resource separate from the scene, and can be loaded and attached to an object via the set_script method:

@onready var FallingPlatform = preload("res://scenes/falling_platform.tscn")
@onready var FallingPlatformScript = preload("res://scripts/falling_platform.gd")

func respawn():	
    var dup = FallingPlatform.instantiate()
    dup.set_script(FallingPlatformScript)

    dup.global_position = init_global_position
    get_tree().current_scene.add_child(dup)
    queue_free()

Finally, after figuring all this out, I was able to spawn a new falling platform, have it positioned at the starting position of the old platform, and react to the player standing on it.

The time it took to work this out is actually a little surprising. I was expecting others to run into the same problem I was facing, where they were trying to instantiate a scene only to have the scripts not do anything. Yet it took me 45 minutes of web searching through Stack Overflow and forum posts that didn’t solve my problem. It was only after a bit of experimentation and print-debugging on my own that I realised that I actually had to attached the script after instantiating the node.

To be fair, I will attribute some of this to not understanding the problem at first: I actually thought the Area2D wasn’t actually being instantiated at all. Yet not one of the Stack Overflow answers or forum post floated the possibility that the script wasn’t being loaded alongside the scene. This does suggest to me that my approach may not be optimal. There does exist a “Local to Scene” switch in the script inspector that could help, although turning it on doesn’t seem to do much. But surely there must be some way to instantiate the script alongside the scene.

Anyway, that’s for later. For now, I’m happy that I’ve got something that works.

Sun, 02 Mar 2025 16:31:50 +1000

It lives!

Mon, 24 Feb 2025 21:02:53 +1000

Prototyped a game I had in mind, sort of a 2D Sokoban-like thing, where you control a robot with a retractable pushing arm that is to push gems to a “receiver” tile. Not entirely sure if it’s fun enough to actually build.

Used PixiJS to build it. Not a bad framework.

Fri, 14 Feb 2025 16:04:47 +1000

So sorry to hear about the loss of @merlinmann's pet lizard, which I just learnt is a central bearded dragon (they're good looking lizards). I didn't include it in the clip but he had some really nice things to say about it.

Tue, 11 Feb 2025 10:39:58 +1000

Request for any open-source projects that want to put banner ads on their site: please consider hard-coding the height of your banner to prevent the ad from reflowing the page. Otherwise, it may have an impact on the experience of those reading your docs.

Tue, 11 Feb 2025 09:00:32 +1000

Oh, that’s nice. Looks like Obsidian allows you to set the starting ordinal for numbered lists.

This was something I wish vanilla Markdown had for a while, so it’s good to see at least one Markdown editor embracing this.

Sun, 19 Jan 2025 14:16:38 +1000

Just heard the name for John's new app. Must say I kinda like it. It grows on you. No spoilers (except in the clip), but I do appreciate that it follows a similar vein to the crazy names I came up with. It just does it so much better.

Sat, 28 Dec 2024 10:30:36 +1000

More fun today working on Blogging Tools. Finished a feature for uploading larger videos to object storage so they can be added to a post using the standard video tag, as opposed to an embedded video player. If you see the screencast below, that means it’s working.

Tue, 24 Dec 2024 09:45:03 +1000

That’s it! I’m never going to use a framework that uses Webpack or installs more than 5 Node dev dependencies. Why? Because every time I check it out to work on it, all these dependencies break, and I’m left to spend hours updating them.

Never again! 😡

Sun, 22 Dec 2024 19:31:20 +1000

I wonder if we could convince Ben to order another run of Stratechery mugs shaped like the one he drinks from. I really like my Stratechery mug — it's one I often use — yet the mug he describes here is intriguing.

Sat, 07 Dec 2024 13:19:05 +1000

In other building-small-things-for-myself news, I spent a bit of time this morning on the image processor for Blogging Tools. The big new change was adding support for working with multiple source images, instead of just one. This made way for a new “Phone Shot” processor, which arranges multiple screenshots of phone apps in a row, while also downscaling them and proving some quick crops and distribution options.

This should reduce the vertical size of mobile app screenshots I post here, something that’s been bothering me a little.

Fri, 29 Nov 2024 16:20:43 +1000

Agree with @manton here. I used to be quite religious about Test Driven Development, but I'm less so nowadays. For the simple stuff, it works great; but for anything larger, you know little about how your going to build something until after you build it. Only then should you lock it in with tests.

Fri, 15 Nov 2024 07:57:50 +1000

Listening to this part of HV got me wondering if the secret to punctual trains is just a whole lot of them. You’re less likely to do something to delay a train — like hold the doors open — if you know the next one’s only a few minutes away, and will arrive on time. One builds on the other.

Wed, 06 Nov 2024 15:48:21 +1000

Just to add one point of anecdata to Ben’s experience: I’ve never been happy with the performance of the mobile radio of Pixel phones. You can be in the middle of the CBD and still experience weird dropouts while using mobile data. It’s quite frustrating.

Sat, 05 Oct 2024 17:10:47 +1000

While on my walk, I stopped briefly to clear a stone from my shoe and this purple swamphen (or pūkeko for our Kiwi friends) came up quite close to me. Not sure why. Looking for food maybe?

Tue, 06 Aug 2024 21:39:25 +1000

My recent exploration of Fyne has got me looking at building a level editor again. Have started work on the viewport, with camera movement using the WASD keys, and a basic mouse tracker for painting cells. Feels pretty good so far, although the cell mouse tracker might need some refinement.

Sun, 04 Aug 2024 22:20:36 +1000

Spending some time with the birds. Archie’s on heat, which is why she’s making those chirping noises. Ivy’s happily keeping to herself off to the side.

Day Trip to Bundanoon

Sun, 09 Jun 2024 23:26:00 +1000

Decided to go on a day trip to Bundanoon today. It’s been five years since I last visited and I remember liking the town enough that I thought it’d be worth visiting again. It’s not close, around 1 hour and 40 minutes from Canberra, but it not far either and I thought it would be a nice way to spend the day. Naturally, others agreed, which I guess explains why it was busier than I expected, what with the long weekend and all. Fortunately, it wasn’t too crowded, and I still had a wonderful time.

The goal was to go on a bush-walk first. I chose to do the Erith Coal Mine track, for no particular reason other than it sounded interesting. This circuit track was meant to take you to a waterfall by an old coal mine. However, the track leading to the actual mine was closed, thanks to the recent rain. In fact, if I could describe the bush-walks in one word, it would be “wet”. The ground was soaked, as were the paths, and although conditions were lovely, the paths were still very slippery.

Eirth Coal Mine track starting off pretty well, if a little wet.

Starting our desent into the vally.

Continuing our desent via these elevated platforms. The stairs here were very narrow.

I assume the path is meant to cross this flat stone, which I'm guessing is either dry, or has a small stream. But all the recent rain has turned it into a torrent.

My make shift walking staff, which prooved useful getting through the slippery parts of the trail.

View behind me as a start climbing back to road level.

I assume the mine was across these rocks, but there was no way I was going to cross it.

After completing that circuit in probably 45 minutes, my appetite for bush-walking was still unsatisfied, so I tried the Fairy Bower Falls walk next. This was not as steep as the first one, but it turned to be a much harder track due to how wet and slippery everything was.

Enterance to Fairy Bower Falls walk.

This track wet and very slippery. Much of it was barely walkable if you wanted to keep your shoes dry.

This was the best shot I have of the waterfall, which is pretty bad, but I can assure you, it was there amongst the trees.

The walk back to the road. This was much easier, partly because it was uphill but also because I know I already walked this part once.

I stopped short of the end of this one too, as it seems the path was washed away. But I did manage to get a glimpse of the waterfall, so I’m considering that a win.

After that, I returned to the town for lunch and some train spotting. The train line to Goulburn runs through Bundanoon, and the last time I was there, there was probably a freight train every hour or so. So I was hoping to get a good view of a lot of freight traffic. Maybe shoot a video of a train passing through the station I could share here.

Bundanoon train station.

I had lunch outside and walked around the town a little, always within sight of the railway line, hoping for at least one train to pass through. But luck wasn’t on my side, and it wasn’t until I was on my way home that I saw what I think was a grain train passing through Wingello. I pulled over to take a video, and while I miss the locomotive, I got a reasonable enough recording of the wagons.

Stopping by the side of the road to film these grain wagons passing by.

Being a little more hopeful, I stopped at Tallong, the next town along the road. I bought a coffee and went to the station to drink it and hopefully see a train pass through. Sadly, it was not to be. So I decided to head back home.

Tallong train station.

So the train spotting was a bust, and the bush-walks were difficult, but all in all it was quite a nice day. I look forward to my next visit to Bundanoon. Lets hope the trains are running a little more frequently then.

Thu, 06 Jun 2024 21:56:07 +1000

Attempting to give head scratches while recording video is more difficult than it looks. 🦜

Small Calculator

Sun, 07 Apr 2024 21:19:01 +1000

Date: Unknown, but probably around 2005

Status: Retired

Give me Delphi 7, a terminal control, and an expression parser, and of course I’m going to build a silly little REPL program.

I can’t really remember why I though this was worth spending time on, but I was always interested in little languages (still am), and I guess I though having a desk calculator that used one was worth having. I was using a parser library I found on Torry’s Delphi Pages (the best site at the time to get free controls for Delphi) for something else, and after getting a control which simulated a terminal, I wrote a very simple REPL loop which used the two.

Example of basic usage.

And credit to the expression parser developer: it was pretty decent. It supported assignments and quite a number of functions. Very capable for powering a desk calculator.

List of functions the parser library supported.

For a while the app was simply that. But, as with most things like this, I got the itch to extend it a little. I started by added a few extra commands. Simple things, like one that would echo something to the screen. All quite innocent, if a little unnecessary. But it soon grew to things like if statements, blocks using curly brackets, and function definitions.

It even extended to small batch scripts, like the one below. The full set of commands is listed here.

x := 2
y := 3

if {x = y} {echo 5} \
  {echo 232}

return

These never went anywhere beyond a few tests. The extra commands was not really enough to be useful, and they were all pretty awful. I was already using a parser library so I didn’t want to spend any time extending it. As a result, many of these extensions were little more than things that scanned and spliced strings together. It was more of a macro language rather than anything else.

The full set of extensions.

Even with the expression parser the program didn’t see a great deal of use. I was working on the replacement at the time which would eventually be much more capable, and as soon as that was ready, this program fell out of use.

Even so, it was still quite a quirky little program to make a bit of an impression.

Sat, 06 Apr 2024 11:59:36 +1000

🎥 I’ve released a video tutorial on how to use and configure the Sidebar For Tiny Theme. This walks through the process of creating and using a custom Micro.blog theme to configure the sidebar with custom HTML. Hope others find it useful.

Sat, 30 Mar 2024 11:17:22 +1000

Picnic train, now boarding. 🚂

Photo Bucket Update: More On Galleries

Tue, 05 Mar 2024 21:43:05 +1000

Spent a bit more time working on Photo Bucket this last week¹, particularly around galleries. They’re progressing quite well. I’m made some strides in getting two big parts of the UI working now: adding and removing images to galleries, and re-ordering gallery items via drag and drop.

I’ll talk about re-ordering first. This was when I had to bite the bullet and start coding up some JavaScript. Usually I’d turn to Stimulus for this but I wanted to give HTML web components a try. And so far, they’ve been working quite well.

The gallery page is generated server-side into the following HTML:

<main>
  <pb-draggable-imageset href="/_admin/galleries/1/items" class="image-grid">
    <pb-draggable-image position="0" item-id="7">
      <a href="/_admin/photos/3">
        <img src="/_admin/img/web/3">
      </a>
    </pb-draggable-image>
        
    <pb-draggable-image position="1" item-id="4">
      <a href="/_admin/photos/4">
        <img src="/_admin/img/web/4">
      </a>
    </pb-draggable-image>
        
    <pb-draggable-image position="2" item-id="8">
      <a href="/_admin/photos/1">
        <img src="/_admin/img/web/1">
      </a>
    </pb-draggable-image>        
  </pb-draggable-imageset>
</main>

Each <pb-draggable-image> node is a direct child of an <pb-draggable-imageset>. The idea is that the user can rearrange any of the <pb-draggable-image> elements within a single <pb-draggable-imageset> amongst themselves. Once the user has moved an image onto to another one, the image will signal its new position by firing a custom event. The containing <pb-draggable-imageset> element is listening to this event and will respond by actually repositioning the child element and sending a JSON message to the backend to perform the move in the database.

A lot of this was based on the MDN documentation for drag and drop and it follows the examples quite closely. I did find a few interesting things though. My first attempt at this was to put it onto the <pb-draggable-image> element, but I wasn’t able to get any drop events when I did. Moving the draggable attribute onto the <a> element seemed to work. I not quite sure why this is. Surely I can’t think of any reason as to why it wouldn’t work. It may had something else, such as how I was initialising the HTTP components.

Speaking of HTML components, there was a time where the custom component’s connectedCallback method was being called before the child <a> elements were present in the DOM. This was because I had the <script> tag in the the HTML head and configured to be evaluated during parsing. Moving it to the end of the body and loading it as a module fixed that issue. Also I found that moving elements around using element.before and element.after would actually call connectedCallback and disconnectedCallback each time, meaning that any event listeners registered within connectedCallback would need to be de-registered, otherwise events would be handled multiple times. This book-keeping was slightly annoying, but it worked.

Finally, there was moving the items with the database. I’m not sure how best to handle this, but I have that method that seems to work. What I’m doing is tracking the position of each “gallery item” using a position field. This field would be 1 for the first item, 2 for the next, and so on for each item in the gallery. The result of fetching items would just order using this field, so as long as they’re distinct, they don’t need to be a sequence incrementing by 1, but I wanted to keep this as much as possible.

The actual move involves two update queries. The first one will update the positions of all the items that are to shift left or right by one to “fill the gap”. The way it does this is that when an item is moved from position X to position Y, the value of position between X and Y would be changed by +1 if X > Y, or by –1 if Y > X. This is effectively the same as setting position X to X + 1, and so on, but done using one UPDATE statement. The second query just sets the position of item X to Y.

So that’s moving gallery items. I’m not sure how confident I am with this approach, but I’ve been testing this, both manually and by writing unit tests. It’s not quite perfect yet: I’m still finding bugs (I found some while coming up with these screencasts). Hopefully, I’ll be able to get to the bottom of them soon.

The second bit of work was to actually add and remove images in the gallery themselves. This, for the moment, is done using a “gallery picker” which is available in the image details. Clicking “Gallery” while viewing an image will show the list of galleries in the system, with toggles on the left. The galleries an image already belongs to is enabled, and the user can choose the galleries they want the image to be in by switching the toggles on and off. These translate to inserts and remove statements behind the scenes.

The toggles are essentially just HTML and CSS, and a bulk of the code was taken from this example, with some tweaks. They look good, but I think I may need to make them slightly smaller for mouse and keyboard.

I do see some downside with this interaction. First, it reverses the traditional idea of adding images to a gallery: instead of doing that, your selecting galleries for an image. I’m not sure if this would be confusing for others (it is modelled on how Google Photos works). Plus, there’s no real way to add images in bulk. Might be that I’ll need to add a way to select images from the “Photos” section and have a dialog like this to add or remove them all from a gallery. I think this would go far in solving both of these issues.

So that’s where things are. Not sure what I’ll work on next, but it may actually be import and export, and the only reason for this is that I screwed up the base model and will need to make some breaking changes to the DB schema. And I want to have a version of export that’s compatible with the original schema that I can deploy to the one and only production instance of Photo Bucket so that I can port the images and captions over to the new schema. More on this in the future, I’m sure.

Apparently I’m more than happy to discuss work in progress, yet when it comes to talking about something I’ve finished, I freeze up. 🤷 ↩︎

Photo Bucket Galleries and Using the HTML Popover API

Mon, 19 Feb 2024 22:05:48 +1000

Spent a bit more on Photo Bucket this evening. Tonight I started working on galleries, which’ll work more or less like albums.

At the moment you can create a gallery and add a photo to it. Most of the work so far has been backend so the UI is pretty rough. Eventually you’ll be able to do things like rearrange photos within galleries, but for the moment they’ll just be added to the end.

I did need to add some modals to the UI, such as the New Gallery model that’s shown for the gallery name. This gave me the opportunity to try out the new popover API. And yeah, it does exactly what it says on the tin: add the popover attribute to an element and it becomes a working popover (at least in the latest version of Vivaldi). Must say it’s impressive that this is now possible with HTML alone.

The initial version of the modals used a <div> for the popover target. And while that worked, there were some small annoyances. First was that the form within the popover didn’t get focus when the popover was displayed. It would be nice to click “New” and start typing out the gallery name. But this is a small thing that’s easily solvable with JavaScript, so it’s no big deal.

The second, slightly larger one, was that dismissing the popover by clicking outside of it will not eat the input. If you were to click a sidebar link while the New Gallery model is opened, you’ll end up on that newly selected page. I’m not a fan of this. Dismissing the popover feels like its own user gesture, and I fear the user accidentally activating things when all they’re trying to do is dismiss the popover (it’s not in place now, but I am planning to dim the background when the Create Gallery modal is visible).

Fortunately, there’s a simple solution to this. It turns out that replacing the <div> element with a <dialog> element would solves both problems. It works seamlessly with the new popover attributes, yet showing the dialog will give focus to the form, and will eat the click when the user dismisses it.

Perfect. Looks like I’ve delayed the need for JavaScript a little longer (it will come eventually; it always will).

Build Indicators

Mon, 29 Jan 2024 19:31:00 +1000

AKA: Das Blinkenlights

Date: 2017 — now

Status: Steady Green

I sometimes envy those that work in hardware. To be able to build something that one can hold and touch. It’s something you really cannot do with software. And yeah, I dabbled a little with Arduino, setting up sketches that would run on prebuilt shields, but I never went beyond the point of building something that, however trivial or crappy, I could call my own.

Except for this one time.

And I admit that this thing is pretty trivial and crappy: little more than some controllable LEDs. But the ultimate irony is that it turned out to be quite useful for a bunch of software projects.

The Hardware

The build indicator light shield, on top of an Arduino.

I built this Arduino shield a while ago, probably something like 2013. It’s really not that complicated: just a bunch of LEDs wired up in series to a bunch of resistors atop an Arduino prototyping shield. The LEDs can be divided up into two groups of three, with each group having a red, amber, and green LED, arrange much like two sets of traffic lights. I’m using the analogue pins of the Arduino, making it possible to dim the LEDs (well, “dimmed”: the analogue pins are little more than a square pulse with an adjustable duty cycle).

Build indicator shield beside a rather dusty Arduino Duemilanove.

The underside of the shield, show the connection between the resistors and the LEDs.

I can’t remember why I built this shield originally: it might had something to do with train signals, or maybe they were intended as indicators right out of the box. But after briefly using them for their original purpose, it sat on my desk for a while before I started using them as indicator lights. Their first use was for some tool that would monitor the download and transcode of videos. This would take between 45–60 minutes, and it was good to be able to start the job, leave the room, and get the current progress without having to wake the screen while I pass by the door. The red LED will slowly pulse while the download was in progress, then the yellow LED will start flashing when transcoding begins. Once everything is done, the green LED will be lit (or the red LED, which will indicate an error). The Arduino sketch had a bunch of predefined patterns, encoded as strings. Each character would indicate an intensity, with “a” being the brightness, and “z” being the dimmest (I believe the space or dot meant “off”). Each LED could be set to a different pattern, which was done via commands sent over the RS-232 connection. I think the code driving this connection was baked into the download-and-transcode tool itself. The Arduino would reset whenever the RS-232 connection is formed, and just letting it do this when the tool started up meant that I didn’t need to worry about connection state (it didn’t make the code portable though).

Watching Webpack

Eventually this tool fell out of use, and for the long time this board sat in my drawer. Projects came and went, until one came along with a problem that was perfect for this device. I was working on a HTML web-app and I was switching between the code and a web-browser, while Webpack was watching for changes. Because I only had a single screen, the terminal was always out of sight — behind either the code editor or the web-browser — and the version of Webpack I was using would stop watching when it encountered an error (a Go application was serving the files, and Webpack was simply deploying the bundle assets to a public folder, so even though Webpack would stop working, the actual web-server will continue running). Not seeing these errors, I’d fall into the trap into thinking that I was changing things, and getting confused as to why I wasn’t seeing them in the browser. I could go for a minute or two like this before I found out that Webpack died because of an earlier error and my changes were not getting deployed at all. So I dug this device out, built a very simple Go CLI tool and daemon that would talk to it, and hacked it into the Webpack config. When a Webpack build started, it would light up the amber LED. If the build was successful, the green LED would light up; if not, the red LED would.

The green LED lit, indicating that the last build was successful.

The amber LED, indicating a build in progress.

The red LED, indicating a failed build.

This proved to be super useful, and took out the guesswork of knowing when a change was deployed. As long as the green LED was lit, it’s good to go, but as soon as amber becomes red, I know I’ll have to check for errors and get it green once more.

The sketch and daemon software is a lot simpler than what this device used to do. Now, instead of individual patterns of intensity, the daemon — which is itself controlled by a CLI tool — would communicate to the device using a very simple protocol that would either turn LEDs on or off. Some of the protocol details, taken from the Arduino sketch, are included below:

/*
 * ledstatus - simple led indicators
 * 
 * SERIAL FORMAT
 * 
 * Commands take the form:  <cmd> <pars>... NL.  Any more than
 * 8 bytes (1 command, 7 parameters) will be ignored.
 * 
 * Responses from the device will take the form: <status> <par>... NL
 * 
 */

// Commands
\#define CMD_NOP       0x0
\#define CMD_PING      'p'   // a ping, which should simply respond with RES_OK
\#define CMD_TURN_ON   'o'   // 'o' <addr>   :: turn on the leds at these addresses
\#define CMD_TURN_OFF  'f'   // 'f' <addr>   :: turn off the leds at these addresses

// Response
\#define RES_OK        '1'

\#define PIN_ADDR_G1   (1 << 0)
\#define PIN_ADDR_Y1   (1 << 1)
\#define PIN_ADDR_R1   (1 << 2)
\#define PIN_ADDR_G2   (1 << 3)
\#define PIN_ADDR_Y2   (1 << 4)
\#define PIN_ADDR_R2   (1 << 5)

But in a way the simplicity actually helps here. Because it’s now a command and daemon, I could use it in anything else where I’d like to show progress without having to see the screen. Just now, for example, I’m working on a Go project that uses Air to rebuild and restart whenever I change a template. The cycle is slightly longer than a simple Webpack run, and I tend to reload the browser window too soon. So waiting for this device to go from amber to green cuts down on these early reloads.

The ledstatus command line tool. It would communicate with the daemon via gRPC bound to a local TCP port.

So thats the Build Indicators. The project is steady, and I have no desire to do anything significant, like modify the hardware. But if I were to work on it again, I think I’d like it to add variable intensity back, and extend the command language to let the user upload customer patterns. But for the moment, it’s doing it’s job just fine.

Fri, 26 Jan 2024 15:08:32 +1000

Working on one of the admin sections of the project I was alluding to yesterday. Here’s a screencast of how it’s looking so far.

The styling and layout is not quite final. I’m focusing more on functionality, and getting layout and whitespace looking good always takes time. But compared to how it looked before I started working on it this morning, I think it’s a good start.

Wed, 10 Jan 2024 20:49:46 +1000

In the end it took significantly more time to write about it then to actually do it, but the dot product approach seems to work.

Download video

Wed, 10 Jan 2024 15:39:38 +1000

🎥 Elm Connections #7: Deploying

In which I round out the series by deploying Clonections to Netlify.

Mon, 08 Jan 2024 11:26:46 +1000

🎥 Elm Connections #6: Fetching And JSON Decoding Puzzles

In which I use Elm’s HTTP client and JSON decoder to fetch puzzles from an external resource.

Wed, 03 Jan 2024 09:30:48 +1000

🎥 Elm Connections #5: Option Shuffling

In which I use Elm’s random number generator to shuffle the options.

Mon, 01 Jan 2024 19:15:25 +1000

🎥 Elm Connections #4: Styling

In which I put away Elm for a bit to make the playfield look good (or at least, better than it was).

Wed, 27 Dec 2023 12:40:13 +1000

🎥 Elm Connections #3: Group Matching

In which I work on “categories”, the model and logic that deals with the groups the player is to “connect”, plus find my way with how sets work in Elm.

Tue, 26 Dec 2023 10:35:06 +1000

🎥 Elm Connections #2: Starting The Playfield

In which I continue work on a Connections clone in Elm by starting work on the playfield.

Sun, 24 Dec 2023 08:23:39 +1000

🎥 Elm Connections #1: First Steps

In which I record video of me building a Connections (or Conlextions) clone in Elm (while at the same time, have a go at editing video).

Fri, 22 Dec 2023 12:29:15 +1000

Making some progress in learning Elm for building frontends. Started working on a Connections clone, which I’m calling “Clonections”. This is what I’ve got so far:

It’s been fun using Elm to build this. So far I’m liking the language. Of course, now I’ll have to come up with puzzles for this. 😐

Sun, 17 Dec 2023 08:47:51 +1000

I realise I’ve been posting a lot about Ivy, and not a whole lot about Archie. So to even the scales a little, here’s a video of Archie receiving a head scratch this morning.

Download

Wed, 06 Dec 2023 08:20:14 +1000

🥛🦜

Should state that both vessels hold ordinary tap water.

Sun, 03 Dec 2023 20:09:27 +1000

Spent a little more time working on my idea for Dynamo-Browse this week. Managed to get it somewhat feature complete this weekend:

Download Video

I probably should say a few words on what it actually is. The idea is to make it quick and easy to run pre-canned queries based on the currently selected item and table.

Let’s say you’ve got a table with customer information, and another table with subscription information, and they’re linked with some form of customer ID. If you wanted to see the subscriptions of a customer, up until now, you’d have to copy the customer ID to the paste-board, change the currently viewed table, then run a query to select the subscription with that customer ID. It’s not difficult but it’s extremely tedious.

This change is meant to streamline this. Now, in a script function, you can define a “related item” provider which, if matched against the currently displayed table, will be given the currently selected item, and will return a list of queries that will display items related to the current item (depending on whatever definition of “related” will be). This will be presented to the user as a list. When the user chooses the item, the query will run and the results will be displayed.

Here’s an example of the script used for the screencasts:

ext.related_items("business-addresses", func(item) {
    return [
        {"label": "Customer", "query": `city=$city`, "args": {"city": "Austin"}},
        {"label": "Payment", "query": `address^="3"`},
        {"label": "Thing", "table": "inventory", 
            "query": `pk=$pk`, "args": {"pk": "01fca33a-5817-4c27-8a8f-82380584e69c"}},
    ]
})

ext.related_items("inventory", func(item) {
    sk := string(item.attr("sk"))
    return [
        {"label": "SK: " + sk, "table": "business-addresses", 
            "query": `pk^=$sk`, "args": {"sk": sk}},
    ]
})

Notice how the last business-addresses item specifies the “inventory” table, and that the “inventory” provider actually uses an attribute of the item. Here’s a screencast of that working:

Download Video

This feature has been on the idea board for a while. I was trying to work out how best to handle the pre-canned queries, especially considering that they will likely be different for each item and table. Some ideas I had were adding additional UI elements that the user could use to configure these queries. These would go into the workspace file, a sort of an embedded database which is created for each session. This was pretty crappy, especially when you consider that workspaces usually only last until the user exists. It was only a few weeks ago when I considered using the scripting facilities to implement this (which, honestly, shows how much it remains under-utilised).

Anyway, I’ve only just finished development of it. I’d still like to try it for the various related items I tend to use during my day-to-day. We’ll see how well it works out.

Idea For Mainboard Mayhem: A Remote Pickup

Sun, 19 Nov 2023 20:21:56 +1000

Sort of in-between projects at the moment so I’m doing a bit of light stuff on Mainboard Mayhem. I had an idea for a new element: a remote control which, when picked up, will allow the player to toggle walls and tanks using the keyboard, much like the green and blue buttons.

I used ChatGGT to come up with some artwork, and it produced something that was pretty decent.

Prompt: pixel art of a remote control with a single red button styled like the tiles found in Chips Challange, rotated 45 degrees to the right.

Only issue was that the image was huge — 1024 x 1024 — and the tiles in Mainboard Mayhem were only 32 x 32.

I tried shrinking it down in Acorn, using various scaling algorithms. The closest that worked was bringing it down slowly to about 128 x 128 using Nearest Neighbour, than trying to go all the way down to 32 x 32 using Lanczos. That worked, but it required true 32 bit colour to be recognisable, and I wanted to preserve the 16 colour palette used by the original Chips Challenge.

So using the original image as a reference, I bit the bullet and drew my own in Acorn. You can see it here in this test level:

They're the elements that look like remote controls.

It turn out okay. At least it’s recognisable. Anyway, I coded it up and gave it a bit of a try:

Yeah, it works well. When the player has the appropriate colour remote, they can hit either Z or X to toggle the green walls or blue tanks respectively. I really should add some indicators in the status bar to show which button to press.

Not sure what I’ll do after this. The fun part was coming up with the element. But I guess I’ll have to come up with a few puzzles that use it.

Fri, 03 Nov 2023 21:00:50 +1000

Also got a bit of train spotting in as well. I parked at Kyneton station in the hope of seeing a train go by. Wish I could say my timing was strategic but in truth I was just lucky.

Sat, 21 Oct 2023 10:13:47 +1000

This conversation with @Gaby got my creative juices flowing so I though I’d put together a small video tutorial for using the GLightbox plugin by @jsonbecker. There have been a few updates with the plugin so how I use it might be slightly out of date. Either way, please enjoy.

Wed, 26 Jul 2023 22:43:28 +1000

Success! Managed to get a Go app built, signed, and notarised all from within a GitHub Action. It even cross-compiles to ARM, which is something considering that it’s using SDL. Here’s the test app being downloaded and launched in a VM (ignore the black window, the interesting part is the title).

Sat, 07 Jan 2023 17:02:00 +1000

I won’t lie to you. I got some pretty strong vibes of the Birds at this point in my walk.

Tue, 01 Nov 2022 08:55:34 +1000

🔗 github.com/charmbracelet/vhs

This little tool is awesome. It allows you to easily make GIFs of a command line session from a text-based DSL. I tried it on the full screen TUI app I’m working on and it worked flawlessly.

Now wondering if I could use it for automated testing. 🤔

Thu, 10 Mar 2022 07:45:00 +1000

Here’s another clip of the echidna, taken from the same 2 minute video I took yesterday. It’s also the third video of wildlife looking for food that I’ve posted on this blog. Is a trend forming I wonder? 🤔

Thu, 10 Mar 2022 07:00:00 +1000

Went for my afternoon walk yesterday, and saw an echidna looking for food. That doesn’t happen every day, so it seemed like a good subject for a video.

Mon, 13 Dec 2021 11:56:00 +1000

Saw this on my lunchtime walk today. I don’t often see cockatoos find food this way.

Fri, 25 Dec 2020 08:12:30 +1000

Follow on from the last post, I also had the opportunity to spot a few trains. Here’s one on it’s way to Bendigo, taken just outside Woodend.