React Server Components（以下、RSC）はサーバ立てなくても使えるよ、という記事を読んで、最近やってたことに関連する領域（つまり、興味あることだけ）を把握した。

• 脆弱性が怖い人でもRSCを活用する方法
• サーバーの無いReactフレームワークFUNSTACK Static

RSCの世界ではデフォルトがサーバコンポーネントで、HTMLのレンダリングが（で合ってる？）ブラウザ上ではない環境、つまり「サーバ」で起こる。ブラウザはやることが減ってパフォーマンスに効くし、さらにはレンダリングが依存するデータ取得もブラウザ外に出せる。部分的に外に出せる。外に出せない部分は全部クライアントコンポーネントで、今まで通りのReact。Reactの世界の内部にそういう境界がある。

この境界はコンポーネントの親子関係（レンダーツリー）ではなく、それを定義する（ES Module的な意味での）モジュールの依存関係のツリー上にあるのが混乱ポイントになりそう。クライアントコンポーネントが依存つまりimportしてるものは全てクライアントコンポーネントになる。だから、（依存されうる）コンポーネント側の定義を見ても、それがサーバコンポーネントかどうかは確定しない（場合がある）。このあたりの話が丁寧に書かれてるのが'use client'のページなのがちょっと不思議な感じ。

実行環境としてのブラウザが動的にやっている依存解決の位置に境界があるってことなんだろうけど、どっちなのかコンポーネント定義のファイル自身が定義していてエディタで色が変わる、ぐらいの分かりやすさがほしくなってしまう。React Server Components自体が微妙な表現かもしれず、RSCという新しい仕組みの中にサーバコンポーネントとクライアントコンポーネントがある、という区分けになってるっぽい。「'use client' は React Server Components 用の機能です」とか言われて混乱する。そもそも非ブラウザ環境を「サーバ」と呼ぶのも変だけど、それは主なターゲットとなるユースケースなんだろうね。

実態としてはこんな感じ？

• React Rendering Environment Separation
  • Browser Components
  • Inbound Components

いずれにせよ、最適化のための戦略は難しそう。勝手に良い感じにやっとくのを超えて、ユーザに協力してもらうためにはどうしたらいいか、という話ね。かっこついてたほうがいいかもしれない。

ある世界の内部に異なる環境がある、という意味での面白さだと、Next.jsもそういう面がある。データ取得の静的なもの（ビルド時）と動的なもの（リクエスト時）が1つのページ定義の1つのファイルの中に存在していて、かつ、そのデータを渡す先のReact（のコンポーネント）がいる。この混ざり方、繋がり方が面白くて興味を持ったのが昔々。

で、React Server Componentsにとっての「サーバ」というのはブラウザの外部のことなので、CIサーバ上でも良いし、ローカルマシン上でも良い、というのが「サーバ立てなくても使えるよ」という冒頭の話。「サーバ立てなくても使えるよ」というだけなら、Next.jsのstatic exportsもそうだし、このサイトの出力に使っているrenderToStaticMarkupも同じ。違うのは、Reactの世界の内部に境界を持てるかどうか。Reactが動くCSRなSPAの一部を事前にレンダリングしておけるのがサーバコンポーネント。一部と言わずほぼ全部にしてもいい。（もちろんリクエスト時に一部をサーバサイドでレンダリングできて、それが表向きのアピールポイントなはず。）

このサイトとしてはSPAをやりたいわけではないからReactが動く必要はなく、JSXを扱えるメジャーなレンダリングシステムとしてReactとその関連技術を使い続けているわけだけど、ありうる選択肢として違いが見えて楽しかった。まだちゃんと分かってないところの理解にも繋がりそう。

今年はライブと遠征の本数を減らそうと思っていて（というか、さすがに減るのは間違いないんだけど）、そうすると運動量が減りそうだなという心配があって、意識的に散歩に出るようにしている。ちなみに1日の平均歩数は、2024年が3311歩、2025年が8686歩、2026年が7264歩。昨年の1月が4612歩だということを考えると、1年のスタートしてはまずまず？せっかくだから数値目標を立てようか。2026年は9000歩を目指します。

昨日言及してたLive Reload的なものを今日は実装した。開発用のリソースサーバは昨日node:httpで書いてたからその続き。nodeのfs.watchでファイル監視して、変更があったらビルドしてServer-Sent Eventsでブラウザに通知して、というのが大枠。fs.watchはOS毎に違いがあるみたいで、ちゃんとやるのは大変そう。参考にしたのは以下。

• Live Reloading From Scratch in Node.JS
• Server-Sent EventsとWebSocketの簡単な実装例

これを書いてる途中で思い出してサーバ起動したし、普段は必要無いかもしれない。でもこのサイトに関しては見えない部分を弄っている時間のほうが圧倒的に長いもんなあ。

こうやって日付入りの記事を2日連続で書いていて偉大ではあるんだけど、サイトのメンテ自体は2026年はずっとやっていて、Next.jsから脱却もLive Reloadもその流れ。他に分かりやすいのだと、JavaScriptからTypeScriptしたのは先週だったらしい。あとはCSSを書き換えてdark mode対応にしたり。CSSはgrid、特にgrid-templateとても良い。

そして今日はReact Server Componentsについて完全に理解したから明日あたり何か書いてみる。

元々このサイトはNext.jsで生成される静的サイトで、以下のようになっていた。

• Next.jsによるStatic Site Generation
  • Next.jsのライフサイクル
    • getStaticPaths
      • [yyyy]_[mm][dd].jsなファイルの一覧を取得
        • 中身はexport default { title: string, content: HTML }なJSX（としてHTMLを持つJSオブジェクト）
        • ただし、ここでは中身は読まず、nodeのfs.readdirでファイル名のみ集める
      • Next.jsのDynamic Routesでposts/[yyyy]/[mm]/[dd]なパス（とページ）を生成
    • getStaticProps
      • [yyyy]_[mm][dd].jsなファイルの一覧を取得（同上）
      • 各ファイルの情報をシリアライズ可能なJSオブジェクトとして用意する（つまりJSX等を渡せない）
    • Next.jsのpage / Reactのライフサイクル
      • JSXとしてHTMLを持つ各ファイルをdynamic importしてページを作る

いろいろと改善はしたけど、2022/04/23 JSX as dataと2021/01/02 Next.jsとPHPと私で書いたときとほぼ同じ。App Routerには移行せずPage Routerのまま。十分楽しんだし、そろそろNext.jsから離れるか、ということで書き換えて、以下のようになった。

• nodeで実行
  • tscでJSXと.tsをESモジュールに変換
    • [yyyy]_[mm][dd].jsなファイルの一覧を取得
    • JSXとしてHTMLを持つ各ファイルをdynamic importする
    • renderToStaticMarkupで静的なHTMLを出力する
      • Reactでページを作る

実行順じゃなくて依存ツリー（？）なので注意。Next.jsのライフサイクルから解放された結果、JSX（を含むJSオブジェクト）のdynamic importを早めに行えるようになり、Reactのライフサイクル内では非同期実行を含まなくなった。あれ？（tscのコンパイル時にはdynamic importは実行されてないのに）コンパイル後のESモジュールがJSXをimportできるのは何故なんだろう。何か勘違いがありそう。ちなみに、renderToStaticMarkupはレガシーなAPIらしく、prerenderToNodeStreamだとサスペンスの解決まで待てるから非同期処理も含められて、かつ、「クライアントで React をまったく実行したくない場合」としてhydrationしない場合への言及もあるから、たぶん移行できるはず。そのうちやる。

HTMLで書きたいが、そのままでは辛い。だからJSX。Reactじゃなくていいのかもしれないけど、そこで道を踏み外すのは辛そうだし十分に好きだからReact。そして静的サイトが欲しくて、かつ、面白そうだったからNext.js。という流れの最後を差し替えたのが今回。いろいろと整理した後だったから割とすんなり。動いていないはずのCSSがNext.js版では動いていることが分かり、謎が解けないから仕方なく正しいものに直したりはした。あとTypeScript関連でも似たような謎があった気がする。

Live Reload的なものが失われたから、次はそれをどうにかしたい。そういうライブラリを使えばいいんだけど、依存を減らしたいから自分で書きたくて、Server-Sent Eventsを使ってどうにかする。開発用のサーバを書く感じ。最終的にこの部分はSwiftで書いてもいいかもなあ。

仕事を辞めて、ライブに行って、旅行に行って、ライブに行って、結婚して、引越して、ライブに行って、という感じ。

ライブは50本以上。宿泊も50泊以上。関東と地元を除くと、北海道、宮城、金沢、富山、長野、愛知、京都、奈良、大阪、岡山、広島、香川、福岡。早めに予定を確定できるし、平日も選べるし、そんなわけで航空券も宿泊費もかなり安め。2024年もこれが不可能ではない働き方をしてたような気もするけど、まあ気力が足りなかったよね。1日平均歩数が2.5倍ぐらいに増えて、体力も増えたはず。

そして上記の流れで友達が増え、シュッと結婚。全国各地で（というほどの数ではないけど）お祝いしてもらって面白かった。この先どうやって生きてくかを考えるつもりが慌ただしく何も考えないままの1年で、人生の半分ぐらいはもう埋まっちゃったね。これで可能性が狭まったのか広がったのか、簡単になったのか難しくなったのか。ともあれ楽しく暮らしています。

あと、4月にtry! Swift Tokyo 2025にスタッフとして初参加。家から会場まあまあ近くて知ってるし、今なら時間の余裕あるし、これ以上無い良い機会だな、と。（とはいえ実際にはスケジュール上は無職の俺がいちばん忙しいということが多々あり、このときはちょうど空いてたのだった。）こういうテック系イベントスタッフのは初めてだったけど、学祭のライブ準備とかを思い出して楽しかった。役割の都合上、セッションもいくつか見れて、（たしかUI系のセッションで見かけた）walk the path of imperfectionという言葉が印象に残っている。それとは別に、スピーカーの人と話してたら盛り上がって、スタッフじゃなかったら声かけられなかっただろうから「これも一つの貢献だな〜」とか考えてたら撤収作業に乗り遅れて、結果として打ち上げの受付を担当することになり、これもまた楽しい縁ができたりした。

そう、縁だね。いろんなところへ赴いて、人やら場所やら濃淡様々な縁ができて、そういうこと自体に価値を認める気には（20年以上前から）ならないままだけど、今の自分にはちょうど合ってたのかもしれないね。2025年の漢字はやっぱり「旅」ということで。

• スティーヴン・ウルフラム『ChatGPTの頭の中』
• 雁屋優『マイノリティの「つながらない権利」』
• 中野珠実『顔に取り憑かれた脳』
• 高樹のぶ子『伊勢物語在原業平 恋と誠』
• 井奥陽子『近代美学入門』
• 津川友介『世界一シンプルで科学的に証明された究極の食事』
• 熊野純彦『カント　美と倫理とのはざまで』
• 鬼龍院翔『超！簡単なステージ論　舞台に上がるすべての人が使える72の大ワザ／小ワザ／反則ワザ』
• 劉慈欣『三体０【ゼロ】　球状閃電』
• 児玉聡『功利主義入門　──はじめての倫理学』
• 重田園江『社会契約論　──ホッブズ、ヒューム、ルソー、ロールズ』

だいたい年初から。だいぶ前に読み始めて放置していたものも含む。Kindleと図書館。

