目指せクラウドネイティブエンジニアの備忘録

ここ1,2年キャリアが迷走してましたが、地に足をつけたクラウドエンジニアをという目標に向け、技術の備忘録を残していきます。

Clean Architecture 達人に学ぶソフトウェアの構造と設計 を読んで

今後の自分のキャリアを、クラウドネイティブを主にしたアーキテクト! と決めた中で勉強本を探して出てきた1冊。 アーキテクトをとしてシステムを設計するための基本原則がまとめられており、評判どおり大満足の内容。 自分の備忘のためにも投稿、主観もかなり入っています。

1. 書籍の紹介

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

著者
ロバート・C. マーチン(通称:アンクルボブ)
アメリカのソフトウェアエンジニア、cleancodrs.comの共同創始者、いくつかの設計原則の開発やアジャイル宣言の作者として有名

en.wikipedia.org

2. 書籍の要約

Ⅰ部 イントロ * ソフトウェアの2つの価値:振る舞い とアーキテクチャ
* アーキテクチャが崩れる可能性はたびたびある、四象限に分類し優先順位付  →アイゼンパワーのマトリックス、下記順番で対応するのがよい    1.重要緊急 2重要緊急ではない 3重要ではない緊急 4重要ではない緊急ではない

Ⅱ部 プログラミングパラダイム * 構造化プログラミング
 →go to 文を排除し、if/then/elseに:直接的な制御の移行に対する規律 * オブジェクト指向プログラミング
 →カプセル化、継承、ポリモーフィズム:間接的な制御の移行に対する規律 * 関数型プログラミング
 →代入の制約(参照渡しなど):代入に対する規律
* それぞれのパラダイムはプログラムに規律を課している、それぞれ、機能・コンポーネントの分離・データ管理に対応。

Ⅲ部 設計原則 * SOLID原則 1. 単一責任の原則 SRP
 →クラスは単一の責任のみ保有するべき、クラスは責任の範囲で定義する 2. オープン・クローズドの原則 OCP
 →変更の影響は受けにくく、システムは拡張しやすい。クラスの関係に対する方向の向きや、クラスの持ち方について 3. リスコフの置換原則 LSP
 →継承の使い方の指針、RectangleとSquareの話 4. インターフェイス分離の原則 ISP
 →そのまま。分けましょう 5. 依存関係逆転の原則 DIP
 →OCPが成り立つように関係を定義する、抽象化の原則。プログラムの流れとクラスの関係が逆になるため、この名前
  Abstract Factoryパターン

  • コンポーネントの凝集性(Cohesion)
    ※凝集性:情報工学においてモジュール内のソースコードが特定の機能を提供すべく如何に協調しているかを表す度合いである。     IPAが実施する情報処理技術者試験では、強度という言葉が使われる。凝集度は順序尺度の一種であり、「凝集度が高い」とか「凝集度が低い」といった言い方で使われる。

  • 再利用・リリース等価の原則(REP)

  • 閉鎖性共通の原則(CCP)  →同じ理由、タイミングで変更されるクラスをコンポーネントにまとめる、変更の理由やタイミングが異なるクラスは別コンポーネント
     →SRPと類似
  • 全再利用の原則(CRP)  →コンポーネントのユーザーに対して、実際に使わないものへの依存を強要してはいけない(ISPを一般化したもの)

  • コンポーネントの結合

  • 非循環依存関係の原則(ADP)
     →コンポーネントの依存グラフに循環依存があってはいけない
  • 安定依存の原則(SDP)
     →安定度の高い方向に依存させる
  • 安定度・抽象度の原則(SAP)
     →コンポーネントの抽象度は安定度と同程度でないといけない
    ※依存性管理の指標
  • バンダリーを引く。ソフトウェアアーキテクチャとはバウンダリーを引く技芸
  • クリーンアーキテクチャ
     →フレームワーク非依存、テスト可能、UI非依存、データベース非依存、外部エージェント非依存
     →1.ビジネスルール、2.アプリケーションのビジネスルール、3.インターフェイスアダプター、4.フレームワークとドライバー

クリーンアーキテクチャ(The Clean Architecture翻訳) | blog.tai2.net f:id:Hatetauen:20191109230130p:plain

3. 所感

原則の内容詳細は正直薄いが、アーキテクチャの全体感を捉える意味で良かった。ただ少し歴史を感じる。 あるべきはまさに示されている原則にしたがって実行するというのは理解できるが、Howが書かれていない。 これをどこまで咀嚼し実行できるか試されている気がします。

 エンジニアリング組織論への招待を読んで

職場の先輩に進められ、下記本を読みました。 良本だったのと自分の備忘のためにも投稿します。

1.書籍の紹介

mixi一期生の広木さんが書いた書籍。現在は「株式会社レクター取締役」。

※Qitaにも著者の紹介議事があったので掲載 qiita.com

2.読もうと思った理由

  1. 前述の通り先輩の紹介
  2. 基幹システム刷新の企画フェーズに参画していたのだが、中々うまくいかず。。  そんな中で割と共感できそうな部分が多かった。

3. 書籍の要約

