あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト

新春ツール入れ替えシリーズです。macOS における Spotlight 的なランチャーツールとして Alfred を長いこと使ってきたが、最近 Raycast を使ってみてこれがよかったので、以来ずっと使い続けている。 Raycast - Supercharged productivity 開発者のための便利ツールという売り文句のようで、そういう点がまさに気に入った。 カレンダーの次の予定が表示される まずこれがいい。これだけで十分使える。ランチャーを起動したときにカレンダーの次の予定を表示してくれる。Enter でそのまま Meet や Zoom を開いてくれるのでキーボードから手を離す必要がない。 もともとカレンダーの確認には Dato を使っていたし今も使ってるが、これでミーティングへのアクセスがかなりよくなった。 コミュニティベースの Store で機能を追加できる https:

社内に「来年の今年の目標は『半年早く動く』です」というエントリを書いて半年が経った。 こういう目標を立てたきっかけは、自分が変化のタイミングとして会社の会計年度（半期）を考えるようになっていたことに気づいたことだった。 同じ会社でマネージャも長いこと続けていると、部下や同僚の退職を見送る経験も多い。これは一般的に言っても、あまり楽しい体験ではない。辞める理由は人それぞれで、ひと括りにすることはできないものであるし、こう考えるのはおこがましい感じもするが、立場的には、自分が何かアクションを起こすことでまだこの会社で活躍してもらえていたんじゃないかと思うのも常だ。そして実際、そのための、たとえば環境を変えるといったことを考えて、準備もしていた場合も多かった。来期まで待っててくれればな……、という具合。 けれど、自分が制度や組織の設計を仕事の手段としてるのでそう考えていたとしても、ひとの人生はそ

Google Apps Script でメールの自動アーカイブの続編です。 https://github.com/motemen/gas-gmail-scripts/blob/master/dist/label-github-issue-status.js GitHub のリポジトリにやってくるイシューや Pull Request って、対応する心的コストがばかにならないので放置しがちなんだけど、すでにクローズとかマージされたものに関しては気楽に流し読みしていいはず。そういうシグナルで自分を解き放っていきます。 Gmail 本体のフィルタルールでもできそうなものだけど、"Closed" を含む〜みたいなルールだとわりと誤爆するので、GAS で書く。 こんな感じにラベルがつけられて、便利ですね。 メールの本文を見て処理を行うだけなら簡単なんだけど、"Closed #42." みたいなのを勝