ここ数ヶ月いろんなものを捨てていて、今月はついに紙の本にも手をつけ始めた。どうせ読まないし、部屋を片付けたいからね。それとは別に、今年は美術展の図録とか画集とか増えた。そいつらを本棚に並べたい。

近況としては色々あるけど後日に回すとして、10のサポート終了を前にWindowsを処分したことだけ先に報告しておく。だから久しぶりにサイトを更新しようとしてﾅﾆﾓﾜｶﾗﾝになったけど、GitLabに接続するためにssh鍵作って、nvmとnodeをインストールしてnpm installしただけだった。デプロイはCIだし。READMEに何も書いてないの酷い！と思ったけど、各種設定ファイルに全部書いてあった。あ、設定ファイル見ろ、って書いとけばいいのか。諸々を更新したほうがいいとは思う。

比較級です。前回から諸々の数値が改善していて、体重を10kg減らしました。目標のBMI22まであと2kgぐらい。

何をやっているかというと、栄養成分を計算してターゲットの範囲に収めるよう頑張っている。本当に頑張っているのかというと謎で、生活というものを頑張るためのゲーミフィケーションとして機能するプログラムをちょうど今の俺なら動かせたみたいな雰囲気。近日中にもうちょっと書いてみる予定。あすけんは最高というわけではないけど、嫌な感じがしないのが良い。

新コロ、旧コロ、ライノ、花粉症など様々な疑惑もそれぞれ通過して、そろそろ本格的に体力をつけていきたい今日この頃。時期は前後するけど、エアロバイクを借りました。選ぶの難しそうだから買わずにレンティオで。

昨年は色々と厳しいことがあり、無事っぽいっだけで上出来という状況でした。あんまり無事ではありません。今年も引き続き、生き延びることにフォーカスしていこうと思います。健康診断の結果も悪かったから、心身ともに健康になるのを目標というか目的に過ごしたいですね。

11月ぐらいからやや元気が出てきて、12月は仙台、名古屋と2週連続でライブ遠征をやりました。思い立った頃には都内はチケット残ってなかったのと、遠くに行きたい気もしたので。新幹線あんまり乗らないから初めてのことも結構あり、JR東西の違いとかもあって滅茶苦茶難しかった。充電できない席があるの知らなくてびっくりしたよ。

このブログもどきの更新頻度も上げていきたいね。

東京に戻る飛行機が離陸したあたりで、身内に訃報が届いていたらしい。

GWの帰省中に祖母が緊急手術となり、それ自体は命に関わるものではなかったけれど、東京に戻るのを数日遅らせた。そして、医者の言葉を聞くことにした。まず、聞く価値という意味で、想定以上の重みがあった。手術箇所の経過については良好で、ただし、手術そのものがダメージになっている、という翌朝の話も。

だから、羽田から帰る電車の中で訃報をもらったとき、一応は心の準備ができてたと思う。どう死んだのか聞けないままになっている数件と比べると、大きな違いだ。でもこれが心の何を準備してたかというと、よく分からない。いつも葬式ではいちばん泣いていそうな自分が今回はほとんど泣かなかった。なのに、はっきりと分かるほど、ダメージを受けて、弱っている。知るべきことを知ることで、傷を深める準備をしてしまったのかもしれない。そういう意味でも、想定以上の重みがあった。

おそらく俺は当事者になろうとしたのだと思う。当事者であるというのは（少なくとも俺にとって）こういうことかもしれないし、たかが数日の影響ならまたちょっと違うのかもしれない。さらには、そんなこと全然関係無く、もうちょっと手前から予め弱っていただけかもしれない。何にせよ、弱っております、はい。

ところで、同日に亡くなったイアン・ハッキングが何故か祖母に顔ちょっと似てて、せっかくなので（？）今年の後半からちょっと読んでみようかなという気分になっている。前世で『The Emergence of Probability』を読んだ記憶があるから、この辺りからかなあ。原著だとKindleあるけど、邦訳も値段一緒だ。そして図書館に無い。んー、どうしようかな。

弱っていてパワー不足の中、最近はNext.jsのApp Routerのドキュメントをちょびちょび読んでいる。恩恵を受ける予定は無いけど、体感目的で移行したいなあ。でも急がなくてもいいか。

「そろそろ知っておいたほうがいいなシリーズ第1弾」の第一歩として、『コンサルティング会社　完全サバイバルマニュアル』を読んだ。面白く、予想より真面目というか真摯な本。

まず、俺がどういう読者なのかというと、コンサルとの業務的な接触が無く、ふわっとしてゴツゴツした幻 のような存在感を感じている。「こんな資料作ってたらコンサルだったら詰められてそう」「なぜ我々はコンサルでもないのにこんなことを……」のように、概念上の参照点として機能している。どこかから得てきた偏見の塊。

特に事前の印象が覆ることはなく、より補強された感じ。人月商売とかプロジェクトマネジメントとか決裁権者を意識したりとか、割と身近な枠組みに全てがぎゅうぎゅうに詰め込まれている感じで、そこからはみ出た部分も含めて理解しやすかった。その名の通りマニュアルになってはいないとしても、とても丁寧に書かれている。

例えば、ワインバーグとか？を読んでると「そう整理してそう言って皆に通じるなら苦労しないわけよ」みたいな悲しさがあるんだけど、言われる側と言う側の双方で「言って通じない」という状況を飲み込んできた経験と、それでもプロジェクトを進め、それでも生き残ってもらうために手を尽くそうとする意志が本書を書かせている。秘訣があるというよりは、単に全力で向き合うしかなく、そのための例示がある。愛だよな、これ。

愛が良いものかどうかは置いとくとしても、長時間労働が解消された後に成立させることが可能な形態なのかは怪しそう。だから書かれているのだろうけど。そして、新卒とかに伝わるのかどうかは疑問だけど、それをサポートすべき立場の人には伝わるはずで、それこそ長時間労働を前提とした環境で無意識に成立していたものを別の形で実現させるためには良い出発点になりそう。ほんまか？ちょっと適当なことを言っていますが、そう言いたくなる感嘆があります。

このあたり、自他を変化させられることへの希望と辛抱があり、これがコンサル（業界？）への新しい印象として加わった。もちろん無理も感じるのだけど、だから「サバイバル」という語を掲げているわけで、そこが誠実で良い。

一つ気になったのは、事業会社の社長は孤独だからコンサルが大局的な戦略の相談相手になれると良いみたいな話があって、業態の理想形の一つを示す素敵な話にも見えるけど、そういう相手が社内にいないこと自体が解決すべき問題のようにも思える。寄り添っている場合なの？って。もちろん実際には俺自身でツッコミを入れられる。事業会社に飛び込んでいく人もいっぱいいるだろうし、コンサルとして経験を積み続けることで言えるようになることもあるだろうし、コンサル側の社内リソースを使えたほうがいいだろうし。でも気になっちゃう。

なんで気になるかっていうのは結局、「なんでコンサル続けてるの？」ってことかもなあ。「そこに情熱があるのねー」「業態の成立自体に関与してるわけじゃないもんね」とかで普通は納得できるはずなんだけど、それ以上の答えを求めてしまうっぽい。おそらく、書かれてることではなく、書かれていないことが気になっている。

たぶん関連する話として、「俺は企業というものにここまで興味持てないな～」という感想があった。大企業の仕組みとか実態は、この文明の偉大な成果であって、現代人が興味を持ってしかるべき対象であるはずだ。そこに興味を持てない門外漢からすると、大きな謎になるんだろうね。そして俺は他人の興味そのものには興味がある。もちろん人それぞれの執着はあるだろうけど、本書としては「まず生き残れ、話はそれからだ」という答えになりそう。

もう何冊かコンサル本を読んでみて、彼らの技術と精神と生態を学んでみる予定。

人生を懸けて何かに取り組むとかは不向きだということが分かっているわけですが、そして、永遠に生きるかのように生きていきたいわけですが、とはいえ人生が短いことも分かっており、そして、「こんなことに俺の人生使いたくない」みたいな気持ちは残念ながら生まれるわけで、どうしよう、困ったね。

これはひょっとして中年ということですか。まあそういうのもある。

（と、書きかけてたのが残ってたので放流。何を考えてたのかは覚えてないけど、人々に一般的な現象が自分に生じる可能性もあるよね、ということに思い至って止まったはず。自分を理解することと他人を理解することをだいぶ別物扱いしてきたけど、使える技術には共通のものもあるわね。それはそう）

1か月間隔で2親等を2人続けて亡くしたので、いわゆる喪中になっています。とはいえ特に何か生活を変える予定も無く、そもそも行く予定の無い初詣に行かないぐらいかなあ。個としての振る舞いはほとんどどうでもよく思っているんだけど、神道への気遣いというか、そこはちょっとだけ。公衆浴場みたいなもんだからね。

念仏を聞きながら思ったのは、弔い方や故人の敬い方が全然何も分からず、お坊さんに助けてもらってるんだなあ、って。これは現代人に限らないかも。そうやって最低限の分だけは皆と一緒に悼むことはできても、自分がどうやって受け止めるかはやっぱり分からないよね。気を散らす物事は無限にあるはずとはいえ。

ちょっとしたミスで事故になるような職業も生活もやってないのだからいつも通りぼんやりしてればいいという話もあり、いつも通りぼんやりしています。

年末だし、近いうちに年末っぽいこと書こうかな。

動いてるコードへのリスペクトもディスリスペクトもずーっとピンと来てなくて。半分以上Appleの影響でモバイルアプリの世界は、「動く」と「壊れる」とプログラミングがそれぞれ近すぎて、動いたから何なの、壊れたから何なの、みたいな感じになっているのかもしれない。人間で言うと、働いている人が偉いっていう側面があるとして～hypothetically～、そんなのどうでもいいでしょ。不安定な環境の中へ投入されて動いたり動かなくなったりするものは、等しく慈しんで憎んでいきましょう。

前回は「壊す」の話だけど、今回は「壊れる」の話なのか。作ることについて考えるための重要なポイントになるのかなあ。

ところで、妙な複雑さをアピールしてくるゲームに対して俺が「人生でやれ」と言うように、人間に向いてないからソフトウェアやってるつもりの人の一部は「人生でやれ」と言いそう。

2年ぐらい前に、嫌いなタイプの人間について考えながら人間を分類してた。

まず、公正世界信念みたいなのを持っちゃってるとなかなか厳しいという話がある。

1. 俺は正しく努力したから正しく成果を得られた
2. だからお前もできるはず

この2段階目によって有害な感じになってしまうんだけど、それは置いておく。有害なものへの嫌悪から「有害だから」を取り除いて考えるのは難しいし、いわゆる（嫌悪以外の）負の感情を喚起させられて消耗することになる。

一般には、嫌悪自体が負の感情を喚起させてアレなんだろうけど、自分はあんまりそういうことはなく、むしろ嫌うだけで済むものは積極的に嫌っていくべきで、「何が好きかより何が嫌いかで自分を語れよ」と思っている。好きなものについて語るのは困難だし、逃れようのない嫌悪みたいな感情との付き合い方がうまくなれたほうが生きやすい。「嫌悪」という言葉に含まれる「悪」のほうについてもだいたい同じように考えてはいるが、ここでは「嫌」だけの意味で「嫌悪」という言葉を使う。悪いことをする人間だけど嫌いじゃないことあるよね。無いと生きづらそう。人間は悪いことをするので。閑話休題。

