Docker Hub の課金安いわりに得られるメリットがでかい ということが分かり月$5課金しはじめた。一番いいのは、 800 円払うだけでプライベートレジストリ使い放題というところ。個人なら$5で済むならなんだかんだこれが一番いい気がする。

最近家のインターネットが不安定な感じがあり 、というのも VM の数とかどんどん増えてるのでたぶんルーターが終わってんだろうなあってかんじ。

現代における SuperOPT100E 的な安定してるいいかんじのルーターってなんかないのかな〜

tailwind で書いたものをメンテしたくないので手元はなるべく sakura.css に寄せていこう、ということでここもそうした。

ある OSS のプラグインにちょっと似ているがちょっと違うみたいなプラグインを作りたくなって、でもその OSS の内部構造とか全然知らないので、プラグインの実装を全部 GPT-4 に渡して「これを参考にこういうの書いて」って流したらパパッと出来た。まあでもその実装自体は不具合多数あるものだったんだけど、一旦シンプルな叩き台ができるとあとは話がはやい。QAプロセスまわして直して実装完了したしそのプロセスで知識も増えたのであとは自分でガシガシいける、ということになった。

ねむい

tailscale とさくらにおいた VPS でサーバー公開してた部分を cloudflared に置き換えていて、まあ、正直 tailscale でやるほうが楽ではあるのだが、 VPS を管理したくないのでというかんじ。

だるい

Intel N100 マシンよすぎて 5 台買ったんだけどそれでも 12 万とかだし、 20 コアで、メモリ 80GB、ストレージ が 2.5TB で 12 万と思うとかなりすごい。

microk8s の dqlite が大暴走するので k3s に移行してみたが完全にこっちのほうが快適だな、 microk8s というか Canonical 文明は「パッと見」動いてる感じで本当にダメだ。

ここの Astro 2.0 に上げてみたが あっさりなにもせずそのまま動いて素晴らしい。 Astro が特別優れているかというとまあ別に、、、ぐらいにしか思ってなかったんだけど、メジャーバージョンアップで壊れないのは本当にいい。 Web フロントエンド界隈でこれができてるのは奇跡だ。

何も考えずに現代でアプリをつくると わりと分散された構成になってしまいがち(?)で、 API は〜〜で、フロントは〜〜で、デプロイのためのワークフローは〜〜とかいってこんなこと全然本質的な作業じゃねーななどと思う一方で、 Rails や Laravel で実際なんか作ってみるとすげーごちゃごちゃしててこれはこれで本質的な作業じゃねーなみたいなのが大量に発生する。

結局のところ自分が「本質的な作業じゃない」みたいに思ってる部分に実際にはシステム開発の神髄があるのだろう。というか嫌々やるような部分にしか「自分がやるべき仕事」みたいのは残らないと言ってもいいかもしれない。

なんもかんもがだるいがとりあえずなんか作ったりはしてるからいいかな、、、

Copilot が AWS CDK のコードを大体生成してくれる

こういう定型的なものはほんと効くし、生成されたコードをみてからドキュメントを見ると理解がはやい。

使ってないマシンは腐る というのがあると思っている。腐るっていう言い方はあれなんだが、いやまあでも腐るとしか表現しようがない。特にデスクトップマシンは腐るんだわ。使ってないマシンをひさしぶりに起動する。ソフトウェアのアップグレードをしようとすると失敗する。ブラウザはあらゆるセッションが終わっていて全部ログインしなおしとなる。こういう状態は腐ると表現するのが一番よいと思う。

で。手元にあるデスクトップ用途のマシンを数えてみると、私物と借り物と併せて全部で 6-7 台はある。そのうちデュアルブートになってるマシンも複数あるので環境としては 10 個ぐらいあるんじゃなかろうか。そうなると当然どれかが腐っていてたまにそれを使うと面倒だ、ということになる。なので最近毎日適当にローテーションして全部使うようにしている。本当に気分で適当に使うのを変える。

そうなると、開発環境が個々のマシンにあるというのでは話にならない。すると .devcontainer とかを整備することになるので、じゃあもう Codespaces でええわ、という感じになっていろいろあるマシンからだいたい Codespaces を使っている、というのが現状。

