私が歌川です

@utgwkk が書いている

ChatGPTでAIとおしゃべりブームが来ている。来ているというか、ひと通り見たので次のAIブームが来たらまた野次馬に来ます、という感じ。いまのところ娯楽としてはおもしろいと思う。

知っている単語と単語をつなげて、構文的にはつながっているけどまったく正しくない文が出てくるのを見ると、まだまだ改善の余地があると思う。知らないことをさも知っているかのように答えてください、分からないはナシです、と言われたら自分もこのように振る舞わざるを得ないのだろうか。知らないことは知らないから知らないとしか言えないと思う。

生身の人間がこのような受け答えをしているほうが厄介だなと思ったけど、自分の学部時代のレポートも似たようなものだったのではないか。一生懸命調べてまとめた結果がそうである、という違いはあるかもしれない。つまり、文章を書いて相手に伝える機会が多いといい、ということが言いたいのであった。

ここで一冊

blog.utgw.net

吉祥寺.pm 31でLTした #kichijojipm

kichijojipm.connpass.com

今回も一句用意してから臨みました。

speakerdeck.com

機能追加やバグ修正以外にも、Pull Requestにはマージされる以外の使い道がある、という話をしました。普段の活動を5分に凝縮してダイジェストする、という意識で発表していましたが、想像したよりもいい反応をもらえたように思います。Pull Requestのページはいろいろなところにコメント欄があるので活用していけるといいと思っています。


今回の吉祥寺.pmではいい話をいろいろ聞くことができてよかったです。技術的に興味深い話や、勇気づけられる話など、いろいろな軸で今年書いたコードの話が聞けました。

Relayのfetch policyは取得したデータをキャッシュするかどうかに影響を与えない

Relay 14.1.0 で確認した。Fetch Policies | Relay を読んでもRelayが取得したデータをキャッシュストレージに格納するかどうかについては言及されておらず、実験して確認した。

fetch policyはあくまでGraphQLクエリを発行するときにキャッシュを使うかどうか (ネットワークリクエストを飛ばすかどうか) を制御するものであって、キャッシュストレージの振る舞いを制御するものではないらしい。

実験に使ったコードがなくてメモ書きみたいになっているけど、GitHub - relayjs/relay-examples: A collection of sample Relay applicationsのサンプルコード (issue-tracker) で fetchPolicy の値を動的に変えたら動作確認できると思う。関係ないけどいつの間にか data-driven-dependencies っていうサンプルコードが増えていた。

Switchのゲームをプレイしている様子を配信できるとおもしろいはず、と思って、Elgatoのキャプチャーボードを買った。

そこまではよかったのだが、デスクトップマシンにUSB 3.0のポートが生えていないことが分かった。PCIスロットは余っているので増設すればよいのだけど、2016年のマシンを今後も使い倒すかどうか、買い替えたほうが早いこともあるのか? とも思って停滞している。ひとまずゲーム配信はMac経由でやっている。HDMIケーブルを抜き差しするのに加えて、Macを立ち上げる手間もあるのでそろそろ動いたほうがいい気はしつつ難しい。

もう1つ、そもそもディスプレイが足りないという問題もあった。HDMIポートが足りていないし、切替器を買ってみたけどうまく動かなかった。ディスプレイごと買い替えるか、あるいはでかいディスプレイとスタンドを買って環境をガラッと変えるか……。いろいろな変数がある中で検討が加速していない。机の大きさが有限であることを踏まえると、棚を買ったほうがいいのか? とか、そういう話題がどんどん出てくる。

JavaScriptで任意のHTML要素を画像化する取り組みのメモ

表題のことについてちょっと調べていて、だいたい以下のようなアプローチに分類できそう、と思ってきたのでメモです。

SVGの <foreignObject> にHTMLを突っ込む

SVGには <foreignObject> という要素があり、SVG以外の要素を描画することができる。ここにHTMLを丸ごと突っ込んだ上でSVGを画像化する、というアプローチ。

html-to-imageというライブラリがこの方針で実装されている。単にforeignObjectに突っ込むだけだと、画像やフォントがうまく使われないので埋め込む、ということをやっていそう*1

SafariではforeignObjectの制約が強いためうまく動かない、ということがhtml-to-imageのREADMEに書いてある。Safariをターゲットとしないならこのアプローチでうまくいきそう。

レンダラーを再実装する

ブラウザのレンダラーと同様に、任意のDOM要素を画像化する部分を実装してしまおう、というアプローチ。この方法は実行環境によらずうまく動く可能性が高いものの、ブラウザと全く同じ描画結果になる保証はない。

html2canvas は、DOM要素を受け取って独自実装のレンダラーでcanvasに画像として書き出している。

vercel/satoriは、DOMのサブセットとスタイルを受け取ってSVGに変換 (ベクタ画像化) している。

画面キャプチャAPIを使う

developer.mozilla.org

画面キャプチャAPIを使って、ブラウザの画面を映し、それを画像化することができそう? ただし画像キャプチャAPI自体はモバイル端末には対応していない。

既存の画像生成アプリケーションをWASMにコンパイルしてブラウザ上で動かす

ぜんぜん調査できていないけど、たしかにそういう手法もありそう!!