さて、件の2段階目を発動させず、かつ、自分が嫌っているタイプが存在していて、そのあたりを考えていたら分類してしまっていたという話が本題。これはおそらく、良くも悪くも自分が興味を持つ人間を分類していて、興味を持てない人間について考えるのは難しそうだね。そしてもちろん（？）グラデーションがある。そういうときは「分類」と言わないほうが良さそうな気もする。後で考える。

• 世界を攻略しようとしている人間
• 世界を作ろうとしている（あるいは否応なくその制作にぶちこまれていると認識している）人間
• 世界を理解しようとしている人間
• 世界で遊ぼうとしている人間

攻略しようとしている人間だけは世界を壊したがらない、という形の理解が生まれたのが面白かった。壊さなくてもいいんだけど、ひとは作るために壊すし、理解するために壊すし、壊して遊ぶ。世界は完璧ではなく、単純なアドオンとして成立する改善は稀だから、世界の全てを保存しようとするとすれば現状肯定への偏りが大きいことになる。さすがに諸々から目を背けすぎでは、という偏見が生まれる。そういうのを前提に、攻略対象だから壊したがらないんだね、と思わされるあたりで嫌いになってる模様。

自分はどうかというと、理解しようとしている人間で、遊ぼうとしている側に寄っているものの、作ろうとしている人間の半分ぐらいを見上げている。ちなみに、作ろうとしている人間について考えようとして失敗したのが今日の午前で、午後は頭を整理するためにこれを書いている。

2年前に考えたことの続きをちょっとだけ進めると、ここから抜け落ちてるものというか、まずほとんどの人間は世界じゃなく個々の人間を相手にしていて、そのスタイルこそが生き方の柱になってるかもしれない。まあでも、公正世界信念に絡めとられるのは個々の人間の相手しすぎだからでしょ、みたいな悪口が咄嗟に出てきたので反省している。そんな雑なことを言ってはいけない。

たぶんいつも以上に「考えるのが困難なことは考えない」みたいな話が出てきているけど、それはこれが考えるために書かれた文章ではなく、考えたことを書いている文章だからだろうなあ。後者のスタイルで前者をやろうとして午前中は失敗したような気がする。俺はこれ意図的に使い分けられるのか？

このサイトはnext exportされた静的ファイルのSPAで、各記事はファイル名が日付のJSXになってる。もしかすると「JSXをvalueとしてもつJavaScriptオブジェクト」という表現のほうが正しいかも。ここでは区別しない。

例えばsrc/2021/2021_0101.jsはこんな感じ。
（拡張子が.jsなのはNext.jsが賢いのに任せているだけで、拡張子を.jsxにしたくない派というわけでもない。）

export default {
    title: '新年',
    content: (
        <p>
            あけましておめでとうございます。<br/>
            CSS何も分からん。
        </p>
    )
}

ブログとか記事とかそういうのはデータとして扱いづらくて、どうするのがいいか悩ましいわけ。今、すごく雑なことを言っています。データとして扱いやすくすると、コンテンツとしての表現力が下がるか面倒になりそう。MDXという解決もあるけど、全然気に入らず。次に、markdownをそのままhtmlに変換するのはどうかと考えたら、

• markdownを書きたくない
• htmlをそのまま書きたい

という気持ちが出て、前者はよく分からないけど放置して、後者に向き合うことにした。そしたら目の前にJSXがあったので採用して、紆余曲折ありつつ、最近やっと当初の目論見がだいたい達成された雰囲気になってきてる。それでもデータフォーマットとしては名前付きexportがexport defaultになったぐらいで他は変わらず。

getStaticPropsとかgetStaticPathsであればnodeのfsが普通に使えるので、記事ファイル名の一覧（2021_0101.jsなど）を取得して、dynamic importで読み込んだJSXをごにょごにょして、サイトの組み立てと表示に使っている。

dynamic importを使って静的なSPAを出力してるのが楽しいところで、混乱するところ。実際にdynamic importしているのはgetStaticなんとかではなく各ページのコンポーネントのレンダリング時（つまりNext.jsではなくReactのライフサイクル内）で、グローバルに1つのPromiseが全記事をまとめてimportしている。このPromiseの裏には上述の「記事ファイル名の一覧」のキャッシュがあって、これは当然グローバルに1つなのだけど、getStaticなんとかのときと、ページコンポーネントがレンダリングされるときでは実行環境が違っていて、前者でキャッシュされていても後者で再取得される。そりゃそうかと思ったり、同じプロセスで実行できないんだっけと考えたり、まだ混乱は残ってるんだけど楽しい。

とはいえ現在はgetStaticPropsで取得したファイル名の一覧をページコンポーネントに渡していて、一度しか取得されない実装になっている。先に取得しておけばいいもんね。この「先に取得しておけばいいもんね」が曲者で、ファイル名の一覧はStringの配列だから渡せるんだけど、記事そのものはJSXなのでページコンポーネントに渡せない。シリアライズできないって理解でいいのかな。JSXはデータじゃないのだ。それはそう。

フェーズの境界を実用のためにゴリッと繋げている通路こそがNext.jsに興味を持った理由なので、このあたりで混乱したり納得したりできて僕は幸せです。

小学生のときに親の実家から持ってきた百科事典に三平方の定理とその証明とか載ってて、具体的なエピソードとして覚えてるのはそれが最古かなあ。全10数冊のうち5冊ぐらいだけ持ってきていて、そこで数学のやつを選ぶぐらいにはその前から算数も好きだったみたい。

中学では「一切テスト勉強しない」という縛りプレイをやっていて、それは数学に対して誠実さを示すためだったんだけど、先生に言うと怒られそうなのでこのまま墓場までもっていきます。

高校に入る頃には面接で「得意な科目というのは特にありませんが、数学が好きです」と言うぐらいには自覚的に好きになってたんだけど、高2ぐらいで教科としての数学に興味を失って、より具体的には教科書がつまらなくて、高3からは文系寄りの科目選択。それでも数学自体は好きだから授業は楽しいほうだったかな。地学でlogを使った計算があって「へー」と思いつつも、数学が役に立っても嬉しくなくて、地学へのLoveが加速するだけだったね。

高2から高3に上がる3～5月に初めて、受験勉強と思って数学だけ1日1時間ぐらいずつ勉強したら、毎月続けて熱を出すことにより知恵熱の存在証明に成功。それまで普通の風邪とか引いたことなかったから、「熱ある」ってだけで親が心配するのにびっくりした記憶がある。インフルとかだと、こっちはそれどころじゃないからね。センターは満点取りにいったのに全然分からず、その割に点数はそんなに悪くなくて何とかなった。2次の前期試験は実質的に記念受験のような有様だったけど、数学だけはまともに解けたから、あれは残りの受験期の精神の安定に効いたと思う。

そんなこんなで大学では数学を全くやってない。妹が受験生の正月に何かの問題を教えてくれと言われて、何も教えずに朝まで同じ部屋で別々に問題を解いてたときに、式の望ましい展開ができなくて、その頃から「好きだけど才能が無い」というレッテルを自分に貼るようになった。でも、その後しばらく数学やってないね。10年ぐらい。

30代からはソフトウェアエンジニアをやってるせいで数学に近づくことはある。あるが、しかし。ちょっと状況が変わったのは、TaPLの第2章の「数学的準備」というのがすごく良くて。それで数学への興味が正式に戻ってきたというか。「何も変わってねーじゃねーか」と言いたくなる程度には全然本を読めない現状について、校長先生からお話があります。

何も知らないなー、と。一通り知っときたいね。一通りって何だろ。ということで、興味持てなさそうな線形代数を最近ちょっと勉強していて、興味持てなさそうなまま毎日寝落ちしてる。

この3か月は久しぶりにまともに働いた。ほんと疲れたよ。働くのは大変。証明は読者への演習問題としない。プログラミングっぽいことに話を絞ると、なんと、F#とRuby on Railsをやりました＆やってます。びっくりだね。

ぷしゃーは、だいたいOCamlだからだいたい分かったんだけど、コンピューテーション式が難しかった。というか、まだちゃんと分かってないのよね。「字面的に、このへんがそうね、ここでビルダーが定義されていて……どうなってるのこれ……」ぐらいの理解。あとパターンマッチもすごくて、何だよアクティブパターンって。何だよ部分的なアクティブパターンって。好き（はーと）。俺は楽しくていいんだけど、ML系を知らないとハードルが高すぎるからギョム的には困っている。プロジェクト設定が悪い可能性もあるけど、Visual Studio for Macがポンコツ感を出していて、MSさん、これ風評的に大丈夫なんですか、みたいな心配をしてた。MSの風評といえば、機械翻訳ドキュメントは事前の認識と偏見通りに酷く、これもギョム的には困りごと。

れーるずは、なんというか、かわいいわね。ときどき「そんなん知らないと分からねーよ」と思いつつ、それでも理不尽な感じはあんまりなく、何かしらの優しさを感じる。見てるのが巨大なプロジェクトなので規模と歴史で大変になってる部分はあれど、むしろここまで頑張れるんだなー、と。単に立派な企業の立派なエンジニアたちにメンテされてきた立派なコードだからでは、という疑惑もある。E2Eテストを書いたのは初めてな気がするけど、rspecもかわいげがあり、この自由度が良くも悪くも強い、という印象。かわいさとは何か。今後の課題とします。でも、Active Recordをほとんど相手してないので、まだまだこれから。

どちらも最高のタイミングで出会えた気になってるんだけど、いつ出会ってもそんなこと言ってそう。

8月にGoの1.17が出て、関数のcalling conventionが引数と返り値についてスタックベースからレジスタベースに変わりましたね。というわけで予定通りABI変更のプロポーザルを読もうかな、と思ったらその冒頭に、

This will remain backwards compatible with existing assembly code that assumes Go’s current stack-based calling convention through Go’s multiple ABI mechanism.

なんじゃそりゃー、というわけで、じゃあまずそっちのプロポーザルを読まなきゃ＆読みました、というのが今回のお話。タイトルがProposal: Create an undefined internal calling conventionで、ますます良くわからない。いろいろ寄り道しながら1周半ぐらい読んだら分かってきた気がするので整理する。

Disclaimer

• ABI変更のプロポーザルを先に読んだほうが理解には効きそう
• 変更前後のABIをほとんど分かってない
• Goのアセンブリを分かっていない
• そもそもGoを書いたことがない

Context

• Go 1.11までのcalling conventionはシンプルだけど非効率
• Go 1系で約束されている後方互換にcalling conventionは含まれない
• calling conventionを壊すとGoアセンブリで書かれたプログラムが壊れる
• アセンブリは少ないけど暗号系とか重要なライブラリの中心になっている
• だから壊せないし、移行期間を用意しても期待できないから、そのまま動いてほしい

凡例

• A: アセンブリで書かれたプログラム
• G: 普通のGoで書かれたプログラム

たぶん、こんな感じ

• 既存のABIをABI0とする
• 新しいコンパイラが内部的に扱うABIをABIInternalとする
• この2つは一致しているところから始まって、後者は変化していく
  • だからan undefined internal calling convention
• native implementation
  • AはABI0で書かれている
  • Gは全関数でABIInternal向けのエントリーポイントを用意する
• ABI Wrapper
  • Aから呼ばれるGの関数にはABI0向けのエントリーポイントも用意する
  • Gから呼ばれるAの関数にはABIInternal向けのエントリーポイントも用意する
