たまたま代休を取っていた5/29に発売だよ〜という事に気付いて嬉しかったので、積ん読消化順を差し込んで読んだ。
書籍のタイトルと翻訳者の名前を見て即買いした次第。
- 作者:Ivar Jacobson,Harold “Bud ”Lawson,Pan-Wei Ng,Paul E. McMahon,Michael Goedicke
- 発売日: 2020/05/29
- メディア: Kindle版
- どんな本でしたか?
- こんな人に良いんじゃない?
- 読後の感想
- 内容に関するメモ
- まとめ
たまたま代休を取っていた5/29に発売だよ〜という事に気付いて嬉しかったので、積ん読消化順を差し込んで読んだ。
書籍のタイトルと翻訳者の名前を見て即買いした次第。
連続でツイートを飛ばそうかと思ったけど書いてる内に止めたやつ。
少しだけ編集して 最終的に色々と足した感じで、ブログに残しておく
① 例えばコーディング規約とかの「比較的ありふれている」と言われるようなプラクティス(各論的な方法)ですら合意を得て導入するのは簡単じゃないので、考え方はバラバラでも良いけど考えている事は揃えたいよね〜的な
② 自分の場合はそういうの入れる時はまず「憲章」から設けるようにしているし、実際に前職で新規レポジトリ作った時は「前段」を入れたりした(当時は、今ほど深く考えていなかったけれど)
コーディング規約 for small team 2018 - 大好き!にちようび
③ こういう「行動を縛るルール」は、道標として機能していれば良く、逆にプラクティスレベルで「どうした方が良いか」の認識がチームで揃っていれば本来的には不要なはず〜って思うと必要悪な感じはする。
④ コーディング規約だと具体的・卑近的すぎて「それが無いほうが理想」というのを想像し難ければ、例えばcode of couduct。アレとかは、「もし無くても皆が求められるような理性的な行動をするならば」という前提で、本当は存在しなくても良いのでは?と。
⑤ こういった「無くても良いのに有るものを減らす」というのが文化の力なんだろうな〜って思う。
もちろん、他の側面では、自分たちを内省して「発見」されたものを言語化して記述して、理想への眼差しを他人同士の見ているもの揃える〜という、文化に対する補佐的な機能が「明文化すること」にはある
⑥ 最近事あるごとに「やり方を上から与えられると歪むのではないか」「どうやって、草の根で文化の力を育むか」みたいな事を考えてたけど、多分こういう事なんだろうなー。決まりがあって人が動く、というのが楽しいかどうか・・下手すると権威だけがそこに残るのではないか・・
と、ここまでがtwの下書きから引っ張ってきたもの。
折角ブログに場を移したので、もうちょいグダグダと書く。
<>
「文化が〜〜」みたいな概念が最近は結構お気に入りで、これはfukabori.fmのエピソードを聞いてハッとしたのがきっかけ。
25. 日本企業を辞めてカーネギーメロン大学へ入学し、Nianticで働くまで w/ noralife | fukabori.fmの30分辺りから。 ↓該当部分の書き起こし
文化っていうのは行動に現れるものである。 要するに、何かを言わなきゃ何かができない・・例えば、すごいわかりやすい各論の話ですけど、会議をした時にその議事録が残っているとか、アジェンダが用意された上で会議に臨んでいる。みたいな行動があったとして、言わなきゃできないんだったらそれは文化じゃないですよね。 何も言わないのにアジェンダが会議に用意されていて、Googleカレンダーに貼ってあって、会議が終わるとアジェンダに議事録のメモが書き起こされて、全員が見れるようになっている。それを、いちいち誰にも言わなくても、全員がそういう行動を起こせるっていうのが、文化として根付いている。そういう行動様式、行動をとりましょうねっていうことだと思うんですけど。
この時に「小さなチーム、大きな仕事」が言及されているのだけど、該当部分を引用するとこんな事が書かれている。
文化はつくるものではない
即席でつくった文化は人工的だ。ミッション・ステートメント、宣言、ルールからなるビッグバンみたいなものだ。わざとらしくて、醜く、見せかけだけだ。即席の文化は絵の具のようなもので、本物の文化は緑青のようなものだ。 文化はつくるものではない。自然に発達するものである。だからこそ新しい会社には独自の文化がないのである。文化とは普段の振舞いの副産物だ。わかち合いを奨励している会社では、それが文化に組み込まれる。信頼を重視すれば、それが組み入れられる。もし、顧客を大事にしているなら、それが文化になる。 文化とは方針ではない。社内のサッカー盤や、社員の信頼を深める研修、クリスマスパーティーやピクニックでもない。それらはただの物や行事で、文化とは程遠い。スローガンでもない。文化とは行動であり、言葉ではない。 無理に文化をつくろうと考えないことだ。上等のスコッチのように、熟成には時間がかかるのだ。
ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン. 小さなチーム、大きな仕事 働き方の新しいスタンダード (Japanese Edition) (Kindle の位置No.1604-1615). Kindle 版.
この「文化とは行動であり、言葉ではない」という部分。 恐らく、自然と過ごす中で育まれ(熟成)、発見され、強化されていくものなんだろうな〜って気がする。
その途中で「それを守るために言語化していくことも必要になってくるタイミングがある」というのも先述のpodcastの中で触れられていて、直近の例でいうとnote社についての発信にそれを感じた。
「文化とは、そこに居る人が何も言わず・言われずとも自然とそう動くこと」「ただ、それを守るために言語化していくことも必要になってくるタイミングがある」のやつだhttps://t.co/QVNnDgqGso
— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2020年5月6日
これなどは、「元々みんながそうしていた事」であって、何も「生み出した」りしていないというのがポイントだな〜と。
何もない所に、人工的に作った何かを根付かせようというのは違うはずだ。
冒頭の「コーディング規約」については、実際問題としては「いやいや文化とかそういう類いじゃないでしょ、生産性に絡む類の規律でしょ」という見方もできそう。ただ、ちゃんと「文化」による支援を得て成立できるといいよねぇ。。。というのが、個人的な感情としてはある。
そして、そういう狙いの場合は殊更「トップダウンで決める」というのがとても難しいのじゃないかなぁ〜とも感じるところ。不可能とは言わない。強力なリーダーシップやカリスマがあれば、寧ろ迅速で効果的に導くこともできそう。
「組織のルール」と「組織の文化」が一致していると強いよねぇ〜という話でもあり。
先日、社内で「変えるのは簡単でトップ(CTOやマネージャー)に言えばそれをイエスやノーにすることは可能。なので、意思決定をしたいならCTOを巻き込むのが早い」という意見や「(トップから落とすのではなく)草の根的にやって、そこから大きなムーブメントが生まれることを期待したい」という意見が交わされるような議論を目にした。
コレなどはまさに、最終的なゴール=組織の理想状態を考える上で「決まり事を作る」という手段にどういう段階で手を出すか?といった見方の相違なのではないかなーと感じる。
恐らくナラティブの概念を補助線にすると問題の構造が見えやすい気がする。
組織の中でベテラン的な存在や(意思決定ツリーの)トップラインに近い位置にいる人などは「規律を作ってから動かす」というアプローチを採用しがちなのかもな?と考えている。彼らは比較的、「組織は理想を持って動くもの」というのを(ともすれば無自覚に)抱いている可能性が高いからだ。なぜなら、組織を「作ってきた側」にあるから。
他方で、若手や ボトム側の人間は、組織やその理想と個々人の気持ちよさだったり納得感というものは「一致していない」のが前提に感じている可能性が高いのではないだろうか。
「ルールがあれば上手くいく(そうなるように頑張ろう)」と思っている人と「ルールなんてファックだ、心で合意できないものが価値を生めるか」と思っている人がいれば、そりゃ対立するよねって気がする。*1
「文化」というのが問いで「ルール」というのが答えだとしたら、やはり文化の方がしなやかで強い組織を育むものと思っている。
自発的に、自他に問い続けることができるチームは、本質への追求を原動力に動けるし理想のための変化を恐れないんだろうな〜と。
カルチャーに導かれて一個にまとまる状態・・・
話が逸れかけましたが、まぁなんというか「気持ちよく働きてぇな〜それが出来ていないって時には何を観察したらいいかね?」という徒然でした。
*1:言うまでもなく私は「気持ちよくやりたいから」後者でいたい、という立場。ただし難易度上がるし時間のかかる道ではあるというのは承知。「動けばいいや」なら前者でいいが、エンジニアって呼ばれる職業やってんだから内部品質の重要性は分かってるでしょ・・?
遅ればせながらリリースしました🎉
connehito/cake-sentryというのは、前職時代に開発していてその後もメンテナに入れてもらっているOSSです。
半年ほど前に、メジャーバージョンアップをどうにか終えました。
daisuki.nichiyoubi.land
この時は「Sentry SDKがリデザインされたので新しいのを使うようにしようよ」だったのですが、1ヵ月ほど後に今度は「CakePHPが新しいメジャーバージョンを出したよ」ということで、それの対応をやらねばやらねば・・・・と今に至ったわけでございます。
cake4はおろかcake3ですら触っていない状況になってしまっていたので、どうにもこうにも腰が重く。*1
そうこうしている間にコミュニティの方々からPRをもらったので、よしコレを基礎としてリリースまで持っていくぞ!!!という気持ちがやっと湧いてきたのでございます。
3つ目のPRである#34をもらった時点で「大まかには動くじゃろ」というのが確認できて、またPRに書いてもらった説明から「どんな感じに変わったの?」が読み取りやすかったので、こらが大変背中を押してくれるような結果になりました。
わかりやすいPR大事だな〜〜〜〜!
久しぶりに全体的にコードを眺めてみる〜という行動になったので、いくつか気になった点を修正したりもしています。
その中でコードカバレッジが100%になったりもしました。ソレ自体はあんま意味のある数字とも思っていないけど、まぁ折角ならキリの良い数にしておいた方が気持ちいいじゃんね!!くらいの。そもそも「あと何行かくらいだし、100%にしておこ」という軽い気持ちで手を出したら「実際にはそこに到達しない(手前でエラーになっている)」という箇所が炙り出せたので、良かったなぁという気持ちです。
他には、久々に全体的に見返していて「名付けが一貫性無いかもな・・・?」と感じた部分をシンプルにしたり、といった事をしています。
今回の改修に関して改めて感じましたが、「そのプラグインを動かすために必要な環境を一緒に梱包しておく」のは、やはり良いですね〜。
CakeSentryでいうとtest_app
という形でdocker-composeと動作デモ用URLを混ぜてありますが、コレのおかげで、開発に際して必要なことに集中できた感じがあります。
cake-sentry/tests/test_app at master · Connehito/cake-sentry · GitHub
コレやってなかったらもっと億劫だっただろうなと・・・・・・
折角Dockerfileもあることですし、Sentry側の変更等への追従を保証すべく、E2EっぽいものをCI上で回したいなぁという野望も抱いていたりします。
「web/cliでエラーを起こして→Sentry側に登録エラーを問い合わせて→登録されるべき形で今のエラーが登録されているか」みたいな。
これをスケジュール設定して動かしておけたら良さそうな感じするんですよねぇ。
作ったものを使ってくれている人がいるのは有り難いなぁ〜〜というのを改めて感じた次第。
PRくれた人に対してどこまで直しをお願いしようかな・・?というのは割と悩ましく感じたけれど、早め早めでマージしつつ気になった所は自分で直す!!くらいの温度感が良さそう〜というのを今回の流れの中で感じました。業務コードだったり相手が同僚だったりした場合とは別だな、と。
折角関わってくれた人に対して敬意を表したいぜ〜〜〜!の気持ちと、少しずつでも前進させていくやり方をとりたいな〜という気持ちと。
今後もメンテちゃんとやっていくぞ〜〜
*1:cake3使っていれば多分cake4移行やろうぜ!!というモチベーションで動かしているだろうにな、とも思いつつ。
いい加減コイツを前に進めねば・・・・・・・・というアレね。
で、有り難いことにPRに要点をまとめてくださっており、フムフムなるほど〜って言いながら読んでみたのですが、マージするに当たってはちゃんと自分の目でも確かめてみないと何とも言えんっていう。
ポイントを掴めた状態で読んでいけるのは有り難い!!
Updates for CakePHP 4 by BGehrels · Pull Request #34 · Connehito/cake-sentry · GitHub
内容をちゃんとまとめたらcake縛りブログに移そうかと思っているけど、とりあえず雑にでも良いからメモを残したい意図でコチラのブログに書きます。
cake3でエラーロガー作った時も同様の調査をしており、「どういう風に流れるか」を掴んでおくと「どういう風に干渉すれば良いのか」が見えるので、やろうと思いました。↓はその時に書いたやつ。
まだcake3歴が浅いタイミング*1だったので探り探りで書いてるやつだなーって印象があるけれども。ErrorとExceptionの差とかもそこまでよく分かってなかった時だぁ〜
で、これと同じようなことを、これと似た動機*2でやっておこーぜというわけです 。ワクワク
なので最重要なのは「エラー処理の流れを追うこと」だ、と。
まずはwebのException、弱いエラーをそれぞれ見ていきます
今回は PagesController::display()
の中から \RuntimeException
を投げてみる
とても良かったのは、cake3の時期に比べてMiddlewareがLoggerに直接依存していたところが解消されていて、ErrorHandlerの(名前の通りの)存在感が増した所です。
(↓のPRの参照)
と同時に、「ErrorHandlerMiddlewareでキャッチされた例外にリクエストコンテキストを扱ってLogに残したい」というのが、コレまでは「Middlewareごと拡張する」という方法しか無かったのも解消しています。
ErrorHandlerはErrorLoggerに対してRequestオブジェクトを渡してくれるんです。やったね!
同じく、 PagesController
のアクション内で trigger_error()
をした感じです。
とてもシンプルでいいですね!
なお、エラーレベルによっては(=致命的なエラーの場合は)、handleError()内で処理が変わるので注意が必要。注意、といっても「そりゃそうだよね」って感じですが 💨
ハンドラの登録ですが、これは BaseErrorHandler::register()
で行われます。
という訳で、基本的には config/bootstrap.php
内の処理として、ハンドラが登録される感じです。
これと同様にConsole系の処理も追う必要があるのですが、今回は取り敢えずやりたいことが出来たのでwebのみの内容に絞って放出してしまいます・・
ErrorHandlerとエラー用のLoggerがどのタイミングでセットされるか?というのも合わせて抑えておくことで、cakeのエラー管理をしっかり行いやすくなると思います。
*1:といっても2018-03なら半年くらいか?業務で必要だったから「エラーを捕まえてSentryに飛ばすようにする」はこの時期だと既に作れていたような気もするんだけど、どうなんだろ。
でもPhpStormをちゃんと使うようになったキッカケの1つだったのは覚えてる!
*2:ず〜〜〜〜〜っとcak4対応やらねばやらねば!!と思っていて滞っていたわけですが、コレの理由の大きな1つが「CakePHP4への変更のキャッチアップをシないといけない、大変そう・・」というところで億劫になってしまっていた面があり。こういう時に、自分が直接のユーザーに慣れていないプロダクトつらいですね。。
ただ、「よく考えてみたらエラーハンドリング周りとプラグイン周りの2箇所だけ追えば、あとは動くな?」という事にふと気付きました。
あと、とにかく「使ってみてもらえるようにして、フィードバックを集められるようにする」方が大事かも知れん。
昼休みブログチャレンジです。
昨日は日曜日でしたので、「Real World HTTP」の第2版を読みました。
Real World HTTP 第2版 ―歴史とコードに学ぶインターネットとウェブ技術
Amazonリンクを貼っているけど自分はオライリーの電書で読んだ。先のエントリーに載せたとおり、「PC Kindleで読むの楽だな〜www」というのをやっています。
(ただPDFファイル読みにくかったので、epub -> mobiにして読んでいます)
その感想とかのメモ
「はぁ〜、色々とインプットが足りない〜〜足りなすぎる〜〜」って感じが爆発してきたので、今年のGWは「本を読むぞ!」という過ごし方をしていました。