2018-09-13

過渡期

いま過渡期だと感じていて，ウェブサービスを作るときにネイティブで動かすかDocker内で動かすかという話題があるとして，各自のコンピュータに合わせたセットアップをしたい人はいなくて，Dockerでやる派の人が多いと思う．もうちょっと離れると，開発のために使うツールたちをどう入れるかという話になって，Macを使っていたらHomebrewで入れるか，Dockerで入れるかという話が始まる．今日はチーム全員でAWS CLIを使うようにしたいという話で，Homebrewで入れるかDockerで動かすか(公式イメージではないけどビルドは自動化されている)という話をしていた．さらに引いていくと，DockerをDockerで入れて動かすことはできないのでそこで話が止まると思う．

2018-09-12

自分を退職に追い込む動きをすると良い

去年，いまのチームに来たときは僕がフロントエンドのリファクタリングを進めたり面倒を見たりしていた．JS得意な友達がバイトに来てくれるようになり，今はその人がBabelを入れたりしてくれている．彼がバイトに来てくれなかったら，いまだになんとなく興味があるので見ますみたいな感じで一人で面倒見ていた気もする．

よくある話で，属人性を高めないように自分の知識を展開しましょうという話があるけど，具体的にアクションプランを考えてもどれが一番良いのかわからない．抽象的に考えると，自分の仕事をなくして退職に追い込むような動きをすると良い．周りのレベルが上がったり移譲されたりしてその分野で価値を発揮できなくなってれば自分じゃなくてもできるようになっている

自分でなくても実装できるようになって，作戦の相談に乗ったりとかしていると，次はそこの属人性が上がってきて，自分のバリューを再びなくすには，誰でも計画を立てたりメンタリングしたりできるようにしましょう，という話になる．今の課題はそこだと感じている．

順調に自分を退職させる動きができると，自分の動きがだんだん抽象的になったり，得意だからといって担当になることがなくなる．得意だった分野も日々得意分野でなくなっているので誰でもできるようになっているはず．

ということをやりつつも職がなくなると困るので，それを回避するような動きもしていくと良くて，そこは勉強するとかがんばるとかそういう動きになると思う．

自分で圧をかけつつ圧を返していくような，深海魚を突然地上に持ってくると，通常の深海魚なら爆発してしまうけど，すごい筋力のある深海魚なら，ぐっと力を入れると爆発せずに済むというイメージが有る．伝わるでしょうか．

2018-09-12

■

皿を洗うの面倒だったけど，酒を飲みまくってなければ意外と大丈夫なことがわかってきた．

以前はカレーを4人前作って，酒を飲みまくり，プライムビデオを3時間くらい見て，朝に片付けようって放置したりしていた．

ほどほどにしておけば食事が終わっても意識があるのでそこから皿を洗ったりできる．

鉄の鍋はすぐに洗うようにしていて，放置するのはテフロンフライパン．調理中にくっつかない性能の高さから雑に扱われるという悲しき事例．

2018-09-11

コードレビューするタイミング

みなさまどんなタイミングでコードレビューされてますか．僕はふだんこういうタイミングで見てます．

気が向いたら /notifications とプロジェクトの /pulls を見てレビュー依頼があったら見る
- メール通知とかはあまり見てなくてインターネット巡回するような感じ
自分からレビュー依頼を1個出したらそのついでに見る
- ほかに見れそうな小さいのがあったら見続ける
アルバイト氏は出社日が限られているので，次の出社日までに見る
- その日にレビュー依頼されたやつを出社日中にレビューできると1日でマージできて便利だったりする
ずっと見てるようなやつは見れる人を増やすため，なるべく他の人に見てもらう
締め切り前とか盛り上がってきたときはレビュー依頼担った瞬間に拾いに行って，チーム内で1日何十件もマージしていた

2018-09-10

進化的アーキテクチャおもしろかった

ThoughtWorksの人たちの本．普段遭遇しているような問題がまさに書いてあって面白かった．

ユーザーはビッグバンリリースを望んでいる
- > ユーザーは定期的に現れる新機能の弾幕を望んでいない．
独自のフレームワーク，インフラを作ってしまい，その後オープンソースで同じことができるようになっても固執して移行しない
githubのscientist
- GitHub - github/scientist: A Ruby library for carefully refactoring critical paths. 新旧二種類のコードを書いておく，メトリクスを収集して，安全に置換可能か調べられる
- > より良いアプリケーションを構築する上でイノベーションを起こす代わりに，彼らは配管の中であくせくずっと働いていた．
マイクロサービスのサービステンプレートの話
- マイクロサービスはコードを共通しなくても，認証やロギング，サービスディスカバリなどの機能は必要，その部分をテンプレートとして用意しておく
サービスの規模に応じて大中小で3種類の技術スタックを選ぶ例
- 大規模プロジェクト用のJava，中規模用のGo，小規模用のRuby on Rails，みたいな
  - 毎回いちから選定するんじゃなくて規模で選ぶのはよさそう
アンチパターン:製品のカスタマイズ
- 製品を売りたいがために無限にカスタマイズ可能なソフトウェアを作ってしまう
- カスタマイズの組み合わせが爆発する
DevOpsの話
- 運用チームの助けなしにQA環境を自動的に構築できるようになると便利そう．ちょうど会社でも同じようなムーブメントがある