日記：Reactの画面分割ライブラリ
よわよわエンジニアが知ったことのメモ日記です
ことの発端
Next.jsを使っていて、画面を右と左に２分割して使いたい。 当然ながらCSSで頑張れば実装は可能だと思うが、Reactのコンポーネントライブラリで簡単に作れるものがないか探したいというのが発端。
結構あるあるのユースケースだし幾らでも記事でてくるだろうと思っていたら、案外日本語の使ってみた系のページが少なかったので、机上調査をまとめておく。
一部動作確認した時の環境は以下の通り
+-- @types/node@20.9.4 +-- @types/react-dom@18.2.17 +-- @types/react@18.2.38 +-- next@14.0.3 +-- react-dom@18.2.0 +-- react-split-pane@2.0.3 +-- react-split@2.0.14 +-- react@18.2.0 `-- typescript@5.3.2
最終的に使うことにしたのは react-split-pane 。
簡単に使えそうだったので最小労力でやりたいことが出来るものとして選択した。
split
Star 5.9k。Sopnsorもついていて安定していそうな印象を受けた。 Split.jsをReact Component化したものっぽく有名どころが元となっている点も良い。
日本語の記事もあった
公式をコピペしてやってみたけど、スプリットされない。。
<Split
sizes={[25, 75]}
minSize={100}
expandToMin={false}
gutterSize={10}
gutterAlign="center"
snapOffset={30}
dragInterval={1}
direction="horizontal"
cursor="col-resize"
>
<div style={{border:1, color: 'red'}}>aaa</div>
<div style={{border:1}}>bbb</div>
</Split>
本当は2つのdivが左右に分かれるはずなのだが、divの中身が縦に二つ並んでしまう。スプリットの境界をドラッグすることも出来ず、境界線も表示されなかった。 特にエラーも出ていなかったのだが、Reactのバージョンが問題かもしれない。
react-split-pane
github.com Star 3.1k。こちらも日本語の記事が数件存在していた。
インストールしようとしたが、エラーが出た。 どうやら最近のReactには対応していないらしい。
$ npm install react-split-pane --save npm ERR! code ERESOLVE npm ERR! ERESOLVE unable to resolve dependency tree npm ERR! npm ERR! While resolving: proto@0.1.0 npm ERR! Found: react@18.2.0 npm ERR! node_modules/react npm ERR! react@"^18" from the root project npm ERR! npm ERR! Could not resolve dependency: npm ERR! peer react@"^16.0.0-0" from react-split-pane@0.1.92 npm ERR! node_modules/react-split-pane npm ERR! react-split-pane@"*" from the root project npm ERR! npm ERR! Fix the upstream dependency conflict, or retry npm ERR! this command with --force or --legacy-peer-deps npm ERR! to accept an incorrect (and potentially broken) dependency resolution. npm ERR! npm ERR! npm ERR! For a full report see: npm ERR! /root/.npm/_logs/2023-11-26T02_50_51_639Z-eresolve-report.txt
公式画面の一番下の方に書いてあった。
こっちでインストールしたら "react-split-pane": "^2.0.3" が入って一応動いた
react-split
Star 52で若干不安。中文。 ただデモページもあり、更新も一人が頑張っているっぽい。 - uiwjs.github.io
react-grid-layout
このページによるとreact-grid-layoutの方が勢いがあるらしい。 今回のケースではちょっと多機能すぎるので、採用は見送ったがこれがデファクトっぽい。
日記：Tell mode, Ask mode
よわよわエンジニアが知ったことのメモ日記です
Tell mode, Ask mode
ある本を読んでいて「Tell mode, Ask mode」という知らない単語を見かけたので調べた。
本の中ではリリース手法とブランチ戦略についての解説に登場した文言。
結論から言うとTesk Mode, Ask Modeはコード品質を上げるためのプロジェクト管理の方針の一つ。
Tell Mode, Ask Modeともレビューを厚めに構えることでチェックイン頻度を下げ品質を担保するという考えがベースとなっている。
現代のスピーディな開発やCICDの流行りには逆行するような方針にも見える。個人的には今もマージリクエストによるレビュープロセスは標準的であるが、Tell Mode, Ask Modeはチェックイン頻度を下げることを目的として明言している点で今の開発プロセスと着眼点が異なると思う。（調べたところ見つかった記事は2004年, 2015年のものなのでやや古い考えかもしれない。日本語の記事もなかったため普及しなかったのだろうか。）
定義としては以下のようなもの。
Tell Mode
部門内のチームには、好きなようにバグを修正する裁量が与えられる。ただし、そのバグを選んだ理由をShiproom*1で発表・説明する必要がある。
そうすることで、事業部内の共通のハードルが確保され、修正のスピードが遅くなり、徐々にビルドクオリティが上がる。Ask Mode
部門内のチームはチェックインする前にShiproomの許可を得る必要がある。
askモードのバグは、夜間の自動化テストとバディテストを経て、問題の発生を防ぐ必要がある。
見ての通り、チェックインにブレーキをかけることで品質を担保しようという方針であるため、トレードオフと適不適がある。
この手法の背景としてあるのは、大規模プロジェクトにおけるリグレッション起因のバグ再発ループである。思うに「開発者が大した影響のないバグにも修正を試みて新たなバグを生んでしまうという状況が品質の低下につながってしまう」という考えから、修正対象を選んだ理由を説明させるTell Modeと修正を承諾制にしたAsk Modeが生まれたのではないか。
こういったプロセスを導入することで、開発者がバグを修正する前に「なぜそのバグを修正するのか」を自発的に考える習慣が生まれるのは良いことだと思う。
参考文献
*1:バグが検討・評価され修正するかどうか判断するデイリーミーティング。恐らくミーティングではなく特定のマネージャの判断で代替することも可能
日記：Chatty vs Chunky
よわよわエンジニアが知ったことのメモ日記です
Chatty vs Chunky
ある本を読んでいて「Chatty Design vs Chunky Desgin」という文言を見かけた。API設計の文脈で登場した言葉である。
聞き馴染みがなかったので調べてみたが、日本語のサイトがこちら*1くらいしか見つからなかったのでちょっとまとめておく。
検索でトップに出てきたワシントン大学のページによれば、以下のような定義らしい。
Chatty services tend to be ones that return simplified information and use more fine-grained operations.
Chunky services tend to return complex hierarchies of information and use coarse operations.
In other words, the difference is that chatty services require more calls than chunky services to return the same information but allow more flexibility to return only the information that is actually required.
またある学習サイトでは、以下のように説明がある。
Chatty API is one that requires consumer to make tremendous (subjective matter) amount of distinct API calls to get needed information about a resource.
雑にChattyとChunkyを日本語で再定義すると以下のような感じだと思う。
Chatty（おしゃべり）
サーバで最低限の処理のみ実行し最低限の出力を返す
ChattyなAPIでは目的を果たすためのリクエスト回数が多くなる
Chunky（かたまり）
サーバでまとまった処理を実行し最終的な出力を返す
ChunkyなAPIでは目的を果たすためのリクエスト回数は少ない
単純な例としては、100万件のデータを持つシステムがあったときに
などが考えられると思う。
Chattyだと1万回もリクエスト投げなきゃいけない。そりゃもはや攻撃だよねと思いつつ、
Chunkyだと100万件のデータを一気に取得するのもそれはそれでどうなの？
ということで、常にChattyがいいとかChunkyがいいとかではないよう。
当然ながらどちらの設計が良いのかはアプリケーションに依存するし、リクエストレート制限やデータ量制限などと併用して設計する必要があるよねということが前提。
とはいえ、MiscroSoftのページでも、以下のように言及がある。
Network calls and other I/O operations are inherently slow compared to compute tasks. Each I/O request typically has significant overhead, and the cumulative effect of numerous I/O operations can slow down the system. Here are some common causes of chatty I/O.
要するにChattyなAPIは、ネットワークコールやI/Oの回数が増えるとオーバーヘッドが増え、ネットワークにもシステムにも負荷がかかるということ。
極度なChattyはシステムに負荷を掛けかねないので、一般的には避ける傾向にあるようだ。
最近のハードウェアはある程度のデータチャンクに耐えうるCPUやメモリを搭載しているので、Chunkyでもリクエストの待ち時間はそこまで大した時間にはならない。その一方でネットワークは高帯域を備えていないことも多く問題になることも多いのかもしれない。
