技術書典 応援祭を応援してみる

2020/2/29から二日間開催予定だった技術書典8が新型コロナウイルスの感染拡大により中止に追い込まれました^1。開催に尽力した主催者や出展者の方々の胸中察するに余りあります。もちろん自分も非常に落ち込みましたが、「技術書典 応援祭」という形で急遽オンライン開催されたのはまさに僥倖でした。関係者各位の並々ならぬ情熱でたった一週間の準備期間で実現足らしめたこの応援祭を自分も応援すべく筆をとりました。

技術書典 応援祭は3月7日から4月5日までの期間限定開催です。技術書典には600を超えるサークルから技術本が出品されているので検索すればきっと気になる技術書が見つかると思います。本記事では自分が買って面白かった本を中心にご紹介したいと思います。

おすすめの薄い本

ページ数は少なめでも熱い情熱のこもった良著をご紹介します! おすすめ本は応援祭の期間中に増殖するかもしれません😄

エンジニアの心を整える技術2

この本は「エンジニアの心を整える技術」の続編です。わかりやすい例をもとに「アドラー心理学」や「仏教」、「マインドフルネス」をキーワードとして心を整える技術を紹介しています。自己肯定感が低いと感じている人やマインドセットを変えたいと思っている人におすすめです。この本も良著ですが前作も良かったので併せて読むのがベストだと思います。前作の感想はこちらに書いたので参考にしてください。

辛いとき、苦しいときにエンジニアの心に寄り添ってくれる本です。

目次はこちら

第1章 感情を整える技術
1.1 エンジニアが心穏やかに働くために
1.1.1 IT 業界は、過労による精神疾患でワースト 1 の劣等生
1.1.2 心のプログラミングは、自分との対話
1.1.3 コードを書き換えるように、自分の心をリファクタリング
1.2 禅とスティーブ・ジョブズ
1.2.1 仏教とエンジニアとシリコンバレー
1.3 「反応しない練習」から学ぶ、ブッダの合理的な考え方
1.3.1 「心の反応」こそが、「バグ」
1.4 心のざわざわや不安を鎮めるフォールトトレランス
1.4.1 心のステークホルダーは、自分。自分で選ぶこと、決めること
1.4.2 自分が書いたコードが原因でバグを出した。そのせいでシステム 障害。
1.4.3 自己否定の無限ループ
1.5 心の状態をコードリーディングする
1.5.1 コントロールできること/できないこと
1.5.2 アドラー心理学の「課題の分離」
1.5.3 自分の行動にフォーカスする
1.5.4 最悪の事態を思い浮かべる
1.6 「きみにはスキルがない」と言われたら
1.6.1 自分は駄目なやつだ。――いや、本当にそうだろうか?
1.7 感情の例外処理
1.7.1 感情を、例外としてキャッチする
1.7.2 身体の感覚を意識する
1.8 あるがままを受け入れる
1.8.1 確かに自分はバグを出した

第2章 不安やストレスを鎮める技術
2.1 エンジニアの不安やストレスとの向き合いかた
2.1.1 「心配性」は裏を返せば、「リスクマネジメントの能力が高い」
2.1.2 適度なストレスは悪いものではない
2.2 「モジュール結合度が高い」人間関係で苦しまない生き方
2.2.1 ブッダは言った。執着こそが苦しみを産んでいる
2.3 心の毒状態を回復する
2.3.1 相手のことを判断しない。事実と主観を分けてカプセル化する
2.4 イヤな相手とどう関わるか。(IF だけ知って、実態は無視せよ)
2.4.1 周りは敵だらけで高エンカウントは疲れる。クリーンな状態にシステムリセット
2.5 ソフトウェア開発における悩みの原因は、心の反応
2.5.1 怒りの正体。怒りをコントロールするには
2.6 バグを出したのは開発チーム全体の責任
2.7 マインドフルネス瞑想で妄想をリセットする
2.8 「捨てる・やめる習慣」―― するべき、でないといけないをやめてみる
2.8.1 それ、本当に必要か?
2.8.2 会議をやめてみる
2.8.3 「こうあるべき」をやめてみる。自分が本当にやりたかったことが見えてくる