どれもそこそこハイスペックなのでこんな使い方するのもったいないのだがまあしかしこうなると本当にどこでも同じような感じで作業できて快適でいいですね、マシンも腐らないし。

ここ next.js から Astro.js にした

動的に生成してる意味ねえなという気がしたので。 Github からデータ更新したいとかは特にない + データベースは持っておきたいというのがあるので、 Firestore に投稿するフォームを別途作った。ただそれだけだと Astro.js の生成ができないので、投稿フォームで投稿すると Github Actions の workflow を dispatch するとかそんなん。

なんかこういうことはじめるとインフラでがちゃがちゃみたいな感じで表現される部分がいまいちテストされてないかんじになってよくないね。

はーまじでだるい

最近 Hotwire をちまちま使っている 。 Rolling Icon くんも Hotwire でフロントエンド書き直してみた。

こんなかんじの SPA っぽいものならわりとすぐ作れる。 Rails のサーバーサイドの書きやすさもあってなんなら next.js とかで作るよりずっと速くできると思う。それから Rails のテストの書きやすさ(特に E2E テスト)もあって圧倒的に堅牢だと思う。

Tailwind が使えるのでスタイルはそれでやればいいと思う。ちょっと前まで MUI/Chakra UI とか使えないの辛いなあとか思ってたのが、 Tailwind に慣れるともうこれでいいやってなって next.js で書くときも twind ってやつ使うようになった。

とはいえ。

• これが流行るとはとても思えない
  • 「テスト書きやすい」ぐらいで next.js から人がこっちくるとは思えない(みんなろくにテスト書いてないでしょ、知ってるぞ)
• なんというかとにかくすべてがワンテンポ遅い
  • React で「普通」に書いたやつと比べてとにかくなんか微妙にモッサリ、みたいな感じになりがち

結構頑張っても精々 Hey ぐらいの使用感にしかならんのよね。とはいえ Hey は「あのレスポンス」にも関わらず GMail とかより体験がいいと思う。それはデザインにコストをかけまくって UX が徹底的に練り込まれているからだと僕は理解している。

なんというかそこらの一般人がサイト/アプリ作るんだったら

1. MUI とかそのへん使ってマテリアルデザインに乗っかってしまう
2. React 使ってなるべく必要そうなものはプリロードして最速で動くの作る
3. next.js の SSR/ISG/SSG を活用してファーストロードを常識的な範囲で最適化する

みたいなかんじで「そこそこのデザインで結構速い」みたいな感じを狙っていくほうがコスパがいい、という気がしている。

とはいえ Hotwire をここ数週間触っていて「悪くないな」という感じが結構強くあり、しかしこんなもん触ってて人生になんの意味が、とか考えたりもする。

レイアウトめっちゃがたつくなー

かなり強引なことをしたので反省はしている

かつて動的生成していたサイトをどのように捨てるか みたいな問題と格闘している。

MySQL 自前運用したくないのでがんばって捨てようとしている

非常にだるい

Firebase で普通の Rails アプリにログイン したい、という要求がある。

Firebase + Rails というコンテキストでよくあるのは

• クライアントサイドは普通の React アプリや iOS アプリで Firebase をつかって認証
• Rails 側は API を提供し、 Firebase で生成した idToken でユーザーを特定

みたいな事例だと思う。この時 Rails 側は基本的にセッション管理の必要がない。

ただ今回は Firebase で認証して Rails のセッションを作りたい。ようするに、ユーザーの管理とログインまわり(典型的には Google とか Github とかを使うだろう)だけを Firebase にやらせたい。

ではどうするか、といえば以下のような感じにすればよい。

まずログインページは以下のような感じにする。

<button id="login">ログイン</button>

<script type="module">
import { initializeApp } from "https://www.gstatic.com/firebasejs/9.6.8/firebase-app.js";
import { GoogleAuthProvider, getAuth, signInWithPopup } from "https://www.gstatic.com/firebasejs/9.6.8/firebase-auth.js";
const firebaseConfig = {
  ...
};

const app = initializeApp(firebaseConfig);
const authenticate = async ()=>{
  const provider = new GoogleAuthProvider();
  const auth = getAuth(app);
  const result = await signInWithPopup(auth, provider);
  return result.user;
}

