ゼロからのDocker入門
この記事は何か
Dockerを全く知らない段階から、下記を目指すためのロードマップです。
- Dockerとは何か？全体像を理解する
- Dockerで開発環境を構築できる
- 開発現場で既存のDockerfileやdocker-compose.ymlを理解し、編集できる
- その先にあるKubernetesやAWSなどに興味を持つ
TLDR
公式Docのチュートリアルをやると理解が捗ります。
https://docs.docker.com/
英語の文章を読むのが辛い時は
最近話題のDeepLで翻訳すると日本語で読めます。
英語は読めるが日本語の方が理解が早いという方も是非。
https://www.deepl.com/translator
Dockerとは
Docker overview | Docker Documentation
Dockerが従来の仮想化ソフトウェアよりも優れている理由
- 軽量である(容量が小さい)
- 高速である(起動や処理が早い)
軽量、高速である理由は下記を参考にしてください。
Dockerとは何か、何が良いのか
Docker入門（第一回）～Dockerとは何か、何が良いのか～ | さくらのナレッジComparing Containers and Virtual Machines
What is a Container? | App Containerization | Docker
Dockerを導入するメリット
- 開発環境構築が簡単になる
- Dockerfileやdocker-compose.ymlを用いて、開発環境をコード管理できます
- プログラミング言語やデータベースの手動での導入...といった煩わしい作業から開放されます
- 開発環境を簡単に共有できる
- コード管理された開発環境のため、バージョン差異なく簡単に共有、構築ができます
- そのため、新規参加メンバーが環境構築で失敗、躓くことがなくなります
- また、PC購入時やデスクトップとノートPCの使い分けの際にも、楽に環境構築ができます
- 開発環境を簡単に実行できる
- docker-composeにより、1コマンドでアプリケーション全体の起動を行えます
- そのため、アプリケーションやデータベースなどをそれぞれ実行する手間が省けます
- また、Railsは起動したけど、PostgreSQLの起動し忘れた...などの問題を防げます
- テスト環境や本番環境の構築も楽になる
- ローカルの開発環境と同じ環境を簡単にCircle CIやAWS上に作ることができます
- そのため、ローカルではテスト通るけど、CIだと落ちてしまうなどの問題を少なくできます
- ただし、開発環境と本番環境は全く同じであることは少ないため、工夫は必要です
より詳細に
https://docs.docker.com/get-started/#docker-concepts
手を動かして学ぶ
下記リンクのどれか良さそうなものを選び、image、container、volume、docker-compose、networkなどDockerの主要機能や概念について学びます。私は一通りやりましたが、公式Docのチュートリアルが最もコンパクト、過不足なくまとまっており分かりやすいです。
オススメ
- Orientation and setup | Docker Documentation
その他の選択肢
- Dockerでプログラマが最低限知るべきことが、最速でわかるチュートリアル - Qiita
- Linuxコマンドから始めるDocker ～ BE A FIRST PENGUIN AND GROW AS WHALE | Udemy
- ゼロからはじめる Dockerによるアプリケーション実行環境構築 | Udemy
- Docker Deep Dive by Nigel Poulton [Leanpub PDF/iPad/Kindle]
Ruby on Rails + PostgreSQL + Docker環境の構築
WIP
Dockerの次に学ぶこと
WIP
参考文献
公式Doc
https://docs.docker.com/
概要、詳細はもちろんのこと、クイックスタート(チュートリアル)やRailsでの利用方法といったSampleも充実しているため、必見です。Docker Deep Dive
https://leanpub.com/dockerdeepdive
Amazonレビューが高かったので読みました。説明が丁寧で、各章において概要や背景から入り、その後手を動かしながら詳細を学ぶというスタイル。個人的には冗長に感じてしまう部分も多々ありましたが、全体的に分かりやすいのでオススメです。なお、Amazonの方が安いですがコピー制限がありDeepLで最後まで日本語翻訳できません。leanpubで購入してpdf落とすと制限なく翻訳できます。
Railsでビジネスロジックをどこに書くか？
どのような歴史を辿ったか？
Rails勃興(2004~2005年)
ViewやControllerにビジネスロジックを記述。見通しの悪さが問題に
モデルにビジネスロジックを書くべきという主張(2006年)
Buckblog: Skinny Controller, Fat ModelFat Modelが問題。サービスオブジェクトなどModelの責務を切り出す動き(2012年)
7 Patterns to Refactor Fat ActiveRecord Models - Code Climate
(日本語訳)肥大化したActiveRecordモデルをリファクタリングする7つの方法 Railsで重要なパターンpart 1: Service Object（翻訳）｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社サービスオブジェクトの間違った運用に警鐘を鳴らす
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
Service Objectがアンチパターンである理由とよりよい代替手段（翻訳）｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社
その他参考
Railsのファットモデル問題に対処する前に読んでほしい記事 - Qiita
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it? - Speaker Deck
railsのエラー処理
参考
1.controller外でのエラー処理
例えば、routing時のエラー(存在しないurlの指定)など
Rails の rescue_from で拾えない例外を exceptions_app で処理する - Qiita
参考コード
add: routing時のエラー制御等を追加 · fv17/rails6-practice-guide@9867d5a · GitHub
2.controller内でのエラー処理
Action Controller の概要 14.Rescue
参考コード
add: エラー表示画面を作成 · fv17/rails6-practice-guide@d86e36a · GitHub
メモ、補足
書籍(Rails実践ガイド)だとStandardErrorもハンドリングしているが、Railsガイドだと非推奨。 親クラスなので、一番最初に指定しないと全て500でキャッチしてしまうリスクがある。
rescue_fromにExceptionやStandardErrorを指定すると、Railsでの正しい例外ハンドリングが阻害されて深刻な副作用が生じる可能性があります。よほどの理由がない限り、この指定はおすすめできません。
参考コード
スクラムマスターとしてすべきこと
メモ
SMとしての役割
- 仕事の可視化
- ムダの可視化
- モチベーション向上
- 障害の追跡と除去
- イベント成果物への集中
- 依存関係の可視化
POへの支援
- リリース計画の支援
- Epicを見積もる
- リリースバーンダウンチャートの作成
- デミングの20%の変動(期間が長いと50%ズレる例も)
- ステークホルダーからの要求管理を支援
- スコープ設定やMVPでの製品開発を支援
開発チームへの支援
- 機能横断的な動きを支援
- スケジュールの可視化を支援
- 技術的リスクの発見を支援
- リーンなドキュメント作成を支援
- タスク分割や割当等を支援
1/2の時間で2倍の成果を出すには？
- 安定したチーム
- 昨日の天気で早く終える
- 3スプリントの平均ベロシティを計画に考慮
- 終わらないスプリントはチームの士気を大きく下げる！
- スウォーミング
- 思考の切り替えはムダである
- 優先順位の高いものから順に終わらせる
- 機能横断を実践するためT型人材
- 割り込み
- 割り込みのためのバッファを、あらかじめ計画に含めておく
- 計画時に詰め込みすぎず、余力を残す
- クリーンなコード
- バグはその日のうちに
- 幸福指標
- コミュニケーションコストを下げる(RW時)
- 必要なツールは導入
- テキストではなく、小さいMTGを開く
ファシリテーションについて
自分用メモ
ファシリテーションとは
- 「腹落ち」を生み出すコミュニケーションの技術
- 「腹落ち」= 目的と理由の理解、ゴールの理解、当事者意識、ワクワク
- リーダー必須スキル
目的、重要性
- 参加メンバーの知恵を引き出し、意欲を高める、自ら動く
難しさ
- 思考力、理解力、表現力が同時に必要
- しかし、思考の処理能力には限界
- そのため、会議中に考えることを少なくしておくことが必要！
事前準備(仕込み)
- 出発点と到達点を明確に
- どこから始めるべきか / どこまで結論を出すべきか
- 具体例：課題を解決したい場合のSTEP(次の4つのうち、スタートとゴールは？)
- 場の目的の共有(なぜ？)
- 解決に向けたアクションおよび理由の共有
- アクションの合意
- 実行プランの共有
- 出発点@参加者の状況の把握
- 認識レベル
- 意見や態度
- キーパーソンや人間関係
- 出発点と到達点における参加者の状態を明確に
-
- 到達点に至る論点の整理
-
会議の進行(さばき)
- 発言を引き出す
-
- 発言を理解/共有
-
- 議論の方向づけ
-
- 結論づける
-
スクラムマスターとして意識すること
- 質問を多くする
- 素晴らしい聞き手
- アイデアをまとめる手助け
- プロセスの外部に