第3章 休息する技術
3.1 会社がモンスターのように私たちを支配している
3.2 エンジニアの「働き方」改革
3.3 休日の罪悪感の正体
3.3.1 「サザエさん症候群」の防ぎ方
3.3.2 休日に疲れをとるのも仕事のうち
3.3.3 休日に個人開発(プライベートプロジェクト)をやってみる
3.4 「残業なし」が当たり前の世界
3.4.1 「遅くまで残って頑張らなきゃ」という思い込みから降りる
3.4.2 みなし残業だと残業しないといけないのか?
3.5 他人の人生を生きるのって
3.5.1 働きすぎを自覚する
3.6 長時間労働は非効率
3.6.1 残業することに逃げていないか
3.6.2 日本の生産性は先進国で最下位
3.6.3 飲み会に行かない
3.6.4 Slack をミュート・退出せよ。心に「ゆとり」を取り戻せ
3.7 たとえ周りに嫌われても、定時で帰る

第4章 自己肯定感を整える技術
4.1 自己肯定感は高くなくてもよい
4.2 人から嫌われた過去を抱えながら生きる
4.2.1 自分が嫌いだ
4.3 自分を哀れむ習慣をやめる
4.3.1 自分を否定しない。いつ何時も
4.3.2 自己肯定感の低い完璧主義
4.3.3 今の時代、自分を否定している人が多い
4.3.4 コンプレックスや挫折感、生きている価値がない
4.3.5 セルフ・ハンディキャッピングと自己弁護のはざまで
4.4 自己否定を抜けるための技術
4.4.1 過去に引きずられない
4.5 まだ起こってないことに悩まない
4.5.1 失敗することに慣れる
4.5.2 失敗が怖い本当の理由
4.6 自分に何かが足りない欠乏感
4.6.1 過去を引きずるということは、記憶に反応している状態
4.6.2 自信をなくした時こそ、素振りする。(コード瞑想のすすめ)
4.7 他人と比べない
4.7.1 嫉妬に「反応しない」

第5章 おわりに

「整いました!」

Amazon Web Services コスト最適化入門

AWSを利用していると予想外の箇所で料金が掛かっている場合が多々あります。かく言う自分も月額利用料が跳ね上がったことがあってAWSのオペレータから電話がかかってきた経験があります。「料金が先月と比べてxx円上がっていますが、お間違いないでしょうか?」と。この電話を受けて青ざめたのですが、このときは自分が何に使ったのか大体予想ができたので何とか落ち着いて返答できました。

このようにAWSのコストで慌てふためかないようにするためにオススメできるのがこの本です。AWSのコスト体系は複雑なのでコスト管理は骨が折れますが、クラウド破産しないためには身につけておくべき技術なので気になったらぜひこの本を手にとってみてください。

目次はこちら

第一部 AWSサービスの料金体系

第1章 Amazon EC2
第2章 Amazon EBS/EFS
第3章 Amazon VPC/データ転送
第4章 Amazon S3

○ 第二部 AWS利用料金の見積もり

第5章 AWS Simple Monthly Calculator
第6章 AWS Pricing Calculator

○ 第三部 AWSコストの可視化・分析・予算管理

第7章 AWS Cost Explorer
第8章 AWS Cost and Usage Report
第9章 AWS Budgets
第10章 コスト配分タグ

○ 第四部 コスト最適化

第11章 AWS Trusted Advisor
第12章 AWS Compute Optimizer
第13章 AWS Well-Architected フレームワーク

クラウド破産を回避するAWS実践ガイド

