-
🔗 Not an April Fool: Dyson announces apocalyptic filter-headphone combo
Yes, the product is weird, but what prompted this link-post is the remark about this being a “perfect addition to your Mega Man cosplay project.” I believe in the games, you could always see Mega Man’s mouth.
-
Even after 18 years of use, I still get blown away at how amazingly useful the command line can be for doing anything slightly non-trivial with text and files. Maybe that’s why it’s still going strong for 50 years and counting.
-
An amusing thought came to me after reading Gruber’s post on Facebook and TikTok. Here’s Facebook hiring a strategy firm that is considering mediums other than Facebook to try and sway people’s opinions of TikTok. Maybe they should try getting their message on to TikTok. 😄
-
Scene: work.
Team: here’s the tasks we need to do, here’s how long they will take, and we’ll probably get it done on 24 April.
Managers: OK, I’ve taken that list, pulled out half the tasks and cut the estimates by 50%. Can you get it done in two weeks?
😠
-
I’ve been racking my brain trying to best work out how to organise the code for awstools. My goals are to make it possible to have view models composable, have state centralised but also localised, and keep controllers from having too much responsibility. I started another tool, which browses SSM parameters, to try and work this all out.
I think I’ve settled on the following architecture:
- Providers and Services will remain stateless
- State will be managed by controllers
- Operations in controllers are only available through tea.Cmd implementations.
- Updates from controllers will only be available through tea.Msg implementations.
- View models (i.e.
tea.Model) will only know enough state to be able to render themselves. - There will be one master model which will coordinate the communication between controllers and view models. This model will react to messages from the controllers and update the views. It will also react to messages from the views and launch operations on the controllers.
We’ll see how this goes and whether it will scale as additional features are added.
-
Credit to Apple for the work they did to get x86 working seamlessly on the M1. It’s only just now, after 6 hours of use, that I realised I downloaded the x86 version of Go when I should have downloaded the ARM version. I finally cottoned on when I tried to spin up the debugger.
-
My theorem regarding email: the chance of me reading an email from a sender is inversely proportional to the number of messages received from that sender per day.
Supporting evidence: seeing 300 unread messages for GitLab that will be immediately marked as read. 🗑
-
The subject here is photography but I think it can be applied to any other creative endeavour out there. Resonated for me as well.
-
Meetings really take it out of me. I had 4 hours worth of meetings today and now I’m really drained. And it’s not just because they were virtual. I would have been drained if I had them in person as well.
-
More work on the AWS tools, mainly rebuilding the UI framework. Need to rip out all the Operation type stuff, as BubbleTea already does this using messages and commands (see tutorial 2). Also taking some time building some UI models that I can reuse across the various commands, including a few that deal with layout changes.
Also tracked down what was causing that delay when trying to create a new list. It turns out during the call to
list.New(), a bunch of adaptive styles are created, which includes a test to see if the terminal is in light or dark mode. This calls some terminal IO methods which were blocking for a significant amount of time, we’re talking in the order of 10’s of seconds.The good thing is that this check is only made once, so what I did was move the check into the main function. Some preliminary tests indicating that this may work: the lists are consistently being created very quickly again. We’ll see if this lasts.
-
Doing a lot of terminal UI app development recently. It’s not easy but I’ve forgotten how much fun it is. Requires a fair bit of thought, not only to make usable UIs using only characters and colour, but also to keep the code from descending into a giant ball of mud.
-
More work on Broadtail this morning. Managed to get the new favourite stuff finished. Favourites are now a dedicated entity, instead of being tied to a feed item. This means that any video can now be favourited, including ones not from a feed. The favourite list is now a top-level menu item as well.
Also found a useful CLI tool for browsing BoltDB files.
-
An idea for that micro-bulk-image tool: instead of prioritising uploads, maybe prioritise processing of already uploaded images. Things like cropping, optimising, etc. after the upload, and then re-uploading it.
-
New AWS Tools Commands
For a while now, I’ve been wanting some tools which would help manage AWS resources that would also run in the terminal. I know in most circumstances the AWS console would work, but I know for myself, there’s a lot of benefit from doing this sort of administration from the command line. I use the terminal a lot when I’m developing or investigating something. Much of the time while I’m in the weeds I’ve got a bunch of tabs with tools running and producing output, and I’m switching between them as I try to get something working across a bunch of systems. Continue reading →
-
Woke up expecting today to be long and annoying, but it turned out not to be as annoying as I anticipated (or as long). I guess the lesson here is not to presume how good or bad a day will be until you’ve lived through it first.
-
Got my copy of Bloch’s Effective Java out today for the first time in years, in order to prepare for an interview. As far as books about programming languages go, this is probably my favourite. Very informative and easy to read.
-
No day trip to Warburton this year: too much to do at work unfortunately. I’ve got a day in leau owed to me so we’ll see if I could make it in April.
-
Wondering if there’s a way where I could quit my job and spend my waking hours building text-based UI applications. Not sure there’s a lot of money in such things unfortunately.
-
Doing some tool smithing at work to make my current task a little easier. Using Bubble Tea to build a TUI-based SQS message browser. Early days so far but already showing promise. Anything which will save me clicks around the AWS console is always a plus.
-
Even more work on Feed Journaler. Still trying to tune the title removal logic. Will probably require a lot of testing.
-
The “Explore Repositories” sidebar on GitHub’s home page (if you’re logged in) is a bit strange. Why am I getting recommendations for projects that I either don’t need, or haven’t sought out? Am I expected to just pull in any bit of code people are publishing? Really weird.
-
Hmm, I’m wondering if Broadtail needs a mode for downloading the audio of a video only, and uploading it to a podcasting service like Pocketcasts. I did this twice before, and now wish I can do it again. Third time is when a pattern is emerging.
Also, a bit of a deviation to finish the current work outstanding for Feed Journaler. Much of it is trying to get the Markdown translator working with Write.as post, mainly to deal with posts without titles, and to strip any hashtags that appear in the first and last paragraph. The code is a real mess. I should probably spend some time cleaning it all up.
-
Showing Only Changed Files in Git Log
This technique shows only the changed files in a git log call without having to show the entire patch: git log --name-only ... Continue reading →
-
If there’s anyone else out there using Buffalo to build web-apps, I just discovered that it doesn’t clean up old versions of bundled JavaScript files. This means that the
public/assetdirectory can grow to gigabytes in size, eventually reaching the point where Go will simply refuse to embed that much data.The tell-tail sign is this error message when you try to run the application:
too much data in section SDWARFSECT (over 2e+09 bytes)If you see that, deleting
public/assetsshould solve your problem. -
Showing A File At a Specific Git Revision
To display the contents of a file at a given revision in Git, run the following command: $ git show <revision>:<filename> For example, to view the version of “README.md” on the dev branch: $ git show dev:README.md There is an alternative form of this command that will show the changes applied to that file as part of the commit: $ git show <revision> -- <filename> This can be used alongside the log command to work out what happened to a file that was deleted. Continue reading →