bouzuya.hatenablog.com

ぼうずやのにっき

Apple Magic Trackpad を買った / ABC318 に参加した

Apple Magic Trackpad が届いて一週間ほど使ってみた。

2019-11-08 から Logicool の MX ERGO https://www.amazon.co.jp/dp/B074Z71C2M を使っていたのだけど左クリックの反応が悪くなり、ドラッグアンドドロップの途中で一瞬離したりするようになってしまった。これはダメだと思い、インプットデバイスを買うことにした。

MX ERGO を買っても良かったのだけど面白みがないので、 Apple Magic Trackpad を検討した。商品ページを開いて価格 (約1万5千円) にひるんで Logicool の他のトラックボールを買おうかとしたのだけど、 Amazon の商品ページをみたらひろゆきの動画がついていたので購入をやめて Apple Magic Trackpad を買った。

ものとしてはほとんど MacBook についてるアレで、大きな差はない。若干サイズが大きかったり傾斜があったりするけど、そこに差は感じない。気になる差としては押し込みが若干 MacBook のものより重いこと。ぼくは押し込みでクリックしていることも多いのですこしストレスを感じる。

MX ERGO からの差異という意味では手の置き場所に迷う。トラックボールの場所に安定して置けていたのが、突起のない板になってしまったので、手元を探すような仕草をしばらくしていた。いまは自身の正面において使うのを試している。まだ模索中。

ABC318 に参加した。 1335 → 1346 (+11) で Highest を更新した。

https://atcoder.jp/users/bouzuya/history/share/abc318

D 問題に時間をかけすぎた。何かの書籍で見た bit DP の遷移の手順と同じなのは気づいたのだけど、どう書くのだったかうまく思い出せず迷ってしまった。

[bouzuya/kireta] をつくっている。方針転換をして WASM の採用をやめることにした。

WebView コンポーネント経由で WASM を使う方針で検討していた。この方針の問題点は次のとおり。

  • すべての呼び出しが async で wrap される
  • 引数が JSON 化できるものに限定される
  • ↑ も合わせて WebView 内と外でのやりとりにコストがかかりそう

どこまでを WASM でやるか……という境界を考えたときに tsukota を踏襲するなら「集約の操作」で切るのだけど async が邪魔だし集約のインスタンスを共有できないし WebView 内にインスタンスを持ったとして表示のたびに async で状態を得て……とか考えてみて良くないなと。

そも全体で見たときにそれが必要なのかから考え直した。

tsukota と類似の構成でもう一本アプリをつくるのは大前提としてあった。 tsukota からの変更点としてバックエンドを Cloud Functions (TypeScript) -> Cloud Run (Rust) にすることを前提として、モデルをバックエンド・フロントエンドで共有するために WASM を検討していた。

バックエンドの Rust 採用は業務で使う技術の検証を兼ねているため。業務に寄せる方針で考えるならその前提は変えない。ここを変えるなら React Native をやめて Rust で Android アプリなどに振るほうがより面白い。オフラインファーストになるよう考えるかなと思っている。

前提を変えない場合でも、モデルをバックエンド・フロントエンドで共有する必要性は怪しい。

たとえば「モデル」と言っているものをクエリモデルとコマンドモデルで別ものと考えれば良いのでは……という観点。イベントを公開する方針は tsukota から踏襲してクエリモデルのみ TypeScript で実装する案。この場合コマンドモデルはバックエンドにあるのでイベントからモデルを再構築するパフォーマンス低下があるのだけど、ここでは tsukota の際に追加しなかった snapshot イベントを試す手もあるかなと思った。またイベントを公開しない方針もあり得る。

コマンドモデル・クエリモデルを共にバックエンドのみに持ち、イベントを公開しない方針もありかなと。むしろ一般的な構成ではある。せっかくなので GraphQL などを試しても良さそう。「業務で使う技術の検証」の色を強く出すならこの方針が良いかなと思っている。

少なくとも WASM をやめることは決定。 snapshot イベントでどれくらいパフォーマンス低下を避けられるのかを検証するのも決定。あとは Rust で GraphQL サーバーを書いたことはないのでそれの検証を入れるかは分からないけど「業務で使う技術の検証」の方向に倒す想定なのでおそらく入れる。

kireta でやることの方向がすこし整理できたように思う。

今日のコミット。