「クラウド破産」というキーワードから一つ前に紹介した本と同じくコスト管理の本かと思いましたが、主な内容はセキュリティでした。セキュリティの重要性は恐らくみんなわかっているけどなかなか手が回らないものの一つだと思います。

一番の理由は「効果的な手法がよく分からない」というものだと思います。セキュリティの技術は日進月歩でしかもいたちごっごの性質もあるので確かに真面目に取り組むのには躊躇してしまう側面もあると思われます。

そんな人におすすめできるのがこの本です。AWSにはセキュリティにおけるベストプラクティスが溜まっておりそれを実行してくれるサービスも揃っているのでうまく活用すれば、必要以上に手間をかけずにセキュリティ強化できます。

セキュリティ事故は一旦起こしてしまうと想像を超える実害信用の大暴落が起こるので、目を逸らさずに真面目に取り組むのが吉です。

目次はこちら

第I部 基礎知識
1章 クラウド破産
2章 AWS

第II部 AWSアカウントの保護
3章 AWSアカウント保護戦略
4章 ルートユーザーのパスワード管理
5章 ルートユーザーのMFAによる保護
6章 IAMによるアクセス管理
7章 パスワードポリシーの厳格化
8章 請求管理の最適化
9章 AWS Budgetsによるコスト管理
10章 登録情報の最新化

第III部 ガードレールの構築
11章 ガードレール構築戦略
12章 CloudTrailによる証跡管理
13章 AWS Configによる構成管理
14章 S3による安全なログ管理
15章 GuardDutyによる脅威検知
16章 IAM Access Analyzerによる公開リソースの検出
17章 Security Hubによる統合
18章 AWS Artifactによる準拠法の変更

第IV部 アラートの通知
19章 アラート通知戦略
20章 SNSによるメール通知
21章 ルートユーザーのアラート通知
22章 CloudFormationによるアラートの一括作成
23章 ChatbotによるSecurity Hubのアラート通知
24章 CloudTrail Insightsのアラート通知

第V部 セキュアなローカル環境
25章 AWS CLIによるオペレーション
26章 git-secretsによる秘匿情報のコミット抑制
27章 AWS Vaultによるアクセスキーの安全な管理
28章 パスワードレスサインイン環境の構築

第VI部 学び方を学ぶ
29章 書籍から学ぶ
30章 Webから学ぶ
31章 ベストプラクティスを学ぶ
32章 AWSサポートを上手に活用する

AWSを使って学ぶ 監視設計

GoogleがSRE(Site Reliability Engineering)の考え方を提示して注目を浴びるようになったSLI/SLO[^2]ですが、本書ではSLI/SLOの設計をAWSで使って説明している本です。内容的には入門者向けで、すでに高度な監視に取り組んでいる方には学びは薄いかもしれませんが、SLI/SLOを初めて聞いたという方にはケーススタディも載っているのでオススメできる本です。

目次はこちら

第1章 監視の設計
第2章 SLI/SLO
第3章 AWSにおける監視設計
第4章 監視対象の多様化
第5章 ダッシュボード
第6章 AWS上のサーバーレスアプリ ケーションの監視(ケーススタディ)

[^2]: SLI(Service Level Indicator)はサービスの品質を測るための指標のことで、SLO(Service Level Objective)とは各SLIに対しての目標数値のことです。SLA(Service Level Agreement)とは異なる概念なので混同しないようにしてください。

実践 AWS CDK - TypeScript でインフラもアプリも!

Infrastructure as Code(IaC)という概念が登場して久しいですが、AWSのインフラ自動化で真っ先に思い浮かぶのがCloudFormationだと思います。ただこのCloudFormationの設定は単なるyamlやjsonファイルであって、普通のプログラミング言語と違って記述力が乏しいのが難点でした。例を上げると、単純な分岐やループが簡単にできないし計算処理も難しいです。またデバッグも困難で実際にスタックを作成してみるまでエラーになるかどうか分からないことが大半です。

