“Hark! Is that the sound of singing angles, I hear?”
“No, it’s just a Hyundai EV reversing.”
Hmm, not sure I’m ready for this reversing EV sound future we’re facing.
Oh, it turns out it’s an older style of referencing targets and is no longer supposed to be used. That’s a shame.
Huh, I was just adding a StimulusJS target attribute when Goland’s LLM suggested using a dot-based approach to reference the controller in the attribute value, instead of within the attribute name. I gave it a try and it worked.
Is referencing the target this way a new thing? I think I prefer it.
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.
We might be seeing the end of the tunnel with our performance woes at work. I did some profiling with pprof this morning, and saw that a large amount of time was spent in context.Value(). Which is strange, given that this is just a way of retreving values being carried alongside context instances.
My initial suspicion was that tracing may have been involved. The tracing library we’re using carries spans — like method calls — in the context. These spans eventually get offloaded to a a service like Jaeger for us to browse.
We never got tracing working for this service, so I suspect all these spans were building up somewhere. The service wasn’t memory starved, but maybe the library was adding more and more values to the context — which acts like a linked list — and the service was just spending time traversing the list, looking for a values.
This is just speculation, and warrents further investigation, maybe (might be easier just to spend that effort getting tracing). But after we turned off tracing, we no longer saw the CPU rise to 100%. When we applied load, the CPU remained pretty constant at around 7%.
So it’s a pretty large signal that tracing not being offloaded is somewhat involved.
Frustrating day today. The service I’m working on is just not performing. It starts off reasonably well, but then the CPU maxes out and performance degrades to 20%.
It may be the JWT generator, but why would performance degrade like that over time? It could be the garbage collector (this is a Go app). Maybe we’re allocating too many things on the heap? Or maybe we’re hitting some other throttled limit, making too many API requests. But I can’t see how that’ll max out the CPU. It’s not like it’s waiting on IO (or, at least, I can’t remember seeing it max out on IO).
Anyway, looks like another session with the profiler is in the cards.
So apparently the X’Trapolis trains have some form of battery. I saw one just drop its pantograph, yet the lights inside were kept on. I guess that makes sense, as there needs to be a way to raise its pantograph back up again.
I remember a time when I thought Gradle was the bee’s knees: “no XML, config written in Groovy, how awesome.” Now, it’s the most frustrating part of Android development.
Got it working in the end by upgrading Java and the Android SDK, but golly it sapped a lot from me. Although, to be fair, I’m not how standard the Gradle build is for a typical Android project. I guess it’s better than when they were using Ant.
Anyway, kids: just use Maven. Work through the XML. It’s just a better build system.
🧑💻 New post on TIL Computer: Link: Probably Avoid Relying On Error Codes To Optimistically Insert In Postgres
Slippery when wet.
Seriously, watch yourself when walking through that subway on a wet day. That tiled floor is treacherous.
I was reading through the feeds in my Feedbin account a couple of weeks ago, as one does, and a passing curiosity grabbed me: when did I actually sign up to Feedbin, and what were my first subscriptions? I’m not sure if it’s possible to get this information from the frontend, but it turns out you can get it from Feedbin’s API. So I plugged in my auth details and took a look.
My first two subscriptions were back on 24 May 2017, for Marco Arment and Daring Fireball, although I’m sure there were others that I’ve since removed. I’m taking that to be the date I actually signed up to Feedbin, and I suspect that these two were part of collection of feeds that I moved from older RSS reader I was using at the time1.
I won’t go through every subscription I have but I will point out a few interesting ones. For instance, I thought I subscribed to Manton Reece much earlier, but apparently it was only on the 6th March 2020. I subscribed to Seth Godin on the 8th December 2020. And the latest subscription was added only a few weeks ago, on the 10th of November of this year.
All up, I’m currently subscribed to 64 feeds. Now, if only I could remember how I discovered these feeds.
-
That was hand-built, and I should dig it out and see if I can get it working again, just to remind myself how it looked. I do know that it used Google’s Material design language. ↩︎
Delta of the Defaults 2024
It’s a little over a year since Dual of the Defaults, and I see that Robb and Maique are posting their updates for 2024, so I’d thought I do the same. There’ve only been a few changes since last year, so much like Robb, I’m only posting the delta:
- Notes: Obsidian for work. Notion for personal use if the note is long-lived. But I’ve started using Micro.blog notes and Strata for the more short-term notes I make from day to day.
- To-do: To-do’s are still going to where my notes go, which is now Strata. Although I’m still using Google Keep for shopping lists.
- Browser: Safari’s out from all machines. It’s Vivaldi everywhere now. Except iPad, where I don’t have a choice.
- Presentations: Believe it or not, I haven’t had to make a presentation since last year. I am still paying for iA Presenter, and despite some thoughts, I think I’ll continue to use it for future presentations. I should also add that I’m using iA Writer for prose writing, not that I do much of that either.
- Social Clients: Still Tusky for now, but I’m wondering how long it’ll be before I install a BlueSky client too.
- Journalling App: I didn’t include this in last year’s list, but it’s worth mentioning here as I’ve moved away from Day One to a home grown web-app, similar to the one built by Kev Quirk.
- POSSE: Micro.blog, EchoFeed. Also a new category, now I’m doing this a bit more nowadays.
Wish Go had Java’s :: operator, where you could convert a method into a function pointer with the receiver being passed in as the first argument. Would be super useful for mapping slices.
Upgraded my work laptop to Sequoia. “Love” the experience that this new version provides, especially the mouse-and-patience exercise I get in the morning. 👎
<img src=“https://cdn.uploads.micro.blog/25293/2024/cleanshot-2024-11-26-at-07.30.252x.png" width=“600” height=“541” alt=“Three permission requests stacked up, with the top one displayed asking if an app called “Obsidian” can find devices on local networks, with options to “Don’t Allow” or “Allow”.">
🧑💻 New post on TIL Computer: Don’t Use ‘T’ RDS Instance Types For Production
Looking for my next project to work on. I have a few ideas but my mind keeps wandering back to an RSS reader for Android. I read RSS feeds quite frequently on my phone and Feedbin’s web app is great, but I think I prefer a native app.
I just need to get over the hump of setting up my Android Studios. There’s something about starting a new project there that just sucks the life out of you.
I wonder if anyone can get anything out of Fandom these days. I went to it yesterday for something, and it was so full of ads that it was barely usable. Got out of there as soon as I could. Didn’t spend a second longer than I needed to. I certaintly wouldn’t choose to casually browse that site.
Playing around with some possible UI design choices for that Android RSS Feed Reader. I think I will go with Flutter for this, seeing that I generally like the framework and it has decent (although not perfect) support for native Material styling.
Started looking at the feed item view. This is what I have so far:
Note that this is little more than a static list view. The items comes from nowhere and tapping an item doesn’t actually do anything yet. I wanted to get the appearance right first, as how it feels is downstream from how it works.
The current plan is to show most of the body for items without titles, similar to what other social media apps would show. It occurred to me that in doing so, people wouldn’t see links or formatting in the original post, since they’ll be less likely to click through. So it might be necessary to bring this formatting to the front. Not all possible formatting, mind you: probably just strong, emphasis, and links. Everything else should result with an ellipsis, encouraging the user to open the actual item.
Anyway, still playing at the moment.
📺 House of the Dragon: Season 1 (2022)
Looking At Coolify
While reading Robb Knight’s post about setting up GoToSocial in Coolify, I got curious as to what this Coolify project actually is. I’m a happy user of Dokku, but being one with magpie tendencies, plus always on the lookout for ways to make the little apps I make for myself easier to deploy, I thought I’d check it out.
So I spun up a Coolify instance on a new Hetzner server this morning and tried deploying a simple Go app, complete with automatic deployments when I push changes to a Forgejo repository. And yeah, I must say it works pretty well. I haven’t done anything super sophisticated, such as setting up a database or anything. But it’s almost as easy as deploying something with Dokku, and I’m please that I was able get it working with my Forgejo setup1.
Anyway, this post is just a few things I want to make a note about for next time I want to setup a Coolify instance. It’s far from a comprehensive set-up guide: there’s plenty of documentation on the project website. But here are a few things I’d like to remember.
Changing the Proxy to Caddy: Soon after setting up your Coolify instance, you probably want to change the proxy to Caddy, just so that you can easily get Lets Encrypt certificates. Do this before you setup a domain as you’ll need direct access to Coolify via the port.
Go to “Servers → localhost” and in the “Proxy” tab, stop the current proxy. You then have the option of changing it to Caddy.
Setting Up a Domain For Coolify Itself: Once you’ve change the proxy, you’d probably want to setup a domain so as to avoid accessing it via IP address and port number. You can do so by going to “Settings,” and within “Instance Settings” changing “Domain”.
If you prepend your domain with https, a certificate will be setup for you. I’m guessing it’s using Lets Encrypt for this, which is fine. I’d probably do likewise if I had to set it up manually.
Deploying From a Private Forgejo Repository: To deploy from a private Forgejo repository, follow the Gitea integration instructions on setting up a private key. This is basically creating a new key in “Keys And Tokens”, and adding it as a key in Forgejo.
As far as I’m aware, it’s not possible to change an application source from a public Git repo to a private one. I tried that and I got a few deploy errors, most likely because I didn’t set the key. I had to delete it and start from scratch.
Setting a Domain For a Project: Setting up a domain is pretty simple: just add a new A record pointing to the IP address of the service the application is running on. Much like the Coolify domain, prefacing your domain with https will provision a TLS certificate for you (docs):
Unlike Dokku, your app doesn’t need to support the PORT environment variable. You should be able to start listening on a port and simply setup a mapping in the project page. The default seems to be port 3000, just in case you’re not interested in changing it:
Automatic Deployments From Forgejo: Coolio looks to have some nice integrations with Github, but that doesn’t help me and my use of Forgejo. So the setup is a little more manual: adding some web-hook to automatically deploy when pushing commits to Forgejo. In Coolify, you’d want to use the Gittea web-hook:
You’ll need to generate the web-hook secret yourself. Running head -c 64 /dev/urandom | base64 or similar should give you something somewhat secure.
Setting up the web-hook on Forgejo’s side was a little confusing. Clicking “Add Webhook” just brought up a list of integrations, which I’m guessing are geared towards particular form of web-hook payloads. You want to select the “Forgejo” one.
Use the URL that Coolify is showing for the Gittea web-hook, leave the method as “POST” and set the secret you generated. The rest you can configure based on your preferences.
So that it. So far I’m liking it quite a bit, and I look forward to going a bit further than simple Go apps that serve a static message (some of the pre-canned applications look interesting). I’d like to try it for a bit longer before I consider it as a replacement for Dokku, but I suspect that may eventually happen.
-
I say “it’s almost as easy” as Dokku, but one thing going for Coolify is that I don’t need to SSH into a Linux box to do things. When it comes to creating and operating these apps, doing it from a dashboard is a nicer experience. ↩︎