document.querySelector("button#login").addEventListener("click", async ()=>{
  const user = await authenticate();
  const idToken = await user.getIdToken();
  document.querySelector("input#idToken").value = idToken;
  document.querySelector("form").submit();
});
</script>

<div style="display:none">
  <%=form_tag("/login", :method => :post) do %>
    <%=hidden_field_tag("authenticity_token", form_authenticity_token)%>
    <%= text_field_tag("idToken", "") %>
  <% end %>
</div>

このようにすればログインボタンを押せば Firebase でログインし、ログインに成功すれば Firebase の idToken が /login という Rails の action に post される。

/login の先の Rails のサーバーサイドは以下のようなかんじ。

def login
  jwks =
    JSON.parse RestClient.get(
                  'https://www.googleapis.com/service_accounts/v1/jwk/securetoken@system.gserviceaccount.com'
                ).body
  id_token = params[:idToken]
  payload, = JWT.decode(id_token, nil, true, { algorithms: ['RS256'], jwks: jwks })
  session[:user_id] = payload['uid']
  redirect_to home_path
end

ようするに、 API 提供するときと同じように idToken を検証して Rails の session を吐き出してしまえばよい。

こうすれば普通の Rails アプリにたいしてログイン部分だけ Firebase を使う、みたいなことができて楽ができる。

在宅勤務のために買ったけどいらなかったものまとめ

「在宅勤務環境整備しました」とかいって金持ち自慢するのがこの 2 年間ずっと流行ってた感じしますよね、最悪です。

本日は在宅勤務環境整備のために買ってみていらなかったもの、ゴミだったものについて紹介していきます。

マルチディスプレイまわり全般

ぼくは家での作業は主に 24 インチ iMac を使っているんですが、ディスプレイ増やしてみるか〜みたいな感じで浪費をしはじめることがたまにあります。

それで買ったものは