そんなときにおすすめできるのがAWS CDK(Cloud Development Kit)です。AWS CDKは汎用プログラミング言語[^3]を用いてAWSインフラを記述できる機能です。AWS CDKは昨年7月にGAになったばかりなので、まとまった情報が少ないのでこの本はおすすめです。AWS CDKとTypeScriptを利用してインフラを記述すると型チェックしてくれるので記述ミスの早期検出が可能になり、VS Code等を利用すれば補完も効くのでインフラ開発が本当に楽しくなってきます。まだCDKを知らない人はぜひこの本を手にとってCDKの門を叩いてみてください。

目次はこちら

第1章 AWS CDKの概要
 1.1 AWS CDKとは
 1.2 CDKのメリットとデメリット

第2章 AWS CDKのはじめかた
 2.1 なぜCDKを使うのか
 2.2 CDK環境の構築
 2.3 CDKプロジェクトの作成
 2.4 CDKアプリのデプロイ
 2.5 まとめ

第3章 TypeScript入門
 3.1 Playgroundではじめよう
 3.2 TypeScriptの型
 3.3 クラスとオブジェクト

第4章 Step Functions入門
 4.1 概要
 4.2 ステートマシン
 4.3 ステートへの入出力

第5章 感情分析システムを作ろう
 5.1 システムの概要
 5.2 プロジェクトの作成
 5.3 入出力バケットの作成
 5.4 メール通知の実装
 5.5 ワークフローの作成
 5.6 入力バケットとワークフローの連携
 5.7 タスクの作成
 5.8 ワークフローを組み立てよう
 5.9 ソースコード

第6章 AWS CDKのデバッグとテスト
 6.1 デバック
 6.2 ユニットテスト

第7章 AWS CDKのCI/CD
 7.1 CI/CD概要
 7.2 CDKにおけるCI/CDパイプライン

第8章 AWS CDK Tips
 8.1 AWS Coreモジュール よく使う機能
 8.2 スタックの呼び出し時にカスタム値を渡す
 8.3 リソース定義の分割
 8.4 環境によってコンテキスト値を変更
 8.5 機密情報の管理
 8.6 SAM CLIとの連携

付録 A
 A.1 CDK CLIコマンド
 A.2 本書で利用したAWSサービス
 A.3 参考文献

 
余談になりますが、AWS CDKはその名の通りAWS専用になります。マルチクラウドで同じようなことがしたい場合にはPulumiという選択肢もあります。Pulumiについては以前に記事を書いたので気になる方は読んでみてください。

[^3]: 2020年3月時点でサポートされている言語はJavaScript、TypeScript、Python、 Java、および C#になります。

ドメイン駆動設計モデリング/実装ガイド

ドメイン駆動設計(DDD)は名前は聞いたことがある、部分的には知っているという人が増えてきたように感じています。ただ導入するには全体像が大きすぎてどこから手を付ければいいのか分からないケースは結構あると思います。ドメインモデルや集約の切り方に自信を持てなかったり、CQRSの使い所に悩んだりして、結局そこに自信を持てないから導入を見合わせたりして、もやもやが溜まったりなどです。

この本は単に原則やケーススタディを説明するだけでなく、そのような入門者の躓きそうなところや疑問に思いそうなところをQ&Aで細かくフォローしてくれているので非常に腹落ちがしました。

 
じつはこの本の解説を行った以下のオンライン勉強会に参加させて頂いたのですが、いままでDDDに抱えていたもやもやが一気にクリアになったような感じがしました。

勉強会自体はもともと3章を説明する予定が「集約」だけに絞っても質問が多すぎて1時間延長になりました。それだけ「集約」というテーマが奥深く難しいテーマなのだと思いますが、驚くべきは質問内容をまるで予想していたかのように、答えが本に載っていたことです。ついつい自分も「本が万能すぎるww」とコメントしてしまいましたが、まさに読者に寄り添う形で書かれた本だということを実感しました。