• ABIInternalを変化させて満足したら、そのABIをABI1とする
• 新しいABIを公布する際には、アセンブリでABIを指定できるようにする。

感想

実際どういうアセンブリ（コンパイル結果）になるんだろ。
例えば、こんな感じ？（Goのアセンブリの文法は一切反映させてない）

新しい関数A_for_ABIInternal:
レジスタから引数を取り出して使う
いろいろやる
レジスタに返り値を詰める

新しい関数A_for_ABI0:
スタックから引数を取り出して、レジスタに入れる
call 新しい関数A_for_ABIInternal
レジスタから返り値を取り出して、スタックに積む

このプロポーザルの大前提として、Goにはdynamic linkが無くてコンパイル時に静的に解決できる、というのがありそうだけど、どうなんだろ。真偽についても影響についてもそんなに自信は無い。dynamic linkありでABIを固定させない場合、ABIが定まる前の時代のSwiftみたいにバイナリごとにruntime埋め込みが必要になるのかな。ただし、あれはiOSが持ってるSwift標準ライブラリとのブリッジだけのはず。（それ以外はコンパイル時に解決というか、同じコンパイラ（つまり同じABI）でビルドしたものしか扱えなくて、実質的にソースからビルドするしかない世界だった。）

Swiftのこと考えてたら気づいたけど、このプロポーザルは、新しいABIを不定のまま処理系をリリースし続けられるってのもポイントなのか。というか、そういうタイトルになってるね。レジスタベースのcalling conventionっていうゴールに惑わされてた。

dynamic linkではなさそうけど、今はBinary-Only Packagesというのもあるみたいで、これはGoアセンブリで書かれたプログラムと同じ扱いになるのかな。

6月前半から7月末まで読んでたっぽい。時間かかったのは、睡眠のお供だからというより、たくさん楽しい寄り道をしてたせい。買ったのはずいぶんと前で、積んでる間に版が変わってPDFをDLし直して、そこからさらに1年以上積んである熟成品。

Goは何回か文法ぐらいは一通り勉強してるはずだけど覚えが悪悪で、「え、そんな言語だっけ？」「A Tour of Goに書いてあるやんけ」を定期的に繰り返していて、書かない言語、興味の無い言語はまあ仕方ない。ただ、この本を読んだら、言語処理系としてのGoはだいぶ好きになってきた。書きたくなってきたかは微妙。

どうもシステムプログラミングというのは、やりたくなるかは置いといて、プログラミング言語とOSの機能の間にある自分の好奇心を満たしてくれるジャンルらしい。おそらく、その間にある1トピックである言語処理系が自分の興味のど真ん中で、そのへんも含めて広く主題になってるのが効いている。特にこの本が面白いのは、LinuxだけじゃなくWindowsもmacOSも（その他のUNIXも、さらに別のOSも）ずっとターゲットに入っていることで、へー、なるほどー、うはー、みたいな感じになりつつ、よく分からないこともピンときやすくなっている。

以下、本の内容が発端になって俺が気になった話。本の内容が気になる人は目次を眺めましょう。

Goがlibcを使わずに標準ライブラリの中にシステムコールラッパーを持っているのは、Goへの偏見に合致していて、まあそうでしょう、という感じ。WindowsだけはMSが仕様を公開していないから各種dllを標準ライブラリが読み込んでいる、というのは、なるほどねー。あれ、でもAppleってシステムコールのABIを固定したくないから直接システムコールを呼ばせたくないんじゃなかったっけ？と思って「mac syscalls dylib」でググったら、Appleのドキュメントを再発見できなかったものの、関連するgoのissueを見つけた。（探してたAppleのドキュメントへのリンク Statically linked binaries on Mac OS X もそこにあった。）そのissueの冒頭に

As I understand it, Go currently has its own syscall wrappers for Darwin. This is explicitly against what Apple recommends, precisely because they're not willing to commit to a particular syscall ABI.

とあり、その後の議論はちゃんと読んでないけど、最終的にGoの1.12でlibSystem.dylibが使われるようになってた。

書籍内では数ページ後の、POSIX的にはポータビリティのためにABIじゃなくCの関数に依存したほうがいいけどGoは自前でシステムコール呼ぶことにした、みたいな文脈の註で余談として、macOS用にはシステムコールを直接呼ばなくした変更に触れられてはいた。なんでそんなところの註で……。まあ自分でググって楽しい思いをしたからいいんだけどさ。

もう1つ気になったのはメモリの話で、goroutineは4KBのスタックを使うだけだから軽量ですよ、という話。書籍から離れると、元々はGoは関数の呼び出し規約が引数と返り値についてスタックベースで、それをレジスタベースに変えようとしてるという話があり、それってgoroutine実装にも影響しないのかな？と。メモリの話に限らず、goroutineの実装についてはいくつか読んでみたいなー（と思ってたことを書きながら思い出した）。

まずはこのABI変更のProposalを読むところからですかね。対応するissueには今日の時点ではProposal-AcceptedとProposal-FinalCommentPeriodのラベルがあって、さらにはGo 1.17のリリースノートのドラフトには

Go 1.17 implements a new way of passing function arguments and results using registers instead of the stack.

とあるから、年内ぐらいには出たりするのかな。

最後にもう1つの寄り道。muslというlibc実装の話が、メモリ管理のところのコラムで出てきて、

C言語のランタイムのlibcにはいくつもの実装があります。静的リンク専用でコンパクトさがうりのmuslのmalloc()はとてもシンプルでナイーブな実装になっています。その反面、長時間利用ではフラグメントが起きやすいという欠点があります。

という記述があり、この「静的リンク専用」の意味が分からなくて混乱した。muslって静的リンク専用なの？とりあえず、muslにも動的リンク用の.soはあります。で、この「静的リンク専用」の意味はさておき、この流れでlibcその他についていろいろと発見があって楽しかった。具体的な話は別途。こういう広がり、寄り道がたくさんできて楽しい読書でした。

本を読み終わったから何か書こうかと思って、ついでにサイトのリファクタリングを延々やってたら力尽きた。それでも何か書こうとしたけど、うまくいかない。まあいいや、さっさとデプロイして明日にしましょう。

ということで毎日更新を諦める。ちょっと疲れたね。ぼちぼちやっていく。

目標に向かって努力する、というのが可能だとして、目標と自分の距離をどうやって測ればいいんだろうね。それを測れる程度にはレベルを上げないとお話にならないのだろうな。悟空がクリリンと亀仙人の下で修行してたとき、強さというのが分かってなかったはずで、だから亀仙人が必要だった。でもセル戦の前に精神と時の部屋に入ったときはイメージできてたんじゃないかと思う。この比喩が正しいのかどうか。どういう場合に正しいか。

まずは今の自分の強さを測れないといけないのか。でも逆に目標というか、より強いものがあって初めて測れるというのもありそう。基準がいる。強さのインフレは、ある程度は自然な現象のようにも思えてきた。強いやつがいると、強くなれる。度合はともかく、あれができてこれができない、というのはもう少し簡単そう。そこまでのレベルは必要か。体系立った学びというのはそこを後押ししてくれるのかもね。

特定の特殊な敵と戦うためでなければとにかく修行としてやれることは同じかもしれないし、特殊な敵と戦いたがってるかもしれない。

久しぶりに肩が凝って、頭が痛いのが続いている。

なんか最近しゃべってるのが仕事みたいな時間が長かったのと、ペアプログラミングはともかく、ペアドキュメンティングみたいなのは疲れやすいなのかもしれない。プログラミングはなんだかんだで特定のファイルに飛んだり戻ったりがサポートされてるし慣れてるけど、テキストファイルとかだとそれが難しかったり、むしろ構造を作るのが本題だったりして、まがりなりにもコンパイラや実行時の挙動によって成立させられている構造を、より大きく、より複雑に、より良いものに変えていくプログラミングより疲れるのは当たり前かもしれない。文字通りあるいは実質的にgoto文だらけのコードだと、似たような疲れ方になるかもしれない。

ここ数年、「なんかちょっと複雑になりすぎちゃってますね」みたいなことをよく言っていて、もちろんそこを書き換えた結果を見てもらうと分かってもらえるんだけど、出発点として複雑ということを共有するのが難しい。「プログラミングというのは問題を理解する過程そのもの」みたいな話があるけど、あれをやって、これをやって、それもやって、アドホックな足し算を積み重ねて面倒なコードになるまではいいとして、コードを書いた人間の理解がそのコードと一致してしまう、つまり、書き終わると同時に理解の過程が終了してしまうことがあるように見える。成立した理解を変えるのは難しい。「完全に理解した」が覆されるのは、コードの場合はバグが出てからということになる。

問題が出てから考えればいいじゃないか、と言えなくもない。でも、そういう問題と戦っていきたいのかな。そして何より、人間が扱える複雑さには限界がある。目の前の複雑さを減らしていかないと、より複雑なものを扱えるところまでいけないんじゃないかな、って。じぇーくえりに親を殺された人が叫んでいるのと同じ話だとは思う。でも、だからこれはダメ、だからこうしないと、という話は些末な小言として、せいぜい遠吠えになるだけで、届くが伝わらない。エンジニアリングというよりは「より良いマニュファクチュア」を目指そうとするアジテーションになってしまう。とはいえ大きな課題に地道にぶつかり続けると、人間は擦り減っていく。人間には叫びが必要である。

サービスやプロダクトを生み出すやつが偉い、みたいなのはそれはそうかもしれない。まあでも、いろんな志向と思考が合わさったほうが人類は強くなれそうだし、いいじゃないですか。ただ、分断されちゃってそうね。エンジニアではなくプログラマと名乗る人々の一部には、そういう分断を無効化しようとする意図を感じる。

2017年と2018年にgitのGUIクライアントを作ろうと思ってSwingで書いてたんだけど、さっき何にも覚えてなかったからプロジェクト開いて、ついでにbitbucketからGitHubにもってきてpublicにしてきた。思い出してきたことを並べてみる。

• 罫線
• フォーカス
• Object
• メインスレッド

罫線が一級市民という感じに便利ですごい、というのがGUIフレームワークとしてのSwingの特徴なんじゃないか、とほとんど真面目に思ってる。ちなみに、javax.swing.borderというパッケージと、javax.swing.BorderFactoryというクラスがあります。iOSだとUIKitではなくその下のCore Animationに罫線のAPIがあって、Androidはざっくり言うと背景として図を描けてそこに罫線が登場する。モバイルアプリのGUIフレームワークの選択がどういうことなのかは分からないけど、単純に違ってるだけで楽しくなってくる。罫線の存在感があるのは例えばエクセルだけど、GUIというよりは書類の世界が透けて見える。線を引くのは人間で、世界はあんまり縁どられていない。でも、人間は線を引きたい。そして、モバイルでもWebでも2次元のUIを扱っているせいか、「我々は矩形から逃れられないんじゃないか」みたいな気持ちが自分にはずっとある。それならばいっそのこと罫線に屈してしまうのもアリなのかもしれない、とSwingを書きながら考えていた。3Dってなんか怖いよね。つまり現世は怖い。

フォーカスのことをどうして俺たちは忘れてしまえるんだろう。テキスト入力エリアへのフォーカスというのはモバイルでもWebでも意識するのだけど、それ以外では忘れていたかのように、Swingを書いてるとフォーカスのことを「思い出す」という体験が何度かあった。正確に何を思い出していたのかは思い出せない。それが何であれ忘れてしまえるのは、パソコンでもだいたいのアプリケーション全画面で使ってるからでしょ、というのはありそう。Swingというよりデスクトップアプリの話だね。Swingを採用する前はElectronを検討していたんだけど、あれは複数Windowあるのかな？

