Tag: code

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 0x0122 failure 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.

white cow statue beside brown tree

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.

plasma ball digital wallpaper

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

padlock on black metal fence

Redis sorted sets are cool

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.

variety of fruits displayed on wooden shelf

Server-side rendering a ClojureScript app with Deno

タイトルは英語のままなのは、日本語にしようとしても結局全部カタカナになるので放置。さてre-frameは俺的にClojureScriptでウェブのフロントエンド作るにあたって標準装備になっているが、ものによっては完全動的に生成されるReactのアプリよりも、検索エンジンなどでも絶対拾える静的HTMLを返した方がいいという場合もある。今回は流行り言葉をいっぱい使えるように、Denoを活かしてClojureScriptアプリのサーバーサイドレンダリングを実現しようと思います。動くコードはGithubにて


Frontend/backend shared routing with reitit

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.

asphalt road between trees

Elasticsearch aggregation to find most popular tags over time

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.


Dealing with circular dependencies in Clojure

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.

timelapse photography of fire