Last year I gave Longhorn a try. It was a nice proposition for me: I was using local storage anyway, so the idea that pods would be independent of the nodes sounded delicious. Except the price was way too much.
At the time I thought that the only problem was Prometheus, which in itself is pretty heavy on disk IO, but it turns out the issue was with Longhorn itself. Also, as I found out, I wasn’t thorough enough deleting Longhorn stuff, which resulted in quite a few headaches this year.
The other day I noticed a post on one of my Misskey Antennas about “a container runtime written in Rust” called youki. This piqued my interest especially since its repository is under the containers org, which is also the home of Podman and crun for example. I’ll be honest and admit that I’m still not very clear about the exact responsibilities of such a runtime. It gets especially fuzzy when both “high level” runtimes like containerd and docker, and low level runtimes (that can serve as the “backend” of high level ones) like kata and youki are referred to just as “runtimes.” Anyway I decided to give it a try and see if I could get it to work with my k3s setup. It really wasn’t as easy as I’d hoped.
I’ve been trying to use linux for pretty much as long as I’ve had a computer. I’d kept running into blocks though: at first I was using my computer mostly for gaming, and that’s still not a strong suite for linux 20 years later. Then my workflows were dependent on tools that only worked on Windows (like Office’s Publisher, or Dreamweaver and Fireworks—hell I still miss the productivity I had with Fireworks). Then I had a laptop half of whose hardware wasn’t supported by any linux distro at that point. Then gradually those issues went away and I’ve been an Ubuntu main for over ten years now. Some linux elitists will look at my desktop and hiss that it’s not just a terminal or a tiled window manager that looks like it’s still 1995.
You might be familiar with OAuth scopes from for example the Github dialog for creating a new access token. You get to choose what the token is authorized to do: can the user manage repos? Leave reviews? Push commits? There are a ton of options. Similarly Mastodon has scopes such as “see favorites” or “post on your behalf.”
I first saw Redis sorted sets in action reading Mastodon’s source code. Sorted sets are used to store feeds (ignore that ZREVRANGEBYSCORE is deprecated). In a use-case such as Mastodon feeds (timelines), sorted sets come handy because you can “just” add new elements and Redis will take care of the sorting.
タイトルは英語のままなのは、日本語にしようとしても結局全部カタカナになるので放置。さてre-frameは俺的にClojureScriptでウェブのフロントエンド作るにあたって標準装備になっているが、ものによっては完全動的に生成されるReactのアプリよりも、検索エンジンなどでも絶対拾える静的HTMLを返した方がいいという場合もある。今回は流行り言葉をいっぱい使えるように、Denoを活かしてClojureScriptアプリのサーバーサイドレンダリングを実現しようと思います。動くコードはGithubにて。
Commonly frontend and backend are separate beasts. Backend written in Ruby using Rails for example, its routing written in its own DSL. Frontend written in TypeScript using Vue.js for example, its routing written in its own DSL. Of course the frontend will call some backend endpoints, so it should definitely know about those backend endpoints too, while there may be some frontend “paths” that don’t correspond to any single API endpoint, yet you might want to generate absolute URLs for those pages on the backend. This results in a nasty mess and duplication of routing and adjacent logic.
Finding popular keywords or tags is what twitter’s trends are (other than a means to manipulate public opinion and introduce artificial trends by paying good cash). While I think having a “trends” feature tends to introduce more problems than the value it provides for discovery, I wanted to figure out how I’d do it before deciding not to.
While working on stuff (of course in Clojure), I kept running into problems with namespaces having circular dependencies. For example I’d have an app.router namespace that defines the, uh, routes. I’d have an app.url namespace that contains helper functions to generate absolute URLs based on route data (so it depends on app.router). I’d have an app.views namespace that uses those URL helpers (thus depending on app.url), and these views would be referenced in the routes so app.router would require app.views.
This completes the dependency circle and is the beginning of my journey. There are a bunch of ways to deal with circular dependencies in Clojure, but I won’t go in-depth about all of them.
Earlier this year I wrote about adding Grafana annotations based on Argo CD events. Since this year I actually got around testing out Flux some more, it was natural to follow up with adding some Grafana annotations based on Flux events.
