第2回社内輪読会として「オブジェクト指向でなぜつくるのか」を読み合ってみた
はじめに
社内有志メンバーで「オブジェクト指向でなぜつくるのか 第2版」の輪読会を行いました。
前回の輪読会の好評がとてもよく、続けようとなったので第2回として開催しました。
前回の輪読会についてはコチラ
ohshige.hatenablog.com
オブジェクト指向でなぜつくるのか 第2版
今回の課題図書は「オブジェクト指向でなぜつくるのか 第2版」です。
- 作者:平澤 章
- 発売日: 2011/04/07
- メディア: 単行本
普段扱っている言語の関係上、オブジェクト指向を使うことが当たり前になっていますが、一歩引いて「なぜ？」という観点から見れるということでこの本が選ばれました。（たぶん）
輪読会
全体の流れは前回と同様に、日付と範囲を決めて当日までに全員が読んでから参加し、持ち回りのファシリテーターが当日議論を回すというものです。
そして、今回は4月から入社した新卒1年目もメンバーに加えての開催となりました。
参加メンバーの幅がさらに広がり、議論も面白いものになっていたと思います。
また、ほぼコロナ自粛期間だったのでオンラインでの開催がほとんどでしたが、全く問題なかったです。
やってみて
本書は「オブジェクト指向でなぜつくるのか」というタイトルではありますが、それだけにとどまらず、プログラミングの歴史や仕組み、UMやデザインパターン、開発手法、関数型プログラミングについても載っており、守備範囲がとても広かったです。
実際の内容に関しては是非読んでみてくださいという話になってしまいますが、オブジェクト指向やプログラミングの初心者や初級者にとっては幅広く学べるため、とても合っていると思います。
また、ある程度プログラミングをしてきてはいても、メモリの仕組みやデザインパターンについてなど、意外と知らないことにも出会える可能性は高いです。
ただ、歴史的経緯であったり定義であったりの説明が多いので、輪読会の課題図書としては議論の余地があまりなく、やりづらかったかなという印象です。
どうしてもただの感想になってしまう場面が多かったので、そういう点では期待通りとはいきませんでした。
もちろん、議論を目的としない場や個人での読書であれば、上述の通り初心者にはとても良い本だと思います。
さいごに
良書と呼ばれる本でも輪読会（議論の場）の場合は合わないこともあるのだと感じることが多かったです。
個人で読む本と輪読会で読む本と見極めつつさらに続けていこうと思いました。
「みんなで早押しクイズ (みんはや)」でエンジニア力なるものをアップさせるのが楽しいし良さそう
最近、コロナの影響で全く外出できず、暇で暇でしょうがない。
そんな中、みんなで早押しクイズ、通称みんはや、というアプリにハマってしまいました。
minhaya.com
競技クイズのようなものを1対1だったり複数人だったりで対戦するアプリなのですが、細かい紹介はたくさん紹介記事等あるようなので省略します。
ここで紹介したいのは、「作問」という機能がとても良いということです。
作問機能として、問題と解答を入力して自分だけのオリジナル問題集を作ることができます。
みんはや内のフリーマッチを見ると、たしかに様々なオリジナルの問題で楽しまれていそうです。
作問してみたいと思い作ったのが、コンピューターサイエンスの基礎から我々の職種に関わるような用語に関するクイズです。
新卒1年目が配属されたもののリモートで一緒にやりづらく技術レベル感を把握しづらかったり、業務としては活躍しているけれど意外とCSの基礎を知らないメンバーがいたり、単純に暇だったり、ピッタリかもしれないと思い、作問しました。
例えば、次のように幅広く問題を作ってみました。
1バイトは何ビットでしょう？
「あるクラスやモジュールやコンポーネントに任せる仕事は1つであるべきだ」という原理原則を日本語で何というでしょう？
整列済みのリストや配列に入ったデータに対する検索を行うにあたって、 中央の値と検索したい値との大小関係を比べて、その結果を踏まえて中央より前半か後半のいずれかを調べて、と繰り返していくアルゴリズムを日本語で何というでしょう？
機械学習のアルゴリズムにおいて、グルーピングやクラスタリングなどの構造を見つけ出すことを目的として、入力のみからモデルを構築するものを何というでしょう？
サーチエンジンの検索結果で上位表示するために、Webサイト内のコンテンツや構造を最適化する施策のことを、アルファベット3文字で何というでしょう？
このような問題をただ一覧を眺めて勉強するのもつまらないと思います。
みんはやでクイズ形式で競争しながらやることで、楽しみながらもレベル感を把握でき勉強にもなるという仕組みです。
実際に数名でやってみましたが、とても盛り上がりました。
一番楽しんでいたのはみんなが解答している様子を見ている自分だった可能性はありますが。
是非一緒にやりましょう！
社内で「ドメイン駆動設計入門」の輪読会を主催して大満足
はじめに
社内有志メンバーで「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」の輪読会を行いました。
一人での読書であったり、ABDは何回かやってきましたが、輪読会という形式は初めてでした。
もともとは会社の分報でいつものごとく雑に募集してみたら多すぎず少なすぎずの人数になりそうだったので、開催して進めてみた次第です。
ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本
この本は、PHPerKaigi 2019のPHPer チャレンジで1位だったりCMでもおなじみの @nrslib さんの著書です。
ブログもいつも読ませていただいて、それを元に大幅にボリュームアップしたということで、買って読まなくてはと思っていました。
ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本
- 作者:成瀬 允宣
- 発売日: 2020/02/13
- メディア: 単行本（ソフトカバー）
輪読会
DDDをしっかりと実践できたことがなく、周りにもそういうメンバーはいませんでした。
そういう状況であるなら、1人で読み、1人でフムフムと言っていても仕方がないのではないかと感じて、皆で読んで議論することがとても効果的な読書法なんじゃないかと思い、輪読会を主催することにしました。
ABDにしかなかった理由は、一応章ごとに独立してるとは言え、前半で出てきた用語がわからないと後半は理解しにくくなるかもしれないと感じていたからです。
結果的に、ありがたいことに、6人でやることになりました。
やり方としては、全15章＋APPの章立てのところを2〜3章ずつ全6回に分け、週に1回の会を設け、その会までに該当の章を全員が読んでくるようにしました。
当日は、担当者がファシリテーターとなり、その章の簡単なまとめと議論の進行などを行う形式にしました。
全6回で6人いるので、1人1回はファシリテーターをすることになります。
輪読会というと、1人が読み込む人となり会当日に他のメンバーにプレゼンをする形式もあるかと思いますが、そのような形式はとらずに、必ず全員が事前に読んでくるようにしました。
理由としては、本書がコードも結構載っていて意外と分量が少なく苦にならないのではないかということと、プレゼン資料を作る時間が勿体ないということと、議論メインにするために前提条件を揃えたかったということがあります。
やってみて
集まったのは、新卒1年目から社内では中堅と呼ばれるメンバーまでで、扱う業務も一部異なっており、議論は全体を通してかなり盛り上がりました。
同じ年次のメンバーだけでやるより、かなり効果的な会になったのではないかと思います。
中堅メンバーは色々な経験をしている分、本書で出てきた表現に関して「わかるわかる」と頷きつつ、それがすべて正しいかったわけではないと理解しつつも、若手が業務になぞらえて話題を提供したときには過去の経験の話をする場面も多々ありました。
若手メンバーとしては、本の内容だけだとどうしても机上の話になってしまいがちなところを、中堅メンバーの実業務での経験も交えた話が加わることで現実感が増し、想像もしやすかったということがありました。
逆に、中堅メンバーとしては、これまでの自分の仕事や考えがすべて正しいわけではないと考えているときに、本書の説明を読んで、「あれは正しかったんだ」「あれはこうすれば良かったんだ」と物思いに耽る場面もありました。
本書のような設計や、他にもアーキテクチャ、思想などの話は、原理原則とは異なり、全てを無条件に受け入れられるわけではありません。
そのため、1人で読んでいるだけだとモヤモヤしたまま終わってしまっていたかもしれないところを、声に出して議論できた点はとても有意義でした。
意見が異なっていたり、同じ意見であったり、過去の経験からの補足を聞けたり、新鮮な意見を聞けたり、大満足でした。
コロナの影響で外出自粛で在宅勤務となり面と向かって輪読会はできなくなりましたが、オンラインで続けることができていて、幸か不幸か読書の時間も確保しやすくなりました。
さらに、とても良い会だったので、次の課題図書も決めて第2回が開催されることが決まりました。
オンラインかオフラインかはコロナ次第ですが、良い本で良い知識をどんどん吸収し、いろいろなことに生かしていきたいと思います。
さいごに
ドメイン駆動設計入門はかなり読みやすく、わかりやすく、とても勉強になりました。
翻訳本にありがちなぎこちない日本語や理解できない謎のジョークは、もちろん一切出てこないので、それもありがたいです。
他にも、強強な方々が日本語で素晴らしい本を書いていただけるととてもありがたいですね。
CloudWatch Alarm と Slack の連携は SNS + Lambda ではなく SNS + AWS Chatbot が簡単で管理も楽
CloudWatch AlarmはCloudWatchのメトリクスを監視し、それが事前に決めた条件を満たすと通知してくれる便利なサービスです。
例えば、CPU利用率が80%を超えたら通知するといったことができます。
CloudWatch Alarmでの通知にはSNS(Simple Notification Service)のトピックを指定することができ、そのトピックと連携することが様々な通知を実現できます。
通知の方法としてよくあるのはSlackへの通知です。
CloudWatch Alarmによる監視の結果をSlackへ通知するようにすることで、異常にすぐに気が付きます。
そんなSlackとの連携ですが、調べるとよく出てくるのが、サブスクライバーとしてLambdaを使い、LambdaからSlackにIncoming Webhookを用いて情報を送るというものです。
Lambdaの関数を作る際に指定できるテンプレート（設計図）にも「cloudwatch-alarm-to-slack-python」というものが用意されており、これらを使えば簡単に作成し設定することはできます。
ですが、より簡単な方法があります。
それがAWS Chatbotを使う方法です。
aws.amazon.com
AWS Chatbotは現在ベータ版ではありますが、コードを一切書かずに、SNSをトリガーにしてSlackに通知するということがとても簡単に実現できます。
まずは、チャットクライアントとしてSlackを選択して「クライアントを設定」を押します。
そうすると、ブラウザでログインしているSlackのワークスペースについて権限を求められるので、ワークスペースと内容をしっかりと確認しつつ許可します。
これでChatbotとSlackの連携は完了です。
あとは、「新しいチャネルを設定」から、CloudWatch Alarmが通知しているSNSトピックとSlackの好きなチャンネルを組み合わせるだけで、CloudWatch Alarm + SNS + Chatbot + Slackの連携は完了です。
Lambdaで設定する場合は、テンプレートをそのまま使うにしてもWebhook URLの設定などが必要ですし、何よりLambda自体の管理が必要になってくるので、少し煩わしいです。
それに比べてChatbotを使う場合は、コードを一切書く必要がなく、メンテナンスも基本的に不要なので、管理もとても楽です。
ただ、Chatbotの場合は通知の内容や表現方法を変更することができないので、CloudWatch Alarmからの情報をいい感じに組み立てて独自のやり方と見せ方で通知したいという場合には向いていません。
また、現時点でベータ版なので今後どうなるかわかりませんし、AWSのGoのSDKでのサポートがまだであるためには現時点ではterraformで利用することもできません。
github.com
これらの違いを比べて、どちらを使うか決めればよいかと思います。
AWS の CloudWatch Logs は CloudWatch Logs エージェントではなく 統合 CloudWatch エージェントを使ってインストールする
表題の通りで、それだけなのですが、一応続けます。
AWSにはCloudWatch Logsというサービスがあり、AWS上のあらゆるリソースであったり、EC2インスタンス、さらにはオンプレサーバーから、ログを収集して保存や監視を行うことができます。
特にEC2インスタンスからログを収集することで、ログの分析も容易になるので便利です。
さて、そんなCloudWatch Logsのインストール方法ですが、情報を探そうと検索すると、公式ではないブログなどでは、基本的に「CloudWatch Logs エージェント」をダウンロードしそれを使ってインストールする方法がたくさん紹介されています。
ですが、実はこの方法はすでに非推奨となっています。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/CWL_GettingStarted.htmldocs.aws.amazon.com
現在推奨されているのは、統合CloudWatchエージェントを使ってログを収集する方法です。
CloudWatch Logsを使おうとしている場合は、高確率でCloudWatchエージェントを使ったカスタムメトリクスの収集もしていると思うので、CloudWatch Logs エージェントなるものを使わなくとも設定を書き換えるだけでCloudWatch Logsが使えるようになるという優しい設計です。
これに気づいたのは最近なんですけど...
具体的にどうやって設定するかというと、CloudWatchエージェントの設定ファイルにはlogsセクションというものが用意されており、そこにこれまでのCloudWatch Logsエージェントの設定ファイルに書いていたものをほぼ同じ形で書くだけです。 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Logssectiondocs.aws.amazon.com
CloudWatch LogsエージェントではなくCloudWatchエージェントのlogsセクションを使うにあたって、2つ注意することがあります。
1つ目は、公式サイトでも紹介されているように、タイムスタンプ形式で使用できる記号に差異があります。
もし移行など古い設定を参照することがあるなら注意した方が良いです。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-logs-timestamp-differencesdocs.aws.amazon.com
2つ目は、公式サイトのどこにも明示的には載っていないのですが、なぜかタイムスタンプ形式を表すフィールド名が datetime_format から timestamp_format に変更されているということです。
こちらも移行などで古い設定を参照することがあるなら注意した方が良いです。
私は、この違いにPullRequestのレビューで気づきました。
長々と書きましたが、CloudWatch Logsを利用する場合は、これまで通りCloudWatch Logsエージェントを使うのではなく、統合CloudWatchエージェントを使った方が推奨されているし楽だよ、というお話でした。
ウイルスから世界を救うボードゲーム「パンデミック」は採用や研修に使えるかもしれない
はじめに
久しぶりのボードゲーム紹介です。
今回は今のご時世に合った「パンデミック」というボードゲームです。
これはウイルスの広がっている世界で協力して治療薬を発見することで世界を救うことを目標した協力ゲームです。
コロナの影響で外出がなかなかできないので、そういうときは家族や同居人とボードゲームをして過ごすのはどうでしょうか。
パンデミック:新たなる試練 (Pandemic) 日本語版 ボードゲーム
- 発売日: 2013/08/01
- メディア: おもちゃ＆ホビー
パンデミック
パンデミックとは、伝染病や感染症が世界中に流行することを表す用語。
このゲームは、世界中に拡大しようとする感染症の根絶を目的とし、プレイヤー同士が協力し合って、4種類の病原体すべてのワクチンを発見するという、多人数協力型ゲームだ。
このように紹介されているように、このボードゲームは珍しい*1協力ゲームという形式です。
そのため、プレイヤー間で争うのではなく、システムに勝つにはどうすればいいのかというプレイングになります。
ゲームの目的はウイルスが蔓延して世界が滅亡する前に4種類の治療薬を発見するというものです。
感染者が増えすぎるとアウトブレイクが発生してしまうので治療をし、ただ治療を進めるだけでは根絶できないので治療薬の発見に勤しみ、そのために世界中を駆け回る必要があるために研究拠点を築き、と、様々な選択肢がある中で何を優先すべきかを考えて協力してゲームを進めていく必要があります。
さらに、このゲームには「科学者」「研究員」「衛生兵」「通信司令員」「作戦エキスパート」などのキャラクターが存在し、それぞれは異なる能力を持っています。
プレイヤーはいずれか1つのキャラクターを担当し、その能力を存分に発揮できるようなプレイを目指します。
採用や研修に利用できるかも？
ボードゲーム自体がアイスブレイク等に利用できるということは、前に紹介しました。 ohshige.hatenablog.com
今回のボードゲームは協力ゲームであり戦略もかなり必要になってくるため、採用や研修時のグループディスカッションの代わりとして利用できるかもしれません。
どういう点で利用できると考えているのか、いくつか紹介します。
理解力
まず、単純なボードゲームではなくルールも多少複雑であるため、最低限の理解力が必要になります。
ルールをしっかりと把握できているかといった判断が可能かもしれません。
もちろんルールをしっかりと伝えられないと意味が無いので、提供側のわかりすい説明が必須になります。
リーダーシップと議論
また、協力ゲームであるためリーダーのようなポジションが必要になってきます。
しかし、リーダーが奉行として指示を出し、周りがそれに従うだけでは駄目で、自分の意見もしっかりと発言しなくてはいけません。
今は何を優先してどうするべきであるかを議論し、とるべき行動を決定します。
性格
人となりもわかるかもしれません。
確率を綿密に計算し効率でものごとを決定するような効率タイプなのか、リスクヘッジに重きをおく慎重タイプなのか、リスク覚悟でハイリターンを求めるギャンブラータイプなのか、プレイヤーの性格が出ます。
このように、理解力、リーダーシップ、性格などが表れるため、採用や研修の場に有効なボードゲームです。
さいごに
御託を並べてはいますが、普通におもしろいので採用や研修関係なく是非やっていただきたいです。
脳内ミルクボーイで AWS ソリューションアーキテクト アソシエイト (SAA-C01) に合格することができた
はじめに
実務として約1年間AWSを触ってきて、ある瞬間に「そうだ、資格をとろう」と思い立ち、しかも現行の試験がもうすぐ終わってしまうということでそれまでに頑張って取ろうと決意しました。
その結果、無事に合格したのでそれについて書きます。
前回のブログも試験に向けた自分用のメモだったわけです。ohshige.hatenablog.com
ただ、今回のブログでは、読むのは「脳内ミルクボーイ」の項目だけで十分かもしれないです。
脳内ミルクボーイ
この話を書きたいがための今回のブログと言っても過言では無いので結論として先に書きます。
問題を解くときのコツとしてミルクボーイネタが使えるのではないかと思ってはいたのですが、実際の本番の試験の際も脳内でミルクボーイのネタが流れていました。
こんな感じです↓
私「うちのオカンがね、使いたいAWSのサービスがあるらしいんやけど」
脳「そーなんや、どんな特徴ゆうてたかってのを教えてみてよ」
私「高い耐久性と可用性のあるところに大量のPDFデータを保存したいって言うねんな」
脳「おー、S3やないかい。その特徴はもう完全にS3やがな」
私「S3なぁ」
脳「すぐ分かったやん、こんなんもー」
私「でもこれちょっと分からへんのやな」
脳「何が分からへんのよー」
私「いや俺もS3と思うてんけどな」
脳「いやそうやろ？」
私「オカンが言うには、保存してからしばらくしたら滅多にアクセスしなくなるからコスト効率を良くしたいって言うねんな」
脳「あー、ほな単なるS3と違うかぁ。S3は標準的なストレージでお安いけどもアクセス頻度もそこそこある場合により適してんのよあれ」
私「そやねん」
脳「ほなもう一度詳しく教えてくれる？」
私「保存してから30日間は頻繁にアクセスするけどそれ以降は滅多にアクセスしないらしいねん」
脳「ほなS3やないかい。ほんで、S3にライフサイクルポリシー設定して30日後に S3 Glacier に移行するパターンやと俺は睨んでんのよ。俺の目は騙されへんよ」
私「まあねー」
脳「S3 Glacierは標準のS3よりも低コストで大量のデータを長期間アーカイブすることに適してんのよあれ」
私「分からへんねんでも」
脳「何が分からへんのこれで」
私「俺もS3とGlacierの組み合わせと思うてんけどな」
脳「そうやろ」
私「オカンが言うには、滅多にアクセスしなくなるけど必要になったらすぐに取り出せなあかんって言うねんな」
脳「ほなGlacierちゃうやないかい。Glacierの取り出しオプションには[迅速][標準][大容量]の3つがあって、最速の迅速読み取りでも数分はかかんねん。せやから必要なったらすぐに取り出すユースケースには適してないんや」
私「そやねんそやねん」
脳「ほなGlacierちゃうやないかい。ほなもうちょっとなんかゆうてなかった？」
私「重要なデータだから30日経ったあとでも耐久性はしっかりしてないとあかんらしいねん」
脳「S3標準 - 低頻度アクセス (S3標準 - IA) やないかい。移行後も高い耐久性が必要で低頻度アクセスでしかも即時取り出しが必要ならS3標準-IAしかないねん」
私「そやねんそやねん」
脳「Glacierと違て必要に応じてすぐ取り出せるねん」
私「せやねん」
脳「S3 1ゾーン - 低頻度アクセス (S3 1ゾーン - IA) もあるけども、それは他と違ってひとつのAZにデータを保存するからコスト削減できる分、多少アベイラビリティを犠牲にしなあかんねん」
私「そやねんな」
脳「ほな、S3にライフサイクルポリシー設定して30日後にS3標準-IAに移行するで決まりやな」
他のパターンでも、こんな感じで「こうだろうか？」「いやこういう条件あるから違うな」みたいなことを繰り返して解いていました。
これがやりたかっただけ。書きたかったこと終わり。
続きを読む