So often I see people giving talks about how the microservice architecture is a failure. You end up losing transactional protections, you’ll have to “join” data across a network boundary, and that network boundary is “always” flaky. Wouldn’t it be much better if everything was in one process, where you could enjoy the benefits of transactions, neighboring data is just a method call away and the only network you have to worry about is the database connection?
Tricking the JVM JIT into speed
On the Clojurians Slack, PEZ brought some delicious Fibonacci performance tuning from the “languages” repo. While I don’t think that benchmark is as useful as mesmerizing the moving circles are in the animated graphs, I had a few very confusing and interesting discoveries.
Step 1: watch Alex Miller’s talk about Clojure’s interop performance. Step 2: learn how to actually do all that stuff. Step 3: notice that recursion does things. Step 4: magic.
Untyped JS objects in ClojureScript
Working on a Chrome plugin I got to use ClojureScript in yet another new environment. After the usual browser setup, Node, Deno and Github Actions, this time it was the Chrome plugin system. While it was mostly a very smooth ride, I had a little trouble figuring out how to deal with a “Cannot infer target type in expression” warning.
It showed up while dealing with a HAR entry object passed in to my callback from devtools.network.onRequestFinished. The HAR object, while its shape is well defined, is not typed in a strict sense (though I guess there may be some type definition for it somewhere out there if I looked hard enough). That’s why when I tried to access its fields like (-> entry .-request .-url) the ClojureScript compiler (through Shadow CLJS) would complain about inferring the “target type” as above.
ClojureDartで自前でwidget作ろうとするときの注意点
やりたかったことは多言語対応の一環だった。flutter_localizationsの生成コードでBuildContextからAppLocalizationは取得できるが、それと別にOSの言語設定を監視したかった。そのために他のウィジェットを包むだけのものを用意して、ミドルウェア的な挙動でOSの言語設定をアプリのDBに保管したかった。でもなぜかそれを適応すると、今度はgo_routerのStatefulShellRouteを使った遷移が機能しなくなってしまった。
extend-protocolでClass/forName怒られるワケ
Clojureでプロトコルをよく使う。defprotocolで作ってextend-protocolで各種の型に実装すると、いろんな入力値にスムーズに対応できる。例えば暗号化周りで、ハッシュや署名の算出のためにバイト配列が必要な際、プロトコルを活かしていい感じのAPIが提供できる。
(defprotocol Byteish
(->bytes ^bytes [input]))
(extend-protocol Byteish
String
(->bytes [input] (.getBytes input)))Some notes on iOS BLE
Dealing with Bluetooth Low Energy (BLE) through Swift can be pretty tricky. The interfaces and delegation are straightforward, but there is an implicit “right way” of doing things that (as far as I could find) is not documented anywhere.
I don’t know if the way you have to hold on to references to things or they get immediately discarded and cleaned up was surprising only for me with zero Swift background, but it took some time to get used to. For example CBPeripheral and CBL2CAPChannel objects require that you keep a reference to them, or the connection will be terminated, resulting in interesting behaviors.
Another thing is that I couldn’t find any details about error patterns in the documentation, but I figured out the following:
- the input and output streams that come with a CBL2CAPChannel are not opened when you get your hands on them, and result in a pretty obscure
0x0122failure if you try to use them without opening them first - you have to read/write those streams from the same DispatchQueue where they are scheduled, or the operations will silently just do nothing. Logging Thread.current can help debugging this.
- error 436 means the local (you) severed the connection. This usually happens when you forget to hold on to the CBPeripheral instance
- error 431 means the remote peer severed the connection. I’m not entirely sure what triggers this, since usually the disconnect is very graceful with a delegate callback. Maybe sometimes closing the streams doesn’t make it in time and this error gets logged first?
- error 582 means the PSM used to initiate the CBL2CAPChannel is incorrect.
Longhorn trash weighing me down
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.
Setting up additional container runtimes
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.
Convenience
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.
Supercharged OAuth scopes with reitit
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.”