Objectがインターフェイスに頻出するのは、Swingがジェネリクス以前から存在するからで、歴史を感じて楽しいよ、という話。現実的に困ることは無かったような。これ以外にも同様のレガシーがあったかも。レガシーといえば、JetBrains以外ほとんど誰もSwingを書いていないせいで、いんたーねっとにある皆様の記事が古く、とはいえSwingは変わってないから役に立たないわけじゃないんだけど、サンプルコードのJavaが古くて、そういうところでも歴史探訪で面白かった。さらに、当時の自分はJava7のシンタックスが一部ぎりぎり使えるAndroidの世界から来ていて、最新のJava8で書ける喜びがあり、Swingはもはや人類の歴史の教科書だったと言っても過言ではない。

メインスレッドがUIスレッドじゃないというのが、なんか面白かった。特に、SwingのUIスレッドで動かすRx用のSchedulerを作るためにRxAndroidのコードを参考にしていたときに、違いについて考えてたら楽しくなった。Androidはエントリーポイントがアプリケーション側には現れないけど、メインスレッドがUIスレッドになっている。SwingはUIスレッドはメインスレッドとは別だから自分でmainとかで

SwingUtilities.invokeLater(() -> new Application(Preference.shared()).start());

みたいに呼び出さなきゃいけないし、逆に言うと、CLIプログラムから任意のタイミングでGUIを呼び出せる。はず。Swingの代表的アプリケーションであるIntelliJは、この特性によって何かメリットかデメリットを享受してたりしたら興奮するんだけど、これはJetBrainsに入るしかないか……。

Androidについては真面目に書くか。書けるのか？例えば、Androidの素晴らしいところを挙げてみるとか。

• Support Library
• targetSdkVersion
• Gradle
• Navigation Component

Support Libraryは、OSの機能やOSにバンドルされてる各ライブラリに依存した良い感じのUIやサービスを、OSのバージョン間の差異を吸収しつつ、OSにバンドルされてるものとは別のライブラリとして提供してくれるもの。iOSと違ってシェアが新しいほうへ移る速度が遅いので、いつまでも2系やら4系やらのサポートを切れずに泣く泣く対応してる開発者への救いの手をGoogleから出してくれていた、という見方は微妙で、古いOSの延命道具の提供を通じてAndroidの諸々のエコシステムを支えていたし、支えているというのが実態だと思う。もしSupport Libraryが無ければ2系、4系、5系をもっと早く切れたのに……、とかよく考えていた。でもSupport Libraryが無ければ、Android全体がもっと微妙なものになっていたかもしれない。実際の影響力という意味では何にも分からないし、アレのほうが重要だったでしょってのを思い出せていない可能性もありそう。なにはともあれ、プラットフォーム運営としてやるべきことをやる、みたいなことをGoogleがちゃんとやってるのすごいよね。誰が始めたんだろう。

targetSdkVersionは、えーと、ちゃんと書こうとするの面倒くさいな。ちょっと遠回りをする。昔々、AndroidにAsyncTaskというその名の通り非同期処理を行うためのクラスがあって、これの実行スレッドが最初（Android 1.5）は1つでした。1.6から複数スレッドで複数タスクが並行に実行されるように変わりました。（ちなみに、スレッドプールのスレッド数がたしかOS固定ではないから、実際はスレッド1つという端末もあったはず。1.6の時点では1スレッドの端末のほうが多かったかもしれないね。）でも並行処理は難しくてみんな間違うから、Android 3.0でシングルスレッドに戻しました。という話があります。

こんな豪快な変更ができる背景と考えてよさそうなものの1つがtargetSdkVersionというわけ。上述のようにAndroid 3.0以降ではシングルスレッドで実行されることになってるんだけど、targetSdkVersionをAndroidの2系（実際の値はAPIレベルなので5～10のどれか）に設定してビルドされたアプリでは2系の挙動をすることになっていて、Android 3.0の端末でもAsyncTaskの各タスクは複数スレッドで実行される（可能性がある）のだ。「targetSdkVersionすごいでしょ」って話をするのに、今の話が全部真実である必要はないんだけど、実際にAndroidのコードを読んで、実行スレッド数までtargetSdkVersionが制御してるのに感動した記憶がある。記憶違いだったらすまぬ。AsyncTaskはもうdeprecatedになってしまって、時代の流れを感じるね。

Gradleがビルドツールとしてどれだけ優れてるのかは置いといて、現代の普通のビルドツールを使ってるというだけで嬉しいよね。というレベルの話。

Navigation Componentは登場直後にイマイチだなと思っていた点が改善されたと知って使ってみたら、こういうの欲しかったんだよ、こういうのでいいんだよ、という感動があった。それと同時に、自分の情熱が消火されていくのを感じた。画面遷移とその依存グラフをコードで良い感じに表現したいという気持ちがあって多少やっていて、いろいろ考えていきたいなと考えていた矢先、ある種の完成系を見た気になって終了してしまった。XMLとGUIでの表現より例えばKotlin DSLのほうが都合良い場合もあるだろうし、いろんな方向性があるんだろうけどね。かつて「バンドやりたいとか思わない？」と聞いたら「いやあ俺はいいかな」と答えてた同級生がいて、彼は（自分が知る限りだと）桑田佳祐とドリームシアターが好きだから「そんな完成されたものを聴いてたら自分でやろうと思わないよな」みたいなことを勝手に考えていたんだけど、そういうやつになった。というのもあって挙げたけど、別にAndroidの素晴らしいところかどうかは微妙だね。これが出てくるまでに何年かかったのよ。

じゃあ今日はこんなところで。

書いたことあるプログラミング言語の思い出シリーズが終わった気がする。忘れてる言語があったらごめんね。忘れてないけどClojureは書いたうちに入れてないとか、そういうのもある。次は、プラットフォーム的なものについて雑に書いてこうかな、と。iOSの何かを思い出そうとすると、これはiOSじゃなくAppleの話じゃないのか、みたいになっちゃうな。ともあれiPhoneの話から。

iPhone自体は知っていたけど、初めて触ったのはiOSアプリ開発をするようになってから。2013年だからiOS7が出ていろいろと新しくなった年で、UITableViewCellのEditモードで複数行を同時に動かすことでぶっ壊せるバグを見つけて楽しく遊んでいたりした。それ以降ずっとiOSのUIを壊せないか試してたんだけど、iOS13のダークモード導入のためにレイアウト系のライフサイクルが変わった影響（たぶん）でUINavigationBarの表示がおかしくなったところをガチャガチャしてApp Storeアプリをクラッシュさせるバグを見つけるまでは再現性のあるものに出会えなかった。そこまでしてダークモード導入したかったわけじゃなくて、いろいろリファクタするついでにダークモードを用意したのかもしれないなあ、とか思ってるけどどうなんでしょうね。この話はすぐ後にもう一度します（予告）。

自分で所有したのはiPhone Xが初めてで、今も使ってる。かつては3Dタッチとキーボード操作の相性がよく、挙動が変わって微妙な感じになり、でもスペース長押しよりはマシだし、ということで最新端末の購入を躊躇してる。App Switcher的なやつの挙動とかは最初より良くなった。「気にしたら負け」みたいに思ってる追加機能とか変化とかはあるけど、Appleにはそういう期待はしてないから大丈夫。良くも悪くも「良いところが良い」みたいな製品を作り続けていてすごい会社。表現が難しいんだけど、センスが無いんだよね。デザインってそういうことじゃないんだろうね。バカにされがちな充電まわりのアレコレ、ああいうやつが例外ではなく本質だと思ってください。各方面の現実と理想の間にある最高の妥協を見つけてくる、というイメージ。ノッチとSafe Area Layout Guideを一緒にもってくる感じ。ダークモードと一緒に

The traitCollectionDidChange(_:) method is only called when the value of a trait changes.

という「それはそうね」みたいな破壊的変更を添えて、App Storeアプリの起動直後のUIが乱れたまま新OSリリースしてくる感じ。センスが無いという表現は間違ってそうだけど、絶対かっこつけようとしてないでしょ。ユーザを気持ちよくしとけば許されると思ってるでしょ。そういう偏見がある。本当に全体というものを見れてるんでしょうね。

ところで、「各方面の現実と理想の間にある最高の妥協を見つけてくる」という偏見の裏には、「未来を作ろうとしていない」という偏見がある。早すぎない。iPhone登場時に乗れなかった人たちが感じてたのは、こういうところにも理由があるんじゃないかな。雰囲気で言っています。未来を作ろうとしなくても、市場はリードできるみたいね。未来を作ろうとしたら、毎年iPhoneは作れないよねぇ。「未来を売ろうとしない」のほうがいいかもしれない。作り続けて売り続けている以上ゴミみたいなものは出てくるが、ちゃんとゴミを捨てる会社だから安心して「気にしたら負け」と言っていられる。

最高の妥協にゴミが混ざる。なんとでも言えてしまうな。酔っぱらって言ってるならともかく、10年かけてまっすぐ偏見を強化してきているのだから酷いもんだ。こんなことを書いてどうするんだろうね。共感を待ってる？そうでもなさそう。自己紹介かな。

昨日は気づくとお布団にいて、書き損ねてしまった。まあ、そういうこともある。毎日書くかどうかまだ悩んでるけど、毎日書くならもうちょっと日記的なものにしたほうがいいかもしれない。

Androidエンジニアとしての最初の仕事はEclipse ADTでした。その1か月後ぐらいにAndroid Studio（v1.0リリース前）を使った新規アプリの仕事に参加していて、Gradleとの出会いはそこのはずだけど、自分がbuild.gradleを触ったかどうかは怪しい。どこでGradleに興味を持ったのか覚えていない。数年後の自分のツイート曰く、xcodeprojを見たあとにbuild.gradle見たら誰でも尻尾振るような気がする。ちょっとだけ興味持った後に『Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築』に出会ったのは大きかったと思う。こうしてビルドとビルドツールに興味をもった人間が出来上がりました（完）。

GradleのDSLは表面から先が何も分からなくて、いろんなものが魔法だった。悪い意味で。Androidのビルドの仕組みを知りたくて、Gradleプラグインのコードを見ようとしたけど、当然何も分からない。というわけで、まずはGroovyに入門することにした。2016年の3月に『プログラミングGROOVY』と『Groovy in Action』を買っていて、やる気に満ちている。後者は2～3か月かけて読んだみたい。Javaの勉強にもなって楽しかった記憶がある。あと、どのタイミングで読んだのかは覚えてないけどGroovyは公式ドキュメントも好きで、印象に残ってるものだとDSLについて書いてるドキュメントの話の流れが好きだった。また読み返してみたいな。GradleはGroovy Scriptとも違う魔法の力で動いてるらしいけど、Groovy ScriptのことはGradleの前提知識としてあるといいね。あとは（重複するけど）Groovy Runtimeのことも知っておくとよさそう。そうやってGroovyを勉強したものの、AndroidのGradleプラグインのコードは何も読めなかったので諦めました（完）。

いろんなプログラミング言語を学ぶ上で「あ、これGroovyでやったやつだ！」となることが結構あって、自分の心の中でそれなりの大きさを持っているのだけど、実際はGradleでしか書いていない。どういう人生だったらGroovyをもっと書いてたのかなあ、と時々思う。これは自分というより、Groovyを取り巻く環境の話かもしれない。

