miyado.dev

昨日のエラーを直したら10分くらいかかって不思議だなあと思っていたビルドが1分未満で終わるようになった。
記事やコメントを投稿したらビルドし直しているので、それが10分かかるのか1分足らずで終わるのかは相当違う。
爆速！　超嬉しい！

Nextでpages以下の構造がルーティングに使われるのは知ってたけど、api以下の構造もルーティングに使われるのを知らなかった……
めちゃくちゃ基本なんだろうからちゃんとドキュメントを読んでおけという話。
api以下にファイルを増やしたら謎の制限でビルド出来なくなって首を傾げていたけど、なるほど納得した。

今日の仕事では風呂敷広げていきたいんですよね〜みたいな話をした。
年始でもあるし夢は大きく。

昨日は記事を書いたけどエラー（セッション切れ？）で投稿されず、今朝は書いて投稿されたけど不具合でビルドできずと不幸が重なっていた。
朝9時に記事を書いたらビルドできない（UTC0時を24時としていてパースできない）不具合だった。
直して無事ビルドできるようになった。
ビルドできないおかげで、結果的に不整合なデータが入っても（最新には更新されないが）対面的には問題なく動き続けるということはわかった。

コンウェイの法則と逆コンウェイの法則は（名前とニュアンスだけは）知っていた。
本書チームトポロジーを通して、その具体的な適用や意図についての理解を深められた。
特に、チームの認知負荷とコンウェイの法則によって規定される「アーキテクチャ」の範囲については自分の考えを改めるこ��になりいい気付きを得られた。

ストリームアラインドチームを構成する際には、職域横断かつサービスの隅々まで賄えるようなプロダクト面でも専門的な集団とするのが理想的な印象があった。
ただ、言われてみれば当たり前ではあるが、現実として存在する認知的な限界を避けることはできない。
よって、認知負荷により制約されるチーム構成とする必要がある。
認知負荷のコントロールのためには、チームの分割・整理もひとつだろう（そのためのチームトポロジーであり本書である）。
これ以外にも、認知のキャパシティを増加するような適切なドキュメンテーションやドメイン知識の整理・抽象化といった基本的な生産性の向上も効きそうだ。

もう1点、コンウェイの法則によって規定される「アーキテクチャ」の範囲として、技術的なアーキテクチャしか頭になかった。
これも言われてみれば当たり前だが、チームの活動は技術的な部分に留まらない。
コミュニケーション、ドキュメンテーション、その他業務上あり得る活動すべてに対して適用される。
コミュニケーションに対するアーキテクチャを考えれば、本書に説明されるチームインタラクションの視点をもつことになる。
そしてドキュメンテーションについてはさらりとしか本書では触れられていないが、その構造もコンウェイの法則によって規定されるもののひとつだ。
コミュニケーションの一形態という意味で主題ではないのかもしれない（し、そのテーマだけで別の本になりそう）。
テレワークが多く殊更にドキュメンテーションの価値はましているわけで、「どこに」「何を」書くかがチームの構造に沿っているのが望ましい。

エンジニアリングチームにはインターフェースを決めるとよさそうだという直感と、具体的にどのように決めるかという課題感をもやもやと抱えていた。
結果として、直感は正しく、決めるべきインターフェースについても一定の方針を得られた。

3連休だったけれど、サーバー側に変な更新を入れてしまったせいで記事投稿・ログインができなくなってしまっていた。
今日は時間があったのでそれを修正した。
参考にした記事の英語の読解が間違っていて、完全に反対のロジックになってしまっていた。

さらに、過去記事の個別URLが404になってしまう不具合も見つけて直した。
これは初期はよかったけど、運用の時間が経って記事数も増えてきたことで露見するようになった不具合だった。
初期の暫定的な実装ではページングできていなかった。

こういうのが見つかるのは、自分の手で動かす醍醐味と言えるかもしれない。
し、面倒さと言えるかもしれないｗ