Ndymium

If my user does jog at 2 AM, then it's better to show 2 AM than 7 PM or 10 AM even if there is a slight chance that on one singular day 2 AM might repeat itself. The user who is aware of how daylight savings works will surely be able to figure that out.

Technically you might argue that I should show 1 AM if the user did run at 2 AM in summer time, but everyone I personally know keeps their schedule over DST transitions. That is, if they did something at X o'clock before the transition, they'll keep doing it at X o'clock after it (sleep be damned). So generally showing 2 AM would be the most correct solution.

You cannot get that information from just UTC if you don't know where the user was when they made those historical events. Thus you either have to keep a history of their location (complicated) or just store the local timestamps (or at least the offsets) at the time of event. Always being able to convert from UTC with no extra data assumes that the user will never move, which might be fine if your application is limited to users in a single country.

Copying what I posted under the original[0] that no one noticed because it's quite relevant to your mention of UTC for past events:

The naming of "timestamp with time zone" is one of my favorite pet peeves. It's one of those things that you can say "well technically it's true" about.

The article suggests that for past events, UTC and this timestamptz would be acceptable as a general rule, but even there it depends on what you will be doing with the data. If you intend to interpret it as a series of local occurrences and try to visualize/summarize that data later, you may be in for a surprise as your user has moved to another timezone and now all the past events are translated to the wrong local hours [1]. For example, your system might end up showing that the user's best time for jogging based on historical data is at 2 in the night.

[0] https://news.ycombinator.com/item?id=48558005

[1] https://blog.nytsoi.net/2022/03/13/utc/

The naming of "timestamp with time zone" is one of my favorite pet peeves. It's one of those things that you can say "well technically it's true" about.

The article suggests that for past events, UTC and this timestamptz would be acceptable as a general rule, but even there it depends on what you will be doing with the data. If you intend to interpret it as a series of local occurrences and try to visualize/summarize that data later, you may be in for a surprise as your user has moved to another timezone and now all the past events are translated to the wrong local hours [0]. For example, your system might end up showing that the user's best time for jogging based on historical data is at 2 in the night.

[0] https://blog.nytsoi.net/2022/03/13/utc/

This is what it looks like right now. Unless there's some huge economic boom coming, which I doubt.

As a Finnish dev with 12 years of experience, I can only aspire for such salary.

It's a game. You're supposed to click on the different route options that are presented to you on the bottom of the screen. That's why it goes slower the more options there are.

But I also just followed it for the first time from beginning to end, not doing anything. Because I assumed someone had already done the math.

While 7700 per hour sounds big, pretty much any dinky server can handle it. So I don't think it's a matter of DDoS. At this point it's just... odd behaviour.

Forgejo does set "cache-control: private, max-age=21600", which is considerably more than one second, but I grant it uses the "private" keyword for no reason here.

For some reason, Facebook has been requesting my Forgejo instance's robots.txt in a loop for the past few days, currently at a speed of 7700 requests per hour. The resource usage is negligible, but I'm wondering why it's happening in the first place and how many other robot files they're also requesting repeatedly. Perhaps someone at Meta broke a loop condition.

Note that the API is split into XSS-safe and XSS-unsafe calls. The XSS-safe calls [0] have this noted for each of them (emphasis mine):

Then drop any elements and attributes that are not allowed by the sanitizer configuration, and any that are considered XSS-unsafe (even if allowed by the configuration)

The XSS-unsafe functions are all named "unsafe". Although considering web programmers, maybe they should have been named "UnsafeDoNotUseOrYouWillBeFired".

[0] https://developer.mozilla.org/en-US/docs/Web/API/HTML_Saniti...

That's the old sanitizer API. That was already removed and what you linked earlier is the new sanitizer API.

Gleam is technically as suitable for distributed computing as Erlang: since it compiles to Erlang, it can do anything that Erlang can. You can use Erlang and Elixir libraries and write FFI code to do things that would be unergonomic to do in Gleam. Sure the experience is different and if you want to embrace the guarantees of static typing, then the APIs will look different, like gleam_otp.

If you compile it to JS, then the guarantees change to JS's guarantees.

Personally I've felt that the JS target is a big plus and hasn't detracted from Gleam. Writing a full stack app with both sides being in Gleam and sharing common code is something I've enjoyed a lot. The most visible impact is that there's no target specific functions in the stdlib or the language itself, so Erlang related things are in gleam_erlang and gleam_otp, and e.g. filesystem access is a package instead of being in the stdlib. If you're just into Erlang, you don't need to interact with the JS target at all.