分量も100ページ強でDDDについて知りたいことがコンパクトに詰まった感じなので、DDDを実践したい全ての人にオススメできる本です。

目次はこちら

第1章 DDD 概要
1.1 言葉の定義
1.2 DDD とは
1.3 モデルとは
1.3.1 定義
1.3.2 モデルの例
1.4 良いモデル、良くないモデル
1.4.1 良いモデルとは
1.4.2 良くないモデルの例
1.5 良いモデルを作るには
1.5.1 ドメインエキスパートと会話する
1.5.2 運用して得られた発見をモデルに還元する
1.6 DDD の問題解決のアプローチ
1.6.1 モデルの継続的な改善
1.6.2 モデルからソフトウェアへの継続的な反映
1.7 取り組む上で重要な考え方
1.7.1 課題ドリブン
1.7.2 小さく初めて、小さく失敗する
1.8 Q&A
1.8.1 DDD の向き・不向き
第2章 モデリングから実装まで
2.1 ドメインモデリング
2.1.1 ユースケース図
2.1.2 ドメインモデル図
2.2 ドメインモデルの実装
2.2.1 アーキテクチャ
2.2.2 ドメインモデル貧血症のコード
2.2.3 ドメインモデル貧血症のコードの問題点
2.2.4 ドメインモデルの知識を表現した実装
2.3 ドメイン層オブジェクト設計の基本方針
2.3.1 ドメインモデルの知識を対応するオブジェクトに書く
2.3.2 常に正しいインスタンスしか存在させない
4.4 実際の開発の進め方
5.5 Q&A
6.5.1 ユビキタス言語の管理方法
7.5.2 モデリングにかける時間
8.5.3 ドメインモデル図の更新頻度
9.5.4 モデリング時に作成するその他の成果物
10.5.5 ユースケース図を使う理由
11.5.6 他のモデリング手法との違い
第3章 DDD 固有のモデリング手法
3.1 集約
3.1.1 集約とは
3.1.2 設計/実装時のルール
3.1.3 集約の境界の決め方
3.2 境界づけられたコンテキスト
3.2.1 境界づけられたコンテキストの概念
3.2.2 境界づけられたコンテキストの実装
3.3 Q&A
3.3.1 DB への意識
3.3.2 集約とトランザクション
第4章 設計の基本原則
4.1 凝集度・結合度について
4.2 凝集度
4.2.1 定義
4.2.2 低凝集な実装
4.2.3 高凝集な実装
4.3 結合度
4.3.1 定義
4.3.2 高結合な実装
4.3.3 低結合な実装
4.4 今後の章との関連
第5章 アーキテクチャ
5.1 3 層アーキテクチャ
5.1.1 タスク管理アプリケーションの例
5.2 レイヤードアーキテクチャ
5.3 オニオンアーキテクチャ
5.3.1 レイヤーごとの責務
5.3.2 丸型の表記
5.4 ヘキサゴナルアーキテクチャ
5.5 クリーンアーキテクチャ
5.6 オニオンアーキテクチャ、クリーンアーキテクチャの比較
5.6.1 シンプルさ
5.6.2 レイヤーの責務の思想の違い
5.7 境界づけられたコンテキストの実装
5.7.1 1 コンテキスト1 アプリケーションの場合
5.7.2 1 コンテキスト1 アプリケーション以外の場合
第6章 ドメイン層の実装
6.1 エンティティ
6.2 値オブジェクト
6.3 ドメインサービス
6.4 リポジトリ
6.5 ファクトリー
6.6 ドメイン層のそれ以外のオブジェクト
6.7 複数集約間の整合性確保
6.8 Q&A(ドメインオブジェクト)
6.8.1 ドメイン層にロジックを寄せる目的
6.8.2 プリミティブ型の使用可否
6.8.3 DB の値からインスタンスを再構成する方法
6.8.4 再構成メソッドを書くべきレイヤー
6.9 Q&A(リポジトリ)
6.9.1 ドメインオブジェクトとDB の対応
6.9.2 ソートの実装方法
6.9.3 キャッシュの実装方法
6.9.4 外部API とリポジトリの関係
6.9.5 外部API から取得した値の詰め替え方法
6.9.6 エンティティ同士の紐付け
6.9.7 リポジトリのインターフェイスを定義するレイヤー
6.9.8 一部カラムを更新するときの扱い
6.9.9 ドメインオブジェクトからリポジトリ操作の可否
6.10 Q&A(その他)
6.10.1 ドメインサービスの命名
6.10.2 リポジトリを通じた削除方法
第7章 ユースケース(アプリケーション) 層の実装
7.1 ユースケース
7.2 ユースケースからの戻り値クラス
7.3 Q&A
7.3.1 クラスの分割単位
7.3.2 命名規則
第8章 CQRS
8.1 DDD の参照系処理で発生する問題
8.2 解決策
8.2.1 参照用モデルの型を定義するレイヤー
8.3 メリット、デメリット
8.4 実装時の注意事項
8.4.1 部分的導入の可否
8.4.2 型を定義するレイヤーがユースケース層である理由
8.4.3 更新系との整合性を確保する方法
8.5 よくある誤解
8.5.1 データソース分離の必要性
8.5.2 イベントソーシングとの関係
8.6 Q&A
8.6.1 クエリサービスの分割判断
8.6.2 DTO として返した値の扱い
8.6.3 参照用モデルの使い所
8.6.4 実装の都合にドメイン層が影響を受ける場合
8.6.5 集約内の一部の値だけ取得したい場合の対応方法
第9章 プレゼンテーション層の実装
9.1 プレゼンテーション層の処理概要
9.2 プレゼンテーション層のクラス、ファイル
9.3 リクエスト仕様の定義
9.4 レスポンス仕様の定義
9.5 Q&A
9.5.1 コントローラーの処理内容
9.5.2 プレゼンテーション層における値オブジェクト生成
第10章 アーキテクチャ全般・ライブラリなど
10.1 例外処理
10.1.1 例外の種類
10.1.2 バリデーション内容の重複
10.1.3 処理結果を例外で表現しない場合
10.2 パッケージ
10.3 Web フレームワークへの依存
10.4 OR マッパー
10.5 言語
10.6 Q&A
10.6.1 アーキテクチャの部分適用
第11章 困った時には
11.1 ドメイン駆動設計入門
11.2 実践ドメイン駆動設計
11.3 英語で検索
11.4 DDD Community Jp
11.5 筆者に質問

無料の薄い本

薄い本の中には無料で電子書籍が配布されている場合があるのでご紹介します。まずは無償版の方を読んでみて、気に入ったら有償版にも手を出してみるというのもアリだと思います^4

変わり種

技術書典 応援祭には同人誌だけでなく商業書籍や学会誌が紛れ込んでいます。懐かしいあの本とかを見つけるとほっこりします。

まとめ

不要不急の外出の自粛が求められる世の中で自宅で技術書を読み耽るのはエンジニアとしては非常に有意義な時間の使い方であり、この応援祭は非常に有り難い存在だと思います。

技術書典 応援祭には、エンジニアの夢と情熱が詰まった素敵な本が集結しています。ぜひ以下のページで気になるキーワードを検索してみてください。あるいはジャケ買いでもいいかもしれません。運命は悪戯なのでその中にはあなたの人生に影響をあたえる一冊が眠っているかもしれません。

 
エンジニアの皆様に技術書典 応援祭で素敵な出会いが見つかることを祈りつつ筆を置きたいと思います。

関係者の皆様、本当にありがとうございました。

本記事が、エンジニアの方々および技術書典 応援祭の一助になれば幸いです。

Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×