A very chilly yet enjoyable bocce session at Calton Gardens today. Won one of the four games played, which is a good day for me.
Weekly Update - 15 Sept 2024
Two projects to discuss this week.
Cyber Burger
I’ve decided to ditch game mode A, where the player is given a series of stages they need to clear. Instead, I’m changing this to be closer to an old-school arcade experience. In this mode, you start the game with a 45 second timer, and you need get as high a score as you can before the timer runs out. Your score depends roughly on how large and “interesting” your burger is. Every burger you make also adds 10 seconds to the clock, so the ultimate aim is to balance making interesting burgers for a higher score, vs. trying to avoid letting the clock run down to zero. Or at least that’s the idea. I need to do some rebalancing, as I think the game is a little easy.
I am wondering whether to award points based on how fast you make the burger. It was originally my intention, but I’m now wondering if that would be considered unfair, as you don’t get to choose the items flying across the screen. I still do need to fix the random number generator too, so as to avoid keeping the player from waiting around too long for a bun base to start building their burger. Resolving these two things will be my goal for the next week.
This working version has been pushed to the web for anyone to try out. If you do, please let me know if you have any feedback.
Nano Journal
The next project I spent some time on was Nano Journal, the web-based
journalling app stolen from inspired by Kev Quirk’s
journalling app.
I wasn’t intending to work on it this week, but I did have a motive to do so as I was expecting to do something that I wanted to document (I ended up not doing that thing).
The biggest changes I made were adding paging and post titles, plus making some improvements on the backend on how posts are stored and retrieved.
Setting the title is done using a slash-commands:
/title This is my post title
This is my post body
I also added an /append slash-command to add to the latest post,
rather than create a new one. This also works for attachments too,
allowing a somewhat clunky way of adding multiple attachments to a
single post.
I am still considering this a prototype, but I have found myself writing here more often than Day One. I definitely need to start thinking about the long-term storage of posts if I want to “productionise” this. Ultimately I want to get them saved in a private Git repository. Each post is just a markdown file stored on the file-system, which will make this easy to do, but I’m somewhat procrastinating on relearning how to use the various Go Git clients that are available.
One other thing that I’d like to do is improve instances where a post couldn’t be saved due to network issues. The way I’m thinking of doing this is to store the current draft in browser local storage, at least until it’s saved on the server. I’m also wondering if it’s worth adding the concept of draft posts. Not sure at this stage whether that juice is worth the squeeze, at least not yet. This was meant to be a relatively simple side-track. But I guess that’s the danger (beauty?) of starting something and finding it useful. 🤷
Anyway, that’s all for this week.
One of my regular walking trails go by a creek that runs along a small cliff. One day, I saw a group of people by the path pointing at and taking photos of something on that cliff. This is what they were looking at:
Since then I’ve been trying spot them, usually quite successfully.
I want to reach out to someone. A blogger that’s reasonably well known. Nothing special, just to say hello and thank you for something I’ve read of theirs recently. I’ve been thinking about it for a week now, deciding whether or not to go through with it. And after seeing a private post today from someone that been on the receiving end of such an outreach, I decided to go ahead with sending that email.
It’s almost like the fates were sending me their own message. If so, then I’m not sure how I should interpret the errors I’m getting from their email spam deferences on their contact page. Nevertheless, I think I’ll keep trying.
Anyone who wants to start a barber or hair styling place, here’s a name for you: Hair Today, Gone Tomorrow.
Or, if you’re an Aussie: There Is Hair In There (And A Chair As Well)
Real opinions from real people about a project management system which unfortunately is also real.
Love the tag line of this site. Also, spoilers, but Confluence makes a warranted appearance here as well.
One day, Vivaldi’s going to release an upgrade that will fix whatever causes the browser to occasionally crash whenever I start to use the developer tools. Today is not that day.
Walking that fine line on my current work task between addressing the known flaws that may or may not crop up in production (they did crop up in testing) and spending an excessive amount of time gold-plating it unnecessarily. It’s hard sometimes to know when a task is truly finished.
Proposal for a new database maxim:
A query, originally written to find one row with a particular value, will eventually be rewritten to find multiple rows with a collection of values.
That is, if you had select * where id = ?, that query will eventually be rewritten to select * where id in (…).
👨💻 A collection of new posts over at TIL Computer:
Swoop-o-meter now at 3 noisy miners. We’ve got confirmed head contact (head strike?). Luckily it was just a tap, but I may avoid going that way for my walk for a while. 👷♂️
Select Fun From PostgreSQL
Using PostgreSQL these last few months reminds me of just how much fun it is to work with a relational database. DynamoDB is very capable, but I wouldn’t call it fun. It’s kinda boring, actually. Not that that’s a bad thing: one could argue that “boring” is what you want from a database.
Working with PostgreSQL, on the other hand, has been fun. There’s no better word to describe it. It’s been quite enjoyable designing new tables and writing SQL statements.
Not sure why this is, but I’m guessing it’s got something to do with working with a schema. It exercises the same sort of brain muscles1 as designing data structures or architecting an application. Much more interesting than dealing with a schemaless database, where someone could simply say “ah, just shove this object it a DynamoDB table.”
It’s either that, or just that PostgreSQL has a more powerful query language than what DynamoDB offers. I mean, DynamoDB’s query capabilities need to be pretty restricted, thanks to how it stores it’s data. That’s the price you pay for scale.
-
My brain muscles couldn’t come up with a better term here. 😄 ↩︎
Working from home today as there’s a protest at the convention centre, disrupting traffic. Got me thinking of the last time I was at that convention centre. It was 5 years ago, almost to the day, when I attended a small dev. conference. I left early on the last day as I had to join a protest.
Swoop-o-meter now sits at 2 noisy miners. Also, wearing or not wearing a blue beanie makes no difference. No magpies yet. 👷♂️
Wish I can use my new vacuum cleaner to suck up all the spam emails I’m getting about my new vacuum cleaner. 😕
This week’s earworm: The Wind Chimes by Mike Oldfield. 🎵
This one’s a bit surprising since it’s not a new addition to my collection. Maybe because I haven’t been listening to it all that often.
I didn’t record narration for the previous post. It featured a dialog and I needed a scene partner. So I tried recording one with AWS’s text-to-speech engine last night, and ah… yeah, it didn’t sound as good as I was hoping. I mean, the tech is getting better, but there’s still a way to go: that uncanny valley hasn’t been bridged yet.
This is probably the best version of what I was able to make. This was using AWS’s new-ish “Generative” voice model. There are only three voices available of this kind in AWS so far. I chose the US English male voice, since it spoke at a rate which, to my ears, is about as close to a speaking rate that I’d consider natural:
I also tried the same exchange out with the “Neural” engine, which has been around for several years:
The Generative voice model is decent. Still not good enough to fool anyone that I’m speaking with a real person, yet it’s a lot better than the Neural engine. There’s no mistake with that one that I’m speaking with a computer.
So, no recorded dialogue, but it was still an interesting exercise. And it’s always a little fun playing around with AWS’s text-to-speech engine.
Rubber-ducking: Of Config And Databases
It’s been a while since my last rubber-ducking session. Not that I’m in the habit of seeking them out: I mainly haven’t been in a situation when I needed to do one. Well that chance came by yesterday, when I was wondering whether to put queue configuration either in the database as data, or in the environment as configuration.
This one’s relatively short, as I was leaning towards one method of the other before I started. But doubts remained, so having the session was still useful.
So without further ado, let’s dive in. Begin scene.
L: Hello
🦆: Oh, you’re back. It’s been a while. How did that thing with the authorisation go?
L: Yeah, good. Turns out doing that was a good idea.
🦆: Ah, glad to hear it. Anyway, how can I help you today?
L: Ok, so I’m working on this queue system that works with a database. I’ve got a single queue working quite well, but I want to extend it to something that works across multiple queues.
🦆: Okay
L: So I’m wondering where I could store the configuration to these queues. I’m thinking either in the database as data, or in the configuration. I’m thinking the database as: A) a reference to the queue needs to be stored alongside each item anyway, and B) if we wanted to add more queues, we can almost do so by simply adding rows.
🦆: “almost do so?”
L: Yeah, so this is where I’m a little unsure. See, I don’t want to spend a lot of effort building out the logic to deal with relaunching the queue dispatcher when the rows change. I rather the dispatcher just read how the queues are configured during startup and stick with that until the application is restarted.
🦆: Okay
L: And such an approach is closer to configuration. In fact, it could be argued that having the queues defined as configuration would be better, as adding additional queues could be an activity that is considered “intentional”, with a proper deployment and release process.
I wonder if a good middle-ground might be to have the queues defined in the database as rows, yet managed via the migration script. That way, we can have the best of both worlds.
🦆: Why not just go with configuration?
L: The main reason is that I don’t want to add something like string representations of the queue to each queue item. I’m okay if it was just a UUID, since I’d imagine PostgreSQL could handle such fields relatively efficiently. But adding queue names like “default” or “test” as a string on each queue item seems like a bit of a waste.
🦆: Do they need to be strings? Could the be like an enum?
L: I rather they’re strings, as I want this arrangement to be relatively flexible. You know, “policy vs. mechanism” and all that.
🦆: So how would this look in the database?
L: Well, each row for a queue would have a string, say like a queue name. But each individual queue item would reference the queue via it’s ID.
🦆: Okay, so it sounds like adding it to the database yet managing it with the migration script is the way to go.
L: Yeah, that is probably the best approach.
🦆: Good. I’m glad you can come away with thinking this.
L: Yeah, honestly that was the way I was leaning anyway. But I’m glad that I can completely dismiss the configuration approach now.
🦆: Okay, good. So I’m guessing my job is done here.
L: Yeah, thanks again.
🦆: No worries.
If all I was taught came from old DOS games, I’d probably come away thinking that archeology is the coolest job in the world. 😀
Have to remind myself that it’s better to build for the state of the world now, rather than for some future state that may never happen. That probably means you’ll need to change it later, when the future inevitably reveals itself. Just be prepared to do so, and don’t be so hard on your past self when you do.