イラストでわかるDockerとKubernetes

読書レポート

概要

https://m.media-amazon.com/images/I/41g+F7WohJL.jpg

目的

話題のKubernetesを知ってみようと思って購入。
漫画のつもりで買ってしまったことは内緒

目標

なんとなくKubernetesについて知る。

総評

DockerとKubernetesについてイラスト付きで解説されており、雰囲気がつかみやすい。
それでいて、それぞれの技術がどう実現するかまで解説されており、玄人向けの内容も含まれている。

この一冊を理解できれば、コンテナ技術をおおよそ理解できたと言えそう。
Dockerfileはレイヤーキャッシュを意識すると良いという学びを得た。

ピックアップ

1章 コンテナ技術の概要

コンテナに関してざっくりと説明。
よく見るVMとの比較画像が登場する。

2章 Dockerの概要

DockerについてイラストやCUIを交えて解説。
普段使っている人はわかるような内容から、低レイヤーの部分まで触れていて幅広い。

個人的にはレイヤーキャッシュを把握していなかったので、2-2はとても勉強になった。 レイヤーごとにキャッシュを持つので、RUNを一纏めにするよりは、意図ある粒度に分けた方がキャッシュが効く。

あと普段やっている「Build、Ship、Run」も改めて見ると趣深い。
雰囲気でDockerを触っている人は、ためになる内容が多いと思う。

3章 Kubernetesの概要

KubernetesについてイラストやCUIを交えて解説。
イラストがとてもわかりやすいので、サラッと理解した気になれる。

4章 コンテナランタイムとコンテナの標準仕様の概要

コンテナランタイムについて解説されている。
ここがわかるとカッコ良いと思うので、読み返して理解できるようになりたい。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

読書レポート

概要

https://images-na.ssl-images-amazon.com/images/I/41SlY0zvpKL._SX350_BO1,204,203,200_.jpg

目的

オススメされたので読んでみる。
経験だけでチーム活動をしているので、体系的に学びたい。

目標

チーム活動で活かせるものを見つける。

総評

少し前の本だが、今でも現役で通じるところが多いと感じた。

リーダーに急になったときの振る舞い方は参考になるし、有害な振る舞いを正すところは目からうろこだった。
真の意味で他者向き合うためには、ネガティブなフィードバックが大切なんじゃないかと思ってきた。

ピックアップ

1章 天才プログラマの神話

  • コードは隠さない
  • HRT（謙虚・尊敬・信頼） の2点が刺さった。

コードは隠さない

これは結構大事だと思う。
冗長かもしれないが、自分は一日の実装が終わったら、コードをプッシュするようにしている。 いつでも引き継ぎができることを意識して。

GitHubにDraftがあるので、気軽にPRを作って、作業状況を可視化するのあり。 Draftの時点で、コメントで認識違いを気づけるし、積極的に使っていきたい。

HRT

個人としては「君は君の書いたコードじゃない」という所が刺さった。

相手にそう思わせる指摘をしたり、自分もそう思っちゃう時があった。
コードレビューするときは言い回しに気をつけたいところ。

2章 素晴らしいチーム文化をつくる

  • 文化
  • コミュニケーション がこの章のポイントと感じた。

文化

チームには強い文化が必要で、それがないと新参者が入ったときに、その新参者が持ち込む菌に耐えられないと。

サッカーが好きなので、サッカーで例える。
レアル・マドリーにはマドリディスモという文化があり、それは人が変わったとしても受け継がれている。

エンジニアチームも同じなんだろうなと理解した。 変化の受け入れはもちろん必要だけど、慎重にやるべしといったところか。

新参者…というわけではないが、自分たちはコロコロ実装方針を変えてしまっているところがある。 それは新しい人が入りづらくなるし、リポジトリもカオスになってしまっている。

まずは今いるメンバーで文化を整えるのが大事と思った。

コミュニケーション

MTG

自分も本書の記載にある「エンジニアはMTGが嫌い」に該当する。 これは本書である通り、アジェンダがまとまっておらず、何を話すか決まっていないのが大きい。

やはりMTG前にアジェンダをまとめておくことは必要だな。

議論

自分たちのチームはよく議論をするが、それがドキュメントにまとめられる事は少ない。 「スクラムでコミュニケーションを重視する」といえば聞こえが良いが、空中に霧散して、「どうなったっけ？」 となることも少ない。

議論したものについて、ドキュメント化して、霧散しないようにしたい。

3章 船にはキャプテンが必要

本章はなんとなくエンジニアからリーダーになってしまった人に向けたものだ

上記に書かれているように、いきなりリーダーになった人向けの内容となっている。

