I’ve known about Clojure multimethods of course, but I never really used them much. I didn’t really have data that I’d need polymorphism like multimethods to handle, and when I did need something like that I’d use protocols. However protocols dispatch based on class, so when I faced the problem of handling ActivityPub objects that are all maps, it was time for defmulti to save the day.
The first time I ran into “structured logging” was way, way back when I first started working on kitsune. Back then I went with the approach of using a Logback Formatter (the JacksonJsonFormatter) to log Clojure maps as JSON. This was nice because I didn’t have to do anything to “transform” the logs further, but had the quite significant downside that logs weren’t really human readable anymore. This plus that that log processors like Loki and CloudWatch can easily parse huge amounts of “traditional” text logs made me pretty much forget about structured logging until recently.
That is until in a thread on the clojurians slack about logging someone mentioned mulog, a structured logging library that caught my attention. I guess maybe from a traditional Clojure background it would’ve been natural to end up with taoensso/timbre at this point, but I never did that bit (though I do have it as an indirect dependency).
いろいろと秋田。飽きた。ここ2年はlogicoolのG613をキーボードとして使っていたが、今年のブラックフライデーをきっかけに買い換えようと決めた。最大の理由はやっぱりキーの不調。キーが反応しなかったり、多重に反応したりして、タイポが多発していた。またスタート？スーパー？キーは爆死していて一切反応しなかった。前者はまだbackspaceという神機能でなんとかなったけど、スタートキーはUbuntuだとActivitiesを起動させるショートカットで重宝なのでないと困る（Windowsだとalt-tabみたいなものかな？）
さて買い換えるのもまた簡単じゃない。まず日本語配列であーる。英語で打つことも少なくないないが、日常の業務などでは日本語入力が当たり前でレイアウトに慣れている（変換・無変換キーとか）。また、同時に最低限2端末に接続ができること。仕事用のPCにはBluetoothで、私用PCにはBluetoothもしくは直に指すUSBで。3端末同時に行けると助かる。最後に、とんでもない金額ではないこと。キーボードに出す金は1.5万で上限、それもかなりかけた気分になる。
この条件のキーボード見つけるまではかなり苦戦した。その最大の理由はAmazonの検索はゴミである点にはあるが、検索の過程はキーボード自体に関係ないので省略する。最終的に落ち着いたのはまたlogi製ではあるが、K855という製品だ。
スマート電球っていいね… と思っちゃった。わざわざベッドから起きなくても消せるし、スマホから操作もできるし、遠距離で点けたり消したりできるし、明度も調整できるし、強いでしょう？とか思いながらも結局金出すほどやりたいことでもなかった。そして今年の夏、ようつべでルームツアーやインテリア動画にハマった時期に紹介の動画を見たら結局衝動買いしちゃった。なぜかというとその辺飲みに行った店の内観がめっちゃササって、それっぽくできるじゃない？と思ったから。
Unlike Argo, Flux has no built-in UI. CD tools should be invisible most of the time, just quietly running in the back, getting changes in the cluster. This is fine for “most of the time” when there are no changes to the applications I’m making myself or the cluster itself. It can just look at the various helm charts and other (git) sources and deploying the changes as configured. It’s nice that I can be sure that my cluster has the latest possible versions of everything running within 10-15 minutes of release (depending on the Flux interval configured) without ever touching kubectl.
When I read about the system versioned (and bitemporal) tables in MariaDB, I was both surprised and delighted. This kind of data versioning is thought of as standard in the “immutable” databases that are big in Clojureland, such as Datomic and XTDB. On the other hand, these databases in Clojureland are usually EAVT based and not the “usual” relational kind. After a little thinking I could think of a bunch of really tricky issues that could arise from system versioning (eg having a by-default immutable log of all changes to some piece of data) in a relational context. The first being foreign keys.
If you create a foreign key in MariaDB without any further specifiers, it assumes ON UPDATE RESTRICT ON DELETE RESTRICT, meaning no referenced key could be changed and no referenced row could be deleted. Just consider this: if there’s a row in some table referencing a row in another, system versioned table, can the row in the system versioned “parent” table be deleted? After all the referenced version of the row will still exist… Or in a similar scenario if the “child” row is system versioned and updated to now reference a different row, will both of those referenced rows be RESTRICTed? After all, both referencing rows will still exist… Of course I had to try.
アドカレのブログでアドカレ作った話を書くのはさすがにちょっとメタすぎる気もするが、学ぶことは少なくなかったのでまとめる。思いの外スムーズにいったこともあって、小規模ながらもおもしろかった。
Ever since I first ran into the Metosin libraries, I’ve been using many of them. One of the most known and used of those is probably reitit, a routing library that can be used both on the server and in the browser. Recently I’ve had more opportunities using ClojureScript in the browser, and I noticed something that was confusing for a few moments.
When you create a whole FluxCD new setup from zero, it’s really easy: use flux bootstrap. it does “everything” for you. In my case I tried this setup first for last year’s advent calendar. Except back then I had an expedition scheduled for the first half of December, so this took the back seat and was eventually forgotten. Therefore in this year past everything I did back then slowly sank into oblivion, so I again had to start pretty much from zero.
I did set up the repo and a cluster (on Civo) back then, but I quickly tore down the cluster when I realized I wouldn’t be able to test it all out. The repo stayed though, so now i was starting afresh with a k3s cluster spanning three nanodes (that’s a linode referral link with a $100 credit over 60 days) and a repository already set up from last year.
Last year I had a brief affair with Longhorn. It’s a tool that abstracts the interface to interact with volumes (in my case in Kubernetes) from where the underlying data actually lives. In my case, my cluster consists of three small nodes, and back then most of the data lived in local-path provisioned volumes. Using local-path means that the data is physically on the host machine instead of some virtually mounted filesystem. This also means that once an application has a PVC, it can’t be assigned to any other node (it results in a “conflict”).
