Meeting at deadline is best. Second best is blowing past the deadline by such a wide margin that is was clear it was never going to happen. The worst by far is being close to meeting the deadline, yet it remains out of reach. Expectations are never recalibrated in those scenarios.

If you’ve ever been asked to decide the session duration for a work-based application, choose a time based on how long your users will be at work. The AWS session token I have last 8 hours, but I’m at work for 9: 8 hours of work plus 1 hour lunch break. Come the end of the day, if I’m still doing things in AWS, I’m always prompted to log in again.

Even better would be a session duration of 10 hours, just in case work goes a little long that day.

Well, it took 2 years, but the final step of decommissioning a domain is over: the domain has now expired. I feel bad for all the links I now broke (it was a domain that receive a little bit of traffic). I just hope all the 301 Permanent Redirects I was sending for 2 years did something.

Must be Theme Changing day, as I’ve made one last change that’s been on my wish-list for a while: the ability to page within the post screen themselves. This allows one to page through the entries without having to go back to the Archive section.

Here’s the template to do that, which uses Tiny Theme’s micro-hooks:

<!-- layouts/partials/microhook-after-post.html -->

<nav class="paging">
  <ul>
  {{ if .PrevInSection }}
    {{ if eq .PrevInSection.Params.trip .Params.trip }}
      <li class="previous">
        <a href="{{.PrevInSection.Permalink}}">❮ Previous Post</a>
      </li>
    {{ end }}
  {{ end }}
  {{ if .NextInSection }}
    {{ if eq .NextInSection.Params.trip .Params.trip }}
    <li class="next">      
      <a href="{{.NextInSection.Permalink}}">Next Post ❯</a>
    </li>
    {{ end }}
  {{ end }}
  </ul>
</nav>

I also added a bit of CSS to space the links across the page:

nav.paging ul {
    display: flex;
    justify-content: space-between;
}

The only thing I’m unsure about is whether “Next Post” should appear on the right. It feels a little like it actually should be on the left, since the “Older Post” link in the entry list has an arrow pointing to the right, suggesting that time goes from right to left. Maybe if I removed the arrow from the “Older Post” link, the direction of time will become ambiguous and I can leave the post paging buttons where they are. Ah well, no time for that now. 😉

Dear Google,

If an address book has a contact with both a home and work phone number, please indicate which number is which in the Messages app. I just sent a birthday message to my sister’s work phone by mistake.

Something like this would be enough:

Regards,

lmika

“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.

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.

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