お気持ち周辺を回ってるだけで、何にも伝わらない文章を書いてる気がしてきた。ここはお前の日記です。

ぐえぇ。

冷やかしで会社作りたいね、という話は前々からあり、いろんなタイミングの重なりによって会社を作ることになった2020年。会社名を考えた後は、勝手に会社ロゴの候補を作って並べてどれがいい？とやって、会社のHPを作った。名刺はプロに任せたけど、そもそも名刺を使う機会があったかというと……。特に無職時は「名刺をご持参ください」とか言うイベントにイラっと来てたけど、そういうのも実質的に滅んでしまって悲しい。経緯とお金と能力の差異の都合でオーナーは最初から決まっていて、自分を役員にするかどうかはちょっと悩んだ。悩んだというか、困ったというか。結局は、2人で始めたのと、会社にあんまりお金を残さない方針ということで、会社員がいたほうが色々と便利なので会社員になった。来期の人がちょっと増えるタイミングで役員になるのもアリかもしれない。これも自分にメリットがあるかどうかはよく分かっていなくて、役員やったことないしな、という冷やかしの精神。そもそも会社員もそんなにやったことないし、プログラミングも含めてだいたい社会見学みたいな気持ちで始めている。

「冷やかし」というのは言葉が悪すぎるけど、ここには「ままごとではなく、社会と接点を持ちつつ、それ自体を目的化する」という意味合いが少なくともある。でも「世の中を良くしたい」みたいな気持ちに冷たい、というのもある。それなら政治家とかになったほうがよくないですか。「自分の望むように世界を作り変えたい」と言え、と。無邪気な情熱に踊らされたり踊ったりして、なるほど、君は救われましたか、よかったですね。まあどうしようもない。人類は愚かだし豊かさは足りない。I don't wanna be a part of it. でも避けがたくこの世界の一部だから、諦めつつ抵抗しつつ楽しむしかない。「遊ぶ」という言葉のほうがいいかもしれない。公園を作る、とかそういう感じ。

もちろんそんなことを考えながら会社を作ったわけではなく、これは創業者間で共有されている感覚のごく一部を自分の中で100倍ぐらいに引き延ばしたもの。でも、子供が自分の公園を作ろうとするように会社を作ったのは事実かもしれない。ただし、大人なので会社は作れてしまう。（この「公園」という比喩には慎重になりたい事情もあるし、象徴的な出来事を思い出したりもしている。もうちょっと考えてみる。）自分は働きたくないし、基本的には一人で遊びたい。でも働かざるをえないとすると、働くというのは他人と協同していくということであって、それなら楽しくやっていく場を作りたい。この「作りたい」のうち半分は、市場でお気に入りを見つけるの難しそうだから簡単なものなら自分で作る、というAndroidアプリみたいな発想だな。というかDIYの発想か。

英語は、もうちょっとできるようになると良いよねぇ、と思いながら寿命を迎える予定になっています。リスニング的なものが元々すごいダメで、センター試験はリスニングが導入される前で助かった。2015年ぐらいからHuluで映画を観るようになって数をこなしてきたおかげで多少は分かるようになってる。なので「もうちょっと」という表現になってる。仕事で使う機会でもあるといいんだけどね。今ちょうど通訳的な日本人と非日本人を挟んでインド系アメリカ人とのMTGが時々あるんだけど、やっぱりインド系の英語は本当に難しくて俺には難しい。中国人の英語が平均的にはいちばん分かりやすいと思っていて、とあるところで会った中国系アメリカ人は「ハリウッド映画で観たやつだ！」と言いたくなる感じの分かりやすさだった。とはいえ中国系アメリカ人とかハリウッド映画出てる中国人とか、中華英語の典型例では全然なさそうだし、韓国人と区別ついてるか怪しい。まあどちらもアメリカ英語の登場率がそれなりにあるから慣れやすそうで、日本人の英語がなんか苦手なのは映画で観てないからかもしれない。

フランス語は、学生のときに多少やってたのをこのまま忘れてしまうのはもったいない、と思い始めたのが2016年らしい。たぶんだけど、これも2015年から映画を観るようになった影響っぽいね。英語と違って、ちょっとは勉強しようという気持ちになってちょっとはやることがあったり、相手がいるおかげで読み書き会話がずっと続いてたりするのだけど、日々の触れる量が少なくて、このままではだめだ感ある。圧倒的にボキャブラリーが足りない。プログラミング関連だと、TwitterでGradleの疑問を書いたら、それを拾ったGradleの中の人（フランス人）がbingの機械翻訳結果が意味不明で戸惑っていて、それに自分の疑問をフランス語で直接リプライして答えを教えてもらった、というほんわかエピソードがあります。

学生時代にはもういくつかの言語をやってるけど、古典ギリシャ語とかラテン語とか、さすがにそのあたりを伸ばしてくことはなさそう。最終的にはサンスクリット語まで手を出すんじゃないかという、二十歳頃に予想してた未来は来なさそう。残念、なのかな。

ところで、皆さんご存じのように、ジャワってJavaで、ジャワ語ってJavaneseで、ジャワ文字はJavanese scriptなんですよ。なのでネタとしてジャワ語に挑戦しようと図書館で本を借りてきたことがあったんだけど、やっぱり文字が未知なのは厳しくて一瞬で挫折してしまった。ラテン文字での表記もあるんだけど、そうするとJavanese scriptが遠くなってしまう。無念。

Cコンパイラのセルフホストまで書いたから、C書いたことあるってことでいいんだろうけど、セルフホストのために特定の機能を「使わない」という意思決定をいくつかしてるわけで、むしろ全然C書いてない気持ちのほうが大きい。他には、メモリ管理をほぼ捨ててるからfreeしたことない。「この構造体は関数内でしか使わないからヒープにアロケートしなくていいね」みたいなのはメモリ管理と言えなくもないか。Cコンパイラを書くというのはCを知るということだから、ある意味ではKotlinよりCのこと知ってるのかもしれない。いろいろ知らないと書けない言語と、いろいろ知らなくても書ける言語を比べても仕方ないのだけど、書ける感・書いた感の得られ方がかなり変わってくるのはちょっと面白い。

その体感を支えてそうな個人的な要因としては、ちゃんとC言語の勉強してない、というのもありそう。書きながら学んでいったほぼ唯一の言語のはず。BNF眺めてたら知らないCの仕様に気づいたのは楽しい体験だった。

セルフホストにもいろいろあるけど、プリプロセッサはgcc任せで、libcはglibcのバイナリを使いつつ、プリプロセス後のlibcヘッダファイルからも逃げて独自の扱いやすいヘッダファイルを作ったから、おそらくセルフホストの中では最も簡単な部類で、libcにもうちょっと向き合えばC書いた感に繋がったかもしれない。コードを見返しながらそのあたりの状況をおさらいしてたら、libcのコードは一部書いてもいいけど、プリプロセッサは興味わかない、という気持ちを掘り起こした。まあ「Cが扱ってる問題領域に興味はあってもC自体には興味無い」ということなんでしょうね。プリプロセッサがCの仕様の一部かどうかは覚えてないけど。

static local variableって言えばいんですかね、あれ好き。

ADT！ADT！

公式サイトにある日本語の『OCamlチュートリアル』と、本としては『プログラミング in OCaml 〜関数型プログラミングの基礎からGUI構築まで〜』、という順番で読んだはず。本は延べ2.8周分ぐらい読んでそう。あんまりWebで読み物を読んでいないので珍しい感じ。

本を買って1年後ぐらいに、OCamlでCコンパイラを書き始めたり、TaPLを読み始めたり。普段はIntelliJファミリーかXcodeという生活だから何で書くか迷うことはないんだけど、OCamlはどうしていいか分からなくて、まずはIntelliJでReasonMLのプラグインを使うことにした。生活のメインマシンはWindowsなので、以下の構成で始めてみた。

Qiitaに記事を書いてみたら、ocaml intellij wslでググると検索TOPに出たのでびっくりした。今も出る。完全に忘れてたけど全部bash経由で動かすんだね、なるほど。たしかCLionはsftpか何かでWSL側のCMakeその他と通信してたけど、汎用的な仕組みとしては公開されてないみたいだからOCamlでは諦めてWSLのbashを使ったんだった。ガチ勢は何を使うんだろう。別の勢力であるはずのReasonML勢も主流派が何を使ってるか分からないけど、そっちはVSCodeというのはありそうね。というわけで、割とすぐ次の構成に移った。

たしか補完とフォーマットをもうちょっと良い感じにするためにocp-indentを使いたいのが背中を押したんだったかな。VSCodeのWSLサポートが便利すぎて辛い。WSL2はまだ試してない。

書き始める前は、OCamlって構文が気持ち悪いと思っていて、F#はそこが完全に気持ちよくて感動してたりしたんだけど、書いてたらOCamlに慣れてしまって、何が気持ち悪かったのか思い出せない。最近は、シャドウイングできるのにlet ～ inじゃないRust気持ち悪い、みたいな偏見とともに生活してます。これもちゃんとRustを勉強して書けば慣れてしまいそう。そういやセミコロンなしの言語も嫌いだったのに慣れてしまったね。こういう体感の変化がプログラミング言語だと割と簡単に起きるのが楽しいね。

冒頭の話に戻ると、SwiftとかKotlinでADT的なものは書いてたはずだけど、OCamlのヴァリアントに出会ってから完全に蝕まれてしまった。Twitterその他の記録を漁っていたら、これはOCamlというよりむしろ『プログラミング in OCaml』のヴァリアントの章その他を繰り返し読んだ影響な気がしてきた。影響そのものが何だったのかも改めて考え直さなきゃ。

（OCamlで）Cコンパイラを書いてたときの一番の印象は、（OCamlの）コンパイルエラーが全然分からないということ。推論させればいいってもんじゃないな、という通過儀礼みたいな気持ちになった。文法が分かってくると変なところで間違えないからそういうことは減っていくかと思いきや、えいやと全体に関わる修正するときにコンパイルエラーの出てる場所もメッセージも頼りづらかったり、調子に乗って4つも型変数を持ってるヴァリアントの修正に泣いたり。そういうことにならないように書くのが正しいんだろうけど、おおきな絵の描き方が分からないな。これは単にGUIアプリケーション以外の経験が少なすぎるだけかもしれない。

SwiftのこともKotlinのことも、雑にいろいろ書こうとしたら気づくことがあって良かった。何かの訓練になるということもあるだろうけど、ちょっと時間とって改めて何かを考えるというのはそれ自体で効果ありそうね。

公式ドキュメントがむかつく、という話だけ書こうかな。

• Why so?
• In "clever words",
• Why?

こういう「お前のブログじゃねえぞ？」みたいな文体と内容が出てきたり、

As we mentioned before, we stick to making things explicit in Kotlin. So,

とか適当なこと書かれてるから、機嫌悪いときだと「クラスのインスタンスを作るのにnewつけないのはexplicitなんですか？」みたいにキレちゃうわけ。実際のところKotlinの良さというのは、なにかにstick toしたりせず、現実のほうを向いてバランス良く落としどころをもたらしてる「現代のちょうどいい言語」になっているところなのだ。たぶん。（識者曰く）Scalaからの影響が明らかにあるのに現在のドキュメントからはそれが意図的に隠されているような気配があったり、他にも思いつくことがあるけど記憶に自信も無いのでこの辺にしておく。