エンジニアがマネージャーになることを嫌がる1つに、コードを書くこと = 仕事していること

上記は去年スクラムマスターになってみて実感した。

今までコードを書くことが仕事だったが、コードを明確なアウトプットが期待できるので手応えがある。 しかし、スクラムマスターでチームビルディングとかを業務にすると、明確なアウトプットが無いことが往々にしてあるため、手応えがないことが続いた。

自分の仕事を測る指標が変わったことは意識する必要があったな。

アンチパターン

  • パフォーマンスが低い人を無視する
  • みんなの友だちになる
  • メンバーを子供として扱う

ここを読んで、他者と他者のキャリアに、ちゃんと向き合うことが大切なんじゃないかと思ってきた。
ポジティブフィードバックだけじゃなく、ネガティブフィードバックもできること。向き合うってそういうことだよなと。

4章 有害な人に対処する

「有害な人」とタイトルは銘打ってあるが、正しくは「有害な振る舞いをする人」である。
振る舞いは正すことが出来るので、その対処方法が書かれている。
「有害な振る舞いをする人は、自分のアクションが有害だと気づいていないので、まずは気づきを与えよう」と書かれているように感じた。

長期的に考えるという部分が大事だと感じた。
ここでは、短期的なメリットを得ることで、長期的にデメリットになることを防ごうと書いてある。
※成熟した文化を壊す必要がないという意味

これは確かにそうだなと思っていて、「リリース優先」と言われると現場猫してしまうが、それが長期的には良くない結果になると思う。
勿論バランスなんだが、「長期的にどうか？」というのは頭に置いておくべきだろう。

5章 組織的操作の技法

理想のチームにしていくために、組織の中でどうやって振る舞っていくかを書いてある。
所謂「社内政治」に触れていたり、何をやっても改善しない場合は「逃げる」ことも述べられていたり、こういった本では語られない部分がある印象。

「攻撃的な」仕事と「防御的な」仕事は参考になった。
ここでは、ビジネス貢献のあるものを「攻撃的」、リファクタリングといったユーザ貢献が少なくみえるものを「防御的」と呼んでいる。
防御的な仕事は大事だが、そればっかりあるとビジネス貢献をしていないように見えるので、攻撃的な仕事とバランスを取る必要があると述べられている。

ちょうど自分たちの部署は毎月10%は保守に割く方針をとっているので、アプローチは近いなと思った。

6章 ユーザも人間

対ユーザの話。
ユーザを意識しないと良いソフトウェアは作れない。

複雑さを隠すという章が印象的。
ユーザが楽にできることを意識すると、コードが複雑になることがある。
そういった部分に自分は消極的であったが、たくさんユーザに使われるものを作ろうとしたら、そういうことを意識する必要があると考え直した。

アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット

読書レポート スクラム

目的

https://images-na.ssl-images-amazon.com/images/I/51wpYhLduAL._SX348_BO1,204,203,200_.jpg

ふりかえりがマンネリ気味（というか楽しくない）のでなにか打破できる内容がないか。

総評

ふりかえりにマンネリを感じていたが、これ読んでアプローチしたいことが、いっぱい見つかった。
最初に出てくる3つの段階を意識して、自分たちはどの段階か考えて、手法を検討したい。

ピックアップ

基礎編

いきなり大事なこと書いてある。ふりかえりは3ステップで順番に進める。

  1. 立ち止まる
  2. チームの成長を加速させる
  3. プロセスをカイゼンする

信頼関係がない状態で3に行くと、原因追求が発生し、隠蔽体質なチームになる可能性がある。 自分たちも改めて2を意識して、信頼関係ができているかは考え直したい。

実践編

漫画を中心にふりかえりの方法やマインドセットが説明されている。
方法や準備のところは、ふりかえり経験者なら大体理解していると思う。

マインドセットでふりかえりは「全員がファシリテーター」と記載されている。
主体的なファシリテーターはローテーションしているが、それ以外のメンバーも円滑に進めるために、発言・準備をしようと。

みんなで場を作ることが大事だなと思いました。

手法編

DAP(Design the Partnership Alliance)がとても良いなと思った。
これを決めてから始めることで、ふりかえりの雰囲気をみんなで作ることができるなと。

どんな感じでふりかえりをやるか決める

どんな雰囲気でやるか
どんな内容をやるか
全員が合意できる内容にする

etc.) 楽しく、感謝する

早速取り入れようと思う。

また起票する際は事実と感情を載せると良いらしい。

例えば「バグが出た」よりは「バグが出たことで焦った」の方が情報量が多い
「バグが出たことで焦ったのはなぜか？」を深堀りすることで、メタ認知につながるから。