• ディスプレイアーム https://www.amazon.co.jp/dp/B00MIBN16O/
• LG の USB Type-C でつながる 4K ディスプレイ https://www.amazon.co.jp/dp/B09CYBJ31X/
• iPad スタンド(こういうやつ https://www.amazon.co.jp/dp/B07FCMGFDB/)

とかいろいろ。ただこうやっていろいろ買ってもほとんど使わないし邪魔だしわりと速やかに撤去されていきました。マルチディスプレイって切り替えに首とか目とかをかなりゴリッと動かさないといけないじゃないですか。でもウインドウの切り替えなら手元で Cmd+Tab とか Alt+Tab とかチョロっと押すだけなので結局マルチディスプレイってあんま意味ないと思う。

そもそもオフィスで働いてるころも 4K ディスプレイ一枚でやってたんだからこれら買う必要とか一切ないんですが、家でダラダラしてると判断力はなくなる。

Quest 2 + Immersed とかだと手に被せるかたちでディスプレイ配置したりとかできるのであれだとまた別の価値があると思うのだが、普通のマルチモニタはうーん、いりますかねえ?

オカムラ フィーゴ

https://www.okamura.co.jp/product/seating/feego/

何年か前にこれを使っていて当時はわりと満足していたので、これにすっか!!と思って買ったけどなんか今は全然体にあわねえなって感じした。

カメラとかマイクとか全般

カメラとかマイクとか買ってみるの絶対みんなやると思うんだけど

• カメラとかだいたいオフにしてる
• 素人がマイクとか設定してもハウリングおこしたりして迷惑かけるだけ
• いろいろ頑張ったとして iMac のカメラとマイクが最強でこれ以上の品質にならない

などの問題があって全部ゴミになった。

Sony WH-1000XM3

会議マイク、ヘッドホンとして買ったつもりだったけど音楽聞くのにしか使ってないしその用途なら別にこんな高いノイキャン必要ないし、これ自体満足してるかというと満足してるけどべつにこんな高いの買う必要なかったなと思う。 M4 と違って M3 はクアルコムチップなので Windows と繋いで低遅延なのはかなりよいです。ゴミにはなってないし使ってるんだけど、当初考えた用途としては一切使ってない。

高いマウスとキーボード全般

もともと Realforce おじさんだったので在宅勤務だしみたいなかんじであたらしくいろいろ買いまくったんですが、結局 Magic Keyboard と Magic Trackpad をメインで使っている。これがとてもいいかというと別にそうでもないと思うけど、別にこれで困りもしないという、、、

環境測定するやつ

温度計湿度計とか二酸化炭素測定器だとか例に漏れずいろいろ買って、データを LoRaWAN 経由でクラウドに飛ばすぜ!!!とかやったりしてるんだけど別に一切みてない。 LoRaWAN 環境(The Things Network)を家に整備して無線 LAN 届かないところにも IoT デバイス置けるようにしたのは結構楽しかったんだけど、それで環境測定してだから何?って感じで割と一瞬で見なくなる。

昇降デスク

一切動かしてないことに気付いて売った。こんなもんが中古で問題なく売れるのはいい時代?だなと思った。

デスク下ケーブル収納トレー

いろいろデスクにデバイス置くぜ!!とか思ってこういうものを買いましたが結局 iMac しか使ってないので一切不要であった。

なんか総じて iMac と Oculus/Meta Quest 2 の満足度が高すぎてこれだけあれば他なんもいらねえなって感じ。ノートで無理矢理仕事するから変なことになってるみたいな人多いんじゃないかと思う。デスクトップマシンまじでいいですね。

今年買ってよかったもの 2022

こんばんわ。今年もいろいろ買っているので買ってよかったものをまとめていきます。

iPhone 13 mini

128GB docomo 版です。正月に東京中を徘徊して吉祥寺のヨドバシでようやく在庫確保して買いました。 MNP の弾はなかったので 2 年使って 2 万円です。 XR から買い替えました。

2 万円で買える携帯電話としては本当によいものだと思います。僕の手は面積としては手が小さい女性と比較してもかなり小さい、という感じなのでこのサイズは非常によいです。ただこうやって投げ売りされていることからあきらかな通り全然売れてないし今年からこのサイズなくなるらしいし悲しいことですね。

詳細は調べてほしいんですが 2 年後に没収されるかわりに 2 万で買える、という買い方をしていて実質的にはリースみたいなもんなので 2 年後に安い電話がないと結構面倒なことになります。

山善のエアフライヤー

あじのりはサイズ比較。完全に衝動買い。山善買うくらいならレビュー偽装してる中国製品買うほうがいいと思ってるんですが安かったので。フライドチキン「らしきもの」は作れたのでとりあえず満足。

チェーンテンショナー

https://www.amazon.co.jp/dp/B00A0DRIZM/

これはなにかというと、変速式の自転車を変速なしで使うように改造するのに使うものです。インターネットでの事例をみると、車輪につけるギアを換装したりするのが普通のようですが、単に変速機をこいつにかえてチェーン適当につけてこいつで張りをつけるかんじにしたらとりあえず普通に乗れるようにはなりました。

変速機が完全にぶっ壊れた自転車があって、変速機の交換とかめんどくせえしどうせ変速とか一切してないしみたいな感じでこれを買ってみたんですが安く自転車が修理できてよかったですね。普通は自転車の軽量化とかを狙って買うらしいんですが俺はそもそも体重が 98kg あって全身に筋肉があるので細かい重量とかは気にしない。

まじでよくわかんねえ Apple Watch と iPhone の充電器

https://www.amazon.co.jp/dp/B092D6CVGX/

正月早々純正の Apple Watch の充電器がぶっ壊れたので適当に買ったやつ。とりあえず普通に Apple Watch も iPhone も充電できたのでオッケーです。

そしてもう買えなくなっとるやんけ。

AZ のグリースを使えるグリースガン

https://www.amazon.co.jp/dp/B085HHL98W/

これまで自転車のグリスは Amazon で「自転車 グリス」とか検索したらでてくる黄色のやつをつかっていて特に性能とかは文句ない(というかグリスの性能差なんてなんも知らねえ)というかんじなんだけど、グリスを注入する注射器とかそういうのをもってないのでチューブからひりだしたあと手で塗り込んだりしていて最悪の体験になっていた。

というわけでエーゼットの緑色のキモい芋虫みたいなチューブを接続できるグリースガンを買った。グリスは近所のホムセンで自動車用だかみたいな一番安いやつを買った。シマノのグリスと性能差あるのかどうかしらねえけど BB バラしてこのグリス使って適当に走ってみたけど一切違いとか分からなかったので今後これでいきます。

ももこの単行本

https://www.wani.com/product/4862698190/

いろいろあって買うの遅れた。エロマンガです。すげえよかった。俺はももこのマンガの時系列を整理した表を Google Spreadsheet でメンテナンスし続けている。

貿易戦争は階級闘争である――格差と対立の隠された構造

https://www.amazon.co.jp/dp/B094959Z6L/

買った覚えないんだけど Kindle のライブラリに入ってたので取り急ぎ読んだ。たぶんカウコンみたあと寝ぼけて買った。最近気付いたんだけど「ジャニーズカウントダウンライブ」なのに「カウコン」って略されてるよな。

内容は「中国、ドイツ(それとかつては日本)の労働者が不当に貧しい暮しをしてその結果これらの国が過剰に輸出をするのでアメリカの中間層が没落している、つまり貿易戦争とは階級闘争なので中国の上層部や富裕層の行動を変えさせないと貿易戦争は最終的に熱戦に至る」というような内容。ざっくりいえばこんな感じなんだけどこれが非常に緻密に議論が展開されています。

しかしまあ中国の腐敗した共産党幹部の気持ちになってよくよく考えてみると熱戦になろうがこの本の著者買いうことを受け入れようが自分の財産が無くなるのは一緒なわけで、ギリギリまでつっぱって戦争したほうがお得なんじゃねえのかって思う。つまりこの本に書かれていることが正しい場合戦争を回避する手段はないように見えるがどうか。

まだ今年 4 日しか経ってないのにいろいろ買っててやばい感じしますね。今年も大量に買い物していきましょう。

セキュリティとアクセシビリティって衝突しがちだと思っている。 このページでは常識的に考えればセッション一時間の寿命で十分でしょ、と思ってそうすると、障害がある人がとんでもなく長い時間かけて使ってくれているのを排除したりすることになる。

セッションの寿命の話だと結局セッションの寿命短くしたい理由が jwt や Rails の cookie store を使っていてステートレスに全部管理しているので指定したセッションだけ狙い撃ちで殺せないから、とかだったりするので、サーバーサイドでもセッション管理しましょう、で済まないことはない。

セキュリティと口にすれば手抜きが許容されやすい、みたいな面もあるにはあるのだが、突き詰めればアクセシビリティとセキュリティはどうしても対立する概念だと思う。アクセシブルなシステムは攻撃者にもアクセシブル。

たとえばだけど、 MFA はアクセシビリティを阻害する。ぼくはデバイスを持ち替えて TOTP を入力することになんの困難も感じていないけれども、それが非常に困難な体験だという人だっていくらでもいる。あるいは、 TOTP のタイムアウトまでに 6 文字を入力することが難しい、という人だってどこにでもいるだろう。

障害者がどういう I/O デバイスを使っているかを知っている人なら健常者の常識でシステムの操作時間を考えてはいけないことは知っている。操作にかかる時間、コストに限らずだが、こういうのって想像力の問題みたいなところに落とされがちだと感じているが実際には知識量の問題だと思う。

セキュリティと両立した実務的なアクセシビリティガイドラインみたいなものがあればいいと思っているが、さすがにそんなものは見たことがない。

arm Mac と向き合う Web アプリケーション開発環境

• しない話: Docker Desktop の課金回避

問題意識

Mac の CPU が arm になってしまった結果、以下のような問題がある

• JVM 系を中心に amd64 な Docker image が Mac で挙動が怪しい
• ネイティブ開発すっか!!となるとライブラリのバンドリングとかでおかしいことになりがち
  • Ruby の nokogiri とか
• ネイティブだと古いものはわりと動かない
• そういう問題がなかったとして arm で開発したものを amd64 環境にデプロイするのはちょっと勇気がいる。

古い環境はアップデートせえやという話なのだが、リソース不足してるものはどうにもならず、結果として古い JVM 環境を延命させてたやつとかはまじでどうにもならなくなったりする。えてしてそういうものは皆さんの手元にあることでしょう。

そして「動く」ものも結構しんどい。実行環境と開発環境が揃ってないのはいかにも今風ではない。すべてをコンテナ化してなるべく同じような環境で動かして環境の問題は環境変数とかを経由して流し込んでいくみたいなのが一般的だと思う(とはいえあまりそこにこだわりすぎてもどうせその流し込んだちょっとした違いみたいなところでいつか問題はおきてくるもんではあるが)。

解決策

いくつか考えられると思う。

1. 本番環境を arm にする

これまでぼくの経験では(といっても大した経験でもないが、、、) AWS の Graviton 2 はコスト面でかなり魅力のある環境だと認識している。シングルコア性能はあんまりでないけど、 Web アプリのボトルネックは大抵 I/O であり安価にコアが沢山並んでるほうが嬉しい事例は多いはず。開発環境は arm なんだし本番環境も arm にしちゃう、というのは選択肢としては十分ありえると思っている。

新規事業でチームもプロダクトも環境もイチから作るぜ！みたいな場合はありえるんじゃないかね。事実上 AWS にロックインされるのは嬉しくないし、レガシーコード抱えてる場合はもちろんどうにもならないね。

2. 開発者のマシンを Mac 以外にする

Linux デスクトップとか WSL2 とかを標準的な開発環境にする。マシンは XPS とか ThinkPad とかを開発者に配る。

僕は日常的には Linux デスクトップを使っていて、そして ThinkPad のファンでもあるのでこれはよい選択肢だと思っている。ただし世の Web 開発者が Windows + WSL2 や Linux に慣れているかというとそうでもないし、ディスプレイとかスリープ復帰とか発熱とかそういうあたりで Apple 製品が未だに圧倒的な魅力を持っていることは否定しがたいとも思っている(逆に言うと Ryzen つかってるとスリープまわりいまだにおかしいのどうなっとるんだ)。

それから日本で仕事をしている場合は特にだが、現代の Web アプリケーションにおいて iOS で動作するアプリはかなり多くの場合で事業において非常に高い地位が与えられていると思う。 Web 開発やってる人でも Xcode も起動しているということは多いだろう。

しかしみんな Linux 普通に使うようにならんもんかねえ。

3. Mac と Mac 以外を開発者に両方わたす

Xcode はどうせ必須問題への答え。 Mac と amd64 マシンどっちも持たせる。案外コスパはいい解決策だと思う。ただし管理するマシンが倍になるのは組織にとっても開発者個々人にとっても負担であろう。

4. クラウドで動作する開発環境をつくる

.devcontainer とかを整備して Github Codespaces とかでどうにかできるようにする、みたいなやつ。

複数のリポジトリにまたがるマイクロサービスとして事業が表現されている、といった場合だとこういうものを構築するのも難易度が高いという問題がある。また Codespaces を使うか使わないかを別にしてもこういうことを現代にやろうとするとどうしても VSCode ありきになりがち、という問題もあると思う。

開発環境を統制してセキュリティ水準を上げられることもメリットになる。そして開発環境を統制するのにおそらくかなり早い段階で専任の担当者が必要になるであろう。

コスト的にもわりとそこそこかかる。いろいろあるけど amd64 ノートも持たせちゃうほうが安上りになることは多そうだと感じている。

で、どうしよう?

開発者のもってるマシンの CPU アーキテクチャが arm になるのでどうしよう、みたいな文脈で話をしてきたわけだけど、解決策のところの最初にかいたように「単に実行環境としても arm なマシンは魅力的な選択肢」という問題もある。つまり amd64 アーキテクチャな CPU を持ってる人に arm な開発環境を提供しなきゃ、みたいなタスクもいずれ生えてくる。

手間とコストはかかってもクラウド上でばっちり使える開発環境を構築して開発者たちに提供していくぜみたいな気合が求められている気がしている。やりたくないけど、、、

えび

かに

CTO という役職が日本の Web ベンチャー界隈において「サーバーサイドの偉い人」という響きをもちがち という現象は絶対にあって、これはなんでこうなるんだろうか？というのをわりとずっと疑問に思っていて、まあ、でも結局 UI よりもデータのほうが偉いみたいな意識がみなどこかにあるんだろうか？

それはそれでまあいいんだけど、 CTO のミッションには UI とかは含まれない、とかなってしまうとそれはどうなんだみたいな話であり、その結果よくないことになってる組織というのもそれなりに見る。

まあ、結局、現代の複雑化したソフトウェア構成の中で適切な技術戦略を立てられる人がほとんど日本にはいないという話なのかもしれん。