それもこれも全部がマーケティングで、実際たぶん成功してるから、その成功の恩恵に与れているからいいじゃん、という考えもあるかもしれない。でも、これがアリなのかどうかとは別に、言語の仕様と実装を担っている人々の思想から離れたドキュメントになっている、と勝手に想像している。GitHubにWebサイトのプロジェクトがあるから今ちょっと確認してみたら、上述した表現が出てくるページの元の文章を書いたのはDeveloper Advocate的な人で、しかも7年前だった。その人が当時どういう職種だったか分からないけど、最初からちゃんとそういう人に書かせるというJetBrainsの戦略が功を奏して、その文章と相性の悪い俺のところまでプロダクトが届いたってことだろう。そしてv1.0が2016年2月15日リリースだから、その前から書かれてたんだね。

好奇心でGitHubでblameを追っていたら、上述の引用部が、2年ぐらい前にchore: remove unneeded comparisons with javaというコミットで変更される前は、

As we mentioned before, we stick to making things explicit in Kotlin. And unlike Java,

だったことに気づいた。たぶん俺これ読んでる。改善はされてきてるみたいだけど、こういう微妙な感じが随所に残ってたんだと思う。微妙というより嫌な感じだと言いたいけど、それを伝える材料が無いので控え目。

ところでmaking things explicit in Kotlinの話、もしかしたらコンパイル時間の短縮のためにそういう方針がとられてた時期があったのかもしれないな、とWikipedia見てたら思いました。

JetBrains lead Dmitry Jemerov said that most languages did not have the features they were looking for, with the exception of Scala. However, he cited the slow compilation time of Scala as a deficiency.[10] One of the stated goals of Kotlin is to compile as quickly as Java.

Scalaのこと（特にコンパイルが遅い理由は）何も知らないまま適当なことを言っているわけだから理由はもちろん妄想レベルだとして、あくまでもv1.0より以前に書かれた7年前の文章の名残であって、当時は正しかったのかもしれないなぁ。

仕事でちょろちょろっと読み書きする機会が無くはなかったけど、ちゃんと勉強したのは4系に入ってから。Appleが用意してる『The Swift Programming Language』を読んだ。（正確にはそのうちの「WELCOME TO SWIFT」と「LANGUAGE GUIDE」で、「LANGUAGE REFERENCE」は形式的な話がほとんどで難しそうだったからスルーした。）夜、寝る前に、というか入眠までこれを読む生活を数か月、たぶんそれを2回ぐらいやっていて、すごく幸せな日々だった記憶がある。Webにもあるけど、iBooks（今は名前違うんだっけ？）で読んでた。https://swift.org/documentation/#the-swift-programming-languageによると、Swift5.3用のepubが https://docs.swift.org/swift-book/TheSwiftProgrammingLanguageSwift53.epub にあるらしいから、他のバージョンも同じように取得できそう。と思ったけど、適当な数字入れても404になるね……。古い版への一覧を見つけたことあった気がするけど、まあいいや。

Appleの他のドキュメントと（はちょっと位置づけは違うんだろうけど）同様に質が良くて、ちょっと気になったのは、

• CあるいはObjective-Cの知識を前提しないと厳しそうな部分があった
• 文字列のところでUnicodeの難しさとメモリ管理の難しさがダイレクトアタックしてくる
• 初期化のところがやけに詳細に踏み込んでいて難しい

今思うと、これってSwiftという言語の本質的に難しい部分だから仕方ないかもね。GUIプログラミングだけならKotlinとかとだいたい同じ感覚で書けるんだけど、システムプログラミングとかそういうところまでカバーしなきゃいけないはずだから、そういう問題領域の難しさが言語仕様にも現れてくる、みたいな。

そういう低レイヤーと、逆方向（？）の型理論の難しいところが、良くも悪くもSwiftでは地続きになっている。それが楽しい。自分の場合、Opaque Result Typeのおかげで「コンパイル時のことよく分かってないな」と思うようになって、https://www.rightpoint.com/rplabs/switch-method-dispatch-tableみたいなMethod Dispatchの話を経由して、Objective-C Runtimeのことが気になってソース見てアセンブリに衝突して、なんやかんやあってCコンパイラを作った、という流れがあった。

地続きというか、まるっと言語処理系ってことか。処理系を意識させてしまう言語が良いか悪いかはともかく、Swiftはそういう言語で、だから言語処理系に入門したんだね、俺。なるほどー。

モバイルアプリをネイティヴからハイブリッドへリプレイスするけどジャヴァスクリプトもうギヴアップってわけ。

そんな気分がありつつ、TypeScript勉強して楽しくなってたから提案というか「選定の無念を晴らす！」という感じでやることにした。当時の自分の周辺ではJSではgulpを使っていて、ちょうどTS公式のドキュメントにもgulp設定が書いてあったりして、さくっと始められた。（あれ、今もgulpでのstart guideあるのね。）プロジェクトの参加メンバーが変わったり増えたりで想定しない状況になったものの「困ったらanyって書いとけばいいからね」で押し切ることにした。

型に守られた世界の住人が自分たちの常識を持ち込んで書く場合だと、そりゃ型無いと無理でしょ、ということに当然なるわけだけど、いわゆるフロントエンドの世界の人たちにはどう見えてたのかなあ。人間というよりフレームワークが型世界に出自を持ってそうな界隈、具体的にはAngularやってる人たちは、フレームワーク都合というより一般論としてTypeScriptに歓迎モードだった印象がある（要出典1）。普通に考えて、型が有効なユースケースを日常的にたくさん見てたからだろうね。それ以外は全体として、既存コードやライブラリとの相性や、たぶん、人間の教育の問題もあり、推進というよりは「焦らずやっていきましょうね」ぐらいの雰囲気で、その雰囲気の幅の広さから、例えばnoImplicitAnyの是非やGradual Typingの加減を火種にときどきボヤとか炎上とか（要出典2）。Twitterで何を見てるかに依存した偏見によると、2020年は平和だった感じがある。ライブラリと人間の世代交代が進んだのかもしれない（要出典3）。なんか、若者すぐ＆まずTypeScriptやってるよね（要出典4）。

さて、こういうどうでもいい偏見の詳細は無視しつつも「世の中ちょっと変わってきたね」が正しいとして、表面的でない変化にはどういうものがあったんだろうね。JavaScriptの柔軟さに合わせて型付けを頑張れるようにするために導入されたいろんな機能があるけど、随分と前から入っているString Literal Typeがいちばん革命的でwebに本質的なものなんじゃないかって最近思うようになってきた。これはもちろんよく考えられた上での結論ではなく、ビビビッときただけ。httpもhtmlもテキスト中心の世界じゃん？そこで文字列に型付けるとかマジ幸せじゃん？ぐらいのノリで、FirebaseのAPI Reference（例えばAnalytics）を見たり、アプリケーションレイヤーでのRoutingに型を付けようとする試みを見てたら、そういう感覚が芽生えてきた。要するに、好き。

型ピ。

かつて、Hyper Textを求める修行僧の一部に、無意識にJavaScriptを繰り出してしまう病が広った。かすかな記憶と痕跡により存在が確認されているその病について、多くを語れる者は少ない。免疫を獲得したと称する者、口を閉ざす者、笑い出す者がいる。彼らに出会うのは殆どの場合、

なんやかんやでHTMLとCSSはインターネットに触れた直後から書いてそうだけど、JavaScriptはよく分からんし、どうせコピペしただけだろうからカウントしないでおく。プログラミングの仕事を始めてから、たぶんTwitterの影響でJavaScriptについての認識を積み上げていって、何かしらの先入観を獲得していったはず。

まあまあ覚えているのはそこから先で、「JavaScriptこわいし、絶対仕事でやりたくない」と思いながらMDNを読んでる期間があった。断片的に読めて周辺事項のリンクを追ってくこともできて内容も楽しくて、MDNのことを好きになったのがきっかけでJavaScriptとの正式な交際が始まったと言っても過言ではない。例のごとく、書いてみようという気持ちが1byteも湧いてこないまま「いや、Web Workerってのがあって今は別スレッドで動かせなくもないよ」などと早口ヲタクをやっていた。

そうこうしてるうちに、モバイルアプリのWebViewで動かす、いわゆるハイブリッドアプリに巻き込まれてしまった。この「巻き込まれ感」というのは「もはやハイブリッドアプリって時代遅れじゃないですか？これで実現できるなら工数減る可能性はあるとして、WebのDeveloperがその辺にたくさん転がってる界隈じゃないでしょ？」みたいな気持ちに由来してたと思う。「時代遅れ」的な話でいうと、むしろモバイル端末のWebViewでもパフォーマンス的に十分だったり、Web側はnodeのエコシステムが発展してきていたりして、HTML5だわっしょいの時代とは違う状況にはなっていた。まあこの辺は別の機会にするとして、そんな感じでJavaScriptをたまに書くようになった。トランスパイラ無しでの素のつらさ、有りでのES2015でのつらさ、色々あった気がする。For example, this was this.

でも、最近ReactやReact Nativeをやっていて、JavaScriptも悪くないやつだな、と思うようになってきている。どんどん良くなっていく言語とその良いところが活かされている世界、という雰囲気がある。単に酷いコードを見ていないだけとか、だいたいJSXを書いてるだろとか、そういう話もあるけど、そういう状況が成立しやすくなっているから言語評価が変わりつつある、というのもありそう。例えるならば、Objective-CからSwiftに移行した環境ではなく、SwiftUIが到来している世界で感じるSwiftの良さに近そう。ただし、SwiftUIのこと何も知りません。体感として得てるわけではないことを続けてふんわり言うならば、REPLの有無と出来でプログラミング言語って全然違うものになるよね、みたいなことかもしれない。

今は普通にWebStormで書いてcommitしてpushして（CI上でビルドされてデプロイされて）るんだけど、こういう疲れてるときはさっさとお布団に入ってゴロゴロしながらTwitterしながら書けるといいなぁ。なんか始まってしまったものを「このまま毎日書き続けるぞ」という気合いがあり、とはいえ毎日書き続けられるような気合いが無から湧いてくるわけではない。でもnext exportする限りビルドと再デプロイは必要になってきちゃうから、そこから変えるのは嫌だな。うーん。

むしろ「仕事後に毎日お布団の外でやる」というのが意味のある変化であって、そこを継続すべきかもしれない。でもでもでもでも「習慣化」みたいな意識高いことを言われると逃げ出したくなってくる。ぐええ。

書いたことある順とは言ったものの、次あたりから順番テキトーになりそう。

「Lisperの気持ちを分かるようになりたい」とプログラミング言語およびプログラマに興味をもった後、どこで偏見を仕入れてきたのか「いきなり関数型言語はアレなんでしょ？」ということでJavaの勉強をすることにした。まず、やさしさを掲げてる風の本が「引数」の読み方を教えてくれず（自分はどこかで知っていた）、そういう本を警戒するようになった。次に、分厚くて大きい翻訳本に手を出してみると、何も教えてくれない（分かってると分かる）系の本で悲しくなった。少なくとも読み物にはなっておらず、何一つ説明された気持ちになれなくて放り出した。

最終的に行きついたのが『Introduction to Programming Using Java』で、正確にはその6th Edition。アメリカのどこかの大学の先生が作ってるオンラインテキストで、ペーパーバック版だと700ページぐらいらしい。紙のページ数を先に知ってたら読まなかったかもね。目次はこんな感じ。

