Oof, spent all morning updating and rebasing out-of-date pull requests. Only got through half of them so far. This project is pretty fast pace at the moment, so conflicts are expected. But many of these are PRs I been neglecting until now, so it’s still mostly my own doing. 😮💨
Here’s today’s instalment of Why Didn’t I Think of This Sooner™.
I’ve got into the habit of squashing commits before I push them as part of a pull request. In order to run the command I use to do this — git rebase -i HEAD~n — I need to know the number of commits I want to squash (this will be the value of n).
Fortunately, I’ve got into the habit of prefixing each commit message with the Jira task number. For example, I may write a commit message with the first line being ABC-123: fixed a bug in the thing, followed by a more detailed list of changes. I do for every commit, even for those “checkpoint commits” I make before changing branches.
So all I need to do to get the number of commits I need to squash is to simply count up all the commits that start with the Jira task number. For all this time, the way I do this is to run git log to open up the history in Vim, and manually count the number of commit messages that began with the particular Jira task number.
Today, I remembered that I could use a shell pipeline to do the same thing:
git log | grep ABC-123 | wc -l
which would save me stack-loads of time and potential mistakes.
Wish I thought of this sooner. 🤦
I’m moving the posts I had on my wiki to this blog and I’m shutting the wiki down.
I never really used the wiki a lot — in fact, the last two posts were the only pages that were on there (the rest were all links). This was partly because I never got around to setting up backups (this was a pretty big reason why I didn’t put anything I wanted to keep there), but also because I found other places to document things. Anything related to software development I found myself just posting it here. Things that related to projects that I wanted to keep private, I wrote in Day One. So nothing really went into the wiki at all.
I did use the wiki a lot to keep bookmarks to guides and resources I occasionally need to lookup. I think, going forward, I’ll just keep these links as a page on this site. I’m in Micro.blog almost every day so I imagine the amount of extra effort needed to keep this page up-to-date will be low. One less site to visit and maintain. 🙂
🔗 A delightful reference for HTML Symbols, Entities and ASCII Character Codes
A great reference site I stumbled along when I was trying to find the perfect arrow to include in a webpage. Nice, clean, and quite comprehensive. No awful ads either, which is a breath of fresh air.
Dynamo-Browse: Using The Back-Stack To Go Forward
More work on Audax toolset. Reengineered the entire back-stack in dynamo-browse to support going forward as well as backwards, much like going forward in a web-browser. Previously, when going back, the current “view snapshot” was being popped off the stack and lost forever (a “view snapshot” is information about the currently viewed table, including the current query and filter if any are set). But I’d need to maintain these view snapshot if I wanted to add going forward as well.
So this evening, I changed it this such that view snapshots were no longer being deleted. Instead, there is now a pointer to the current view snapshot that will go up or down the stack when the user wants to go backwards or forwards. This involved changing the back-stack from a single-linked list to a doubly-linked list, but that was pretty straightforward. The logic to pop snapshots from the stack hasn’t been removed: in fact, it has been augmented so that it can now remove the entire head up to the current view snapshot. This happens when the user goes backwards a few times, then runs a new query or sets a new filter, again much like a web-browser where going backwards a few times, then clicking a link, will remove any chance of going forward from that point.
Last thing I changed this evening was to restore the last viewed table, query or filter when relaunching dyanmo-browse using an existing workspace. This works quite nicely with the back-stack as it works now: it just needs to read the view snapshot at the head.
Second breakfast time.
Breakfast time.
One thing I miss about working in Java is that the JVM comes out of the box with an interactive debugger. With just a few switches, you can enable a remote debugging session without having to do anything special with your build.
As far as I can tell, such a thing is not possible in Go, at least by default. This means that if you need to debug something running in something like Kubernetes, you either need to bundle something like delve in your container — which might not be possible if you don’t control the entire build pipeline — or you’re out of luck and need to resort to print-level debugging.
I wonder if people who say they hate bagpipes are actually saying they don’t like the music traditionally played with bagpipes. I’m not one that likes that sort of music either. But Mike Oldfield is a favourite artist of mine, and he’s not afraid of using a fair bit of bagpipe.
Went to the Union Club Hotel, in Collingwood, with a few friends for dinner tonight. Apparently quite popular with footy fans, which I did not know: there was a group that was quite roudy when I arrived. Fortunately things settled down when we ate dinner, which was pretty good.
Off to breakfast this morning.
Met some locals on the way.
Day One needs a “this time one day ago” section, where you look at the entries from yesterday, realised you’ve made all these spelling and grammatical errors, and you go ahead and fix them. I sure know I can make use of such a feature.
Adding Copy-To-Clipboard And Layout Changes In Dynamo-Browse
Spent some more time on dynamo-browse this morning, just a little bit.
Got one new feature built and merged to main, which is the ability to copy the displayed item to the pasteboard by pressing c. This is directly inspired by a feature in K9S, which allows you to copy the logs of a running pod to the pasteboard (I use this feature all the time). The package I’m using to access the pasteboard is github.com/golang-design/clipboard, which seems to offer a nice cross-platform approach to doing this.
The copied item is not meant for machine use. It’s exactly what’s displayed in the item viewport and is intended for tracking items that change over time. What I’ve found myself doing, when I need to track such an item, is to manually select it with Terminal and pasting it to an untitled textedit window. I do this again when the item changes until I’m ready to eye the changes manually. It’s not sophisticated, but it tends to work. And although this feature is not a full-blown item comparer, it will make this use case a little easier. Plus, it will copy the entire image, not just the lines displayed when a viewed item is too large for the viewport.
Speaking of which, the other thing I started working on today was on allowing the user to resize the item viewport to take up more of the screen. At the moment, the displayed item viewport takes up the bottom 14 lines of the screen, and is not resizable. Naturally, for large items, this is not large enough, and having the ability to resize this viewport would be a good thing to have.
I’ve been thinking about the best way to handle this, and I’ve decided that an approach similar to how Vim does this — where you need to press a key-chord followed by a number to move the vertical split between two views — would be a little to annoying here. Too much fine grain control for when you just need the viewport bigger. So, I’m opting for a more course-grain approach, where you simply press w and the viewport size will cycle amongst 5 different sizes:
- 14 rows at the bottom of the screen (the default)
- Half the screen
- All but the top 6 rows of the screen, so you can still see a bit of the table view
- The entire screen (i.e. hiding the table view)
- Completely hidden (i.e. the table view takes up the entire screen).
Doing this will not necessarily steal focus from the table view: even if shown the entire screen, you can still go through each item by pressing Up or Down. But you’ll be able to see more of the selected item.
Anyway, that’s the theory. We’ll see how well this works in practice.
Turning Off Shared Command History in Oh My Zsh
TL,DR: add “unsetopt share_history” to your .zshrc file
I’ve been using Oh My Zsh at work for a few months. As far as terminal config managers go, this one works pretty well. But the default configuration does include something which I found quite annoying.
First, a few words on how I use the terminal. I’m in the terminal constantly in my day to day. At the start of the day, I’m creating terminal tabs and running commands to do things like build the project I’m working on, start a testing session, etc. This all starts very ad-hoc, but over time these tabs take on a particular role. I may run make and git in the left-most tab, run tests in the tab next to that, have logs tailing in the one after that, etc. As I start and stop commands in each tab, they all build up a different history, which is usually visible in the terminal output itself. Eventually it comes to the point where in order to run a particular tool, I simply need to switch to the particular tab and press ↑ one or two times to get to it.
Installing Oh My Zsh broke this workflow. Out of the box Oh My Zsh enables shared command history across each session, meaning that the commands recalled when pressing ↑ are the last commands executed in any tab. This meant that when going through the history, the recalled command would be different from the ones that I’ve entered in the tab I’m in. In addition to this resulting in pressing ↑ way more times than I used to — sometimes to the point where I gave up and simply typed the command out again — it also meant that the recalled commands differ from the ones I saw in the tab output itself. This was very jarring.
Fortunately, this feature can be turned off simply by adding the following to your .zshrc file.
unsetopt share_history
I did just this and my old workflow was restored.
I don’t know why shared command history was chosen as the default. Am I in the minority using the terminal this way? Maybe. But I know for certain that this group is larger than a single person. In either case, I’m glad that I was able to disable this “feature”.
The last hold-out.
Discovered something cool on the ATP website. If you play old shows while logged in as a member, you actually get those from the members feed instead of the public one. Not sure if I’m the last person to find this out, but chalk me up as someone delighted by this little feature.
I started seeing job ads for “Blockchain Engineer” on LinkedIn recently. I have no interest in such roles. But I was curious, so I clicked into one to see what it actually entails. Now, LinkedIn is emailing me similar web3 roles, thinking that I’m interested.
Serves me right. 🤦
Dad and I have been watching YouTube cab-rides of the NYC subway system recently. Part of the fun is trying to understand the various track configurations and how the system operates. The size of the network never ceases to amaze.
I had the opportunity to meet up with someone I use to work with at the Bureau of Meterology this morning.
I left the Bureau about five years ago, and although I didn’t work with this person on a daily basis, our two teams were reasonably close. One advantage of working in the team that manages the message switching service (MSS) is that you tend to have dealings with many other teams that need to shuffle data around. This person belong to one such team. He dealt with with software related to severe weather, and the alerts produced by them had to be ferried around by out team.
We talked a little about the Bureau. There have been people that have retired or moved on but the team I use to work with is still largely intact. We talked a little about the project that was meant to have replaced the home grown MSS that our team was responsible for. The goal was to replace it with a commercial, off the shelf package sold by a firm that specialises in software for met services. This was meant to have happened roughly a year or two after I left, way back in 2017. But it turns out that this MSS system will not go quietly. Given how tailored it is to the general operations of the Bureau, replacing it proved way too difficult, and it seemed like those that were trying to do so have given up in defeat, at least for the moment. And I get it, nothing lasts for ever, and eventually this MSS system will have to be replaced by something. But even so, it’s good to hear that it’s still around.
And yes, I asked about the admin tool I built. It’s still being used, and indications seem to be that people still like using it.
I was pleased to hear that. Talking about it this morning bought me back to that particular project. I had fond memories working on it. It was fun, and I was proud of what I was able to build. And yet, despite how difficult it was to step away from it, I can’t help think that doing so was the right decision. Staying on that project would not have help me grow professionally. I’ve learnt so much since then, and feel like a much better developer, thanks to moving on and trying different things. Well, it’s good to have the memories.
Adding A Back-Stack To Dynamo-Browse
Spent some more time working on dynamo-browse, this time adding a back-stack. This can be used to go back to the previously viewed table, query or filter by pressing the Backspace key, kind of like how a browser back button works.
This is the first feature that makes use of a workspace, which is a concept that I’ve been thinking about since the start of the project. A workspace is basically a file storing various bits of state that could be recalled in future launches of the tool. A workspace is always created, even if one is not explicitly specified by the user. The workspace filename be set by using the -w switch on launch, or if one is not specified, then a new workspace filename within the temp directory is generated. The workspace file itself is a Bolt database, which is a very simple, embeddable key/value store that uses B-Trees and memory-mapped data access. I’m actually using StormDB to access this file, since it provides a nice interface for storing and querying Go structs without having to worry about marshalling or unmarshalling.
The back-stack consist of view-snapshots, which are essentially records of the currently view table, filter, and query. The view-snapshots are stored as a linked list, and the back-stack simply pushes new snapshots as the view changes (because this is stored on file, the backlinks are actually ID references and not physical pointers). I had a bit of trouble getting this right at first. The initial version actually pushed a snapshot of the previous view before it changed (i.e. a new table was selected or the filter was changed). But this resulted in a bit of messy implementation, with push calls copied and pasted across the various controllers with various special cases, etc.
So I went back and reimplemented it so that the top of the back-stack is actually a snapshot of the current view. Pressing the Backspace key will actually pop the current snapshot, then read the head of the stack and use that to update the view. This means that there will always be one item in the stack, which bothered me a little at first, but that did make the code easier to implement.
There is another benefit to this arrangement which just came to me while I was writing this. Since the current state of the view is always at the top of the stack, I could add the ability to restore the last view when launching dynamo-browse with an existing workspace, saving the user from selecting a table and running their last query. This will come a bit later. For the meantime, I need to get this back-stack working with user scripts, so that when a script changes the view, the user can still go back.
Finally, a shoutout to boltcli which is a useful CLI tool for browsing a Bolt database. This tool has come in handy for debugging this feature.