また複数人が同じことを思ったのであれば、それはチームとしての課題と捉えられる。

プラスの感情も同様で、「AWSを触って楽しかった」と書き、他の人も共感できると、チームとしてのモチベーションUPに繋がる。

これも確かにその通りで、感情を載せることで情報量が増えるし、質問の深堀りもしやすくなるなと思った。

Tips編

ここはふりかえりについての悩みと回答、スクラムガイドのスプリントレトロスペクティブに触れている。
スクラムガイド2020をベースに解説されており、資料としての信頼が高い。

ポジティブという単語は「前向き」という言葉以外に、「建設的」・「実用的」という意味がある

ここらのニュアンスは大事だなと思う。
楽しさということも勿論大事だが、建設的であることは生産活動において大事だと思うので、混同しないようにしたい。
※仲が良いことと心理的安全性が高いことは違うように

初めてのE2E

勉強 PHP

E2Eテストとは

End to Endのテストの略で、システム全体を通したテストを行うこと。
Webサービスで言うと、ブラウザ上からテストを行うこととなる。

メリット

ブラウザ上から実行するということで、よりユーザに近い環境でテストを行い、品質を担保することができる。
その結果として、ユーザに影響が出ていないことを担保できる。

難しい点

ブラウザ上から実行するためには、事前の準備が必要となる。
単体テストであればモックを使うことができるか、E2Eはそうはいかないので、DB等一通りのミドルウェアの準備は必要。

またHTMLの構造が変わりやすい場合、E2Eテストが動かなくなる恐れがある。
構造の変化に追従するコストも払う必要がある。

ブラウザ上から実行するということで、よりユーザに近い環境でテストを行い、品質を担保することができる。 その結果として、ユーザに影響が出ていないことを担保できる。

実行

Puppeteerとは

Chrome / Chromium を動かす Node のフレームワーク。 デフォルトは Headless（GUI を持たず、コマンドで操作できる）で、ブラウザを出しての操作も可能。

Seleniumとの比較

過去によく使われていたツールとしてSeleniumがある。 Seleniumと比べると、下記の強みがある

Webページのステータスコードを判定できる
Chromeに特化した機能もテストできる
出典 : https://qiita.com/okitan/items/a625d68496fc1a11dcd9

一方で下記のデメリットがある

出典 : https://www.cresco.co.jp/blog/entry/15215/

今回はステータスコードも確認できるPuppeteerを使おうと思います。

導入

PHPでPuppeteerを使えるpuphpeteerを利用して、テストを動かしてみた。 https://git.dmm.com/kimura-tsuyoshi/TIL/tree/master/PHP/E2E

コードを動かすとLCのTOPページのスクショを撮る。

躓いた点

Docker上でブラウザを動かすために、インストールするモジュールが多かった

https://github.com/juve534/TIL/blob/c5a61d7d6a1596b17a919036ce147ac782f01ba7/PHP/E2E/Dockerfile#L10

Botmanでテストコードを作成

PHP 勉強

概要

Botmanで作成したコードをテストする方法。

実装

app/tests/BotMan/ExampleTest.php を例に進めていく。

感覚的にはPHPUnitと同様に、メソッドを実行し、返り値を判定する形となる。

シンプルな Hi のテストをベースに解説していく。 1. $this->bot->receives にBotmanで実行したいキーワードを設定する。 2. assertReplyで返り値を判定する

public function testBasicTest()
{
    $this->bot
        ->receives('Hi')
        ->assertReply('Hello!');
}

assert系のメソッドはapp/vendor/botman/studio-addons/src/Testing/BotManTester.phpに定義されているので、テストコードを書く前に一読し、自分のテストに使うものを選定すると良い。

参考

BotMan - Testing

画面外clickでポップアップを閉じる

勉強 JS jQuery

概要

画面外をクリックしたときにポップアップを閉じるってやつ、結構ありますし便利ですよね。
今回はそれを実装します。

やること

documentまたは、id要素に対してクリックイベントが発生したときに、クリックした対象が該当DOM以外であれば閉じるようにする。

$(document).on('click touchend', function(event) {
  if (!$(event.target).closest('#target').length) {
    // ここに処理;
    $('#target').hide('slow');
  }
});

参考

範囲外クリックでポップアップを閉じる正しい JQuery

Laravelで発行されるクエリを確認する

Laravel 勉強

概要

LaravelのORMやクエリビルダで発行されるクエリを見たい時がある。 毎回調べるのが億劫なので、ここにメモする。

やり方

クエリを見たい箇所に下記を挟む。

\DB::enableQueryLog();
モデルでもRepositoryでも可
\DB::getQueryLog();

参考