• Chapter 1: Overview: The Mental Landscape
• Chapter 2: Programming in the Small I: Names and Things
• Chapter 3: Programming in the Small II: Control
• Chapter 4: Programming in the Large I: Subroutines
• Chapter 5: Programming in the Large II: Objects and Classes
• Chapter 6: Introduction to GUI Programming
• Chapter 7: Arrays
• Chapter 8: Correctness, Robustness, Efficiency
• Chapter 9: Linked Data Structures and Recursion
• Chapter 10: Generic Programming and Collection Classes
• Chapter 11: Advanced Input/Output: Streams, Files, and Networking
• Chapter 12: Threads and Multiprocessing
• Chapter 13: Advanced GUI Programming

「コンピュータというのはね」みたいなところから始まって、ずっと文章が楽しくて嬉しくて感動してた。タイトルにそのままあるように、これで（Javaというより）プログラミングに入門したんだと思う。これは本当に良い出会いだった。Free Programming Booksというページで見つけたことは記録から分かっているのだけど、このページをどうやって見つけたかは覚えていなくて、たぶん雑にググったんだと思う。

楽しくて嬉しくて感動したものの、Javaは何も書かないままiOSアプリの仕事をするようになって、その半年後ぐらいにAndroidアプリの仕事で初めてJavaを書くようになった。Javaはenumがね、enumが好きでした。なんで過去形なのか。JavaでIntersection Typesを書いたのはその最初のAndroid仕事だけで、今も時々あれは正解だったのか考えてしまう。豪快にアニメーションするボタンについて通常時とクラスを分けて描画関連の機能制限したらアニメーションからちらつきが消えて勝利した、その勝利への道すがらにIntersection Typesが自然と出てきた思い出として美化されているから強い。このまま額縁に飾っておきます。

enumもジェネリクスも、Objective-Cの反動で嬉しがってたんだろうね。さすがにこういうのは実際にプログラミング経験が無いと生じない感触っぽい。きっとプログラミング言語も制約と誓約で強くなるもので、念能力者以外には分からないことがあって、こういう体験のためにプログラミングに興味をもったはず。初心を忘れず、一喜一憂してこうな。

Swingの話もJavaの一部のような気がするけど、今日は疲れたからまた今度。

何かの拍子にLisp:S式の理由とかそのあたりを読んで、なぜか「Lisperの気持ちを分かるようになりたい」と思ったのが、プログラミングへの最初の正式な興味だった。でもこれプログラミングじゃなくてプログラマへの興味だね。ともあれその年は何かしらのプログラミングの勉強をして、そしてあんまり関係無い流れでプログラマになった。なんとなく職業プログラマにすんなりなれたのは、そういう事前の経験値稼ぎがあったからかもしれない。

すぐにはLispには近づかなかったし、今もあんまり近づこうとしていない。最後に最接近したのは『プログラミングClojure』を読んだ直後あたり。いつだったかな。これを翻訳した川合史朗さんが上記のサイトおよび文章を書いていたことのに気づいたのはだいぶ後で、TCFMおよび「低レイヤを知りたい人のためのCコンパイラ作成入門」（魂が影響を受けた順）のRuiさんのコメントもある。ずっとこの周りをぐるぐるしてそう。

書いたことある順に、プログラミング言語のことを。

実質的に初めてのプログラミングはObjective-Cでの仕事。「暇だったら勉強しといて」って言われたから本を読んで、翌月ぐらいから新規iOSアプリの開発に参加した。macは持ってなかったから書くのは仕事だけ。本は仕事始めてからはずっと読んでたと思う。「今日初めてswitchを書いたよ」みたいにキャッキャしてた。仕事としてはプログラミングよりXcodeのInterface BuilderとAuto Layoutのほうが難しそうだけど、そこはあんまり苦労した記憶が無い。最初の一歩か三歩をプロに教わってるのと、これはゼロから作るほうが簡単なジャンルなのと、UIパーツ組み合わせパターンが複数ある（IBだけで実現したくない）世界だったからかな。複雑なデータとUIをどう抽象化するか、みたいなところが難しかった。まあその抽象化に成功はしてないけど、課題自体が難しかったから仕方ない。言語およびランタイムとしては、Objective-C 2.0だし、ARCだし、そういう意味では変な苦労はしていない。古めかしいプロジェクトのメンテをしたことはあるけど、そういうものはだいたい別の種類の苦労が待っていた。新規でMRCプロジェクトを書くことになったら厳しかっただろうね。

Objective-Cは当時も今も割と好きな言語で、特に最初は『詳解 Objective-C 2.0』の影響が大きい。ここ最近だと2019年にSwiftの違いとかを調べてて改めてObjective-Cランタイムに興味をもって、古い本（『Dynamic Objective-C』）を読んでたらCレベルの話が出てきたり、ソースを読もうとしてたらアセンブリに遭遇したり、そうやって低レイヤーのほうへ進んでいってCコンパイラを書いた、というのが昨年まで。道草を食わなければ『エキスパートObjective-Cプログラミング －iOS/OS Xのメモリ管理とマルチスレッド－』を読んでたはずなんだけど、積んだまま。今年は読もうね。

プライベートはそんな感じでも、仕事ではしばらくObjective-Cを書いてなかった。やっぱりここ数年はSwiftがほとんど。ところがReact Nativeをやることになって久しぶりに再会。Native Module部分もSwiftで書けなくはないはずだけど、JSとのブリッジに使われてるのは結局はObjective-Cランタイムの機能っぽいし、使いたいライブラリがObjective-Cだったのもあって、素直にObjective-Cで書いた。言語は相変わらず好きだとして、標準ライブラリでつらくなった。なんでArrayにmapが生えてないの？とか、そういうやつ。特に最近のJSと往復してると、進化を止めた言語という雰囲気がある。そんなん自分でいくらでもメソッド生やせばいいやんけ、という言語なのかもしれない。3rd Partyのライブラリが自分で宣言してる型を無視した値を返してくるというワイルドな状況にも遭遇したのだけど、なんかそういうのは「まあ直せばいいんじゃない？」ぐらいの気持ちになっていて、これは大人になるということなんでしょうか。ちなみにReact Native自体のソースを覗いてみるのも楽しくて、でもすぐにC++が出てきて逃げ出した。C++を読めると世界は広がりそうだけどねぇ。

「書いたことある順」って日本語として成立してるのかな……。

2019年と2020年は言語処理系に入門した。

Ruiさんの『低レイヤを知りたい人のためのCコンパイラ作成入門』を初めて読んだのが2019年の夏で、その年末から読書会に参加して再読とCコンパイラ実装を始めて、2020年の春先にセルフホストまでやって力尽きた。

2020年4月にはRuiさんが「Cコンパイラ作成集中講座（2020）」を始めて、4月末の第2回から参加してた。この講座にはSlackワークスペースもあって、各チャンネルでの進捗報告とか質問とかも面白かった。

それと前後して、4月末にはOCamlでCコンパイラを書き始めたり、『型システム入門 プログラミング言語と型の理論』いわゆるTaPLを買って読み始めたりした。GWに始めるか、というノリがあったような気もする。

前者は途中で飽きてしまった。2020年9月で止まっている。CでCコンパイラ書くとセルフホストという目標ができるのは大きいんだな、と思った。セルフホストはほぼ無職でやっていたので、これは労働に負けただけかもしれない。OCaml書いてみたくなっただけなので、まあ十分といえば十分。

後者はしばらく続いてから挫折というよりはフェードアウトした。Kindleによると28%ぐらい。挫折するほどの理解を自分には求めてないけど、ちょっと離れると戻ってこれないね……。（それを挫折と呼ぶ説もあります。）良くも悪くも、数学と論理学に対する自分の能力は期待通りだった。それでそれなりには楽しめて、10年後にはもっと楽しく読めそうという見込みができたので人生は明るい。とはいえ2021年は再読を開始したいなあ。

他人が書いてる（のを読む）ぶんには全然良いのだけど、じゃあ自分が書くかっていうと「ブログって前世紀の文化でしょ？」みたいな気持ちになってしまい、各種ブログサービスに近づけない。たぶんブログ元年やらブログ全盛期やらを学生時代に通過したせいで、歴史の闇に葬り去りたい何かになってしまっている。今世紀をうまく過ごせた気がしておらず、バランスをとるために過去に追いやっているのだ。記憶は消せないが、時系列はあやふやにしておける。

とはいえ何か書き続けてみようかという気分になって準備しながら「でも1枚に全部並べるのもすぐに限界来るよね」とか「なんだかんだで日付もあったほうがいいな」とか、そんなことやってたらブログというものに近づいてきて悩ましい。ブログのようなもののリハビリに、ブログのようなものを作る、というのはアリかもしれない。

もうちょっと別のことを書こうと思っていたけど、まあいいや。労働に負けずに続けたい。

このサイトはNext.jsのnext exportで出力した静的HTMLその他をFirebase Hostingにデプロイ（までをGitLab CIで実行）してるイマドキっぽい構成。

会社のHPを作っていたら手書きのhtmlがちょっとだけつらくて何かちょうど良い感じのものが欲しかったところ、たまたまドキュメント読んで楽しんでたNext.jsが気に入って移行したのが去年の11月ぐらい。ちょっとしたサイトならもう俺はこれでいいや。もちろんReactを多少は知っている必要はあって、そのコストがどんなもんなのかはよく分からない。でも基本もいらないかもしれない。明らかにHTMLやCSSのほうが難しい。

このサイトは上述のようにnext exportつまりSSGなので（開発時のnext devを除くと）いわゆるアプリケーションサーバとしては使っていないけど、毎回動的に生成するSSRとかちょっとずつ（再）生成するISRとかいろいろ機能があって、それらを一つのFrameworkで並べて実現するために生えてるAPI（getStaticPropsとgetServerSideProps）が面白い、という話を聞いて興味を持ったような気がする。

ReactとJSXでファイルシステムベースのルーティング、つまりもうこれPHPじゃん、とか考えていたら、実際にFAQの「What is this inspired by?」という質問にこう答えられていた。

The ease-of-use of PHP is a great inspiration. We feel Next.js is a suitable replacement for many scenarios where you would otherwise use PHP to output HTML.

2020年は過去最高かつ薄くPHPに縁があって、それで余計にNext.jsが染みたのかなー、と思ってる。プロダクションコードは1行も書いてなくて、Laravelアプリのセッション関連の挙動を調べたり、その開発環境として用意されていたDocker Composeの説明をしたり、新規のPHPプロジェクトの立ち上げで開発環境をDocker Composeで作ったり。あ、徳丸本も読んでた。

そんなすれ違いで恋しくなってたところに颯爽と現れた今話題のNext.js君。空いた心の穴を埋めてしまった。

あけましておめでとうございます。
CSS何も分からん。

How (not) to work

iOSとAndroidとその周辺のお仕事。
30歳ぐらいからプログラミングを始めて、金融系のアプリが多め。
旧友の会社で4年、フリーランス3年、仲間と会社を作って5年、無職2年目。

C'est la vie

新婚。
元TDLキャスト。
高知県出身、東京都在住。
東京大学文学部哲学専修課程卒業、人文社会系研究科中退。

Links

https://guignol.ninja
https://twitter.com/guignol_ninja
https://github.com/guignol
https://qiita.com/guignol