og:description is exactly the meta tag to use for link descriptions in embeds. Not all meta tags are only for search engines. The app acted correctly here.

It's basically what Phoenix LiveView specifically is. That's only one way to do it, and Phoenix is completely capable of traditional server rendering and SPA style development as well.

LiveView does provide the tools to simulate latency and move some interactions to be purely client side, but it's the developers' responsibility to take advantage of those and we know how that usually goes...

This is essentially what a ground source heat pump system is. Except instead of a sealed water tank you just make a tall hole that fills with water and the sun will warm it for you during the summer automatically.

1800 kWh is very little. We use around 12000 kWh and our neighbours' new house uses around 8000 kWh annually and most of that is heating. I'm not sure how many houses can hit 1800.

Made me laugh though, when in the first level that it completely blocks, the director tells you to get close to a pickup, but the car you're chasing smashes the pickup to the sky like Team Rocket.

Last I heard there was a feature branch for testing a software implementation of floating point that would fix these issues, but naturally it would be a lot slower. I haven't tried it myself.

I admit that latter part is just for whimsy, because I think it looks fun. The dashes I like for their aesthetics and if that makes me eccentric then so be it. They shouldn't distract anyone's reading, or at least they didn't use to before LLMs.

En and em dashes are easily accessible on both my laptop's and phone's keyboard layouts and I like using them, just like putting the ö in coöperate. It's sad if this now makes me look like a robot and I have to use the wrong dashes to be more "human".

Note that you linked to the 0.1.1 version of the gleam_otp documentation. The latest version resides at https://hexdocs.pm/gleam_otp/index.html and both gleam_erlang and gleam_otp have hit 1.0.0 already. It doesn't contain every feature yet (like dynamic supervisors) but it's usable (and I've rolled my own dynamic supervisor in the meantime).

Here's a modern take I like with banjo and accordion by Slack Bird: https://www.youtube.com/watch?v=WMvpeYBnwTg

Turns out you can play it with an angry face.

*Ei saa peittää. :)

I'm not, the author was my colleague at the time. I can only hope to be half as brilliant as him.

It was quite likely this one: https://www.vincit.com/blog/software-development-450-words-p...

Sadly the audio samples are gone. I'll need to pester someone to fix that.

Thanks to your article I just realised my HTML entity codec library doesn't support decoding those named entities that can omit the semicolon at the end. More work for me, good thing my summer vacation just started! :)

There's no zoom feature in the OS.

macOS absolutely has a zoom feature. I use it regularly, it's bound to ctrl + mouse scroll for me.

More: https://support.apple.com/en-il/guide/mac-help/mchl779716b8/...

Personally I'm specifically talking about Forgejo which is Go, but calls git for some operations. And the effect that was worse than pegging all the CPUs to 100% was filling of the disk with generated zip archives of all of the commits of all public repositories.

Sure, we can say that Forgejo should have had better defaults for this (the default was to clear archives after 24 hours). And that your site should be fast, run on an efficient server, and not have any even slightly expensive public endpoints. But in the end that is all victim blaming.

One of the nice parts of the web for me is that as long as I have a public IP address, I can use any dinky cheapo server I have and run my own infra on it. I don't need to rely on big players to do this for me. Sure, sometimes there's griefers/trolls out there, but generally they don't bother you. No one was ever interested in my little server, and search engines played fair (and to my knowledge still do) while still allowing my site to be discoverable.

Dealing with these bots is the first time my server has been consistently attacked. I can deal with them for now, but it is an additional thing to deal with and suddenly this idea of easy self hosting on low powered hardware is no longer so feasible. That makes me sad. I know what I should do about it, but I wish I didn't have to.

Search engine crawlers generally respected robots.txt and limited themselves to a trickle of requests, likely based on the relative popularity of the website. These bots do neither, they will crawl anything they can access and send enough requests per second to drown your server, especially if you're a self hoster running your own little site on a dinky server.

Search engines never took my site down, these bots did.

It's mentioned in their code forge[0] that they're working on getting the first release out. So there's not yet anything to download.

[0] https://codeberg.org/comaps/comaps

No, it was a test for a year and deemed a failure.

The Selectric is listed under 1961.