🔗 Using Web Components on My Icon Galleries Websites
Lot of neat stuff referenced in this post, like htmx and web components. I’d like to try them in some capacity, like some small web project. Unfortunately, the only things I can think of building right now are things for my job.
I use to write up design documents directly in Confluence, as we use that as our knowledge base, but recently I’ve started drafting them in Obsidian. And it’s wonderful. So little friction with getting my thoughts down, especially when it comes to diagrams. Builtin support for Mermaid.js is great.
Launched Logic Pro and did some MIDI recording this evening. Here’s an except from “Top of the Morning” from Tubular Bells 3.
Yes, PA equipment organised: two speakers, a mixer, and cables. I’ll have to drive to Windsor to pick it up, which is a bit of a hike for me, but I’m glad that’s sorted now.
Goland updated to the latest, and the issue I was having with the debugger last week has been resolved. Curious how upgrading to Go 1.21 seems to freak an old version of Goland out when you hit a breakpoint. Would’ve have though that would be fine. But no matter, it’s all working again.
All aboard the Goland upgrade train. Calling at 2022.1.4, 2022.2.28, 2023.1.45…
If I can recommend one thing anyone with a PA hire service should do, it’s to have specifics of the equipment you offer for hire up on your website. Photos (front and back), size, whether it’s suitable for outdoors, etc. All this would be super useful for someone working out what they’ll need.
Been out all morning trying to find someone that does PA hire. Drove to three different locations I found on Google Maps. Two of them are no longer there, and one is only selling consumer audio instead. Now trying someone that does PA hire from their home. Good thing is that they’re close.
Looks like the Go debugger has already checked out for the week. I’m trying to debug this unit test and it’s refusing to start the app. It’s just showing me an eternal spinner.
Pixel Phones Are Not Dog-food, and That's a Problem
John Gruber on the Pixel 8 launch event:
It’s also impossible not to comment on just how much less interest there is in Google’s Pixel ecosystem. […] On the one hand I’m tempted to say the difference is just commensurate with how much better at hardware Apple is than Google. But I think there’s more to it than that. There’s something ineffable about it. There are aspects of marketshare traction — in any market — that can’t be explained by side-by-side product comparisons alone.
Can’t speak for the market but as a Pixel 6 Pro owner I can give you my opinion. You don’t need to watch the keynote to get that sense of disinterest. You can get it just by using the phone.
For the last few months1 I’ve been experiencing a bug with the calendar widget. If you have nothing on your calendar for the next two weeks, it completely blanks out:
I doubt that this is intentional as the plus button doesn’t work either. Tapping it does nothing at all.
For comparison, here’s how it’s meant to look:
Now, bugs in software happen — they certainly happen in mine — and there’s no reason why Google would be immune to this, so I can forgive them for this bug showing up in a shipped version of Android. My problem is that it’s been like this for months now. This is a widget built by Google, included in Google’s Calendar app running on Google’s OS and Google’s hardware, and it’s been broken for this long. I would’ve expected this to be fixed in a few weeks, but for it to take this long?
I can’t see how anyone with an Android phone using this widget would not notice this. And the only reason I can come up with is that no-one in Google has noticed this. They simply don’t use Android, the OS that they build, in their day-to-day. Maybe some of them do, but obviously not enough of them to drive change. If there was, they would’ve found this problem and fix it by now. To quote Linus, “given enough eyeballs, all bugs are shallow,” and those eyeballs are obviously looking elsewhere.
Now this theory may be far fetched, but after reading Gruber’s piece, it seems like I’m not alone in thinking this. As he says later in the same article:
I’d wager that more Google employees carry an iPhone than carry a Pixel.
It shows.
-
I can’t remember when I first saw this, but I think it was in July. ↩︎
I’m shutting down Untraveller. I can’t resolve the tension of wanting a comprehensive, but really dry, account of a trip, vs. making it interesting for others to read. I think a Day One journal is more suitable for this.
May keep the domain though. One of the rare ones that worked off the bat.
Vivaldi occasionally lockups when I bring up the context menu. I think it happens when it tries to makes a network request for the search icon.
I can remove the menu item if I wanted to, but I’d like to keep it around as I do find it useful. It would be nice to turn the icon off though.
Had to go to the new office today so I tried out the commute. The walk from Southern Cross to the office is exactly 20 minutes.
Organising travel documents for an upcoming work trip. I used to rely on Google Inbox for this. The way it ingested your itinerary and hotel booking was useful, but the thing I miss the most were the high quality banner images of your destination. Really nice touch.
Your Dev Environment is Not Your Production Environment
There will be certain things you’re going to need to do in your development environments that you should never do in production. That’s pretty much a given: playing around with user’s data or potentially doing something that will cause an incident is generally not a good idea.
But there are things you shouldn’t do in prod that you may need to do in dev. And make no mistake, there may be a legitimate need to do these things. Using Auth0 and only have a limited number of emails available for your test environment? You may need a way to quickly reset a user. Support billing in multiple countries and need to do a test in one of them? You’ll need a way to change the user’s countries.
And I think that’s fine. Not every environment needs to be a reflection of production. As long you’ve got a staging or pre-prod environment where you can do things like rehearse deployments. But everything else should be skewed towards ease of development, which will mean making these drastic options available and easy to use.
It’s so much easier to post about how something others have worked on could be made better than it is to write about what I’ve been working on. I think there’s room for both on this blog, but I feel the balance is too many posts on the former and not enough on the latter. I’ll try to do better here.
Don’t want to turn this into the “look at what’s wrong with Atlassian’s software” blog, but I found another thing that annoys me about Confluence:
Clicking on a status label brings up a picker, giving you options to change the colour, etc. The picker appears below the label, which usually means it blocks the next thing I want to modify, like the status label in the row below. I need to dismiss the picker first before I can select the label I want to change next.
It’d probably be better if the picker appeared above the label instead.
This is also an issue with dates and links to Jira tickets as well, although with Jira tickets you’re required to make edits within a modal.
Given the number of times I make wiki pages that are little more than pseudo-databases-as-a-table, it would be nice if Confluence had a way to make this better. Maybe something like Notion databases, just to organise information a little neater than the free-for-all you get from tables.
Day 30: treasure
This one’s inside a box without hinges, key, or lid. #mbsept
Day 29: contrast #mbsept