Chapter 1 思考のリファクタリング

  • 思考の違いによる不確実性(エントロピー)から発生する様々な事象(プロジェクト初期の不確実性やコミュニケーションコスト、認知の歪み、ベーコンの4つのイドラ、情報の非対称性)を紹介。
     →エンジニアリングとは以下のエントロピーを下げることと定義   ・不確実性(エントロピー)    未来:環境不確実性      方法不確実性      目的不確実性    他人:通信不確実性(環境不確実性を増大させる)
  • 論理的思考を、1.演繹的思考、2.帰納的思考、3. 仮説思考、と紹介。
  • ロジックツリーとシステム思考→つまりシステムとは全体から捉えらこと(全体論的思考)
  • 問題解決より問題発見のほうが難しい  →全体の問題性を整理すれば問題は解決すると紹介

Chapter 2 メンタリングの技術 * 傾聴・可視化・リフレーミング * アクノレッジメントの段階  1.存在承認  2.行動承認  3.結果承認

Chapter 3 アジャイルなチームの原理 * プロジェクトマネージとプロダクトマネージャーの関心事の違い  プロジェクトマネージャー:コストと納期、プロジェクト期間、方法論、  プロダクトマネージャー:プロダクトの目的、マーケット * アジャイルソフトウェア宣言の重要性  個人と対話  動くソフトウェア  顧客との協調  変化への対応

Chapter 4 学習するチームと不確実性マネジメント * エージェンシースラック:依頼された人は管理されないとウソをつきだす。 →見積もりやスプリント * リーンキャンバスによる仮説の作り方

Chapter 5 技術組織の力学とアーキテクチャ * 権限と責任の委譲、デリゲーションポーカー、 →技術負債とコンウェイの法則

4. 所感

個人的には前半の思考のリファクタリングが響いた。プロジェクトだけでなく一般生活でもあるある。 * 人は立場や目的が異なる中それぞれ意見するのでよく衝突するが、システム思考で全体を捉えて、情報を整理すると問題が解決する、 * 仮説思考からの論理展開、論理的思考の盲点:人は正しく事実を認知できないなど  イドラ:種族・洞窟・市場・劇場  認知の歪み:ゼロイチ思考、一般化のしすぎ、すべき思考(大学生だから就職しないと。。)、レッテル貼り、結論の飛躍、感情の理由付け などなど

あとはアジャイルもちょうどしてたので響く。

思考を整理するための知識としてとても面白い本でした。How to本というよりも読み物という印象でした。

Dockerのマウント(-v)でハマった点

Dockerでコンテナ作成時に、ホストと共有するフォルダを作成するために、「-v」でローカルファイルを作成したときに、コマンドタイプミスでハマったので記録します。

下記コマンドでコンテナを作成


  • docker run -v コンテナパス →コマンドが通るがホストとコンテナがうまくマウント出来ない
$docker inspect コンテナ名

〜
"Mounts": [
          {
              "Type": "volume",
              "Name": "a8bf414e0adf047013c34ca31e1bf289456e0813c9a3a5406f23b536bfcf6be2",
              "Source": "/var/lib/docker/volumes/a8bf414e0adf047013c34ca31e1bf289456e0813c9a3a5406f23b536bfcf6be2/_data",
              "Destination": "/Users/aa572057/Documents/docker/TestWeb1",
              "Driver": "local",
              "Mode": "",
              "RW": true,
              "Propagation": ""
          }

〜

Source:ホストのマウントパス Destination:コンテナのマウントパス


  • docker run -v ホストパス:コンテナパス

Git初心者がよく使うコマンドまとめ

Gitを触り出した初心者(筆者)が良く使うコマンドを備忘のために残します。

リポジトリの新規作成

mkdir gittest
ck gittest
git init

ローカルリポジトリへのコミット

git add ファイル名
git commit -m "メッセージ"
git commit -a //変更のあったファイルすべて
git commit -v  //変更を表示

リモートリポジトリの確認

git remote -v

リモートリポジトリからのクローン作成

cd  ローカルリポジトリ
git clone リモートリポジトリ(htttp://github.XXX)

ブランチの作成など

git branch //ブランチ表示
git branch [ブランチ名] //ブランチ作成
git checkout [ブランチ名] //カレントのブランチ名を移動
git branch -d [ブランチ名] //ブランチ削除

Github でリポジトリを削除する方法

githubリポジトリを作ったらどう削除していいかわからなくなったため、備忘で残します。

1.リポジトリのページで"Setting"を選択

f:id:Hatetauen:20190501170324p:plain

2.ページ末にある、「Delete this repository」を選択

f:id:Hatetauen:20190501170407p:plain

3.削除したいリポジトリネームを入力し削除

Gitアカウント作成方法

恥ずかしながら今までGitHubに登録していませんでした。。 ようやくですが登録するので、方法を共有したいと思います。

1. Gitインストール準備

1-1 ローカルにGitがインストールされているか確認

git --version

windowsはインストールが必要、macは初期でインストールされています。

2. Gtiアカウントの作成

  • Gitサイトへアクセス github.com f:id:Hatetauen:20190421200227p:plain

  • Subscriptionを選択します。個人ならFreeで問題なし。

f:id:Hatetauen:20190421200619p:plain

  • 認証メールを対応すれば完了です。

※ Gitのチュートリアル

guides.github.com

3. 新規リポジトリの作成

作成したいリポジトリネームを入力。 Readme...はチェックしたほうがよい。

f:id:Hatetauen:20190421202448p:plain

これで一通りは登録完了です。

AWS ec2にdockerをインストールする。

今流行りのdockerを個人的に勉強したく、AWSのEC2にdockerをインストールしてみます。

  • Dockerのインストールについて、詳細は下記を参照

docs.aws.amazon.com

手順

  1. インスタンスでインストールされているパッケージとパッケージキャッシュを更新
sudo yum update -y

2 .