NoccaLabs

Flutterアーキテクチャについて

Sun, 31 May 2026 00:00:00 GMT

概要

Flutter は「すべてがウィジェット（everything is a widget）」という思想のもと、宣言的・リアクティブに UI を構築するクロスプラットフォーム UI ツールキットである。普段は Column や Container を組み合わせるだけで画面が作れてしまうが、「なぜ width: 100 を指定しても 100px にならないのか」「ホットリロードが効かないのはなぜか」「RenderFlex overflow は何が起きているのか」といった疑問にぶつかったとき、その裏側の仕組みを知っているかどうかで対応力が大きく変わる。

この記事では、Flutter 公式ドキュメントを要約しつつ、以下のトピックを具体例を交えて整理する。

Flutter のアーキテクチャ全体像（レイヤー構造 / 3 つのツリー / レンダリングパイプライン）
Flutter 内部の仕組み（なぜ大量のウィジェットでも高速なのか）
レイアウトの黄金ルール（Constraints go down. Sizes go up. Parent sets position.）
ホットリロードの仕組みと効かないケース
ビルドモード（debug / profile / release）
ドットショートハンド構文（Dart 3.10 / Flutter 3.44）

最後に、これらを段階的に理解していくための学習ロードマップを示す。

本記事は Flutter 3.44 時点の公式ドキュメントを参照している。

💻 前提環境

Flutter: 3.44 系を想定
言語: Dart 3.10 以降
対象読者: Flutter を触り始めた初心者〜中級者
サンプルコードは説明用の簡略版

🏛️ Flutter のアーキテクチャ全体像

レイヤーモデル（Framework / Engine / Embedder）

Flutter は 拡張可能でレイヤー化されたシステム として設計されている。各レイヤーは下位レイヤーに依存するが、下位レイヤーへの特権的アクセスは持たず、フレームワーク部分はすべて 任意で置き換え可能 になっている。

レイヤー	主な言語	役割
Framework	Dart	開発者が普段触る層。ウィジェット / レイアウト / アニメーション / Material・Cupertino
Engine	C++	合成済みシーンのラスタライズ、テキストレイアウト、I/O、Dart ランタイム。`dart:ui` 経由で公開
Embedder	Java/C++（Android）, Swift/ObjC（iOS/macOS）, C++（Win/Linux）	OS との橋渡し。エントリポイント / レンダリング面 / 入力 / イベントループ

flowchart TB
  subgraph framework [Framework Dart]
    materialCupertino[Material / Cupertino]
    widgets[Widgets]
    rendering[Rendering]
    foundation[Foundation / Animation / Painting / Gestures]
    materialCupertino --> widgets --> rendering --> foundation
  end
  subgraph engine [Engine C++]
    dartui[dart:ui]
    impeller[Impeller / Skia / Dart Runtime]
    dartui --> impeller
  end
  subgraph embedder [Embedder Platform]
    os[Android / iOS / Web / Desktop]
  end
  framework --> engine --> embedder

Framework 層をさらに下から見ると次のように積み上がっている。

Foundation: 基礎クラス、アニメーション・描画・ジェスチャなどの共通抽象
Rendering: レイアウトを扱う層。レンダリング可能オブジェクトのツリーを構築する
Widgets: 合成の抽象化層。リアクティブなプログラミングモデルはここで導入される
Material / Cupertino: ウィジェット層の合成プリミティブを使って各デザイン言語のコントロールを実装

Framework 自体は比較的小さく、camera や webview などの多くの高機能はパッケージ（プラグイン）として提供される。

アプリの構成要素

flutter create で生成される標準的なアプリは、以下のピースで構成される。

Dart App: ウィジェットを組み合わせて UI とビジネスロジックを実装（アプリ開発者が所有）
Framework: ウィジェットツリーをシーンに合成する高レベル API
Engine: 合成済みシーンのラスタライズ。dart:ui で公開し、Embedder API で各プラットフォームと統合
Embedder: OS とのやり取り、イベントループ管理
Runner: Embedder のプラットフォーム固有 API を組み合わせ、実行可能なアプリパッケージにする

リアクティブ UI: `UI = f(state)`

Flutter は React に影響を受けた リアクティブ / 宣言的 UI フレームワークである。開発者は「アプリの状態 → UI の対応」を記述するだけで、状態が変わったときの UI 更新はフレームワークが担う。

ウィジェットは build() メソッドで自身の UI を宣言する。これは状態を UI に変換する関数だと考えられる。

UI = f(state)

build() は 副作用がなく高速 であることが前提で、フレームワークは必要に応じて（最悪フレームごとに）何度でも呼び出せる。

ウィジェットと「合成（Composition）」

Flutter の最大の特徴のひとつが 積極的な合成（aggressive composability） である。たとえば「余白」は他ウィジェットのプロパティではなく、Padding という独立したウィジェットになっている。中央寄せも Align プロパティをいじるのではなく Center ウィジェットで包む。

// 中央寄せは「プロパティ」ではなく「ウィジェットで包む」
Center(
  child: Padding(
    padding: const EdgeInsets.all(16),
    child: const Text('Hello World'),
  ),
)

クラス階層をあえて 浅く広く することで、小さな単機能ウィジェットの組み合わせ爆発によって表現力を確保している。よく使う Container でさえ、内部的には LimitedBox / ConstrainedBox / Align / Padding / DecoratedBox / Transform といったウィジェットの合成で作られている。

3 つのツリー（Widget / Element / RenderObject）

Flutter を理解するうえで最重要なのが、3 種類のツリー が連携して動く点である。

flowchart LR
  subgraph w [Widget Tree]
    w1["不変の設定値<br/>毎フレーム作り直し可"]
  end
  subgraph e [Element Tree]
    e1["ツリー上の位置と実体<br/>State を保持・永続的"]
  end
  subgraph r [RenderObject Tree]
    r1["レイアウト・描画<br/>ヒットテスト"]
  end
  w -->|inflate| e -->|生成・更新| r

ツリー	性質	役割
Widget	不変（immutable）	UI の「設定」。`build()` が毎回新しく返す
Element	永続的	ウィジェットの「実体」。ツリー上の位置と State を保持
RenderObject	永続的	実際のレイアウト・描画・ヒットテストを担当

ポイントは Widget は使い捨て、Element は再利用される という点。 Text('A') を Text('B') に変えると新しい Widget オブジェクトが作られるが、Element ツリーはフレームをまたいで維持され、変更があった部分だけを差分更新する。これにより「ウィジェットツリーは完全に使い捨てに見えるが、内部表現はキャッシュされている」という設計が成立する。

Element には 2 種類ある。

ComponentElement: 他の Element を保持するホスト
RenderObjectElement: レイアウトや描画フェーズに参加する Element（対応する RenderObject の仲介役）

build() の引数 BuildContext は、実体としてはこの Element への参照（ツリー上の位置のハンドル）であり、Theme.of(context) のような呼び出しはこの context を使って祖先を辿っている。

状態管理（State / InheritedWidget）

状態を持たないウィジェットは StatelessWidget
状態を持つウィジェットは StatefulWidget。ウィジェット自体は不変なので、可変状態は別の State クラスに保持する
状態を変えるときは setState() を呼び、フレームワークに再 build を依頼する

ツリーが深くなると、状態をバケツリレーするのが煩雑になる。そこで InheritedWidget を使うと、共通の祖先からデータを効率よく取得できる。

// 祖先に置いた状態を、子孫から型で取得する
final studentState = StudentState.of(context);

Flutter 自身もテーマ（Theme.of(context)）などで InheritedWidget を多用している。provider などの状態管理パッケージも、その多くは InheritedWidget のラッパーである。

レンダリングパイプライン（Build → Layout → Paint）

UI コードが実際のピクセルになるまでの流れは次の通り。

flowchart LR
  state[State] -->|build| widget[Widget Tree]
  widget -->|inflate| element[Element Tree]
  element -->|create/update| render[RenderObject Tree]
  render -->|layout| size[サイズ・位置確定]
  size -->|paint| scene[Scene]
  scene -->|compositeFrame| gpu[GPU でラスタライズ]

Build: 状態から Widget ツリーを構築し、対応する Element ツリーへ展開（inflate）。ここで Container が ColoredBox を挿入するなど、コードより深いツリーになることがある
Layout: RenderObject ツリーを深さ優先で 1 パス走査。親から子へ制約（constraints）を渡し、子から親へサイズ（geometry）を返す。O(n) で完了する
Paint: 各 RenderObject が paint() で描画。ルートの RenderView が compositeFrame() でシーンを合成し、dart:ui 経由で GPU に渡す

なお Flutter は OS のウィジェットを使わず、自前のウィジェットセットを直接描画する（描画は Impeller）。これにより OS バージョンによらず同じ見た目・性能を保ち、Flutter ↔ プラットフォーム間の往復オーバーヘッドを避けている。

⚙️ Flutter 内部の仕組み（なぜ高速なのか）

積極的な合成の結果、Flutter の UI は 大量のウィジェット で構成される。それでも高速に動くのは、レイアウトとビルドに サブリニア（sublinear）なアルゴリズム を採用しているためである。

サブリニアなレイアウト

Flutter のレイアウトは 1 フレームにつき 1 回・単一パス で行われる
親が子の layout を呼んで制約を渡し、子はサイズを返す。一度返した RenderObject はそのフレームでは原則 二度と訪問されない
各 RenderObject はレイアウト中に 最大 2 回（下りと上り）しか訪問されない

さらに、無駄な再計算を避ける仕組みがある。

子が dirty でなく、前回と 同じ制約 を受け取ったなら、子は即座に return できる（走査を打ち切る）
親が子のサイズを使わないなら、子のサイズが変わっても親は再レイアウト不要
tight 制約（最小 = 最大）なら、子は親から新しい制約が来ない限りサイズを変えられないので、親の再計算も不要

結果として、dirty なノードとその周辺の限定的な部分木だけが訪問される。

サブリニアなウィジェットビルド

ビルド後のウィジェットは Element ツリーが保持する（ウィジェットは不変で親子関係を覚えられないため）
setState() などで Element が dirty になると、フレームワークは dirty な Element のリストを持ち、ビルド時にそこへ直接ジャンプして clean な Element を飛ばす
ビルド中は情報が 下方向にしか流れない ため、各 Element はビルド時に最大 1 回しか訪問されない

ここで効くのが const と「再投影（reprojection）」パターン。ウィジェットが不変なので、親が 同一インスタンス の子で再ビルドすれば、Element はオブジェクト同一性の比較だけで「変わっていない」と判断し、即座に return できる。

// const を付けると同一インスタンスとして扱われ、再ビルドがスキップされやすい
const SizedBox(height: 20)

また、InheritedWidget は各 Element にハッシュテーブルとして情報を 下方向にプッシュ することで、テーマ参照などのたびに親チェーンを辿る O(N²) を回避している。

線形の差分（reconciliation）と key

意外なことに、Flutter は ツリー差分（tree-diffing）アルゴリズムを使っていない。代わりに、各 Element の子リストを個別に O(N) で照合する。最適化されるケースは以下。

旧子リストが空
新旧リストが同一
1 か所だけ挿入・削除された
同じ key を持つウィジェット同士をマッチさせる

key を付けると、リスト内で要素が並び替わっても「同じものだ」と認識でき、State を取り違えずに済む。

ツリーサージェリー（GlobalKey）

Element の再利用は、State と RenderObject を保持できる ため性能上きわめて重要。 GlobalKey を使うと、Element ツリーの 別の場所へウィジェットを移動 しても、新規生成ではなく既存 Element を付け替え（reparent）て部分木全体を維持できる。

これは Hero アニメーション やナビゲーションで多用される。移動先の親が同じ制約を渡せば、子はレイアウトを即 return できるため、移動してもレイアウト情報が再利用される。

無限スクロール（Viewport / Sliver）

ListView のような無限スクロールは、表示されているぶんだけウィジェットをオンデマンド生成する。

スクロール領域の外側は Viewport（「中身が外より大きい箱」）
その子は RenderBox ではなく RenderSliver（ビューポートを意識したレイアウトプロトコルを持つ）
Sliver は「見えている残り空間」の情報を受け取れるので、無限の子を持ちうる場合でも 有限個だけ 生成する

これを成立させるため、Flutter は ビルドとレイアウトのフェーズを織り交ぜる。レイアウト中（＝見える空間が分かった時点）に、その配下のウィジェットを必要なぶんだけ生成できる。

Element と RenderObject を分ける理由

両ツリーはほぼ同型（RenderObject ツリーは Element ツリーの部分集合）だが、あえて分けている。

性能: レイアウト変更時、合成由来の余計なノードを飛ばして必要部分だけ走査できる
明確さ: ウィジェットのプロトコルと描画のプロトコルをそれぞれ専門化でき、API が単純になる
型安全: RenderObject ツリーは座標系ごとに型を保証できる

📐 レイアウトの黄金ルール

Flutter のレイアウトでつまずく多くの原因は、HTML/CSS の感覚を持ち込んでしまうこと。公式は次のルールを 早い段階で暗記すべき としている。

Constraints go down. Sizes go up. Parent sets position. （制約は下りていく。サイズは上っていく。位置は親が決める。）

詳細にすると次の流れ。

ウィジェットは親から 制約（constraints） を受け取る。制約とは「最小・最大の幅」「最小・最大の高さ」の 4 つの double
ウィジェットは各子に制約を伝え、子に「どんなサイズになりたいか」を尋ねる
ウィジェットは子の位置を決める
最後に、ウィジェットは自分の サイズ を親に伝える（受け取った制約の範囲内で）

親子の「交渉」の具体例

公式の例（幅 300・高さ 85 の制約、5px の padding 付き Column）を要約すると、こうした会話になる。

親「君は幅 0〜300px、高さ 0〜85px の範囲ね」
ウィジェット「padding 5px ぶん引くので、子には最大 290 × 75 を渡そう」
第 1 子「では幅 290px、高さ 20px にします」
ウィジェット「2 つ目は第 1 子の下に置くから、残り高さは 55px」
第 2 子「幅 140px、高さ 30px にします」
ウィジェット「位置は第 1 子 (5,5)、第 2 子 (80,25)。自分は 300×60 にする」と親へ報告

つまり 位置は子自身では決められず、親が決める。子は与えられた制約の範囲でしかサイズを選べない。

ボックスの 3 つのタイプ

制約の扱い方で、ボックスは大きく 3 種類に分かれる。

タイプ	振る舞い	例
できるだけ大きくなる	与えられた制約いっぱいに広がる	`Center`, `ListView`
子と同じサイズになる	子に合わせる	`Transform`, `Opacity`
特定サイズになろうとする	固有のサイズを持つ	`Image`, `Text`

Container は引数次第で変化する。デフォルトは「できるだけ大きく」だが、width を与えるとそのサイズを尊重しようとする。

これが「width: 100 を指定したのに 100px にならない」問題の正体。たとえば画面いっぱいの制約を受けた Container(width: 100) は、親（画面）の tight な制約 に従って画面サイズになってしまう。Center で包むと、Center が子に「0〜画面サイズ」の loose な制約 を渡すため、ようやく 100px になれる。

// これは画面いっぱいになる（親が tight な制約を渡すため width が無視される）
Container(width: 100, height: 100, color: Colors.red)

// Center で包むと loose な制約になり、100x100 になれる
Center(
  child: Container(width: 100, height: 100, color: Colors.red),
)

tight 制約と loose 制約

tight（きつい）制約: 最小 = 最大。満たすサイズはただ 1 つ。例: 画面ルートが子に渡す制約
loose（ゆるい）制約: 最小が 0。「最大までなら好きなサイズで良い」。例: Center が子に渡す制約

ConstrainedBox と UnconstrainedBox の違いも理解の助けになる。

ConstrainedBox: 親から受けた制約に 追加の制約 を課す。親が tight ならその追加は効かないことがある
UnconstrainedBox: 子に制約を課さず、子が好きなサイズになれる。ただし子が大きすぎると、あの overflow 警告 が出る

// Row の中で子が大きすぎると "RenderFlex overflow" になる
Row(
  children: [
    Container(width: 4000, color: Colors.blue), // 画面幅を超えて溢れる
  ],
)

Row / Column のオーバーフローは、「子に制約を課さない」性質と「画面という有限の制約」がぶつかった結果である。Expanded や Flexible で残り空間を分配したり、SingleChildScrollView でスクロール可能にしたりして解決する。

🔥 ホットリロードの仕組み

ホットリロードは、更新したソースコードを実行中の Dart ランタイムへ注入 する機能。クラスのフィールドや関数を新しい版に差し替えたあと、Flutter フレームワークがウィジェットツリーを自動的に再ビルドし、変更を即座に確認できる。

仕組み

ホスト側が前回のコンパイル以降に編集されたコードを調べ、変更されたライブラリ・アプリのメインライブラリ・そこに至るライブラリを再コンパイルする
生成された kernel ファイルをデバイスの Dart VM に送る
Dart VM が新しい kernel からライブラリを再ロードする（この時点ではまだコードは再実行されない）
フレームワークが既存の全ウィジェット / RenderObject の再ビルド・再レイアウト・再描画を発火する

重要なのは、ホットリロードは既存ウィジェットの再ビルドを引き起こすだけ という点。再ビルドに関わるコードしか再実行されないため、main() や initState() は 再実行されない。

State が保持される

ホットリロードは アプリの状態を保持 する。ログイン後の深い画面で UI を修正してリロードしても、ログインし直さずに変更を確認できる。これが通常は望ましい挙動。

ただし、状態に影響する変更をした場合、「最初から実行したときの状態」とは食い違うことがある。その場合は ホットリスタート（状態を捨てて再起動）が必要になる。

ホットリロードが効かない / 効きにくいケース

ケース	挙動	対処
`main()` / `initState()` の変更	再実行されないため反映されない	ホットリスタート
グローバル変数・static フィールドの初期化子変更	遅延初期化のため再実行されない	ホットリスタート
enum ↔ 通常クラスの相互変更	反映されない	ホットリスタート
ジェネリック型の宣言変更（`A<T>` → `A<T, V>`）	反映されない	ホットリスタート
ネイティブコード（Kotlin/Swift 等）の変更	反映されない	フルリスタート（停止して再起動）
コンパイルエラー	拒否されエラー表示	該当行を修正
アプリが kill された	中断される	再起動

// 例: ルートウィジェットの build より「下流」の変更はホットリロードで反映される
class Counter extends StatelessWidget {
  const Counter({super.key});

  @override
  Widget build(BuildContext context) {
    // ここの文字色やテキストを変えるとホットリロードで即反映される
    return const Text('count: 0');
  }
}

判断の目安は「変更したコードが、ルートウィジェットの build() より下流で再実行されるか」。下流なら反映される。final bar = foo; のような初期化子の変更は反映されにくいので、const にするか getter（int get bar => foo;）に置き換えると良い。

🏗️ ビルドモード

Flutter はコンパイル時に 3 つのモードを持つ（加えてテスト用のヘッドレスモード）。開発サイクルのどこにいるかで使い分ける。

モード	用途	コンパイル	主な特徴
debug	開発中（ホットリロード）	JIT	assert 有効、サービス拡張有効、デバッグ可能。実行速度より開発速度を最適化
profile	性能分析	AOT	release に近いが、トレースと一部サービス拡張（パフォーマンスオーバーレイ等）が有効
release	本番リリース	AOT	assert 無効、デバッグ情報除去、起動・実行・サイズを最適化

flutter run            # debug（デフォルト）
flutter run --profile  # profile
flutter run --release  # release
flutter build apk      # release ビルドの生成（ターゲット指定）

ポイント。

debug は JIT、profile / release は AOT（事前にネイティブコードへコンパイル）でマシンコードに変換される
ホットリロードは debug モードのみ 利用できる
profile / release は実機が必要で、エミュレータ / シミュレータでは無効（実機相当の性能が出ないため）
Web では debug が dartdevc、release が dart2js（minify + tree shaking）でコンパイルされる

開発は debug、カクつきの原因調査は profile、ストア提出は release、と覚えておけば良い。

✨ ドットショートハンド構文（Dart 3.10 / Flutter 3.44）

ドットショートハンドは、コンパイラが文脈から型を推論できる場合に、静的メンバ・コンストラクタ・enum 値の型名を省略できる 機能。 Flutter は深くネストしたウィジェットツリーを書くことが多く、Alignment.center や MainAxisAlignment.center のような型名の繰り返しがボイラープレートになりがちだった。これを .center のように短く書ける。

Before / After

// Before（型名を明示）
Container(
  alignment: Alignment.center,
  padding: const EdgeInsets.all(16.0),
  child: Column(
    mainAxisAlignment: MainAxisAlignment.center,
    crossAxisAlignment: CrossAxisAlignment.start,
    children: [
      Text('Hello World', style: TextStyle(fontWeight: FontWeight.bold)),
    ],
  ),
);

// After（ドットショートハンド）
Container(
  alignment: .center,                  // Alignment.center
  padding: const .all(16.0),           // EdgeInsets.all(16.0)
  child: Column(
    mainAxisAlignment: .center,        // MainAxisAlignment.center
    crossAxisAlignment: .start,        // CrossAxisAlignment.start
    children: [
      Text('Hello World', style: TextStyle(fontWeight: .bold)), // FontWeight.bold
    ],
  ),
);

使える場所

コンパイラが明確な「コンテキスト型」を持つ場所、つまりウィジェットのプロパティ指定のほぼすべてで使える。

enum: MainAxisAlignment, CrossAxisAlignment, BoxFit, TextDirection など
静的プロパティ / メソッド: FontWeight.bold → .bold など
コンストラクタ: EdgeInsets.all() → .all()、BorderRadius.circular() → .circular()

// 名前付きコンストラクタ（基底クラス EdgeInsetsGeometry を推論）
Padding(
  padding: .symmetric(horizontal: 16.0, vertical: 8.0),
  child: Text('Spaced out text'),
)

// .new で無名コンストラクタも呼べる（ウィジェットツリーでは稀）
final ScrollController _scrollController = .new(); // ScrollController()

型名が省けるぶん可読性が上がる一方、文脈が曖昧だと推論が効かない。慣れるまでは「何の型が推論されているか」を意識しておくと安全。

🗺️ 理解を深めるためのロードマップ

ここまでの内容を、手を動かしながら段階的に深めていくためのロードマップを示す。各フェーズの「課題」を実際に試すことで、ドキュメントの知識が腑に落ちる。

flowchart TB
  p1["Phase 1: 入門<br/>ウィジェットで画面を作る"]
  p2["Phase 2: 基礎<br/>レイアウトと状態管理"]
  p3["Phase 3: 内部理解<br/>3 ツリーとパイプライン"]
  p4["Phase 4: 実践<br/>性能・最適化・運用"]
  p1 --> p2 --> p3 --> p4

Phase 1: 入門 — ウィジェットで画面を作る

項目	手を動かす課題	対応ドキュメント
Stateless / Stateful の違い	カウンタアプリを `setState` で実装	architectural-overview
合成（composition）	`Center` + `Padding` + `Column` で簡単な画面を組む	architectural-overview
ホットリロード体験	色やテキストを変えて即反映を確認、`main()` 変更が効かないことも体験	hot-reload

ゴール: 「すべてがウィジェット」「UI = f(state)」を体感する。

Phase 2: 基礎 — レイアウトと状態管理

項目	手を動かす課題	対応ドキュメント
レイアウトの黄金ルール	`Container(width:100)` が画面いっぱいになる→`Center` で 100px になる、を再現	constraints
tight / loose 制約	`ConstrainedBox` と `UnconstrainedBox` の違いを確認	constraints
overflow の解消	`Row` をわざと溢れさせ、`Expanded` / `SingleChildScrollView` で直す	constraints
状態の受け渡し	`InheritedWidget`（または `provider`）でテーマや状態を共有	architectural-overview

ゴール: 「Constraints go down. Sizes go up. Parent sets position.」を説明できる。

Phase 3: 内部理解 — 3 つのツリーとパイプライン

項目	手を動かす課題	対応ドキュメント
Widget / Element / RenderObject	Flutter DevTools の Inspector で実際のツリーの深さを観察	architectural-overview / inside-flutter
key の役割	リストの並び替えで State が崩れる例を作り、`key` で直す	inside-flutter
GlobalKey とツリーサージェリー	`Hero` アニメーションを実装し、State 保持を確認	inside-flutter
const の効果	`const` の有無で再ビルド回数が変わることを確認	inside-flutter
無限スクロール	`ListView.builder` で大量データを表示し、Sliver の遅延生成を理解	inside-flutter

ゴール: 「なぜ大量のウィジェットでも高速なのか（サブリニア / 線形差分）」を説明できる。

Phase 4: 実践 — 性能・最適化・運用

項目	手を動かす課題	対応ドキュメント
ビルドモードの使い分け	debug / profile / release を切り替えて性能差を体感	build-modes
性能分析	profile モードで DevTools の Performance を見て jank を調査	build-modes
`RepaintBoundary`	再描画範囲を絞って描画コストを下げる	inside-flutter
ドットショートハンド	既存コードを `.center` 等で書き換えて可読性を改善	dot-shorthands
プラットフォーム連携	Platform Channel / FFI でネイティブ機能を呼ぶ	architectural-overview

ゴール: 性能問題を計測ベースで切り分け、適切な最適化を選べる。

📚 参考リンク（公式ドキュメント）

OSPO（Open Source Program Office）とは？

Sun, 24 May 2026 00:00:00 GMT

概要

OSPO（Open Source Program Office）は、企業や組織においてオープンソースソフトウェア（OSS）を効果的かつ安全に活用・管理するための専門部署です。

TODO Group の定義では、OSPO は組織の OSS 運用の「center of competency（能力の中心）」であり、戦略・ガバナンス・コンプライアンス・コミュニティエンゲージメントという4つの枠組みを横断して、コードの利用・配布・選定・監査・コントリビュートに関するポリシー策定、社内外の教育、法務コンプライアンスの担保、コミュニティとの橋渡しを担うとされています。 (TODO Group OSPO Definition)

この記事では「OSPO とは何か」だけでなく、OSS / OSPO に関わる人材になるにはどうすればよいかという視点で、必要な知識・なり方・具体的なロードマップ・OSS 活動で押さえておくべきことを横断的にまとめます。

1. OSPO人材の全体像

OSPO は単一の職種ではなく、複数の専門性を持つ人が「異なる帽子をかぶって」協働する組織です。 (TODO Group OSPO Definition) おおまかに次の3つの顔があります。

顔	主な役割	関連スキル
技術	OSS 利用方針、依存管理、上流コントリビュート、内製の OSS 化支援	SDLC / Git / CI/CD / セキュリティ
法務・コンプライアンス	ライセンス選定・互換性、IP 管理、監査、M&A 時のソース監査	OSS ライセンス / 知財 / コンプラ
コミュニティ・エコシステム	Developer Relations、社内教育、財団・コミュニティとの関係構築	コミュニケーション / 渉外 / 教育

そして、OSS への関わり方には段階があります。多くの人は「利用者」から始まり、徐々に関与を深めていきます。OSPO 担当者はこの全レイヤーを理解していることが求められます。

flowchart LR
    user["OSS利用者<br/>(使う・読む)"] --> contributor["コントリビューター<br/>(Issue/PRを出す)"]
    contributor --> maintainer["メンテナー<br/>(プロジェクトを運営)"]
    maintainer --> ospo["OSPO担当<br/>(組織横断で統括)"]
    user -. "ポリシー/教育で支援" .- ospo
    contributor -. "上流ファースト推進" .- ospo

重要なのは、「いきなり OSPO 担当になる」のではなく、利用者・コントリビューターとしての実体験を積み上げた人がOSPO の中核を担うという点です。

2. どんな知識が必要か

OSPO / OSS 人材に求められる知識は、大きく4つの能力領域に分けられます。これは Linux Foundation の OSPO 研修（OSPO 101）でカバーされる範囲ともおおむね一致します。 (OSPO Career Path / OSPO 101)

2-1. 技術

OSS の利用と貢献の土台になる、ソフトウェアエンジニアリングの基礎知識です。

ソフトウェア開発ライフサイクル（SDLC）の理解
Git / GitHub（fork、branch、PR、レビュー、issue 運用）
CI/CD（GitHub Actions などでのビルド・テスト自動化）
依存管理（lockfile による固定、^1.2.3 のような曖昧バージョンの危険性）
SBOM / SCA（Software Composition Analysis）による依存の可視化

2-2. 法務・コンプライアンス

OSPO の存在意義の中核。ライセンスを「読めて・判断できる」ことが求められます。

ライセンス	タイプ	主な注意点
MIT / BSD	パーミッシブ	著作権表記の保持
Apache-2.0	パーミッシブ	特許条項、NOTICE ファイル
GPL / LGPL	コピーレフト	ソース開示義務、リンク形態
AGPL	強いコピーレフト	ネットワーク越し利用も開示対象
SSPL	非OSI	商用 SaaS 提供に制限

ライセンス互換性（例: GPL と Apache-2.0 の組み合わせ可否）
IP（知的財産）・著作権・NOTICE / attribution（著作権表記）
監査（M&A 時のソースコードデューデリジェンスを含む）

2-3. セキュリティ・サプライチェーン

近年もっとも重要度が増している領域です。詳細は別記事の CNCFプロダクトルールについてにまとめていますが、最低限以下は押さえておきたいところです。

SBOM 生成（Syft / Trivy）と脆弱性スキャン（Grype / osv-scanner）
成果物への署名（cosign / sigstore）と来歴情報（provenance / SLSA）
OpenSSF Scorecard によるプロジェクトの健全性評価
SECURITY.md、2FA、branch protection などのメンテナー保護

2-4. ソフトスキル

意外と軽視されがちですが、OSPO の成否を分けるのはむしろここです。

コミュニティ運営・ファシリテーション
Developer Relations（社内外の開発者との関係構築）
社内教育・トレーニングの設計
部門横断（エンジニア・法務・経営）の調整力・合意形成

3. どうすればなれるか

OSPO 人材への道は、段階的に OSS への関与を深めることで開けます。資格よりも「実際に OSS を使い、貢献し、社内で旗を振った実績」が重視されます。

OSS 利用者として基礎を固める
- 業務で使っている OSS のライセンスを一覧化してみる
- 依存ツリーと脆弱性を実際にスキャンしてみる
小さなコントリビュートを始める
- ドキュメント修正・typo・翻訳など低リスクな PR から
- good first issue ラベルの活用
ライセンス／コンプライアンスを学ぶ
- 自社プロダクトのライセンス互換性をチェック
- NOTICE / attribution の整備
社内ポリシー・教育に関与する
- OSS 利用申請フローや承認ポリシーの草案づくり
- 開発者向けのライセンス入門研修を企画
OSPO ロールへ
- TODO Group は OSPO Lead 採用のための職務記述テンプレートも公開しており、求められる役割像の参考になります。 (How to create an OSPO)

OSPO Lead に求められるのは、技術とビジネス双方を理解し、組織文化を踏まえて橋渡しできる人材です。 (FINOS OSPO ロール定義)

4. 具体的なロードマップ

学習と実践を並走させる、フェーズ別のロードマップ例です。あくまで目安として、自分の現状に合わせて調整してください。

フェーズ	学習リソース	実践・成果物
0〜3ヶ月（基礎）	OSPO 101 の「Open Source Introduction」、Git/GitHub 入門	業務で使う OSS のライセンス一覧を作成、初めての PR（docs/typo）
3〜6ヶ月（コンプラ／貢献）	LFC112（Open Source Licensing Basics）、OSPO 101 の「Compliance Programs」	依存スキャン＆ SBOM 生成の習得、機能 PR、ライセンス互換性チェック表
6〜12ヶ月（運営／統括）	LFC204（Effective Open Source Program Management）	社内 OSS 利用ポリシー草案、開発者向け研修の実施、上流コントリビュート戦略の提案

学習リソースの入口:

TODO Group OSPO Career Path / OSPO 101（無料・モジュール式）
Linux Foundation Open Source Management & Strategy（LFC112 / LFC204 等）
OSPO Book（OSPO の立ち上げ・運営の体系的ガイド）

利用 → 貢献 → コンプラ理解 → 社内ポリシー → OSPO運営
 │        │           │              │            │
基礎     初PR      SBOM/ライセンス   研修/規程    戦略立案

5. OSS活動で知っておくべきこと

実際に OSS に貢献・運営する際に、つまずきやすい・トラブルになりやすいポイントをまとめます。

5-1. コントリビュート前の確認

CONTRIBUTING.md を読み、貢献の手順・コーディング規約を確認する
CLA（Contributor License Agreement）／ DCO（Developer Certificate of Origin） の署名要否を確認する
CODE_OF_CONDUCT.md（行動規範）を尊重する
大きな変更は、いきなり PR を出す前に Issue で方針を合意しておく

5-2. 良い PR・コミットの作法

1 PR = 1 目的（巨大な PR は避ける）
コミットメッセージは「なぜ」を伝える
テストを添える、CI を緑にする
上流ファースト（upstream first）: 自社で fork して魔改造するのではなく、まず本家に還元できないかを考える

5-3. ライセンス順守

「コピー&ペーストの罠」: ネット上のコードにもライセンスがある
依存を追加するときは追加前にライセンスを確認する
GPL / AGPL 混入はプロダクトの配布形態に影響する
NOTICE / attribution（著作権表記）の保持義務を忘れない

5-4. メンテナー視点

自分がプロジェクトを公開・運営する側になったときに重要になる点です。

項目	内容
`SECURITY.md`	脆弱性の報告窓口・対応方針を明示
2FA 必須	GitHub / npm / PyPI などのアカウント保護
署名コミット	GPG / Sigstore による真正性担保
レビュー必須	1人 merge を避け、レビュー文化を作る

5-5. 企業として参加する際の注意

業務時間での OSS 貢献に関する社内ルール（就業規則・著作権の帰属）を確認する
会社として CLA に署名できる権限があるか
コミットに機密情報・社内固有情報が混入しないかを必ずチェックする

6. まとめ & 次の一歩

OSPO / OSS 人材は、技術・法務・コミュニティを横断する「橋渡し役」です。資格よりも実体験が物を言う領域であり、小さく始めて段階的に関与を深めるのが王道です。

まず踏むべき最初の一歩はシンプルです。

いま業務で使っている OSS を1つ選び、そのライセンスと依存関係を調べてみる。

ここから「利用者 → コントリビューター → メンテナー → OSPO 担当」への道が始まります。

参考リンク

短縮URL OSS 徹底比較 (Shlink / YOURLS / Kutt / Dub / Polr / Slash / Sink)

Thu, 21 May 2026 00:00:00 GMT

概要

短縮URLサービスは Bitly や TinyURL のような SaaS が有名ですが、以下のような理由で自前運用を検討するケースがあります。

自社ドメインで運用したい
アクセスログを社外に出したくない
課金体系に縛られたくない
SaaSのリンク数制限に引っかかる

こうした要件には 自己ホスト型 (Self-hosted) の OSS がフィットします。本記事では代表的な OSS を比較し、AWS で構築した場合の費用感や、選定時にチェックしたい観点を整理します。

想定読者とこの記事のゴール

短縮URLサービスを自社で運用したいエンジニア・SRE
マーケティング部門から「クリック分析できる自社ドメインのリンクが欲しい」と相談を受けた人
既存の Bitly 等から自前運用へ移行を検討している人

ゴールは次の3点です。

主要 OSS の特徴・できること/できないことを把握する
AWS で構築した場合の概算費用を見積もる
運用に乗せるための検討ポイントを押さえる

まず全体像

短縮URL OSS は、大まかに次のような系統に分けられます。

flowchart LR
    A[短縮URL OSS] --> PHP[PHP系]
    A --> NODE[Node.js系]
    A --> GO[Go系]
    A --> EDGE[エッジ/サーバーレス系]

    PHP --> Shlink
    PHP --> YOURLS
    PHP --> Polr
    NODE --> Kutt
    NODE --> Dub
    GO --> Slash
    EDGE --> Sink

    classDef active fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
    classDef stable fill:#fff3e0,stroke:#ef6c00,color:#e65100;
    classDef slow fill:#ffebee,stroke:#c62828,color:#b71c1c;

    class Shlink,Kutt,Dub,Slash,Sink active;
    class YOURLS stable;
    class Polr slow;

色は「メンテナンスの活発度」のイメージです (緑：活発 / 橙：安定だが緩やか / 赤：更新が少なめ)。

各 OSS の概要

Shlink

公式: https://shlink.io/
ドキュメント: https://shlink.io/documentation/
GitHub: https://github.com/shlinkio/shlink
言語: PHP 8.x (Mezzio / Laminas)
ライセンス: MIT
GitHub Star: 約 4,000+

できること (Shlink)

REST API / CLI / 公式 Web Client (別リポジトリで配布)
複数ドメイン対応 (1 インスタンスで複数ドメインの短縮URL)
QRコード生成、タグ管理、UTM パラメータ自動付与
地理情報・デバイス・OS・リファラ別の詳細トラッキング
Real-time 統計、Webhook、Matomo / Google Analytics 連携
マルチユーザー対応 (v4.x 以降)

できない・苦手 (Shlink)

単体では UI が最低限。フル機能の管理画面は shlink-web-client を別途デプロイする必要がある
パスワード保護リンク、A/B テスト、リンクの有効期限内分岐などの高機能は標準ではない

企業内の業務用途や、メール配信・キャンペーン計測のような 真面目な計測用途 に向いています。

YOURLS

公式: https://yourls.org/
ドキュメント: https://yourls.org/docs/
GitHub: https://github.com/YOURLS/YOURLS
言語: PHP
ライセンス: MIT
GitHub Star: 約 9,000+

できること (YOURLS)

古参 (2009年〜) で安定感がある
プラグインエコシステムが豊富 (yourls-plugins で公式・非公式が多数)
カスタム短縮 URL、QR コード、簡易統計、ブックマークレット
PHP + MySQL のみで動作するため、レンタルサーバーでも動く

できない・苦手 (YOURLS)

UI/UX は 2010 年代風で古い
標準の分析ダッシュボードは Bitly や Dub と比べて見劣りする
マルチテナント・チーム機能は弱い

「とにかく軽く動かしたい」「PHP のレガシー環境がある」場合に依然として現実的な選択肢です。

Kutt

公式: https://kutt.it/
ドキュメント: https://docs.kutt.it/
GitHub: https://github.com/thedevs-network/kutt
言語: TypeScript / Node.js
ライセンス: MIT
GitHub Star: 約 8,000+

できること (Kutt)

モダンな UI (React / Next.js ベース)
カスタム短縮 URL、QR コード、リンクの有効期限、パスワード保護
API トークンによる API 連携
Telegram ボット、ブラウザ拡張機能
ドメイン追加機能 (複数ドメイン対応)

できない・苦手 (Kutt)

単体ではアナリティクスがシンプル (国別・リファラ等の基本のみ)
A/B テストやリンク内クローキングなどの高度な機能はない
大規模利用では Redis + PostgreSQL の運用知識が必要

「中小規模で OK、UI もまともで API も使いたい」のスイートスポット。

Dub

公式: https://dub.co/
ドキュメント: https://dub.co/docs
GitHub: https://github.com/dubinc/dub
言語: TypeScript / Next.js
ライセンス: AGPL-3.0
GitHub Star: 約 18,000+

できること (Dub)

SaaS 品質のモダン UI / 機能 (Vercel 系開発者文化)
高機能リンク管理 (UTM ビルダー、リンククローク、Geo/Device ターゲティング、A/B テスト)
リッチな OG プレビュー、リンクの有効期限、パスワード保護
Tinybird ベースのリアルタイムアナリティクス
チーム / ワークスペース / Webhook / 公開 API
Conversion Tracking、決済連携 (Stripe)、Affiliate 等の機能も拡張中

できない・苦手 (Dub)

構成要素が多い (Postgres / Redis / Tinybird / S3 / Resend など) ため、純粋な「自己ホスト」のハードルは高い
AGPL-3.0 なので、改修して SaaS 提供する場合はソース公開義務が発生する
小規模用途にはオーバースペック気味

「Bitly の代替を本気で内製したい」場合の最右翼。SaaS 版 dub.co を使う前提でも品質は最高クラス。

Polr

公式: https://polrproject.org/
ドキュメント: https://docs.polrproject.org/
GitHub: https://github.com/cydrobolt/polr
言語: PHP (Laravel)
ライセンス: GPL-2.0
GitHub Star: 約 4,000+

できること (Polr)

シンプルかつ軽量
API、カスタム短縮 URL、基本的なクリック統計
マルチユーザー、API トークン
Pro 版 (有料) で更に機能拡張可能

できない・苦手 (Polr)

メンテナンスの活発度はやや低下傾向 (リリース間隔が長い)
モダンな分析機能はなく、SaaS と比較すると見劣りする
セキュリティ修正の追従が遅れがちなので、本番運用は要注意

「学習用、社内ツールでとりあえず動かす」用途には十分。

Slash (補足)

GitHub: https://github.com/yourselfhosted/slash
言語: Go
ライセンス: MIT
GitHub Star: 約 5,000+

できること (Slash)

単一バイナリで動作する Go 製短縮URL/ブックマーク管理
Docker で 1 コマンド起動
軽量で軽い、SQLite/PostgreSQL/MySQL に対応
チーム共有のリンクコレクション機能あり

できない・苦手 (Slash)

大規模なクリック分析は弱い
短縮 URL に特化というよりは「チーム向けリンク共有」の色合いが強い

「個人 / 小チームで Docker 1 個で済ませたい」場合の選択肢。

Sink (サーバーレス系)

GitHub: https://github.com/ccbikai/Sink
公式デモ: https://sink.cool/
言語: TypeScript (Nuxt 3)
ライセンス: MIT
GitHub Star: 約 6,000+

ここまで紹介してきた OSS は基本的に コンテナ / VM 上で動かす前提 ですが、Sink は Cloudflare ネイティブ (Workers + KV + Analytics Engine) で動作する点が大きく異なります。サーバーを 1 台も立てずに、wrangler deploy 1 コマンドで運用開始できます。

できること (Sink)

Cloudflare アカウント1つで構築完了 (サーバー不要)
グローバルにエッジ配信されるため リダイレクトの初動が非常に速い
AI (Workers AI) によるスラッグ自動生成
パスワード保護リンク、有効期限付きリンク
リアルタイムアナリティクス (国 / デバイス / リファラ、Analytics Engine ベース)
個人利用なら 実質 $0 / 月 で運用可能 (Cloudflare の無料枠内)

できない・苦手 (Sink)

Cloudflare ロックイン が強い。他クラウドへの移植性は低い
KV は 結果整合性 なので、書き込み直後の世界規模での即時反映は保証されない
Workers 無料枠は 10万 req/日、超過時は Workers Paid ($5/月〜) へ
Webhook / 業務システム連携機能は控えめ
監査ログや細かな権限管理が必要なエンタープライズ要件には不向き

「個人ブログ・社内ツール・小さな SaaS のリンク管理で、運用コストをゼロに近づけたい」場合の決定版。

比較表

観点	Shlink	YOURLS	Kutt	Dub	Polr	Slash	Sink
言語	PHP	PHP	Node.js	Next.js	PHP (Laravel)	Go	TypeScript (Nuxt 3)
ライセンス	MIT	MIT	MIT	AGPL-3.0	GPL-2.0	MIT	MIT
GitHub Star (概算)	4k+	9k+	8k+	18k+	4k+	5k+	6k+
メンテナンス活発度	高	中	高	非常に高	低〜中	高	高
初版リリース	2016	2009	2017	2022	2014	2023	2024
ホスティング形態	コンテナ/VM	コンテナ/VM	コンテナ/VM	コンテナ/VM	コンテナ/VM	コンテナ/VM	サーバーレス (Cloudflare)
DB	MySQL/MariaDB/PostgreSQL/SQLite	MySQL/MariaDB	PostgreSQL	PostgreSQL	MySQL/MariaDB/SQLite	SQLite/PostgreSQL/MySQL	Cloudflare KV
Redis	任意	不要	任意	必須 (Upstash 等)	不要	不要	不要
必須外部サービス	なし	なし	なし	Tinybird, Resend, S3 等	なし	なし	Cloudflare 一式
公式 Docker	あり	あり	あり	あり (開発用)	あり	あり	不要 (Workers)
マルチドメイン	あり	プラグイン	あり	あり	限定的	あり	あり
マルチユーザー	あり (v4+)	プラグイン	あり	あり (ワークスペース)	あり	あり	単一管理者
カスタム短縮 URL	あり	あり	あり	あり	あり	あり	あり
QR コード	あり	プラグイン	あり	あり	プラグイン	なし	あり
パスワード保護	なし	プラグイン	あり	あり	なし	なし	あり
有効期限	あり	プラグイン	あり	あり	あり	なし	あり
A/B テスト	なし	なし	なし	あり	なし	なし	なし
Geo/Device ターゲティング	なし	なし	なし	あり	なし	なし	なし
アナリティクス	高機能	簡易	中程度	非常に高機能	簡易	簡易	中程度 (Analytics Engine)
公開 API	あり (REST)	あり	あり (REST)	あり (REST)	あり	あり (gRPC/REST)	あり (REST)
想定月額 (個人利用)	$30〜 (AWS)	$30〜 (AWS)	$30〜 (AWS)	$150〜 (AWS)	$30〜 (AWS)	$30〜 (AWS)	$0 (CF 無料枠)
推奨用途	業務計測	レガシー軽量	中規模・API 利用	大規模・SaaS 品質	学習・個人	小チーム	ゼロコスト運用

AWS で構築した場合の費用概算

東京リージョン (ap-northeast-1)、1 年継続利用 (On-Demand) の概算です。為替・割引は時期により変動するため、目安としてご覧ください。

構成パターン

flowchart LR
    subgraph User
        U[利用者]
    end

    subgraph AWS
        R53[Route 53<br/>独自ドメイン]
        ALB[ALB / CloudFront]
        APP[ECS Fargate or EC2<br/>短縮URL アプリ]
        DB[(RDS<br/>MySQL/PostgreSQL)]
        CACHE[(ElastiCache<br/>Redis)]
        S3[(S3<br/>必要に応じて)]
    end

    U --> R53 --> ALB --> APP
    APP --> DB
    APP --> CACHE
    APP --> S3

パターン 1: 最小構成 (個人〜小規模社内)

項目	リソース	想定月額 (USD)
Compute	EC2 t4g.small (1台、24h)	約 $12
DB	RDS db.t4g.micro (Single-AZ)	約 $13
ストレージ	EBS 20GB + RDS 20GB	約 $5
データ転送	アウト 10GB/月	約 $1
Route 53	ホストゾーン + クエリ	約 $1
合計		約 $32 / 月 (約 5,000 円)

ALB を使わず、Nginx + Let's Encrypt で EC2 直撮 (Elastic IP) の前提です。 Shlink / YOURLS / Polr / Slash / Kutt (Redis 無し設定) が現実的です。

パターン 2: 中規模 (社内全体・サービス公開)

項目	リソース	想定月額 (USD)
Compute	ECS Fargate 0.5 vCPU/1GB × 2 タスク	約 $30
ALB	1 台	約 $22
DB	RDS db.t4g.small Multi-AZ	約 $55
Redis	ElastiCache cache.t4g.micro	約 $12
データ転送	アウト 100GB/月	約 $12
CloudFront	100GB/月	約 $10
WAF	Basic + 数ルール	約 $10
Route 53	ホストゾーン + クエリ	約 $1
合計		約 $152 / 月 (約 23,000 円)

Shlink / Kutt あたりに最適。冗長化と CDN を効かせた構成です。

パターン 3: 大規模 (Dub 級の SaaS 品質を内製)

項目	リソース	想定月額 (USD)
Compute	ECS Fargate 1 vCPU/2GB × 3 タスク	約 $90
ALB	1 台	約 $22
DB	RDS db.r6g.large Multi-AZ	約 $370
Redis	ElastiCache cache.t4g.small × 2 (HA)	約 $50
データ転送 + CloudFront	アウト 1TB/月	約 $120
ログ/分析基盤	Kinesis Firehose + S3 + Athena	約 $50
WAF + Shield Standard		約 $20
Route 53	ホストゾーン + クエリ	約 $5
合計		約 $727 / 月 (約 11 万円)

これに加えて Dub の場合は Tinybird (有料)、Resend (メール送信) などのサードパーティ費用が乗ります。

補足: 短縮URLは「リダイレクトだけ」と侮りがちですが、クリック計測の書き込み量がスループットのボトルネック になります。本格運用では Redis や ClickHouse / Tinybird のようなアナリティクス基盤の検討が早期に必要です。

パターン 4: サーバーレス (Cloudflare / Sink 利用)

AWS ではなく Cloudflare を使う前提で、Sink を採用する場合の費用感です。 EC2 / RDS / ALB といったリソースが一切不要になるため、桁が変わります。

flowchart LR
    User[利用者] --> CF[Cloudflare<br/>エッジ]
    CF --> W[Cloudflare Workers<br/>リダイレクト + 管理画面]
    W --> KV[(Cloudflare KV<br/>slug → 元URL)]
    W --> AE[(Analytics Engine<br/>クリックログ)]
    W -.->|任意| AI[Workers AI<br/>slug 自動生成]

項目	リソース	想定月額 (USD)
実行	Cloudflare Workers (Free Plan)	$0
ストレージ	Cloudflare KV (Free Plan)	$0
分析	Analytics Engine (Free 枠)	$0
独自ドメイン	Cloudflare DNS 管理	$0
合計 (小規模)		約 $0 / 月

中規模以上 (1日 10 万リクエスト超 / KV 読み取り 10 万/日超) では Workers Paid プランへの移行が必要です。

項目	リソース	想定月額 (USD)
実行	Cloudflare Workers Paid	$5
ストレージ	KV 追加分 (1000万 read で $0.50)	$1 〜
分析	Analytics Engine 超過分	$1 〜
合計 (中規模)		約 $5 〜 $10 / 月

AWS のパターン 2 (約 $152/月) と比較すると、Sink + Cloudflare は1桁安く済む ケースがほとんどです。ただし、Cloudflare 依存・KV の結果整合性・監査ログの粒度 などのトレードオフがあるため、用途と要件次第で AWS 構成と使い分けるのが現実的です。

選定にあたって検討したい観点

機能比較だけで選ぶと後悔しがちなので、以下の観点も合わせて評価することをおすすめします。

1. ドメイン戦略

短縮 URL は 独自ドメイン (例: go.example.co.jp) で発行するのが基本
ブランド毀損や乗っ取り対策のため、ドメインの HSTS preload / CAA レコード / DMARC も同時に検討
リンクは長期間生き残るので、捨てやすいドメインを使わない

2. リンクの永続性 (Link Persistence)

数年後にもクリックされる前提で、DB バックアップ・サービス停止時の代替案 を必ず用意
移行性を考えるなら、カスタム短縮 URL (slug) のエクスポート / インポート がしやすい OSS を選ぶ
ShortIO 等の SaaS から移行する場合、CSV インポート可否を確認する

3. アナリティクスの粒度と保存期間

クリックログは個人情報 (IP) を含むため、保存期間・匿名化方針 を最初に決める
大量のリンク + 大量のクリックを扱う場合、RDB だけでは負荷的に厳しい。カラムナ DB (Tinybird / ClickHouse) や Redis、Kinesis との組み合わせを検討
GDPR / 個人情報保護法を意識するなら、IP のハッシュ化やジオロケーション粒度の制御が必要

4. セキュリティ

短縮 URL は フィッシングや C2 通信の踏み台 として悪用されやすい
対策として、事前 URL スキャン (Google Safe Browsing API, VirusTotal API)、禁止ドメインリスト、レート制限、短縮可能ユーザーの認証 をどう実装するか
公開短縮 URL を許す場合は、CAPTCHA + WAF + 通報フロー を必ず設計する

5. 可用性・SLO

短縮 URL がダウンすると、過去に配信したすべてのリンクが死ぬ
影響範囲が極めて大きいので、Multi-AZ / CDN キャッシュ / 障害時のフォールバック を初期から考慮
CloudFront でリダイレクト結果を短時間キャッシュ (例: 60秒) するだけでも、原本ダウン時の被害が抑えられる

6. ライセンスと商用利用

AGPL-3.0 (Dub) は SaaS として外部提供する場合にソース公開義務が生じる
GPL-2.0 (Polr) も同様に注意が必要
社内利用にとどめる前提なら問題は少ないが、プロダクトに組み込んで顧客提供する場合は法務確認 を

7. 運用負荷

個人で運用するなら 依存サービスが少ない OSS (YOURLS / Slash / Shlink) が無難
「フルマネージドに近づけたい」なら App Runner / ECS Fargate + RDS のような構成にして、EC2 直運用を避ける
自動デプロイ・自動バックアップ・脆弱性パッチ自動適用までを最初の構築時に組み込んでおく

用途別おすすめ

flowchart TD
    Q1{用途は?}
    Q1 --> |個人・小規模| Q0{ランニングコストを<br/>ほぼゼロにしたい?}
    Q1 --> |業務・社内全体| Q3{高度な分析が必要?}
    Q1 --> |顧客向けSaaS| Q4{AGPL に同意できる?}

    Q0 --> |Yes Cloudflare依存OK| Sink[Sink<br/>Cloudflare サーバーレス]
    Q0 --> |No 自前運用したい| Q2{Docker 1 個で済ませたい?}

    Q2 --> |Yes| Slash[Slash]
    Q2 --> |No, UIも欲しい| Kutt[Kutt]

    Q3 --> |Yes 詳細計測| Shlink[Shlink]
    Q3 --> |No 軽くてOK| YOURLS[YOURLS]

    Q4 --> |Yes| Dub[Dub]
    Q4 --> |No | Dev[Dub のフォーク不可<br/>独自開発 or 他OSSベースを検討]

    classDef rec fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
    class Sink,Slash,Kutt,Shlink,YOURLS,Dub rec;

利用イメージ (典型的なリクエストフロー)

短縮 URL の典型的なリクエスト / トラッキングは下記の流れになります。 Dub クラスではここに A/B テストや UTM 付与が挟まり、Shlink クラスでは Webhook で SIEM に転送、といったバリエーションが生まれます。

sequenceDiagram
    participant User as ユーザー
    participant CDN as CloudFront
    participant App as 短縮URLアプリ
    participant DB as DB (slug → 元URL)
    participant Q as ログキュー / Redis
    participant DW as 分析基盤

    User->>CDN: GET https://go.example.co.jp/abc
    CDN->>App: cache miss
    App->>DB: SELECT * WHERE slug='abc'
    DB-->>App: 元URL, 設定
    App->>Q: クリックログ非同期送信 (IP, UA, Referer)
    App-->>CDN: 302 Location: https://...
    CDN-->>User: 302 Location: https://...
    Q-->>DW: 集約・集計
    Note over App,DB: 必要に応じて<br/>パスワード/期限/Geo分岐

まとめ

シーン	おすすめ
とにかく無料で運用したい (Cloudflare OK)	Sink
とりあえず動かしたい / レガシー PHP 環境	YOURLS
業務での真面目な計測・複数ドメイン	Shlink
モダンUI + API 連携、中規模社内	Kutt
Bitly 代替を本気で内製 (顧客提供)	Dub
学習・個人ブログ用途	Polr
Docker 1 個でチームのリンク共有	Slash

短縮 URL は「ドメインの寿命 = リンクの寿命」と「クリックログのスケール」が落とし穴です。 選定の前に "5 年後もこのドメインを維持できるか / 月間クリックがどこまで伸びるか" を見積もる ことを強くおすすめします。

最終的には、

ランニングコスト最優先 (Cloudflare 依存OK) → Sink
個人・社内ツール (自前運用) → Shlink / Kutt / Slash
顧客向け本格運用 → Dub (or 自社開発)

が最初の選択肢になるはずです。

モバイルアプリ開発ディープリンクについて

Mon, 11 May 2026 00:00:00 GMT

概要

モバイルアプリ開発における「ディープリンク」について、iOS/Android それぞれの仕組み、セキュリティ面の注意点、そして Flutter での実装方法をまとめる。

Web から特定のアプリ画面にユーザーを誘導したい、メールや SNS の URL から直接「商品詳細」「特定のチャット」に飛ばしたい、というのは現代のモバイルアプリでは当たり前の体験となっている。その裏側で動いているのがディープリンクであり、その実装の正しさはユーザー体験だけでなく、フィッシングなどのセキュリティリスクにも直結する。

💻 環境

Flutter: 3.41.4 (fvm)
OS: macOS Tahoe
IDE: Cursor
iOS: 18 以降想定
Android: 12 (API 31) 以降想定

🔗 ディープリンクとは

ディープリンクとは、Web の URL からアプリ内の特定画面に直接遷移させるリンクの総称。モバイルにおけるディープリンクは、大きく以下の 3 種類に分類できる。

種類	iOS	Android	検証	安全性
Web URL ベース	Universal Links	App Links	サーバ上の検証ファイル必須	高
カスタム URI スキーム	`myapp://...`	`myapp://...`	なし	低
Deferred Deep Link	3rd party SDK 等	3rd party SDK 等	サービス依存	サービス依存

iOS: Universal Links

https://example.com/items/123 のような 通常の HTTPS URL が、アプリがインストールされていればアプリで開かれ、未インストールであれば Safari で Web ページとして開かれる仕組み。

ドメインの所有者であることを Apple に検証させる
検証ファイル: https://example.com/.well-known/apple-app-site-association (AASA)
AASA は Content-Type が application/json、リダイレクトなし、HTTPS 必須

AASA の例:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAMID.com.example.myapp",
        "paths": [ "/items/*", "/users/*", "NOT /admin/*" ]
      }
    ]
  }
}

appID は <TeamID>.<BundleID> の形式
iOS 13 以降は details の appIDs(複数) と components を使う新フォーマットも推奨

iOS 側設定:

Xcode の Signing & Capabilities で Associated Domains を追加
applinks:example.com を登録

Android: App Links

https://example.com/items/123 のような HTTPS URL をアプリで処理する仕組み。Android 12 以降は デフォルトで未検証のリンクはアプリで開かれなくなった ので、Web 検証が必須に近い扱いとなっている。

検証ファイル: https://example.com/.well-known/assetlinks.json
アプリ署名証明書の SHA-256 fingerprint を記載

assetlinks.json の例:

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.myapp",
      "sha256_cert_fingerprints": [
        "AA:BB:CC:..."
      ]
    }
  }
]

Google Play App Signing を使っている場合は Play Console の「アプリの署名」から アプリ署名鍵の SHA-256 を取得する(アップロード鍵ではない)
検証コマンド:

adb shell pm verify-app-links --re-verify com.example.myapp
adb shell pm get-app-links com.example.myapp

BundleID/カスタム URI スキーム (`myapp://...`)

myapp://item/123 のようにアプリ独自のスキームを宣言してアプリを開く方式。歴史的に最初に使われたディープリンクで、今でも OAuth コールバックなど一部用途では現役。

セキュリティ面の懸念

誰でも同じスキームを宣言できる
- 悪意あるアプリが先にインストールされていると、本来のアプリではなくそちらが起動される可能性
- 認証コードやアクセストークンを URI で渡している場合、トークンの横取りに繋がる
ドメインのような所有権検証が存在しない
- ユーザーから見て「これは正規アプリのリンクである」ことを保証できない
OS 側の挙動が不安定
- iOS では同じスキームが複数ある場合、どのアプリが開くかは未定義

ベストプラクティス

新規実装ではまず Universal Links / App Links を第一候補にする
カスタム URI スキームを使う場合は:
- スキーム名を アプリ固有かつ衝突しにくい命名 にする (例: com.example.myapp を逆ドメインで)
- 認証コールバックには PKCE を併用し、トークン横取りを前提に防御
- URI 経由で渡される値は 必ず検証 する(SQL/HTML エスケープ、整数範囲チェックなど)
- 機微情報(JWT, refresh token など)を URI に載せない
- OAuth であれば RFC 8252 (Native Apps) で推奨される Claimed HTTPS スキーム = Universal Links/App Links を優先

Deferred Deep Link (DDL)

通常のディープリンクは「アプリがインストール済み」が前提だが、Deferred Deep Link は 未インストール時のフローも含めて目的画面まで誘導する 仕組み。

典型的なフロー:

ユーザーが広告/SNS のリンクを踏む
アプリ未インストールなので App Store / Play Store に誘導
インストール後、初回起動時に「本来開きたかった画面」へ自動遷移
ついでにインストールアトリビューション(どの広告から来たか)も取得

実装はストア側で URL パラメータを保持できないため、サードパーティ SDK の利用が一般的。

AppsFlyer
Adjust
Branch.io
Firebase Dynamic Links (※ 2025/8/25 にサービス終了済み)

Firebase Dynamic Links が終了したことで、現状新規構築する場合は AppsFlyer / Adjust / Branch などの有償 SDK か、自前実装(初回起動時にクリップボードや IP+UserAgent でマッチング)するしかない。自前実装は精度・プライバシー両面で難があるため、本格運用では SDK 採用が現実的。

🦋 Flutter での設定

Flutter ではプラットフォーム側 (iOS/Android) のネイティブ設定 + Dart 側でリンクを受け取るパッケージを組み合わせる。

代表的なパッケージ:

app_links (推奨。uni_links の後継的存在)
uni_links (メンテ停止気味)
go_router (ルーティング側で deep link を吸収できる)

Dart 側: app_links を使う

import 'package:app_links/app_links.dart';
import 'package:flutter/material.dart';

class DeepLinkHandler extends StatefulWidget {
  final Widget child;
  const DeepLinkHandler({super.key, required this.child});

  @override
  State<DeepLinkHandler> createState() => _DeepLinkHandlerState();
}

class _DeepLinkHandlerState extends State<DeepLinkHandler> {
  final _appLinks = AppLinks();

  @override
  void initState() {
    super.initState();
    _initDeepLinks();
  }

  Future<void> _initDeepLinks() async {
    // 起動時に URI で開かれた場合
    final initialUri = await _appLinks.getInitialAppLink();
    if (initialUri != null) {
      _handleUri(initialUri);
    }

    // 起動中にリンクで叩かれた場合
    _appLinks.uriLinkStream.listen(_handleUri);
  }

  void _handleUri(Uri uri) {
    // /items/123 のようなパスを解析してナビゲーション
    debugPrint('deep link: $uri');
  }

  @override
  Widget build(BuildContext context) => widget.child;
}

go_router を使う場合は GoRouter の redirect や routes で uri.path をそのままハンドリングできるので、より簡潔に書ける。

iOS 側設定

ios/Runner/Runner.entitlements に Associated Domains を追加

<key>com.apple.developer.associated-domains</key>
<array>
  <string>applinks:example.com</string>
</array>

Xcode の Signing & Capabilities でも同じ設定を行う
https://example.com/.well-known/apple-app-site-association を HTTPS かつ Content-Type application/json かつリダイレクトなし で配置
カスタムスキームも併用する場合は Info.plist に追加

<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleURLName</key>
    <string>com.example.myapp</string>
    <key>CFBundleURLSchemes</key>
    <array>
      <string>myapp</string>
    </array>
  </dict>
</array>

Android 側設定

android/app/src/main/AndroidManifest.xml の <activity> に intent-filter を追加:

<activity
    android:name=".MainActivity"
    android:exported="true"
    ... >

    <!-- App Links (HTTPS) -->
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="https"
              android:host="example.com"
              android:pathPrefix="/items" />
    </intent-filter>

    <!-- カスタムスキーム (任意) -->
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="myapp" />
    </intent-filter>
</activity>

android:autoVerify="true" を付けることで App Links として OS が assetlinks.json を自動取得・検証する
Play Store にアップロード後は アプリ署名鍵 の SHA-256 を assetlinks.json に登録する必要がある(ローカルビルド時のデバッグ署名とは別物)

動作確認コマンド

# iOS Simulator
xcrun simctl openurl booted "https://example.com/items/123"
xcrun simctl openurl booted "myapp://item/123"

# Android (実機 / エミュレータ)
adb shell am start -a android.intent.action.VIEW -d "https://example.com/items/123" com.example.myapp
adb shell am start -a android.intent.action.VIEW -d "myapp://item/123" com.example.myapp

⚠️ その他知っておきたいこと

1. アプリ未起動 / 起動済みで挙動が違う

コールドスタート: getInitialAppLink() で取得
バックグラウンドから復帰: uriLinkStream (StreamSubscription) で受け取り

両方を実装しないと「起動済みのときだけ動かない」「初回だけ動かない」というバグが起きやすい。

2. ナビゲーションスタックの設計

ディープリンクで深い階層に直接飛ばす場合、戻るボタンの遷移先がない、というのが頻出問題。

例: 商品詳細にディープリンクで飛んできたユーザーが「戻る」を押したらアプリが落ちる
対策: ホーム→商品一覧→詳細、のようにスタックを擬似的に積む or go_router の initialLocation 設計をする

3. ログインが必要な画面への遷移

ディープリンクで飛ばしたい画面が認証必須の場合、

リンク受信 → 認証状態チェック
未認証ならログイン画面へ、ログイン後に本来の URI へ復元

という「保留 URI」の管理が必要。go_router の redirect と state.matchedLocation が便利。

4. AASA / assetlinks.json のキャッシュ

iOS は AASA を Apple の CDN 経由でキャッシュ してから端末に配布する仕組みのため、自社サーバの AASA を更新しても すぐには端末に反映されない
開発中は アプリの再インストール と、設定 > 開発者 > Associated Domains Development の有効化が役立つ
Android は adb shell pm verify-app-links --re-verify で再検証可能

Apple CDN にキャッシュされている AASA を直接確認する

Apple 側がどの AASA をキャッシュしているかは、以下の URL から 直接取得できる。実機が見る AASA とほぼ同じ内容になっているはずなので、デプロイ後の反映確認はここを見るのが一番早い。

https://app-site-association.cdn-apple.com/a/v1/<domain-name>

例:

# Apple CDN にキャッシュされた example.com の AASA を確認
curl -sS https://app-site-association.cdn-apple.com/a/v1/example.com | jq .

# 自社サーバ上の AASA との差分を見たい場合
diff \
  <(curl -sS https://example.com/.well-known/apple-app-site-association | jq -S .) \
  <(curl -sS https://app-site-association.cdn-apple.com/a/v1/example.com   | jq -S .)

ポイント:

<domain-name> には スキームなし のドメインを入れる (例: example.com)
自社の AASA を更新した直後はここがまだ古いことがある。反映には数十分〜数時間かかる ケースもある
ここで取得できる JSON が「自社サーバの最新版と一致しているか」が、iOS の Universal Links が動く前提条件
404 や古い内容が返る場合、AASA の Content-Type / リダイレクト / HTTPS 証明書まわりで弾かれている可能性が高いので、自社サーバ側の応答(ヘッダ含む)を再確認する

5. 検証ツール

iOS: Apple の App Search API Validation Tool
Android: Asset Links Tool / Statement List Generator

6. プライバシーへの配慮

クリップボード経由で deferred deep link を実装すると、iOS 14 以降は クリップボードアクセス通知 がユーザーに表示されたり、App Tracking Transparency (ATT) の同意が必要になるケースがある。3rd party SDK を使う場合も、SDK が裏でやっている挙動を把握しておく。

7. ブラウザ → アプリ起動の "クッション"

SNS の WebView (Instagram, LINE 内ブラウザ等) からは Universal Links が WebView 内で開いてしまい、アプリに飛ばない ことがある。これに対しては中継ページで「アプリで開く」ボタンを置く、intent:// URI (Android Chrome) を使う、などのフォールバックを検討する。

あとがき

ディープリンクは「ただ URL を貼るだけ」に見えて、

ドメイン検証 (AASA/assetlinks.json)
署名証明書の SHA-256
アプリ側の intent-filter / Associated Domains
起動状態によるハンドリング差
ナビゲーションスタック設計

と複数レイヤが絡む地味に難しい領域。特にカスタム URI スキームは「動くから OK」で済ませがちだが、OAuth 等で使うとセキュリティリスクに直結するので、まずは Universal Links / App Links を第一に検討するのが鉄則。

Firebase Dynamic Links 終了で Deferred Deep Link は選択肢が減ったので、必要なら早めに代替 SDK の評価を始めるのがよさそう。

参考

Oracle Cloud 関連資格の整理（2026年時点・OCI 2025 ラインアップ）

Fri, 01 May 2026 00:00:00 GMT

概要

Oracle Cloud（特に OCI）はサービスと認定試験のバリエーションが多く、名称に年度が付くため「どれから取ればよいか」「自分の役割に近いのはどれか」が分かりにくいです。本記事では 2026 年時点で Oracle が提供している OCI 2025 Certification 系の主な試験を、ジャンル・ざっくり難易度・学習期間の目安とあわせて一覧にし、あわせて受験の考え方の補足をまとめます。

個々の試験の出題範囲の細部や問題傾向の深掘りは扱いません。受験を決めたら、必ず Oracle の認定ポータルと各試験ページのシラバスで確定してください。

この記事の対象と範囲

向いている読者: OCI をこれから触る／触り始めた人、社内で資格取得を検討している人、なんとなく名前だけ聞いて地図が欲しい人。
分かること: 主要な OCI 系認定のおおよその位置づけ、Fundamentals と Associate／Professional の違いのイメージ、学習の出発点の考え方。
分からないこと・しないこと: 各試験の詳細シラバス解説、合格のための対策本の比較、正確な当日の受験料（地域・キャンペーンで変わるため）。

以下の表は 受験料・期間・受験方法は一般的な目安です。特に Foundations 系の無料化やプロモーションは時期によって変わります。

Oracle Cloud 認定資格一覧（OCI 2025 ラインアップ、2026 年時点）

表は列数が多いため、狭い画面では横スクロールになります。試験の正式名称・試験番号・当日の料金・利用可能な受験モードは、Oracle Certification および Oracle University の試験一覧の各試験ページを優先してください。

出典・確認日の目安: 試験名は Oracle Certification（Oracle Cloud Infrastructure 欄）の掲載（2026 年 5 月時点）と照合しています。HPE（Hands-on Performance Exam）など試験形式の説明は Oracle University の OCI 2025 認定向け告知も参考にしました。

資格名	ジャンル	概要	難易度	受験料（目安）	学習期間（目安）	受験方法（目安）	学習の手がかり
Oracle Cloud Infrastructure 2025 Foundations Associate	OCI 基礎	OCI の基本概念（Compute, Storage, IAM）	★	無料〜（要確認）	1〜2 週間	オンラインが一般的	Oracle University の Foundations 教材
Oracle Data Platform 2025 Foundations Associate	データ基礎	データ基盤・分析の基礎	★	無料〜（要確認）	1〜2 週間	オンラインが一般的	Oracle University
Oracle Cloud Infrastructure 2025 AI Foundations Associate	AI 基礎	AI/ML・生成 AI の基本	★	無料〜（要確認）	1〜2 週間	オンラインが一般的	Oracle AI Foundations 系教材
Oracle Cloud Infrastructure 2025 Architect Associate	アーキテクト	OCI 設計の基礎	★★	約 $150	1〜2 ヶ月	オンライン／会場（地域による）	ラボ＋公式模擬・Learning Path
Oracle Redwood Application 2025 Developer Associate	アプリ開発	Redwood UI ベースの開発	★★	約 $150	1〜2 ヶ月	オンラインが一般的	Redwood 公式ドキュメント
Oracle Cloud Infrastructure 2025 Architect Professional	上級設計	高可用性・大規模設計（HPE 形式）	★★★	約 $245	2〜3 ヶ月	試験により指定あり	実務＋公式 Hands-on 系準備
Oracle AI Vector Search Professional	AI/DB	ベクトル検索（AI 検索）	★★	約 $150	約 1 ヶ月	オンラインが一般的	DB・AI 関連 Learning Path
Oracle Cloud Infrastructure 2025 Multicloud Architect Professional	マルチクラウド	他クラウド等との連携設計	★★★	約 $245	2〜3 ヶ月	試験により指定あり	マルチクラウド設計の公式教材
Oracle Cloud Infrastructure 2025 Networking Professional	ネットワーク	OCI ネットワーク設計	★★★	約 $245	2〜3 ヶ月	試験により指定あり	VCN・接続の公式コース
Oracle Cloud Infrastructure 2025 Developer Professional	開発	OCI でのアプリ開発	★★★	約 $245	2〜3 ヶ月	試験により指定あり	SDK/CLI・公式ラボ
Oracle Cloud Infrastructure 2025 DevOps Professional	DevOps	CI/CD・自動化	★★★	約 $245	2〜3 ヶ月	試験により指定あり	DevOps 系 Learning Path
Oracle Analytics Cloud 2025 Professional	分析	BI/ダッシュボード	★★★	約 $245	約 2 ヶ月	オンラインが一般的	OAC 公式教材
Oracle APEX Cloud Developer Professional	ローコード	APEX 開発	★★★	約 $245	約 2 ヶ月	オンラインが一般的	APEX ハンズオン
Oracle Cloud Infrastructure 2025 Security Professional	セキュリティ	IAM・セキュリティスタック（HPE あり）	★★★	約 $245	2〜3 ヶ月	試験により指定あり	セキュリティ公式シナリオ
Oracle Cloud Infrastructure 2025 Cloud Operations Professional	運用	監視・運用設計	★★★	約 $245	約 2 ヶ月	試験により指定あり	運用・管理系コース
Oracle Cloud Infrastructure 2025 Observability Professional	可観測性	ログ/メトリクス分析	★★★	約 $245	約 2 ヶ月	試験により指定あり	Monitoring / Logging 公式教材
Oracle Cloud Infrastructure 2025 Migration Architect Professional	移行	クラウド移行戦略	★★★	約 $245	2〜3 ヶ月	試験により指定あり	移行ツール・ベストプラクティス
Oracle Cloud Infrastructure 2025 Generative AI Professional	生成 AI	LLM 活用・設計	★★★	約 $245	約 2 ヶ月	オンラインが一般的	GenAI 公式 Learning Path
Oracle Cloud Infrastructure 2025 Data Science Professional	データサイエンス	ML/分析実装	★★★	約 $245	2〜3 ヶ月	試験により指定あり	Data Science / OAC 関連
Oracle Cloud Infrastructure 2025 Application Integration Professional	統合	API/連携（OIC 等）	★★★	約 $245	約 2 ヶ月	オンラインが一般的	Integration Cloud 公式コース
Oracle AI Cloud Database Services 2025 Professional	DB×AI	AI 対応 DB サービス	★★★	約 $245	約 2 ヶ月	試験により指定あり	Autonomous DB 関連
Oracle AI Autonomous Database 2025 Professional	自律 DB	自動運用 DB	★★★	約 $245	約 2 ヶ月	試験により指定あり	Autonomous Database 公式教材
Oracle Database@AWS Architect Professional	DB/マルチ	AWS 上の Oracle 設計	★★★	約 $245	2〜3 ヶ月	試験により指定あり	Database@AWS 公式資料
Oracle Cloud Infrastructure for Sunbird ED Specialty	教育	教育プラットフォーム（Sunbird ED）	★★	約 $150	約 1 ヶ月	オンラインが一般的	Sunbird ED 向け公式ガイド

免責（再掲）: 受験料の通貨単位、割引・無料キャンペーン、Proctor 形式、試験の廃止・追加は告知どおり変わります。申し込み前に必ず各試験の公式ページで確認してください。

補足（重要ポイント）

1. レベル感のざっくり整理

難易度の星はあくまでこの記事内での目安であり、公式の区分名とは一致しません。

★（Fundamentals 相当）
OCI やデータ、AI の「入口」。多くはアソシエイトより前段の位置づけで、無料で受けられるプロモーションが出やすい区分です（常に無料とは限らない）。
★★（Associate 相当）
特定ロールにフォーカスした実務入り口。 Architect Associate のように汎用設計から、Redwood／Vector Search のように専門トピックに絞ったものまで含みます。
★★★（Professional 相当）
設計判断・運用実務が前提になることが多いです。Oracle University の OCI 2025 認定向け告知によれば、Architect Professional や Security Professional などは Hands-on Performance Exam（HPE） のように、実機に近い課題で評価される形式もあります。

2. Foundations（無料枠）の位置づけ

OCI / Data Platform / AI の Foundations は、チーム全体の共通言語づくりや、自らの学習マップの確認に向きます。ここで終わらず、役割に応じて Associate 以降を組み合わせると「設計・実装」につながりやすいです。料金が無料ないし割引になるキャンペーンは期間限定のことがあるため、申込画面で確認してください。

3. おすすめの受験順の一例

一例にすぎません（担当がデータ基盤のみ、なら Data Platform Foundations → DB 系、などルートは人によって変わります）。

Oracle Cloud Infrastructure 2025 Foundations Associate（OCI の全体像）
興味に応じて Oracle Data Platform 2025 Foundations Associate または Oracle Cloud Infrastructure 2025 AI Foundations Associate
インフラ寄りなら Oracle Cloud Infrastructure 2025 Architect Associate
役割に合わせて Professional（例: セキュリティ担当なら Security Professional、ネットワーク専任なら Networking Professional）

Professional は未受験でも受けられるものと、実務経験が推奨されるものがあります。前提条件は試験ごとの公式説明を参照してください。

4. 受験方法・試験形式について

表の「オンライン／テストセンター」は大まかな例です。実際には オンライン監督付き（プロクタ）／会場試験／HPE（パフォーマンス系） など試験ごとに異なり、アカウントの地域や提携プロクタ会社の事情でも変わります。「すべての Professional が会場のみ」などと決めつけず、申込時の選択肢で確定してください。

5. 試験名の「2025」と更新サイクル

試験名に付く **2025 は「その年度版のカリキュラム・シラバスに対応」**という意味に近く、「2026 年に受けても意味がない」わけではありません。一方で Oracle はサービス更新に合わせて試験内容を更新するため、受験直前にシラバスと Learning Path の更新履歴を見る習慣があると安全です。古い教材だけでなく、公式の最新コースやブログ（例: Oracle University の OCI 2025 認定向け告知）をあわせて確認してください。

学習リソースについて

表の「学習の手がかり」列は、記事の保守をしやすくするために大分類だけに留めています。具体的なコース名・モジュールは変わりやすいので、各試験ページから Oracle University の対応 Learning Path / Exam Prep に進むのが確実です。

あわせて、以下の公式ドキュメント・比較資料・FAQ を参照すると、資格学習と実務の橋渡しがしやすくなります。

まとめ

本記事では、2026 年時点の Oracle 公式リストに沿った OCI 2025 ラインアップ中心の認定を、ジャンルとレベル感で俯瞰できるように整理しました。次のステップは次の 3 点です。

Oracle Certification で自分の関心に近い試験名を開き、シラバスと前提条件を読む。
受験料・スケジュール・利用可能な受験方式を 申込フロー で確定する。
公式 Learning Path で学習し、必要ならコミュニティや社内勉強会と組み合わせる。

資格は学習の道しるべであり、実務の代替ではありませんが、OCI の幅広いサービスを把握するうえで、地図としての一覧には役立つはずです。

Claude Code Pro で 24 時間自律稼働させる実行可能ベストプラクティス

Tue, 28 Apr 2026 00:00:00 GMT

この記事のゴール

「機能要件を 1 行書けば、寝ている間に PR が出来上がっている」という状態を、Pro プラン($20/月)でも実現するための最小構成のベストプラクティスをまとめます。

ここでは「今日から導入できる実装手順」だけを順序立てて並べていきます。

全体像:5 層構成で考える

無人運用は、以下の 5 層をきれいに積み上げることで安定します。

flowchart TB
    A["⑤ 永続実行層<br/>bash ループ + caffeinate + launchd"]
    B["④ 分業層<br/>Skills + Subagents + MCP"]
    C["③ 行動原則層<br/>CLAUDE.md + TODO.md"]
    D["② 権限層<br/>settings.json + Hooks"]
    E["① モデル層<br/>/model sonnet 固定"]

    A --> B --> C --> D --> E

    style E fill:#e1f5ff,stroke:#0277bd
    style D fill:#fff3e0,stroke:#ef6c00
    style C fill:#f3e5f5,stroke:#7b1fa2
    style B fill:#e8f5e9,stroke:#2e7d32
    style A fill:#fce4ec,stroke:#c2185b

層	役割	主なツール
① モデル	安定稼働	`/model sonnet` 固定
② 権限	暴走防止	`settings.json` の deny + Hooks
③ 行動原則	動作優先・止めない	`CLAUDE.md` + `TODO.md`
④ 分業	コンテキスト圧迫回避	Skills + Subagents + MCP
⑤ 永続実行	24 時間化	bash ループ + `caffeinate` + `launchd`

すべて .claude/ 配下と ~/Library/LaunchAgents/ だけで完結します。

ベストプラクティス 1:モデルは `/model sonnet` を明示する

Pro プランでは Opus はそもそも使えませんが、Default のままだと週次 Opus 上限に当たってブロックされます。
起動直後に必ず /model sonnet を実行しましょう。5 時間制限なら自動切替が効くため止まりません。
残量は npx ccusage@latest blocks --live で常時確認できます。statusLine に登録するとプロンプト下に常駐表示されます。
真犯人は Cache Read です。月初に ccusage daily --breakdown で内訳を確認する習慣をつけてください。

flowchart LR
    A["起動"] --> B{"/model 設定"}
    B -->|"Default のまま"| C["❌ 週次 Opus 上限で<br/>ブロック"]
    B -->|"/model sonnet 明示"| D["✅ 5h 上限のみ<br/>自動切替で継続"]
    style C fill:#ffebee,stroke:#c62828
    style D fill:#e8f5e9,stroke:#2e7d32

ベストプラクティス 2:権限は「三層防衛」で固める

settings.json の deny には 2025〜2026 年に既知バグが残っているため、必ず PreToolUse Hook で重ねがけしましょう。

flowchart TB
    Tool["Claude がツール実行を試みる"] --> L1{"① settings.json<br/>allow / deny"}
    L1 -->|"deny ヒット"| Block1["🛑 ブロック"]
    L1 -->|"allow / 通過"| L2{"② PreToolUse Hook<br/>block-dangerous.sh"}
    L2 -->|"exit 2"| Block2["🛑 ブロック<br/>(deny バグの保険)"]
    L2 -->|"exit 0"| L3{"③ DevContainer<br/>iptables ファイアウォール"}
    L3 -->|"許可外通信"| Block3["🛑 ブロック"]
    L3 -->|"通過"| Exec["✅ 実行"]

    style Block1 fill:#ffebee,stroke:#c62828
    style Block2 fill:#ffebee,stroke:#c62828
    style Block3 fill:#ffebee,stroke:#c62828
    style Exec fill:#e8f5e9,stroke:#2e7d32

`.claude/settings.json` 最小テンプレ

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm:*)", "Bash(pnpm:*)", "Bash(git status)", "Bash(git diff *)",
      "Bash(git add *)", "Bash(git commit -m *)", "Bash(gh *)",
      "Read", "Edit", "Write", "Glob", "Grep",
      "mcp__playwright__*", "mcp__github__*", "mcp__context7__*"
    ],
    "ask": ["Bash(git push *)"],
    "deny": [
      "Read(./.env)", "Read(./.env.*)", "Read(**/.aws/**)", "Read(**/.ssh/**)",
      "Bash(rm -rf:*)", "Bash(sudo:*)", "Bash(curl:*)", "Bash(wget:*)"
    ]
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command",
        "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/block-dangerous.sh" }]
    }],
    "PostToolUse": [{
      "matcher": "Edit|Write|MultiEdit",
      "hooks": [
        { "type": "command", "command": "npx prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\" 2>/dev/null; true" }
      ]
    }],
    "Stop": [{
      "hooks": [{ "type": "command",
        "command": "afplay /System/Library/Sounds/Glass.aiff & osascript -e 'display notification \"Task done\" with title \"Claude Code\"'" }]
    }]
  }
}

抑えておきたい原則

defaultMode: acceptEdits が無人運用の基本です。bypassPermissions は実機では使わないようにしてください。
exit 2 でブロッキングできるのが Hook の強みです(Unix 慣習と逆なので注意してください)。
git push だけは ask に置いて、PR 作成だけは人間が確認する運用が安全です。

ベストプラクティス 3:CLAUDE.md は「200 行以下」「動作ルールだけ」

LLM の指示遵守は 150〜200 個が限界と言われています。@docs/architecture.md のように外出しして、本体は 行動原則 に絞りましょう。

flowchart LR
    subgraph "✅ CLAUDE.md (200 行以内)"
        A1["動作原則<br/>3 つだけ"]
        A2["禁止事項<br/>(git add -A など)"]
        A3["@docs/... import"]
    end
    subgraph "📄 外部ファイル"
        B1["docs/architecture.md"]
        B2["docs/style-guide.md"]
        B3["TODO.md"]
    end
    A3 -.必要時にロード.-> B1
    A3 -.必要時にロード.-> B2
    A3 -.必要時にロード.-> B3
    style A1 fill:#e1f5ff
    style A2 fill:#e1f5ff
    style A3 fill:#e1f5ff

必須の 3 原則

動作優先・デザイン後回し:UI は最低限の見た目で先に動かす
解決困難は TODO.md に「⚠️ Blocked」で記録して次へ:3 回連続失敗したら諦める
完了報告の禁止条件:failing tests / compile errors が残っていたら完了と言わせない

コピペテンプレ(抜粋)

## 開発フロー
1. `git switch -c feat/<topic>` でブランチ作成
2. 実装 → `npm run typecheck` → `npm test` → Playwright 検証
3. 全グリーンで `git add -p` → Conventional Commits でコミット
4. 機能完了で `gh pr create --fill`

## 解決困難な課題
- 同じテストが 3 回連続失敗 → TODO.md に「⚠️ Blocked」追記して次へ
- 不確実な API は Context7 MCP で確認

## 禁止事項
- `git add -A` 禁止
- `.env*`、`*.pem` のコミット禁止
- `any`、`as`、`@ts-ignore` 禁止
- 既存テストの削除禁止

ベストプラクティス 4:Skills と Subagents で分業する

flowchart TB
    Main["🧠 メインエージェント<br/>(タスク分配)"]

    subgraph "Subagents (独立コンテキスト)"
        S1["feature-implementer<br/>+ worktree 隔離"]
        S2["test-writer"]
        S3["code-reviewer"]
        S4["debugger"]
    end

    subgraph "Skills (共有スキル)"
        K1["commit"]
        K2["run-tests-and-fix"]
        K3["verify-in-browser<br/>(Playwright MCP)"]
    end

    Main --> S1 & S2 & S3 & S4
    S1 -.使う.-> K1 & K2 & K3
    S2 -.使う.-> K2
    S1 -- 最終要約のみ返却 --> Main

    style Main fill:#fff3e0,stroke:#ef6c00
    style S1 fill:#e8f5e9
    style S2 fill:#e8f5e9
    style S3 fill:#e8f5e9
    style S4 fill:#e8f5e9

Skills は 3 つだけ用意

.claude/skills/<name>/SKILL.md の YAML frontmatter は 「◯◯と言ったら必ず使え」と押し気味に書くのが Anthropic 推奨です。

Skill	役割
`commit`	Conventional Commits を自動生成
`run-tests-and-fix`	テスト実行 + 失敗時の修正
`verify-in-browser`	Playwright MCP で UI を実機検証

Subagents は 4 つに絞る

.claude/agents/<name>.md に独立コンテキスト・独立権限のエージェントを定義します。最終要約だけ親に返るためメインを汚染しません。

feature-implementer(実装、isolation: worktree)
test-writer(テスト作成)
code-reviewer(レビュー)
debugger(デバッグ)

5 個以上に増やすと選択ミスが増えます。3〜7 個が黄金比です。

ベストプラクティス 5:MCP は `.mcp.json` ルート直下に置く

.claude/.mcp.json だと一部読み込まれない既知不具合があります。必ずプロジェクトルートに置いてください。

無人運用に効く 7 点セット:

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp",
      "headers": { "Authorization": "Bearer ${GITHUB_PAT}" }
    },
    "playwright": { "command": "npx", "args": ["@playwright/mcp@latest", "--browser=chromium"] },
    "chrome-devtools": { "command": "npx", "args": ["chrome-devtools-mcp@latest"] },
    "context7": { "command": "npx", "args": ["-y", "@upstash/context7-mcp@latest"] },
    "sequential-thinking": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"] },
    "memory": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-memory"] }
  }
}

⚠️ @modelcontextprotocol/server-github の npm 版は 2025/4 に deprecated になりました。GitHub 公式の HTTP 版を使ってください。

ベストプラクティス 6:TODO.md 駆動の無限ループで 24 時間化

「LLM の記憶を信じない、ファイルに状態を書き続ける」という Ralph Wiggum ループ思想が核になります。各イテレーションは フレッシュコンテキスト で開始し、知識は Git と TODO.md で永続化させます。

flowchart TB
    Start(["🌙 launchd 22:00 起動"]) --> Loop{"TODO.md に<br/>[ ] タスクあり?"}
    Loop -->|"なし"| Done(["🎉 全完了通知<br/>(osascript)"])
    Loop -->|"あり"| Fresh["🆕 フレッシュ Claude 起動<br/>(timeout 30m)"]
    Fresh --> Impl["実装 → テスト → コミット<br/>→ TODO.md 更新"]
    Impl --> Check{"結果"}
    Check -->|"ITERATION_COMPLETE"| Loop
    Check -->|"usage limit"| Wait["⏰ リセット時刻まで<br/>caffeinate -i sleep"]
    Wait --> Loop
    Check -->|"3 回連続失敗"| Block["⚠️ TODO.md に Blocked 追記"]
    Block --> Loop

    style Start fill:#e1f5ff
    style Done fill:#e8f5e9
    style Wait fill:#fff3e0
    style Block fill:#ffebee

`claude-loop.sh`(macOS / Linux 両対応・最小版)

#!/usr/bin/env bash
set -uo pipefail
TODO="$(pwd)/TODO.md"; LOG_DIR="$(pwd)/.claude-loop"; mkdir -p "$LOG_DIR"
ITER=0; MAX_ITER="${MAX_ITER:-50}"

while (( ITER < MAX_ITER )); do
  ITER=$((ITER + 1)); LOG="$LOG_DIR/iter_${ITER}.log"

  # 未完了タスクが無ければ終了
  grep -qE '^\s*-\s*\[\s*\]' "$TODO" 2>/dev/null || {
    osascript -e 'display notification "ALL DONE 🎉" with title "Claude Loop"'
    break
  }

  timeout 30m claude -p "TODO.md の最上位 [ ] タスクを実装→テスト→コミット→[x]更新。
完了で 'ITERATION_COMPLETE' を最終行に出力。3 回連続失敗で ⚠️Blocked 追記して次へ。" \
    --permission-mode acceptEdits --output-format text 2>&1 | tee "$LOG"

  # リミット検知 → リセット時刻まで待機
  if grep -qiE "usage limit reached" "$LOG"; then
    reset=$(grep -oE 'reset at [0-9]+(am|pm)' "$LOG" | tail -1 | awk '{print $3}')
    sleep_for=$(( $(date -j -f '%I%p' "$reset" +%s 2>/dev/null || echo 1800) - $(date +%s) + 60 ))
    (( sleep_for < 60 )) && sleep_for=1800
    caffeinate -i sleep "$sleep_for"
  fi
done

tmux で起動する場合

tmux new-session -d -s claude-loop \
  "caffeinate -i ./claude-loop.sh > .claude-loop/run.log 2>&1"
tmux attach -t claude-loop   # 監視
# Ctrl+b d でデタッチ

ベストプラクティス 7:Mac の launchd で完全無人化(cron は使わない)

cron は寝てる Mac では発火しません。launchd 一択です。

flowchart LR
    A["💤 Mac スリープ中"] --> B{{"launchd<br/>22:00 起床"}}
    B --> C["caffeinate -i<br/>(スリープ抑止)"]
    C --> D["claude-loop.sh"]
    D --> E["朝起きたら<br/>PR が積み上がっている"]

    style A fill:#eceff1
    style B fill:#e1f5ff,stroke:#0277bd
    style C fill:#fff3e0
    style E fill:#e8f5e9,stroke:#2e7d32

`~/Library/LaunchAgents/com.user.claude-loop.plist`

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0"><dict>
  <key>Label</key><string>com.user.claude-loop</string>
  <key>ProgramArguments</key><array>
    <string>/usr/bin/caffeinate</string><string>-i</string>
    <string>/bin/bash</string><string>-lc</string>
    <string>cd /Users/me/projects/myapp && /usr/local/bin/claude-loop.sh</string>
  </array>
  <key>StartCalendarInterval</key>
    <dict><key>Hour</key><integer>22</integer><key>Minute</key><integer>0</integer></dict>
  <key>EnvironmentVariables</key>
    <dict><key>PATH</key><string>/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin</string></dict>
  <key>StandardOutPath</key><string>/Users/me/.claude-loop/stdout.log</string>
  <key>StandardErrorPath</key><string>/Users/me/.claude-loop/stderr.log</string>
</dict></plist>

4 つの「壁」を事前に潰しましょう(GMO ペパボの知見)

cron / launchd で自走させるとき、毎回ハマる 4 つのポイントがあります。

flowchart LR
    Start["🚀 launchd 起動"] --> W1{"壁 ①<br/>Bypass<br/>permissions"}
    W1 -->|"OK"| W2{"壁 ②<br/>Trust this<br/>folder"}
    W2 -->|"OK"| W3{"壁 ③<br/>MCP<br/>allow/deny"}
    W3 -->|"OK"| W4{"壁 ④<br/>ファイル<br/>除外リスト"}
    W4 -->|"OK"| Run["✅ 自走開始"]

    W1 -.解決策.-> S1["acceptEdits 設定"]
    W2 -.解決策.-> S2["事前に対話モードで<br/>一度開く"]
    W3 -.解決策.-> S3["事前 allowlist"]
    W4 -.解決策.-> S4[".env 等の deny を<br/>settings.json に"]

    style Run fill:#e8f5e9,stroke:#2e7d32

壁	内容	解決策
① Bypass permissions	権限プロンプトで止まる	`--permission-mode acceptEdits`
② Trust this folder	初回起動で信頼確認	対話モードで一度開く、もしくは `~/.claude.json` の `hasTrustDialogAccepted: true` を直書き
③ MCP の allow/deny	MCP ツールで止まる	事前に対話モードで一度許可
④ ファイル除外	`.env` などへのアクセス	settings.json の deny に明記

推奨ディレクトリ構成

~/projects/myapp/
├── CLAUDE.md                  # 200 行以下、行動原則だけ
├── TODO.md                    # [ ] / [x] / ⚠️ Blocked
├── .mcp.json                  # ルート直下が必須
├── .claude/
│   ├── settings.json          # 権限 + Hooks
│   ├── skills/{commit,run-tests-and-fix,verify-in-browser}/SKILL.md
│   ├── agents/{feature-implementer,test-writer,code-reviewer,debugger}.md
│   └── hooks/block-dangerous.sh
└── specs/<feature>/{requirements,design,tasks}.md   # SDD

全体の流れ:要件 1 行から PR まで

sequenceDiagram
    actor User as 👤 あなた
    participant TODO as 📝 TODO.md
    participant Loop as 🔁 claude-loop.sh
    participant Claude as 🧠 Claude (Sonnet)
    participant Sub as 👥 Subagents
    participant GH as 🐙 GitHub

    User->>TODO: 機能要件を 1 行追記
    User->>Loop: launchd 22:00 起動
    loop 各タスク (フレッシュコンテキスト)
        Loop->>Claude: TODO の [ ] タスクを渡す
        Claude->>Sub: feature-implementer に委譲
        Sub->>Sub: 実装 + test-writer + reviewer
        Sub-->>Claude: 完了要約のみ返却
        Claude->>GH: gh pr create --fill
        Claude->>TODO: [x] に更新
    end
    Loop->>User: 🎉 朝起きたら PR が並んでいる

チェックリスト:今日やること

[ ] /model sonnet を明示する習慣をつける
[ ] ccusage statusline を ~/.claude/settings.json に登録する
[ ] .claude/settings.json の deny に .env / rm -rf / sudo を追加する
[ ] .claude/hooks/block-dangerous.sh で deny を二重化する
[ ] CLAUDE.md を 200 行以下に削り、3 原則を明記する
[ ] .mcp.json をルート直下に置き、Playwright + GitHub + Context7 を登録する
[ ] Skills を commit / run-tests-and-fix / verify-in-browser の 3 つだけ作る
[ ] Subagents を 4 つに絞る(isolation: worktree)
[ ] claude-loop.sh + caffeinate で tmux 起動を試す
[ ] 安定したら launchd plist で 22:00 起動に登録する

まとめ

Pro プランで 24 時間自律稼働させる肝は、派手な機能ではなく 地味な 3 つの徹底 にあります。

権限は三層で固める(settings の allow/deny + PreToolUse Hook + DevContainer)
行動原則は短く書く(CLAUDE.md は 200 行、解決困難は次へ)
状態はファイルに書く(TODO.md + Git で記憶を永続化、コンテキストはフレッシュ)

これに caffeinate + launchd という 2 つの Mac 固有の小技を足せば、寝ている間に PR が積み上がる環境が完成します。残るボトルネックは Claude ではなく 人間が書く要件の質 だけで、それを requirements.md に EARS 記法で書ければ、あとは任せられます。

Claude Code を Pro プランで 24 時間自律稼働させる完全ガイド

Tue, 28 Apr 2026 00:00:00 GMT

概要

機能要件さえ書けば無人で開発が進む究極のセットアップは、5 つの層を組み合わせれば 2026 年 5 月時点で実現可能 です。--permission-mode acceptEdits、.claude/settings.json の hooks、Subagents と Skills、.mcp.json での Playwright/GitHub MCP、そして Mac の launchd + caffeinate + tmux でラップする Ralph Loop──これだけで「PROMPT.md / fix_plan.md 駆動の自律実装ループ」が成立します。

Anthropic は 2025 年 7 月発表 / 8 月施行でユーザーの 5% 未満 しか引っかからない週次リミットを導入し、2025 年 9 月の Claude Code 2.0 で Checkpointing と VS Code 拡張(Plan Mode 自体は Shift+Tab で 2.0 以前から存在)、2025 年 10 月で Skills、2026 年 2 月で Agent Teams (実験的)、2026 年 3 月で --permission-mode auto、2026 年 4 月で Routines(クラウド定期実行) と Opus 4.7 を順次解放しました。Pro プランは Sonnet 4.6 中心(Opus 4.7 は Max プラン以上が前提)で「機能要件 1 行 → spec 生成 → 自律実装 → 自動検証 → PR 作成」までほぼ無人で回すことができ、リミット到達時は Claude が返すリセット時刻を bash でパースして caffeinate -i sleep で待機させればよいのです。

本稿では公式ドキュメント・GitHub の主要 OSS・Zenn / Qiita の実装事例を統合し、コピペで動くテンプレート一式を提示します。

全体アーキテクチャ

flowchart TB
    User["👤 機能要件 1 行"] --> Loop["🔁 ralph-loop.sh<br/>(.ralph/PROMPT.md 駆動)"]

    subgraph "5 つの層"
        L5["⑤ launchd + caffeinate + tmux<br/>= 24 時間自走"]
        L4["④ Skills + Subagents + MCP<br/>= 分業と外部連携"]
        L3["③ CLAUDE.md + .ralph/fix_plan.md<br/>= 行動原則と作業キュー"]
        L2["② settings.json + Hooks<br/>(Stop で Ralph 継続強制)"]
        L1["① /model sonnet 固定<br/>= 安定稼働"]
    end

    Loop --> L5 --> L4 --> L3 --> L2 --> L1
    L1 --> PR["🐙 GitHub PR<br/>朝起きたら完成"]

    style User fill:#fff3e0
    style PR fill:#e8f5e9,stroke:#2e7d32
    style Loop fill:#e1f5ff,stroke:#0277bd

Pro プランの二層リミットと「Sonnet 固定」の鉄則

Anthropic のサブスクリプションは 2025 年 8 月 28 日以降、5 時間セッション(rolling)と週次リミット の二層構造に変わりました。プラン別の上限は次の通りです。

プラン	月額	5h あたり	週次 Sonnet	週次 Opus
Pro	$20	約 45 メッセージ	40〜80 時間	❌ ほぼ不可
Max 5x	$100	-	140〜280 時間	15〜35 時間
Max 20x	$200	-	240〜480 時間	24〜40 時間

Pro プランは事実上 Sonnet 専用です(2026 年 5 月時点)。Opus 4.7 を本格利用したいなら Max 5x 以上に上げる必要があります。リミット超過時は extra usage を有効にすれば、標準 API レートで継続課金できます。あるいは後述の claude-code-router で OpenRouter 等の API へ動的にスワップする運用もあります。

flowchart LR
    A["起動"] --> B{"/model 設定"}
    B -->|"Default のまま"| C["❌ 週次 Opus 上限で<br/>ブロック"]
    B -->|"/model sonnet 明示"| D["✅ 5h 上限のみ<br/>自動切替で継続"]
    style C fill:#ffebee,stroke:#c62828
    style D fill:#e8f5e9,stroke:#2e7d32

無人運用で最も詰まるのは(Max プラン以上の場合)「/model を Default (recommended) にしていると、週次の Opus 上限到達時に Sonnet へ自動フォールバックせずブロックされる」点です。/model sonnet を明示 すれば 5 時間制限は自動切替が効きます(Qiita @takezone)。Pro プランの場合は最初から Sonnet 固定なのでこの問題は生じませんが、習慣として /model sonnet を明示しておくと安全です。リミット到達時に Claude Code が出すメッセージは Claude usage limit reached. Your limit will reset at 3pm (America/New_York). または API 直エラーでは Claude AI usage limit reached|1749924000(Unix epoch)で、これを bash で正規表現パースします。

残量監視は ccusage(日本人開発者 ryoppippi 作、npx ccusage@latest blocks --live)が標準で、~/.claude/projects/*.jsonl を解析して 5 時間ブロックとモデル別コストを表示します。ccusage statusline を ~/.claude/settings.json の statusLine に登録すれば、プロンプト下部に常時残量が出ます。Python 製の claude-monitor(uv tool install claude-monitor、--plan pro --timezone Asia/Tokyo)は機械学習でリセット時刻を予測する TUI を提供し、tmux-claude-live で tmux ステータスバーへも出せます。日本語 note 記事(@euro0202)の指摘で重要なのは「消費の大半は output ではなく Cache Read」という点で、ccusage daily --breakdown で必ず内訳を確認すべきです。

自動化フラグの全貌と auto モードという新解

Claude Code v2.1+ には自動化用フラグが 50 種類以上ありますが、無人運用で覚えるべきものは限られています。

フラグ	役割
`--print` (`-p`)	非対話実行
`--continue` (`-c`)	カレントディレクトリの直近セッション再開
`--resume` (`-r`)	ID 指定再開
`--max-turns`	ターン上限
`--output-format stream-json`	NDJSON ログ取得
`--input-format stream-json`	SDK 連携用 NDJSON 入力
`--worktree` (`-w`)	`.claude/worktrees/<name>/` への隔離 worktree 作成 (v2.1.49+)

権限制御の中心は --permission-mode で、値は default/acceptEdits/plan/auto/bypassPermissions の 5 つです。Shift+Tab で対話モード中の YOLO / auto-accept 切替に使います。

stateDiagram-v2
    [*] --> default
    default --> acceptEdits: Shift+Tab
    acceptEdits --> plan: Shift+Tab
    plan --> bypassPermissions: Shift+Tab
    bypassPermissions --> default: Shift+Tab
    plan --> auto: Shift+Tab
    auto --> default: Shift+Tab

    note right of acceptEdits
        🟢 無人運用の基本
    end note
    note right of bypassPermissions
        ⚠️ 危険:実機では避ける
    end note
    note right of auto
        🆕 2026/3 導入
        サーバ側で危険検知
    end note

--dangerously-skip-permissions は bypassPermissions の別名 で、全パーミッションプロンプトをスキップしますが .git/.claude/.vscode/.idea/.husky への書き込みだけは依然確認します(リポジトリ / フック破壊防止)。Anthropic 公式は「コンテナで使え、実機では使うな」と明記しており、2025 年 10 月 21 日に報告された Wolak 事件 (Issue #10077, Claude Code v2.0.22, WSL2 / Ubuntu) では rm -rf tests/ patches/ plan/ ~/ がチルダ展開後に実行され、ユーザのホームディレクトリを丸ごと削除しました(validation はチルダ展開「前」に行われていた)。eesel AI 調査では同フラグ利用者の 32% が意図しないファイル変更 を経験、9% がデータ損失 を経験しています。

2026 年 3 月 24 日導入の --permission-mode auto がこの代替として推奨されています(Sonnet 4.6 / Opus 4.6 以上必須、当初は Team プランのリサーチプレビュー)。サーバ側の transcript 分類器(fast filter → chain-of-thought)が危険操作を検知し、3 連続 / 累計 20 の拒否で人間にエスカレーションする仕組みです。auto 進入時は blanket shell access、python/node/ruby の wildcard、パッケージマネージャ run の always-allow ルールはドロップされる安全設計になっています。

settings.json は「許可リスト + deny + hooks」の三層で固める

.claude/settings.json(プロジェクト)と ~/.claude/settings.json(ユーザー)と managed-settings.json(IT 管理)の 3 階層があり、配列フィールドは連結マージ、評価順は deny → ask → allow → defaultMode で最初にマッチしたルールが勝ちます。

flowchart TB
    Tool["Claude がツール実行を試みる"] --> L1{"① settings.json<br/>deny → ask → allow"}
    L1 -->|"deny ヒット"| Block1["🛑 ブロック"]
    L1 -->|"通過"| L2{"② PreToolUse Hook<br/>block-dangerous.sh"}
    L2 -->|"exit 2"| Block2["🛑 ブロック<br/>(deny バグの保険)"]
    L2 -->|"exit 0"| L3{"③ DevContainer<br/>iptables ファイアウォール"}
    L3 -->|"許可外通信"| Block3["🛑 ブロック"]
    L3 -->|"通過"| Exec["✅ 実行"]

    style Block1 fill:#ffebee,stroke:#c62828
    style Block2 fill:#ffebee,stroke:#c62828
    style Block3 fill:#ffebee,stroke:#c62828
    style Exec fill:#e8f5e9,stroke:#2e7d32

Bash ルールは glob、Read / Edit は gitignore 互換、WebFetch は domain: プレフィックスで指定します。ただし 2025〜2026 年の Issue #6699 / #18846 / #15921 / #13340 で allow/deny が一部効かない既知バグ が複数 open のため、重要な制約は必ず PreToolUse hook で重ねがけする のが業界 consensus です。

無人開発向けの推奨 settings.json テンプレートは以下の通りです。defaultMode を acceptEdits にし、開発で頻発する npm/pnpm/git/node/python/pytest/make 系を allow、git push だけ ask、機密ファイル(.env、.aws、.ssh、credentials*)と破壊コマンド(rm -rf:*、sudo:*、curl:*、wget:*)を deny します。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "env": {
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
  },
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm:*)", "Bash(pnpm:*)", "Bash(yarn:*)",
      "Bash(git status)", "Bash(git diff *)", "Bash(git log *)",
      "Bash(git add *)", "Bash(git commit -m *)", "Bash(git checkout -b *)",
      "Bash(node *)", "Bash(python *)", "Bash(pytest *)", "Bash(make *)",
      "Bash(gh *)",
      "Read", "Edit", "Write", "Glob", "Grep",
      "WebFetch(domain:docs.anthropic.com)",
      "WebFetch(domain:github.com)",
      "mcp__playwright__*", "mcp__github__*", "mcp__context7__*"
    ],
    "ask": ["Bash(git push *)"],
    "deny": [
      "Read(./.env)", "Read(./.env.*)", "Read(**/.aws/**)",
      "Read(**/.ssh/**)", "Read(**/credentials*)",
      "Bash(rm -rf:*)", "Bash(sudo:*)", "Bash(curl:*)", "Bash(wget:*)"
    ]
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command",
        "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/block-dangerous.sh" }]
    }],
    "PostToolUse": [{
      "matcher": "Edit|Write|MultiEdit",
      "hooks": [
        { "type": "command", "command": "npx prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\" 2>/dev/null; true" },
        { "type": "command", "command": "npx eslint --fix \"$CLAUDE_TOOL_INPUT_FILE_PATH\" 2>/dev/null; true" }
      ]
    }],
    "Stop": [{
      "hooks": [{ "type": "command",
        "command": "afplay /System/Library/Sounds/Glass.aiff & osascript -e 'display notification \"Task done\" with title \"Claude Code\"'" }]
    }],
    "Notification": [{
      "matcher": "permission_prompt",
      "hooks": [{ "type": "command",
        "command": "afplay /System/Library/Sounds/Basso.aiff & osascript -e 'display notification \"Approval needed\" with title \"Claude Code\"'" }]
    }]
  }
}

Hook は 20 種類前後のライフサイクルイベント(2026 年 5 月時点で公式 21 イベント)を持ち、PreToolUse(ツール呼出前、deny 可)、PostToolUse / PostToolUseFailure(編集後フォーマット)、Stop / StopFailure(応答終了、exit 2 で継続強制可、Ralph Loop の心臓部)、SessionStart / SessionEnd、UserPromptSubmit、SubagentStart / SubagentStop、PreCompact、Notification、PermissionRequest などが主役になります。

sequenceDiagram
    participant U as User
    participant C as Claude
    participant H as Hooks
    participant T as Tool

    U->>C: プロンプト送信
    C->>H: UserPromptSubmit
    C->>C: 推論
    C->>H: PreToolUse (deny 判定可)
    alt deny ヒット
        H-->>C: exit 2 (ブロック)
    else 通過
        C->>T: ツール実行
        T-->>C: 結果
        C->>H: PostToolUse (フォーマット等)
    end
    C-->>U: 応答返却
    C->>H: Stop (テスト失敗なら exit 2 で継続強制)

exit 0 で成功・exit 2 でブロッキング / 継続強制 というセマンティクスが Unix 慣習と異なる点に注意してください。PreToolUse で permissionDecision: "deny" を返せば bypassPermissions モードでも止まるため、settings.json の deny バグを補完できます。Stop hook で「テストが通るまで継続」を強制する例は次の通りです。

#!/usr/bin/env bash
INPUT=$(cat); ACTIVE=$(echo "$INPUT" | jq -r '.stop_hook_active')
[ "$ACTIVE" = "true" ] && exit 0   # 無限ループ防止
if ! npm test > /tmp/test.log 2>&1; then
  echo "Tests failing. Fix and retry. See /tmp/test.log" >&2
  exit 2   # Claude に継続させる
fi

CLAUDE.md・Skills・Subagents で「動作優先・解決困難は後回し」を行動原則化

CLAUDE.md は セッション開始時に自動でコンテキストへロードされる Markdown で、プロジェクトの「憲法」として働きます。

flowchart TB
    Start["セッション開始"] --> E["Enterprise managed"]
    E --> P["プロジェクトルート<br/>CLAUDE.md"]
    P --> S["サブディレクトリ<br/>(lazy)"]
    S --> H["~/.claude/CLAUDE.md"]
    H --> L["CLAUDE.local.md"]
    L --> Loaded["📚 重ねがけで全部ロード"]

    style Loaded fill:#e8f5e9,stroke:#2e7d32

優先順位は Enterprise → プロジェクトルート → サブディレクトリ(lazy)→ ~/.claude/CLAUDE.md → CLAUDE.local.md の順で重ねがけされます。HumanLayer 調査によれば LLM の指示遵守は 150〜200 個程度が限界 のため、本体は 200 行以下 にし、@docs/architecture.md のような import 構文で組織化するのがベストプラクティスです。コードスタイルは linter / formatter / hook に任せ、CLAUDE.md には「動作ルール」だけ書きましょう。

ユーザーの要件「動作優先・デザイン後回し」「解決困難は後回し」「自動コミット」を行動原則化した CLAUDE.md テンプレートは以下の通りです。

# プロジェクト: <NAME>

## アーキテクチャ概要
- 言語:TypeScript(厳格)/ Next.js 15 / Vitest + Playwright
- 詳細は @docs/architecture.md

## 開発フロー(必ず守る)
1. 変更前に `git switch -c feat/<topic>` でブランチ作成
2. **動作優先・デザイン後回し**:UI は最低限の見た目で先に動かす。
   美化や色調整は最後にまとめて行う
3. 機能を実装したら必ず:
   a. `npm run typecheck` を通す
   b. `npm test` を通す
   c. UI 機能なら verify-in-browser スキルで Playwright 検証
4. 全グリーンになったら **自動コミット**:
   `git add -p` で関連変更のみステージ → Conventional Commits でコミット
5. 1 機能完了ごとに push し、`gh pr create --fill` で PR 作成

## 解決困難な課題のハンドリング
- 同じテストが **3 回連続で失敗** したら、修正を諦めて以下を行う:
  1. `.ralph/fix_plan.md` に「⚠️ Blocked: <問題> / <ファイル:行> / <最後のエラー>」を追記
  2. 該当箇所に `// TODO(claude): blocked - see .ralph/fix_plan.md` コメントを残す
  3. **次のタスクに進む**(Ralph ループを止めない)
- 不確実な API 仕様は Context7 MCP で確認してから実装

## Retry Policy
- 問題発生時は自動で**最大 5 回**まで再試行
- 完了報告時に「failing tests / compile errors / unresolved errors」が
  残っていた場合は完了報告禁止

## 禁止事項
- `git add -A` 禁止(必ず `git add <file>` か `git add -p`)
- `.env*`、`secrets/`、`*.pem` のコミット禁止
- `any`、`as`、`@ts-ignore` の使用禁止
- 既存テストの削除禁止(壊れたら原因を直す)

## 関連ドキュメント
- @.ralph/PROMPT.md(同一プロンプト)
- @.ralph/fix_plan.md(現在の作業キュー)
- @docs/architecture.md

Skills の progressive disclosure

Skills(2025 年 10 月発表)は .claude/skills/<name>/SKILL.md に YAML frontmatter で定義する「専門知識パック」で、progressive disclosure によりコンテキストを圧迫しません。

flowchart LR
    A["セッション開始"] --> B["📋 メタデータのみロード<br/>(name + description)"]
    B --> C{"トリガー?"}
    C -->|"description にマッチ"| D["📖 SKILL.md 本体ロード"]
    D --> E{"参照必要?"}
    E -->|"yes"| F["📚 references/ を Read"]
    E -->|"yes"| G["🔧 scripts/ を Bash 実行"]
    C -->|"非マッチ"| H["💤 ロードしない<br/>= コンテキスト節約"]

    style B fill:#e1f5ff
    style H fill:#eceff1
    style D fill:#e8f5e9

description は「ユーザーが◯◯と言ったら必ずこのスキルを使え」と やや押し気味 に書くのが Anthropic 推奨です。コミット用、テスト実行用、ブラウザ検証用の 3 つを最低限揃えると無人ループが回ります。

---
name: verify-in-browser
description: >
  実装した UI 機能を Playwright MCP で実際にブラウザで開き、
  期待通りに表示・動作するか確認する。フロントエンド機能の
  実装完了直後、PR 作成前に必ず使用。
allowed-tools: mcp__playwright__*, Read, Bash
---
## 手順
1. `npm run dev` をバックグラウンド起動(ポート確認)
2. `browser_navigate` で localhost:<port> を開く
3. `browser_snapshot` でアクセシビリティツリー取得
4. 実装した UI フロー(クリック・入力・遷移)を実行
5. 期待 DOM/テキストの存在を検証
6. 失敗したら debugger サブエージェントへ委譲
7. 成功なら "✅ Verified in browser: <flow>" を返す

Subagents で並列分業

Subagents(.claude/agents/<name>.md)は独立コンテキスト・独立ツール権限・独立モデルを持つ専門エージェントで、親には 最終要約だけ 返るためメインのコンテキストが汚染されません。

flowchart TB
    Main["🧠 メインエージェント<br/>(タスク分配)"]

    subgraph "Subagents (独立コンテキスト)"
        S1["feature-implementer<br/>+ worktree 隔離"]
        S2["test-writer"]
        S3["code-reviewer"]
        S4["debugger"]
    end

    Main -->|並列起動| S1
    Main -->|並列起動| S2
    Main -->|並列起動| S3
    Main -->|並列起動| S4
    S1 -->|最終要約のみ| Main
    S2 -->|最終要約のみ| Main
    S3 -->|最終要約のみ| Main
    S4 -->|最終要約のみ| Main

    style Main fill:#fff3e0,stroke:#ef6c00
    style S1 fill:#e8f5e9
    style S2 fill:#e8f5e9
    style S3 fill:#e8f5e9
    style S4 fill:#e8f5e9

クラスメソッドの検証では「アーキテクチャ調査 / テストカバレッジ調査 / 依存関係調査」を 3 並列起動して 53 回のツール呼び出しを 2 分で完了しています。3〜7 個に絞る のが推奨で、feature-implementer(実装)/ test-writer(テスト)/ code-reviewer(レビュー)/ debugger(デバッグ)の 4 構成が標準です。isolation: worktree を frontmatter に書けば各サブエージェントが独立 worktree で動き、並列編集時のコンフリクトを物理的に防げます。

MCP サーバー 7 点セットで「ブラウザで動かして検証」まで自動化

MCP(Model Context Protocol)は 2024 年 11 月発表のオープンプロトコルで、claude mcp add または .mcp.json で接続します。ルート直下の .mcp.json に置く こと(.claude/.mcp.json だと一部サーバが読み込まれない既知不具合あり、Issue #5037)。

flowchart LR
    Claude["🧠 Claude Code"]

    subgraph "MCP 7 点セット"
        M1["🐙 GitHub MCP<br/>issue/PR/コミット"]
        M2["📁 Filesystem MCP"]
        M3["🌐 Playwright MCP<br/>ブラウザ操作"]
        M4["🔍 Chrome DevTools MCP<br/>ネットワーク解析"]
        M5["📚 Context7 MCP<br/>最新ドキュメント"]
        M6["🧠 Sequential Thinking"]
        M7["💾 Memory MCP<br/>SQLite KG"]
    end

    Claude --> M1 & M2 & M3 & M4 & M5 & M6 & M7
    style Claude fill:#fff3e0,stroke:#ef6c00

無人開発に効く 7 点セットは GitHub MCP(公式の api.githubcopilot.com/mcp、issue/PR/コミット)、Filesystem MCP、Playwright MCP(Microsoft 公式、browser_navigate/browser_snapshot/browser_run_code)、Chrome DevTools MCP(Google 公式、ネットワーク解析)、Context7 MCP(Upstash、ライブラリ最新ドキュメント取得)、Sequential Thinking MCP、Memory MCP(SQLite Knowledge Graph)です。

⚠️ 注意:@modelcontextprotocol/server-github npm 版は 2025 年中に deprecated となっています(現行は github/github-mcp-server リポジトリの Docker / HTTP 版に統合)。本記事の .mcp.json は HTTP 版(api.githubcopilot.com/mcp)を採用しています。

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp",
      "headers": { "Authorization": "Bearer ${GITHUB_PAT}" }
    },
    "playwright": { "command": "npx", "args": ["@playwright/mcp@latest", "--browser=chromium"] },
    "chrome-devtools": { "command": "npx", "args": ["chrome-devtools-mcp@latest"] },
    "context7": { "command": "npx", "args": ["-y", "@upstash/context7-mcp@latest"] },
    "sequential-thinking": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"] },
    "memory": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-memory", "--memory-path", "${HOME}/.claude-memory"] }
  }
}

ブラウザ動作確認のワークフローは次の連鎖になります。

flowchart LR
    A["1. 機能実装"] --> B["2. browser_navigate"]
    B --> C["3. browser_snapshot<br/>(a11y tree)"]
    C --> D["4. DOM/テキスト検証"]
    D -->|"OK"| E["7. PR 作成<br/>(GitHub MCP)"]
    D -->|"NG"| F["5. Chrome DevTools MCP<br/>で深掘り"]
    F --> G["6. 修正"] --> A

    style E fill:#e8f5e9,stroke:#2e7d32
    style F fill:#fff3e0

Microsoft の playwright-cli install --skills で Skill が自動配置され、--codegen オプションで TypeScript テストの自動生成までしてくれます。

Ralph Loop:2026 年に標準化された「同一プロンプト無限投入」パターン

リミット到達の検知から再開までの実装は OSS が複数公開されています。terryso/claude-auto-resume(bash で Claude usage limit reached を grep → date -d で時刻パース → sleep → --continue)と cheapestinference/claude-auto-retry(npm、tmux capture-pane でポーリング、DST 対応)が代表格です。Anthropic 公式 issue(#36320, #35744, #18980)でも要望が多数集まっていますが、2026 年 5 月時点で公式機能としては未実装のため、自前で組みます。

「機能要件さえ書けば無人で動く」コア部分は、Geoffrey Huntley が提唱した Ralph Wiggum ループ(原典 ghuntley.com/ralph / everything is a ralph loop / note @jujunjun110 日本語解説)で実装します。思想は 「同じプロンプトを while ループで AI に投げ続け、状態は AI の記憶ではなくファイル(PROMPT.md / fix_plan.md / AGENTS.md)+ git に保持する」。各イテレーションは フレッシュコンテキスト で開始するので context rot(コンテキスト劣化)が起きず、根気だけで機能が完成します。

2026 年 5 月時点のエコシステム

Ralph パターンは 2025 年後半から 2026 年にかけて急速に標準化されました。主要な実装の現況は次の通りです。

実装	形態	特徴
Anthropic 公式 `ralph-loop` plugin	`claude.com/plugins/ralph-loop`	Stop hook で自動再投入、`--max-iterations`、`--completion-promise "DONE"` 標準対応
snarktank/ralph	OSS フレームワーク非依存	`.ralph/{PROMPT.md,fix_plan.md,AGENT.md}` を正典とする最も支持されている canonical 実装
vercel-labs/ralph-loop-agent	AI SDK 向け	TypeScript、Next.js とのインテグレーション
frankbria/ralph-claude-code	Claude Code 特化	終了検出強化(false-positive 抑制)
OpenAI Codex CLI 0.128.0 (2026/4/30)	CLI 組込	`/goal` コマンドとして Ralph がビルトイン化
jujunjun110/claude-looper	日本語解説 + bash 実装	入門に最適

Ralph Loop ベストプラクティス 4 原則

2026 年に確立した実装ガイドラインです。

flowchart LR
    A["① 機械検証可能な完了条件<br/>(tests pass, lint clean, checklist [x])"] --> B["② ハードキャップ必須<br/>(--max-iterations + $ budget)"]
    B --> C["③ コンテキスト枯渇前に<br/>fresh agent へ rotate<br/>状態は AGENTS.md + git へ"]
    C --> D["④ SDD と分離<br/>(spec は人間 / 実装だけ Ralph)"]

    style A fill:#e8f5e9
    style B fill:#fff3e0
    style C fill:#e1f5ff
    style D fill:#f3e5f5

Mechanically checkable な完了条件:pnpm test && pnpm lint && pnpm typecheck がすべて緑、または fix_plan.md の全項目が [x] になる、といった機械判定可能なゴールに限定する。「プロっぽく見せて」「ユーザフレンドリーに」など曖昧条件は厳禁。
ハードキャップ必須:--max-iterations 30 と --max-budget-usd 5.00 を必ず設定し、暴走時の被害を物理的に止める。
コンテキスト枯渇前に fresh agent へ rotate:1 イテレーション = 1 セッション。状態は AGENTS.md / fix_plan.md / git log に逃がす。
SDD と組み合わせる:仕様策定(BMAD / cc-sdd / GitHub Spec Kit / bmalph)と Ralph 実装は分離する。Ralph は greenfield + 機械検証可能なタスクに最適、本番 critical path には別の人間レビューを噛ませる。

全体フロー

flowchart TB
    Start(["🌙 launchd 22:00 起動"]) --> Init["📂 .ralph/ 初期化<br/>PROMPT.md / fix_plan.md / AGENTS.md"]
    Init --> Loop{"fix_plan.md に<br/>[ ] あり?"}
    Loop -->|"なし"| Done(["🎉 完了通知<br/>(osascript)"])
    Loop -->|"あり"| Fresh["🆕 フレッシュ claude -p<br/>(同一 PROMPT.md 投入)"]
    Fresh --> Impl["実装 → テスト → コミット<br/>→ fix_plan.md 更新"]
    Impl --> Check{"Stop hook<br/>判定"}
    Check -->|"DONE 出力"| Loop
    Check -->|"usage limit"| Wait["⏰ リセット時刻まで<br/>caffeinate -i sleep"]
    Wait --> Loop
    Check -->|"3 回連続失敗"| Block["⚠️ fix_plan.md に<br/>Blocked 追記"]
    Block --> Loop
    Loop -->|"max-iter 到達"| Cap(["🛑 ハードキャップで停止"])

    style Start fill:#e1f5ff
    style Done fill:#e8f5e9
    style Wait fill:#fff3e0
    style Block fill:#ffebee
    style Cap fill:#ffebee

推奨実装:公式 ralph-loop plugin + 薄い bash ラッパー

最もメンテコストが低いのは Anthropic 公式 ralph-loop plugin を使い、リミット待機だけ bash で巻く パターンです。

# プラグインインストール(2026/5 時点)
claude plugin install anthropic/ralph-loop

.ralph/PROMPT.md(同一プロンプトで毎回再投入される正典)を作ります。

<!-- .ralph/PROMPT.md -->
# 目的
@specs/feature/requirements.md を fix_plan.md のチェックリストに沿って実装する。

# あなたが毎イテレーション必ず行うこと
1. `git status` と `cat .ralph/fix_plan.md` で現在地を確認
2. `[ ]` の最上位項目を 1 つだけ選ぶ
3. TDD で実装(Red → Green → Refactor)
4. `pnpm test && pnpm lint && pnpm typecheck` がすべて緑になるまで修正
5. `git add -p && git commit -m "feat: ..."`(Conventional Commits)
6. `.ralph/fix_plan.md` で該当項目を `[x]` に更新して再 commit
7. **完了したら最終行に必ず `DONE` とだけ出力**
8. 5 回連続で同じテストが落ちたら、その項目に `⚠️ Blocked: <理由>` を追記し次へ

# 禁止
- `git add -A` / `--no-verify` / `any` / `as` / `@ts-ignore`
- 既存テストの削除(壊れたら原因を直す)
- specs/ 以下の改変(仕様変更が必要なら fix_plan.md に「要 spec 改訂」と書いて停止)

ループ本体は次のシンプルな bash で十分です(リミット時刻パース + caffeinate + osascript 通知付き)。

#!/usr/bin/env bash
# ralph-loop.sh - 公式 plugin に薄く被せるリミット耐性ラッパー
set -uo pipefail
REPO="$(pwd)"; LOG_DIR="${REPO}/.ralph/logs"; mkdir -p "$LOG_DIR"
ITER=0; MAX_ITER="${MAX_ITER:-30}"; BUDGET="${BUDGET_USD:-5.00}"

while (( ITER < MAX_ITER )); do
  ITER=$((ITER + 1)); TS=$(date +%Y%m%d_%H%M%S)
  LOG="$LOG_DIR/iter_${ITER}_${TS}.log"
  echo "===== Ralph Iteration ${ITER} =====" | tee "$LOG"

  # ① fix_plan.md に未完了 [ ] が残っているか
  if ! grep -qE '^\s*-\s*\[\s*\]' .ralph/fix_plan.md 2>/dev/null; then
    osascript -e 'display notification "Ralph: ALL DONE 🎉" with title "Claude"' 2>/dev/null
    break
  fi

  # ② フレッシュコンテキストで PROMPT.md 投入
  timeout 30m claude -p "$(cat .ralph/PROMPT.md)" \
    --permission-mode acceptEdits \
    --max-turns 80 \
    --output-format text 2>&1 | tee -a "$LOG"
  EC=${PIPESTATUS[0]}

  # ③ リミット検知 → リセット時刻まで caffeinate sleep
  if grep -qiE "usage limit reached" "$LOG"; then
    reset=$(grep -oE 'reset at [0-9]+(am|pm)' "$LOG" | tail -1 | awk '{print $3}')
    tz=$(grep -oE '\([A-Za-z_/]+\)' "$LOG" | tail -1 | tr -d '()')
    target=$(TZ="$tz" date -j -f '%I%p %Y-%m-%d' "$reset $(date +%Y-%m-%d)" +%s 2>/dev/null \
             || date -d "today $reset" +%s 2>/dev/null \
             || echo $(( $(date +%s) + 1800 )))
    now=$(date +%s); (( target <= now )) && target=$((target + 86400))
    sleep_for=$(( target - now + 60 ))
    osascript -e "display notification \"Ralph waiting $((sleep_for/60))m\" with title \"Claude\"" 2>/dev/null
    caffeinate -i sleep "$sleep_for"
    continue
  fi

  # ④ DONE が最終行になければ次イテレーションで再投入(これが Ralph の本質)
  if ! tail -3 "$LOG" | grep -q "^DONE$"; then
    sleep $(( 30 * (1 + ITER % 5) ))    # 軽いバックオフのみ
  fi
done

Stop hook で plugin を駆動する派(より洗練された方法)は .claude/settings.json に次を入れます。

{
  "hooks": {
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/ralph-continue.sh"
      }]
    }]
  }
}

#!/usr/bin/env bash
# .claude/hooks/ralph-continue.sh - Stop 時に DONE が無ければ exit 2 で継続強制
INPUT=$(cat)
[ "$(echo "$INPUT" | jq -r '.stop_hook_active')" = "true" ] && exit 0
LAST=$(echo "$INPUT" | jq -r '.transcript_path' | xargs tail -n 5)
if echo "$LAST" | grep -q "^DONE$"; then exit 0; fi
echo "fix_plan.md にまだ [ ] が残っています。次のタスクを継続してください。" >&2
exit 2   # Claude に継続を強制

tmux で「夜間放置」する場合は tmux new-session -d -s ralph "caffeinate -i ./ralph-loop.sh > .ralph/logs/run.log 2>&1" で起動し、tmux attach -t ralph で監視、Ctrl+b d でデタッチします。OS 再起動後の自動復元には tmux-resurrect + tmux-continuum を組み合わせます。

Mac 固有の自動化:launchd + caffeinate + 4 つの壁突破

caffeinate -i でアイドルスリープ防止、-d でディスプレイ、-s で AC 電源時の system sleep、-t 28800 で時間限定が可能です。実は Claude Code 自身が内部で caffeinate -i -t 300 を 5 分ごとに spawn する ため対話実行中はそもそもスリープしませんが(Issue #21432)、バックエンド / cron / launchd から spawn する場合は明示的に caffeinate でラップする のが安全です。ラップトップを閉じた瞬間も caffeinate は効きません。

flowchart LR
    A["💤 Mac スリープ中"] --> B{{"launchd<br/>22:00 起床"}}
    B --> C["caffeinate -i<br/>(スリープ抑止)"]
    C --> D["claude-loop.sh"]
    D --> E["朝起きたら<br/>PR が積み上がっている"]

    style A fill:#eceff1
    style B fill:#e1f5ff,stroke:#0277bd
    style C fill:#fff3e0
    style E fill:#e8f5e9,stroke:#2e7d32

GMO ペパボの記事(zenn.dev/pepabo)が指摘する cron 自走で毎回ハマる 4 つの壁 を整理しました。

flowchart LR
    Start["🚀 launchd 起動"] --> W1{"壁 ①<br/>Bypass<br/>permissions"}
    W1 -->|"OK"| W2{"壁 ②<br/>Trust this<br/>folder"}
    W2 -->|"OK"| W3{"壁 ③<br/>MCP<br/>allow/deny"}
    W3 -->|"OK"| W4{"壁 ④<br/>ファイル<br/>除外リスト"}
    W4 -->|"OK"| Run["✅ 自走開始"]

    W1 -.解決策.-> S1["acceptEdits 設定"]
    W2 -.解決策.-> S2["事前に対話モードで<br/>一度開く"]
    W3 -.解決策.-> S3["事前 allowlist"]
    W4 -.解決策.-> S4[".env 等の deny を<br/>settings.json に"]

    style Run fill:#e8f5e9,stroke:#2e7d32

壁	内容	解決策
① Bypass permissions	権限プロンプトで止まる	`--permission-mode acceptEdits`
② Trust this folder	初回起動で信頼確認	対話モードで一度開く / `~/.claude.json` の `hasTrustDialogAccepted: true` を直書き
③ MCP の allow/deny	MCP ツールで止まる	事前に対話モードで一度許可
④ ファイル除外	`.env` などへのアクセス	settings.json の deny に明記

これらを抜ければ launchd で完全無人化できます。~/Library/LaunchAgents/com.user.claude-loop.plist を以下で配置します。

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0"><dict>
  <key>Label</key><string>com.user.claude-loop</string>
  <key>ProgramArguments</key><array>
    <string>/usr/bin/caffeinate</string><string>-i</string>
    <string>/bin/bash</string><string>-lc</string>
    <string>cd /Users/me/projects/myapp && /usr/local/bin/claude-loop.sh</string>
  </array>
  <key>StartCalendarInterval</key>
    <dict><key>Hour</key><integer>22</integer><key>Minute</key><integer>0</integer></dict>
  <key>EnvironmentVariables</key>
    <dict><key>PATH</key><string>/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin</string></dict>
  <key>StandardOutPath</key><string>/Users/me/.claude-loop/stdout.log</string>
  <key>StandardErrorPath</key><string>/Users/me/.claude-loop/stderr.log</string>
  <key>WorkingDirectory</key><string>/Users/me/projects/myapp</string>
</dict></plist>

launchctl load ~/Library/LaunchAgents/com.user.claude-loop.plist でロードし、launchctl start com.user.claude-loop で即時実行できます。cron は寝てる Mac では発火しない ため pmset repeat wake MTWRF 02:55:00 の事前起床と組み合わせるか、launchd 一択 です。完了通知は osascript -e 'display notification "Iteration 5 完了" with title "Claude Loop" sound name "Glass"' でロックスクリーンに送れます。fswatch -o src/ tests/ | xargs -n1 -I{} claude -p "..." のファイル監視併用も有効で、保存と同時にテスト / 修復ループが走ります。

究極のセットアップ:4 フェーズで「機能要件 1 行 → PR 作成」

ディレクトリ構成は次のように .claude/ と .ralph/ 配下に 全制御ファイルを集約 します。

~/projects/myapp/
├── CLAUDE.md                     # 200 行以下、行動原則
├── AGENTS.md                     # マルチ AI 共通(Ralph 状態の正典)
├── .mcp.json                     # 7 点セット MCP
├── .ralph/
│   ├── PROMPT.md                 # 同一プロンプト(毎イテレーション再投入)
│   ├── fix_plan.md               # 作業キュー([ ]/[x]/⚠️ Blocked)
│   └── logs/                     # 各イテレーションのログ
├── .claude/
│   ├── settings.json             # 権限・hooks(Stop で ralph-continue.sh)
│   ├── skills/
│   │   ├── commit/SKILL.md       # Conventional Commits 自動生成
│   │   ├── run-tests-and-fix/SKILL.md
│   │   └── verify-in-browser/SKILL.md  # Playwright 検証
│   ├── agents/
│   │   ├── feature-implementer.md  # model: sonnet, isolation: worktree
│   │   ├── test-writer.md
│   │   ├── code-reviewer.md
│   │   └── debugger.md
│   └── hooks/
│       ├── block-dangerous.sh
│       ├── format-and-lint.sh
│       └── ralph-continue.sh     # Stop hook で DONE 判定 → 継続強制
└── specs/<feature>/{requirements,design,tasks}.md   # cc-sdd の SDD

運用は次の 4 フェーズで進めます。

flowchart TB
    P1["📋 Phase 1: 計画(人間関与)<br/>plan モード + /kiro-discovery<br/>requirements → design → tasks"]
    P2["🔁 Phase 2: 自律実装ループ<br/>/ralph-loop で TDD 実装<br/>Stop hook でテスト自動実行"]
    P3["🌐 Phase 3: 自動 QA<br/>qa subagent + Playwright MCP<br/>各種 viewport で実フロー検証"]
    P4["🐙 Phase 4: 出荷<br/>gh pr create<br/>Actions で自動レビュー"]

    P1 --> P2 --> P3 --> P4

    style P1 fill:#fff3e0,stroke:#ef6c00
    style P2 fill:#e1f5ff,stroke:#0277bd
    style P3 fill:#f3e5f5,stroke:#7b1fa2
    style P4 fill:#e8f5e9,stroke:#2e7d32

Phase 1(計画、人間関与) で claude --permission-mode plan を起動し cc-sdd プラグイン(gotalab/cc-sdd)で機能要件を requirements.md(EARS 記法)→ design.md → tasks.md に分解、人間が approve します。この成果物を .ralph/fix_plan.md の機械検証可能なチェックリストへ変換するのが Phase 1 の最終ステップ です。Phase 2(Ralph 自律実装ループ) で claude -w feature-x から ./ralph-loop.sh を起動、Sonnet 4.6 が フレッシュコンテキストで .ralph/PROMPT.md を毎回再投入、各タスクを TDD で実装、Stop hook (ralph-continue.sh) で DONE が出ていなければ自動継続。Phase 3(自動 QA) では qa subagent が Playwright MCP で 375×667 モバイル含む各種 viewport で実フロー検証、失敗時はデバッガに自動委譲します。Phase 4(出荷) で gh pr create し、GitHub Actions の anthropics/claude-code-action@v1 が PR レビューを自動コメントします。

「機能要件 1 行 → 無人で機能完成」の最小コマンドは次の通りです(Ralph パターン版)。

# 1. 仕様を spec に展開(対話、5 分)
echo "ユーザーが商品にレビューを書いて星評価できる機能" > /tmp/req.txt
claude --permission-mode plan \
  -p "$(cat /tmp/req.txt) を cc-sdd で specs/review/{requirements,design,tasks}.md に展開し、
       .ralph/fix_plan.md にテストで検証可能なチェックリストを作成してください"

# 2. Ralph ループを夜間に走らせる
caffeinate -i tmux new -d -s ralph \
  "MAX_ITER=30 BUDGET_USD=5.00 ./ralph-loop.sh"

# 3. 朝、PR を確認
gh pr list --author @me

Pro プランで 24 時間化する経済的レシピ は、ローカル launchd で毎晩 22:00 に ralph-loop.sh を起動し(/loop はセッション終了で消えるため永続用途には不適)、ccusage statusline で残量常時表示、リミット到達時は bash でリセット時刻まで caffeinate -i sleep するというものです。Routines(クラウド)は Pro で 5 回 / 日と少ないため、@claude の PR コメント自動レビュー専用に使い、メイン開発はローカル Ralph で回しましょう。Pro 上限が頻繁にぶつかるようなら Max 5x($100)か musistudio/claude-code-router で Sonnet を OpenRouter 経由 API(例: anthropic/claude-sonnet-4.6)にスワップ する運用が現実解です。

隔離戦略:DevContainer + Worktree + Checkpointing が三種の神器

--dangerously-skip-permissions を実機で直に使うのはプロンプトインジェクションと破壊コマンドのリスクが高いです。

flowchart TB
    Risk["⚠️ プロンプトインジェクション<br/>+ 破壊コマンド"]

    subgraph "🛡️ 三種の神器"
        A["🐳 DevContainer<br/>iptables ホワイトリスト"]
        B["🌳 Worktree 隔離<br/>.claude/worktrees/"]
        C["⏪ Checkpointing<br/>Esc Esc / /rewind"]
    end

    Risk -.防ぐ.-> A
    Risk -.防ぐ.-> B
    Risk -.防ぐ.-> C

    A --> Safe["✅ 無人実行可能"]
    B --> Safe
    C --> Safe

    style Risk fill:#ffebee,stroke:#c62828
    style Safe fill:#e8f5e9,stroke:#2e7d32

Anthropic 公式 DevContainer(anthropics/claude-code/.devcontainer)は 3 ファイル構成(devcontainer.json/Dockerfile/init-firewall.sh)で、iptables + ipset によるホワイトリスト型ファイアウォールを node ユーザー sudoers で設定し、api.anthropic.com/registry.npmjs.org/api.github.com 等のみ outbound 許可、それ以外 deny します。Anthropic は「コンテナのセキュリティ強化により安全に無人実行できる」と明記していますが、「Claude Code credential が漏洩しうるので 信頼できるリポジトリでのみ使え」と注意しています。スタンドアロンで動かすなら docker run --cap-drop=ALL --cap-add=NET_ADMIN --cap-add=NET_RAW -v $(pwd):/workspaces/project claude-code-sandbox が定石で、~/.ssh ~/.aws は絶対にマウントしないでください。

--worktree (-w) ネイティブサポートは v2.1.49–50 で CLI 統合され、<repo>/.claude/worktrees/<name>/ に隔離 worktree を作成します。Subagent frontmatter の isolation: worktree で各サブエージェントを独立 worktree に閉じ込められ、並列実行時の同一ファイル編集競合を物理的に防げます。Boris Cherny 自身は 同時 10〜15 体 の Claude を回しています。Checkpointing(Claude Code 2.0)は各編集前に自動スナップショットし Esc Esc または /rewind で巻き戻せますが、Claude のファイル編集ツールが行った変更のみ が対象で手動編集や bash 経由の変更は含まれません──必ず Git と併用してください。--max-turns 50 と --max-budget-usd 5.00 で物理的上限も設定し、PreToolUse hook で rm -rf|sudo|:(){:|:&};:|dd if=|mkfs を正規表現で deny するスクリプトを必ず登録するようにしましょう。

結論:Pro でも実装可能、ボトルネックは「人間の要件記述」だけ

2026 年 5 月時点で「機能要件さえ書けば Claude Code が無人で開発を進める」セットアップは Pro プランでも完全に実装可能です。鍵は次の 5 つです。

mindmap
  root((Pro で<br/>24h 自走))
    1. 三層防衛
      acceptEdits モード
      厳密な deny
      PreToolUse Hook
    2. 行動原則
      動作優先
      解決困難は次へ
      fix_plan.md 記録
    3. 分業
      Skills
      Subagents
      MCP 7 点
    4. 自己 QA
      Playwright MCP
      自動ブラウザ検証
    5. Ralph Loop で 24h 自走
      公式 ralph-loop plugin
      Stop hook 継続強制
      caffeinate + launchd

(1) acceptEdits モード + 厳密な deny + PreToolUse hook の三層防衛 で危険操作を物理ブロックする
(2) CLAUDE.md に「動作優先・解決困難は .ralph/fix_plan.md に⚠️で記録して次へ」を行動原則化 する
(3) Skills と Subagents で実装 / テスト / レビュー / QA を分業 する
(4) Playwright MCP で自己 QA まで閉じさせる
(5) Ralph Loop(公式 ralph-loop plugin or snarktank/ralph)+ caffeinate + リミット時刻パース + launchd で 24 時間自走させる

Ralph Wiggum ループ思想で「フレッシュコンテキスト × ファイルと git による状態永続化」を徹底し、機械検証可能な完了条件 + ハードキャップ(--max-iterations/--max-budget-usd) を必ず設定すれば、context rot で破綻せず根気で機能を完成させられます。

留意点として、Claude Code は週次で急速にアップデートしており、auto モード(2026/3)、Agent Teams(2026/2 実験的)、Routines(2026/4)、Opus 4.7(2026/4/16 GA)、OpenAI Codex CLI への Ralph ビルトイン化(2026/4/30)など 2026 年に入って自律性の階梯が一段上がりました。Pro での Routines 5 回 / 日制限は重要トリガー(PR review など)に絞り、メインのループはローカル launchd + Ralph で安く長く回すのが経済合理的です。

最後に注意したいのは Pro は事実上 Sonnet 専用(Opus 4.7 は Max 以上)である点、/model sonnet 明示で安定稼働 する点、Cache Read がトークン消費の主犯 である点で、ccusage daily --breakdown で月初に内訳を確認する習慣をつけたいところです。残るボトルネックは Claude ではなく 人間が書く機能要件の質(と .ralph/fix_plan.md に落とす機械検証可能なチェックリストの設計)だけで、それを SDD の requirements.md に EARS 記法で書ければ──あとは寝ている間に PR が積み上がっています。

ClaudeCodeで抑えておく機能

Tue, 28 Apr 2026 00:00:00 GMT

概要

Claude Code は Anthropic が提供する CLI ベースの AI コーディングエージェントです。単なる「コード補完ツール」ではなく、ファイル操作・シェル実行・Web 検索・サブエージェント呼び出しといった機能を組み合わせて、設計→実装→レビュー→コミットまで一連の開発ワークフローをこなせる点が特徴です。

ただし機能が豊富なため、「とりあえず使う」だけだとコンテキスト肥大・無限ループ・誤操作などの落とし穴にハマりがちです。本記事では Claude Code を実務で使ううえで 押さえておくべき主要機能 と、それぞれのベストプラクティス／アンチパターン／活用事例をまとめます。

CLAUDE.md（プロジェクト記憶ファイル）
Skills（再利用可能な手順書）
自動承認モード（permission mode）
コンテキストサイズと /compact
マルチエージェント（Sub-agents）
リモート Claude（Remote Agents / Sandbox）
Hooks（イベントフック）
Plugins
Chrome 拡張
GitHub 連携
その他押さえておきたい機能
全体ベストプラクティスまとめ

CLAUDE.md（プロジェクト記憶ファイル）

機能概要

Claude Code は起動時にカレントディレクトリ及び親ディレクトリの CLAUDE.md を自動的に読み込み、システムプロンプトに追加します。プロジェクト固有のコーディング規約・ディレクトリ構造・ビルドコマンド・禁止事項などを記述することで、毎回指示し直す必要がなくなります。

階層は以下の優先順で読み込まれます：

スコープ	パス	用途
ユーザー	`~/.claude/CLAUDE.md`	個人の好み（言語、口調、共通ルール）
プロジェクト	`<repo>/CLAUDE.md`	チーム共有のルール（Git にコミット）
ローカル	`<repo>/CLAUDE.local.md`	個人用の上書き（`.gitignore` 推奨）
サブディレクトリ	`<repo>/path/to/CLAUDE.md`	特定モジュール固有のルール

使い方

/init コマンドを叩くと、Claude がリポジトリを走査して CLAUDE.md の雛形を自動生成してくれます。

# 起動して
claude

# プロジェクトのルートで
/init

記載すべき主要項目：

# Project Overview
- 何のプロジェクトか / 主要技術スタック

# Build & Test Commands
- `pnpm install` / `pnpm test` / `pnpm lint` などよく使うコマンド

# Code Style
- 言語別のコーディング規約
- コメントは日本語、識別子は英語、など

# Architecture
- 主要ディレクトリの責務
- 依存関係の方向

# Do / Don't
- 直接編集禁止のファイル
- 触ってはいけない設定

ベストプラクティス

「コマンド一覧」を必ず書く：Claude は知らないとビルドコマンドを推測しがち。明示すれば確実にそれを使う。
Don't（禁止事項）を明確に：「migrations/ 配下のファイルは編集しない」など、人間が暗黙に守っているルールほど書く価値が高い。
長くなりすぎない：CLAUDE.md は毎ターンのコンテキストに乗る。500 行を超えたら Skills に切り出す。

アンチパターン

❌ README をそのままコピー → 不要な情報でコンテキストを汚染
❌ 「丁寧に説明してください」など曖昧な指示 → 守られない
❌ 全社共通ルールをプロジェクト CLAUDE.md に書く → ユーザースコープに置くべき

活用事例

モノレポで各パッケージの README 代わりに packages/*/CLAUDE.md を配置し、Claude にそのパッケージ内の作業をさせる
DB スキーマ規約を db/CLAUDE.md に書き、SQL マイグレーション生成を任せる

Skills（再利用可能な手順書）

機能概要

Skills は「特定タスクの手順書」をディレクトリ単位で定義し、必要な時だけロードできる仕組みです。CLAUDE.md と違って常時ロードされないため、コンテキストを節約しつつ、複雑な手順を再現性高く実行できます。

~/.claude/skills/
├── pr-review/
│   ├── SKILL.md           # 説明（先頭の YAML フロントマターでトリガー定義）
│   └── scripts/...        # 補助スクリプトも置ける
└── deploy-staging/
    └── SKILL.md

SKILL.md の冒頭に description を書くと、Claude がユーザーの要求と照らし合わせて自動的に適切な Skill を起動します。

使い方

---
name: pr-review
description: |
  GitHub PR のレビューを実施する。差分取得・テスト確認・
  コメント投稿までを行う。「PR レビューして」と言われたら起動。
---

# PR Review Skill
1. `gh pr view` で対象 PR を取得
2. `gh pr diff` で差分取得
3. レビュー観点（セキュリティ、パフォーマンス、可読性）でチェック
4. `gh pr review --comment` でコメント投稿

明示的に呼び出すこともできます：

/pr-review 1234

ベストプラクティス

「定型作業」を Skill 化：リリース、コードレビュー、調査レポート生成など、毎回似た手順を踏むものは Skill にすると再現性が上がる。
description はトリガー条件を具体的に：「いつ起動すべきか／すべきでないか」を書くと誤起動が減る。
Skill 内で別 Skill を呼ぶ：合成して大きなワークフローを作れる。

アンチパターン

❌ 1 回しか使わない処理を Skill 化 → 普通に依頼すれば良い
❌ description が曖昧 → 起動されない or 誤起動
❌ 巨大スクリプトを SKILL.md に直書き → scripts/ に分割する

活用事例

security-review：差分に対してセキュリティ観点のレビューを実施
init：新規プロジェクトに CLAUDE.md を生成
simplify：直近の差分をリファクタしてシンプル化

自動承認モード（permission mode）

機能概要

Claude Code は安全のため、ファイル書き込みやシェル実行のたびに確認プロンプトを出します。これを制御するのが permission mode です。

モード	挙動
`default`	危険な操作のみ確認
`acceptEdits`	ファイル編集のみ自動承認
`plan`	計画のみ立てて実行はしない（読み取り専用）
`bypassPermissions`（俗称：YOLO モード）	すべて自動実行（要注意）

起動時オプションや実行中の Shift+Tab で切り替え可能。

# 起動時に指定
claude --permission-mode acceptEdits

# 完全自動（サンドボックス環境でのみ推奨）
claude --dangerously-skip-permissions

ベストプラクティス

通常作業は acceptEdits：編集の確認プロンプトが減るだけでも体感が大きく変わる。
読むだけなら plan モード：調査や設計レビューはこれで十分。
完全自動は隔離環境で：Docker / Devcontainer / git worktree 内で動かす。
.claude/settings.json で 特定コマンドのみ allowlist にしておけば、permission prompt の発生回数を減らせる。

{
  "permissions": {
    "allow": [
      "Bash(pnpm test*)",
      "Bash(pnpm lint*)",
      "Bash(git status)",
      "Bash(git diff*)"
    ]
  }
}

アンチパターン

❌ 本番リポジトリで最初から --dangerously-skip-permissions → rm -rf 系の事故が起きうる
❌ allowlist に Bash(*) を入れる → 自動承認の意味がない
❌ git push --force を allowlist に入れる → 取り返しがつかなくなる

活用事例

大量のリファクタを夜間に流すとき、サンドボックスで YOLO モード＋ Hooks でテスト自動実行
レビュー専用エイリアス：alias claude-review='claude --permission-mode plan'

コンテキストサイズと /compact

機能概要

LLM には扱えるコンテキストウィンドウ（Claude Sonnet 4.5/4.6 系で 200K〜1M トークン）があり、会話が長引くと制限に達します。Claude Code はこれを軽減するため：

/compact：会話履歴を要約して圧縮（手動実行）
自動コンパクション：上限近くで自動的に要約
/clear：履歴を完全リセット

使い方

# 手動で要約
/compact

# 要約のヒントを指定
/compact 「現在のリファクタリングの進捗とTODOを残して圧縮して」

# 完全リセット（タスク切替時）
/clear

ベストプラクティス

タスクが切り替わったら /clear：前のタスクの記憶は新タスクのノイズになる。
長期タスクは /compact を意識的に：自動コンパクションは予測しにくい。区切りで明示的に呼ぶと精度が安定する。
重要事項はファイルに書き出す：TODO / 設計メモは notes/ などに残せば、/clear してもファイル経由で復元可能。
キャッシュを温存する操作を選ぶ：プロンプトキャッシュは 5 分 TTL。/compact 直後など、キャッシュが切れる操作の連発はコスト増につながる。

アンチパターン

❌ 1 セッションで何時間も同じスレッドを使い続ける → コストも品質も悪化
❌ /compact を何度も連打 → 要約の要約で情報が劣化
❌ 大きなファイル全体を何度も Read → コンテキストを圧迫。Grep / 範囲指定 Read を使う

活用事例

長時間の調査タスクで「中間レポートを report.md に保存 → /clear → 続き」というワークフロー
マルチタスクの並走時、git worktree ＋別セッションで分離

マルチエージェント（Sub-agents）

機能概要

Claude Code には Agent ツールがあり、メインのエージェントからサブエージェントを起動して、独立したコンテキストで作業させられます。

エージェント種別	用途
`Explore`	高速な調査専用（読み取りのみ）
`general-purpose`	何でもこなす汎用エージェント
`Plan`	設計・計画立案専用
カスタム	`.claude/agents/*.md` で独自定義可能

使い方

メインエージェントが「広範な調査」「独立検証」「設計レビュー」を必要とした際に内部的に呼び出します。ユーザーが明示的にお願いすることも可能：

このコードベースで認証周りの実装をすべて洗い出して。Exploreエージェントを使って。

カスタムエージェント定義例 .claude/agents/sql-reviewer.md：

---
name: sql-reviewer
description: SQLマイグレーションをレビューし、ロック・性能観点で問題を指摘
tools: [Read, Grep, Bash]
---
あなたはDB専門家です。以下を確認してください：
- NOT NULL 追加時のロック影響
- インデックスの妥当性
- 後方互換性

ベストプラクティス

コンテキスト分離が目的：メインエージェントの履歴を汚さずに済む大量の調査・検証はサブに任せる。
独立した「セカンドオピニオン」に使う：レビュアーや設計レビューには別エージェントが効く。
並列実行できる場合は並列で：複数の独立調査は 1 メッセージで並列スポーン。

アンチパターン

❌ 些細な質問でも毎回サブエージェント → 起動コストの無駄
❌ サブにあいまいな指示「いい感じにして」 → 独立コンテキストなので余計に迷子になる
❌ サブの結果を鵜呑み → 「やったつもり」の幻覚に注意。実ファイルを確認する

活用事例

大規模リファクタの「事前調査 → 計画 → 実装 → レビュー」を 4 つのサブで分業
セキュリティレビュー時に general-purpose ＋ security-review Skill を併用

リモートClaude（Remote Agents / Sandbox）

機能概要

ローカルマシンを占有せずに、**Anthropic 側のサンドボックス（または GitHub Actions などのリモート実行環境）**で Claude Code を走らせる機能群です。代表的なものに：

Anthropic 公式の Cloud Agents / Routines：cron スケジュールで自動実行
GitHub Actions 連携：PR コメントで @claude メンションするとサンドボックス内で実行
Devcontainer / Docker 内実行：自前のサンドボックス

使い方

cron 風のスケジュール実行（例）：

/schedule "毎日 9:00 に dependabot PR をレビューしてマージ可能なものは approve"

GitHub PR でのメンション：

@claude このPRをレビューして、テストの不足を指摘してください

ベストプラクティス

「夜間バッチ」用途に最適：定期的な依存更新・脆弱性スキャン・ドキュメント整備など。
権限を最小化：リモート Claude が触れる範囲を GitHub App の権限で絞る（特定リポのみ、特定 Action のみ）。
シークレット管理：API キーは Repo Secrets 経由。Claude のログに漏れないよう Hooks でマスク。

アンチパターン

❌ 本番デプロイ権限まで渡す → 想定外コミットでロールアウトされる事故
❌ ログ未確認で長期間放置 → 暴走に気付けない
❌ コスト管理なしで cron 連打 → API 費用が膨らむ

活用事例

毎日 9:00 に「昨日マージされた PR を要約して Slack へ投稿」
毎週月曜に「ライブラリ更新 PR を作成」

Hooks（イベントフック）

機能概要

Claude Code には ライフサイクルイベントがあり、各イベントで任意のシェルコマンドを実行できます。設定は .claude/settings.json の hooks フィールド。

イベント	タイミング
`PreToolUse`	ツール実行直前
`PostToolUse`	ツール実行直後
`UserPromptSubmit`	ユーザー入力送信時
`Stop`	エージェント停止時
`SubagentStop`	サブエージェント停止時
`Notification`	確認プロンプト発生時

使い方

.claude/settings.json 例：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "pnpm lint --fix" }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "osascript -e 'display notification \"Claude finished\"'" }
        ]
      }
    ]
  }
}

ベストプラクティス

編集後は自動 lint / format：人間がレビューするときに無駄な指摘が減る。
ガードレールに使う：PreToolUse で「特定ファイルへの編集を拒否」など。
完了通知：長時間タスクの終了を macOS 通知 / Slack で受け取る。

アンチパターン

❌ Hook で重い処理（フルテストなど）→ 体感が極端に遅くなる
❌ 失敗しても無視するスクリプト → 通った気になる落とし穴
❌ 無限ループを作るフック（編集→lint→ファイル書き換え→編集 …）

活用事例

PostToolUse で prettier --write → 常にフォーマット済み
Stop フックで notify-send ＋ベル音
PreToolUse で本番DBに接続しようとした場合に拒否

Plugins

機能概要

Plugin は Skills / Hooks / Agents / Commands をパッケージ化して配布可能にする仕組みです。marketplace から追加でき、社内独自の Plugin を Git リポジトリで公開することも可能です。

使い方

# Plugin 一覧
/plugins

# 追加（マーケットプレイス）
/plugins install anthropic/code-review

# 自社プラグインを Git から
/plugins install git+ssh://git@github.com/myorg/claude-plugins.git

Plugin の中身（例）：

my-plugin/
├── plugin.json          # メタデータ
├── skills/
│   └── deploy/SKILL.md
├── agents/
│   └── reviewer.md
└── hooks/
    └── post-edit.sh

ベストプラクティス

チーム共通の作法を Plugin 化：CLAUDE.md だけでは表現しきれない複合的な機能（Skill ＋ Hook ＋ Agent）をひとまとめに配布。
バージョニング：Plugin の更新で挙動が変わると事故になるのでセマンティックバージョニングを徹底。

アンチパターン

❌ 信頼できないソースから入れる → Hook で任意コマンド実行されるリスクあり
❌ 1 機能だけの Plugin を乱立 → Skill 単体で十分

活用事例

社内デプロイフローをまるごと Plugin 化（Skill: deploy-staging / Hook: 自動 changelog 更新 / Agent: deploy-reviewer）

Chrome拡張

機能概要

Claude Code 関連の Chrome 拡張は、ブラウザの内容（選択テキスト、PR、Issue、Stack Overflow など）を Claude にワンクリックで渡すためのものです。代表的には：

Claude for Chrome：ページの選択範囲・URL を取得して Claude のコンテキストに送る
Obsidian 連携拡張：Web → Obsidian → Claude の動線

使い方

拡張をインストール
ページ上で対象テキストを選択
拡張のショートカットキーで Claude に送信
ローカルの Claude Code セッションがコンテキスト付きで起動

ベストプラクティス

長文のドキュメントを丸ごと送らない：必要部分のみ選択。
機密ページでは無効化：社内 Wiki などで送信先を誤らないよう、ドメイン制限を設定。

アンチパターン

❌ 「全ページ送信」→ コンテキスト浪費＋情報漏洩リスク
❌ 拡張を経由してログを残さない → 何を送ったか後から確認できない

活用事例

LeetCode / AtCoder の問題ページから直接 Claude に解法を相談
GitHub Issue を選択 → 関連する自分のコードベースを Claude に調査させる

GitHub連携

機能概要

Claude Code には GitHub 公式 App があり、PR・Issue 上で @claude メンションすると、リモート Claude が起動して以下を実行できます：

PR レビュー＋コメント投稿
Issue から PR 自動作成（実装 → ブランチ作成 → PR）
CI 失敗時の自動リトライ・修正提案

ローカル CLI からも gh コマンド経由で密接に連携できます。

使い方

# Claude Code 内から
gh pr create --title "feat: add X" --body "..."
gh pr review 123 --approve
gh issue list --label bug

PR コメントで：

@claude このコメントの指摘を反映してコミットしてください

ベストプラクティス

GitHub App の権限は最小化：必要なリポのみ、必要なスコープのみ。
gh を活用：ローカル Claude Code は gh で十分強力。コードレビュー、PR 作成、リリースノート作成までこなせる。
CI と組み合わせる：CI 失敗 → Claude にスタックトレースを渡して修正案、というループ。

アンチパターン

❌ main への直接 push 権限を Claude に与える → ロールバック不能事故
❌ Issue の自動 PR 化を「全 Issue」に適用 → ノイズ PR が量産される
❌ レビュー結果を盲信して即マージ → 必ず人間のサインオフを残す

活用事例

Issue ラベル claude-task が付いたものだけ自動で PR ドラフト化
リリース前に過去 1 週間の PR を Claude が要約してリリースノート生成

その他押さえておきたい機能

Worktree / Isolation

git worktree を使った分離実行で、メインブランチに影響を与えずに並列タスクを走らせられる。エージェント呼び出し時に isolation: "worktree" を指定可能。

Background tasks

run_in_background 付きで Bash 実行すると、長時間タスクをバックグラウンド化できる。Monitor でログのストリーミング監視。

MCP（Model Context Protocol）

外部のツールサーバー（DB、Slack、Figma など）を MCP サーバーとして接続でき、Claude が直接呼び出せる。.mcp.json に定義。

Slash Commands（カスタム）

.claude/commands/*.md でプロジェクト固有のコマンドを定義可能。Skill よりも軽量、テンプレート的な使い方に向く。

Settings 階層

~/.claude/settings.json（個人）
<repo>/.claude/settings.json（プロジェクト共通、コミット）
<repo>/.claude/settings.local.json（個人ローカル、.gitignore）

キャッシュ最適化

プロンプトキャッシュは 5 分 TTL。短時間に繰り返し呼ぶワークロードは安く速くなる。逆に 5 分超え での待機はコストが膨らむので注意。

全体ベストプラクティスまとめ

「効く順」で導入する

CLAUDE.md を整備（最大の費用対効果）
.claude/settings.json の allowlist で permission prompt を減らす
Hooks で lint / format / 完了通知を自動化
Skills で定型作業をパッケージ化
マルチエージェント / Plugins / リモート は必要になってから

安全運用の三原則

🔒 権限は最小・段階的に：plan → default → acceptEdits → bypass の順に上げる
🔒 隔離環境で攻めた使い方：Docker / worktree / リモートサンドボックス
🔒 コミットは人間が確認：git commit の自動化はしても、push 前のレビューは残す

コスト・速度の三原則

⚡ タスク切替で /clear
⚡ 大きなファイルは Grep / 範囲 Read
⚡ 5 分以内ならキャッシュ温存、長く待つなら一気に

失敗パターンの早期発見

エージェントが同じツールを繰り返すようになったら無限ループの兆候 → 一度止める
「やりました」と言うが diff がない → 必ず git status / git diff で確認
要約後に話が噛み合わない → /compact の劣化、/clear ＋要点ファイル読み直しに切り替え

Claude Code はあくまで「優秀だが新人のチームメイト」です。CLAUDE.md で文化を共有し、Hooks でガードレールを敷き、Skills と Plugins で標準作業を整備することで、長期的に安定したパフォーマンスを引き出せます。逆に何も整備せず権限だけ広げると、便利さと裏腹に事故率が上がるので、上記のベストプラクティスを段階的に取り入れていくのがおすすめです。

Macディスクスペース確保操作

Mon, 27 Apr 2026 00:00:00 GMT

概要

Macのストレージは新しいバージョンのmacOSやアプリケーション更新により、気づかないうちに容量が逼迫することがあります。本記事では、Macでディスクスペースを確保するための調査方法と削減テクニック、開発環境固有の容量問題、そしてよくあるトラブルシューティングをまとめています。

ディスクスペースが逼迫する主な原因

1. 開発環境関連（最も容量消費しやすい）

Xcode キャッシュ&派生データ：DerivedDataが数GB～十数GBになることも
iOS DeviceSupport：複数バージョンのシミュレータサポートファイル
Gradle キャッシュ（Android開発）：.gradle/caches/ が数GB
Node.js（node_modules）：プロジェクトごとに数百MB～GB単位
pnpm/npm/yarn キャッシュ：パッケージマネージャの履歴
Docker イメージ&コンテナ：不要なイメージが蓄積
Python 仮想環境（venv, conda）：複数プロジェクトで重複

2. キャッシュファイル（見えにくい）

~/Library/Caches/：アプリケーション各種のキャッシュ
ブラウザキャッシュ（Chrome、Safari等）
システムキャッシュ

3. ログファイル（蓄積型）

~/Library/Logs/：アプリケーションログ
システムログ（/var/log/）
アプリケーション固有のログディレクトリ

4. Macあるあるな容量消費

Time Machine ローカルスナップショット：バックアップ容量
言語データ：Spotlightやシステムの多言語対応ファイル
システムキャッシュ（.DS_Store等）
一時ファイル（/tmp/, /var/tmp/）
古いバージョンのOSダウンロード（/Library/Updates/）

5. メディアとバックアップ

ダウンロードフォルダ：使い終わったファイルが残存
ゴミ箱：未削除ファイル
クラウドストレージのローカルキャッシュ（iCloud Drive等）

容量を調査するコマンド

ディスク全体の使用状況を確認

# 全体の概観を見る
df -h

# より詳細に見る
diskutil info /

大容量フォルダを特定（推奨）

# 1GB以上のフォルダを容量順で表示（デスクトップに結果を出力）
sudo du --si -xct 1000000000 /System/Volumes/Data | sort -nr | head -30

# より詳細：結果をファイルに保存
sudo du --si -xct 1000000000 /System/Volumes/Data | sort -nr > ~/Desktop/DiskSpace.txt

特定ディレクトリの容量を確認

# ホームディレクトリの直下のフォルダサイズ
du -sh ~/*

# Libraryディレクトリの直下
du -sh ~/Library/*

# より詳細（木構造で表示）
tree -h -L 2 ~/Library 2>/dev/null || find ~/Library -maxdepth 2 -type d | xargs du -sh | sort -hr | head -20

ローカルスナップショットのサイズ確認（Time Machine）

# Time Machine ローカルバックアップのサイズ確認
tmutil listlocalsnapshots /

開発環境関連の容量削減

1. Xcode キャッシュとシミュレータ

DerivedData の削除（数GB～20GB程度削減可能）

# まず容量を確認
du -sh ~/Library/Developer/Xcode/DerivedData

# 削除
rm -rf ~/Library/Developer/Xcode/DerivedData/*

iOS DeviceSupport の不要バージョン削除

# リスト表示
ls -lh ~/Library/Developer/Xcode/iOS\ DeviceSupport/

# 不要なバージョン（古いiOSバージョン）をフォルダごと削除
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/16.* # 例：iOS 16系を削除

シミュレータの利用不可デバイスを削除

# 利用可能なデバイスをリスト表示
xcrun simctl list devices

# 利用不可デバイスを自動削除（2～3GB削減可能）
xcrun simctl delete unavailable

Xcodeキャッシュの強制リセット

xcrun --kill-cache

2. Gradle キャッシュ（Android開発）

# Gradleキャッシュディレクトリの容量確認
du -sh ~/.gradle/caches/

# 削除
rm -rf ~/.gradle/caches/

# または、gradle コマンドで実行
cd /path/to/your/android/project
./gradlew cleanBuildCache

3. Node.js パッケージマネージャ

pnpm の不要キャッシュ削除

# ストア内の不要ファイル削除（推奨、安全）
pnpm store prune

# より詳細に確認
pnpm store status

npm キャッシュ削除

npm cache clean --force

yarn キャッシュ削除

yarn cache clean

node_modules の削除（開発中は注意、再インストール必要）

# 個別プロジェクト
cd /path/to/project
rm -rf node_modules/
pnpm install # または npm install / yarn install

# 複数プロジェクトを一括処理
find ~ -maxdepth 4 -name node_modules -type d -exec du -sh {} \; | sort -rh

4. Docker

# 使用していないイメージ、コンテナ、ネットワークを削除（推奨）
docker system prune -a

# より詳細な確認
docker system df

# 特定のイメージを削除
docker rmi <image_id>

# ダンgling imageだけ削除（安全）
docker image prune -a --filter "dangling=true"

5. Ollama（LLMモデル）

# ダウンロード済みモデルをリスト表示
ollama list

# 不要なモデルを削除（数GBまたは数十GB）
ollama rm <model_name>

# 例：Llama2 (7B) を削除
ollama rm llama2:7b

6. Python 仮想環境

# venv の容量確認
du -sh ~/.venv/
du -sh ./venv/

# 不要な仮想環境をまとめて削除
find ~ -maxdepth 3 -name "venv" -o -name ".venv" | xargs du -sh | sort -rh

# 削除
rm -rf ~/.venv/
rm -rf ./venv/

# conda の場合
conda clean --all -y

キャッシュとログの削減

Caches フォルダの削除

# 容量確認
du -sh ~/Library/Caches/

# 削除（注意：アプリの再ダウンロードが発生する可能性）
rm -rf ~/Library/Caches/*

# 安全な部分削除（Chromeキャッシュなど）
rm -rf ~/Library/Caches/Google/Chrome/Default/Cache/
rm -rf ~/Library/Caches/Firefox/

ブラウザキャッシュの削除

# Chrome
rm -rf ~/Library/Application\ Support/Google/Chrome/Default/Cache/
rm -rf ~/Library/Application\ Support/Google/Chrome/Default/Code\ Cache/

# Safari
rm -rf ~/Library/Safari/History.db*
rm -rf ~/Library/Caches/com.apple.Safari/

# Firefox
rm -rf ~/Library/Application\ Support/Firefox/Profiles/*/cache*/

ログファイルの削除

# ホームディレクトリ内のログ
du -sh ~/Library/Logs/
rm -rf ~/Library/Logs/*

# システムログ（rootが必要）
sudo du -sh /var/log/
sudo rm -rf /var/log/*.log  # 注意：ログが消える

一時ファイルの削除

# /tmp ディレクトリ
du -sh /tmp
rm -rf /tmp/*

# /var/tmp ディレクトリ
sudo du -sh /var/tmp
sudo rm -rf /var/tmp/*

Macあるあるな容量問題

1. Time Machine ローカルスナップショット

Macがバッテリー駆動で外付けドライブがない場合、自動的にローカルスナップショット（バックアップ）が作成されます。これが10GB～100GB近く占めることがあります。

# スナップショット確認
tmutil listlocalsnapshots /

# 最も古いスナップショットを削除
tmutil deletelocalsnapshots $(tmutil listlocalsnapshots / | head -1 | tr -d '.' | awk '{print $NF}')

# より安全：全スナップショット削除（要確認）
tmutil disablelocal  # ローカルスナップショット無効化

2. 言語データと絵文字

# Spotlightインデックス
du -sh ~/Library/Metadata/CoreSpotlight/

# システム言語ファイル
du -sh /Library/Components/

# 不要な言語リソースを削除する場合
# /System/Library/English.lproj/ など（リスク高）

3. .DS_Store ファイル

macOSが各フォルダに自動生成するメタデータ。単体は小さいが、蓄積するとGB単位に。

# すべての .DS_Store を検索・削除
find ~ -name ".DS_Store" -type f -delete

# または
sudo find / -name ".DS_Store" -type f -delete

4. ダウンロードフォルダの未整理

# ダウンロードフォルダの容量確認
du -sh ~/Downloads

# 30日以上前のファイルを確認
find ~/Downloads -mtime +30 -type f

5. ゴミ箱の未削除

# ゴミ箱の容量確認
du -sh ~/.Trash/

# 空にする
rm -rf ~/.Trash/*

6. iCloud Drive のローカルキャッシュ

# iCloud Driveのキャッシュ
du -sh ~/Library/Mobile\ Documents/

# 保存容量を最適化
# システム設定 > iCloud > iCloud Drive > オプション > 書類とデータ

7. アプリケーションの言語ファイル削除

# アプリの多言語サポートを削除（日本語のみ残す等）
# AppMaker等のツールを使用するか、手動で削除可能

便利なツール

GUI ツール

ツール	説明	価格
Disk Diag	ディスク容量を視覚的に表示、大容量ファイルを検出	無料/有料
CleanMyMac X	キャッシュ、ログ、不要ファイルの一括削除	有料（サブスク）
DaisyDisk	円形グラフでディスク使用状況を視覚化	有料
OmniDiskSweeper	シンプルで軽量、視覚的なディスク分析	無料
Finder の「ファイル情報」	標準機能でフォルダサイズを確認	無料

CLI ツール

ncdu（NCurses Disk Usage）

# インストール
brew install ncdu

# 使用例
ncdu ~
ncdu ~/Library

# ナビゲーション
# ↑↓：上下移動
# →：フォルダを開く
# ←：戻る
# d：削除
# q：終了

dust（より modern な du）

# インストール
brew install dust

# 使用例
dust ~/Library
dust -r ~/  # 逆順でソート

dirstat-rs（Rust 製）

# インストール
brew install dirstat-rs

# 使用例
dirstat ~/Library

duf（ディスク使用状況 CLI）

# インストール
brew install duf

# 使用例
duf        # マウント済みディスク全体
duf ~/     # ホームディレクトリ

ワンコマンドで実行できるスクリプト

安全な削減スクリプト

#!/bin/bash

echo "🧹 Macディスク容量削減スクリプト"
echo "================================"

# 現在の使用量
echo ""
echo "📊 削減前の使用量："
df -h | grep -E "disk|Filesystem"

# キャッシュ削除
echo ""
echo "🗑️  キャッシュを削除..."
rm -rf ~/Library/Caches/* 2>/dev/null
pnpm store prune 2>/dev/null
npm cache clean --force 2>/dev/null

# Xcode 関連
echo "🗑️  Xcode キャッシュを削除..."
rm -rf ~/Library/Developer/Xcode/DerivedData/* 2>/dev/null
xcrun simctl delete unavailable 2>/dev/null

# Docker
echo "🗑️  Docker イメージを削除..."
docker system prune -a -f 2>/dev/null

# ログ削除
echo "🗑️  ログファイルを削除..."
rm -rf ~/Library/Logs/* 2>/dev/null

# 結果表示
echo ""
echo "📊 削減後の使用量："
df -h | grep -E "disk|Filesystem"
echo ""
echo "✅ 完了！"

より詳細に容量を確認するスクリプト

#!/bin/bash

echo "🔍 Macディスク容量分析"
echo "===================="

DIRS=(
  "~/Library/Developer/Xcode/DerivedData"
  "~/Library/Caches"
  "~/Library/Logs"
  "~/.gradle/caches"
  "~/.docker"
  "~/Library/Mobile Documents"
  "~/.Trash"
  "~/Downloads"
)

for DIR in "${DIRS[@]}"; do
  EXPANDED=$(eval echo "$DIR")
  if [ -d "$EXPANDED" ]; then
    SIZE=$(du -sh "$EXPANDED" 2>/dev/null | awk '{print $1}')
    echo "$DIR: $SIZE"
  fi
done

削減時の注意点

削除しても安全なもの

✅ DerivedData（再構築される）
✅ キャッシュ（再生成される）
✅ 不要なDockerイメージ
✅ .DS_Store
✅ ローカルスナップショット（バックアップ必須時のみ）

削除に慎重なもの

⚠️ node_modules（再インストール必要）
⚠️ Python 仮想環境（再構築必要）
⚠️ システムログ（トラブル時に必要）
⚠️ iCloud Drive のキャッシュ（同期の遅延）

絶対に削除してはいけないもの

❌ /System（システムファイル）
❌ /Library/Fonts（フォント）
❌ 重要なプロジェクトファイル
❌ Time Machine の有効なバックアップ

まとめ

Macの容量逼迫は予防が重要です：

定期的に大容量フォルダを確認する習慣をつける
開発環境のキャッシュを定期的にクリアする
不要なアプリ、言語ファイルを削除する
Time Machine の設定を確認する
必要に応じて自動削減ツールを活用する

スクリプトを cronjob で定期実行させることで、容量問題をプロアクティブに解決できます。

脆弱性診断関連ツール種別サマリ

Mon, 13 Apr 2026 00:00:00 GMT

概要

脆弱性診断ツールは種類が多く、選定の時点で迷いやすいです。この記事では、まず全体像をつかみ、そのあとに実運用で使える比較と導入ステップまで一気に整理します。

想定読者とこの記事のゴール

本記事は、開発チームまたはSRE/セキュリティ担当として「脆弱性診断ツールをどう選び、どう運用に乗せるか」を短時間で判断したい読者を想定しています。

ゴールは次の3点です。

種別ごとの役割を誤解なく把握する
無料/有料を含む現実的な選択肢を比較する
明日から動ける導入ステップを決める

まず押さえる用語整理

似た言葉が多いため、最初にざっくり整理しておきます。

SAST: ソースコードを静的に解析し、実装上の問題を早期検出
DAST: 稼働中アプリにリクエストを送り、外部から見える脆弱性を検出
OAST: 外部コールバックを使い、Blind系（SSRF/XXE等）の検出を補完
SCA: OSS依存パッケージの脆弱性・ライセンスを把握
CSPM/KSPM/IaC Scan: クラウド設定やIaCのミスコンフィグを検出

実務上は「診断（検出）」と「防御（RASP/CNAPP/CWPPなど）」を分けて考えると、導入時の判断がしやすくなります。

まず全体像（種別一覧）

最初に、脆弱性診断の種別を一枚で把握します。ここを基準に、この後の比較表や導入パターンを見ていくと理解しやすいです。

ツール種別	略称＊SASTなど	診断対象・目的	代表ツール	その他備考
サーバー・OS・インフラ脆弱性診断	VMS / VM	OS・ミドルウェア・ネットワーク機器の既知脆弱性検出	Nessus, Qualys VMDR, OpenVAS	定期スキャンとパッチ管理の連携が重要
コンテナ・イメージスキャン	CIS	コンテナイメージ内のOS/ライブラリ脆弱性検出	Trivy, Grype, Clair	CI/CD組み込みでシフトレフトしやすい
Webアプリケーション動的診断	DAST	稼働中Webアプリへの疑似攻撃で脆弱性検出	OWASP ZAP, Burp Suite, Invicti	実行環境依存。認証付きテスト設計が鍵
Out-of-Bandアプリケーション診断	OAST	外部コールバックを利用し、Blind系脆弱性（SSRF/XXE/Command Injection等）を検出	Burp Collaborator, Interactsh	DASTやAPI診断と併用して検出率を高める
ソースコード静的解析	SAST	コード上の脆弱実装・危険パターン検出	SonarQube, Checkmarx, Semgrep	早期検出に有効。誤検知チューニングが必要
ソフトウェア・コンポジション解析	SCA	OSS依存関係の脆弱性・ライセンスリスク把握	Snyk, Dependabot, OWASP Dependency-Check	SBOM運用と相性が良い
クラウド設定ポスチャ管理	CSPM	クラウド設定ミス・過剰権限・準拠違反の検出	Prisma Cloud, Wiz, Orca Security	マルチクラウド統制に有効
インタラクティブ・アプリケーション診断	IAST	実行時のアプリ内部計測で脆弱性を高精度検出	Contrast Security, Seeker	DAST/SASTの中間的アプローチ
モバイルアプリ診断	MAST	モバイルアプリの静的/動的/逆コンパイル診断	MobSF, QARK, NowSecure	端末側保護や証明書ピンニング評価も対象
APIセキュリティ診断	APIST	API仕様・認可不備・ビジネスロジック欠陥検出	42Crunch, Salt Security, Burp Suite API Scan	OpenAPI連携で網羅性向上
外部アタックサーフェス管理	EASM	公開資産の棚卸し・露出リスク・設定不備の検出	Censys, Shodan, Randori	Shadow ITの可視化に有効
実行時アプリ自己防御	RASP	実行中アプリを監視し攻撃を検知・防御	Contrast Protect, Imperva RASP	防御寄り技術。診断と併用が一般的
クラウドネイティブ統合保護基盤	CNAPP	CSPM/CWPP/CIEM等を統合しクラウド全体を管理	Prisma Cloud, Wiz, Lacework	機能重複があるため導入時の整理が必要
クラウドワークロード保護	CWPP	VM/コンテナ/Kubernetes実行基盤の保護・検知	Aqua Security, Sysdig Secure, Prisma Cloud Compute	ランタイム保護中心
Kubernetes設定ポスチャ管理	KSPM	Kubernetesクラスタ設定不備・権限過多の検出	Kubescape, Checkov, kube-bench	Kubernetes特化。CSPMの補完として有効
Infrastructure as Code診断	IaC Scan	Terraform/CloudFormation等の設定不備を事前検出	Checkov, tfsec, Terrascan	デプロイ前検出で手戻り削減
シークレット検出	Secrets Scan	ソース/履歴内のAPIキー・資格情報漏えい検出	Gitleaks, TruffleHog, GitHub Secret Scanning	インシデント予防の即効性が高い

ツール選定マップ（Mermaid）

次に、よく使う種別と代表ツールの関係をマップで俯瞰します。無料/有料/推奨を色で見分けられるようにしています。

flowchart LR
    A[脆弱性診断種別]
    A --> SAST[SAST]
    A --> DAST[DAST]
    A --> OAST[OAST]
    A --> SCA[SCA]
    A --> CSPM[CSPM]
    A --> APIST[APIST]
    A --> CIS[CIS]
    A --> SECRET[Secrets Scan]

    SAST --> Semgrep[Semgrep]
    SAST --> SonarQube[SonarQube]
    DAST --> ZAP[OWASP ZAP]
    DAST --> Burp[Burp Suite]
    OAST --> Interactsh[Interactsh]
    OAST --> Collaborator[Burp Collaborator]
    SCA --> Dependabot[Dependabot]
    SCA --> Snyk[Snyk]
    CSPM --> Prowler[Prowler]
    CSPM --> Wiz[Wiz]
    APIST --> APIFuzz[APIFuzzer]
    APIST --> Crunch[42Crunch]
    CIS --> Trivy[Trivy]
    CIS --> Grype[Grype]
    SECRET --> Gitleaks[Gitleaks]
    SECRET --> GHSecret[GitHub Secret Scanning]

    class Semgrep,ZAP,Interactsh,Dependabot,Prowler,APIFuzz,Trivy,Grype,Gitleaks free;
    class SonarQube,Burp,Collaborator,Snyk,Wiz,Crunch,GHSecret paid;
    class Semgrep,ZAP,Trivy,Gitleaks,Dependabot recommended;

    classDef free fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
    classDef paid fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
    classDef recommended fill:#fffde7,stroke:#f9a825,stroke-width:3px,color:#5d4037;

色の意味: 緑=無料中心、青=有料中心、黄枠=推奨（導入しやすさ/実績ベース）

有料・無料と推奨の一覧（実務向け）

マップで全体感をつかんだあと、実際の選定に使えるように有料/無料と推奨候補を表で整理します。

ツール種別	略称	無料候補	有料候補	推奨（まず使う候補）	その他備考
サーバー・OS・インフラ脆弱性診断	VMS / VM	OpenVAS	Nessus, Qualys VMDR	Nessus（商用）/ OpenVAS（OSS）	エージェント運用の有無を先に決める
コンテナ・イメージスキャン	CIS	Trivy, Grype	Prisma Cloud Compute, Snyk Container	Trivy	CIへの組込みが容易
Webアプリケーション動的診断	DAST	OWASP ZAP	Burp Suite Pro, Invicti	ZAP + Burp Suite（併用）	自動と手動の併用が有効
Out-of-Bandアプリケーション診断	OAST	Interactsh	Burp Collaborator	Interactsh（OSS）	Blind系検出でDAST補完
ソースコード静的解析	SAST	Semgrep CE	Checkmarx, SonarQube Server	Semgrep CE	ルール調整で誤検知抑制
ソフトウェア・コンポジション解析	SCA	OWASP Dependency-Check, Dependabot	Snyk, Mend	Dependabot + Dependency-Check	SBOM連携しやすい
クラウド設定ポスチャ管理	CSPM	Prowler, ScoutSuite	Wiz, Prisma Cloud, Orca	Wiz（商用）/ Prowler（OSS）	マルチクラウド対応を要確認
インタラクティブ・アプリケーション診断	IAST	（選択肢少）	Contrast, Seeker	Contrast	APM連携や性能影響を確認
モバイルアプリ診断	MAST	MobSF	NowSecure	MobSF	まずは静的診断から開始
APIセキュリティ診断	APIST	OWASP ZAP API Scan, APIFuzzer	42Crunch, Salt Security	ZAP API Scan	OpenAPI定義の整備が前提
外部アタックサーフェス管理	EASM	Shodan（限定無料）, Amass	Censys, Randori	Censys（商用）/ Amass（OSS）	資産棚卸しプロセスとセット運用
実行時アプリ自己防御	RASP	（選択肢少）	Contrast Protect, Imperva RASP	Contrast Protect	防御系で運用チーム連携が必要
クラウドネイティブ統合保護基盤	CNAPP	（実質なし）	Wiz, Prisma Cloud, Lacework	Wiz	単一製品へ寄せると運用しやすい
クラウドワークロード保護	CWPP	Falco（検知寄り）	Aqua, Sysdig Secure	Sysdig Secure	ランタイム監視設計が重要
Kubernetes設定ポスチャ管理	KSPM	Kubescape, kube-bench	Prisma Cloud, Wiz	Kubescape	Admission制御との併用推奨
Infrastructure as Code診断	IaC Scan	Checkov, tfsec, Terrascan	Snyk IaC	Checkov	PR時の自動チェック推奨
シークレット検出	Secrets Scan	Gitleaks, TruffleHog	GitHub Advanced Security	Gitleaks	pre-commit導入が効果的

ツール選定の判断軸

製品比較は機能の多さだけでなく、運用に乗るかどうかで評価するのが重要です。最低限、以下の軸で比較することを推奨します。

判断軸	見るポイント
検出カバレッジ	想定脅威（Web/API/クラウド/依存関係）をどこまでカバーできるか
精度	誤検知/見逃しのバランス、チューニング容易性
開発体験	CI/CD連携、PRコメント連携、実行時間
運用コスト	初期設定、ルール整備、日次トリアージ負荷
組織適合	監査要件、マルチクラウド、責任分界との整合

組織規模別の導入パターン

1. 小規模チーム（まずは低コストで開始）

Semgrep（SAST）
Trivy（コンテナ/CIS）
Gitleaks（Secrets）
Dependabot（SCA）
必要に応じて OWASP ZAP（DAST）

まずは「PRで検出し、重大項目だけブロック」を目標にします。

2. 中規模チーム（OSS + 商用のハイブリッド）

OSSで日常スキャン（Semgrep/Trivy/Gitleaks）
商用で可視化や高度分析（Burp Suite Pro, Wiz, Snykなど）
DAST + OAST（ZAP + Interactsh/Burp Collaborator）を併用

検出の幅と運用効率のバランスを取りやすい構成です。

3. 大規模組織（統合基盤でガバナンス強化）

CNAPP を中核に CSPM/CWPP/KSPM を統合
開発側に SAST/SCA/Secrets を標準組込み
監査向けレポートとSLA運用をセットで定義

「全体可視化」と「現場の改善サイクル」を分断しないことが成功の鍵です。

CI/CDへの最小実装例（GitHub Actions）

最初の一歩として、PR時に SAST + SCA + Secrets + Container を実行する構成が現実的です。

name: security-minimum
on:
  pull_request:
  push:
    branches: [main]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Semgrep (SAST)
        uses: returntocorp/semgrep-action@v1

      - name: Trivy (Container/FS)
        uses: aquasecurity/trivy-action@0.24.0
        with:
          scan-type: "fs"
          scan-ref: "."
          severity: "CRITICAL,HIGH"

      - name: Gitleaks (Secrets)
        uses: gitleaks/gitleaks-action@v2

      - name: Dependency Check (SCA)
        uses: dependency-check/Dependency-Check_Action@main
        with:
          project: "sample"
          path: "."
          format: "HTML"

ポイントは、最初から完璧を目指さず、重大度で閾値を決めて段階的に厳格化することです。

運用ルール（導入後に効く項目）

ツール導入よりも、トリアージ運用の設計が成果を左右します。最低限、以下を決めておくと運用が安定します。

重大度ごとの対応期限（例: Criticalは48時間以内）
誰が一次トリアージするか（開発/セキュリティの責任分界）
誤検知のクローズ基準と再発防止の記録方法
例外承認フロー（期限付き、承認者明記）
月次での再発傾向レビュー

よくある失敗と回避策

ツールを増やしすぎて誰も見なくなる
-> 最初は4種類程度に絞る（SAST/SCA/Secrets/Container）
検出はするが直らない
-> SLAと担当を定義し、未対応を可視化する
誤検知が多く開発体験を壊す
-> ルールを棚卸しし、ノイズの高い検知は調整する
本番運用前にCI時間が肥大化する
-> PR時と夜間バッチでジョブを分割する

30/60/90日ロードマップ

期間	目標	実施内容
30日	可視化開始	Semgrep/Trivy/Gitleaks/DependabotをCIへ導入し、重大項目を把握
60日	運用定着	トリアージ手順、SLA、例外承認フローを文書化して運用
90日	統制強化	DAST/OASTやCSPMを追加し、クラウド/アプリ横断で継続改善

参考フレームワーク

判断根拠を揃えるため、以下のフレームワークを参照すると実務で説明しやすくなります。

OWASP ASVS
OWASP SAMM
NIST SSDF

まとめ

脆弱性診断ツールの導入は「どの製品を入れるか」だけでなく、「どの順で、誰が、どう回すか」で成果が大きく変わります。まずは小さく始めて、SAST/SCA/Secrets/Container を確実に運用し、次に DAST/OAST や CSPM へ広げる進め方が現実的です。

SSO連携について

Mon, 13 Apr 2026 00:00:00 GMT

概要

SSO（Single Sign-On）は、1回の認証で複数システムにアクセスできる仕組みです。
「SSO連携」と一口に言っても、利用するプロトコルやトークンの扱いによって実装パターンが大きく変わります。

この記事では、実務でよく使われるSSO連携の実装種別を整理し、各方式の動きと実装観点を図付きでまとめます。

SSO連携の実装種別

代表的な実装種別は次の4つです。

SAML 2.0ベースSSO
OpenID Connect（OIDC）ベースSSO
OAuth 2.0（認可委譲）を中心にした疑似SSO
ゲートウェイ／リバースプロキシ型SSO

補足: 近年の新規開発ではOIDCが中心ですが、企業システムではSAMLが現役のケースも多く、ハイブリッド運用も一般的です。

各実装種別ごとの具体的な内容

1) SAML 2.0ベースSSO

SAMLの方式概要

ブラウザリダイレクトとXMLアサーションを使って認証結果を連携
IdP（Identity Provider） が認証し、SP（Service Provider） が受け入れる
企業内業務システムやSaaS連携で現在も広く利用

sequenceDiagram
    participant U as User
    participant SP as Service Provider
    participant IdP as Identity Provider

    U->>SP: サービスへアクセス
    SP-->>U: IdPへリダイレクト（AuthnRequest）
    U->>IdP: ログイン
    IdP-->>U: SAMLResponse（署名付き）をPOST
    U->>SP: SAMLResponseを送信
    SP->>SP: 署名検証・属性マッピング
    SP-->>U: セッション発行

SAML実装のポイント

メタデータ交換: IdP/SP間で証明書・エンドポイントを事前共有
署名検証: SAMLResponseの署名検証は必須
属性マッピング: NameID や属性をアプリのユーザー情報へ対応付け
セッション管理: SP側セッションの有効期限と再認証条件を設計

SAMLが向いているケース

既存の企業基盤（ADFS, Shibboleth など）との連携
既存SaaS連携がSAML中心の組織

2) OpenID Connect（OIDC）ベースSSO

OIDCの方式概要

OAuth 2.0を拡張し、IDトークン（JWT） で認証情報を表現
Web/SPA/モバイルなどモダンなアプリ実装と相性が良い
Authorization Code Flow + PKCE が現在の推奨

sequenceDiagram
    participant U as User
    participant C as Client App
    participant OP as OIDC Provider
    participant API as Resource API

    U->>C: ログイン要求
    C-->>U: OPへリダイレクト（認可要求）
    U->>OP: 認証
    OP-->>C: 認可コード
    C->>OP: コード交換（+PKCE）
    OP-->>C: IDトークン + Accessトークン
    C->>API: Accessトークン付きAPI呼び出し
    API-->>C: レスポンス

OIDC実装のポイント

フロー選定: サーバーサイド/SPAで適切なフローを選ぶ
トークン検証: 署名、iss、aud、exp の検証を徹底
PKCE対応: 公開クライアント（SPA/モバイル）では必須
リフレッシュ戦略: セキュアな保管と失効設計が重要

OIDCが向いているケース

新規開発のWebアプリ、モバイルアプリ、API中心アーキテクチャ
Keycloak、Auth0、Entra IDなどモダンIdP利用時

3) OAuth 2.0中心の疑似SSO

OAuth中心方式の概要

OAuthは本来「認可」の仕様であり、認証そのものの標準はOIDCが担う
ただし実務では「同じ認可サーバーのトークンで複数APIを呼ぶ」ことで、体感的なSSOを実現するケースがある

flowchart LR
    U[User] --> FE[Frontend]
    FE --> AS[Authorization Server]
    AS -->|Access Token| FE
    FE --> API1[API A]
    FE --> API2[API B]
    FE --> API3[API C]

OAuth中心方式の実装ポイント

認証と認可の分離理解: ログイン要件はOIDC併用で満たす
スコープ設計: API単位の権限境界を明確化
トークン寿命: 短命化と更新制御で漏えいリスクを低減

OAuth中心方式の注意点

OAuth単独では「ユーザーが誰か」を標準化して表現しづらい
「SSOを実装したつもり」になる落とし穴があるため、要件定義で認証責務を明確にする

4) ゲートウェイ／リバースプロキシ型SSO

ゲートウェイ型の方式概要

アプリの手前に認証ゲートウェイを置き、認証を共通化する方式
各アプリはゲートウェイから渡されるヘッダやクレームを信頼して利用
レガシーアプリを短期間でSSO配下に入れたい時に有効

flowchart TB
    U[User] --> GW[Auth Gateway / Reverse Proxy]
    GW --> IdP[Identity Provider]
    GW --> APP1[Legacy App]
    GW --> APP2[Internal Tool]
    GW --> APP3[Admin Console]

ゲートウェイ型の実装ポイント

信頼境界の明確化: ヘッダ偽装防止（内部NW限定、mTLS等）
アプリ改修最小化: 既存アプリ側は最小限のユーザー受け渡し対応
監査ログ: ゲートウェイで統一的に認証/アクセスログを取得

ゲートウェイ型が向いているケース

レガシー資産が多く、アプリ個別改修コストを抑えたい
認証統制を入口で一元管理したい

実装選定の観点（簡易比較）

観点	SAML	OIDC	OAuth中心	ゲートウェイ型
主な用途	企業連携/既存SaaS	新規Web/SPA/モバイル	API認可中心	レガシー統合
実装難易度	中	中	中	中〜高
モダン開発との相性	低〜中	高	中	中
認証標準としての明確さ	高	高	低（単独では不足）	構成依存

まとめ

SSO連携は「どのプロトコルを使うか」だけでなく、認証責務をどこで担保するかを決める設計です。
新規開発ではOIDCが第一候補になりやすく、既存環境ではSAMLやゲートウェイ型との併用が現実的です。

最終的には、次の3点で選ぶと失敗しにくくなります。

利用中のIdP・既存資産との親和性
対象アプリ（Web/SPA/モバイル/レガシー）の実装特性
監査・運用（失効、ログ、障害時切り戻し）まで含めた運用設計

flutter JIT エラーで実機デバッグができなくなったことについて

Mon, 16 Mar 2026 00:00:00 GMT

概要

flutter開発をしていて、突然実機デバッグビルドができなくなったのでエラーを調査したことについて記載

💻 環境

Flutter: 3.29.0 (fvm)
OS: macOS Tahoe
IDE: Cursor
実機iPhone: 26.3.1
xCode: 26.3

❌ エラー内容

Launching lib/main.dart on iPhone in debug mode...
Automatically signing iOS for device deployment using specified development team in Xcode project: xxxxxxxx
Xcode build done.                                           83.3s
You may be prompted to give access to control Xcode. Flutter uses Xcode to run your app. If access is not allowed, you can change this through your Settings > Privacy & Security > Automation.
version=3.7.2 (stable) (Tue Mar 11 04:27:50 2025 -0700) on "ios_arm64"
pid=81547, thread=259, isolate_group=vm-isolate(0x1056e1400), isolate=vm-isolate(0x105ccd000)
os=ios, arch=arm64, comp=no, sim=no
isolate_instructions=1071d75a0, vm_instructions=1071d75a0
fp=16d2a9050, sp=16d2a9030, pc=107c2f624
  pc 0x0000000107c2f624 fp 0x000000016d2a9050 Dart_DumpNativeStackTrace+0x18
  pc 0x00000001077ddbc8 fp 0x000000016d2a9070 dart::Assert::Fail(char const*, ...) const+0x30
  pc 0x00000001078d8adc fp 0x000000016d2a9520 dart::Code::FinalizeCode(dart::FlowGraphCompiler*, dart::compiler::Assembler*, dart::Code::PoolAttachment, bool, dart::CodeStatistics*)+0x82c
  pc 0x0000000107966450 fp 0x000000016d2a9b30 dart::StubCode::Init()+0x320
  pc 0x0000000107828c94 fp 0x000000016d2aa5e0 dart::Dart::DartInit(Dart_InitializeParams const*)+0x2b18
  pc 0x0000000107c15ef4 fp 0x000000016d2aaa60 Dart_Initialize+0x60
  pc 0x000000010779e5c4 fp 0x000000016d2ab030 flutter::DartVM::Create(flutter::Settings const&, fml::RefPtr<flutter::DartSnapshot const>, fml::RefPtr<flutter::DartSnapshot const>, std::_fl::shared_ptr<flutter::IsolateNameServer>)+0x1d64
  pc 0x00000001076fa73c fp 0x000000016d2ab790 flutter::Shell::Create(flutter::PlatformData const&, flutter::TaskRunners const&, flutter::Settings, std::_fl::function<std::_fl::unique_ptr<flutter::PlatformView, std::_fl::default_delete<flutter::PlatformView>> (flutter::Shell&)> const&, std::_fl::function<std::_fl::unique_ptr<flutter::Rasterizer, std::_fl::default_delete<flutter::Rasterizer>> (flutter::Shell&)> const&, bool)+0x310
  pc 0x00000001071e6564 fp 0x000000016d2ac520 -[FlutterEngine createShell:libraryURI:initialRoute:]+0xa8c
  pc 0x0000000107218e64 fp 0x000000016d2ac580 -[FlutterViewController sharedSetupWithProject:initialRoute:]+0x198
  pc 0x0000000107218ca4 fp 0x000000016d2ac5b0 -[FlutterViewController awakeFromNib]+0x6c
  pc 0x000000019c255374 fp 0x000000016d2aca80 <redacted>+0x6dc
  pc 0x000000019c82b61c fp 0x000000016d2acaf0 <redacted>+0xec
  pc 0x000000019c82b4f4 fp 0x000000016d2acb20 <redacted>+0x50
  pc 0x000000019c6893e4 fp 0x000000016d2acb80 <redacted>+0x8c
  pc 0x000000019b3f8a68 fp 0x000000016d2acbc0 <redacted>+0xa8
  pc 0x000000019c688908 fp 0x000000016d2acdb0 <redacted>+0x280
  pc 0x000000019bc91ea4 fp 0x000000016d2acde0 <redacted>+0x74
  pc 0x000000019b33de94 fp 0x000000016d2ace30 _UIScenePerformActionsWithLifecycleActionMask+0x70
  pc 0x000000019bc92720 fp 0x000000016d2acef0 <redacted>+0xfc
  pc 0x000000019bc9222c fp 0x000000016d2acf60 <redacted>+0xd4
  pc 0x000000019bc92538 fp 0x000000016d2ad070 <redacted>+0x260
  pc 0x000000019bc91fc4 fp 0x000000016d2ad0e0 <redacted>+0xf4
  pc 0x000000019bc9d444 fp 0x000000016d2ad120 <redacted>+0x94
  pc 0x000000019c10fcec fp 0x000000016d2ad220 <redacted>+0x2e0
  pc 0x000000019b33ecac fp 0x000000016d2ad290 _UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion+0xe0
  pc 0x000000019bc9d140 fp 0x000000016d2ad390 <redacted>+0x13c
  pc 0x000000019badc3b4 fp 0x000000016d2ad4e0 <redacted>+0x268
  pc 0x000000019badb448 fp 0x000000016d2ad650 <redacted>+0xd0
  pc 0x000000019badc020 fp 0x000000016d2ad710 <redacted>+0xf4
  pc 0x000000019c687968 fp 0x000000016d2ad7d0 <redacted>+0x1dc
  pc 0x000000019c138adc fp 0x000000016d2ad860 <redacted>+0x120
  pc 0x00000001b5a00388 fp 0x000000016d2ada10 <redacted>+0x16c
  pc 0x00000001b5a00840 fp 0x000000016d2ada50 <redacted>+0x80
  pc 0x00000001b5a001a0 fp 0x000000016d2adb20 <redacted>+0x1b4
  pc 0x00000001b5a6eb34 fp 0x000000016d2adbe0 <redacted>+0x120
  pc 0x00000001b5a0df00 fp 0x000000016d2adc20 <redacted>+0xa8
  pc 0x00000001b5a2ad98 fp 0x000000016d2add70 <redacted>+0x1e0
  pc 0x00000001b5a2c6fc fp 0x000000016d2ade00 <redacted>+0x10c
  pc 0x00000001b5a0df00 fp 0x000000016d2ade40 <redacted>+0xa8
  pc 0x00000001041c62e0 fp 0x000000016d2ade50 _dispatch_client_callout+0x10
  pc 0x00000001041b0998 fp 0x000000016d2adea0 _dispatch_block_invoke_direct+0x128
  pc 0x00000001ad0f41d4 fp 0x000000016d2aded0 <redacted>+0x34
  pc 0x00000001ad0f4054 fp 0x000000016d2adf50 <redacted>+0xe0
  pc 0x0000000195973f10 fp 0x000000016d2adf60 <redacted>+0x1c
  pc 0x0000000195973e84 fp 0x000000016d2adf90 <redacted>+0xac
  pc 0x0000000195951b30 fp 0x000000016d2adff0 <redacted>+0x14c
  pc 0x00000001959286d8 fp 0x000000016d2aed50 <redacted>+0x334
  pc 0x0000000195927a6c fp 0x000000016d2aede0 <redacted>+0x214
  pc 0x000000023753c498 fp 0x000000016d2aee30 GSEventRunModal+0x78
  pc 0x000000019b302df8 fp 0x000000016d2aeeb0 <redacted>+0x318
  pc 0x000000019b2abe54 fp 0x000000016d2aef40 UIApplicationMain+0x150
  pc 0x000000019b3d7820 fp 0x000000016d2aef80 <redacted>+0x24c
  pc 0x0000000103a6882c fp 0x000000016d2aefd0 $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ+0x78
  pc 0x0000000103a687a4 fp 0x000000016d2af000 $s6Runner11AppDelegateC5$mainyyFZ+0x2c
  pc 0x0000000103a688a8 fp 0x000000016d2af020 __debug_main_executable_dylib_entry_point+0x1c
  pc 0x000000019293ae28 fp 0x000000016d2af690 <redacted>+0x1bcc
-- End of DumpStackTrace
=== Crash occurred when compiling unknown function in unoptimized JIT mode in unknown pass
════════════════════════════════════════════════════════════════════════════════
A change to iOS has caused a temporary break in Flutter's debug mode on
physical devices.
See https://github.com/flutter/flutter/issues/163984 for details.

In the meantime, we recommend these temporary workarounds:

* When developing with a physical device, use one running iOS 18.3 or lower.
* Use a simulator for development rather than a physical device.
* If you must use a device updated to iOS 26.2.1 23C71, use Flutter's release or
  profile mode via --release or --profile flags.
════════════════════════════════════════════════════════════════════════════════
=== Flow Graph not available

Exited (1).

🛠 解決方法

flutterバージョンアップ

# こちらにアップ
flutter --version
# Flutter 3.41.4 • channel stable • https://github.com/flutter/flutter.git
# Framework • revision ff37bef603 (12 days ago) • 2026-03-03 16:03:22 -0800
# Engine • hash 99578ad0355da00edb26301c874a3c250a5716f5 (revision e4b8dca3f1) (11 days ago) • 2026-03-03 18:24:54.000Z
# Tools • Dart 3.11.1 • DevTools 2.54.1

環境初期化

端末内のアプリを削除しておく
プロジェクトはflutter clean、flutter pub getからやり直す

IDE(vscode/launch.json)経由ではうまく行かない

IDEでいつも起動しているところからProfileモードで起動してもうまく行かなかった
コマンドラインから立ち上げることでうまく立ち上がることを確認

flutter run --profile -d <device-id>

あとがき

セキュリティ上の理由とのことだが少し不便

デバッグはSimulatorで実施するべしとのこと

参考

flutter fvm 設定について

Mon, 16 Mar 2026 00:00:00 GMT

概要

fvmのセットアップ方法をまとめます。

# インストール
brew tap leoafarias/fvm
brew install fvm

# flutter install
# インストールできるリストを確認
fvm releases

# インストール
fvm stable
fvm 3.41.4

# インストールされているリストを確認
fvm list

# 環境変数設定
echo -e "\n# FVM Global Flutter Path\nexport PATH=\"\$HOME/fvm/default/bin\":\"\$PATH\"" >> ~/.zshrc
source ~/.zshrc

# バージョン確認
flutter --version

プロジェクトローカルで指定する方法

# プロジェクトローカルで指定
fvm use <使用したいバージョン>
# 作成されるファイル) .fvm/fvm_config.json

# 他メンバが開いたときに指定されたバージョンのインストール
fvm install

IDE側でSDK設定
- vscodeの場合（.vscode/settings.json）
- 以下の設定を追加して認識させること

{
  "dart.flutterSdkPath": ".fvm/flutter_sdk",
  "search.exclude": {
    "**/.fvm": true
  },
  "files.exclude": {
    "**/.fvm": true
  }
}

gitignoreでsdkファイルは除外すること

# FVM
.fvm/flutter_sdk

でも、プロジェクトごとにsdkを置くのはディスク容量取るのであまりやりたくない

That's all!

Git に誤ってプッシュしたセンシティブデータを完全削除する方法

Mon, 16 Mar 2026 00:00:00 GMT

概要

APIキー、パスワード、秘密鍵などのセンシティブな情報を誤って Git リポジトリにコミット・プッシュしてしまった場合、単純に git rm してコミットするだけでは不十分です。Git の履歴にはすべての変更が記録されているため、過去のコミットを辿れば誰でも削除したつもりのファイルを参照できてしまいます。

この記事では、GitLab および GitHub から該当ファイルの履歴を物理的に削除する手順を解説します。

まず最初にやること 作業を始める前に、流出したクレデンシャルを今すぐ無効化・ローテーションしてください。削除作業中もそのクレデンシャルは有効なままです。完全な削除が完了するまでの間も攻撃者がアクセスできる状態が続きます。

GitLab 編

1. ツールのインストール

履歴書き換えには git-filter-repo を使用します。Git 公式も推奨しているツールで、旧来の git filter-branch より安全かつ高速です。

pip install git-filter-repo

2. ミラークローンで全履歴を取得

git clone --mirror <リポジトリの URL>
cd <リポジトリ名>.git

ミラークローンとは？

通常の git clone はデフォルトブランチのみを取得しますが、--mirror オプションを付けるとすべてのブランチ・タグ・refs を含む完全なコピーが取得されます。作業ディレクトリは作成されず、.git の中身がそのままフォルダに展開された状態（ベアリポジトリ）になります。

履歴の書き換えはすべてのブランチに一括で適用する必要があるため、ミラークローンが必要です。

3. 対象ファイルの履歴を削除

git filter-repo --path <削除対象ファイルのパス> --invert-paths

--path : 対象ファイルのパスを指定します（例: config/secrets.yml、src/.env）
--invert-paths : 指定したパス以外を残す、つまり指定したファイルをすべての履歴から取り除く、という意味です

複数ファイルを一度に削除したい場合は --path を並べます：

git filter-repo --path config/secrets.yml --path .env --invert-paths

実行後、すべてのコミット履歴からそのファイルが取り除かれます。

4. GitLab のプロテクトブランチを一時解除

強制プッシュ（force push）は通常、保護されたブランチへは禁止されています。GitLab の管理画面から一時的に解除します。

GitLab のリポジトリページを開く
Settings > Repository > Protected branches に移動
main、develop などの保護ブランチを Unprotect にする

作業終了後は必ず保護設定を元に戻してください。

5. リモートの登録と強制プッシュ

ミラークローンした状態ではリモートが未設定のため、まず追加します：

git remote add origin <リポジトリの URL>

すべてのブランチとタグを強制プッシュします：

# 全ブランチの強制プッシュ
git push origin --force --all

# 全タグの強制プッシュ
git push origin --force --tags

強制プッシュが必要な理由

通常のプッシュはリモートの履歴に対して追記のみが許可されています。今回は履歴を書き換えているため、リモートとローカルの履歴が矛盾します。--force を使うことでリモートの履歴を上書きします。

6. プロテクトブランチの保護設定を復旧

手順 4 で Unprotect したブランチを元の設定に戻します。

Settings > Repository > Protected branches から再設定してください。

7. GitLab 上の物理削除（ハウスキーピング）

強制プッシュでリモートから参照は外れますが、GitLab のサーバー上にはキャッシュや内部オブジェクトが残っている場合があります。ハウスキーピングを実行して物理的にデータを削除します。

GitLab のリポジトリページを開く
Settings > General > Advanced に移動
Housekeeping（ハウスキーピング） を実行

GitLab.com（SaaS）の場合、完全な物理削除にはサポートへの問い合わせが必要になるケースもあります。セルフホスト版では管理者が git gc --prune=now を実行することでも対応できます。

8. 削除確認

対象ファイルへの古いコミットのパーマリンク URL にアクセスし、404 エラーが返ることを確認します。

例：

https://gitlab.com/<namespace>/<repo>/-/blob/<古いcommit hash>/<削除対象ファイルのパス>

404 が返れば、GitLab 上からは閲覧不可能になっています。

GitHub 編

基本的な手順は GitLab と同様ですが、いくつか差異があります。

1〜3. ツールインストール・ミラークローン・履歴削除

GitLab と完全に同じ手順です。

pip install git-filter-repo
git clone --mirror <リポジトリの URL>
cd <リポジトリ名>.git
git filter-repo --path <削除対象ファイルのパス> --invert-paths

4. GitHub のブランチ保護ルールを一時解除

GitHub のリポジトリページを開く
Settings > Branches に移動
Branch protection rules の対象ブランチ（main など）の Edit をクリック
Require a pull request before merging などのルールを一時的に無効化するか、または Allow force pushes を有効にする

5. 強制プッシュ

git remote add origin <リポジトリの URL>
git push origin --force --all
git push origin --force --tags

6. ブランチ保護ルールの復旧

手順 4 で変更した設定を元に戻します。

7. GitHub のキャッシュ削除

GitHub 側のキャッシュやフォークには古いデータが残っている可能性があります。

キャッシュのクリア: GitHub サポートへ問い合わせることで、サーバー側のキャッシュを削除してもらえます。
フォークの扱い: フォークしているリポジトリには書き換えが反映されないため、フォーク先でも同様の作業が必要です。フォーク一覧は Settings > Danger Zone から確認できます。

GitHub には Secret scanning 機能があり、プッシュされたシークレットを自動検出してアラートを出してくれます。流出したシークレットのローテーションと合わせて活用してください。

チームメンバーへの周知とローカル環境の復旧

これが非常に重要です。 書き換えた履歴を他のメンバーがそのまま git push すると、削除したはずの履歴が復活してしまいます。必ずチーム全員に作業完了を通知し、ローカル環境を更新してもらってください。

絶対禁止: 作業完了前後に既存のローカルリポジトリから git push しないこと 古い履歴を持ったまま push すると、削除した情報が再びリモートに載ってしまいます。

未プッシュの変更がない人

一番シンプルなケースです。既存のフォルダを削除して再クローンするだけです。

# 既存のフォルダを削除
rm -rf <リポジトリのフォルダ>

# 再クローン
git clone <リポジトリの URL>

未プッシュの変更がある人

作業中の変更をパッチファイルに退避してから再クローンします。

# ステップ1: 現在の差分をパッチファイルに書き出す
git diff > my.patch

# ステップ2: ステージ済みの変更も含める場合
git diff --cached >> my.patch

# ステップ3: 既存フォルダを削除して再クローン
rm -rf <リポジトリのフォルダ>
git clone <リポジトリの URL>
cd <リポジトリのフォルダ>

# ステップ4: パッチを適用して変更を復元
git apply my.patch

ブランチも含めた変更がある場合は、git bundle を使うとより安全に移行できます。

まとめ・チェックリスト

ステップ	内容
✅ 0	流出したクレデンシャルを今すぐ無効化・ローテーション
✅ 1	`git-filter-repo` のインストール
✅ 2	ミラークローンで全履歴取得
✅ 3	`--invert-paths` で対象ファイルを履歴から削除
✅ 4	ブランチ保護の一時解除
✅ 5	`--force --all` と `--force --tags` で強制プッシュ
✅ 6	ブランチ保護の復旧
✅ 7	ハウスキーピング（物理削除）
✅ 8	古い URL が 404 になることを確認
✅ 9	チームメンバーへ周知・ローカル環境を再クローン

そもそも防ぐためには .gitignore の徹底や git-secrets などのプリコミットフックの導入が有効です。「消す方法」を知ることも大事ですが、「プッシュしない仕組み」を先に整えることを強くお勧めします。

That's all!

rbenvの設定方法について

Fri, 13 Mar 2026 00:00:00 GMT

概要

flutter開発していて、以下の構成で進めていたが、cocoapodsが不安定になってきたので、gemfileのバージョン固定に乗り換えるためにrbenvの設定方法についてまとめます。

元々の構成

ツール	管理
rbenv	brew
ruby	brew
cocoapods	brew

Gemfile構成

ツール	管理
rbenv	brew
ruby	rbenv/Gemfile
cocoapods	rbenv/Gemfile

fastlaneなどを動かす場合は、同じくGemfileでバージョン固定するのが良さそう

1. Homebrewでrbenvをインストール

まずはパッケージマネージャーのHomebrewを使って、rbenvと、Rubyのビルドに必要なruby-buildをインストールします。

brew update
brew install rbenv ruby-build

2. シェルの設定（パスを通す）

インストールしただけではrbenvは動きません。お使いのシェル（多くの場合はZsh）の設定ファイルに、rbenvを初期化する記述を追加します。

echo 'eval "$(rbenv init -)" ' >> ~/.zshrc
source ~/.zshrc

Note: Bashを使っている場合は ~/.zshrc を ~/.bash_profile に読み替えてください。

3. Ruby 4.0.1 のインストール

次に、目的のバージョンをインストールします。

# インストール可能なリストを更新
brew upgrade ruby-build

# 4.0.1 がリストにあるか確認
rbenv install -l | grep 4.0.1

# インストール実行
rbenv install 4.0.1

4. バージョンの切り替え

インストールが終わったら、PC全体（global）で使うバージョンを4.0.1に固定します。

rbenv global 4.0.1

# 反映を確認
ruby -v

よくあるトラブルと解決策

「4.0.1が見つからない」と言われる場合: brew upgrade ruby-build を実行して、rbenvが最新のRubyを知っている状態にしてください。
ビルドエラーが出る場合: Xcode Command Line Toolsが必要です。xcode-select --install を実行してから再度試してみてください。

Ruby 4.0.1の準備が整いましたね！次に、プロジェクトでライブラリ（Gem）を管理するための Gemfile を作成しましょう。

最も一般的で「作法」に則った方法は、Bundler というツールを使う方法です。

ここからはGemfileのセットアップ

1. Bundlerをインストールする

Ruby 4.0系であれば標準で含まれていることが多いですが、念のため最新をインストールします。

gem install bundler

2. Gemfileを自動生成する

プロジェクトのルートディレクトリ（作業フォルダ）に移動して、以下のコマンドを叩きます。

bundle init

これだけで、カレントディレクトリに Gemfile という名前のファイルが作成されます。

3. Gemfileの中身を編集する

生成された Gemfile をテキストエディタで開き、必要なライブラリを記述します。

# frozen_string_literal: true

source "https://rubygems.org"

# 使用するRubyのバージョンを指定（チーム開発で役立ちます）
ruby "4.0.1"

# インストールしたいGemをここに書く
gem "rails"
gem "sqlite3"

4. ライブラリをインストールする

記述が終わったら、ターミナルで以下のコマンドを実行します。

bundle install

これにより、Gemのインストールと同時に Gemfile.lock というファイルが生成されます。これは「どのバージョンのGemをインストールしたか」を正確に記録する重要なファイルです。

Gemfile管理のイメージ

Gemfileは「注文書」、Gemfile.lockは「納品書（確定版）」のような関係です。

GoogleCalendarイベント追加リンク作成方法

Wed, 25 Feb 2026 00:00:00 GMT

概要

GoogleCalendarイベントをリンクから作成する方法についてまとめます。

作成方法参考

https://github.com/InteractionDesignFoundation/add-event-to-calendar-docs/blob/main/services/google.md

パラメータ解説

ドメイン / いづれかを利用
- https://calendar.google.com/calendar/render
- https://calendar.google.com/calendar/r/eventedit
  - こっちはactionパラメータが不要

# TEMPLATE のみしか指定できない
action=TEMPLATE

# タイトル
text=hogeTitle 

# 日付
dates=20201231T193000Z/20201231T223000Z

# タイムゾーン
ctz=America/New_York

# 詳細
details=With clowns and stuff

# 場所
location=North Pole

# 他、パラメータは割愛

サンプルURL

https://calendar.google.com/calendar/u/0/r/eventedit?text=Birthday&dates=20201231T193000Z/20201231T223000Z&details=With+clowns+and+stuff&location=North+Pole

Markdownファイルをリアルタイムで編集する方法

Wed, 25 Feb 2026 00:00:00 GMT

概要

Markdown編集の管理方法について

VSCode Extension

Markdown Editor

https://marketplace.cursorapi.com/items/?itemName=zaaack.markdown-editor
拡張機能でWYSIWYGが実現できるエディタ

Tools

MarkText

https://github.com/marktext/marktext
brew経由だとインストール後に起動できないことを確認しました。
以下より直接インストールすることで動作確認ができました。
- https://github.com/marktext/marktext?tab=readme-ov-file#download-and-installation

ローカルLLM実践入門

Thu, 17 Apr 2025 00:00:00 GMT

基本情報

価格：2530円（本体2300円）　発行・発売日：2024年12月23日

◆自宅のパソコンで「CharGPT」のようなチャットAIサービスを動かす方法がわかります！

◆最初はGUIの操作だけで動かす方法を紹介するので、ローカルLLMがはじめてでも安心！

◆ローカルLLMをPythonのプログラムに組み込む方法がわかります！

◆ローカルLLMが生成した文章を「ずんだもん」に読み上げさせる方法がわかります！

◆ローカルLLMを快適に動かすためのパソコンを自作できます！

　「ChatGPT」のようなチャットAIサービスを手元のパソコンで動かす環境が整いつつあります。チャットAIサービスの頭脳とも呼ぶべき「LLM」（大規模言語モデル）が多数、公開されるようになったからです。本書では、これら公開されているLLMを手元のパソコンで動かし、活用する方法を解説しています。
　活用の手段として、本書では主にPythonのプログラムを利用しています。そう聞くと「Pythonのプログラマー向けか？」と思われるかもしれません。ご安心ください。本書はPythonを使ったことのない人でもローカルLLMを活用できるよう、Pythonの実行環境の導入方法なども含めて丁寧に解説しています。
　一つだけ注意点があります。現状は高性能なパソコンでなければ、ローカルLLMを快適には動かせないことです。特に高性能なグラフィックス機能を搭載しないパソコンでは、処理が終わるのに数十分も待たされたり、正しく動作しなかったりします。
　本書は7つの章で構成しています。第1章でローカルLLMの概要を解説した後、第2章以降で、実際に手元のパソコンでローカルLLMを動かす方法を解説しています。本書の解説とおりに手を動かしながら読み進めることで、ローカルLLMの動く仕組みと基本的な使い方、さらには活用法までを理解できる構成になっています。

【目次】

第1章　ローカルLLM［大規模言語モデル］の概要
　「LLM」には「クラウド型」と「ローカル型」があることを解説し、「ローカル型」のLLMである「ローカルLLM」を手元のパソコンで動かすのに必要なソフトウエアを紹介しています。

第2章　ローカルLLMをサクッと使える　ChatGPT風ツール「Jan」
　ローカルLLMを動かすためのソフトウエアとして「Jan」を紹介します。インストールから設定、利用まで、すべてGUIの操作だけで済むので、ローカルLLMがはじめてでも簡単に動かすことができます。

第3章　ローカルLLMを活用できる　コマンドラインツール「Ollama」
　ローカルLLMを動かすのに、コマンドラインを利用するソフトウエアとして「Ollama」を紹介します。基本的な使い方だけでなく、「LLMサーバー」として使う方法と、Pythonのプログラムに組み込んで使う方法も簡単に紹介しています。

第4章　ローカルLLMを活用（その1）　画像の内容を説明
　第4章から第6章は、主にローカルLLMをPythonのプログラムに組み込んで活用する方法を紹介します。第4章では、画像を読み込んで説明文を生成できる「マルチモーダル対応のLLM」を使う方法を紹介します。

第5章　ローカルLLMを活用（その2）　コードの作成を支援
　米Microsoftの「Visual Studio Code」などのテキストエディタにローカルLLMを組み込み、コードの作成を支援してもらう方法を解説します。実際に解説とおりに試すと、生成したコードを修正しなくても正常に動作することがわかります。

第6章　ローカルLLMを活用（その3）　LLM の回答を読み上げる
　ローカルLLMと音声読み上げライブラリ「「VOICEVOX CORE」を組み合わせ、ローカルLLMが生成した文章を、人気の読み上げキャラクターである「ずんだもん」の声で読み上げる方法を解説します。

第7章　ローカルLLMが快適に使える　最適なパソコンを自作しよう
　ローカルLLMが快適に動かせるパソコンのスペックと、お勧めのPCパーツを紹介します。パソコンの自作がはじめてでも、PCパーツの選び方や購入先などがわかります。

　なお、本書は第3章を除き、以下の日経BPが発行する専門誌の掲載記事を加筆修正する形で掲載しています。
第1章　日経ソフトウエア　2024年9月号　特集1
第2章　日経ソフトウエア　2024年9月号　特集1
第4章　日経ソフトウエア　2024年9月号　特集1
第5章　日経ソフトウエア　2025年1月号　特集1
第6章　日経ソフトウエア　2025年1月号　特集1
第7章　日経PC21　2024年12月号　特集

はじめに

OpenAI が ChatGPT を公開したのは2022年11月のこと
生成AI：会話、ストーリー、画像、動画、音楽などの新しいコンテンツやアイデアを生み出すことのできる AI の一種
LLM(大規模言語モデル)：文書を生成するAIの中核となる技術
GoogleやMetaが高性能なLLMモデルを公開し始めたのでローカル環境で高性能なLLMを利用することができるようになった

✅ GoogleやMetaが自社LLMを公開した理由まとめ

目的	説明
技術の普及	研究・教育・技術開発の加速。オープンなAI開発を促進。
ブランド強化	技術力のアピールや人材獲得。業界内での存在感を示す。
利用データ取得	実利用によるフィードバックでモデルを改善。偏りやバグの発見も可能。
エコシステム構築	他社に使わせて囲い込み。自社クラウドやプラットフォームの利用促進。
コスト削減	開発リソースを分散し、他者の改良を取り込むことで効率的に改善。
社会的責任	透明性の確保や規制対応。オープンにすることで責任あるAI開発を推進。

第1章　ローカルLLM［大規模言語モデル］の概要

「LLM」には「クラウド型」と「ローカル型」があることを解説し、「ローカル型」のLLMである「ローカルLLM」を手元のパソコンで動かすのに必要なソフトウエアを紹介しています。

ローカルLLMの一種
- MicrosoftCopilot
- Apple Intelligence
  - 情報漏洩の心配もなし
  - 従量課金の心配もなし
Pythonライブラリを利用すればWebUIも簡単に実装可能
- Chainlit
- Streamlit
AIチャットボットも構築可能
- Transforms
- Langchain
ローカルLLMのカスタマイズ
- RAG
- ファインチューニング

1.2 ローカルLLMに必要なファイル

必要なファイルは２つ
- LLMファイル
  - インターネット上にある膨大なデータを学習したモデルファイル
  - ChatGPTのようなクラウド型のAIはクローズド型
  - インターネット公開されているものはオープン型のLLMファイル
    - HuggingFaceのModelsのウェブページから入手可能
    - https://huggingface.co/models
      - ファイルはGB単位で、一般的にサイズが大きいほど高性能なLLM
      - 日本語に強いLLMがあったり色々
    - LLM選択のポイント
      - gguf形式であること
      - パラメータ数
      - 量子化のビット数
        
        量子化・標本化について：https://joho-taisaku.com/sampling/
    - まとめ
      - パラメータ数と量子化のビット数が多いほど高性能なLLMだが、代わりにファイルサイズも巨大になるので、動かすには高性能なパソコンを用意しなければならない
      - 性能の低いパソコンをでLLMを動かしたいのであれば、パラメータ数と量子化ビット数が少ないLLMを選ぶ
    - LLM選定の３つのポイントはファイル名に含まれている
      - ELYZA-japanese-Llama-2-7b-q4_0.gguf
      - 7b:70億パラメータを示す billion
      - q4:量子化ビット数は4bitを示す、qはquantization(量子化)の略
      - gguf:ファイル形式
- LLMプラットフォームのソフトウェア
  - LLM実行環境と呼ばれるもの
  - 例）
    - Jan
    - Ollama
    - llama.cpp
    - Text-generation-webui
    - Backyard AI
    - LM Studio
    - NVIDIA ChatRTX
    - AI Toolkit for VS Code
  - これらのソフトでダウンロードしたLLMファイルを動かすことが可能

第2章　ローカルLLMをサクッと使える　ChatGPT風ツール「Jan」

ローカルLLMを動かすためのソフトウエアとして「Jan」を紹介します。インストールから設定、利用まで、すべてGUIの操作だけで済むので、ローカルLLMがはじめてでも簡単に動かすことができます。

2.1 ChatGPT風ツール「Jan」を導入する

Jan: ローカル環境で大規模言語モデル（LLM）を簡単に実行できるオープンソースのプラットフォーム
- 👋のマークのLLMプラットフォーム
- たぶん、Janは人名でよく使われる名称で親しみを込めて命名されたのでは？という説
ここからインストール
- https://jan.ai
開くといろんなLLMモデルが表示されるが、タグがついていないのが、現在のマシンで推奨されるモデル
Llama 3.2 1B Instruct Q8
- 8bit量子化
- 10億パラメータ

2.2 Llama 3.2 とのチャットAIを試す

前提
- Fugakuはスペック不足でインストールできなかったので、Llamaで試す
Jan起動
適当なChatを実施する
左下のサーバーボタンを選択し、StartServerでサーバ起動

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:1337/v1", api_key="dummy")

completion = client.chat.completions.create(
  # model="Fugaku-LLM-13B-instruct-Q4_0.gguf",
  # model="meta-llama/Llama-3.2-1B",
  model="llama3.2:1b",
  messages=[
    {"role": "system", 
     "content": "あなたは親切なアシスタントです。"},
    {"role": "user", 
     "content": "プログラミング言語を二つに分類すると、何と何になりますか？"}
  ])

print(completion.choices[0].message.content)

tempelatureの値を0に設定すると毎回ほぼ同じ解答になる
- ばらつきを示す
- 0.7がばらんすの取れた値とされている

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:1337/v1", api_key="dummy")

completion = client.chat.completions.create(
  temperature=0,
  # model="Fugaku-LLM-13B-instruct-Q4_0.gguf",
  # model="meta-llama/Llama-3.2-1B",
  model="llama3.2:1b",
  messages=[
    {"role": "system", 
     "content": "あなたは親切なアシスタントです。"},
    {"role": "user", 
     "content": "プログラミング言語を二つに分類すると、何と何になりますか？"}
  ])

print(completion.choices[0].message.content)

別PCからアクセス可能にするために、Server起動時に127.0.0.1のループバックアドレスではなく、0.0.0.0を指定する

Pythonダウンロードと設定

brew install python@3
python3 -m venv ~/mypy
source ~/mypy/bin/activate
pip3 install openai
deactivate

2.5 チャットAIのWebサイトを構築

PythonのOSSWebUIライブラリの「Chainlit」を使ってWebサイト構築
- Vscodeをインストール
- pip install chainlit
以下実行

from openai import AsyncOpenAI
import chainlit as cl

client = AsyncOpenAI(base_url="http://127.0.0.1:1337/v1", api_key="dummy")

@cl.on_message
async def on_message(input):
  completion = await client.chat.completions.create(
    # model="Fugaku-LLM-13B-instruct-Q4_0.gguf",
    model="llama3.2:1b",
    messages=[
      {"role": "system", 
       "content": "あなたは親切なアシスタントです。"},
      {"role": "user", 
       "content": input.content}])

  await cl.Message(content=completion.choices[0].message.content).send()

返答が少しずつ表示されるように改修

from openai import AsyncOpenAI
import chainlit as cl

client = AsyncOpenAI(base_url="http://127.0.0.1:1337/v1", api_key="dummy")

@cl.on_chat_start   # チャット開始時に実行される関数
def start_chat():
  # ユーザーセッションの変数"history"を設定する
  cl.user_session.set("history",
    [{"role": "system",   # "history"の初期値
      "content": "あなたは親切なアシスタントです。"}])

@cl.on_message   # ユーザーが質問文を送信したときに実行される関数
async def main(input):   # ユーザーの質問文は引数inputに格納される
  message = cl.Message(content="")   # メッセージを作成
  await message.send()               # メッセージを送信
  
  # ユーザーセッションの変数"history"を取得
  history = cl.user_session.get("history")
  # "history"にユーザーの質問文を追加
  history.append({"role": "user", "content": input.content})

  # LLMに変数"history"の内容を送る
  stream = await client.chat.completions.create(
    # model="Fugaku-LLM-13B-instruct-Q4_0.gguf",
    model="llama3.2:1b",
    messages=history, 
    stream=True)   # ストリーミングをオンにする

  # LLMの返答を1トークンずつ表示
  async for part in stream:
    token = part.choices[0].delta.content
    if token != "":
      await message.stream_token(token)

  # "history"にLLMの返答を追加
  history.append({"role": "assistant", "content": message.content})
  await message.update()

休題

ローカルLMMを手軽に試すには？
- ローカルLMMのスマホアプリ
  - 例
    - PocketPal
    - PricateLLM
    - LLM Farm

第3章　ローカルLLMを活用できる　コマンドラインツール「Ollama」

ローカルLLMを動かすのに、コマンドラインを利用するソフトウエアとして「Ollama」を紹介します。基本的な使い方だけでなく、「LLMサーバー」として使う方法と、Pythonのプログラムに組み込んで使う方法も簡単に紹介しています。

3.1 Ollamaの概要

OllamaはJanと同じく、LLMプラットフォームで、ローカル環境でLLMを実行するためのOSSの１つ
- データが外部に送信されない
- オフラインでも実行可能
- 大規模言語モデルの推論を高速に実行するためのOSSライブラリである「llama.cpp」を実行基盤としている
- そのため、llama.cppで実行できる、「GGUF」形式のファイルをサポートしている
  - 「.safetensors」や「.pth」などのモデルファイル形式には対応していない

3.2 Ollamaのインストール

Windowsの場合
- https://ollama.com/download
- こちらからインストール
Macの場合
- homebrewでインストール可能
- brew install --cask ollama
- 以下のコマンドを追加実行すると最新化できる
  - brew upgrade --cask ollama
  - pkill ollama
  - open -a Ollama
  - ollama --version

3.3 Ollamaの使い方

ollama pullコマンドでモデル（LLMファイル）をダウンロードできる
- ダウンロード済みのモデルをアップデートするときにも使う
ollama runコマンドを実行することで動作させる

# モデル名を指定してダウンロード
ollama pull llama3.2
# ダウンロード済みのモデル自一項
ollama run llama2.3
# 正常に実行完了すると >>> で入力受付になるので対話形式で動かしてみる
# 対話形式で実行中に /? でヘルプ表示をすることも可能
# /bye で実行中のollama runコマンドを終了できる
# /load <model> でモデルを切り替えることができる

量子化でサイズを小さくしているモデルについての説明

3.4 Ollamaを深く知ろう

発展的な使い方
- Ollamaのローカルサーバーにリクエストを送信する
- PythonのプログラムからOllamaを実行する
１）Ollaamaのローカルサーバーにリクエスト送信
- Ollamaを起動している間はローカルサーバー（JanのLLMサーバと同じ）が立ち上がっている
- ollama serve
- すでに立ち上がっていたらエラーが返る
  - Error: listen tcp 127.0.0.1:11434: bind: address already in use

# HTTP送信
curl http://localhost:11434/api/generate -d '{"model": "llama3.2", "prompt": "こんにちは"}'
# デフォルトだとStream形式で表示される

# Streamオフ
curl http://localhost:11434/api/generate -d '{"model": "llama3.2", "prompt": "こんにちは","stream": false}'

PythonのプログラムからOllamaを実行する
Ollamaインストール
pip install ollama

from ollama import Client
import json

client = Client()
response = client.chat(
    model="llama3.2", messages=[{"role": "user", "content": "こんにちは"}]
)

response = response.model_dump()
print(json.dumps(response, indent=2, ensure_ascii=False))

休題：　Llamaのポート番号について

11434 は、LlamaのLeetであると言われている
Leetとは：類似の文字や読みの同じ文字を別の文字に置き換えて表現すること
- 有名なところだと toやforを、2や4に置き換えて表現するもの

第4章　ローカルLLMを活用（その1）　画像の内容を説明

第4章から第6章は、主にローカルLLMをPythonのプログラムに組み込んで活用する方法を紹介します。第4章では、画像を読み込んで説明文を生成できる「マルチモーダル対応のLLM」を使う方法を紹介します。

4.1 画像を読み込んで説明する

LLMの中には文章だけではなく、画像も解釈できるものがあるいわゆる「マルチモーダル」に対応するLLM

例えば）
- llava-llama-3-8b-v1_1-ggufがそれに当たる
画像読み込んで処理させる説明は省略

第5章　ローカルLLMを活用（その2）　コードの作成を支援

米Microsoftの「Visual Studio Code」などのテキストエディタにローカルLLMを組み込み、コードの作成を支援してもらう方法を解説します。実際に解説とおりに試すと、生成したコードを修正しなくても正常に動作することがわかります。

5.1 VSCodeの拡張機能「Continue」

ContinueはVSCodeにAI支援を追加する拡張機能
流れ
- VS Codeインストール：割愛
- OllamaとGemma2 2Bを導入
  - Googleが公開している「Gemma 2 2B」とGemma 2 2Bにコード生成させるためのソフトウェアである「Ollama」を導入
  - ollama pull gemma2:2b
  - ollama run gemma2:2b
- Python導入：割愛
- Continueを導入
  - http://localhost:11434/にアクセスしてOllama is running と表示されるかどうかを確認
  - VSCodeのプラグイン検索：Continue

5.2 MacOSとLinuxで使えるZedエディタ

Zed: AI支援機能付きのエディタ

5.3 コマンドプロンプトで使える「Aider」

コマンドプロンプトで対話しながら、LLMにプログラムの作成を依頼できるPythonで作られたツール

第6章　ローカルLLMを活用（その3）　LLM の回答を読み上げる

ローカルLLMと音声読み上げライブラリ「「VOICEVOX CORE」を組み合わせ、ローカルLLMが生成した文章を、人気の読み上げキャラクターである「ずんだもん」の声で読み上げる方法を解説します。

第7章　ローカルLLMが快適に使える　最適なパソコンを自作しよう

ローカルLLMが快適に動かせるパソコンのスペックと、お勧めのPCパーツを紹介します。パソコンの自作がはじめてでも、PCパーツの選び方や購入先などがわかります。

LLM動作環境の自作PC構成例について

2026-04_認証と認可 Keycloak入門第2版

Thu, 17 Apr 2025 00:00:00 GMT

基本情報

Keycloak（キークローク）は、Webベースのシステムに認証と認可の機能を組み込むOSS（オープンソースソフトウェア）です。セキュリティ事件が相次ぐ今、認証・認可は必須技術です。「第２版」は、WildFlyからQuarkusへ刷新されたオープンソースのセキュリティの仕組み「Keycloak（キークローク）」の新アーキテクチャを詳解する日本初の書籍です。 本書では、豊富な機能を備えるKeycloakについて、前提となる認証と認可の仕組みを基礎から解説し、典型的なユースケースの実現方法や本番システムへの実装方法まで詳しく解説しました。前提知識の部分も説明が少なかったログアウト等も補足しました。 最新技術に対応した実践的な内容で、ソフトウェア技術者必読の一冊です！

第1章 Keycloakを理解するための第一歩
- 1.1 認証と認可およびKeycloakの概要
- 1.2 Keycloakの動作要件とディレクトリー構成
- 1.3 Keycloakのセットアップと動作確認
- 1.4 本章のまとめ
第2章 OAuthとOIDCの基礎知識
- 2.1 OAuthのフロー
- 2.2 アクセストークンとリフレッシュトークン
- 2.3 トークンの無効化と認可判断
- 2.4 OIDCのフロー
- 2.5 本章のまとめ
第3章 SSOの基礎知識
- 3.1 SSOを理解する
- 3.2 標準プロトコルによるSSO
- 3.3 本章のまとめ
第4章 Keycloakの基礎を理解する
- 4.1 Keycloakの用語解説
- 4.2 セッションとトークンの設定
- 4.3 Keycloakの情報源
- 4.4 本章のまとめ

認証認可について
- Authenticationを略して、AuthN
- Authorizationを略して、AuthZ
- と呼ばれることがあるらしい
KeyCloakは IAM(Identity and Access Management) のソフトウェア
- IAM: 適切な人やマシンが適切なリソースに適切な理由のため適切なタイミングでアクセスできるようにするもの
  - *ガートナー社定義
- IAMの中でも、「認証と認可」を担っている
- IAMで認証・認可以外に重要な機能
  - IDライフサイクル管理: 入社/異動/退職に合わせてアカウントと権限を自動で付与・変更・剥奪する（JML: Joiner/Mover/Leaver）
  - ユーザー/組織情報の統合: 人事DBやディレクトリ（LDAP/AD）と連携し、ID情報を一元管理する
  - 特権アクセス管理（PAM）: 管理者アカウントの利用を最小化し、払い出し・記録・承認を厳格化する
  - 監査ログと追跡性: 「誰が・いつ・どの権限で・何をしたか」を証跡として残し、監査に対応する
  - セルフサービスと運用効率化: パスワードリセット、アクセス申請、承認フローをユーザー主導で回せるようにする
- IAMで押さえるべき実務ポイント
  - 最小権限の原則: 初期権限は必要最小限にし、ロール設計は職務ベース（RBAC）を基本にする
  - 権限の定期レビュー: 付与しっぱなしを防ぐため、棚卸し（アクセスレビュー）を定期実施する
  - 職務分掌（SoD）違反の防止: 申請と承認を同一人物に集中させないなど、統制ルールを設ける
  - 可用性と災害対策: IAM停止が業務停止に直結するため、冗長化・バックアップ・復旧手順を準備する
  - 法令/規制対応: 個人情報保護や各種ガイドラインに合わせ、保持期間やマスキング方針を明確化する

KeyCloakの中のIAM機能

区分	KeyCloakでできること	代表的な機能例
ID管理（Identity Management）	ユーザー、グループ、ロール、属性の管理。LDAP/Active Directory連携。	ユーザー属性管理、グループベース割当、LDAP Federation
認証（Authentication）	ログイン/ログアウト、セッション管理、MFA、パスワードポリシー、認証フローのカスタマイズ。	Browser Flow、OTP、条件付き認証
認可（Authorization）	RBAC、クライアントスコープ、ポリシーベース認可。	Authorization Services（Resource/Scope/Policy）
フェデレーションとSSO	OIDC/SAMLによるSSO、外部IdP連携、SLO。	Identity Brokering、Google/Azure AD連携
トークンとセッション制御	Access/Refresh/IDトークンの発行・更新・失効、有効期限設定。	Token Lifespan設定、Revocation、Offline Session
監査・運用管理	認証イベント/管理イベントログ、管理コンソール、Admin API、Realm分離。	Event Logs、Admin REST API、マルチRealm運用

KeyCloakの守備範囲外（または単体では不足しやすい）IAM機能

機能領域	概要	KeyCloak単体での扱い	代表的な製品/サービス例
特権アクセス管理（PAM）	管理者IDの貸与、記録、セッション統制、緊急アクセス管理。	直接の中核機能は弱い。外部PAM連携が一般的。	CyberArk、BeyondTrust、Delinea、HashiCorp Boundary
IGA（IDガバナンス/ライフサイクル）	入社/異動/退職（JML）、申請承認、アクセスレビュー、SoD統制。	ワークフロー/統制機能は限定的。外部IGAが必要になりやすい。	SailPoint、Saviynt、Omada、Microsoft Entra ID Governance
権限申請・承認ワークフロー	業務ロール申請、上長承認、期限付き付与、自動剥奪。	標準で本格的な承認ワークフローは薄い。	ServiceNow、SailPoint、Saviynt
SIEM/SOC連携による高度監視	横断ログ分析、相関検知、脅威ハンティング、インシデント対応。	イベント出力は可能だが、分析基盤は別途必要。	Splunk、Microsoft Sentinel、Elastic Security、IBM QRadar
非人間ID（Workload/Secrets）管理	サービスアカウント、マシンID、秘密情報ローテーション。	一部対応は可能だが、Secrets管理は専用製品が適する。	HashiCorp Vault、AWS Secrets Manager、Azure Key Vault
ゼロトラスト文脈制御（ZTNA）	端末状態・ネットワーク文脈を加味したアクセス制御。	認証基盤としては連携可能だが、ZTNA自体は範囲外。	Zscaler、Cloudflare Zero Trust、Netskope

KeyCloakアーキテクチャの変換点

timeline
    title Keycloakの歴史（主要マイルストーン）
    2013-07 : GitHubで初公開
            : Red Hat/JBossコミュニティ主導で開発が進展
    2022 : Keycloak 17.0.0
         : WildFlyベースからQuarkusベースへ大規模刷新
         : クラウドネイティブ対応を強化
    2023-04 : CNCF Incubatingプロジェクトとして承認

Web情報ベースで追加で押さえるポイント

観点	押さえるポイント	実務でのアクション
最新リリース追従	Keycloakは継続的にリリースされ、セキュリティ修正（CVE対応）が頻繁に入る。	四半期ごとにリリースノートを確認し、計画的にアップデートする。
Quarkus前提の運用	Keycloak 17以降はQuarkusディストリビューションが前提。WildFly時代と設定/運用手順が異なる。	新規構築はQuarkus前提で設計し、移行時は公式Migrationガイドを必ず確認する。
Kubernetes運用	Keycloak OperatorでKubernetes/OpenShift運用が可能。	Operator導入時はCRDベース運用を採用し、設定は宣言的に管理する。
アップグレード統制	Operatorの自動更新は意図しないバージョン更新やDBマイグレーションを招く可能性がある。	本番は手動承認で更新し、事前にステージングでマイグレーション検証を行う。
CNCFエコシステム連携	CNCF Incubatingとして、クラウドネイティブ運用との親和性が高い。	監視（Prometheus）、トレース、GitOpsなど周辺基盤との統合を前提に構成する。

Quarkusについて

Quarkusは、コンテナー/Kubernetes環境を前提に最適化されたJavaフレームワーク。特に「起動の速さ」「省メモリ」「運用しやすさ」を重視しており、クラウドネイティブなJava実行基盤として採用が進んでいる。 Keycloakもバージョン17以降でQuarkusベースに移行し、従来のWildFlyベースより軽量で予測可能な運用がしやすくなった。

Quarkusの主な特徴
- 高速起動: 開発時のホットリロードと本番時の短時間起動
- 省メモリ: コンテナー密度を上げやすい
- Kubernetes親和性: 設定・ヘルスチェック・メトリクス連携がしやすい
- JVMモード/Native Imageモード: 要件に応じて実行形態を選択可能

Javaフレームワーク比較（歴代含む）

フレームワーク/世代	主な時代感	強み	注意点・向いている用途
Java EE / Jakarta EE（仕様）	2000年代〜現在	エンタープライズ標準、仕様ベースで移植性が高い	実装製品への理解が必要。大規模業務システム向け
WildFly	2013年〜現在	Java EE/Jakarta EE準拠の実装。高い拡張性と豊富な運用機能	設定や運用が複雑になりやすい。従来型/大規模システム向き。最新のクラウドネイティブ用途はQuarkus推奨
Struts（1/2）	2000年代前半〜中盤	当時のMVC Web開発を普及	現代的な開発体験や保守性で不利。新規採用は限定的
Spring Framework（MVC中心）	2000年代中盤〜	DI/AOPで柔軟、エコシステムが巨大	設定自由度が高く設計ルールがないと複雑化しやすい
Play Framework	2010年代〜	非同期I/O、軽快なWeb開発体験	採用母数はSpring系より小さい
Dropwizard	2010年代〜	シンプルなREST API構築、運用部品がまとまっている	機能拡張の幅はSpring Bootより狭め
Micronaut	2018年〜	低メモリ・高速起動、DIをコンパイル時に解決	周辺エコシステムはSpringより小さめ
Helidon（SE/MP）	2018年〜	MicroProfile対応、軽量マイクロサービス向け	採用事例は限定的で情報量が少なめ
Spring Boot	2014年〜現在	実績・情報量・ライブラリ連携が非常に豊富	デフォルト運用でメモリ消費が大きくなりやすい
Quarkus	2019年〜現在	起動速度・省メモリ・Kubernetes親和性、Native Image対応	Native化時は制約確認が必要。クラウドネイティブ用途に強い

補足: 実務では「既存資産の多さならSpring Boot」「軽量・高速起動重視ならQuarkus/Micronaut」を軸に比較するケースが多い。

トークン検証について

以下の２通りがある
- ローカルでのトークン検証
  - https://www.jwt.io/ja/librariesに対応する言語とのライブラリーが紹介されている
- トークンイントロスペクション

admin-cli

各Realmには admin-cliクライアントが作成される
- このクライアントを使ってKeyCloakのAdminRESTAPIを呼び出せる

KeyCloakコミュニティー

公式な最新情報
- KeyCloak公式Webサイトのブログ
  - https://keycloak.org/blog
- KeyCloakのXアカウント
  - https://x.com/keycloak
質問をしたい
- Slack
  - https://slack.cncf.io/
    - keycloak,#keycloak-devチャネル
- Discourse
  - https://keycloak.discourse.group/
- GitHub Disscussions
  - https://github.com/keycloak/keycloak/discussions
- メーリングリスト
  - ユーザー向け；https://groups.google.com/g/keycloak.user/
  - 開発者向け：https://groups.google.com/g/keycloak.dev/
    - Slackなどが出てきてあまり活発でなくなった
これらについては公式ページにも案内あり、その時の最新は公式から取得する必要あり
- Questions and help: https://www.keycloak.org/community
バグ報告や機能追加リクエストをしたい
- Issueを作成する
コードやドキュメントの開発に貢献したい
- Contributionガイドを確認しPullRequestを提出
最新の標準仕様の開発に携わりたい
- https://github.com/keycloak/keycloak-oauth-sig/tree/main
ユーザーや開発者と交流したい
- https://community.cncf.io/cloud-native-security-japan/
- https://www.keycloak.org/community

実践編

実際の3つのユースケースを題材に基本的な使い方と設定方法をマスターしよう

第5章 OAuthに従ったAPI認可の実現
- 5.1 API認可を実現する環境の構築
- 5.2 認可コードフローによるアクセストークン取得
- 5.3 API呼び出し時の認可判断とスコープの設定
- 5.4 トークンのリフレッシュと無効化
- 5.5 OAuth/OIDCのセキュリティー確保
- 5.6 API認可で重要なKeycloakの利用方法
- 5.7 本章のまとめ
第6章 SSOを実現する
- 6.1 本章で取り扱うユースケース
- 6.2 Spring Securityを用いた認証連携
- 6.3 リバースプロキシーを用いた認証連携
- 6.4 JavaScriptアダプターを用いた認証連携
- 6.5 SSOとSLOの動作確認
- 6.6 その他のSSOの動向と概略
- 6.7 本章のまとめ
第7章さまざまな認証方式を用いる
- 7.1 認証の強化
- 7.2 外部ユーザーストレージによる認証
- 7.3 外部アイデンティティープロバイダーによる認証
- 7.4 本章のまとめ

認証方式についての情報

この部分についての公式ページ
- https://www.keycloak.org/docs/latest/server_admin/index.html
KeyCloakではOTPやパスキー認証が可能
認証フローの概要
- Executionと呼ばれる個々の認証処理を組み合わせて構成
認証フロートその構成の考え方
- 認証フロー要件（Requirement）の種類
  - Required（必須）
    - フロー内の Required 要素は、順番にすべて成功する必要がある
    - 必須要素のいずれかが失敗した時点で、そのフローは終了する
  - Alternative（代替）
    - フローが成功と判定されるには、Alternative 要素のうち1つが成功すればよい
    - ただし同じフロー内に Required 要素がある場合、Required だけで成功条件を満たすため、Alternative は実行されない
  - Disabled（無効）
    - その要素は、フロー成功判定の対象にならない
  - Conditional（条件付き）
    - この要件タイプはサブフローにのみ設定できる
    - Conditional サブフローには Execution を含めることができ、Execution は論理式として評価される
    - すべての Execution が true の場合、Conditional サブフローは Required として動作する
    - いずれかの Execution が false の場合、Conditional サブフローは Disabled として動作する
    - Execution を設定しない場合、Conditional サブフローは Disabled として扱われる
    - フローに Execution が含まれていても、フロー自体が Conditional に設定されていない場合、Keycloak は Execution を評価せず、機能的には Disabled と同様に扱う
acr（認証コンテキストクラスリファレンス）クレームを用いたステップアップ認証
- 概要
  - acr は「どの強度で認証したか」を示すクレーム
  - ステップアップ認証は、通常操作では低い認証強度、重要操作では高い認証強度を要求する考え方
  - これにより、UXを保ちながら高リスク操作だけを強固に守れる
- よくある利用シーン
  - 閲覧系画面: パスワードログインのみで許可
  - 振込・個人情報変更・管理者操作: OTPやパスキーの追加認証を要求
- 具体例（ECサイトの支払い情報変更）
  - 1. ユーザーが通常ログイン（例: acr=low）
  - 1. 商品閲覧やカート操作はそのまま許可
  - 1. 「クレジットカード変更」画面に遷移したとき、アプリ側で高い acr（例: acr=high）を要求
  - 1. Keycloak がOTP入力を要求し、成功後に acr=high のトークンを再発行
  - 1. アプリは acr=high を確認して、支払い情報変更を許可
- 実装時のポイント
  - アプリ側で「どの操作にどの acr が必要か」を明確に定義する
  - API側でも acr を検証し、フロントだけに依存しない
  - acr の値設計（low / medium / high など）は運用ルールと合わせて統一する
- https://www.keycloak.org/docs/latest/server_admin/index.html#_step-up-flow

応用編

実システム利用を見据えた使い方を知ろう

第8章 Keycloakのカスタマイズ
- 8.1 カスタマイズの可能な箇所と仕組み
- 8.2 画面のカスタマイズ
- 8.3 SPIの新規プロバイダーの開発
- 8.4 Keycloakのビルド
- 8.5 カスタムコンテナーイメージの作成
- 8.6 本章のまとめ
第9章 Keycloakの非機能面の考慮ポイント
- 9.1 HA構成
- 9.2 HTTPSの設定
- 9.3 エンドポイントの設定
- 9.4 可観測性（Observability）
- 9.5 アップグレード
- 9.6 本章のまとめ

独習PHP 第4版

Fri, 13 Oct 2023 00:00:00 GMT

独習PHP 第4版

PHPについて
- https://atmarkit.itmedia.co.jp/aig/07wcr/php.html#:~:text=ピー・エイチ・ピー %2F PHP,コンパイルを必要としない。
- 当初はPHP(Personal Home Page)として公開され
- PHP3.0で PHP:Hypertext Preprocessorとなった
サンプルファイルについて
- https://wings.msn.to/index.php/-/A-03/978-4-7981-6849-4/

第1章　イントロダクション

1.1　PHPとWebアプリ

サーバとクライアントの話
サーバには色々あります
静的なページを返すだけの場合もある
PHPは動的なページを作成するための代表的なサーバーサイド技術！

1.2　サーバーサイド技術におけるPHPの位置付け

PHPの特徴
- 習得が容易である
- ドキュメントが充実している
- 利用できる環境が豊富である

1.3　PHP環境を設定するための手順

XAMPP(ザンプ)のインストール
- https://www.apachefriends.org/jp/download.html

1.4　PHPの基本構文

1.4.2 拡張子は「.php」が基本

Apacheは拡張子が「.php」であるファイルが要求されたタイミングでPHPの実行エンジンを起動するファイル名に含めていいのはシングルバイト文字だけマルチバイト文字（日本語）などは含めることができない

1.4.3 文字コードの設定

PHPでは文字化けを防ぐため、php.iniファイルで文字コードを宣言している

BOM無しのUTF-8で宣言していく

1.4.4 改行コードの設定

PHPではLFで統一すべしとしている

PHP8では、JIT(Just-In-Time)機能を搭載した JITとはソースコードを毎回翻訳するのではなく、内部的に一括翻訳する一括翻訳されたコードはメモリ上に保存して再利用されるので、実行効率が大幅に向上する

1.4.6 PHPはHTML埋込み型言語

<?php ?> のことをスクリプティングデリミターや、PHPタグと言う

スクリプトブロックが.phpファイルの末尾で終わる場合は、その後方に改行や空白があると、これがブラウザーにも出力されてしまい、レイアウトがずれる原因にもなるため、ファイルの末尾の「?>」は調略すべきというコーディング規約が一般的

文字列を出力する省略構文

<?= 'こんにちは、世界！' ?><br/>
<?= 'こんにちは、皆さん！' ?>

スクリプトの文末にセミコロンは必須！

セミコロンで区切れば1行にもかけるが、あまりいい書き方ではない

<?php
print 'こんにちは、世界！<br />'; print 'こんにちは、皆さん！';
?>

大文字小文字を区別しないので、ごちゃまぜでかけるが、可読性が下がるので統一すべき
- printでもPriNtでもうまく動く

1.4.9 コメントは開発者のための備忘録

1. 
1. //, #
- 単一業コメント
1. /* */
- 複数行コメント、入れ子にできない

この章の理解度チェック

第2章　PHPの基本

2.1　変数

2.2　定数

2.3　データ型

2.4　配列

2.5　型の相互変換

この章の理解度チェック

第3章　演算子

3.1　代数演算子

3.2　代入演算子

3.3　比較演算子

3.4　論理演算子

3.5　ビット演算子

3.6　その他の演算子

3.7　演算子の優先順位と結合則

この章の理解度チェック

第4章　制御構文

4.1　条件分岐

4.2　繰り返し処理

4.3　ループの制御

4.4　制御命令のその他の話題

この章の理解度チェック

第5章　組み込み関数

5.1　関数の基本

5.2　文字列関数

5.3　配列関数

5.4　正規表現（PCRE）関数

5.5　ファイルシステム関数

5.6　その他の関数

この章の理解度チェック

第6章　ユーザー定義関数

6.1　ユーザー定義関数とは?

6.2　変数の有効範囲（スコープ）

6.3　引数のさまざまな記法

6.4　関数呼び出しと戻り値

6.5　ジェネレーター

この章の理解度チェック

第7章　標準クラスライブラリ

7.1　オブジェクト指向プログラミングの基本

7.2　DateTimeクラス

7.3　DirectoryIteratorクラス

7.4　外部ライブラリの活用―Composer

7.5　HTTPクライアントGuzzle

この章の理解度チェック

第8章　リクエスト情報

8.1　リクエスト情報

8.2　ポストデータ―$_POST

8.3　クエリ情報―$_GET

8.4　ヘッダー情報―$_SERVER

8.5　サーバー環境変数―$_ENV

8.6　クッキー情報―$_COOKIE

8.7　セッション情報―$_SESSION

8.8　アップロード処理の実装―$_FILES

この章の理解度チェック

第9章　データベース連携

9.1　データベースの種類

9.2　データベース操作の基本

9.3　データベース抽象化レイヤー

9.4　データベースへの接続

9.5　SQLクエリの発行

9.6　結果セットの取得

9.7　パラメーター値のバインド

9.8　トランザクション処理

この章の理解度チェック

第10章　オブジェクト指向構文

10.1　クラスの定義

10.2　カプセル化

10.3　継承

10.4　ポリモーフィズム

10.5　トレイト

10.6　オブジェクトの操作

10.7　例外処理

10.8　マジックメソッド

10.9　名前空間

10.10　クラスの自動ローディング

この章の理解度チェック

第11章　高度なプログラミング

11.1　属性

11.2　セキュリティ対策

11.3　ドキュメンテーションコメント

11.4　VSCode＋PHP Debug拡張によるデバッグ

この章の理解度チェック

付録A　「練習問題」「この章の理解度チェック」解答

AWS_SolutionArchitectSpecialist_受験対策まとめ

Sat, 24 Jun 2023 00:00:00 GMT

AWS SysOps Administrator Associate Exam preparation

基本情報

試験時間：試験完了までに 180 分
スコア：100-1000点
最低合格スコア：720点
受験料：300 USD
フォーマット: 75 問

WEB情報

https://aws.amazon.com/jp/certification/certified-solutions-architect-professional/?ch=sec&sec=rmg&d=1

認定によって検証される能力

複雑な組織に対応する設計
新しいソリューションのための設計
既存ソリューションの継続的な改善
ワークロードの移行とモダナイゼーションの加速

内容の概要

分野	出題の比率
第 1 分野複雑な組織に対応するソリューションの設計	26%
第 2 分野新しいソリューションのための設計	29%
第 3 分野既存のソリューションの継続的な改善	25%
第 4 分野ワークロードの移行とモダナイゼーションの加速	20%
合計	100%

タスク

第１分野: 複雑な組織に対応するソリューションの設計

タスクステートメント 1: ネットワーク接続戦略を設計する。

対象知識:

AWS のグローバルインフラストラクチャ
AWS ネットワークの概念 (Amazon VPC、AWS Direct Connect、AWS VPN、推移的ルーティング、AWS コンテナサービスなど)
ハイブリッド DNS の概念 (Amazon Route 53 Resolver、オンプレミス DNS 統合など)
ネットワークセグメンテーション (サブネット、IP アドレス指定、VPC 間の接続など)
ネットワークトラフィックモニタリング

対象スキル:

複数の VPC の接続オプションを評価する
オンプレミス、コロケーション、クラウド統合の接続オプションを評価する
ネットワークとレイテンシーの要件に基づいて AWS リージョンとアベイラビリティーゾーンを選択する
AWS ツールを使用してトラフィックフローの問題を解決する
サービス統合のサービスエンドポイントを活用する

タスクステートメント 2: セキュリティコントロールを規定する。

対象知識:

AWS Identity and Access Management (IAM) と AWS Single Sign-On
ルートテーブル、セキュリティグループ、ネットワーク ACL
暗号化キーと証明書管理 (AWS Key Management Service [AWS KMS]、AWS CertificateManager [ACM] など)
AWS のセキュリティ、アイデンティティ、コンプライアンスのツール (AWS CloudTrail、AWS Identity and Access Management Access Analyzer、AWS Security Hub、Amazon Inspector など)

対象スキル:

クロスアカウントアクセス管理を評価する
サードパーティー ID プロバイダーと統合する
保存中のデータと転送中のデータに対する暗号化戦略を導入する
セキュリティイベントの通知と監査を一元化するための戦略を策定する

タスクステートメント 3: 信頼性と耐障害性に優れたアーキテクチャを設計する。

対象知識:

目標復旧時間 (RTO) と目標復旧時点 (RPO)
災害対策戦略 (AWS Elastic Disaster Recovery [CloudEndure Disaster Recovery]、パイロットライト、ウォームスタンバイ、マルチサイトの使用など)
データのバックアップと復元

対象スキル:

RTO および RPO 要件に基づいて災害対策ソリューションを設計する
障害から自動的に復旧するアーキテクチャを実装する
スケールアップとスケールアウトのオプションを考慮し、最適なアーキテクチャを策定する
効果的なバックアップ/復元の戦略を設計する

タスクステートメント 4: マルチアカウント AWS 環境を設計する。

対象知識:

AWS Organizations と AWS Control Tower
マルチアカウントイベント通知
環境間の AWS リソース共有

対象スキル:

組織の要件に最も適したアカウント構造を評価する
一元的なログ記録とイベント通知の戦略を推奨する
マルチアカウントガバナンスモデルを開発する

タスクステートメント 5: コスト最適化と可視化の戦略を決定する。

対象知識:

AWS のコストおよび使用状況のモニタリングツール (AWS Trusted Advisor、AWS Pricing Calculator、AWS Cost Explorer、AWS Budgets など)
AWS 購入オプション (リザーブドインスタンス、Savings Plans、スポットインスタンスなど)
サイズ適正化のための AWS 可視化ツール (AWS Compute Optimizer、Amazon S3 StorageLens など)

対象スキル:

AWS ツールでコストと使用量をモニタリングする
コストを事業単位にマッピングする効果的なタグ付け戦略を策定する
購入オプションがコストとパフォーマンスに与える影響を理解する

第 2 分野: 新しいソリューションのための設計

タスクステートメント 1: ビジネス要件を満たす導入戦略を設計する。

対象知識:

Infrastructure as Code (IaC) (AWS CloudFormation など)
継続的インテグレーション/継続的デリバリー (CI/CD)
変更管理プロセス
構成管理ツール (AWS Systems Manager など)

対象スキル:

新しいサービスや機能のためのアプリケーションまたはアップグレードパスを決定する
デプロイ戦略を策定し、適切なロールバックメカニズムを実装するためのサービスを選定する
必要に応じてマネージドサービスを採用し、インフラストラクチャのプロビジョニングやパッチ適用のオーバーヘッドを削減する
複雑な開発タスクとデプロイタスクを AWS にまかせ、高度なテクノロジーを利用できるようにする

タスクステートメント 2: 事業継続性を確保するソリューションを設計する。

対象知識:

AWS のグローバルインフラストラクチャ
AWS ネットワークの概念 (Route 53、ルーティングメソッドなど)
RTO と RPO
災害対策シナリオ (バックアップと復元、パイロットライト、ウォームスタンバイ、マルチサイトなど)
AWS の災害対策ソリューション

対象スキル:

災害対策ソリューションを構成する
データとデータベースのレプリケーションを構成する
災害対策テストを実行する
自動化され、費用対効果が高く、複数のアベイラビリティーゾーンおよび/またはAWS リージョンをまたいで事業継続性をサポートするバックアップソリューションのアーキテクチャを設計する
障害時もアプリケーションとインフラストラクチャの可用性を維持するアーキテクチャを設計する
プロセスとコンポーネントを活用して一元的なモニタリングを行い、システム障害からプロアクティブに復旧する

タスクステートメント 3: 要件に基づいてセキュリティコントロールを決定する。

対象知識:

IAM
ルートテーブル、セキュリティグループ、ネットワーク ACL
保管中のデータと転送中のデータの暗号化オプション
AWS サービスエンドポイント
認証情報管理サービス
AWS マネージドセキュリティサービス (AWS Shield、AWS WAF、Amazon GuardDuty、AWS Security Hub など)

対象スキル:

最小権限アクセスの原則に従った IAM ユーザーと IAM ロールを指定する
セキュリティグループルールとネットワーク ACL ルールを使用したインバウンドおよびアウトバウンドのネットワークフローを指定する
大規模なウェブアプリケーションの攻撃対策戦略を策定する
保管中のデータと転送中のデータの暗号化戦略を策定する
サービス統合のサービスエンドポイントを指定する
組織の規格への準拠を維持するためのパッチ管理戦略を策定する

タスクステートメント 4: 信頼性の要件を満たす戦略を策定する。

対象知識:

AWS のグローバルインフラストラクチャ
AWS ストレージサービスとレプリケーション戦略 (Amazon S3、Amazon RDS、AmazonElastiCache など)
マルチ AZ およびマルチリージョンアーキテクチャ
オートスケーリングのポリシーとイベント
アプリケーション統合 (Amazon Simple Notification Service [Amazon SNS]、AmazonSimple Queue Service [Amazon SQS]、AWS Step Functions など)
サービスクォータと上限

対象スキル:

ビジネス要件に基づいて可用性の高いアプリケーション環境を設計する
高度な技術を活用して障害に備えて設計し、シームレスなシステム回復性を確保する
疎結合依存関係を実装する
高可用性アーキテクチャを運用、保守する (アプリケーションのフェイルオーバー、データベースのフェイルオーバーなど)
AWS マネージドサービスを活用して高可用性を実現する
DNS ルーティングポリシーを実装する (Route 53 のレイテンシールーティングポリシー、位置情報ルーティング、シンプルルーティングなど)

タスクステートメント 5: パフォーマンス目標を満たすソリューションを設計する。

対象知識:

パフォーマンスモニタリングテクノロジー
AWS のストレージオプション
インスタンスファミリーとユースケース
目的別データベース

対象スキル:

さまざまなアクセスパターンに対応した大規模アプリケーションアーキテクチャを設計する
ビジネス目標に合わせて伸縮自在なアーキテクチャを設計する
キャッシュ、バッファリング、レプリカでパフォーマンス目標を達成するための設計パターンを適用する
必要なタスクに特化したサービスを選択するためのプロセス方法論を策定する
サイズ適正化戦略を設計する

タスクステートメント 6: ソリューションの目標と目的を達成するためのコスト最適化戦略を決定する。

対象知識:

AWS のコストおよび使用状況のモニタリングツール (Cost Explorer、Trusted Advisor、AWS Pricing Calculator など)
料金モデル (リザーブドインスタンス、Savings Plans など)
ストレージ階層化
データ転送コスト
AWS が提供するマネージドサービス

対象スキル:

インフラストラクチャを選択し、適切なサイズにする機会を特定し、リソースの費用対効果を上げる
適切な価格モデルを特定する
データ転送のモデル化とサービスの選択を行い、データ転送コストを削減する
経費支出と使用状況を認識するための戦略を策定し、制御を実装する

第 3 分野: 既存のソリューションの継続的な改善

タスクステートメント 1: 全体的な運用上の優秀性を高めるための戦略を作成する。

対象知識:

アラートと自動修復の戦略
災害対策計画
モニタリングとログ記録のソリューション (Amazon CloudWatch など)
CI/CD パイプラインとデプロイ戦略 (ブルー/グリーン、オールアットワンス、ローリングなど)
構成管理ツール (Systems Manager など)

対象スキル:

最も適したログ記録とモニタリング戦略を決定する
改善の機会を特定する目的で現在のデプロイプロセスを評価する
ソリューションスタック内の自動化の機会に優先順位を付ける
構成管理を自動化を可能にするために適切な AWS ソリューションを提案する
復旧アクションの理解をサポートし、演習するための障害シナリオアクティビティを設計する

タスクステートメント 2: セキュリティを向上させるための戦略を決定する。

対象知識:

データ保持、データ機密性、データ規制要件
モニタリングと修正の自動化戦略 (AWS Config ルールなど)
シークレット管理 (Systems Manager、AWS Secrets Manager など)
最小権限アクセスの原則
セキュリティ固有の AWS ソリューション
パッチ適用のプラクティス
バックアップのプラクティスと方法

対象スキル:

シークレットと認証情報を安全に管理するための戦略を評価する
最小権限アクセスについて環境を監査する
実装されたソリューションを見直し、すべてのレイヤーでセキュリティを確保する
ユーザーとサービスの包括的なトレーサビリティを見直す
脆弱性の検出に対する自動対応に優先順位を付ける
パッチと更新のプロセスを設計し、実装する
バックアッププロセスを設計し、実装する
修復手法を採用する

タスクステートメント 3: パフォーマンスを改善するための戦略を決定する。

対象知識:

高パフォーマンスのシステムアーキテクチャ (オートスケーリング、インスタンスフリート、プレイスメントグループなど)
グローバルサービス (AWS Global Accelerator、Amazon CloudFront、エッジコンピューティングサービスなど)
モニタリングツールのセットとサービス (CloudWatch など)
サービスレベルアグリーメント (SLA) と重要業績評価指標 (KPI)

対象スキル:

ビジネス要件を測定可能な指標に変換する
修復ソリューション候補をテストし、提案を行う
新しいテクノロジーとマネージドサービスを導入する機会を提案する
ソリューションを評価し、要件に基づいてサイズの適正化を行う
パフォーマンスのボトルネックを特定し、調査する

タスクステートメント 4: 信頼性を向上させるための戦略を決定する。

対象知識:

AWS のグローバルインフラストラクチャ
データレプリケーション方法
スケーリング方法論 (ロードバランシング、オートスケーリングなど)
高可用性と回復力
災害対策の方法とツール
サービスクォータと上限

対象スキル:

アプリケーションの利用増加と使用傾向を把握する
既存のアーキテクチャを評価し、信頼性が不十分な領域を特定する
単一障害点を修正する
データレプリケーション、自己修復、伸縮自在な機能とサービスを実現する

タスクステートメント 5: コスト最適化の機会を特定する。

対象知識:

コスト意識の高いアーキテクチャを選択する (スポットインスタンスの利用、スケーリングポリシー、リソースのサイズ適正化など)
価格モデルの採用 (リザーブドインスタンス、Savings Plans など)
ネットワークとデータ転送のコスト
コスト管理、アラート、レポート作成

対象スキル:

使用状況レポートを分析し、使用率の低いリソースと使用率の高いリソースを特定する
AWS ソリューションを活用して使用されていないリソースを特定する
予想される使用パターンに基づいて課金アラームを設計する
AWS Cost and Usage Report をきめ細かく調査する
コスト配分とレポート作成にタグ付けを活用する

第 4 分野: ワークロードの移行とモダナイゼーションの加速

タスクステートメント 1: 移行が可能な既存のワークロードとプロセスを選択する。

対象知識:

移行アセスメントおよび追跡ツール (AWS Migration Hub など)
ポートフォリオアセスメント
アセットプランニング
ワークロードの優先順位付けと移行 (ウェーブプランニングなど)

対象スキル:

アプリケーション移行アセスメントを実施する
7 つの一般的な移行戦略 (7R) に従ってアプリケーションを評価する
総保有コスト (TCO) を評価するタスクステートメント 2: 既存ワークロードの最適な移行アプローチを決定する。

対象知識:

データ移行のオプションとツール (AWS DataSync、AWS Transfer Family、AWS SnowFamily、S3 Transfer Acceleration など)
アプリケーション移行ツール (AWS Application Discovery Service、AWS ApplicationMigration Service [CloudEndure Migration]、AWS Server Migration Service[AWS SMS] など)
AWS ネットワークサービスと DNS (Direct Connect、AWS Site-to-Site VPN、Route 53 など)
アイデンティティサービス (AWS SSO、AWS Directory Service など)
データベース移行ツール (AWS Database Migration Service [AWS DMS]、AWS SchemaConversion Tool [AWS SCT] など)
ガバナンスツール (AWS Control Tower、Organizations など)

対象スキル:

適切なデータベース転送メカニズムを選択する
適切なアプリケーション転送メカニズムを選択する
適切なデータ転送サービスと移行戦略を選択する
移行ツールに適したセキュリティ方法を適用する
適切なガバナンスモデルを選択する

タスクステートメント 3: 既存ワークロードの新しいアーキテクチャを決定する。

対象知識:

コンピューティングサービス (Amazon EC2、AWS Elastic Beanstalk など)
コンテナ (Amazon Elastic Container Service [Amazon ECS]、Amazon Elastic KubernetesService [Amazon EKS]、AWS Fargate, Amazon Elastic Container Registry[Amazon ECR] など)
AWS ストレージサービス (Amazon Elastic Block Store [Amazon EBS]、Amazon Elastic FileSystem [Amazon EFS]、Amazon FSx、Amazon S3、Volume Gateway など)
データベース (Amazon DynamoDB、Amazon OpenSearch Service [Amazon ElasticsearchService]、Amazon RDS、Amazon EC2 のセルフマネージド型データベースなど)

対象スキル:

適切なコンピューティングプラットフォームを選択する
適切なコンテナホスティングプラットフォームを選択する
適切なストレージサービスを選択する
適切なデータベースプラットフォームを選択する

タスクステートメント 4: モダナイゼーションと機能強化の機会を決定する。対象知識:

サーバーレスコンピューティングサービス (AWS Lambda など)
コンテナ (Amazon ECS、Amazon EKS、AWS Fargate など)
AWS ストレージサービス (Amazon S3、Amazon EFS など)
目的別データベース (DynamoDB, Amazon Aurora Serverless、ElastiCache など)
統合サービス (Amazon SQS、Amazon SNS、Amazon EventBridge [Amazon CloudWatchEvents]、Step Functions など)

対象スキル:

アプリケーションコンポーネントを切り離す機会を特定する
サーバーレスソリューションの機会を特定する
コンテナに適したサービスを選択する
目的別データベースの機会を特定する
適切なアプリケーション統合サービスを選択する

試験の対象となる主要なツール、テクノロジー、概念

コンピューティング
コスト管理
データベース
災害対策
高可用性
マネジメントとガバナンス
マイクロサービスとコンポーネントのデカップリング
移行とデータの転送
ネットワーク、接続、コンテンツ配信
セキュリティ
サーバーレスの設計原則
ストレージ

範囲内の AWS のサービスと機能分析:

Amazon Athena
AWS Data Exchange
AWS Data Pipeline
Amazon EMR
AWS Glue
Amazon Kinesis Data Analytics
Amazon Kinesis Data Firehose
Amazon Kinesis Data Streams
AWS Lake Formation
Amazon Managed Streaming for Apache Kafka (Amazon MSK)
Amazon OpenSearch Service
Amazon QuickSight アプリケーション統合:
Amazon AppFlow
AWS AppSync
Amazon EventBridge (Amazon CloudWatch Events)
Amazon MQ
Amazon Simple Notification Service (Amazon SNS)
Amazon Simple Queue Service (Amazon SQS)
AWS Step Functions ビジネスアプリケーション:
Alexa for Business
Amazon Simple Email Service (Amazon SES) ブロックチェーン:
Amazon Managed Blockchain クラウド財務管理:
AWS Budgets
AWS Cost and Usage Report
AWS Cost Explorer
Savings Plans コンピューティング:
AWS App Runner
AWS Auto Scaling
AWS Batch
Amazon EC2
Amazon EC2 Auto Scaling
AWS Elastic Beanstalk
Amazon Elastic Kubernetes Service (Amazon EKS)
Elastic Load Balancing
AWS Fargate
AWS Lambda
Amazon Lightsail
AWS Outposts
AWS Wavelength コンテナ:
Amazon Elastic Container Registry (Amazon ECR)
Amazon Elastic Container Service (Amazon ECS)
Amazon ECS Anywhere
Amazon Elastic Kubernetes Service (Amazon EKS)
Amazon EKS Anywhere
Amazon EKS Distro データベース:
Amazon Aurora
Amazon Aurora Serverless
Amazon DocumentDB (MongoDB 互換)
Amazon DynamoDB
Amazon ElastiCache
Amazon Keyspaces (for Apache Cassandra)
Amazon Neptune
Amazon RDS
Amazon Redshift
Amazon Timestream デベロッパーツール:
AWS Cloud9
AWS CodeArtifact
AWS CodeBuild
AWS CodeCommit
AWS CodeDeploy
Amazon CodeGuru
AWS CodePipeline
AWS CodeStar
AWS X-Ray エンドユーザーコンピューティング:
Amazon AppStream 2.0
Amazon WorkSpaces フロントエンドのウェブとモバイル:
AWS Amplify
Amazon API Gateway
AWS Device Farm
Amazon Pinpoint IoT:
AWS IoT Analytics
AWS IoT Core
AWS IoT Device Defender
AWS IoT Device Management
AWS IoT Events
AWS IoT Greengrass
AWS IoT SiteWise
AWS IoT Things Graph
AWS IoT 1-Click

機械学習:

Amazon Comprehend
Amazon Forecast
Amazon Fraud Detector
Amazon Kendra
Amazon Lex
Amazon Personalize
Amazon Polly
Amazon Rekognition
Amazon SageMaker
Amazon Textract
Amazon Transcribe
Amazon Translate マネジメントとガバナンス:
AWS CloudFormation
AWS CloudTrail
Amazon CloudWatch
Amazon CloudWatch Logs
AWS Command Line Interface (AWS CLI)
AWS Compute Optimizer
AWS Config
AWS Control Tower
AWS License Manager
Amazon Managed Grafana
Amazon Managed Service for Prometheus
AWS Management Console
AWS Organizations
AWS Personal Health Dashboard
AWS Proton
AWS Service Catalog
Service Quotas
AWS Systems Manager
AWS Trusted Advisor
AWS Well-Architected Tool メディアサービス:
Amazon Elastic Transcoder
Amazon Kinesis Video Streams 移行と転送:
AWS Application Discovery Service
AWS Application Migration Service (CloudEndure Migration)
AWS Database Migration Service (AWS DMS)
AWS DataSync
AWS Migration Hub
AWS Schema Conversion Tool (AWS SCT)

AWS Snow ファミリー

AWS Transfer Family ネットワークとコンテンツ配信:
Amazon CloudFront
AWS Direct Connect
Elastic Load Balancing (ELB)
AWS Global Accelerator
AWS PrivateLink
Amazon Route 53
AWS Transit Gateway
Amazon VPC
AWS VPN セキュリティ、アイデンティティ、コンプライアンス:
AWS Artifact
AWS Audit Manager
AWS Certificate Manager (ACM)
AWS CloudHSM
Amazon Cognito
Amazon Detective
AWS Directory Service
AWS Firewall Manager
Amazon GuardDuty
AWS Identity and Access Management (IAM)
Amazon Inspector
AWS Key Management Service (AWS KMS)
Amazon Macie
AWS Network Firewall
AWS Resource Access Manager (AWS RAM)
AWS Secrets Manager
AWS Security Hub
AWS Security Token Service (AWS STS)
AWS Shield
AWS Single Sign-On
AWS WAF ストレージ:
AWS Backup
Amazon Elastic Block Store (Amazon EBS)
AWS Elastic Disaster Recovery (CloudEndure Disaster Recovery)
Amazon Elastic File System (Amazon EFS)
Amazon FSx (すべてのタイプに対応)
Amazon S3
Amazon S3 Glacier
AWS Storage Gateway

Web参考記事

AWS セキュリティベストプラクティス
- https://d1.awsstatic.com/whitepapers/ja_JP/Security/AWS_Security_Best_Practices.pdf
Trusted Advisor ベストプラクティス
- https://aws.amazon.com/jp/premiumsupport/trustedadvisor/best-practices/
ホワイトペーパー
- https://aws.amazon.com/jp/whitepapers
受験録系
- https://www.sky365.co.jp/blog/certification/aws-certified-solutions-architect---professional.html
- https://engineerblog.mynavi.jp/technology/sap-gokaku-repo/

書籍

AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説
- https://www.amazon.co.jp/AWS認定ソリューションアーキテクト-プロフェッショナル-試験特性から導き出した演習問題と詳細解説-平山-毅/dp/4865942483
AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル　改訂第2版 (ＡＷＳ認定資格試験テキスト)
- https://www.amazon.co.jp/AWS認定資格試験テキスト＆問題集-AWS認定ソリューションアーキテクト-プロフェッショナル-改訂第2版-ＡＷＳ認定資格試験テキスト-山下光洋/dp/4815617929/ref=d_pd_sbs_sccl_2_2/357-9098591-2099520?pd_rd_w=oeQXV&content-id=amzn1.sym.0658137e-f5cd-4a01-8903-013eee01b385&pf_rd_p=0658137e-f5cd-4a01-8903-013eee01b385&pf_rd_r=49DM6XEHKNBQ4H26W830&pd_rd_wg=IDn7j&pd_rd_r=33121b2a-c7fb-49da-89aa-32c23c0a7b8e&pd_rd_i=4815617929&psc=1

問題集

Whizlabx
- https://www.whizlabs.com/learn/course/aws-solutions-architect-professional/168

抑えておくサービス

Lambda
APIGateway
DynamoDB
Codeシリーズ
X-ray
CloudFormation
Cognito
SQS
S3
ElasticBeanstalk
CloudFront
KMS
Kinesis

AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル　改訂第2版 (ＡＷＳ認定資格試験テキスト)

Sat, 24 Jun 2023 00:00:00 GMT

AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル　改訂第2版 (ＡＷＳ認定資格試験テキスト)

書籍情報

https://www.sbcr.jp/product/4815617929/

山下光洋：著者

基礎知識から合格する解答力を身につける！

AWSプラットフォームでシステム設計やアプリケーション開発をするために必要な技術スキルと経験を検証するのが「AWS認定ソリューションアーキテクト-プロフェッショナル」試験です。プロフェッショナル試験では、具体的な業務要件や課題をケース問題で出題されるため、基本となる知識をベースに、要件や課題に対応した最適な解答を導く応用力が求められます。本書は、2022年秋に改訂された「SAP-C02 」試験に向けたテキスト＆問題集になっています。出題分野である「複雑な組織に対応するソリューションの設計」「新しいソリューションのための設計」「既存のソリューションの継続的な改善」「ワークロードの移行とモダナイゼーションの加速」に対応して、具体的な要件や課題を読み解きながら、ポイントとなるサービスの利用方法を紹介し、最適な解答につながるように丁寧に解説しています。各節末のポイントのまとめは試験の直前に知識の確認に利用してもらえ、各章末の確認テストや最終章の模擬試験は合格に必要な解答力をしっかり身につけてもらえます。

コンテンツ

第1章　AWS認定ソリューションアーキテクト－プロフェッショナル

1　試験の概要

IMDb: https://psbr.hatenablog.com/entry/imdb
- Amazonの子会社
- AWS Data Exchangeを使っていて、S3バケットに様々なデータをインポートしている
AWS Data Pipeline: AWSリソースやコマンドからAWSリソースへデータを変換、コピーする一連の処理をパイプラインとして設定できる
- 現在、マネジメントコンソールからアクセスできなくなったため、今後は重要なサービスではなくなる可能性がある
Amazon EMR: EMR(Elastic Map Reduce)はApacheHadoopやSparkなどのOSSをマネージドサービスで提供
AWS Glue: ETLサービス
- データを指定した方法で変換してS3などストレージやデータベースにデータを保管できる
Amazon Kinesis Data Analytics: ストリーミングデータをSQLなど使い慣れた言語を使ってリアルタイムに抽出検索
Amazon Kinesis Data Firehose: 最低60秒のバッファでデータをS3、OpenSearchServiceなどに簡単に格納
Amazon Kinesis Data Streams: 秒あたり数GBのデータをリアルタイムにストリーミング処理できます。
AWS Lake Formation: データレイクの構築、管理を簡易化
Amazon Managed Streaming for Apache Kafka(Amazon MSK): マネージドなApache Kafkaを提供するサービス
Amazon OpenSearch Service: Amazon Elasticsearch Serviceの後継サービス
- テキストや非構造化データの全文検索や視覚化、ダッシュボード分析が可能
Amazon QuickSight: BIサービス
Amazon AppFlow: 外部SaaSからのノーコードなデータ連携サービス
AWS AppSync: GraphQL APIとPubSub APIを高速に開発できる

2　お勧めの学習方法

模擬試験 AWS Skill Builder
- https://explore.skillbuilder.aws/learn/external-ecommerce;view=none;redirectURL=?ctldoc-catalog-0=se-"architect professional"
検証用のAWSアカウント
- 会社、個人でAWSアカウントを利用して実際に動かしてみる
Well-Architected Framework
- https://aws.amazon.com/jp/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc&wa-guidance-whitepapers.sort-by=item.additionalFields.sortDate&wa-guidance-whitepapers.sort-order=desc
- 6つの柱を抑えておく
  - オペレーショナル・エクセレンス
  - セキュリティ
  - パフォーマンス
  - コスト最適化
  - 信頼性
  - 持続可能性
その他リソース
- AWS Black Belt
- AWS FAQ

第2章　複雑な組織への対応

1　組織のネットワーク設計

VPC内のEC2からリクエストを実行するためには以下のいずれかが必要
- インターネットゲートウェイがアタッチされたVPCのパブリックネットワークでEC2を起動する
- インターネットゲートウェイがアタッチされ、NATゲートウェイが起動しているVPCのプライベートサブネットでEC2を起動
- VPCエンドポイントを設定
VPCエンドポイント
- ゲートウェイエンドポイント
  - VPCのサービス専用のゲートウェイをアタッチする
  - 対象サービスはS3とDynamoDB
- インターフェースエンドポイント
  - VPCのサブネットにENI(Elastic Network Interface)を作成
  - ENIに割り当てられたプライベートIPアドレスを使用してサービスにアクセス
  - ENIとサービス間のプライベート接続を提供しているのがAWS PrivateLinkという技術

S3ゲートウェイエンドポイント

ゲートウェイエンドポイントは利用料金が不要

オンプレからアクセスする場合はプロキシサーバーを経由してアクセス

プロキシサーバーの可用性を考慮すると、ELB、EC2、Auto Scalingを検討する必要がある

S3インターフェースエンドポイント

インターフェイスエンドポイントは利用料金が発生する

インターフェイスエンドポイントは指定したサブネットにENIを作成

インターフェイスエンドポイントが作成されるとDNS名が発行される

このDNSをS3のエンドポイントに指定してアプリケーションなどからリクエストを実行

VPCエンドポイントにはエンドポイントポリシーがあり、デフォルトでは全てのリソース、すべてのアクションを許可している

AWS PrivateLinkを使用したサードパーティサービスの提供

独自のソフトウェアサービスをサードパーティサービスと呼ぶことがある

AWSクライアントVPN

クライアントからVPCへのアクセス

VPCを介したオンプレミスやインターネット、他のVPCへのOpenVPNベースのVPNクライアントを使用した安全なアクセスを可能にする

認証タイプ
- Active Directory（ユーザーベース）
  - AWS Managed Microsoft ADまたは、AD Connectorを使用
- シングルサインオン（SAMLベースのフェデレーション、ユーザーベース）
  - IAM SAML IDプロバイダー
- 相互認証（証明書ベース）
  - AWS Certificate Managerにアップロードしたサーバー証明書とクライアント証明書を使用
基本設定
- クライアントが使用するIPアドレス用にをCIDRで設定
- AWSクライアントVPNにサブネットを関連付ける
- 関連付けられたサブネットにはENIが作成され、ENIにはセキュリティグループがアタッチされる
接続ログ
- オプションでCloudwatchLogsに接続ログを記録することができる
接続ハンドラ
- 接続時にLambda関数で任意のプログラムを実行して、接続の許可・拒否判定ロジックを実装できる

AWS Site-to-Site VPN

VPCに仮想プライベートゲートウェイをアタッチして、データセンターなどのオンプレミスのルーターと、インタネットプロトコルセキュリティ（IPSec）VPN接続が可能

仮想プライベートゲートウェイ
- ASN（自律システム番号）を指定することもできる
- 指定しない場合はAmaxonのデフォルトASN（64512）が使用
カスタマーゲートウェイ
- オンプレミス側のルーターなどのこと
- 動的ルーティングでは、BGP（ボーダーゲートウェイプロトコル）ASNの指定が可能
- パブリックなASNが無い場合は、プライベートASNを指定できる
- 証明書ベースではなく、事前共有キーで認証する場合は、インターネットから接続可能なIPアドレスが必要
- 証明書ベースの認証をする場合は、AWS Certificate Managerにプライベート証明書をインポートして指定可能
静的ルーティングと動的ルーティング
- カスタマーゲートウェイデバイスがBGPをサポートしている場合は動的ルーティング
- サポートしていない場合は静的ルーティングを選択
VPN接続
- Internet Key Exchangeバージョン2(IKEv2):暗号化のための共通鍵を交換する仕組み
- NATトラバーサル: オンプレミス側でNATルーターを介したVPN接続が可能
- デッドピア検出（DPD）：接続先のデバイスが有効かどうかを確認
複数のSite-to-SiteVPN接続
- 1つの仮想プライベートゲートウェイから、複数のカスタマーゲートウェイにVPN接続を作成可能
- この設計はVPN CloudHubと呼ばれる
冗長なSite-to-SiteVPN接続
- カスタマーゲートウェイデバイスを冗長化する構成
ソフトウェアVPN
- EC2インスタンスにソフトウェアVPNをセットアップして、インターネットゲートウェイ経由でVPN接続も可能
- 次のような要件の場合利用
  - コンプライアンス要件により、接続両端を完全にコントロールする必要がある
  - IPsec以外のVPNプロトコルが必要

AWS Direct Connect(DX)

ユーザーまたはパートナーのルーター（Customer Router）からDirect Connectのルーター（DX Router）に標準のイーサネット光ファイバーケーブルを介して接続するサービス

この接続を使用して、VPCやAWSパブリックサービスへの仮想インターフェースを作成

インターネットサービスプロバイダーを利用する必要なく、オンプレミス拠点間の専用線の代替として、AWSへの接続に使用できるサービス

接続
- 専用接続
- ホスト接続
VPNバックアップのDirectConnect
回復性レベル
- 最大回復性：Direct Connectローケーション全体、またはロケーション内部に物理障害があっても、冗長化を継続できる回復性レベル
- 高い回復性
- 開発とテスト
- クラシック
- AWS Direct Connect フェイルオーバーテスト
仮想インターフェース
- AWS Direct Connect接続を使用するには、仮想インターフェイス(VIF)が必要
- 仮想インターフェイスの種類は以下（覚えておく）
  - プライベート仮想インターフェイス
    - オンプレミスのOSでEFSにマウントできる
  - パブリック仮想インターフェイス
    - S3,DynamoDBにアクセスできる
  - トランジット仮想インターフェイス
    - Direct Connect Gatewayに関連付けられたTransit Gatewayにアクセスできる
LAG(Link Aggregation Group)
Direct Connect の料金
- ポート時間
  - 容量、接続タイプによって時間料金が決まる
- データ転送
  - プライベートVIFの場合は、データ転送を行うAWSアカウントに課金される
Direct Connect 専用接続
- 1,10,100Gbpsから選択可能
Direct Connect ホスト接続
- 500Mbpsを選択可能
Direct Connectのポート時間料金が発生するタイミング
- 接続確立していないが、接続が作成されてから９０日後から
- ９０日経っていないが、Direct Connectエンドポイントとカスタマールーターの接続が確立されたときから

VPC ピア接続

VPCピア接続を使用することで、VPCが他のVPCとの接続をプライベートネットワークで行える

AWS Transit Gateway

最大5000のVPCやオンプレミス環境の接続を簡素化する

VPCアタッチメント
VPN接続
Direct Connectトランジット仮想インターフェイス
Transit Gatewayピアリング接続
Transit Gateway Network Manager
Global Accelerator連携のVPN高速化
Route 53 プライベートホストゾーンとRoute 53 Resolver
- Route 53 プライベートホストゾーン
- Route 53 Resolver

2　マルチアカウント

クロスアカウントアクセス

組織内でのクロスアカウントアクセス
- 複数のAWSアカウントに対して認証が必要な場合の管理
- IAMユーザは特定のAWSアカウントで管理
- 組織内の各AWSアカウントにはIAMロールを作成
- AWS STSのAssume RoleアクションによってIAMロールから一時的認証情報を取得して使用
- 信頼関係
  - 誰がIAMロールに対して、sts:AssumeRoleを実行できるかを許可しているのが信頼関係

カスタムIDブローカーアプリケーション

クロスアカウントだけでなく、オンプレミスのアプリからも同様にSDKにより開発したプログラムでIAMロール二リクエストを実行することにより、一時的な認証情報を使用してAWSのサービスをアプリケーションから使用したり、マネジメントコンソールへのリダイレクトURLを生成できる

サードパーティ製品へのアクセス許可

外部のサービスに対して必要なリソースへの操作を許可することもできる

ただし、「混乱した代理問題」が課題

※AWS作図くんの例
「混乱した代理問題」を解決するのが「外部ID」

AWS Directory Service

サーバー認証に、組織で管理している既存のActiceDirectoryを使用したいケースがある

AD Connector
- オンプレミスのデータセンターなどで稼働しているActiveDirectoryの認証をそのまま使えるサービス
- AD Connectorを使えば、Amazon Workspaces, Amazon WorkDocs, Amazon WorkMail, Amazon QuickSightなどのAWSマネージドディレクトリと連携するサービスを、既存のADのユーザ情報で利用できる
Simple AD
- Samba 4 Active Directory Compatible Server
- 最大５０００ユーザー
  - 5000を超える場合はAWS Managed Microsoft ADを利用
    - また、他ドメインとの信頼関係、MFA（多要素認証）が必要な場合もAWS Managed Microsoft ADを使用する
AWS Directory Service for Microsoft Active Directory(AWS Managed Microsoft AD)
- Microsoft Active Directoryのマネージドサービス
- 5000を超えるユーザー
- 他ドメインとの信頼関係
- MFA(他要素認証)

IAMアイデンティティセンター（AWS SSOの後継）

複数のAWSアカウントとSalesforceやBOXなどの外部アプリケーションへのSSOが可能

IAMアイデンティティセンターの認証
- アイデンティティセンターディレクトリ
  - 認証情報（ユーザ名、パスワード）をIAMアイデンティティセンターで管理、デフォルト設定
- ActiveDirectory
  - AWS Managed Microsoft ADか、AD Connectorを選択できる
- 外部IDプロバイダー
  - Azure AD,Okta,OneLoginなど外部IDプロバイダーを使用できる
AWSアカウントへの許可セット
- IAMアイデンティティセンターで許可セットを作成して、AWSアカウントにSSOした際の権限を設定できる
外部アプリケーションの追加
IAMアイデンティティセンターを使用しないケース
- すでにAD FS(Active Directory Federation Services)や、認証だけでなくOkta、OneLoginのポータルサイトも使用している場合に、
- IAMアイデンティティセンターを使用せずに設定するケースもある

AWS Organizations

AWS Organizationsを利用していない複数のアカウント環境では、次の重複作業が発生

アカウント作成時にクレジットカード、電話番号などの登録
各アカウントのIAMロールのポリシー設定
請求管理
CloudTrailなどのさまざまなサービスはアカウントごとの設定

AWS Organizationsを利用した場合

AWS Organizations APIによるアカウント作成の自動化
SCP(サービスコントロールポリシー)による組織単位のポリシー設定
一括請求管理
各AWSサービスとのサービス統合
アカウント作成の自動化
- 通常、あWSアカウントの作成時には、メールアドレス、パスワード、住所、電話番号、クレジットカードが必要
- SMSか通話での本人確認も必要
- Organizationsでは、既存アカウントを組織のメンバーアカウントとして招待できますが、新規メンバーアカウントもマネジメントコンソール、CLI、SDKから追加可能
SCP(サービスコントロールポリシー)
- Organizations組織でOUやアカウントに設定するポリシー
- 予防コントロールとして、OUに所属するアカウント、またはアカウントでの権限を制限できる
- SCPはOUの階層において下のレベルへ継承される
SCPの許可リスト戦略
SCPの拒否リスト戦略
一括請求（コンソリデーテッドビリング）
- １つの請求書、統合請求データ：コストと使用状況データを複数カウントに渡って複合的に分析できる
- 合計量によるボリュームディスカウント：複数アカウントの合計容量による従量制の割引が受けられる
- リザーブドインスタンス（RI）、Savings Plansの共有
  - 組織のアカウントの合計使用量にリザーブドインスタンス、Savings Plansを適用できるので選択しやすくなる
MEMO: Saving Plans https://aws.amazon.com/jp/savingsplans/
- Savings Plans は、1 年または 3 年の時間単位で利用をコミットする代わりに、オンデマンド料金と比較して最大 72% の請求額の削減を可能にする柔軟な料金モデルです。
- AWS は 3 種類の Savings Plans を提供しています:
  - Compute Savings Plans
  - EC2 Instance Savings Plans
  - Amazon SageMaker Savings Plans
AWS CloudFormation StackSets
- 複数リージョン、複数アカウントにスタックを作成して、変更・削除・管理できる機能
- Organizationsと統合することで、組織、OU、アカウントを指定して、スタックを作成・変更・削除できる
AWS CloudTrail （ユーザのアクティビティやAPI使用量をトレース）
- Organizations組織のマスターアカウントで、組織内のすべてのアカウントについてCloudTrailを有効化できる
- 書き出されるS3オブジェクトのプレフィックスには組織IDが含まれる
AWS Service Catalog
- IAMユーザ二CloudFormationスタックで作成されるリソースへの直接的なアクセス権限を与えられずに、事前に用意されたテンプレートからスタックを作成できる
- 例えば、スタックによって作成されたEC2インスタンスなどのリソースには直接アクセスできませんので、決められたインスタンスタイプ以外を起動したり、セキュリティグループを勝手に変更することはできない
- 管理者があらかじめテンプレートを製品としてService Catalogに登録し、IAMユーザに許可する製品のリストをポートフォリオとして設定
- ポートフォリオはいわばIAMユーザにとってのサービスカタログメニューで、Organizations組織でOUを指定して共有できる
AWS Resource Access Manager(RAM)
- Organizationsと連携して組織、OUとの共有が可能
- Transit Gateway、サブネット、Route53Resolverの転送ルールを複数アカウントで共有可能
- License Managerではソフトウェア・ライセンスを複数アカウントにまたがって管理
AWS Control Tower
- 複数アカウントのベストプラクティスであるランディングゾーンを児童構築する
- ランディングゾーンは、Organizations組織のベストプラクティス構成
- ログアカウントと監査アカウント
  - SecurityOUにログと監査のアカウントを作成
  - ログアカウントにはCloudTrailとConfigのログが集約される
    - Athenaなどを使用して集約されたログを分析可能
  - 監査アカウント
    - 各アカウントのSNSトピックのサブスクライバーのLambda関数から、監査アカウントのSNSトピックへ通知がパブリッシュ（送信）される
- アカウトの追加、招待
  - アカウントは、Service Controlポートフォリオで作成されたAccountFactoryで新規作成、または追加ができる
- アカウント認証
  - Organizationsと連携するIAMアイデンティティセンターによって、各アカウントへのシングルサインオン設定が可能
- コントロール（ガードレール）
- ダッシュボード
  - Control Tower ランディングゾーンは作成して終わりでなく、ダッシュボードで確認、設定が可能

3　確認テスト

第3章　ソリューション設計と継続的改善

1　運用上の優秀性

デプロイ関連サービス

この節では、リリース作業を自動化するAWSデプロイサービスと、サービスを活用することにより実現しやすくなったデプロイメントパターンを解説
Cloud9
- 統合開発環境（IDE）をブラウザさえあれば実行できる
CodeGuru
- ソースコードのレビューによってバグや問題の抽出、パフォーマンスの最適化を自動化
CodeStar
- CodePipeline、CodeCommit、CodeBuild、CodeDeployなどを組み合わせたCICDパイプライン
CodeArtifact
- パッケージを適切なアクセス権限でチーム内に公開、共有可能
OpsWorks
- Chef、Puppetの機能をマネージドで提供
AWS Codecommit
- リポジトリのアクセス許可はIAMポリシーで制限可能
- リポジトリのソースコードなどのデータはKMSのAWSマネージドキーによってサードパーティ暗号化されている
- リポジトリへのアクセス履歴はCloudTrailによって記録
AWS CodeBuild
- ビルド環境：AWSが用意したLinux、Windowsコンテナを選択したり任意のコンテナを用意したりもできる
- ソースコード：CodeCommit以外にもS3バケット、Github、Bitbucketが選択可能
- CodeBuildで実行される、テストやコンパイル、パッケージ作成、コンテナイメージ作成などはbuildspec.ymlに事前定義されたコマンドによって実行される
- 作成されたパッケージ（アーティファクトファイル）は、指定したS3バケットへ保存されたり、buildspec.ymlに定義したdocker pushコマンドでアップロードしたECRリポジトリに保存される
AWS CodeDeploy
- EC2インスタンス、ECSのコンテナ、Lambda関数、オンプレミスサーバーへのデプロイを自動化するサービス
- EC2インスタンス・オンプレミスのデプロイ設定
  - AllAtOnce
    - 正常なホストの最小数値：0
    - 一度にすべてのインスタンスにデプロイ
  - HalfAtATime
    - 正常なホストの最小数値：50%
    - 一度に最大半分のインスタンスにデプロイ
  - OneAtAAtime
    - 正常なホストの最小数値：１
    - 一度に１つのインスタンスにデプロイ
- ECSのデプロイ設定
  - ECSで実行しているコンテナデプロイは、カナリアとリニアから選択可能
  - Canary：最初一定の割合のみにリリースしたあと、指定した期間後に残りのリリースを完了
  - Linear:最初一定の割合のみにリリースしたあと、指定した感覚でデプロイ対象を増分する
    - ECSCanary10Percent5Minutes:最初10%のみ移行、5分後に残り90%も移行
    - ECSLinear10Percent1Minutes:すべての移行が完了するまで、1分ごとに10%ずつ移行
    - ECSAllAtOnce:一度にすべてのコンテナにデプロイ
- Lambdaのデプロイ設定
  - AWS Lambdaにはバージョン、エイリアスという機能がある
  - バージョン：イミュータブルで開発後にバージョンを作成したら変更できない
  - エイリアス：バージョンと紐づけ管理する
  - こうすることで迅速なデプロイとロールバックが可能
  - LambdaCanary10Percent5Minutes
  - LambdaLinear10PercentEvery1Minutes
  - LambdaAllAtOnce
AWS CloudFormation
- テンプレートをもとにAWSリソースをスタックという単位で作成する
- カスタムリソース
  - Resourcesにカスタムリソースを含めて任意のLambda関数を実行することができる
  - カスタムリソースを使用してLambda関数を実行することによって、CloudFormationがサポートしていない処理や、必要な情報を動的に取得可能
- CloudFormationヘルパースクリプト
  - EC2インスタンスへデプロイするアプリケーション向けに、CloudFormationヘルパースクリプトが用意されている
  - Amazon Linux AMIにはすでにインストールされていて、/opt/aws/binにある
    - cfn-init: パッケージのインストール、ファイルの作成、サービスの開始などが可能
    - cfn-signal: CreationPolicy、またはWaitConditionにシグナルを送信するために使用可能
- スタックポリシー
  - スタックに含まれるリソースノ更新は、テンプレートの更新によって行う
  - 意図しない更新を防ぐためにはスタックポリシーを使用できる
- DeletionPolicy（削除ポリシー）
  - スタック削除時に特定のリソースを保護することができる
  - データベースやストレージを保護する際などに有効
- AWS CDK
  - ソースコードからCloudFormationテンプレートを生成することができる
AWS CodePipeline
- ソース、ビルド、デプロイのCI/CDパイプラインを自動化
AWS Elastic Beanstalk
- 開発者がすばやくAWSを使い始めることができるようにするサービス
- .ebextensions: EB CLIを実行するカレントディレクトリに、.ebextensionsディレクトリを作成して、配下にconfigファイルを配置することで、アプリケーションのカスタマイズが可能

デプロイメントパターン

ローリングデプロイ
- 指定したバッチサイズ（インスタンス数、割合）ずつ更新デプロイします。
ブルー／グリーンデプロイ
- 現在のアプリケーションバージョンをブルー
- 新しいバージョンをグリーンとしてデプロイ
- リクエスト送信先を切り替えてリリース方法をブルー／グリーンデプロイと呼ぶ
- Route53を使用したデプロイ
- Application Load Balancerを使用したデプロイ
- EC2 Auto Scalingを使用したデプロイ

モニタリング

AWS Healthイベント
- AWSアカウントに影響を及ぼすイベントをモニタリングできる
- AWS Personal Health Dashboard
  - マネジメントコンソールにサインインんして、ダッシュボードとイベントログで、過去９０日のアカウント固有のイベントとパブリックイベントを確認可能
  - 問題のイベントタイプコードの例：
  - アカウント通知のイベントタイプコードの例
  - スケジュールされた変更のイベントタイプコードの例
- AWS Health API
- Service Health Dashboard
  - インターネット上の公開ページで、パブリックイベントを確認可能
Amazon CloudWatch
- メトリクス、ダッシュボード
- アラーム
- 以上検出
- CloudWatch Logs
  - AWSサービスうやCloudWatchエージェントによるアプリケーションログなどさまざまなログを収集できる
- CloudWatch Synthetics
  - CanaryというLambda関数を設定したスケジュールで実行し、指定したウェブページへ定期的に自動アクセス
  - その時点のスクリーンショットの取得と、Webページに含まれるコンテンツのダウンロード時間などを記録
- CloudWatch RUM
  - RUM(リアルユーザモニタリング)は、エンドユーザの場所や使用デバイス別のパフォーマンスやエラー発生情報を収集、モニタリングできる
Amazon VPCのモニタリング
- VPC Flow Logs
  - ENIへのインバウンド／アウトバウンドトラフィックに関する情報は、CloudWatchLogsまたはS3バケットへ送信可能
  - VPC Flow Logsでは各種のAWS情報をモニタリング可能
  - トラフィックミラーリング
- AWS X-Ray
  - アプリケーションの潜在的なバグとボトルネックを抽出
  - X-RayのPutTrace Segments APIアクセ本により、実行時間やリクエストの成功失敗がX-Rayに送信される
  - 結果をサービスマップやトレース情報で確認可能
- SIEM on Amazon OpenSearch Sevice
  - SIEM(Security Information and Event Management)と呼ばれるログの収集、一元的なモニタリング、分析が可能なシステムを、
  - Amazon OpenSearchServiceを中心として構築できる
  - OpenSearch Dashboardsで可視化、分析可能

構成管理、メンテナンス

AWS Systems Manager
- LinuxやWindowsのEC2インスタンス、オンプレミスサーバにSSMAgent(AWS Ssytems Managerエージェント)をインストールすることで、Systems Managerのマネージドインスタンス(管理対象)にできる
- Session Manager
  - セキュリティグループでSSHポートを許可する必要もキーペアを使用する必要も内
  - ブラウザのSessionManagerからsudo可能なssm-userを使って対話式コマンドを実行可能
- RunCommand
  - EC2、オンプレミスサーバーなどマネージドインスタンスに、コマンドドキュメントに事前定義されたコマンドを実行可能
  - 定形運用をドキュメント化して、Run Commandにより1回のみ実行したり、Lambdaから動的に実行するなども可能
  - コマンド実行対象のインスタンスは、インスタンスID、タグ、リソースグループから指定可能
- パッチマネージャ
  - マネージドインスタンスへのパッチ適用を自動化できる
- Automation
  - 定義済みのオートメーションドキュメントを実行
  - 例）Health EventのEventBridge連携の自動アクションで紹介したAWS-RestartEC2Instanceの例を紹介
    - インスタンスIDとIAMロールがパラメータで定義されている
- OpsCenter
  - 運用で発生した問題の確認やステータスを一言管理できる

AWS Config

AWSアカウント内のリソースの設定情報を収集する
ControlTowerによって組織内のアカウントすべてのリソースの設定情報を集約することもできます。
設定変更の際にイベント通知
有効にしておいたルールによって組織で決められたルールやコンプライアンス要件に準拠しているかを確認できる
非準拠になり修復する必要がある場合は、修復アクションを設定して自動修復することも可能
自動修復にはSystemsManagerAutomationを選択可能
S3バッチオペレーション
- S3のオブジェクト管理機能にバッチオペレーションがある
- 数十億のオブジェクトを大規模に管理可能
- S3バッチオペレーションが使用するIAMロールには、batchoperations.s3.amazonaws.comからの信頼ポリシーが必要

2　セキュリティ

ルートユーザーの保護

ルートユーザはIAMポリシーを設定できず、すべてのアクションが可能
ルートユーザは基本的に使用せず、複雑なパスワードとMFAを設定して保護しておくこと
メールアドレスは個人に紐づくものではなく、企業のエイリアスやメーリングリストを使用する
ルートユーザーにしかできないタスク
- アカウント設定の変更：アカウント名、Eメールアドレス、パスワードの変更
- アクセスキーの作成：ルートユーザーにもアクセスキーを作成できますが非推奨なので作成しないこと
- 請求情報へのIAMアクセスの有効化：有効化したあとはIAMユーザー、IAMロールに請求情報へのアクションをポリシーで許可できる
- MFA Delete：S3バケットのMFA Deleteを設定
- S3バケットポリシーの修復：誰もアクセスできないS3バケットポリシーを設定してしまった場合は、ルートユーザーによって削除、編集可能
ルートユーザ使用時に通知する
- GuardDutyで検知
  - Amazon GuardDuty→AmazonEventBridge→AmazonSNS

最小権限の適用

IAM Access Analyzer: 最小権限の原則を適用するために便利なサービス

IAM Access Analyzer
- 外部に共有されているリソースの識別
- IAMポリシーの検証
- CloudTrailログに基づいたIAMポリシーの作成
- 外部に共有されているリソースの識別
  - IAMロール、S3バケット、KMSキー、RDSスナップショットといったアカウントやパブリックなどのアカウント外部と共有可能なリソースを調べて、
  - 外部と共有されたリソースを検出する
  - Organizationsの組織全体での検出が可能だが、リージョンごとに有効化する必要がある
- IAMポリシーの検証
  - IAM Access AnalyzerはIAMポリシーの作成時に、セキュリティ・エラー・警告・提案の４つの視点で検証してくれる
- CloudTrailログに基づいたIAMポリシーの作成
  - IAMユーザー、IAMロールが実行したリクエストのCloudTrailログを分析して、適切なIAMポリシーを生成してくれる
アクセス許可の境界
- IAMユーザー、IAMロールを作成しポリシーを設定するユーザーが過剰な権限を適用することを防ぐ機能
- 例）Lambda関数やEC2インスタンス向けのIAMロールを作成することを許可されたユーザがいるとする。
  - 開発ユーザ自身はapp-bucketにアクセスすることは許可されているが、機密情報が保存されたsecure-bucketへのアクセスは許可されていない
  - このとき、開発ユーザーがIAMロールとIAMポリシーを作成する際に、secure-bucketへのフルアクセス許可のあるIAMロールを作成下とすると、開発ユーザはIAMロールをEC2インスタンスに設定して、EC2インスタンス上でCLIなどでの操作でsecure-bucketへアクセスできてしまう
  - だからといって、開発ユーザからIAMロールやIAMポリシーの権限を奪ってしまうと開発スピードが落ちる
  - この問題を解決するのがアクセス許可の境界
  - アクセス許可の境界はIAMユーザー、IAMロールに追加で設定する管理ポリシーです。

VPCのセキュリティ

VPCにおけるセキュリティ設定の基礎
- ルートテーブル
- セキュリティグループ：ALB,EC2,ENIを保護するファイアウォール
- ネットワークACL：サブネットを保護するファイアウォール

AWS KMS

CMK(カスタマー管理キー)を管理して、データキーを生成・暗号化・復号するなど、復号化に必要なキー管理、キーオペレーションを提供するマネージド・サービス

さまざまなAWSサービスとシームレスに統合することができる

KMSキーの種類
- カスタマー管理キー：AWSユーザーが作成、管理、完全に制御するキー。キーストレージ料金とリクエスト量に応じた料金が発生
- AWS管理キー：AWSが作成、管理するキー。特定のサービスを使用したり、暗号化するときに選択することで作成される。リクエスト量に応じた課金のみ
エンベロープ暗号化
- 対象暗号化
- 非対称暗号化
キーのローテーション
- KMSキーには年ごとに自動ローテーション機能がある
- カスタマー管理キーでは、自動ローテーションはオプションで有効にできる
- AWS管理キーは自動ローテーションが矯正される
- 有効にするとKMSは毎年新しいキーマテリアルを生成
- 私達はキーIDを指定して暗号化／復号をするのみで、ローテーションされたキーマテリアルの指定は意識しない
キーのエイリアス
- カスタマー管理キーにはエイリアスが設定できる
- アプリケーションからはキーIDのかわりにエイリアスを指定してキーへのアクションを実行できる
キーのインポート
- カスタマー管理キーの作成時にキーをインポート可能
- オンプレミスで作成したキーマテリアルをアップロードしてカスタマー管理キーとして使用できる
KMSをサポートするサービス
- AWS Systems Manager Parameter Store
- AWS Secrets Manager
- Amazon DynamoDB
  - デフォルトはDynamoDBが管理するキーで暗号化出来る
- Amazon EBS
- Amazon RDS
  - 暗号化されていないRDSを暗号化するには：スナップショットを暗号化、暗号化されたスナップショットから復元すると同じ暗号化形式で復号化出来る
- Amazon WorkSpaces
- Amazon EMR
  - ストレージにS3またはEBSを使用します
- Amazon Redshift
  - 4階層のキーで暗号化される。KMSキー＞クラスターキー＞データベースキー＞データ暗号化キー＞クラスタ内のデータブロック
- Amazon S3
  - クライアントサイド暗号化
    - CSE-C
    - CSE-KMS
  - サーバーサイド暗号化
    - SSE-S3
    - SSE-KMS
    - SSE-C

AWS CloudHSM

キー保存、暗号化を実行するハードウェアを物理的に専有するサービスが、AWS CloudHSM

CloudHSMはFIPS 140-2レベル3に準拠している

AWS KMSもFIPS 140-2レベル2に準拠しているが、レベル3が必要な場合はCloudHSMを選択

CloudHSMの構成
KMSカスタムキーストア
CloudHSMのバックアップ
CloudHSMのユースケース(TDE)

AWS Certificate Manager

パブリックなSSL/TSL証明書の保存、更新を提供する無料のサービス

Croud Front,Elastic Load Balancer, API Gatewayと連携してユーザー所有のドメインの証明書を作成出来る

所有者の確認はメール認証化、CNAME認証で行われる、発行済みの証明書をインポートすることも出来る

ACMはサイトシールを提供していない

AWS Private Certificate Authority

プライベートな独自の証明機関(CA)階層を作成し、ユーザー、デバイス、アプリケーションなどの認証のプライベート証明書を作成可能

Amazon Cognito

Webアプリケーションやモバイルアプリケーションに安全に認証を提供するサービス

Cognitoユーザープール
- サインアップ・サインインを短期間でアプリケーションに実装
  - 認証基盤を開発しなくても、モバイルアプリケーションやWebアプリケーションからのサインアップ、サインインのために使用可能
  - 開発コストを下げて開発機関を短くするためにも有用
  - Cognitoユーザープールのみで認証も可能、SNSなど外部での認証も可能
- MFA、アドバンスドセキュリティ他
  - パスワードポリシー
  - メールアドレス、電話番号の検証
  - MFA(多要素認証)
  - アドバンスドセキュリティ
- Lambdaトリガー
  - サインアップイベント、サインインイベントをトリガーにAWS Lambda関数を実行できる
IDプール
- モバイルアプリケーションやクライアントサイドJavaScriptが動作しているアプリケーションで、AWSのサービスに対して安全にリクエストを実行したい場合、CognitoIDプールを利用する

AWS Secrets Manager

データベースなどの認証情報を保持し、取得にはSecrets ManagerへのAPIリクエストを使用します。

認証情報のローテーション更新が必要となった際には、Secrets Managerがデータベースの認証情報を更新して保持します

アプリケーションからはSecrets ManagerへGetSecretValueリクエストを実行することで、常に現在の認証情報を取得できるので、認証情報の再配布やそのための長時間に渡るシステムダウンタイムはない

ローテーション戦略

Amazon Inspector

EC2インスタンス、ECRコンテナイメージ、Lambda関数を自動的に検出して、脆弱性のスキャンを継続的に行い、レポートで可視化するサービスです。

以前はInspector用のエージェントが必要で、EC2のみスキャン可能でしたが、そのバージョンはAmazon Inspector Classicになった

AWS WAF

Web Application Firewall

CloudFront,APIGateway,ApplicationLoadBalancer,AppSync GraphQL API, Cognitoユーザープール、App Runnerへのリクエストに対応できる

AWS WAFの構成と料金
AWS WAFの代表的なマネージドルール

AWS Shield

DDoS攻撃から保護するサービスで、StandardとAdvancedがある

AWS Shield Standardは無料で有効になり、AWSサービスへのベーシックなネットワークレイヤー攻撃を自動的に緩和する
Advancedは1ヶ月3000USDのサブスクリプションサービスで、Organizations組織で利用可能
AWS Shield Advancedで可能になること
AWS Shield Engagement Lambda
- DDoS攻撃を自動検知して、エスカレーションアクションを自動化する設計パターン

AWS Network Firewall

VPC向けのステートフルなマネージドネットワークファイアウォール及びIPSサービス

Network Firewallはトラフィック量に応じて自動的にスケールし、複数のAZにエンドポイントをデプロイすることで高可用性を実現

AWS Firewall Manager

複数アカウントで以下を一元管理
- AWS WAF
- AWS Shield Advanced
- VPCセキュリティグループ
- AWS Network Firewall
- Amazon Route53 Resolver DNSファイアウォール

Amazon GuardDuty

CloudTrail,S3データログ、VPC Flow Logs、DNSクエリログを分析して脅威を抽出する

Amazon Macie

S3バケットに保存された機密データを機械学習とパターンマッチングで検出・監視出来る

参考
- https://dev.classmethod.jp/articles/introduce-to-amazon-macie/
- Macieは女の子の名前で「武器」「活発でスポーティで魅力的な人の代表名」という意味

AWS Security Hub

AWS Security Hubは、GuardDutyやMacieなどAWSのセキュリティサービスや外部のサードパーティサービスの検出結果を、AWS Security Finding形式という共通のJSONフォーマットに変換して結合する

Amazon Detective

GurardDutyの検出結果や、取り込んだログデータソースから、簡単に調査、原因の特定が行えるサービス

例えば、いつもは呼び出されないAPIリクエストがいつもとは違う送信元から呼び出されたことがGuardDutyで検出されたとする。 Detectiveではその送信元から最初と最後の呼び出しや、合計時間、IAMロールなどに関連付けている他の検出結果など、調査二必要な情報を次々に確認出来る

3　信頼性

災害対策

RPOとRTO
- RPO(Recovery Point Objective)：目標復旧時点
- RTO(Recovery Time Objective)：目標復旧時間
オンプレミスからのバックアップ＆リカバリー
AWS Storage Gateway
- オンプレミスから主にS3などのAWSストレージサービスを透過的に使用するためのサービス
- ゲートウェイ種類
  - AmazonS3ファイルゲートウェイ
  - ボリュームゲートウェイ
  - テープゲートウェイ
  - Amazon FSｘファイルゲートウェイ
- オンプレミスにデプロイする仮想イメージ
  - VMware ESXi
  - Microsoft Hyper-V 2012R/2016
  - Linux KVM
AWS マルチリージョンのバックアップ＆リカバリー
- AWSリージョンで稼働しているWEB層/アプリ層/DB層の3層システムの災害対策サイトを他のAWSリージョンにする例
- AMI,ESBは対象範囲がリージョンなので、クロスリージョンコピーをする必要がある
- DLM(Data Lifecycle Manager)で自動取得し、クロスリージョンコピーをスケジューリング出来る
AWS Backup
- システム全体のストレージ、データベースサービス之バックアップを一元管理して自動化出来る
- 以前から各ストレージ之バックアップ機能（EBSのDataLifecycleManager、RDSの自動スナップショット、DynamoDBのAPIバックアップなど）はあったが、
- それらのスケジュールや世代管理はそれぞれで設定する必要があったが、この機能で一元管理が可能
- バックアップボールト
  - バックアップを管理する抽象的な入れ物
- バックアッププラン
  - ルールとリソースを指定
    - ルール：バックアップスケジュール、保存世代、対象のボールトを指定
    - リソース：同じリージョンの対象リソースタイプ（EBS、RDSなど）をすべて指定したり、特定のタグキーと値で限定したり出来る
パイロットライト
- Web層やアプリ層はAMIとCloudFormationテンプレートを作成しておく
- 災害発生時はスタックを作成して復旧
- RDSはクロスリージョンリードレプリカを作成しておき、障害発生時はマスターへ昇格し、スタンバイデータベースを作成
- DynamoDBはグローバルテーブルでレプリカを作成しておく
- ※AWS Elastic Disaster Recovery: システムダウンタイム時間を最小に抑えながら、オンプレミスのサーバーをAWSへ復旧
ウォームスタンバイ（最小構成のスタンバイ）
- パイロットライト構成に加えて、WEB層とアプリ層を最小構成で稼働させておく
- パイロットライトよりもRTOを短縮できるがコストが増加する
マルチサイトアクティブ／アクティブ
- すべてのリソースを常時稼働させておく構成
AWS Global Accelerator
- フェールオーバー時間をさらに短縮出来る
AWS Fault Injection Simulator
- 用意されたシナリオによる障害をAWSリソースに注入することで、災害をシュミレーション出来る

疎結合化による信頼性の改善

外部API呼び出し処理を、SNSとSQSでファンアウト(Fanout)して、アプリケーションEC2インスタンスが行っていた処理をLambdaで実行
順番を守るため、SNSトピックとSQSキューの両方でFIFOトピックとFIFOキューを選択しておく
このような構成にすることで極力外部のAPIに依存しない設計にすることが出来る

データベースへのリクエスト改善

RDS Proxy

リフト&シフトからの信頼性の改善

WEB層、アプリ層をステートレスにすることで異なるリージョンでも切り替えられるようにする

EC2 Auto Scaling

EC2インスタンスを自動で増減する機能

スケーリングポリシー
- スケールアウト・スケールインをいつ行うか、どのような状態になったら行うか、どうなりそうなら行うかを設定
同期的設計
- 普通の３層設計
非同期的設計
- SQS+Lambdaを挟んだ設計
- ※オフロード戦略：少ない処理を先に終わらせ、並列処理が必要なものを非同期で行う
SQSに基づくスケーリング
- キューの属性ApporoximateNumberOfMessagesを取得
- Auto ScalingグループからのInService状態のインスタンス数を取得
- CloudWatchのPutMetricDataAPIで送信する。ココマdの処理を定期的に繰り返すLambda関数をデプロイする
- AutoScalingグループのスケーリングポリシーによって、PutMetricDataされたメトリクスのしきい値アラームに応じたスケールアウト・スケールインアクションが実行される
ファンアウト
- fanout: 扇形に広がるという意味
- SNSトピック＋SQSキューで複数のキューにためて、複数のAutoScalingグループで処理させる
優先処理を考慮したキュー
- SQSの優先度の高い方から取得して処理実施
ライフサイクルフック
- スケールアウト時にソフトウェアのデプロイを完全に完了したことを確認してからInServiceにしたり
- スケールイン時に必要なデータをコピー完了してからターミネートする場合などに利用できる
  - ※一時的にPending:Wait状態にする

Amazon Route 53

パブリックまたはプライベートなホストゾーンやリゾルバーを提供するDNSサービス。ドメインの購入、管理も可能

Route53ヘルスチェック
- IPアドレスかドメインとポートを指定して、接続テストが実行可能
フェイルオーバールーティングポリシー
- ２つのリージョン間でDNSクエリに対して返すIPアドレスが変わる設定
位置情報ルーティングポリシー
- 位置情報でルーティングを決める設定
レイテンシールーティングポリシー
- 低いレイテンシーのレコードを返す設定

AWS Service Quotas

AWSの各サービス使用量には制限がある

調整可能な制限値と使用量が、現在のAWSアカウントでどうなっているかをAWS Service Quotasで確認可能

クォータモニタ(AWS Limit Monitor)
- サービス使用量が制限に近づいているかのモニタリングを自動化するソリューション実装

4　パフォーマンス

EC2のパフォーマンス

インスタンスタイプ
- m6g.large
  - m:ファミリー
  - 6:世代
  - g:追加機能
  - large:サイズ
- 新しい世代を選択したほうがコスト、パフォーマンスでメリットのある場合が多い
追加機能について
- d: インスタンスストアが使用できる
- n: ネットワーク強化
- a: AMDプロセッサ搭載
- g: Gravitonプロセッサ搭載
インスタンスファミリー
- 汎用（T3,T4g,M5,M6g,A1など）：Web、アプリなど
- コンピューティング最適化（C5,C7g）：HPC,メディアトランスコード、機械学習推論など
- メモリ最適化（R5,R6g,X1）：大きなデータセット処理など
- 高速コンピューティング（P4,G5,F1,Trn1）：機械学習推論、GPUグラフィックス処理など
- ストレージ最適化（I3,D3,H1）：ビックデータ処理など
  - 覚え方参考）https://qiita.com/cloud-solution/items/c8dd9ed491abd3360516
バーストパフォーマンスインスタンス
- T2,T3,T3a,T4gインスタンスにはCPUバーストパフォーマンスがある
- 通常はインスタンスサイズごとに決まっているベースラインまでのCPUが使えるが、ベースラインを超えてバースト可能
- ベースラインを超えるときにはCPUクレジットが消費され、ベースラインを下回っているときにはCPUクレジットが蓄積される
- CPU使用率がベースラインを超え続けるような使い方はバーストパフォーマンスインスタンスとしては不向きなので、M5などのインスタンスを検討する
拡張ネットワーキング
- 現行世代を含むほとんどのインスタンスタイプでは、Elastic Network Adapter(ENA)がサポートされている
- 起動時拡張ネットワーキングが有効になっている
- enaモジュールがインストールされていることを確認：modinfo ena
- ネットワークインターフェースドライバーの確認：ethtool -i eth0
ジャンボフレーム
- 最大送信単位(MTU:Maximum Transmission Unit)は単一パケットで渡すことの出来る最大許容サイズのこと
- EC2ではすべてのインスタンスで1500MTUがサポートされている
- かつ、ほとんどのインスタンスで、9001MTU(ジャンボフレーム)がサポートされている
- イーサネットではMTUは1500バイトまでと規定されているhttps://e-words.jp/w/MTU.html
プレイスメントグループ
- ネットワークレイテンシを低くして、ネットワークパフォーマンスを向上させる選択肢としてプレイスメントグループがある
  - クラスタプレイスメントグループ
    - 拡張ネットワーキング、ジャンボフレームで高いネットワークスループットを実現
  - パーティションプレイスメントグループ
    - パーティションというセグメントに配置し、各パーティションは異なるラックになる
  - スプレッドプレイスメントグループ
    - 1つ1つ異なるラックに配置され、1つのAZごとに7つまでインスタンス起動が可能

ストレージのパフォーマンス

Amazon FSx for Lustre
- Lustreという、大規模なHPC(ハイパフォーマンスコンピューティング)やスーパーコンピューターで使用されている分散ファイルシステムがある
- FSx for Lustreは、Lustreを簡単に効率よく起動出来る
- SSD、HDDからストレージを選択可能
- S3と統合することで、S3のオブジェクトをインポートすることも、S3にエクスポートすることも可能
Amazon S3のパフォーマンス最適化
- S3マルチパートアップロードとダウンロード
- S3 Transfer Acceleration
  - 離れた大陸や地域からアップロードが実行される場合、さまざまな影響を受けレイテンシーが高くなる可能性がある
  - Transfer Accelerationを有効にすることで、全世界のエッジロケーションを経由してアップロードを実行出来る
Amazon DynamoDBのパフォーマンス最適化
- 投票アプリケーションのように、まとめて集計するように全アイテムにアクセスすることが多く、書き込みの処理時間を短くする要件の場合はランダムサフィックスを検討

Amazon CloudFront

Webコンテンツの配信
- CloudFrontの配信設定のことをディストリビューションと呼ぶ
オリジンへのアクセス制限
- OAC(Origin Access Control)
  - S3バケットがオリジンの場合は、OACが使用できる
  - OACは2022年8月にリリースされた
  - 以前はOAI(Origin Access Identity)が使用されていたが、SSE-KMSに対応していなかったり、POST、PUTリクエストがそのままではできなかったりと課題があった
- カスタムヘッダー
  - オリジンがALB等の場合に有効
- IPアドレス制限
オンデマンドビデオ、ライブストリーミングビデオの配信
- S3二アップロードされた動画をAWS Elemental MediaConvertによってHLSなどに変換して、配信用のS3バケットに保存し、
- CloudFrontディストリビューションから再生アプリケーションやデバイスへ配信
- AWS Elemental MediaLivで、リアルタイムにエンコードしたコンテンツをAWS Elemental MediaStoreに保存して、CloudFrontを使用して配信可能
フィールドレベルの暗号化
署名付きURLと署名付きCookieを使用したプライベートコンテンツの配信
エッジ関数
- CloudFrontディストリビューションへのHTTPリクエスト、レスポンスの処理をエッジ関数でカスタマイズ出来る
- エッジ関数には、CloudFront FunctionsとLambda@Edgeの２種類がある

AWS Global Accelerator

AWSグローバルネットワークを利用することで、AWSリージョンへのネットワーク経路を最適化、静的エニーキャストIPアドレスが提供される

BYOIPとしてIPアドレスを持ち込むことも可能

CloudFrontと似ている
リージョンまたぎのLBみたいなものみたい
参考）https://qiita.com/miyuki_samitani/items/9a320888a833b4aed08c

Amazon ElastiCache

マネージドなインメモリのデータストアとして、Memcachced,Redisを提供

MemcachedとRedis

Amazon RDSのパフォーマンス

インスタンスクラス
ストレージ
リードレプリカ
読み取り可能なスタンバイを備えたマルチAZ

Amazon Aurora

MySQL,PostgreSQLと互換性のあるそれぞれのタイプを用意している、高いパフォーマンスデータベースエンジン

サーバーレス
- Serverless V2を使用すると、インスタンスクラスを指定する必要はなく、ACU(Aurora Capacity Unit)の最小値、最大値を決めます
- 開始して間もない、リクエスト量の読めないアプリに向いている

Amazon API Gateway

API Gatewayキャッシュ
API エンドポイント
- エッジ最適化APIエンドポイント
- リージョンAPIエンドポイント
- プライベートAPIエンドポイント
使用量プラン
APIの認証
- IAM認証
- Cognitoオーソライザー
- Lmabdaオーソライザー

5　コスト最適化

Amazon EC2のコスト

リザーブドインスタンス
- Savings Plansもあるが、リザーブドインスタンスも依然として有効な割引オプション
スポットインスタンス
- 各AZの各インスタンスタイプの使用されていない量によって決定されるスポット料金
- 上限料金をリクエストして使用
- スポット料金が上限料金を超えた場合か、AZに利用可能なキャパシティがなくなった場合、スポットインスタンスは中断される
  - 中断に備えたベストプラクティス
    - リクエスト料金にデフォルトのオンデマンドインスタンス料金を使用
    - 中断されたインスタンスのかわりにのインスタンスをすぐに起動できるように、AMI,起動テンプレートを準備しておく
    - S3、DynamoDB、RDS、EFSなどにデータを保存する
    - SQSからジョブメッセージを受信して処理をし、中断時には可視性タイムアウトによって他のインスタンスから再試行可能な構成にする
    - 中断前の処理が必要な場合、メタデータのポーリングかEventBridgeで検知し処理を完了させる
    - Fault injection Simulatorでスポットインスタンス中断を発生させてアプリケーションをテストする
Dedicated Hosts(専有ホスト)
- 専用物理サーバにEC2インスタンスを起動出来る
Saving Plans
- 1年または3年期間で時間あたりの使用料金を契約することで、割引料金で使用可能
  - EC2 Instance Savings Plans
  - Compute Savings Plans
  - SageMaker Savings Plans

Amazon S3のコスト

S3ストレージクラス（S3標準とS3標準IA）
S3 Intelligent-Tiering
- アップロード後の経過日数によってアクセス頻度の変化するパターンが一定でない場合、S3 Intelligent-Tieringを使用することでコスト最適化が可能
S3 リクエスタ支払い
- リクエスト料金とデータ転送料金をリクエストした側のアカウントに請求するのが、リクエスタ支払い
- リクエスタ料金を有効にすると、AWSアカウント以外からのアクセスができなくなる
- x-amz-request-payerをヘッダーに含めることで課金される
S3 Storage Lens
- 複数アカウント、複数のS3バケットの使用状況をS3コンソールのダッシュボードで分析可能

Amazon DynamoDBのコスト

DynamoDBのアイテムの読み込み・書き込みにはオンデマンドモードとプロビジョンドキャパシティモード

オンデマンドモード
- 書き込み、読み込みリクエストが発生するごとに料金が発生
  - 書き込みは1KBの項目100万回あたりの料金：$1.4269
  - 読み込みは4KBの項目を強い整合性読み込みは100万回、結果整合性の読み込みは200万回分の料金：$0.285
プロビジョンドキャパシティモード
- 1秒間の書き込み・容量に対して設定するWCU、読み込み回数・容量に対して設定するRCUを設定
- 1WCU:1KB/1秒 1回
- 1RCU:4KB/1秒強い整合性1回結果整合性2回
比較
- プロビジョンドキャパシティモードの１時間あたりの料金に合わせた場合、オンデマンドモードでは５２０回リクエストが可能
- プロビジョンドキャパシティモードは１秒間に１回実行できるので、毎秒実行したとして３６００回実行可能のため、オンデマンドモードのほうが高くなる
- 頻度が少ない場合や、急激なスパイクが発生する場合はオンデマンドモードのほうが優位性がある
- 継続的なリクエストが発生して、ゆるやかな増減がある場合はプロビジョンドキャパシティモードのほうが良い
- 請求モードは24時間に１回切り替えることが可能
DynamoDB Accelerator(DAX)
- VPC内でDynamoDBキャッシュ二アクセス出来る
- マイクロ秒での応答が必要なケースでDAXを検討する

その他リザーブドオプション

Amazon RDS
Amazon ElastiCache
Amazon Redshift
Amazon Open Search Service

コスト配分タグ

タグをサポートしているリソースに適切なタグを設定することは、コスト分析、モニタリングに役立つ

請求メニューのコスト配分タグで指定してアクティブにできる

Organizationsタグポリシー
SCP：SCPで特定のリソース作成時にタグ付けを必須にする

AWS Cost Explorer

コストの使用状況のグラフビューを使用できる

コストの予測
- 日付範囲に未来の日付を含めることで予測を作成可能
予約とSavings Plans
- 使用状況だけでなく、予約の使用状況と過去実績に基づく推奨事項が確認可能

AWS Cost Anomaly Detection

支払いパターンをモニタリングしながら異常なコストを検出する

AWS Cost and Usage Repots

より詳細な課金の情報を、S3に保存されるCSV、Parquestデータで確認可能

CSVデータを個別にダウンロードして確認、分析するのではなく、AthenaからSQLクエリで分析したり、さらにQuickSightを使用して可視化されたグラフのGUIで分析可能

AWS Budgets

AWSアカウント、Organizations組織にまたがった全体の予算や、特定の条件でフィルタリングした条件での予算を作成出来る

請求アラーム

アカウントの請求設定で、「請求アラートを受け取る」オプションを有効にしていると、バージニア北部のCloudWatchで請求アラームを設定可能

マネージドサービスの利用

AWSの請求だけがコストではない、EC2はOSの運用管理も必要

EC2中心のアーキテクチャからサーバーレスアーキテクチャへ
NATインスタンスをNATゲートウェイに変更する
- NATゲートウェイは、内部的な冗長化、復元可用性を持っている
- NATインスタンスは、送信先・送信元チェックを無効化したEC2インスタンス

データ転送料金の削減

NATゲートウェイの料金削減
- 時間利用料金とデータ処理料金が発生
- データ処理料金はデータ量に応じて増加する
メディア配信コストの最適化

AWS Compute Optimizer

EC2,AutoScalingグループ,EBSボリューム,Lambda関数,Fargate(ECS)に付いて、使用率メトリクスを分析し、リソースサイズの選択が最適化どうかレポートして、コスト削減とパフォーマンスに関する推奨事項を提供

6　確認テスト

第4章　移行とモダナイゼーションの加速

1　移行評価とアプローチ

7つのR

移行する際の考え方についての７つのRが公開されている

Refactor
- アプリケーションをフルにカスタマイズ出来るケース
Replatform
- アプリケーションのカスタマイズは行わない
- オンプレミスで利用している成約はそのまま引き継ぐ
Repurchase
- これまで組織で構築し運用していたシステムをSaaSなどに変更する方法
- 例）サーバーに構築していたRedmineをBacklogやJiraなどのSaaSに変更するケース、社内メールサーバをクラウドメールサーバーに変更するなど
Rehost
- シンプルな載せ替えのこと
- アンマネージドサービスであるEC2を中心に構成
Relocate
- VMware Cloud on AWSの使用を開始し、そのままAWSへ移行する手段
Retain
- 検討した結果オンプレミスのままというビジネス判断をしたもの
- システムを見直すいい機会になった
Retire
- 移行を検討する段階で、不要なシステムやインフラがあれば、Retire(廃止)します

移行評価支援のサービス

AWS Cloud Adoption Readiness Tool(CART)
- クラウド支援準備ツール
- ６つのパースペクティブについての質問に答えることで準備状況に関する大まかな推奨事項のレポートを生成
- https://cloudreadiness.amazonaws.com/#/cart
AWS Application Discovery Service
- オンプレミスのサーバーの使用状況や設定データを収集することでAWSへの移行計画をサポート
- AWS Migration Hubに統合されており、収集した情報はAWS Migration Hubで確認できる
- WindowsやLinuxにインストール出来るエージェント型
- VMware向けのエージェントレスコネクタ型

データ、アプリケーション移行のサービス

AWS Snowファミリー
- Snowcone
- Snowball Edage Storage Optimized(ストレージ最適化)
- Snowball Edage Compute Optimized(コンピューティング最適化)
- Snowball Edage Compute Optimized with GPU(コンピューティング最適化GPU)
- Snowmobile
  - エクサバイト規模のデータ転送をサポートする
AWS DataSync
- オンプレミスなどのデータをS3,EFS,FSxへ安全かつ高速に転送するサービス
AWS Application Migration Service(MGN)
- オンプレミスサーバをAWSに移行するサービス
- MGNの料金
  - 90以内に移行が完了したサーバーにはコスト発生なし
AWS Database Migration Service(DMS)
- データベースの移行サービス

2　移行後アーキテクチャとモダナイゼーション

クラウドジャーニー：移行してからクラウドの最適化を勧め、継続的な改善が出来る状態にしていくこと

コンテナ

Amazon ECS(Amazon Elastic Container Service)
- クラスタ、タスク定義、サービスの設定があり、コンテナイメージの保存先としてECRも利用できる
- Amazon ECR(Amazon Elastic Container Registry)
  - コンテナイメージを管理するレジストリ
  - ECS,EKS,App Runnerなどのコンテナ実行サービスから使用できる
- ECS クラスタ
  - コンテナを実行するためのサービスとタスクのグループがクラスタ
  - 組織のチームや部門ごとに分けたり、アクセス権限やコストで分離したりする
- タスク定義
  - コンテナイメージ、タスクサイズ、使用するポート、コンテナタスクがAWSサービスへのアクセスを許可するためのIAMロール、コンテナを実行するためのIAMロール、環境変数、ログ記録などを定義
  - JSONで直接記述することも可能
- サービス
  - 実行するタスク定義、コンテナを配置するVPC、サブネット、セキュリティグループ、スケーリングポリシー、ALBのターゲットブループ、インフラストラクチャなどが設定出来る
- 起動タイプトキャパシティプロバイダー
  - 起動タイプ：AWS FargateとEC2のどちらで実行するか選択可能
    - Fargateでコンテナを起動すれば、OS、クラスタの可用性、ソフトウェアの管理が必要なくなり、コンテナの実行に集中出来る
  - キャパシティプロバイダー
    - より詳細にコントロール出来るコンテナの実行環境
- ネットワークモード
- ECSイベントストリーム
AWS Proton
- コンテナの実行環境を環境テンプレートとサービステンプレートに分けて、自動構築、管理出来るサービス
- 環境テンプレート：VPC、IAMロール、ECSクラスタなどが作成
- サービステンプレート：ALB、ECSタスク、ECSサービス、ECR、CodePipleineが作成
Amazon EKS(AMazon Elastic Kubernetes Service)
- コンテナオーケストレーションのためのオープンソースソフトウェアのマネージドサービス
- EKSでもEC2起動タプとFargateを使用できる
AWS App Runner
- Githubのそー＾すリポジトリまたはECRイメージからアプリケーションを継続的にデプロイ、運用出来る
Amazon Managed Service for Prometheus
- Prometheusとの互換性を持つモニタリングサービス
- コンテナによって構築されたマイクロサービスと相性の良いモニタリングソフトウェア
- Prometheusクエリ言語を使用して、コンテナで構築されたサービスのモニタリングとアラートを出せます
Amazon Managed SErvice for Grafana
- Grafanaのフルマネージドサービス
- KibanaやOpenSearch Dashboardsのようにさまざまなデータソースを可視化、分析できるダッシュボード
- Prometheusもデータソースとして使用可能

Amazon Kinesis

ストリーミングデータを扱うサービス

Amazon kinesis DataStreams
- ストリームデータを収集して順番通りにリアルタイム処理を実現する
Amazon Kinesis Firehose
- 大量のデータを、指定した送信先へ簡単に送る
Amazon Kinesis Data Analytics
- Kinesis Data Streams, Kinesis Data Firehoseのストリーミングデータをもとに、SQLクエリを使用して分析
Amazon Kinesis Video Streams
- 動画ストリームをAWSに収集して、Amazon Rekognition Videoなどと連携してリアルタイムな動画分析が行える
Amazon Managed Streaming for Apache Kafka(Amazon MSK)
- マネージドなApache Kafkaを提供するサービス

S3を中心としたデータレイク

データレイク
- クラウドに送信されたデータを収集して保存し、保存したデータを加工処理したり、分析処理したり、可視化したりします
- 可視化された結果から気づきを得て、ビジネス戦略を練ったり、エンドユーザーに対して提案したりしている
AWS Glue
- フルマネージドなETL(Extract Transform Load)サービス
- S3のデータをGlueデータカタログでカタログ化し、これはAthenaやRedshift Spectrumでも使用可能
Amazon Athena
- S3内のデータをSQLを使用して簡単に分析出来るサービス
  - S3に保存した、CSV,JSON,ParquestなどのデータをSQLで分析する要件の場合は、まずAthenaを検討する
AWS Lake Formation
- データレイクの芝やい構築、きめ細やかなアクセス制限を設定出来る
- ブループリント
  - LakeFormationに用意されているブループリントを使用すると、RDSデータベース、CloudTrail、Application Load BalancerからS3へデータを収集するために必要なリソースを自動で作成可能
AWS Data Exchange
- データプロバイダーが提供するデータ製品をS3バケットにインポート出来る
Amazon AppFlow
- Salesforce、ServiceNow,Slack,Datadog,Zendeskなど様々なSaaSサービスから、コード開発することなく、S3やRedshiftなどのAWSサービスへデータを連携でkリウ
Amazon SageMaker
- 機械学習のトレーニングのための環境構築、作成した推論モデルのデプロイなどを提供しているサービスが、Amazon SageMaker
Amazon Comprehend
- 文章テキストから自動でキーワードを抽出したり、ネガティブ／ポジティブを判定したり出来る
Amazon Rekognition
- 画像、動画を分析できるサービス
- S3バケットにアップロードした画像データから顔を比較して個人を特定して顔認証を実現したり、写真内の要素を検出して自動でラベルを設定したりで着る
Amazon Forecast
- S3に蓄積した過去の時系列データをもとに、将来予測を作成出来る
Amazon Fraud Detector
- オンライン決済詐欺や偽アカウントによる不正を自動検知出来る
Amazon Kendra
- S3,FSx,RDSなどのAWSサービスや、SaaSのストレージサービスの情報をインデックスして、自然言語検索サービスを構築できる
Amazon Translate
- 翻訳サービスで、すぐに使い始めることも出来る
Amazon Polly
- テキストを音声に変換するサービス
- 言語ごとに男性・女性の音声が用意されていて、プロパティで選択できる
Amazon Transcrive
- 音声をテキストに変換するサービス
Amazon Textract
- 手書きのドキュメント化rあ自動で文字を抽出して、テキストデータに出来る
- OCRと呼ばれる技術に該当するサービスですが、従来のOCRのレベルにとどまらず、どこに書いてあっても自動で抽出出来る
Amazon Lex
- Alexaと同じ会話形AIチャットボットを作成出来る
- Amazon ConnectやKendraと連携して、サポートセンターを構築するのに役立つ

Amazon Simple Email Service

SES受信
- Route53などのDNSサービスで、MXレコードをSESドメインに向けて設定する
SES送信
- エンドユーザーからの問い合わせフォームや資料請求、ECサイトでの購入確認メールの送信など、取引における送信メールの自動化、マーケティング目的のダイレクトメールや、エンドユーザーへの一括アナウンスを自動化
Amazon PinPoint
- マーケティングのためのサービス
- 顧客にメール、ショートメッセージ、アプリケーションプッシュメッセージなどキャンペーンメッセージを送る

AWS Transfer Family

S3バケット、EFSファイルシステムへのデータ保存に、SFTP、FTPS、FTPプロトコルを使用できる

IPアドレスに依存した設計

Network Load BalancerにIPアドレスを固定する
- 固定IPアドレスを持ち込んで設定出来る
Elastic Network Interface
- プライベートIPアドレス、MACアドレスやセキュリティグループ、Elastic IPアドレスなどを紐づけておくことが出来る
Egress-Only インターネットゲートウェイ
- VPCではIPv6を使用できる
- IPv４では、プライベートサブネットからインターネットへの出口にNATゲートウェイを使用するが、IPv６ではEgress-Onlyインターネットゲートウェイを使用する

低遅延を実現するサービス

AWS Outposts
- AWSのデータセンターで運用されているものと同様のハードウェア機器がラックサーバー単位で指定したオンプレミスデータセンターに設置される
- 最も近い場所でAWSサービスを使用できるサービス
- 物理的な管理はすべてAWSが実施
AWS Local Zones
- リージョンの拡張
- リージョンよりもユーザーに近い拠点で一部のサービスを使用可能
AWS Wavelength
- 5Gねとワークの通信事業者のネットワークへの直接的なデータ送受信が可能になる
- 日本ではKDDI5Gネットワークが利用できる

マネージドデータベース

目的別データベーストマネージドデータベース
Amazon Neptune
- グラフデータベースで、ノード同士の関係性を保存して検索する機能を提供
Amazon DocumentDB
- MongoDBと互換性を持ったマネージドデータベースサービス
Amazon Keyspaces
- Apache Cassandra互換のマネージドデータベースサービス
- Cassandraクエリ言語、API、Cassandraドライバーをサポートしているので、これまで同様の開発者ツールを使える
Amazon Timestream
- 時系列データを管理することに特化したマネージドデータベースサービス

マネージドアプリケーションサービス

AWS AppSync
- GraphQL APIとPub/Sub APIを高速に開発出来る
- DynamoDBテーブル、OpenSearch Serviceなどへ安全に接続してデータの読み書きが行える
AWS Device Farm
- アプリケーション二台する複数のブラウザ、複数のモバイルデバイスからのテストを実行

3　確認テスト

第5章　模擬テスト

1　問題

2　解答と解説

X.確認テストまとめ

2-3.確認テスト

２つのアカウントでクロスアカウントアクセス
- IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任 - AWS Identity and Access Management
  - https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
外部IDの正しい使い方
ADConnector
- オンプレミスのActive Directoryを利用して、AWS　IAMアイデンティティセンターのIDソースにする
S3ゲートウェイエンドポイント
- 追加料金不要でS3アクセス
- S3インターフェイスエンドポイントは追加料金がかかる
- PrivateLinkはインターフェースエンドポイントを実現している技術の名称
PC端末からVPCにVPN接続する必要がある、どの方法が運用負荷がかからないか
- AWS クライアントVPN
マネージドSite-to-SiteVPN接続を作成するために必要な要素
- カスタマーゲートウェイ：オンプレミス側のIPアドレスなどの設定
- 仮想プライベートゲートウェイ：VPC側二アタッチしてカスタマーゲートウェイとVPN接続
仮想プライベートゲートウェイのAWS site-to-siteVPN接続でサポートされている機能
- デッドピア検出
コンプライアンス要件によりVPN接続両端を完全にコントロールする必要がある
- ソフトウェアVPN：EC2にソフトウェアVPNをインストr－うするので、インスタンスレベル、OSレベルでコントロール出来る
ISPを介さない500Mbpsの接続が必要
- Direct Connectホスト接続
- Direct Connect専用接続：1Gbps,10Gpbs,100Gbpsから選択する
DirectConnect ロケーション全体またはロケーション内部に物理障害があってもDirect Connectの冗長化を継続できる回復性は次のどれ？
- 最大回復性
S3,DynamoDBへの専用接続が必要
- パブリック仮想インターフェース
Direct Connectのポート時間料金が発生するのはどれ？
- 接続確率していないが、接続が作成されてから90日後から
- 90日経っていないが、Direct Connectエンドポイントとカスタマールーターの接続が確率されたときから
数十のVPCと複数のデータセンター拠点との複雑な接続が必要、運用負荷を軽減しルーティングの一元管理ができる？
- Transit Gateway
複数リージョンでのTransit Gatewayを使った接続は次のどれで実現可能か？
- Transit　Gatewayピア接続
オンプレミスト双方向のDNSアクセスを実現できるのは次の打ちどれか？
- Route53 Resolver
Organizationsを使用するメリットはどれ？
- SCPによるOU単位でのセキュリティ管理
- 一括請求による請求管理の簡易化とディスカウントオプションの適用
予防コントロール、検出コントロール、ログ集約アカウント、監査アカウント、AWS IAMアイデンティティセンター連携などマルチアカウントの組織におけるベストプラクティスを自動で簡単に構築出来るOrganizationsと連携したサービスはどれ？
- AWS Control Tower

3-6.確認テスト

CodeDeployでEC2インスタンスにアプリケーションをデプロイする直前にOSレベルでの処理を実行したい
- appspec.ymlのBeforeInstallに処理を記述する
CloudFormationスタック之作成時にLambda関数を実行して追加の処理を実行したい
- カスタムリソース
  - Lambda関数のARNを指定して実行出来る
CodeCommitとECRのどちらかが更新されたときに、ECSへのリリースをしたい
- CodePipelineのソースでCodeCommitとECRのそれぞれを設定して２つのEventBridgeルールによってCodePipleineが実行されるようにする
EC2インスタンスのホストがリタイアする前に自動でEC2インスタンスのホストを変更したい
- AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULEDイベントでSystems Manager Automationを呼び出して自動処理が可能
AWS X-Ray で抽出できるもの
- アプリケーションのバグ
- アプリケーションのボトルネック
VPC内のトラフィックのパケット内容をモニタリング
- トラフィックミラーリング
企業はLinuxでのSSH接続を止めることにした、どの手順が必要か？
- EC2インスタンスが引き受けるIAMロール二Amazon SSM ManagedInstance Coreポリシーをアタッチし、IAMユーザはセッションマネージャを使用できるようにポリシー追加
- SSMエージェントがインストール済みのAMIを選択するか、EC2インスタンスにSSMエージェントをインストールする
- EC2インスタンスがSSMサービスへ通信できるようにネットワーク設定する
複数のEC2インスタンスに効率的にかつ正確にOSレベルでのコマンドを実行したい
- RunCommand
  - 複数のターゲットに事前定義したコマンドを一括で実行可能
特定のEC2インスタンスに特定のパッチを除外して、必要なパッチを適用する方法
- パッチマネージャでベースラインを設定し、対象のEC2インスタンスにタグを設定し、RunCommandを実行する
S3バッチオペレーションでできることを３つ
- オブジェクトロックの保持設定
- オブジェクトのコピー
- AWS Lambda関数の呼び出し
- すべてのオブジェクトタグを置換する
- すべてのオブジェクトタグを削除する
- アクセスコントロールリストを置き換える
- S3オブジェクトロックのリーガルホールド
なるべくコストを抑えてKMSをを利用したい
- AWS管理キーを使用する
  - ストレージ料金分のコストが抑えられます
複数のアプリケーションサーバーで使用するパラメータを暗号化して保持したい
- パラメータストア
  - システムズマネージャーパラメータストアのSecureStringを使用すれば、
  - KMSのキーで暗号化される
使用中のEBSボリュームを暗号化しなければならなくなった、どうしたらいい？
- スナップショットを作成して、スナップショットをもとに新規ボリュームを作成するときに暗号化を有効にする
- 新しくできた暗号化ボリュームをEC2インスタンスにアタッチする
特定のS3バケットでアップロードされるS3オブジェクトの保管時の暗号化設定が必要
- バケットのプロパティでデフォルトの暗号化を設定する
キー管理に専有ハードウェアと高可用性が必要、どの選択肢が最適？
- CloudHSMクラスタを複数のAZを指定して起動し、HSMインスタンスを複数作成して使用する
Webアプリにユーザがhttps接続できるように証明書が必要、CloudFrontで配信している場合どうしたらいいか
- CloudFrontにACM(AWS Certificate Manager)の証明書を設定する
開発するモバイルアプリにサインインする際にMFAが必要
- CognitoユーザープールでMFAを有効にする
EC2インスタンスがビットコインのマイングに使用されている可能性があることなどの脅威を検出するサービス
- Amazon GuardDuty
RDSデータベースで使用されているパスワードを毎月変更する必要がある
- Secrets Managerシークレットに格納して自動ローテーションを有効にする
組織は24時間365日対応のShield Response Team(SRT)を必要としています
- AWS Shield Advanced
オンプレミスのストレージ容量を節約しながらオンプレミスのアプリケーション・サーバーからiSCSIで接続してデータを保存したい
- Storage Gatewayボリュームゲートウェイキャッシュモード
EC2のスケールインが実行される前に追加の処理が必要、どうすればいいか？
- インスタンス終了するときのライフサイクルフックを設定して、EventBridgeルールを作成し、処理するLambdaをターゲットに設定
EC2同士のネットワークレイテンシを極力低くするためのオプションは？
- クラスタプレイスメントグループ
Auroraクラスタデータベースへの多くの接続とリクエストにより接続拒否が発生している。どうしたら改善されるか？
- RDS Proxy: SQLリクエストが調整される
CloudFrontディストリビューションで配信するサイトのオリジンがS3バケットです。直接S3バケットへのリクエストは拒否したい
- S3バケットポリシーでCloudFront OAC(OriginAccessControl)からのリクエストのみを許可する
- CloudFrontオリジン設定でOACを設定する
AWS Global Acceleratorが提供するものは？
- グローバルな静的エニーキャストIPアドレス
ElastiCache for Memcahedの特徴
- マルチスレッドでの実行が可能
- 自動検出機能によってノードを追加、削除する
Redisの方は？
- ソート済みセット型をサポート
- アトミックオペレーションによりキャッシュ内のデータ値をINCR/DECRコマンドで増減
- 永続性を持つ
API Gatewayで呼び出されるLambdaの実行回数を減らしたい
- API Gateway キャッシュを有効にする
リザーブドインスタンスを１年契約しているが、期限切れになったときなるべき未適用期間が発生しないようにしたい
- 購入予約をキューに入れる
  - https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ri-market-concepts-buying.html
組織ではオンプレミスアプリケーションをEC2に移行したあと、1年を目標期間として、順次コンテナ化して、部分的にサーバレスアーキテクチャに変更することも予定している。可能化限り割引を適用したい
- Compute Savings Plans
  - EC2、Fargate、Lambdaに適用できるので、アーキテクチャを変更してもコンピューティングリソースの割引が受けられる
- EC2 Instance Savings Plans,EC2 Reserved Instance:EC2にしか適用できない
- SageMaker Savings Plan: Sagemakerインスタンスの割引プラン
S3 Intelligent-Tieringの特徴
- アクセスされないオブジェクトは自動的に低頻度階層へ移動し、自動的にコストが最適になる
- Glacier：アーカイブされるのでアクセスするときは取り出しに3～5時間かかる
- ライフサイクルルール：アップロードした日から設定した日数追加したオブジェクトがS3標準IAへ移動する
- オブジェクトロック：コンプライアンスモードではオブジェクトが削除から保護される
S3オブジェクトに対してリクエストしたアカウントに請求が発生するようにしたい
- リクエスタ支払いを有効にして、リクエスト側はx-amz-request-payerをリクエストに含める。リクエスト料金とデータ転送料金がリクエスト側に請求される
コストの異常検知をするには？
- Cost Anormaly Detectionでコストモニターを作成する
課金状況に対して月ごとに増加する予算管理を死体
- コスト予算の月次予算設定で初期予算と成長率を入力する
AWS Compute Optimize
- EC2インスタンスタイプ、Lambda関数のメモリ最適化レポートを確認出来る

4-3.確認テスト

AWS Application Migration Service
- サーバー之継続移行が可能
SCTでスキーマ変換してDMSでデータ移行する
AWS Glue
- ETLツール
- S3バケットに格納されているJSONデータを変換して別のS3バケットに格納
Outposts
- ユーザの敷地内でAWSサービスを実行できるラックを設置して低レイテンシを実現
Amazon MQ
- Apache ActiveMQを提供するマネージドサービス

5-1.模擬テスト（メモ）

「ユーザー名をタグに設定しなければ作成できないように制限」しなければならない条件
- アクセス権の境界設定ポリシーが必要
- 制限を超えた権限を持つIAMロールをEC2にアタッチしても、境界以上の権限は拒否出来る
IAM Permissions boundary（アクセス権限の境界）で明示的に許可していないアクションでも条件次第で実行できるということを評価論理の流れを眺めて再認識してみた | DevelopersIO
- https://dev.classmethod.jp/articles/iam-policies-evaluation-logic-rikai/
S3 RTC(Replication Time Control)を有効にすることで、ほとんどのオブジェクトは数秒でレプリケートされ、
99.99%のオブジェクトは15分以内にレプリケートされる
15分のしきい値を超えたとき、イベント通知を作成可能
AWS Transfer Family
- パブリックアクセス可能なSFTP対応サーバーではElastic IPアドレスは設定できない
- https://dev.classmethod.jp/articles/202210-aws-transfer-family-sftp/
Amazon SESでエンドユーザーに対してメールを送信出来る
メールのイベントは設定セットを作成してメール送信時のパラメータで指定することで、イベントをKinesis Data Firehoseに送信できます
Kinesis Data FirehoseはS3バケットへデータを送信出来る
S3バケットに送信されたデータはAthenaからSQLクエリで検索、抽出が可能
User-Agentなどのパケット内容はVPC Flow Logsでは調査できない
VPCトラフィックミラーリングを使用する
Dedicated Hostsのアフィニティオプションを使うことで、ライセンス要件を満たせる
問題16
- AuroraやRDSデータベースのスナップショットは、クラスタやインスタンスを暗号化しているKMSのCMK(カスタマーマスターキー)で暗号化される
- スナップショット化r復元する際は、CMKを使用する権限が必要
- CMKはエクスポートできない
問題18
- DynamoDBに Saving Plansはない
問題19
- Elastic IPアドレスをサポートしているのはNetwork Load Balancer
- API GatewayやApplication Load Balancerはサポートしていない
問題23
- Kinesis Data Analyticsを四王するとストリーミングデータを１秒未満のレイテンシーで処理出来る
問題24
- Redisクラスタのライトスルー戦略
問題33
- IPv6アドレスを利用するには
- Egress-Onlyインターネットゲートウェイを使用することでアウトバウンド専用のネットワークを構築可能
問題34
- IAMユーザとMFA認証必須化
- TODO: 復習
問題36
- サードパーティ製品ごとに外部ID
問題60
- Kinesis Video Streams
- Rekognition Video
- 倉庫の監視カメラの映像をリアルタイム分析して、人を検出した際に通知したい
問題65
- ルートユーザーの認証に対して通知：RootCredentialUsageイベントで検知可能
- CloudTrailのログ集約と迅速な検索：１つのアカウントに集約して、Athenaでデータパーティション分割
- CloudTrailのログ改ざん検知：整合性検証オプションを有効にすればいい
問題66
- Application Discovery Serviceは移行の判断や移行の計画を立てることに役立つ
- オンプレミスのサーバーにエージェントをインストールして情報を収集するエージェント型と
- VMWare向けのコネクタ型がある
問題68
- FSx for Lustre:高速な共有ストレージ
- AWS Wavelenght:5Gネットワークの通信事業者のネットワークへの直接送受信
- AWS OutPuts:特定の場所にAWSサービスを構築
- AWS Local Zones:ユーザーに近い場所を選択できる
問題70
- amazon-efs-utils(EFSマウントヘルパー)をインストールして、
- マウントヘルパーコマンドで、-o tlsオプションを付けてマウントする
- このときEFSファイルシステムIDを指定するので名前解決できている必要がある
問題72
- RDS Proxy: データベース接続プールの作成ト再利用により多くのリクエストを調整処理出来る

メモ

AWS Connector for vCenter AWS Step Functions Timestream Timestream は、高速でスケーラブルかつフルマネージドの専用時系列データベースであり、毎日何兆もの時系列データポイントを保存して分析することができます。Timestream は、リレーショナルデータベースよりも最大 1000 倍高速になることがあります。 https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html

このソリューションは 2 部に分かれます。IAM Access Analyzer は CloudTrail ログを分析して、外部アクセスが許可されているかどうかを判断します。Macie は S3 バケットを分析して、パブリックオブジェクト、パブリックバケット、または機密情報が Amazon S3 にあるかどうかをチェックします。IAM Access Analyzer と Macie の調査結果は両方とも Security Hub で報告できます。Security Hub は Organizations と統合されているため、単一の Security Hub ダッシュボードを使用して、両方のセキュリティ問題を 1 か所でモニタリングできます。 IAM Access Analyzer と Security Hub の統合の詳細については、「AWS Security Hub との統合」を参照してください。 Security Hub との Macie 統合の詳細については、「Amazon Macie Integration with AWS Security Hub (AWS Security Hub との Macie 統合)」を参照してください。 Security Hub と Organizations との統合の詳細については、「AWS Security Hub: および AWS Organizations」を参照してください。

SCP を使用できるようにするには、組織内のすべての機能を有効にする必要があります。

AWS OutPosts サーバーとラックは異なるもの https://engineers.ntt.com/entry/2023/03/24/095642

EC2 Fleet

S3 Transfer Acceleration は、CloudFront エッジロケーションと最適化されたネットワークパスを使用して、オブジェクトの転送を高速化します。マルチパートアップロードは、チャンクを並列にアップロードすることで、大きなファイルを高速に転送します。この方法では、アップロードのスピードが向上し、失敗したアップロードの回復性が向上します。

CloudWatch Synthetics を使用して、エンドポイントと API をモニタリングするために、スケジュールに従って実行される設定可能なスクリプトであるカナリアを作成できます。GET メソッドで API カナリアを作成して、サードパーティーサービスが期待どおりに応答しているかどうかを判断できます。Route 53 はアラームステータスを追跡でき、必要に応じてセカンダリリージョンにフェイルオーバーできます。 Amazon Timestream は、高速でスケーラブルな、サーバーレスの時系列データベースです。Timestream には、時系列関数をサポートし、消費者行動の傾向を特定するのに役立つ組み込みの時系列分析があります。Timestream は数百テラバイトのデータを保存できます。Timestream は、最新データのメモリストアと履歴データの磁気ストアにより、データライフサイクル管理を簡素化します。Timestream は、受信データに対してリアルタイム分析を実行するために、クエリを定期的かつ自動的にスケジュールできます。このソリューションはすべての要件を満たしています。 AWS PrivateLink VPC間のIPが被っても接続可能

Amazon QuickSightからAmazon Athenaに接続

Amazon WorkSpaces

Excelで学ぶビジネスデータ分析の基礎

Sun, 26 Feb 2023 00:00:00 GMT

Excelで学ぶビジネスデータ分析の基礎

理解したこと

書籍サイト

https://aoten.jp/store/detail.html?no=a1500i_b171113

ダウンロード

https://stat.odyssey-com.co.jp/book/statex_basic/

書籍情報

商品の特長本書は、ビジネスの現場でさまざまなデータを活用するための基本的な知識とExcelを使用したデータ分析の方法を解説した書籍です。義務教育の算数・数学レベルを習得していれば、十分理解して実践できる内容になっています。統計分析の実務やデータの見方を習得したい学生、ビジネスパーソン、マネージャー、経営者の方を対象としています。また本書は、資格試験『ビジネス統計スペシャリストエクセル分析ベーシック』の出題範囲を網羅しており、試験対策テキストとしてもご利用いただけます。

内容は大きく3つの部門に分かれており、全15章で構成されています。章が進むにつれて、より高度な分析方法を習得できるようになり、ビジネス実務におけるデータ分析の理解と実践的な力が身につけられます。また、各章の最後には章末問題があり、学習した内容の理解度を確認できます。

目次 [ビジネスデータ把握力編] 第1章平均値｜第2章中央値｜第3章最頻値｜第4章レンジ｜第5章標準偏差

[ビジネス課題発見力編] 第6章外れ値の検出｜第7章度数分布表｜第8章標準化｜第9章移動平均｜第10章季節調整

[ビジネス仮説検証力編] 第11章集計｜第12章散布図｜第13章相関｜第14章回帰分析｜第15章最適化

[ビジネスデータ把握力編]

第1章平均値

第2章中央値

外れ値(他のデータと大きく異なる値)の影響を受けにくい
データの個数が偶数の場合は２つの値の平均を取る

第3章最頻値

modeと呼ばれる
- modeに流行り、流行のような意味合いがあり最頻値と結びついてそう
MODE.MULT,MODE.SNGLの違い
- http://www.eurus.dti.ne.jp/~yoneyama/Excel/kansu/mode.htm
  - MULT: マルチの意味で複数の最頻値を返却する
  - SNGL: シングルの意味で単一の最頻値を返却する
代表値
- 平均値
- 中央値
- 最頻値 https://atmarkit.itmedia.co.jp/ait/articles/2109/15/news033.html

第4章レンジ

データが分布している範囲を表す

第5章標準偏差

[ビジネス課題発見力編]

第6章外れ値の検出

第7章度数分布表

第8章標準化

第9章移動平均

第10章季節調整

[ビジネス仮説検証力編]

第11章集計

第12章散布図

第13章相関

第14章回帰分析

第15章最適化

Linux教科書_LinuCレベル2Version10.0対応

Sat, 20 Nov 2021 00:00:00 GMT

Linux教科書_LinuCレベル2Version10.0対応

理解したこと

書籍サイト

https://www.shoeisha.co.jp/book/detail/9784798167961

ダウンロード

https://www.shoeisha.co.jp/book/download/9784798167961/detail

書籍情報

支持率No.1「Linux教科書」シリーズのノウハウを注いだ『LinuCレベル2』が登場！クラウド時代のLinuxエンジニアの技術力を証明する資格として LPI-Japanにより新たに開発された認定試験が「LinuC（リナック）」です。

この試験が、2020年4月よりVersion 10.0にバージョンアップ。本書は「レベル2 Version 10.0」に対応したLPI-Japan認定テキストです。「あずき本」で有名な、支持率No.1「Linux教科書」シリーズのノウハウをすべて注ぎ込み、LinuCレベル2最新バージョンの出題範囲を完全網羅した新しい定番書です。

●「201試験」「202試験」の2試験に対応。出題範囲を完全網羅 ●学習したことを確認できる練習問題を、各章末に豊富に掲載しています ●巻末には1回分の模擬試験を収録。本試験に向けて実力を試せます ●Linux実習環境（CentOS）を翔泳社Webサイトからダウンロード可。　実際にコマンドを入力しながら学習できます

【LinuCレベル2】「仮想マシン・コンテナを含むLinuxシステム、ネットワークの設定・構築」ができるエンジニアとして認定されます。

メモ

ローカル環境にDockerでCentOS7環境を作ってSSHで接続して演習する
- https://pocketcode.net/docker-centos7-ssh-connect

序章　LinuCの概要

LinuCとは

LinuCの概要

受験の申し込み手続き

受験の実際

試験問題の形式

学習の進め方

受験のテクニック

■第1部　201試験（LinuC Level2 Exam 201）

第1章　システムの起動とLinuxカーネル

1.1　ブートプロセス

BIOS
- MBR:マスターブートレコード
  - ブートローダ：OSを起動するプログラム
  - パーティションテーブル
UEFI
- GPT:GUID Partition Table
- ブートローダ：UEFIシステムパーティション(ESP)に格納される

# ブロックデバイスを一覧表示する
lsblk

ブートローダ：OSを起動するプログラム
- Linuxでもっともよく利用されるブートローダはGRUB(Grand Unified Bootloader)
カーネル
- OSの中でハードウェアとソフトウェアの仲立ちをしてくれるプログラム
- https://qiita.com/uguis410/items/17ec1e447e9716bfdca7
- 起動処理
  - 組み込まれているハードウェアの検出と初期化
  - システムクロックの設定
  - ルートパーティションのチェックとマウント
  - systemdの開始

journalctl -b
dmesg

初期RAMディスク
- カーネルが起動すると、初期RAMディスクをルートパーティションとしてマウントする
RAMディスク：メモリ上にファイルシステムを作成
ループバックマウント：ファイルをファイルシステムとしてマウントする
TODO: 初期RAMディスクの作成などについては復習が必要

1.2　ブートローダ

ブートローダとは：
- カーネルをストレージから読み込み、システムを起動するためのプログラム
- Linuxの代表的なブートローダはGRUB

1.3　システム起動のカスタマイズ

# メンテナンスモード
systemctl isolate rescue.target
systemctl rescue
# 緊急モード
systemctl isolate emergency.target
systemclt emergency

Unit設定ファイル
- /etc/systemd/systemディレクトリに配置される

[tomo@localhost system]$ cat multi-user.target.wants/postfix.service
[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop

[Install]
WantedBy=multi-user.target

# systemd-deltaコマンド 設定ファイルの差分を出力
[tomo@localhost system]$ systemd-delta
[EXTENDED]   /run/systemd/system/user-0.slice → /run/systemd/system/user-0.slice.d/50-After-systemd-logind\x2eservice.conf
[EXTENDED]   /run/systemd/system/user-0.slice → /run/systemd/system/user-0.slice.d/50-TasksMax.conf
[EXTENDED]   /run/systemd/system/user-0.slice → /run/systemd/system/user-0.slice.d/50-Description.conf
[EXTENDED]   /run/systemd/system/user-0.slice → /run/systemd/system/user-0.slice.d/50-After-systemd-user-sessions\x2eservice.conf
[EXTENDED]   /run/systemd/system/session-2.scope → /run/systemd/system/session-2.scope.d/50-After-systemd-user-sessions\x2eservice.conf
[EXTENDED]   /run/systemd/system/session-2.scope → /run/systemd/system/session-2.scope.d/50-After-systemd-logind\x2eservice.conf
[EXTENDED]   /run/systemd/system/session-2.scope → /run/systemd/system/session-2.scope.d/50-Description.conf
[EXTENDED]   /run/systemd/system/session-2.scope → /run/systemd/system/session-2.scope.d/50-Slice.conf
[EXTENDED]   /run/systemd/system/session-2.scope → /run/systemd/system/session-2.scope.d/50-SendSIGHUP.conf
[EXTENDED]   /run/systemd/system/session-2.scope → /run/systemd/system/session-2.scope.d/50-TasksMax.conf
[EXTENDED]   /run/systemd/system/session-6.scope → /run/systemd/system/session-6.scope.d/50-Slice.conf
[EXTENDED]   /run/systemd/system/session-6.scope → /run/systemd/system/session-6.scope.d/50-TasksMax.conf
[EXTENDED]   /run/systemd/system/session-6.scope → /run/systemd/system/session-6.scope.d/50-After-systemd-user-sessions\x2eservice.conf
[EXTENDED]   /run/systemd/system/session-6.scope → /run/systemd/system/session-6.scope.d/50-After-systemd-logind\x2eservice.conf
[EXTENDED]   /run/systemd/system/session-6.scope → /run/systemd/system/session-6.scope.d/50-Description.conf
[EXTENDED]   /run/systemd/system/session-6.scope → /run/systemd/system/session-6.scope.d/50-SendSIGHUP.conf
[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
[EXTENDED]   /run/systemd/system/session-3.scope → /run/systemd/system/session-3.scope.d/50-After-systemd-logind\x2eservice.conf
[EXTENDED]   /run/systemd/system/session-3.scope → /run/systemd/system/session-3.scope.d/50-SendSIGHUP.conf
[EXTENDED]   /run/systemd/system/session-3.scope → /run/systemd/system/session-3.scope.d/50-TasksMax.conf
[EXTENDED]   /run/systemd/system/session-3.scope → /run/systemd/system/session-3.scope.d/50-Description.conf
[EXTENDED]   /run/systemd/system/session-3.scope → /run/systemd/system/session-3.scope.d/50-Slice.conf
[EXTENDED]   /run/systemd/system/session-3.scope → /run/systemd/system/session-3.scope.d/50-After-systemd-user-sessions\x2eservice.conf
[EXTENDED]   /run/systemd/system/user-1000.slice → /run/systemd/system/user-1000.slice.d/50-After-systemd-logind\x2eservice.conf
[EXTENDED]   /run/systemd/system/user-1000.slice → /run/systemd/system/user-1000.slice.d/50-Description.conf
[EXTENDED]   /run/systemd/system/user-1000.slice → /run/systemd/system/user-1000.slice.d/50-TasksMax.conf
[EXTENDED]   /run/systemd/system/user-1000.slice → /run/systemd/system/user-1000.slice.d/50-After-systemd-user-sessions\x2eservice.conf

27 overridden configuration files found.

systemdのログ

journalctl -b
journalctl -f
journalctl -n 10
journalctl -p err
-p, --priority=
           Filter output by message priorities or priority ranges. Takes either a single numeric or textual log level (i.e. between 0/"emerg" and 7/"debug"), or a range of numeric/text log levels in the
           form FROM..TO. The log levels are the usual syslog log levels as documented in syslog(3), i.e.  "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4), "notice" (5), "info" (6),
           "debug" (7). If a single log level is specified, all messages with this log level or a lower (hence more important) log level are shown. If a range is specified, all messages within the range are
           shown, including both the start and the end value of the range. This will add "PRIORITY=" matches for the specified priorities.

journalctl -r
# よく使うことになるのはこれだけと思う
journalctl -u postfix.service

ログの保存場所
- /var/run/log/journalディレクトリ配下にバイナリファイルが存在する。このファイルはシステム再起動で失われるため永続化するなら
- /var/log/journalディレクトリを作成して、/etc/systemd/journalId.confファイルで次の設定

Storage=persistent
SystemMaxUse=200M

1.4　カーネルの構成要素

カーネルバージョン
- unameコマンドでバージョンがわかる
- cat /proc/versionでもわかる
カーネルイメージ
- ls /bootでvmlinuz-xxxの名前でファイルが存在する
lsmodコマンド
- 現在ロードされているすべてのモジュール一覧を表示
- cat /proc/modulesでも同様の情報が取得できる
modinfoコマンド
- モジュールの情報を表示
insmodコマンド
- ローダブルモジュールをロード
rmmodコマンド
- ロードされているモジュールをアンロード
modproveコマンド
- モジュールのロードやアンロードを行います。
- insmodやrmmodだと依存関係を気にしなければ行けないが、
- このコマンドであれば必要なモジュールをロードできるから楽
- modproveコマンドが参照する依存関係はmodles.depファイルに記述されている

1.5　カーネルのコンパイル

カーネルソースの格納ディレクトリ：/usr/src/linux
TODO: ディレクトリ内構造把握しておいたほうがいい

1.6　カーネルパラメータの変更

1.7　カーネルの管理と問題解決

練習問題

1.1 GRUBの設定ファイルgrub.cfgを生成するコマンド：grub2-mkconfig -o /boot/grub2/grub.cfg
1.2 システム起動→GRUBメニュー画面→カーネルが見つからないエラー：メニュー画面で[c]を押下してGRUBシェルを起動し、原因を探って修復
1.3 GRUBを再インストールするコマンド：grub-installorgrub2-installコマンド
1.4 systemdを採用したシステムでログを確認するコマンド：journalctlコマンド
1.5 systemdを採用したシステムでnginxサーバが自動起動しないようにするコマンド：systemctl disabled nginx.service
1.6 rescueモードで起動：一般ユーザはログインできない、ネットワーク接続されない
1.7 mobproveコマンドが利用するファイルで、モジュールの依存関係情報が格納されているファイル：/lib/modules/4.19.132/modules.dep
1.8 xxx
1.9 カーネルソースツリーを初期化するコマンド：make mrproper
1.10 ロードされているカーネルモジュールを確認する方法：lsmodorcat /proc/modules
1.11 初期RAMディスクに関する問題：システム起動に必要なデバイスドライバがカーネル本体に含まれていれば初期RAMディスクは必須ではない
1.12
1.13
1.14
1.15

第2章　ファイルシステムとストレージ管理

2.1　ファイルシステムの設定とマウント

ファイルシステム：SSDやHDDなどのストレージにファイルを保存して管理する仕組み
システムで利用するファイルシステム情報は/etc/fstabファイルに記述されている

[root@localhost etc]# cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Sat Nov 20 22:26:51 2021
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos-root /                       xfs     defaults        0 0
UUID=165774f9-21d1-4f11-ac52-75928012626b /boot                   xfs     defaults        0 0
/dev/mapper/centos-swap swap                    swap    defaults        0 0

# 書式：
# 1.デバイスファイル名・ラベル・UID
# 2.マウントポイント
# 3.ファイルシステムの種類
# 4.マウントオプション
# 5.dumpコマンドの対象
# 6.ブート時にfsckがチェックする順序


# UUIDを確認するコマンド
[root@localhost etc]# blkid
/dev/mapper/centos-root: UUID="947b91d3-28fe-493a-b8e9-522e5c598fb6" TYPE="xfs"
/dev/sda2: UUID="Rl5syf-IFgI-7shw-aKvy-Y4cH-ZrIM-lVVpOU" TYPE="LVM2_member"
/dev/sda1: UUID="165774f9-21d1-4f11-ac52-75928012626b" TYPE="xfs"
/dev/mapper/centos-swap: UUID="4fab2c94-5288-45ee-8a62-1acd401bb752" TYPE="swap"

[root@localhost etc]# ls -l /dev/disk/by-uuid/
合計 0
lrwxrwxrwx. 1 root root 10 11月 21 17:49 165774f9-21d1-4f11-ac52-75928012626b -> ../../sda1
lrwxrwxrwx. 1 root root 10 11月 21 17:49 4fab2c94-5288-45ee-8a62-1acd401bb752 -> ../../dm-1
lrwxrwxrwx. 1 root root 10 11月 21 17:49 947b91d3-28fe-493a-b8e9-522e5c598fb6 -> ../../dm-0

# UUIDを変更するコマンド
tune2fs -U `uuidgen` /dev/sdb1




[root@localhost etc]# cat /usr/lib/systemd/system/tmp.mount
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Temporary Directory
Documentation=man:hier(7)
Documentation=http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime

# Make 'systemctl enable tmp.mount' work:
[Install]
WantedBy=local-fs.target


# カーネルがサポートしているファイルシステム
[root@localhost etc]# cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   ramfs
nodev   bdev
nodev   proc
nodev   cgroup
nodev   cpuset
nodev   tmpfs
nodev   devtmpfs
nodev   debugfs
nodev   securityfs
nodev   sockfs
nodev   dax
nodev   bpf
nodev   pipefs
nodev   configfs
nodev   devpts
nodev   hugetlbfs
nodev   autofs
nodev   pstore
nodev   mqueue
nodev   selinuxfs
        fuseblk
nodev   fuse
nodev   fusectl
        xfs
nodev   rpc_pipefs


# 現在どのようなファイルシステムがマウントされているか
[root@localhost etc]# cat /etc/mtab
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=4515168k,nr_inodes=1128792,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,seclabel,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,seclabel,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,seclabel,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,seclabel,nosuid,nodev,noexec,relatime,net_prio,net_cls 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,seclabel,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,seclabel,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,seclabel,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,seclabel,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,seclabel,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,seclabel,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,seclabel,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,seclabel,nosuid,nodev,noexec,relatime,freezer 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/mapper/centos-root / xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=22,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10915 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0
/dev/sda1 /boot xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
tmpfs /run/user/1000 tmpfs rw,seclabel,nosuid,nodev,relatime,size=906448k,mode=700,uid=1000,gid=1000 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
tmpfs /run/user/0 tmpfs rw,seclabel,nosuid,nodev,relatime,size=906448k,mode=700 0 0

# こちらにもほぼ同じ情報（どのようなファイルシステムがマウントされているか）
[root@localhost etc]# cat /proc/mounts
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=4515168k,nr_inodes=1128792,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,seclabel,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,seclabel,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,seclabel,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,seclabel,nosuid,nodev,noexec,relatime,net_prio,net_cls 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,seclabel,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,seclabel,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,seclabel,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,seclabel,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,seclabel,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,seclabel,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,seclabel,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,seclabel,nosuid,nodev,noexec,relatime,freezer 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/mapper/centos-root / xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=22,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10915 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0
/dev/sda1 /boot xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
tmpfs /run/user/1000 tmpfs rw,seclabel,nosuid,nodev,relatime,size=906448k,mode=700,uid=1000,gid=1000 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
tmpfs /run/user/0 tmpfs rw,seclabel,nosuid,nodev,relatime,size=906448k,mode=700 0 0

# そのため、/etc/mtabを誤って編集してしまった場合は、/proc/mountsを利用して復旧を試みることができる

マウントとアンマウント
- ファイルシステムを利用するには、任意のディレクトリをマウントポイントとしてマウントする必要がある
- ファイルシステムをマウントするにはmountコマンドを使う

[root@localhost etc]# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=4515168k,nr_inodes=1128792,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,devices)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,net_prio,net_cls)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,hugetlb)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,memory)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,blkio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,freezer)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mapper/centos-root on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10915)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel)
/dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=906448k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=906448k,mode=700)


# マウント
mount /dev/sdb1 /data
mount -o remount /data

スワップ
- スワップ領域は、ブロックデバイス上の仮想的なメモリ領域として使われます。
- スワップ領域は通常、システムのインストール時に作成しますが、あとから作成することも可能
- 作成するには、mkswapコマンドを使う

# スワップ領域作成
mkswap -c /dev/sda3

[root@localhost etc]# dd if=/dev/zero of=/tmp/swapfile bs=1M count=500
500+0 レコード入力
500+0 レコード出力
524288000 バイト (524 MB) コピーされました、 0.539949 秒、 971 MB/秒
[root@localhost etc]# mkswap /tmp/swapfile
スワップ空間バージョン1を設定します、サイズ = 511996 KiB
ラベルはありません, UUID=2b778452-5107-43a0-8f90-03fb310b6c19
[root@localhost etc]# chmod 600 /tmp/swapfile
[root@localhost etc]# ll /tmp/swapfile
-rw-------. 1 root root 524288000 11月 21 18:59 /tmp/swapfile

[root@localhost etc]# swapon /tmp/swapfile
[root@localhost etc]# swapon -s
Filename                                Type            Size    Used    Priority
/dev/dm-1                               partition       839676  0       -2
/tmp/swapfile                           file    511996  0       -3
[root@localhost etc]# cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/dm-1                               partition       839676  0       -2
/tmp/swapfile                           file            511996  0       -3


[root@localhost etc]# swapoff /tmp/swapfile
[root@localhost etc]# swapon -s
Filename                                Type            Size    Used    Priority
/dev/dm-1                               partition       839676  0       -2

2.2　ファイルシステムの作成

mkfsコマンド：ファイルシステムを作成するコマンド

# ブロックデバイス確認
lsblk
[root@localhost etc]# lsblk -p
NAME                        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
/dev/sda                      8:0    0    8G  0 disk
tq/dev/sda1                   8:1    0    1G  0 part /boot
mq/dev/sda2                   8:2    0    7G  0 part
  tq/dev/mapper/centos-root 253:0    0  6.2G  0 lvm  /
  mq/dev/mapper/centos-swap 253:1    0  820M  0 lvm  [SWAP]
/dev/sr0                     11:0    1 1024M  0 rom

# ext2/ext3/ext4ファイルシステムの作成
mke2fs


# mke2fsコマンドのデフォルト値
[root@localhost etc]# cat /etc/mke2fs.conf
[defaults]
        base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
        default_mntopts = acl,user_xattr
        enable_periodic_fsck = 0
        blocksize = 4096
        inode_size = 256
        inode_ratio = 16384

[fs_types]
        ext3 = {
                features = has_journal
        }
        ext4 = {
                features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize,64bit
                inode_size = 256
        }
        ext4dev = {
                features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
                inode_size = 256
                options = test_fs=1
        }
        rhel6_ext4 = {
                features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
                inode_size = 256
                enable_periodic_fsck = 1
                default_mntopts = ""
        }
        small = {
                blocksize = 1024
                inode_size = 128
                inode_ratio = 4096
        }
        floppy = {
                blocksize = 1024
                inode_size = 128
                inode_ratio = 8192
        }
        big = {
                inode_ratio = 32768
        }
        huge = {
                inode_ratio = 65536
        }
        news = {
                inode_ratio = 4096
        }
        largefile = {
                inode_ratio = 1048576
                blocksize = -1
        }
        largefile4 = {
                inode_ratio = 4194304
                blocksize = -1
        }
        hurd = {
             blocksize = 4096
             inode_size = 128
        }



# mkfsコマンドによるファイルシステム作成
mkdf -t ext3 /dev/sdc1

Btrfsファイルシステムの作成
- Btrfs(B-tree file system)はLinux向けの新しいファイルシステムで対象外性に優れ先進的な機能が取り込まれている
  - 最大ファイルサイズは16EiB
  - コピーオンライと
  - ディスク容量の効率的な使用
  - iノードの動的割当
  - ストレージプール対応
  - スナップショット機能
  - チェックサムによる完全性の保証
  - 効率的な増分バックアップ
  - オンラインデフラグ
- mkfs.btrfsコマンドを実行して作成する
  - mkfs.btrfs /dev/sdb1 /dev/sdb2
    - このように複数の物理ボリュームをまとめた１つの仮想的なボリュームをストレージプールと言う
  - btrfs-convertコマンドを使うと、ext2/ext3/ext4ファイルシステムをBtrfsに変換できる

2.3　ファイルシステムの管理

ext2/ext3ファイルシステムはブロック単位で管理されている
ブロックには以下が存在する
- データブロック
- iノードブロック
  - どのデータブロックにどんなデータが格納されているかの情報
  - ファイル・タイプ、アクセス権、所有者、所有グループ、ファイルサイズ
- スーパーブロック
  - ファイルシステムの全般的な情報（データブロックサイズ、マウント回数、iノードやデータブロックの数など）
  - スーパーブロックは非常に重要なので、ブロックグループごとにバックアップが作成される
TODO: 詳細見れていない・・

2.4　LVM

LVM:論理ボリューム管理　Logical Volume Manager
- ディスクのパーティションを直接操作するのではなく、仮想的なパーティションである論理ボリュームを動的に管理
- パーティションを使ったディスク管理に比べて次の制約を回避できる
  - 一度パーティションを作成するとサイズ変更ができない
  - 別のディスクにパーティションを移動させることができない
  - ディスクのサイズを超える大きさのパーティションは作成できない
- ★：PVがPhysical Volume(物理ボリューム)、VGがVolume Group(ボリュームグループ)、LVがLogical Volume(論理ボリューム)の略称であることを覚えておく
LVMの作成
- 物理ボリュームを用意して、パーティションタイプを「8e」(Linux LVM)に設定しておく
- pvcreate: デバイスを物理ボリュームとして初期化
- vgcreate testvg /dev/sdd1 /dev/sde1: ボリュームグループの作成
- lvcreate -L 500M -n lv01 testvg: 論理ボリュームの作成
- lvscan: 論理ボリュームの状態を完結に表示
TODO: vg~~コマンドが他にも多数あるが詳細は一旦飛ばす

練習問題

2.1 カーネルがサポートしているファイルシステムの種類を確認するにはどのコマンドを実行すればよいか
- cat /proc/filesystems
- その他：
  - /etc/mtabには現在マウントされているファイルシステムについての情報が格納されている
2.2 /etc/fstabで指定できるマウントオプションの説明で適切でないもの
- 割愛
2.3 /etc/fstabの書式として適切でないもの
2.4 /mntディレクトリにマウント下Btrfsファイルシステムの使用状況を表示したい場合
- btrfs filesystem df /mnt
2.5 Btrfsファイルシステムのサブボリューム/dataのスナップショットを/mnt/data_snapとして作成
- btrfs subvolume snapshot /data /mnt/data_snap
2.6 USBメモリを読み取り専用でマウントしたい。マウントポイントは/media/usb、デバイスファイルは/dev/sdb1とする。ファイルシステム地アプはvfat
- mount -t vfat -o ro /dev/sdb1 /media/usb
2.7 現在マウントされているファイルシステムとそのオプションを知るには何というファイルを参照
- cat /etc/mtab
2.8 ファイルシステムの種類がxfsであるファイルシステムのみをすべてアンマウントするには
- unmount -at xfs
2.9 unmount /home; mount /homeを実行するのと同じことを１コマンドで実行したい場合
- mount -o remount /home
2.10 スワップ領域を/dev/sda7に作成するコマンドを引数とともに記述してください
- mkswap /dev/sda7
2.11 アクティブなスワップ領域を表示するには
- swapon -s
2.12 mkfsコマンドを使ってext4ファイルシステムを作成。その際に、予約ブロックの割合も変更する。不良ブロックのチェックも行う。必要なオプションをすべて選択
- -t:タイプを指定
- -c:不良ブロックのチェック
- -m:root用の予約領域を指定する
2.13 rootユーザー用予約領域が5%確保されているext4ファイルシステム/dev/sda5がある。この領域を0%に死体
- tune2fs -m 0 /dev/sda5
2.14 XFSファイルシステムをバックアップするコマンド
- xfsdump
2.15 /dev/sdb1を物理ボリュームとして初期化したい場合に実行するコマンド
- pvcreate /dev/sdb1
2.16 testvgという名称のボリュームグループを作成したい場合。ボリュームグループを構成する物理ボリュームデバイスは/dev/sdb1と/dev/sdc1
- vgcreate -s 32m testvg /dev/sdb1 /dev/sdc1
2.17 ボリュームグループtestvg内にサイズが10Gバイトの論理ボリュームlv01を作成しようとする。
- lvcreate
  - -L:サイズ
  - -n:論理ボリューム名
  - 引数にはボリュームグループ名を指定する

第3章　ネットワーク構成

3.1　基本的なネットワーク構成

ネットワークデバイスの操作
- インターフェース名：eth0,eth1,loなどがもともと
- 最近は、enp0s3などの名前が使われる

# カーネルが認識しているネットワークデバイスを確認
lspci | grep -i eth
journalctl -b | grep -i eth | grep enp

ipコマンド
- ネットワークインターフェースやルーティングテーブル、ARPテーブルなどを管理するコマンド

# データリンク層
ip link show
# IPアドレス
ip addr show
# ルーティングテーブル
ip route show
# ARPキャッシュ
ip neigh show


ip -s link show enp0s3

# add でパラメータ設定する
ip addr add 192.168.11.10/24 dev enp0s3

#### ifconfigコマンド
# ipコマンド以前に広く使われていたコマンド
ifconfig
ifconfig -a

ifconfig enp0s3 192.168.120.27 netmask 255.255.255.0
ifconfig enp0s3 up
# まとめて指定も可能
ifconfig enp0s3 192.168.120.27 netmask 255.255.255.0 up

#### ARP
# MACアドレスとIPアドレスを変換するプロトコル
# 自分のIPアドレス/MACアドレスと相手のIPアドレスが含まれたパケットをブロードキャストして、指定されたIPアドレスを持つ相手がこのパケットを受け取ると、自分のMACアドレスを返す
# 一度取得した情報は、ARPキャッシュと呼ばれるテーブルに一定期間キャッシュされる

無線ネットワークの設定

iwconfig

3.2　高度なネットワーク設定

route
netstat -r
# 情報は同じ物が出力される

[root@localhost etc]# netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         buffalo.setup   0.0.0.0         UG        0 0          0 enp0s3
192.168.11.0    0.0.0.0         255.255.255.0   U         0 0          0 enp0s3
192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0
[root@localhost etc]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         buffalo.setup   0.0.0.0         UG    100    0        0 enp0s3
192.168.11.0    0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

基本的なネットワーク管理コマンド
- pingコマンド：指定されたホストにICMPパケットを贈り、その反応も表示
  - オプション：
    - -n:ホスト名を名前解決せずにIPアドレスで表示
    - -c 回数
    - -i 間隔：指定した間隔ごとにICMPパケットを送信
- ping6コマンド：IPv6用コマンド
- tcpdumpコマンド：指定したネットワークインターフェースを監視市、そこに到達したデータをコンソール上に表示
- netstatコマンド：ネットワーク機能に関する様々な情報を表示
- ssコマンド：netstatコマンドに変わるのがssコマンド
- tracerouteコマンド：指定されたホストまでパケットが伝わる経路を表示
  - ネットワーク経路上にICMPメッセージに返答しないホストが存在する場合などでは適切な動作は期待できない
- ncコマンド：TCP/UDPを使ったネットワーク通信を行うシンプルなコマンド
  - ポートスキャンを実施したり、通信状態を確認したりといったちょっとした操作に活用できる
  - nc localhost 25
NetworkManager
- ネットワークを管理するサブシステムとして、NetworkManagerが導入されている
- 稼働しているか確認：systemctl status NetworkManager
- nmcliコマンドを使ってネットワークの設定、接続の管理、状態の確認などが可能

nmcli

# NetworkManagerの状態確認
nmcli general status

# ネットワークインターフェースの設定ファイル
cat /etc/sysconfig/network-scripts/ifcfg-enp0s3

3.3　ネットワークの問題解決

ネットワーク設定情報の収集
- /etc/hostname: ホスト名を記述
- /etc/hosts: ホスト名とIPアドレスの対応を記述
- /etc/networks: ネットワーク名とネットワークアドレスの対応が記述
- /etc/nsswitch.conf: 名前解決をする際の問い合わせ順を記述
- /etc/resolv.conf: 問い合わせ先のDNSサーバーやドメイン名を記述

##### /etc/nsswitch.conf
[root@localhost ~]# cat /etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#       nisplus                 Use NIS+ (NIS version 3)
#       nis                     Use NIS (NIS version 2), also called YP
#       dns                     Use DNS (Domain Name Service)
#       files                   Use the local files
#       db                      Use the local database (.db) files
#       compat                  Use NIS on compat mode
#       hesiod                  Use Hesiod for user lookups
#       sss                     Use sssd (System Security Services Daemon)
#       [NOTFOUND=return]       Stop searching if not found so far
#
# WARNING: Running nscd with a secondary caching service like sssd may lead to
#          unexpected behaviour, especially with how long entries are cached.

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:     files sss
shadow:     files sss
group:      files sss
#initgroups: files sss

#hosts:     db files nisplus nis dns
hosts:      files dns myhostname

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   nisplus sss

publickey:  nisplus

automount:  files nisplus sss
aliases:    files nisplus

ネットワークの通信経路の確認

練習問題

3.1 ARPキャッシュを表示したりエントリーを追加したりするときに利用するコマンド
- arp
3.2 tcpdumpコマンドの出力の一部。適切な説明を選択
- 接続元IPアドレス.ポート番号(サービス名) > 接続先IPアドレス.ポート番号(サービス名)
3.3 routeコマンドを実行したときの表示
3.4 routeコマンドの使い方
- route add -net 192.168.100.0 netmask 255.255.255.0 gw 172.16.100.1
3.5 ルーティングテーブルを表示するコマンド
- route
- ip route show
- netstat -r
3.6 /etc/resolv.confの記述
- nameserver 172.16.0.1
3.7 www.example.comに到達するまでに経由するルーター一覧を表示して経路を確認したい場合、役立つコマンド
- traceroute6
- mtr

第4章　システムの保守と運用管理

4.1　makeによるソースコードからのビルドとインストール

tar cvf
tar xvf
tar tvf
gzip
gunzip
bzip
bunzip

4.2　バックアップ

バックアップの種類
- 完全バックアップ：時間がかかり容量も必要
- 差分バックアップ：復元にはフルバックアップと最新の差分バックアップが必要
- 増分バックアップ：復元にはフルバックアップとフルバックアップ以降のすべての増分バックアップが必要
バックアップデバイス
- CD-R/RW、リムーバブルハードディスク
- DVD-R/RW
- BD-R/RE
- 磁気テープ
- ネットワーク
ローカルでのバックアップ
- tar,dd,dump,restoreなどのコマンドでバックアップが可能

# OP,形式と拡張子
# -j bzip -> bz2
# -z gzip -> gz
# -J xz - xz

# このコマンドをあわせて使う使い方は必要に応じて調べるで良さそう
dump
restore

# テープドライブを操作するコマンド
mt

# ネットワーク経由でのバックアップ
rsync

4.3　ユーザーへのシステム管理情報の通知

ログイン前後のメッセージ
- /etc/issue: 接続前に表示されるメッセージ　telnet接続だと表示される sshだとログイン前メッセージが表示されない（Teratermとコマンドプロンプト）
- /etc/issue.net: 接続前に表示されるメッセージ　telnet接続だと表示される sshだとログイン前メッセージが表示されない（Teratermとコマンドプロンプト）
- /etc/motd: 接続後に表示されるメッセージ
ログイン中のユーザへの通知
- wall "message"
- shutdown -k now "message"
https://qiita.com/montblanc18/items/8b4fd2cf150913c6e1c2
- telnetを有効にする方法で参考

4.4　リソース使用状況の把握

CPU使用率やメモリの状況など、システムリソースを総合的に確認できるツール
- top
- vmstat
EPELリポジトリ epelリポジトリを追加方法
- https://linuc.spa-miz.com/2020/10/13/installing-htop-centos/

top
htop
vmstat
iostat
iotop
sar
uptime # システムの稼働時間やログインユーザー数、平均負荷などが表示される。topコマンドの１行目とほぼ同じ
w # 現在ログインしているユーザと各ユーザのプロセス情報が表示される

# CPU使用率の測定
ps
ps aux: システムで使用されているすべてのプロセスを表示

# 開いているファイルやポートの確認
lsof
# /var/log/messagesファイルを開いているプロセスを検索
[root@localhost top]# lsof /var/log/messages
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
abrt-watc  914 root    4r   REG  253,0   718793 10468097 /var/log/messages
rsyslogd  1338 root    7w   REG  253,0   718793 10468097 /var/log/messages
# プロセス名が開いているファイルを表示
[root@localhost top]# lsof -p `pidof rsyslogd`
COMMAND   PID USER   FD      TYPE             DEVICE SIZE/OFF     NODE NAME
rsyslogd 1338 root  cwd       DIR              253,0      224       64 /
rsyslogd 1338 root  rtd       DIR              253,0      224       64 /
rsyslogd 1338 root  txt       REG              253,0   663976  3172893 /usr/sbin/rsyslogd
rsyslogd 1338 root  mem       REG               0,19  8388608     8307 /run/log/journal/4f887155365a419b9cb02e497221d5a4/system.journal
rsyslogd 1338 root  mem       REG              253,0    68192   176358 /usr/lib64/libbz2.so.1.0.6
rsyslogd 1338 root  mem       REG              253,0    99944   176516 /usr/lib64/libelf-0.176.so
rsyslogd 1338 root  mem       REG              253,0   402384   383771 /usr/lib64/libpcre.so.1.2.0
rsyslogd 1338 root  mem       REG              253,0    19896   176626 /usr/lib64/libattr.so.1.1.0
rsyslogd 1338 root  mem       REG              253,0   338672  1300052 /usr/lib64/libdw-0.176.so
rsyslogd 1338 root  mem       REG              253,0   109976   383691 /usr/lib64/libresolv-2.17.so
rsyslogd 1338 root  mem       REG              253,0    19384   176460 /usr/lib64/libgpg-error.so.0.10.0
rsyslogd 1338 root  mem       REG              253,0   535064   176472 /usr/lib64/libgcrypt.so.11.8.2
rsyslogd 1338 root  mem       REG              253,0    61752   270256 /usr/lib64/liblz4.so.1.8.3
rsyslogd 1338 root  mem       REG              253,0   157424   176353 /usr/lib64/liblzma.so.5.2.2
rsyslogd 1338 root  mem       REG              253,0   155744   176263 /usr/lib64/libselinux.so.1
rsyslogd 1338 root  mem       REG              253,0  1136944   383671 /usr/lib64/libm-2.17.so
rsyslogd 1338 root  mem       REG              253,0    20048   176631 /usr/lib64/libcap.so.2.22
rsyslogd 1338 root  mem       REG              253,0   203688  1300065 /usr/lib64/libsystemd.so.0.6.0
rsyslogd 1338 root  mem       REG              253,0    25024  5817422 /usr/lib64/rsyslog/imjournal.so
rsyslogd 1338 root  mem       REG              253,0    38048  5817429 /usr/lib64/rsyslog/imuxsock.so
rsyslogd 1338 root  mem       REG              253,0    24432  5817430 /usr/lib64/rsyslog/lmnet.so
rsyslogd 1338 root  mem       REG              253,0  2156272   383663 /usr/lib64/libc-2.17.so
rsyslogd 1338 root  mem       REG              253,0    88720       85 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
rsyslogd 1338 root  mem       REG              253,0    20064   176270 /usr/lib64/libuuid.so.1.3.0
rsyslogd 1338 root  mem       REG              253,0    40896  1245966 /usr/lib64/libfastjson.so.4.0.0
rsyslogd 1338 root  mem       REG              253,0    15424  1299766 /usr/lib64/libestr.so.0.0.0
rsyslogd 1338 root  mem       REG              253,0    43712   383693 /usr/lib64/librt-2.17.so
rsyslogd 1338 root  mem       REG              253,0    19248   383669 /usr/lib64/libdl-2.17.so
rsyslogd 1338 root  mem       REG              253,0   142144   383689 /usr/lib64/libpthread-2.17.so
rsyslogd 1338 root  mem       REG              253,0    90248   176266 /usr/lib64/libz.so.1.2.7
rsyslogd 1338 root  mem       REG              253,0   163312   383656 /usr/lib64/ld-2.17.so
rsyslogd 1338 root    0r      CHR                1,3      0t0     1028 /dev/null
rsyslogd 1338 root    1w      CHR                1,3      0t0     1028 /dev/null
rsyslogd 1338 root    2w      CHR                1,3      0t0     1028 /dev/null
rsyslogd 1338 root    3r  a_inode               0,10        0     6415 inotify
rsyslogd 1338 root    4u     unix 0xffff8e7135db5940      0t0    23333 socket
rsyslogd 1338 root    5r      REG               0,19  8388608     8307 /run/log/journal/4f887155365a419b9cb02e497221d5a4/system.journal
rsyslogd 1338 root    6w      REG              253,0    18803  8671877 /var/log/cron
rsyslogd 1338 root    7w      REG              253,0   718793 10468097 /var/log/messages
rsyslogd 1338 root    8w      REG              253,0    20795 10468098 /var/log/secure
rsyslogd 1338 root    9w      REG              253,0     1639 10468099 /var/log/maillog


### メモリ及びスワップ使用量の測定
# メモリ使用率を測定するには、先に上げたtop,sadc/sarコマンドなどが利用できる他freeコマンドも利用できる
# Linuxは、使われていない物理メモリをできるだけキャッシュに割り当てようとします。
# そのため、Linuxの起動時間が長くなればなるほど、Mem行のfree列の値は小さくなっていきます。
# その値が小さくても、キャッシュに割り当てられているサイズが大きいのであれば、実際にメモリが足りないわけではない、ということに注意してください。
# available列を見ると、おおよその利用可能なメモリ量がわかります。スワップはディスクの一部を仮想的なメモリとして利用する機能です。
# システムの物理メモリが不足するとスワップが行われます。スワップ領域が継続的に使われるようであれば、システムのパフォーマンスが低下します。
# そのため、システムが利用しているメモリ量を把握することは必要です。前記の例ではスワップは利用されていませんが、スワップが頻繁に利用されるようなら、
# 不要なサービスを停止させるか、メモリの増設を検討する必要があります。freeコマンド以上に詳細なメモリの情報を得るには、/proc/meminfoを参照します。


### ディスク使用量の測定
df

### ネットワークトラフィックの測定
netstat -s
ss -s

netserver
netperf
iptables
iftop

# この辺詳細ちょっとおいきれてないので後で振り返り

4.5　死活監視と運用監視ツール

リソースの枯渇
- スラッシング：アプリが使うメモリ領域が肥大し、空きメモリがなくなるとメモリの一部がスワップ領域に移されその分のメモリが開放される
  - さらにメモリ不足が継続すると、スワップ領域への対比が頻発市、システムの動作が大幅に遅くなってしまうこと
システムの過負荷
サービスの以上
OOMKiller
- cat /proc/sys/vm/panic_on_oomこれが0であればOOM Killerは動作しない、1であれば動作する
- 真っ先にOOM Killerに強制終了されるプロセスはdstatコマンドで調べることができる
- dstat --top-oom
- pidof python2 dstatコマンドで出力されるのはこの値が最も高いプロセス
- 強制終了の優先度を変更するには、/proc/PID/oom_adjファイルに値を書き込む
監視作業
- 死活監視
- リソース監視
- ログ監視
  - swatch: simple log watcherが古くから使われている
SNMP: ネットワーク上のサーバーやネットワーク機器を監視できるプロトコル
- SNMPマネージャ：監視する側
- SNMPエージェント：監視される側
- 監視の仕組み：
  - SNMPマネージャ側からSNMPエージェント側に情報を求める（ポーリング）
  - SNMPエージェント側からSNMPマネージャ側に通知する
    - ポーリングには、SNMPエージェント側のUDP161ポート、SNMPマネージャ側のUDP162ポートが使われる
システム運用監視ツール
- collectd: システムの各種情報を定期的に収集する軽量なデーモン
- Nagios
- MRTG (Multi Router Traffic Grapher)
- Cacti
- Icinga2
- Zabbix

4.6　システム構成ツール

Ansibleの概要
- YAML形式のテキストファイルで設定
- Pythonが動けば使える
コントロールノードとターゲットノード
- コントロールノード：システム構成処理の指示を出すホスト
- ターゲットノード：コントロールノードによってシステム構成処理が実行されるホスト
インベントリとPlaybook
- インベントリ:
  - ターゲットノードのリストが記述される
  - 複数のターゲットノードをまとめたグループも設定できる
- Playbook:
  - ターゲットノードで実施するシステム構成処理が記述される
モジュール: Ansibleの構成管理機能を実現するため、数多くのモジュールが提供されている
Ansibleの基本的な設定
- /etc/ansible/ansible.cfg

[root@localhost 1340]# cat /etc/ansible/ansible.cfg
# config file for ansible -- https://ansible.com/
# ===============================================

# nearly all parameters can be overridden in ansible-playbook
# or with command line flags. ansible will read ANSIBLE_CONFIG,
# ansible.cfg in the current working directory, .ansible.cfg in
# the home directory or /etc/ansible/ansible.cfg, whichever it
# finds first

[defaults]

# some basic default values...

#inventory      = /etc/ansible/hosts
#library        = /usr/share/my_modules/
#module_utils   = /usr/share/my_module_utils/
#remote_tmp     = ~/.ansible/tmp
#local_tmp      = ~/.ansible/tmp
#plugin_filters_cfg = /etc/ansible/plugin_filters.yml
#forks          = 5
#poll_interval  = 15
#sudo_user      = root
#ask_sudo_pass = True
#ask_pass      = True
#transport      = smart
#remote_port    = 22
#module_lang    = C
#module_set_locale = False

# plays will gather facts by default, which contain information about
# the remote system.
#
# smart - gather by default, but don't regather if already gathered
# implicit - gather by default, turn off with gather_facts: False
# explicit - do not gather by default, must say gather_facts: True
#gathering = implicit

# This only affects the gathering done by a play's gather_facts directive,
# by default gathering retrieves all facts subsets
# all - gather all subsets
# network - gather min and network facts
# hardware - gather hardware facts (longest facts to retrieve)
# virtual - gather min and virtual facts
# facter - import facts from facter
# ohai - import facts from ohai
# You can combine them using comma (ex: network,virtual)
# You can negate them using ! (ex: !hardware,!facter,!ohai)
# A minimal set of facts is always gathered.
#gather_subset = all

# some hardware related facts are collected
# with a maximum timeout of 10 seconds. This
# option lets you increase or decrease that
# timeout to something more suitable for the
# environment.
# gather_timeout = 10

# Ansible facts are available inside the ansible_facts.* dictionary
# namespace. This setting maintains the behaviour which was the default prior
# to 2.5, duplicating these variables into the main namespace, each with a
# prefix of 'ansible_'.
# This variable is set to True by default for backwards compatibility. It
# will be changed to a default of 'False' in a future release.
# ansible_facts.
# inject_facts_as_vars = True

# additional paths to search for roles in, colon separated
#roles_path    = /etc/ansible/roles

# uncomment this to disable SSH key host checking
#host_key_checking = False

# change the default callback, you can only have one 'stdout' type  enabled at a time.
#stdout_callback = skippy


## Ansible ships with some plugins that require whitelisting,
## this is done to avoid running all of a type by default.
## These setting lists those that you want enabled for your system.
## Custom plugins should not need this unless plugin author specifies it.

# enable callback plugins, they can output to stdout but cannot be 'stdout' type.
#callback_whitelist = timer, mail

# Determine whether includes in tasks and handlers are "static" by
# default. As of 2.0, includes are dynamic by default. Setting these
# values to True will make includes behave more like they did in the
# 1.x versions.
#task_includes_static = False
#handler_includes_static = False

# Controls if a missing handler for a notification event is an error or a warning
#error_on_missing_handler = True

# change this for alternative sudo implementations
#sudo_exe = sudo

# What flags to pass to sudo
# WARNING: leaving out the defaults might create unexpected behaviours
#sudo_flags = -H -S -n

# SSH timeout
#timeout = 10

# default user to use for playbooks if user is not specified
# (/usr/bin/ansible will use current user as default)
#remote_user = root

# logging is off by default unless this path is defined
# if so defined, consider logrotate
#log_path = /var/log/ansible.log

# default module name for /usr/bin/ansible
#module_name = command

# use this shell for commands executed under sudo
# you may need to change this to bin/bash in rare instances
# if sudo is constrained
#executable = /bin/sh

# if inventory variables overlap, does the higher precedence one win
# or are hash values merged together?  The default is 'replace' but
# this can also be set to 'merge'.
#hash_behaviour = replace

# by default, variables from roles will be visible in the global variable
# scope. To prevent this, the following option can be enabled, and only
# tasks and handlers within the role will see the variables there
#private_role_vars = yes

# list any Jinja2 extensions to enable here:
#jinja2_extensions = jinja2.ext.do,jinja2.ext.i18n

# if set, always use this private key file for authentication, same as
# if passing --private-key to ansible or ansible-playbook
#private_key_file = /path/to/file

# If set, configures the path to the Vault password file as an alternative to
# specifying --vault-password-file on the command line.
#vault_password_file = /path/to/vault_password_file

# format of string {{ ansible_managed }} available within Jinja2
# templates indicates to users editing templates files will be replaced.
# replacing {file}, {host} and {uid} and strftime codes with proper values.
#ansible_managed = Ansible managed: {file} modified on %Y-%m-%d %H:%M:%S by {uid} on {host}
# {file}, {host}, {uid}, and the timestamp can all interfere with idempotence
# in some situations so the default is a static string:
#ansible_managed = Ansible managed

# by default, ansible-playbook will display "Skipping [host]" if it determines a task
# should not be run on a host.  Set this to "False" if you don't want to see these "Skipping"
# messages. NOTE: the task header will still be shown regardless of whether or not the
# task is skipped.
#display_skipped_hosts = True

# by default, if a task in a playbook does not include a name: field then
# ansible-playbook will construct a header that includes the task's action but
# not the task's args.  This is a security feature because ansible cannot know
# if the *module* considers an argument to be no_log at the time that the
# header is printed.  If your environment doesn't have a problem securing
# stdout from ansible-playbook (or you have manually specified no_log in your
# playbook on all of the tasks where you have secret information) then you can
# safely set this to True to get more informative messages.
#display_args_to_stdout = False

# by default (as of 1.3), Ansible will raise errors when attempting to dereference
# Jinja2 variables that are not set in templates or action lines. Uncomment this line
# to revert the behavior to pre-1.3.
#error_on_undefined_vars = False

# by default (as of 1.6), Ansible may display warnings based on the configuration of the
# system running ansible itself. This may include warnings about 3rd party packages or
# other conditions that should be resolved if possible.
# to disable these warnings, set the following value to False:
#system_warnings = True

# by default (as of 1.4), Ansible may display deprecation warnings for language
# features that should no longer be used and will be removed in future versions.
# to disable these warnings, set the following value to False:
#deprecation_warnings = True

# (as of 1.8), Ansible can optionally warn when usage of the shell and
# command module appear to be simplified by using a default Ansible module
# instead.  These warnings can be silenced by adjusting the following
# setting or adding warn=yes or warn=no to the end of the command line
# parameter string.  This will for example suggest using the git module
# instead of shelling out to the git command.
# command_warnings = False


# set plugin path directories here, separate with colons
#action_plugins     = /usr/share/ansible/plugins/action
#become_plugins     = /usr/share/ansible/plugins/become
#cache_plugins      = /usr/share/ansible/plugins/cache
#callback_plugins   = /usr/share/ansible/plugins/callback
#connection_plugins = /usr/share/ansible/plugins/connection
#lookup_plugins     = /usr/share/ansible/plugins/lookup
#inventory_plugins  = /usr/share/ansible/plugins/inventory
#vars_plugins       = /usr/share/ansible/plugins/vars
#filter_plugins     = /usr/share/ansible/plugins/filter
#test_plugins       = /usr/share/ansible/plugins/test
#terminal_plugins   = /usr/share/ansible/plugins/terminal
#strategy_plugins   = /usr/share/ansible/plugins/strategy


# by default, ansible will use the 'linear' strategy but you may want to try
# another one
#strategy = free

# by default callbacks are not loaded for /bin/ansible, enable this if you
# want, for example, a notification or logging callback to also apply to
# /bin/ansible runs
#bin_ansible_callbacks = False


# don't like cows?  that's unfortunate.
# set to 1 if you don't want cowsay support or export ANSIBLE_NOCOWS=1
#nocows = 1

# set which cowsay stencil you'd like to use by default. When set to 'random',
# a random stencil will be selected for each task. The selection will be filtered
# against the `cow_whitelist` option below.
#cow_selection = default
#cow_selection = random

# when using the 'random' option for cowsay, stencils will be restricted to this list.
# it should be formatted as a comma-separated list with no spaces between names.
# NOTE: line continuations here are for formatting purposes only, as the INI parser
#       in python does not support them.
#cow_whitelist=bud-frogs,bunny,cheese,daemon,default,dragon,elephant-in-snake,elephant,eyes,\
#              hellokitty,kitty,luke-koala,meow,milk,moofasa,moose,ren,sheep,small,stegosaurus,\
#              stimpy,supermilker,three-eyes,turkey,turtle,tux,udder,vader-koala,vader,www

# don't like colors either?
# set to 1 if you don't want colors, or export ANSIBLE_NOCOLOR=1
#nocolor = 1

# if set to a persistent type (not 'memory', for example 'redis') fact values
# from previous runs in Ansible will be stored.  This may be useful when
# wanting to use, for example, IP information from one group of servers
# without having to talk to them in the same playbook run to get their
# current IP information.
#fact_caching = memory

#This option tells Ansible where to cache facts. The value is plugin dependent.
#For the jsonfile plugin, it should be a path to a local directory.
#For the redis plugin, the value is a host:port:database triplet: fact_caching_connection = localhost:6379:0

#fact_caching_connection=/tmp



# retry files
# When a playbook fails a .retry file can be created that will be placed in ~/
# You can enable this feature by setting retry_files_enabled to True
# and you can change the location of the files by setting retry_files_save_path

#retry_files_enabled = False
#retry_files_save_path = ~/.ansible-retry

# squash actions
# Ansible can optimise actions that call modules with list parameters
# when looping. Instead of calling the module once per with_ item, the
# module is called once with all items at once. Currently this only works
# under limited circumstances, and only with parameters named 'name'.
#squash_actions = apk,apt,dnf,homebrew,pacman,pkgng,yum,zypper

# prevents logging of task data, off by default
#no_log = False

# prevents logging of tasks, but only on the targets, data is still logged on the master/controller
#no_target_syslog = False

# controls whether Ansible will raise an error or warning if a task has no
# choice but to create world readable temporary files to execute a module on
# the remote machine.  This option is False by default for security.  Users may
# turn this on to have behaviour more like Ansible prior to 2.1.x.  See
# https://docs.ansible.com/ansible/become.html#becoming-an-unprivileged-user
# for more secure ways to fix this than enabling this option.
#allow_world_readable_tmpfiles = False

# controls the compression level of variables sent to
# worker processes. At the default of 0, no compression
# is used. This value must be an integer from 0 to 9.
#var_compression_level = 9

# controls what compression method is used for new-style ansible modules when
# they are sent to the remote system.  The compression types depend on having
# support compiled into both the controller's python and the client's python.
# The names should match with the python Zipfile compression types:
# * ZIP_STORED (no compression. available everywhere)
# * ZIP_DEFLATED (uses zlib, the default)
# These values may be set per host via the ansible_module_compression inventory
# variable
#module_compression = 'ZIP_DEFLATED'

# This controls the cutoff point (in bytes) on --diff for files
# set to 0 for unlimited (RAM may suffer!).
#max_diff_size = 1048576

# This controls how ansible handles multiple --tags and --skip-tags arguments
# on the CLI.  If this is True then multiple arguments are merged together.  If
# it is False, then the last specified argument is used and the others are ignored.
# This option will be removed in 2.8.
#merge_multiple_cli_flags = True

# Controls showing custom stats at the end, off by default
#show_custom_stats = True

# Controls which files to ignore when using a directory as inventory with
# possibly multiple sources (both static and dynamic)
#inventory_ignore_extensions = ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo

# This family of modules use an alternative execution path optimized for network appliances
# only update this setting if you know how this works, otherwise it can break module execution
#network_group_modules=eos, nxos, ios, iosxr, junos, vyos

# When enabled, this option allows lookups (via variables like {{lookup('foo')}} or when used as
# a loop with `with_foo`) to return data that is not marked "unsafe". This means the data may contain
# jinja2 templating language which will be run through the templating engine.
# ENABLING THIS COULD BE A SECURITY RISK
#allow_unsafe_lookups = False

# set default errors for all plays
#any_errors_fatal = False

[inventory]
# enable inventory plugins, default: 'host_list', 'script', 'auto', 'yaml', 'ini', 'toml'
#enable_plugins = host_list, virtualbox, yaml, constructed

# ignore these extensions when parsing a directory as inventory source
#ignore_extensions = .pyc, .pyo, .swp, .bak, ~, .rpm, .md, .txt, ~, .orig, .ini, .cfg, .retry

# ignore files matching these patterns when parsing a directory as inventory source
#ignore_patterns=

# If 'true' unparsed inventory sources become fatal errors, they are warnings otherwise.
#unparsed_is_failed=False

[privilege_escalation]
#become=True
#become_method=sudo
#become_user=root
#become_ask_pass=False

[paramiko_connection]

# uncomment this line to cause the paramiko connection plugin to not record new host
# keys encountered.  Increases performance on new host additions.  Setting works independently of the
# host key checking setting above.
#record_host_keys=False

# by default, Ansible requests a pseudo-terminal for commands executed under sudo. Uncomment this
# line to disable this behaviour.
#pty=False

# paramiko will default to looking for SSH keys initially when trying to
# authenticate to remote devices.  This is a problem for some network devices
# that close the connection after a key failure.  Uncomment this line to
# disable the Paramiko look for keys function
#look_for_keys = False

# When using persistent connections with Paramiko, the connection runs in a
# background process.  If the host doesn't already have a valid SSH key, by
# default Ansible will prompt to add the host key.  This will cause connections
# running in background processes to fail.  Uncomment this line to have
# Paramiko automatically add host keys.
#host_key_auto_add = True

[ssh_connection]

# ssh arguments to use
# Leaving off ControlPersist will result in poor performance, so use
# paramiko on older platforms rather than removing it, -C controls compression use
#ssh_args = -C -o ControlMaster=auto -o ControlPersist=60s

# The base directory for the ControlPath sockets.
# This is the "%(directory)s" in the control_path option
#
# Example:
# control_path_dir = /tmp/.ansible/cp
#control_path_dir = ~/.ansible/cp

# The path to use for the ControlPath sockets. This defaults to a hashed string of the hostname,
# port and username (empty string in the config). The hash mitigates a common problem users
# found with long hostnames and the conventional %(directory)s/ansible-ssh-%%h-%%p-%%r format.
# In those cases, a "too long for Unix domain socket" ssh error would occur.
#
# Example:
# control_path = %(directory)s/%%h-%%r
#control_path =

# Enabling pipelining reduces the number of SSH operations required to
# execute a module on the remote server. This can result in a significant
# performance improvement when enabled, however when using "sudo:" you must
# first disable 'requiretty' in /etc/sudoers
#
# By default, this option is disabled to preserve compatibility with
# sudoers configurations that have requiretty (the default on many distros).
#
#pipelining = False

# Control the mechanism for transferring files (old)
#   * smart = try sftp and then try scp [default]
#   * True = use scp only
#   * False = use sftp only
#scp_if_ssh = smart

# Control the mechanism for transferring files (new)
# If set, this will override the scp_if_ssh option
#   * sftp  = use sftp to transfer files
#   * scp   = use scp to transfer files
#   * piped = use 'dd' over SSH to transfer files
#   * smart = try sftp, scp, and piped, in that order [default]
#transfer_method = smart

# if False, sftp will not use batch mode to transfer files. This may cause some
# types of file transfer failures impossible to catch however, and should
# only be disabled if your sftp version has problems with batch mode
#sftp_batch_mode = False

# The -tt argument is passed to ssh when pipelining is not enabled because sudo
# requires a tty by default.
#usetty = True

# Number of times to retry an SSH connection to a host, in case of UNREACHABLE.
# For each retry attempt, there is an exponential backoff,
# so after the first attempt there is 1s wait, then 2s, 4s etc. up to 30s (max).
#retries = 3

[persistent_connection]

# Configures the persistent connection timeout value in seconds.  This value is
# how long the persistent connection will remain idle before it is destroyed.
# If the connection doesn't receive a request before the timeout value
# expires, the connection is shutdown. The default value is 30 seconds.
#connect_timeout = 30

# The command timeout value defines the amount of time to wait for a command
# or RPC call before timing out. The value for the command timeout must
# be less than the value of the persistent connection idle timeout (connect_timeout)
# The default value is 30 second.
#command_timeout = 30

[accelerate]
#accelerate_port = 5099
#accelerate_timeout = 30
#accelerate_connect_timeout = 5.0

# The daemon timeout is measured in minutes. This time is measured
# from the last activity to the accelerate daemon.
#accelerate_daemon_timeout = 30

# If set to yes, accelerate_multi_key will allow multiple
# private keys to be uploaded to it, though each user must
# have access to the system via SSH to add a new key. The default
# is "no".
#accelerate_multi_key = yes

[selinux]
# file systems that require special treatment when dealing with security context
# the default behaviour that copies the existing context or uses the user default
# needs to be changed to use the file system dependent context.
#special_context_filesystems=nfs,vboxsf,fuse,ramfs,9p,vfat

# Set this to yes to allow libvirt_lxc connections to work without SELinux.
#libvirt_lxc_noseclabel = yes

[colors]
#highlight = white
#verbose = blue
#warn = bright purple
#error = red
#debug = dark gray
#deprecate = purple
#skip = cyan
#unreachable = red
#ok = green
#changed = yellow
#diff_add = green
#diff_remove = red
#diff_lines = cyan


[diff]
# Always print diff when running ( same as always running with -D/--diff )
# always = no

# Set how many context lines to show in diff
# context = 3

/etc/ansible/hosts

[root@localhost 1340]# cat /etc/ansible/hosts
# This is the default ansible 'hosts' file.
#
# It should live in /etc/ansible/hosts
#
#   - Comments begin with the '#' character
#   - Blank lines are ignored
#   - Groups of hosts are delimited by [header] elements
#   - You can enter hostnames or ip addresses
#   - A hostname/ip can be a member of multiple groups

# Ex 1: Ungrouped hosts, specify before any group headers.

## green.example.com
## blue.example.com
## 192.168.100.1
## 192.168.100.10

# Ex 2: A collection of hosts belonging to the 'webservers' group

## [webservers]
## alpha.example.org
## beta.example.org
## 192.168.1.100
## 192.168.1.110

# If you have multiple hosts following a pattern you can specify
# them like this:

## www[001:006].example.com

# Ex 3: A collection of database servers in the 'dbservers' group

## [dbservers]
##
## db01.intranet.mydomain.net
## db02.intranet.mydomain.net
## 10.25.1.56
## 10.25.1.57

# Here's another example of host ranges, this time there are no
# leading 0s:

## db-[99:101]-node.example.com

Playbook
- YAML形式で記載する
- 実行するにはansible-playbookコマンドを使う
Ansibleの活用
- アプリケーションのリリース
- 仮想サーバー・コンテナの払い出し
  - KVMによる仮想マシンや、Dockerコンテナ、コンテナイメージの作成などを自動化できる
- ネットワーク機器の管理
  - CISCOを始めとするネットワークベンダーの様々なネットワーク機器に対応しており、ネットワーク機器の設定や情報収集に利用できる

練習問題

4.1 gitコマンド
- git clone http://github/xxxx
4.2 gzファイルを展開する方法
- gunzip newsoft.tar.gx ; tar xvf newsoft.tar
- tar zxvf newsoft.tar.gz
- gzip -dc newsoft.tar.gz | tar xvf -
4.3 make
- ./configureでMackefileを作成
- makeコマンドでMakefileに基づいてコンパイルを行う
- make installコマンドでコンパイル済みのファイルをインストール
4.4 パッチの適用を取り消すには？patchコマンドでなんというオプション？
- R
4.5 dd if=/dev/sdb of=/dev/sdc
4.6 tar cvf /dev/st0 /home
- tar [option] [アーカイブ先] [アーカイブ元]
4.7 /dataディレクトリ以下を、ホストjupiterの/backupディレクトリにバックアップ
- rsync -auvz -e ssh /data/ march@jupiter:/backup
- TODO: rsyncコマンド使ってみる
4.8 メンテナンス情報を通知する方法
4.9 スワップ領域がどの程度利用されているのか、その容量を計測したい場合のコマンド
- vmstat,cat /proc/swaps,free
- swapon,/proc/meminfo
4.10 vmstatコマンドで使用率が高いと考えられるリソース
- TODO: vmstatコマンドの見方再確認
4.11 sarで今月の15日の記録を見たい
- sar -b -f /var/log/sa/sa15
4.12 次のコマンド実行結果の説明
- vmstat 30 50
  - 30秒間隔で計測結果が50回表示される
  - 使用中のスワップ領域サイズが表示される
  - バッファキャッシュとページキャッシュの利用状況が表示される
4.13 プロセスごとにメモリ使用量を把握したい
- top
- ps auxでもわかる。ps -exは、Unix98オプションとGNUオプションを続けて指定できないためエラーになる
4.14 物理メモリが枯渇してしまう前にプロセスを強制終了し、そのプロセスが使っていたメモリを開放する仕組み
- OOM Killer
4.15 Ansibleの説明について
4.16 Ansilbeをインストール下ホストで以下のコマンドを実行
- ansible-playbook -i localtest test_playbook.yml
- TODO: ansibleを実際に使ってみる必要ある

第5章　仮想化サーバー

5.1　仮想マシンの仕組みとKVM

仮想化
- ホスト型仮想化：仮想化ソフトウェアをインストールし、仮想化ソフトウェアが作り出した仮想マシン上にOSをインストールする方式
  - ホストOSとゲストOSに分けられる
- ハイパーバイザー型仮想化：コンピュータ上にハイパーバイザと呼ばれる仮想化管理機構を用意し、その上で仮想マシンを動かす方式
  - ホスト型仮想化よりも高いパフォーマンスを期待できる
仮想化のメリット・デメリット
- メリット：
  - トータルの運用コストを削減できる
  - リソースの変化に柔軟に対応できる
- デメリット：
  - 仮想マシンのホストに障害が発生したい場合、複数の仮想マシンが影響
  - 物理サーバとは違った形での運用スキルやセキュリティ対策が必要
  - ハードウェア上で直接OSを動作させるのに比べてパフォーマンスが低下してしまう
    - オーバーヘッドを低減するCPUの仮想化支援機能
      - Intel社のCPUに搭載されているVT-x
      - AMD社のCPUに搭載されているADM-V
KVM
- CPUが仮想化支援機構に対応しているかどうかを確認するコマンド：
  - lscpu | grep Virtualization
  - grep -E 'vmx|svm' /proc/cpuinfo

5.2　仮想マシンの作成と管理

KVM環境の構築
- 手順
  - KVMと関連ツールおよびQEMU(ハードウェアエミュレータ)をインストール
    - yum install libvirt bridge-utils qemu-kvm virt-manager virt-install
    - systemctl start libvirt
    - systemctl enable libvirt
  - ブリッジネットワークを設定する
    - nmcli con add type bridge con-name br0 ifname br0
    - nmcli con mod br0 ipv4.method manual ipv4.addresses "192.168.1.80/24" ipv4.gateway "192.168.1.1" ipv4.dns "192.168.1.1"
  - 仮想マシンを作成する
実際にvirshを使った操作が紹介されているが試す環境ないので割愛

練習問題

5.1 ホスト型とハイパーバイザ型の問題
5.2 cat /proc/cpuinfo | grep flags | uniq
- KVMを利用するには、CPUが仮想化支援機能に対応している必要がある（IntelのVT-xかAMDのAMD-V）
- 中の文字列に、「vmx」か「svm」がなければ対応しない
5.3 CUI環境でKVM観葉マシンを作成してゲストOSをインストールするには
- virt-installコマンドを使う
5.4 KVMを使って仮想マシンを運用したい
- systemctl enamble libvirt
  - libvirtは仮想マシンの制御を抽象化したライブラリ
  - KVMを使って仮想マシンを運用するには、libvirtサービスを起動しておく必要がある
5.5 KVM仮想マシンを作成してCentOS7をインストールしたい
- virt-installコマンド
5.6 コマンドラインからKVM仮想マシン「vm01」に接続してコマンド操作をしようとしています。
- virsh console vm01

第6章　コンテナ

6.1　コンテナの仕組み

仮想マシンと並んでよく使われる仮想化技術

コンテナ型仮想化
- 仮想マシンを動かす技術ではなく、独立下環境でアプリケーションを動かす技術
- コンテナ型仮想化ではホストOSとカーネルを共有するので仮想マシンよりもコンテナのほうがシステムリソースの消費が少なくて済む
参考
- 特定のサーバープロセスなどアプリケーションのみを実行するコンテナをアプリケーションコンテナ
- 一連のシステムプロセス群を実行し仮想マシンに近いコンテナをシステムコンテナということがあります。
名前空間とcgroup
- 名前空間
  - コンテナの隔離に使われているカーネルの機能のこと
- cgroup
  - プロセスをグループ化して管理する仕組み
  - グループごとにシステムリソースの利用に制限をかけることができる
  - 管理できるシステムリソースはls /sys/fs/cgroup/で確認できる
Docker
- コンテナ化する仕組みをDockerエンジンといいます。

6.2　Dockerコンテナとコンテナイメージの管理

Dockerの導入
- yum install docker
- systemctl start docker.service
- docker version
dockerコマンド
- 実行するにはroot権限が必要
- 一般ユーザでも実行させるにはdockerグループに所属させる必要がある
- groupadd docker
- usermod -aG docker linucuser
dockerの基本操作
- コンテナイメージの取得
  - docker pull centos:8
ディスク容量不足になったのでvirtualboxの容量増やす
- https://cream-worker.blog.jp/archives/1077340749.html

docker pull centos:8
docker images
docker create --name mycentos8 centos:8
docker start mycentos8
# dokcer pull/create/start をあわせた動きが docekr runコマンド
docker run centos:8 cat /etc/redhat-release
docker ps
docker ps -a
docker rm [コンテナIDorコンテナ名]

# コンテナへのログイン
# docker run -it --name コンテナ名 イメージ名:タグ名 シェル
docker run -it --name mucentos centos:8 /bin/bash
uname -a # あくまでホストOSのカーネル情報が見える
Ctrl + p, Ctrl + q で抜ける
docker ps # プロセスが立ち上がっていることを確認
docker attach mycentos
exit # exitで抜けるとcontainerが落ちる
docker ps

仮想ネットワークの利用

docker run -itd --name centosA cenots:8 /bin/bash
docker run -itd --name centosB cenots:8 /bin/bash
docker ps
docker exec centosA /sbin/ip a
docker exec centosB /sbin/ip a

# ホストOS側にdocker0というネットワークインターフェースが作成されているのがわかる
ip a show docker0

# 仮想ネットワークを新しく作成することもできる
docker network create mynetwork
docker network connect mynetwork centosA
docker network connect mynetwork centosB

docker exec centosA /sbin/ip a
docker exec centosB /sbin/ip a

dockerイメージの作成

docker run -it centos:8 /bin/bash

echo "My Docker Image" >> /root/docker.txt
exit

docker commit [コンテナID/コンテナ名] test/centos
docker images

docker run test/centos cat /root/docker.txt
docker rmi test/centos

ポート変換

docker run --name nginxtest -d -p 8080:80 nginx

docker run --name nginxtest2 -v /home/tomo/html:/usr/share/nginx/html -d -p 8080:80 nginx
# 権限が足りずうまく行かなかった

Dcokerfile
- 既存のDockerイメージに操作を加えて、新しいDockerイメージを作ることができる
- Dockerfileに記述して独自のイメージを作成する

FROM centos:8
MAINTAINER testimage <linucuser@example.com>

RUN yum -y install httpd

EXPOSE 80

CMD ["/usr/sbin/httpd","-DFOREGROUND"]

docker build -t local/centos:apache .
docker images

# 作成したDockerイメージからコンテナ名「apachetest」としてコンテナを作成、起動
docker run --name apachetest -d -p 8080:80 local/centos:apache

コンテナの運用・管理コマンド

# コンテナの状態を詳しく確認できる
docker stats

# 圧縮アーカイブファイルを取得してDockerイメージを生成
docker import http://example.com/exampleimage.tgz

# コンテナ内のすべてのプロセスを一時停止/再開
docker pause
docker unpause

# コンテナ終了
docker stop
# docker stopコマンドで終了できない場合に利用 メインプロセスに対してKILLシグナルを送信してコンテナを終了します。
docker kill

# プライベートレジストリの構築
docker run -d -p 5000:5000 --name registry registry:2
docker pull ubuntu
docker tag ubuntu:latest localhost:5000/ubuntu
docker push localhost:5000/ubuntu

docker images

docker pull localhost:5000/ubuntu
# ローカルレジストリ削除
docker stop registry && docker rm -v registry

練習問題

6.1 仮想マシンと比較した際、コンテナにはどういうメリットがあるか
- カーネルはホストOSのものを利用するのでシステムリソースの消費が少なくて済む
6.2 dockerコマンド
- docker pull centos:8
- docker create --name testctl centos:8
- dokcer start testctl
6.3 起動中コンテナのシェルに接続
- docker attach testct2
6.4 改変を加えたコンテナから新しいDockerイメージを作成する際のコマンド
- docker commit
6.5 Dockerfile

第7章　201模擬試験

TODO: Q1.
- EFIシステムパーティションはFAT（またはVFAT）でフォーマットされる
- BIOSはマザーボード上のフラッシュメモリに保存される
TODO: Q2.GRUB2の設定ファイル/etc/default/grubの変更後は、grub-mkconfigコマンドを実行して/boot/grub/grub.cfgファイルを生成する必要がある
TODO: Q3.GRUB2ブートローダ
TODO: Q4.GRUBを再インストールするには
- grub2-install /dev/sda
TODO: Q5.systemdについて
- /usr/lib/systemd/systemディレクトリ：デフォルトのUnitファイル
- /etc/systemd/systemディレクトリ：管理者がカスタマイズするUnitファイル
Q6.systemd postfix.serviceが自動起動するように設定
- systemctl enable postfix.service
TODO: Q7.システムメンテナンスを行うためレスキューモードに移行
- systemctl isolate rescue.target
TODO: Q8./bootディレクトリ以下にあるファイルのうち、カーネルイメージを選択
- /boot/vmlinuz-カーネルバージョンという名前のファイル
- 自己解凍される圧縮ファイルとなっている
- /boot/initamfsや/boot/initrdは初期RAMディスクファイル
- /boot/System.mapはシンボルのマッピングファイル
- configはカーネルコンフィギュレーションファイル
TODO: Q9.現在利用中のカーネルバージョンを表示することができるコマンド
- uname -r
- cat /proc/version
TODO: Q10.カーネルのコンフィギュレーションが保存されるファイルのファイル名
- /usr/src/linux/.config
TODO: Q11.初期RAMディスクの作成ができるコマンド
- mkinitrd,mkinitramfs,dracut
Q12.systemdを採用したシステムでsshdサービスのログを取得
- journalctl -u sshd.service
TODO: Q13. udevを使用している場合、.rulesファイルが格納されているデフォルトのディレクトリ
- /etc/udev/udev.conf
- /etc/udev/rules.dディレクトリ
TODO: Q14.PCIデバイスの情報を集めている。1番目のバス、8番目のスロットに関する詳細な情報を表示
- lspci -vv -s 0:8
TODO: Q15./etc/fstabファイルの書式
- ファイルシステムの情報が記載されたファイル
- デバイスファイル名またはUUIDまたはラベル　マウントポイント　ファイルシステムの種類　マウントオプション　dumpフラグ　fsckのチェック順
TODO: Q16.現在マウントされているファイルシステムとそのマウントオプションを確認
- /etc/mtab
- /proc/mounts
TODO: Q17.有効になっているスワップ領域を確認するコマンド
- cat /proc/swaps
- swapon -s
Q18.ext4ファイルシステムをブロクサイズ4096バイトで作成したい場合
- mke2fs -b 4096 -t ext4 /dev/sdb1
TODO: Q19.Btrfsを使っている。/mntにマウントしているトップレベルのサブボリュームの下に、/mnt/sub1というボリュームを作ろうとしている。
- btrfs subvolume create /mnt/sub1
TODO: Q20./dev/sda5にはext2ファイルシステムが格納されている。このファイルシステム内のデータに影響を与えずに、ext3ファイルシステムに変換したい場合
- tune2fs -j /dev/sda5
- 既存のext2ファイルシステムに影響を与えずにext3ファイルシステムに変換できる
  - 他のオプションも含めて確認する
Q21.LVMの論理ボリューム/dev/centos/rootｎ構築されたXFSファイルシステムの情報を確認
- xfs_info: XFSファイルシステムの情報を確認できる
Q22.パーティションやディスクに対してLVMの物理ボリュームを作成するコマンド
- pvcreate:物理ボリュームを作成
- vgcreate:ボリュームグループを作成
- lvcreate:論理ボリュームを作成
Q23.ボリュームグループvolgroup1の空き容量が不足してきたので、物理ボリューム/dev/sdd1をvolgroup1に追加したい
- vgextend volgroup1 /dev/sdd1
Q24./dev/vg01/lv01のスナップショットをlv01_snapという名前で作成しようとしている
- lvcreate -s -L 500m -n lv01_snap /dev/vg01/lv01
- スナップショットを作成するには、lvcreateに-sオプションをつける
- -Lはサイズの指定、-nはスナップショットの名称を指定
Q25.LAN内に存在するホストをしるために、IPアドレスとMACアドレスとの対応テーブルを作成したい場合実行すべきこと
- LAN内のブロードキャストアドレスに対してpingコマンドを実行し、次にarpコマンドを実行する
Q26.デフォルトゲートウェイを192.168.1.1に設定しようとしている
- ip route add default via 192.168.1.1
- route add default gw 192.168.1.1
Q27.無線ネットワークに関わるコマンドや説明で適切なもの
- iwconfigコマンドで無線LANインターフェースの状態を表示できる
- 無線LANのアクセスポイントを識別するIDとしてSSID・ESSIDがある
Q28.ルーティングテーブル系問題
Q29.tcpdumpコマンドの出力結果読み解き問題クライアントのIPアドレスはどれか
Q30.ルーティングテーブル系問題
Q31.ネットワークに異常がみられるので、ルーティングテーブルを表示しようとしている。
- DNSの問題と切り離すため、名前解決せずに表示させたい場合、routeコマンドにどのオプションをつければよいか
  - route -n
  - netstat -rnでも同じ
Q32.パケットの受信および転送におけるエラーや取りこぼしの状況をネットワークインターフェースごとに表示することができるコマンド
- netstat -i
Q33.ターゲットホストまでのネットワーク経路を確認
- mtr
- traceroute
- tracepath
Q34.gitコマンド系
- git clone https://github.com/xxxxxx
Q35.ソフトウェアをソースコードからコンパイルしてインストールするときの説明
- makeコマンドを利用してもソフトウェア間の依存関係を解消できない
Q36.gccコンパイラがなくてconfigureとmakeでエラー
Q37.ソースコードに適用したパッチを取り消したい場合、patchコマンドでは何というオプションを指定すればいいか
- patch -R p0 < patch-2.3.4
Q38.バックアップメディアの必要本数問題
Q39.dumpコマンド
- ファイルシステム単位でext2/ext3/ext4ファイルシステムをバックアップ
Q40.ログインプロンプトの上方に表示されるディストリビューション情報などを編集したい
- 編集すべきファイル「/etc/issue」
Q41.ファイルシステムやディスクのI/Oを計測できるコマンドを2つ選択してください
- iostat
- iotop
Q42.vmstatの出力結果
- bi:block in ブロックデバイスから受け取ったブロック数(ブロック数/秒)
- r: 実行待ちプロセス数
- bo: ブロックデバイスに送られたブロック数(ブロック数/秒)
- wa: 入出力待ち時間
- b: 割り込み不可能なスリープ状態にあるプロセス数
Q43.freeコマンドからメモリとスワップ領域の状態について読み取る問題
Q44.vmstatコマンドの実行結果から読み取る問題
Q45.Webブラウザ経由でサーバーのCPU利用率やネットワークのトラフィックを監視したいときに導入すべきソフトウェア
- collectd,Nagios,MRTG,Cacti,Icinga2
Q46.SNMPに関する説明
- SNMPマネージャからSNMPエージェント側に情報を求めることをポーリングという
- 障害発生時にSNMPマネージャへ通知する異常通知データをTRAPという
- SNMPではUDPの161と162が使われる
Q47.Ansibleに関する説明
- インベントリにはシステム構成処理が実行されるホストのリストが記述されている
- AnsibleのターゲットノードはLinuxホスト以外にも対応
- 冪等性とはある操作を何度行っても同じ結果になること
Q48.Ansibleの導入目的として不適切なものを１つ
- サーバーのセキュリティを高める
Q49.playbookを実行するコマンド
- ansilbe-playbook -i server.hosts sample_playbook.yml
Q50.ハイパーバイザ型仮想化の説明
- 1つのハードウェア上で複数のOSを仮想マシン上で実行できる
- ホストOSのハードウェア障害は仮想マシンから特定しづらい
- CPUの仮想化支援機能を利用できる
Q51.サーバーのCPUがKVMに対応しているかどうかを調べる
- cat /proc/cpuinfo | grep flags | uniq
  - 根拠となるフラグ：vmx or svm
Q52.仮想マシンのネットワークインターフェースをホストOSのネットワークインターフェースと同じネットワークに配置する仕組みをなんと呼ぶか？
- ブリッジネットワーク
Q53.GUI環境で仮想マシンを管理：virt-manager
Q54.virsh は仮想マシン操作のためのコマンドラインインターフェース
- virsh shutdown vm_centos7
Q55.コマンドラインで仮想マシンを作成してOSをインストールするためのコマンド
- virt-install
Q56.コンテナに関する説明で誤っているもの
Q57.Dockerの説明としてただしいもの
- ホストOSのディレクトリをコンテナ内からアクセスできるように設定できる
- DockerレジストリでDockerイメージを入手できる
- DockerではLinuxカーネルの機能であるcgroupが使われる
Q58.
- docker run -it alpine:latest /bin/sh
Q59.
- docker attach [id]
  - バックグラウンドで起動中のコンテナに入るにはattachを使う
Q60.
- docker images

模擬試験問題

模擬試験解答・解説

■第2部　202試験（LinuC Level2 Exam 202）

第8章　ネットワーククライアントの管理

8.1　DHCPの設定

8.2　PAM認証

8.3　LDAP

第9章　ドメインネームサーバー

9.1　DNSの基本

9.2　BINDの基本設定

9.3　ゾーンファイルの管理

9.4　DNSサーバーのセキュリティ

第10章　HTTPサーバーとプロキシサーバー

10.1　Webサーバーの設定

10.2　Nginx

10.3　プロキシサーバーの設定

第11章　電子メールサービス

11.1　SMTPサーバーの構築

11.2　Dovecotの利用

第12章　ファイル共有サービス

12.1　Microsoftネットワーク

12.2　Sambaサーバーの構築

12.3　NFSサーバーの構築

第13章　システムのセキュリティ

13.1　パケットフィルタリング

13.2　OpenSSH

13.3　OpenVPN

13.4　セキュリティ業務

第14章　システムアーキテクチャ

14.1　高可用システムの実現方法

14.2　キャパシティプランニングとスケーラビリティの確保

14.3　クラウドサービス上のシステム構成

14.4　典型的なシステムアーキテクチャ

第15章　202模擬試験

模擬試験問題

模擬試験解答・解説

付録　Linux実習環境の使い方

Linux実習環境の利用について

VirtualBoxのインストール

仮想マシンの使い方

安全なWebアプリケーションの作り方_脆弱性が生まれる原理と対策の実践_第2版

Thu, 20 Aug 2020 00:00:00 GMT

安全なWebアプリケーションの作り方_脆弱性が生まれる原理と対策の実践_第2版

理解したこと

書籍情報

著者
- 徳丸浩:ＥＧセキュアソリューションズ株式会社代表、ＯＷＡＳＰＪａｐａｎアドバイザリーボード、独占行政法人情報処理推進機構（ＩＰＡ）非常勤研究員
定価
- 3,520円
発売日
- 2018/06/22
ISBN
- 978-4-7973-9316-3

Ｗｅｂアプリ開発者が知っておくべき攻撃と防御の知識を徹底解説。脆弱性が生まれる原理と具体的な対処法が学べる。実習用仮想マシンのダウンロードサービス付き。ＯＷＡＳＰＴｏｐ１０−２０１７対応。【「TRC MARC」の商品解説】

日本中の現場で支持されたベストセラーが、最新環境にあわせて全面刷新＋大増ページ！

Webアプリケーションにはなぜ脆弱性が生まれるのか？脆弱性を解消するにはどうプログラミングすればよいか？ PHPサンプルへの攻撃を通して脆弱性が生まれる原理と具体的な対処方法が学べる！

Webアプリ開発者の必読書、待望の改訂版！ OWASP Top 10 - 2017対応

<主な改訂内容> ・HTML5の普及に対応してWeb APIやJavaScriptに関する解説を新設・OWASP Top 10 - 2017に対応して、XXEや安全でないデシリアライゼーションなどを解説・脆弱性診断に対する関心が高まっていることから、脆弱性診断の入門の章を親設・IE7のサポート終了など現在のソフトウェアの状況に対応・実習環境をWindowsに加えてMacにも対応【商品解説】

1章 Webアプリケーションの脆弱性とは

1.1 脆弱性とは、「悪用できるバグ」

脆弱性(vulnerability)とは：バグの中でも悪用できてしまうもの

1.2 脆弱性があるとなぜ駄目なのか

経済的損失
法的な要求
利用者が回復不可能なダメージを受ける場合が多い
Webサイト利用者に嘘をつくことになる
攻撃インフラ（ボットネットワークなど）構築に荷担してしまう

1.3 脆弱性が生まれる理由

理由
- (A)バグによるもの：XSS
- (B)チェック機能の不足によるもの：ディレクトリトラバーサルなど

1.4 セキュリティバグとセキュリティ機能

1.5 本書の構成

1.6 セキュリティガイドラインとの対応

ガイドライン２種類
- 安全なウェブサイトの作り方
- OWASP Top 10

本書の項目との対応表の説明

2章実習環境のセットアップ

2.1 実習環境の概要

サンプルを動かす環境
- Linux
- nginx 1.10
- Apache 2.4
- PHP 5.3 / PHP 7.0
- Tomcat 8.5
- MariaDB 10.1
- Postfix 3.1
インストールするプログラム
- Firefox
- VirtualBox
- 仮想マシン
- OWASP ZAP(脆弱性診断に用いるツール)
- FoxyProxy-Standard(プロキシを切り替えるFirefoxアドオン)
実習用仮想マシンのダウンロード
- https://wasbook.org/download/

2.2 Firefoxのインストール

XSSフィルタが標準では実装されていないのでクロスサイトスクリプティングという脆弱性の体験がやりやすい
ダウンロードURL
- https://www.mozilla.org/ja/firefox/new/

2.3 VirtualBoxのインストール

ダウンロードURL
- https://www.virtualbox.org/

2.4 仮想マシンのインストールと動作確認

wasbookのOSイメージをインポートホストネットワークマネージャを設定ゲストOSの設定＞ネットワークより以下を確認アダプター１にNATが設定されているアダプター２にホストオンリーアダプター、名前に先程ホストネットワークマネージャより設定した名前が選択されていること

ゲストOSを起動してログイン ip aでアドレス確認ホストOSからping疎通

2.5 OWASP ZAPのインストール

OWASP ZAPとは
- OWASP ZAP(OWASP Zed Attack Proxy)は、OWASP(The Open Web Application Security Project)が開発・公開しているWebアプリケーション脆弱性診断用ツールで、無償で公開されている
- OWASP ZAPはWindowsPC/Mac上でプロキシとして動作し、HTTP通信を観察したり、変更したりすることができる
- 同種のツールに、Burp SuiteやFiddlerなどがあるが、本書では以下の理由でこちらを使う
  - 完全に無償で利用できる
  - 自動の診断ツールが手軽に利用できる
  - WindowsとmacOSの両方で利用できる
JREのインストール
- OWASP ZAPはJavaで記述されているので実行環境が必要
- ただしmacOS版のOWASP ZAPはJRE版が同梱されているのでJREをインストールする必要はありません
- Windowsは必要があればJREをインストール
  - java -versionで確認
OWASP ZAPのインストール
- https://owasp.org/www-project-zap/
- JRE実行環境とbit数をあわせること

オプションの設定を行っておく

2.6 Firefoxの拡張FoxyProxy-Standardのインストール

ForxProxy Satandard
- https://addons.mozilla.org/ja/firefox/addon/foxyproxy-standard/

アドオン内のプロキシ設定を修正

2.7 OWASP ZAPを使ってみる

実際にFireFoxからアクセスして記録されるかどうかを確認する

2.8 Webメールの確認

本書では、メール処理に伴う脆弱性でメールを送信したり、脆弱性に対する攻撃でメールを送信したりする場合があるので、ブラウザからメールを確認できるように、RoundcubeというWebメールソフトが導入されている

実際にログインして確かめましょう

3章 Webセキュリティの基礎～ HTTP、セッション管理、同一オリジンポリシー

3.1 HTTPとセッション管理

なぜHTTPを学ぶのか
- Web固有の特性に由来して、脆弱性が発生するため
一番かんたんなHTTP
Referer
- セキュリティ上の問題になるのは、URLが秘密情報を含んでいる場合
- 典型的にはURLにセッションIDを含んでいる場合、Referer経由で外部に漏洩し、なりすましに悪用される可能性がある
hiddenパラメータの書き換えを体験
- hiddenパラメータ部分に脆弱性がある場合に、OWASP ZAPのようなプロキシツールを用いてhiddenパラメータを改変し、攻撃することが可能であることを実感してもらうため
hiddenパラメータのメリット
- hiddenは利用者自身からは書き換えできるものの、情報漏洩や第三者からの書き換えに対しては堅牢だということ
- hiddenパラメ―tあと比較する対象には、後述するクッキーやセッション変数がある
- 特にログイン前の状態でかつ、地域型JPドメイン名や都道府県型JPドメイン名を使っている場合、後述するクッキーモンスターバグの影響により、セッション変数の漏洩に対する効果的な対策がない
- このため利用者自身によっても書換えられては困る認証や認可に関する情報はセッション変数に保存するべきだが、それ以外の情報はまずはhiddenパラメータに保存することを検討するとよい
- 特にログイン前の状態では認証認可に関する情報はないはずなので、原則としてセッション変数の使用は避け、hiddenパラメータを使うことが情報漏えいなどに対して安全
ステートレスなHTTP認証
- HTTPには認証機能がサポートされている
- HTTP認証と総称されるが
  - Basic認証
  - NTLM認証
  - Digest認証
    - などが存在する
- HTTPがステートレスなプロトコルであることから、HTTP認証もステートレス
Basic認証を体験する
- Basic認証は認証が必要なページにリクエストがあると、いったん「401 Unauthorized(認証が必要なのにされていない)」というステータスを返します。これを受けてブラウザはIDとパスワードの入力画面を表示し、入力されたIDとパスワードを追加したリクエストをあらためてサーバーに返信します。
認証と認可
- 認証とは：利用者がたしかに本人であることをなんらかの手段で確認すること
  - Basic認証のほか、HTMLフォームでIDとパスワードを入力させるフォーム認証、TLSクライアント証明書を用いるクライアント認証など
- 認可とは：認証済みの利用者に権限を与えること
  - 具体的には、データの参照・更新・削除や、預金の振り込み、物品の購入などを「できるようにする」こと
クッキーとセッション管理
- クッキー：サーバー側からブラウザに対して、「名前＝変数」の組を覚えておくように指示するもの
  - クッキーはセッション管理という機能の実現に使われる
アプリケーションがSet-Cookieというレスポンスヘッダーを返却して、ブラウザに対してクッキーを覚えるように指示する
クッキーには有効期限が設定できるが、有効期限が設定されていないクッキーはブラウザ終了時まで有効になる
クッキーによるセッション管理
- アプリケーションデータを保持する目的でクッキーそのものに値を入れることはあまり行われない
- その理由は以下の通り
  - クッキーが保持できる値の個数や文字列長には制限がある
  - クッキーの値は利用者本人には参照・変更ができるので、秘密情報の格納に向かない
    - このためクッキーには「整理番号」としてセッションIDを格納しておき、実際の値はサーバー側で管理する方法が広く用いられている
    - これをクッキーによるセッション管理と呼ぶ
セッションIDに求められる要件
- 要件１：第三者がセッションIDを推測できないこと
  - 暗号論的擬似乱数生成器を用いて生成https://www.cryptrec.go.jp/list.html
  - しかし実際にはセッションIDを自作するのではなく、Webアプリケーション開発ツールで提供されるものを利用すべき
  - セッション管理機構は自作しないことが重要
- 要件２：第三者がセッションIDを強制されないこと
  - セッションIDの固定化攻撃(Session Fixaction Attack)を受けないように、認証が完了したタイミングでセッションIDを新しく払い出そうという話
- 要件３：第三者にセッションIDが漏洩しないこと
  - セッションIDが漏洩する主な原因
    - クッキー発行の際の属性に不備がある
    - ネットワーク的にセッションIDが盗聴される
    - XSSなどアプリケーションの脆弱性により漏洩する
    - PHPやブラウザなどプラットフォームの脆弱性により漏洩する
    - セッションIDをURLに保持している場合は、Refererヘッダから漏洩する
クッキーの属性

属性	意味
Domain	ブラウザがクッキー値を送信するサーバーのドメイン
Path	ブラウザがクッキー値を送信するURLのディレクトリ
Expires	クッキー値の有効期限。指定しない場合、ブラウザの終了まで
Secure	HTTPSの場合のみクッキーを送信
HttpOnly	この属性が指定されたクッキーはJavascriptからアクセスできない

このうちセキュリティ上重要な属性
- Domain
- Secure
- HttpOnly
Domain属性：通常設定しない
- 複数のサーバに送信されるクッキーを生成したい場合に使うが、Domain属性を指定しない状態がもっともクッキーの送信範囲が狭く、安全な状態と言える
Column：クッキーモンスターバグ
- 筆者が所属する会社のドメイン名はeg-secure.co.jpなので、クッキーを発行する際のドメイン指定の最短はeg-secure.co.jpとなるはず
- ところが、古いブラウザを使っていると.co.jpのドメインのクッキーが作れてしまうという問題があった
- このバグを「クッキーモンスターバグ」という
クッキーのセキュア属性
- HTTPS通信の場合のみにサーバーに送信されるので、HTTPS通信を保証することができる
クッキーのHttpOnly属性
- Javascriptからアクセスできないクッキーを設定するもの
- XSS攻撃でJavascriptを悪用してクッキーを盗み出すというもので、クッキーにHttpOnly属性をつけておくとJavascriptによりクッキーを盗み出すことができなくなる
- HttpOnly属性をつけることで悪影響はないのでつけておくことをおすすめ

3.2 受動的攻撃と同一オリジンポリシー

能動的攻撃と受動的攻撃
- 能動的攻撃：攻撃者がWebサーバーに対して直接攻撃すること
- 受動的攻撃：攻撃者がサーバーに直接攻撃するのではなく、Webサイトの利用者に罠を仕掛ける事により、罠を閲覧したユーザを通してアプリケーションを攻撃する手法
  - 罠サイト経由でCSRFやXSSの攻撃を仕掛ける
ブラウザはどのように受動的攻撃を防ぐか
- 受動的攻撃に対しては、ブラウザとWebサイトそれぞれで対策を行う必要がある
- Webサイト側の対策を説明する前に、この節でブラウザのセキュリティ機能について説明する
サンドボックスという考え方
- 利用者に配布元を確認させた上で、利用者が許可した場合のみに実行する
- プログラムの「できること」を制限するサンドボックスという環境を用意する
  - ローカルファイルへのアクセス禁止
  - プリンタなどの資源の利用禁止（画面表示は可能）
  - ネットワークアクセスの制限（同一オリジンポリシー）
同一オリジンポリシー
- JavaScriptなどのクライアントスクリプトからサイトをまたがったアクセスを禁止するセキュリティ上の制限であり、ブラウザのサンドボックスに用意された制限の１つ
- iframeを題材にして、同一オリジンポリシーがなぜ必要かを説明していきます
同一オリジンである条件
- 「同一オリジン」であるとは、以下のすべてを満たす場合
  - URLのホスト（FQDN:Fully Qualified Domain Name）が一致している
  - スキーム（プロトコル）が一致している
  - ポート番号が一致している
- クッキーに対する条件はスキームとポート番号は関係ないのでJavaScriptの制限のほうが厳しい
- 一方JavaScriptにはディレクトリに関する制限はない
- iframeだけでなく、Ajaxの実現に使用されているXMLHttpRequestについても成約がある
- ただし、XMLHttpRequestについては相手側の許可があれば同一オリジンでなくても通信できるCORSという規格が策定されました
アプリケーション脆弱性と受動的攻撃
- ブラウザは同一オリジンポリシーにより受動的攻撃を防止しているが、アプリケーションに脆弱性があると受動的攻撃を受ける場合がある
- その代表がクロスサイトスクリプティング（XSS）攻撃
- iframeの外側から内側の要素へアクセスすることはできないが、何らかの方法で内側の要素にスクリプトを埋め込むことができれば、同一オリジンポリシーの制約は受けないのでドキュメント情報にアクセスできる
JavaScript以外のクロスドメインアクセス
- frame要素とiframe要素
- img要素
- script要素
- CSS
  - クロスドメインで読み込み可能
  - IEにはCSSXSSと呼ばれる脆弱性があった
  - HTMLやJavaScriptをCSSとして呼び出した場合、これらCSSでないデータが部分的に読み出せるジェイ弱製があった
- form要素のaction属性
  - form要素のaction属性もクロスドメインの指定が可能
  - またformの送信（submit）はJavaScriptから常に（action先がクロスドメインであっても）操作できる
  - この仕様を悪用した攻撃手法がクロスサイトリクエストフォージェリ（CSRF）攻撃
  - CSRF攻撃では、ユーザの意図しないformを送信させられ、アプリケーションの機能が勝手に実行される

3.3 CORS（Cross-Origin Resource Sharing）

シンプルなリクエスト
- 特定の王権を満たす「シンプルなリクエスト」の場合、XMLHttpRequestを用いて異なるオリジンにHTTPリクエストを送ることが相手側の許可なしに可能
Access-Control-Allow-Origin
- クロスオリジンからの読み出しを許可するための仕掛けで、情報の提供元がHTTPレスポンスヘッダとして出力
- http://example.jpに対してXMLHttpRequestなどのアクセスを許可する場合は下記のHTTPレスポンスヘッダを送信
  - Access-Control-Allow-Origin: http://example.jp
  - 情報提供元がこの許可をすればJavaScriptから参照できるようになる
シンプルなリクエストの要件
- メソッド
  - GET
  - HEAD
  - POST
- XMLHttpRequestオブジェクトのsetRequestHeaderメソッドで設定するリクエストヘッダは以下に限る
  - Accept
  - Accept-Language
  - Content-Language
  - Content-Type
- Content-Typeヘッダは以下のいずれかである
  - application/x-www-form-urlencoded
  - multipart/form-data
  - text/plain
プリフライトリクエスト
- クロスオリジンアクセスにおいて「シンプルなリクエスト」の条件を満たさない場合、
- ブラウザは、プリフライトリクエスト（pre-flight request）というHTTPリクエストを送信する
- 上記のシンプルなリクエストの要件に合致しない場合、ブラウザは以下のようなリクエストヘッダを送信
  - Access-Control-Request-Method: POST
  - Access-Control-Request-Headers: content-type
  - Origin: http://example.jp
MEMO: CORS制約に引っかかる場合でもリソース提供元のソースは走る
- 返却されたリソースを読み込むときに、レスポンスヘッダが存在しないと読み込むことができない様になっている
認証情報を含むリクエスト
- デフォルトでは、クロスオリジンに対するリクエストにはHTTP認証やクッキーなどの認証に用いられるリクエストヘッダは自動的に送信されません
- これらを用いるには、XMLHttpRequestのプロパティwithCredentialsをtrueにセットする必要がある
- withCredentialsプロパティをtrueにしたリクエストに対しては、Access-Control-Allow-Credentials: trueというレスポンスヘッダを返す必要がある
- まとめると
  - クライアント側：XMLHttpRequestオブジェクトのwithCredentialsプロパティをtrueにする
  - サーバー側：レスポンスヘッダとしてAccess-Control-Allow-Credentials: trueを返す

4章 Webアプリケーションの機能別に見るセキュリティバグ

4.1 Webアプリケーションの機能と脆弱性の対応

脆弱性はどこで発生するか
- Webアプリケーションの出力処理で発生
  - ここでいう出力は、ブラウザ表示、RDB処理、シェル実行、メール処理、ファイル処理など
- まとめると
  - 脆弱性には処理に起因するものと出力に起因するものがある
  - 入力に起因する脆弱性はない（ミドルウェアの範囲を広げると、入力時の検証処理に脆弱性が入り込む余地はある）
  - 出力に起因する脆弱性には「インジェクション」という単語がつくものが多い
インジェクション系脆弱性とは
まとめ
- 脆弱性の説明を始めるにあたり、脆弱性の発生箇所と脆弱性の種類の関連性について説明しました
- また「出力」で発生する脆弱性は、インジェクションと呼ばれる共通の原理で発生することを紹介

4.2 入力処理とセキュリティ

WEBアプリケーションの「入力」では何をするのか
- 処理に入る前の準備段階
  - 文字エンコーディングの妥当性検証
  - 文字エンコーディングの交換（必要な場合のみ）
  - 入力値（パラメータ文字列）の妥当性検証
文字エンコーディングの検証
- PHPの場合、文字エンコーディングの検証にはmb_check_encoding関数が利用できる
文字エンコーディングの変換
- 言語によって文字エンコーディングの変換手段は異なる
- おおまかな分類として、文字エンコーディングを自動的に変換する言語と、スクリプトで変換ロジックを明示する言語がある
入力値の検証
- 入力値の検証がないと...
  - 数値のみを受け付ける項目に英数字や記号を入力して、データベースのエラーになる
  - 更新処理が途中でエラーになり、データベースの不整合が発生する
  - 利用者が多数の項目を入力して事項ボタンをクリックしたら内部エラーとなり入力を最初からやり直す羽目になる
  - メールアドレスの入力を忘れているのにアプリケーションがメール送信処理を実行する
    - 入力検証はこのような悪いことが起きる可能性をへらす！
- 目的
  - 入力値の間違いを早期に発見して再入力を促すことにより、ユーザビリティ（使いやすさ）を向上する
  - 間違った処理を継続することによるデータの不整合などを防ぎ、システムの信頼性を向上させる
バイナリセーフという考え方とヌルバイト攻撃
- バイナリセーフとは：入力値がどんなバイト列であっても正しく扱えること
- ヌルバイトは、バイナリセーフでない関数の場合終端文字として扱われるため、後ろの文字列を評価対象としない
入力値検証だけでは対策にならない
- 入力段階で不正な入力をチェックしておけば、セキュリティ対策は終わりにできないか？
  - アプリの仕様のためすべての文字を許容するという仕様の場合は入力時点でも何も防げない

4.3 表示処理に伴う問題

クロスサイトスクリプティング（基本編）
- 外部からの入力値を画面に表示するしてHTMLを生成する処理に問題があると生じる脆弱性
- 影響
  - サイト利用者のブラウザ上で、攻撃者の用意したスクリプトの実行によりクッキー値を盗まれ、利用者がなりすましの被害にあう
  - 同じくブラウザ上でスクリプトを実行させられ、サイト利用者の権限でWebアプリケーションの機能を悪用される
  - Webサイト上に偽の入力フォームが表示され、フィッシングにより利用者が個人情報を盗まれる
攻撃手法と影響
- クッキー値の盗み出し
  - 罠サイトを用意してiframeで標的サイトを表示し、script実行！
- その他のJavaScriptによる攻撃
  - ワーム攻撃
- 画面の書換え
  - JavaScriptを使わない攻撃
  - formを表示する画面で入力画面と編集画面を兼ねているようなもので、各入力項目の初期値が設定できるようになっているページに脆弱性があると実現する
  - MEMO: 最初わからなかったが腑に落ちた！ただこんなページを実装しているサイトは無いと思う。。

P129まで 2020-08-27 02:33:29

反射型XSSと持続型XSS
- 反射型：攻撃用JavaScriptが攻撃対象サイトとは別のサイトに有る場合
- 持続型：攻撃用のJavaScriptが、攻撃対象のデータベースなどに保存される場合
COLUMN: TRACEメソッドの無効化とXST
- 古いブラウザに対して飲み有効なクロスサイト・トレーシングという攻撃がある
- JavaScriptによりHTTPのTRACEメソッドを送信する事によりクッキーやBasic認証のID・パスワードを盗み出す手法
- XST攻撃はブラウザで対策が2006年に完了しており、リスクはほぼないと考えられる
対策まとめ
- 必須対策（個別の対策）
  - HTMLの要素内容
    - htmlspecialchars関数によりエスケープ
  - 属性値
    - htmlspecialcharsカンスによりエスケープしてダブルクォートで囲む
- 必須対策（共通対策）
  - HTTPレスポンスに文字エンコーディングを明示する
- 保険的対策
  - X-XSS-Protectionレスポンスヘッダの使用
  - 入力値の検証
  - クッキーにHttpOnly属性を付与
  - TRACEメソッドの無効化（コラム参照）
4.3.2 クロスサイトスクリプティング（発展編）
href属性やsrc属性のXSS
- 対策
  - http:またはhttps:で始まる絶対URLチェック
  - スラッシュで始まる相対URLチェック
JavaScriptの動的生成
- イベントハンドラのXSS
  - Javascriptのメソッド引数にサーバ側で動的に生成したスクリプトが注入されている場合
    - 対策
      - JavaScript文字列リテラルとしてエスケープする
      - 結果をHTMLエスケープする
- script要素のXSS

4.4 SQL呼び出しに伴う脆弱性

4.5 「重要な処理」の際に混入する脆弱性

4.6 セッション管理の不備

4.7 リダイレクト処理にまつわる脆弱性

4.8 クッキー出力にまつわる脆弱性

4.9 メール送信の問題

4.10 ファイルアクセスにまつわる問題

4.11 OSコマンド呼び出しの際に発生する脆弱性

4.12 ファイルアップロードにまつわる問題

4.13 インクルードにまつわる問題

4.14 構造化データの読み込みにまつわる問題

4.15 共有資源やキャッシュに関する問題

4.16 Web API実装における脆弱性

4.17 JavaScriptの問題

5章代表的なセキュリティ機能

5.1 認証

5.2 アカウント管理

5.3 認可

5.4 ログ出力

6章文字コードとセキュリティ

6.1 文字コードとセキュリティの概要

6.2 文字集合

6.3 文字エンコーディング

6.4 文字コードによる脆弱性の発生要因まとめ

6.5 文字コードを正しく扱うために

6.6 まとめ

7章脆弱性診断入門

7.1 脆弱性診断の概要

7.2 脆弱なサンプルアプリケーションBad Todo

7.3 診断ツールのダウンロードとインストール

7.4 Nmapによるポートスキャン

7.5 OpenVASによるプラットフォーム脆弱性診断

7.6 OWASP ZAPによる自動脆弱性スキャン

7.7 OWASP ZAPによる手動脆弱性診断

7.8 RIPSによるソースコード診断

7.9 脆弱性診断実施上の注意

7.10 まとめ

7.11 脆弱性診断報告書のサンプル

8章 Webサイトの安全性を高めるために

8.1 Webサーバーへの攻撃経路と対策

8.2 成りすまし対策

8.3 盗聴・改ざん対策

8.4 マルウェア対策

8.5 まとめ

9章安全なWebアプリケーションのための開発マネジメント

9.1 開発マネジメントにおけるセキュリティ施策の全体像

9.2 開発体制

9.3 開発プロセス

9.4 まとめ

現場で使える Ruby on Rails 5速習実践ガイド

Thu, 20 Aug 2020 00:00:00 GMT

現場で使える Ruby on Rails 5速習実践ガイド（ISBN978-4-8399-6222-7）

理解したこと

書籍サイト

https://book.mynavi.jp/ec/products/detail/id=93905

サポートサイト

https://book.mynavi.jp/supportsite/detail/9784839962227.html

書籍情報

Railsアプリの基本から実践的なノウハウまでこの1冊で！本書は、Ruby on Rails（以下Rails）を使ってWebアプリケーションを開発するための解説書です。

RailsでどのようにWebアプリケーションを作るのかという基本的なところから、現場のニーズに合わせてどのように機能を追加していくのか、テストはどのように行うのか、複数人で開発していく場合の方法といった実践的なトピックまで、幅広くカバーしています。

本書を読んだ方が単にRailsでWebアプリケーションを作れるようになるだけでなく、「Railsらしいアプリケーションコード」を書けるようになり、そして開発チームの仲間とともに実現したいことを実現できるように、という視点で必要な情報をまとめた1冊です。

なお、本書の対応バージョンはRuby 2.5／Rails5.2です。Rails5.2から導入されたActive Storageやcredentials.yml.encについても解説しています。macOS／Windows 10（64ビット版）対応。

■読者対象について

Ruby以外の言語でのWebアプリケーションの開発や、オブジェクト指向プログラミングについては知識・経験があるものの、RubyやRailsについては初めて学ぶ方を主な対象にしています。

ただし、Webアプリケーションやオブジェクト指向が初めての方にも理解しやすいように説明するように努めています。

■構成と内容について

本書の構成は以下の通りです。

＜入門編＞ Chapter 1 RailsのためのRuby入門 Chapter 2 Railsアプリケーションをのぞいてみよう Chapter 3 タスク管理アプリケーションを作ろう

＜レベルアップ編＞ Chapter 4 現実の複雑さに対応する Chapter 5 テストをはじめよう Chapter 6 Railsの全体像を理解する Chapter 7 機能を追加してみよう

＜発展編＞ Chapter 8 RailsとJavaScript Chapter 9 複数人でRailsアプリケーションを開発する Chapter 10 Railsアプリケーションと長く付き合うために

章ごとの内容は以下の通りです。

Chapter1では、Railsのアプリケーションのコードを読み書きするために最低限必要となるようなRubyの基礎知識を解説していきます。

Chapter2では、RubyやRailsが動作する環境を構築するとともに、簡単なサンプルアプリケーションを作成し、中身の構成を解説していきます。

Chapter3では、シンプルなタスク管理アプリケーションの作成を通じて、CRUDと呼ばれるソフトウェアの基本的な機能をRailsで実装する方法について学んでいきます。

Chapter4では、Chapter3で作成したアプリケーションに、いくつかの機能を追加していきます。具体的には「データ内容の制限」「検証」「コールバック」「フィルタ」「ログイン機能の追加」「関連」「検索」について解説していきます。

Chapter5では、Railsにあらかじめ用意されている「自動テスト」という仕組みについて、利用方法や注意事項を解説します。

Chapter6では、Railsの備える機能や、Railsを取り巻く世界の全体像を改めて一望し、これまで取り上げる機会のなかったいくつかの重要な要素について解説していきます。

Chapter7では、Railsアプリケーションで比較的よくある具体的な機能を実現するやり方を、Chapter4までで作成したアプリケーションへの機能追加という形で紹介していきます。

Chapter8では、Railsを利用する際のJavaScriptの扱い方について解説していきます。モダンなJavaScriptについても扱っています。

Chapter9では、複数人で開発を行う場合に重要になってくる知識や、注意すべきポイントについて解説していきます。

Chapter10では、Railsアプリケーションと長く付き合っていくために特に重要なテーマとして、「バージョンアップに対してどのように取り組むべきか」「Railsアプリケーションコードが複雑になっていくことにどうに立ち向かい、メンテナンスしやすい状態の維持を図るのか」について扱います。

＜入門編＞

Chapter 1 RailsのためのRuby入門

1-1 オブジェクトを理解しよう

1-1-1 万物がオブジェクト

オブジェクトという存在になれましょう
- ※詳細割愛

1-1-2 irb

Rubyには、irb(アイアールビー)という、対話的な実行環境が付属している
オブジェクトがどういうものかを体験していただくために操作しながら読みすすめる
以下から実行環境を取得しておいた
- https://rubyinstaller.org/

1-1-3 文字列

ダウブルクォーテーションかシングルクォーテーションで文字列を囲む
- 違い：https://qiita.com/ryosuketter/items/ddad508cb0124e4fe378

1-1-4 数値

1-1-5 オブジェクトに、自分が何者かを聞いてみる

irb(main):006:0> "氏名".class
=> String
irb(main):007:0> 1.class
=> Integer
irb(main):008:0> 1.1.class
=> Float
irb(main):009:0> true.class
=> TrueClass
irb(main):010:0> false.class
=> FalseClass
irb(main):013:0> "氏名".object_id
=> 300
irb(main):014:0> "氏名".object_id
=> 320
irb(main):015:0> "氏名".object_id
=> 340
irb(main):016:0> 1.object_id
=> 3
irb(main):017:0> 1.object_id
=> 3
// 数値は同じオブジェクトIDを取るが、文字列は異なるオブジェクトIDを取る
// この辺はJavaのプリミティブ型、参照型と同じ概念のよう

1-1-6 クラスとインスタンス

「オブジェクトXのクラスがAであるとき、XはAのインスタンス（オブジェクト）である」といいます。

1-1-7 オブジェクトの機能はクラスで決まる

オブジェクトの種類により、プロパティなどが異なりますよという説明

1-1-8 変数

ローカル変数の記載
- スネークケースで先頭は小文字か_(アンダースコア)で記載されるのでこれに習おう
  - sample_message
  - part2
  - _user
定数は大文字で始まる名前にすること。

1-1-9 コメント

# １行をコメントアウト
name = "氏名" # 途中からも可能

1-1-10 メソッド

class cat
  def run(ネズミ)
    puts "一生懸命 #{ネズミ} を追いかけた..." # 画面にメッセージを出力します
  end
end

タマ = cat.new

メソッドの基本的な説明
メソッドを呼び出すときにかっこを省略できる

irb(main):066:0> message1 = "こんにちは"
=> "こんにちは"
irb(main):067:0> message2 = "こんばんは"
=> "こんばんは"
irb(main):068:0* split = ^C
irb(main):068:0> split = "｜"
=> "｜"
irb(main):069:0> message3 = "あいさつ！"
=> "あいさつ！"
irb(main):070:0> message3.concat message1, message2
=> "あいさつ！こんにちはこんばんは"

1-2 自分でクラスを作ってみよう

1-2-1 クラスを作る

1-2-2 Userクラスを作る

1-2-3 Userクラスにメソッドを定義する

1-2-4 インスタンス変数

インスタンス変数：オブジェクトが抱えている変数

class User
  def name=(name)
    @name = name
  end

  def name
    @name
  end
end

1-2-5 ローカル変数とインスタンス変数の違い

1-2-6 属性

一般的にオブジェクトが抱えるデータのことを「属性（Attribute）」
属性とインスタンス変数はよく似た概念と言える

1-2-7 ゲッターやセッターを簡単に定義する

class User
  #attr_accessor :name
  #attr_reader :name
  #attr_writer :name
end

1-2-8 住んでいる場所やEメールアドレスを持たせる

class User
  attr_accessor :name, :address, :email
end

1-2-9 メソッドからメソッドを使う

1-2-10 まとめ - オブジェクトの振る舞いとデータ

1-3 Rubyプログラムの基礎知識

1-3-1 演算子

目新しい演算子はないので割愛

1-3-2 nil

# nilにする
value = nil
# nilかどうか確かめる
value.nil?

1-3-3 真偽

Rubyでは0も真になるので注意！

1-3-4 条件分岐

number = 1
if number == 1
  puts '数値は1です'
elsif number == 2
  puts '数値は2です'
else
  puts '数値は1や2以外です'
end

# ifは評価結果を返すことを抑えておく
number = 100
message = if number > 50
            "numberは50より大きいです"
          else
            "numberは50以下です"
          end
# elseがなくどのオブジェクトにも当てはまらない場合はnilオブジェクト

# 当てはまらない場合に分岐する unless
# ifの裏返しを表現する方法
# これは使わなくても良さそう わかりにくくなる
age = 16
unless age >= 20
  puts "未成年者には酒類を提供できません！"
end

# 後置if
puts 'おはようございます' if true
puts 'お疲れ様でした' if false

1-3-5 配列

# eachメソッド
a = [1,2,3]
a.each do |element|
  puts element
end

# forでもかける
for element in a
  puts element
end

Rubyに慣れている人は、For文よりもeachを好んで使うとのこと

# 配列に要素を追加する場合は<<を使う
a = [1,2,3]
a << 4

https://qiita.com/may88seiji/items/ce9396a4c267a3d449ae

1-3-6 ハッシュ

内部的にデータをキーと対応づけて格納しておくデータ構造

pref = { tokyo: 13636222, kanagawa: 9144572 }

irb(main):060:0> pref
=> {:tokyo=>13636222, :kanagawa=>9144572}
irb(main):061:0> pref[:tokyo]
=> 13636222

1-4 少し高度なテクニック

1-4-1 initialize

class User
  attr_reader :name, :address, :email
  def initialize(name, address, email)
    @name = name
    @address = address
    @email = email
  end
end

user = User.new("田中太郎","東京都",nil)

1-4-2 メソッドの呼び出しに制限をかける

class Person
  def initialize(money)
    @money = money
  end
  def billionaire?
    money >= 1000000000
  end

  # privateキーワード以降のメソッドはプライベートメソッドとなる
  # initializeメソッドはprivate指定しなくても自動的にプライベートになる
  private

  def money
    @money
  end
end

person = Person.new(1000000000)

# privateなのでエラーになる！
person.money

1-4-3 引数にデフォルト値を指定する

# デフォルト値を指定することができる
def name(full = true, with_age = true)
  n = if full
        "#{given_name} #{family_name}"
      else
        given_name
      end
  n << "(#{age})" if with_age
end

1-4-4 キーワード引数

# キーワード引数の定義
def name(full: true, with_age: true)
  n = if full
        "#{given_name} #{family_name}"
      else
        given_name
      end
  n << "(#{age})" if with_age
end

# デフォルト値の省略も可能
def name(full: true, with_age:)
end

# どんな順序で呼び出してもいい
person.name(full: true, with_age: false)
person.name(with_age: false, full: true)

1-5 似たところのあるクラスを作りたいとき

1-5-1 継承

# < で継承ができる
class Book
  def title
    '本のタイトル'
  end
end

class Magazine < Book
  # オーバーライド
  def title
    '雑誌のタイトル'
  end
end

1-5-2 モジュールによる共通化（Mix-in）

Rubyの基本単位のオブジェクトであり、オブジェクトの設計図としてクラスがある
ある一連の振る舞いの設計図を一箇所にまとめた存在として「モジュール(Module)」という概念がある

module Chatting
  def chat
    "hello"
  end
end

class Dog
  include Chatting
end

モジュールをクラスに取り込んで振る舞いを追加することをRubyでは、「Mix-in」(ミックスイン)と呼びます

Column クラスメソッド

クラスに対して呼び出せるクラスメソッドという概念が存在する

class Tax
  def self.rate
    1.08
  end
end

1-6 プログラムの異常を検知しよう（例外捕捉）

独自例外を作成するときはStandardErrorを継承して作成する

begin
rescue
ensure
end

# メソッド内の例外処理なら以下のようにかける
def method
  rescue
  # 例外に対応するコード
  ensure
  # 例外が発生してもしなくても必ず実行したいコード
end

begin
  do_something
rescue SomeSpecialError => e
  # エラーオブジェクトを変数として受け取る方法
  puts "#{e.class} (#{e.message})が発生しました。処理を続行します。"
end

1-7 読めると便利！Rubyっぽい書き方

1-7-1 nil ガード

number ||= 10
number || (number = 10)

def children
  @children ||= []
end
# childrenがnilの状態であっても必ず配列で初期化されるので安心

1-7-2 ぼっち演算子 &.

user = User.new
user.name

object = nil
object&.name
# => ここでエラーにならない

1-7-3 %記法

# すべての要素が文字列である配列は、通常の配列記法の他に、「%w」というキーワードを使って書くことができる
ary1 = ['apple','banana','orange']
puts ary1
# irb(main):001:0> ary1 = ['apple','banana','orange']
# => ["apple", "banana", "orange"]
# irb(main):002:0> puts ary1
# apple
# banana
# orange
# => nil

irb(main):003:0> ary2 = %w(apple banana orange)
=> ["apple", "banana", "orange"]

# すべての要素がシンボルの場合は、「%i」というキーワードを使ってかける
irb(main):004:0> ary2 = %i(apple banana orange)
=> [:apple, :banana, :orange]

1-7-4 配列の各要素から特定の属性だけを取り出す

class User
  attr_accessor :name
end

user1 = User.new
user1.name = 'テスト１'
user2 = User.new
user2.name = 'テスト２'
user3 = User.new
user3.name = 'テスト３'

users = [user1, user2, user3]

# ------ 名前だけが入った配列を求める方法１ --------

names = []
user.each do |user|
  names << user.name
end

p names

# ------ 名前だけが入った配列を求める方法２ --------

names = users.map do |user|
  user.name
end

# ------ 名前だけが入った配列を求める方法３ --------

names = users.map { |user| user.name }

# ------ 名前だけが入った配列を求める方４ -------- ※これが一番簡潔！

nemes = users.map(&:name)

※なれないとわからない書き方だと思った

Chapter2 Railsアプリケーションをのぞいてみよう

2-1 コマンド実行環境を準備しよう

2-1-1 Windowsでコマンド実行環境を用意する

windows環境のWSLでubuntuを動かしてそこにRubyを入れる wsl -u root wslにログインしてupdate打つ際に管理者権限が必要なのだが、 Windowsユーザだとパスワード通らなかったのでrootではいって更新コマンド売った

sudo apt update

# Cドライブ直下
ls /mnt/c

2-2 rbenvをインストールしよう

2-2-1 macOSでrbnevをインストール

2-2-2 Windows（WSL）でrbenvをインストール

git clone https://github.com/rbenv.git ~/.rbenv

echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "${rbenv init -}"' >> ~/.bashrc
exit

# 再度ログイン
wsl -u root

rbenv -v
# => バージョンが表示されること


# rbenvでのRubyのインストールを簡単にするプラグイン、ruby-buildをセットアップ
git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build

# こちらのコマンドはhttps://github.com/rbenv/ruby-build/wiki を参照
sudo apt-get install autoconf bison build-essential libssl-dev libyaml-dev libreadline-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm-dev libdb-dev

# libgdbm6 このパッケージが見つからなかった
# sudo apt-get install autoconf bison build-essential libssl-dev libyaml-dev libreadline-dev # zlib1g-dev libncurses5-dev libffi-dev libgdbm libgdbm-dev libdb-dev
# Reading package lists... Done
# Building dependency tree
# Reading state information... Done
# E: Unable to locate package libgdbm

2-3 Rubyのインストール

rbenv install 2.5.1
rbenv global 2.5.1

ruby -v
which ruby

# うまく行かなかったので以下を参照して設定した
# <https://qiita.com/yuma-ito-bd/items/00f89ca0c04909c7c467>

2-3-1 Rubyのパッケージ管理ツール「RubyGems」

Rubyは本体だけでも動作するが、公開されているサードパーティのライブラリを利用することで素早く生産的にプログラミング可能
これらのライブラリは「gem」という形式でパッケージ化されている
本書で取り扱っていくRailsもgemの１つ
Rubygemsと呼ばれるパッケージ管理ツールがgemのインストールや管理を簡単にしてくれる

gem update --system

gem -v

gem list

2-3-2 Bundlerのインストール

Bundler：gemをどのバージョンで利用するのかを管理する仕組み
プロジェクトのディレクトリにGemfileという名前のファイルを作成し、gemの名前を記載しておくとそのとおりにインストールしたり、それらのgemをRubyから利用したりすることができるようになる

gem install bundler

bundle install: Gemfileに記述したgemをインストールする
bundle exec [コマンド]: Bundlerが管理するgemを利用できる状態でコマンドを実行する
bundle init
bundle update

2-4 Railsのインストール

gem install rails -v 5.2.1
rails -v

2-4-1 Node.jsのインストール

Javascriptランタイムとしてnodejsをインストールする

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash - sudo apt install nodejs

nodebrewインストール参考 <https://www.kimoton.com/entry/20190215/1550166179>

2-5 データベースのインストールとセットアップ

2-5-1 macOSの場合

2-5-2 Windows（WSL）の場合

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/${lsb_release -cs}-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -P - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo apt update
sudo apt install postgresql

# 資料に記載の手順でpostgresqlインストールできなさそうだったので以下の手順で実施
# 参考）<https://www.digitalocean.com/community/tutorials/how-to-install-postgresql-on-ubuntu-20-04-quickstart-ja>
sudo apt update
sudo apt install postgresql postgresql-contrib
# サービスが起動しているか確認し起動していなければ立ち上げる
service postgresql status
service postgresql start

2-5-3 トラブルシューティング：RailsでPG::ConnectionBadというエラーになるとき

2-6 Railsに触れてみよう

2-6-1 実際にアプリケーションを動かしてみよう

# 雛形生成
rails new scaffold_app -d postgresql
# 確認
cd scaffold_app
ls
# データベース作成
# railsコマンドではなく、bin/railsコマンドを利用する
# このスクリプトだと、bundle exec railsとして実行したときと同様に、Gemfile通りのgemを利用できる環境上でrailsコマンドを実行することができる
bin/rails db:create

# サーバー起動
bin/rails s

うまくRails立ち上がらないので、書籍とは別のバージョンを入れる
https://qiita.com/Gushi_maru/items/f3b5cc43e135e678085f
apt-get install libpq-dev


# 問題：postgresqlが5432portで立ち上がらない問題
# 原因：Windows側でインストールしているPostgresqlがすでに5432ポートで立ち上がっていたため
# 対策：Windows側で立ち上がっていたサービスを停止した上で起動
root@DORAEMON:/etc/postgresql/10/main# service postgresql start
 * Starting PostgreSQL 10 database server                                                                                                                                                     * Removed stale pid file.
Error: /usr/lib/postgresql/10/bin/pg_ctl /usr/lib/postgresql/10/bin/pg_ctl start -D /var/lib/postgresql/10/main -l /var/log/postgresql/postgresql-10-main.log -s -o  -c config_file="/etc/postgresql/10/main/postgresql.conf"  exited with status 1:
2021-03-28 04:08:07.395 JST [210] LOG:  could not bind IPv4 address "127.0.0.1": Permission denied
2021-03-28 04:08:07.395 JST [210] HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
2021-03-28 04:08:07.395 JST [210] WARNING:  could not create listen socket for "localhost"
2021-03-28 04:08:07.395 JST [210] FATAL:  could not create any TCP/IP sockets
2021-03-28 04:08:07.396 JST [210] LOG:  database system is shut down
pg_ctl: could not start server
Examine the log output.


# 問題：DB作成ができない問題
root@DORAEMON:/mnt/c/users/Tomo/ruby-work/scaffold-app# bin/rails db:create
FATAL:  role "root" does not exist
Couldn't create 'scaffold_app_development' database. Please check your configuration.
rails aborted!
PG::ConnectionBad: FATAL:  role "root" does not exist
/mnt/c/users/Tomo/ruby-work/scaffold-app/bin/rails:9:in `<top (required)>'
/mnt/c/users/Tomo/ruby-work/scaffold-app/bin/spring:15:in `<top (required)>'
bin/rails:3:in `load'
bin/rails:3:in `<main>'
Tasks: TOP => db:create
(See full trace by running task with --trace)

そもそもPostgresqlにユーザ作成しておく必要がありそうなので対応
Postgresqlにユーザを作成する手順
- https://qiita.com/krtsato/items/4565051608a63f11b316
パスワードは環境変数に設定しておき読み込む
- https://www.techscore.com/blog/2012/10/26/how-to-manage-database-yml/
ユーザ作成
- https://qiita.com/sibakenY/items/407b721ad1bd0975bd00

railsはHTTPサーバとしてpumaを使用している
Pumaは広く使用されており、Railsの機能を利用する上で不足はありません。

2-6-1-2 ユーザ管理画面の雛形を作る

# ユーザーに関するscaffoldを自動生成する
bin/rails generate scaffold user name:string address:string age:integer

# ユーザ管理機能に使うデータベースを作成する
bin/rails db:migrate

# 準備が整ったところで再度アプリケーションを起動する
bin/rails s

2-6-1-4 コードの通り道

Controllerからページテンプレート周りの簡単な説明

2-6-1-5 ディレクトリ構成

ディレクトリ構成（割愛）
database.yml
- データベースと接続するための設定ファイル
- development,test,productionという環境用にそれぞれ作成

項目名	説明
adapter	データベースの接続に使用するアダプタの名前を指定します。アダプタには各データベースに対応するsqlite3,postgresql,mysql2,oracle_enhancedなどがある
encoding	文字コード
pool	コネクション数の上限
database	データベース名
username	データベースに接続するユーザ名
password	データベースに接続するユーザのパスワード
host	データベースが動作しているホスト名またはipアドレス

# PostgreSQL. Versions 9.3 and up are supported.
#
# Install the pg driver:
#   gem install pg
# On macOS with Homebrew:
#   gem install pg -- --with-pg-config=/usr/local/bin/pg_config
# On macOS with MacPorts:
#   gem install pg -- --with-pg-config=/opt/local/lib/postgresql84/bin/pg_config
# On Windows:
#   gem install pg
#       Choose the win32 build.
#       Install PostgreSQL and put its /bin directory on your path.
#
# Configure Using Gemfile
# gem 'pg'
#
default: &default
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see Rails configuration guide
  # https://guides.rubyonrails.org/configuring.html#database-pooling
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  database: scaffold_app_development

  # The specified database role being used to connect to postgres.
  # To create additional roles in postgres see `$ createuser --help`.
  # When left blank, postgres will use the default role. This is
  # the same name as the operating system user that initialized the database.
  #username: scaffold_app

  # The password associated with the postgres role (username).
  #password:

  # Connect on a TCP socket. Omitted by default since the client uses a
  # domain socket that doesn't need configuration. Windows does not have
  # domain sockets, so uncomment these lines.
  #host: localhost

  # The TCP port the server listens on. Defaults to 5432.
  # If your server runs on a different port number, change accordingly.
  #port: 5432

  # Schema search path. The server defaults to $user,public
  #schema_search_path: myapp,sharedapp,public

  # Minimum log levels, in increasing order:
  #   debug5, debug4, debug3, debug2, debug1,
  #   log, notice, warning, error, fatal, and panic
  # Defaults to warning.
  #min_messages: notice

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  <<: *default
  database: scaffold_app_test

# As with config/credentials.yml, you never want to store sensitive information,
# like your database password, in your source code. If your source code is
# ever seen by anyone, they now have access to your database.
#
# Instead, provide the password as a unix environment variable when you boot
# the app. Read https://guides.rubyonrails.org/configuring.html#configuring-a-database
# for a full rundown on how to provide these environment variables in a
# production deployment.
#
# On Heroku and other platform providers, you may have a full connection URL
# available as an environment variable. For example:
#
#   DATABASE_URL="postgres://myuser:mypass@localhost/somedatabase"
#
# You can use this database configuration with:
#
#   production:
#     url: <%= ENV['DATABASE_URL'] %>
#
production:
  <<: *default
  database: scaffold_app_production
  username: scaffold_app
  password: <%= ENV['SCAFFOLD_APP_DATABASE_PASSWORD'] %>

Column YAMLの基本

エイリアスとアンカー問機能

animal: &animal
  cat: 'ネコ'
  dog: 'イヌ'

animal_shop_1:
  <<: *animal
  hamster: 'ハムスター'

animal_shop_2:
  <<: *animal
  parrot: 'オウム'

routes.rb
- アプリケーションのルーティングを定義するファイル
- リクエストに対応するレスポンスを作るためにどの処理を実行するかを定義したもの

# すべてのルーティングを確認できる
bin/rails routes

2-6-2 RailsのMVC

Chapter3 タスク管理アプリケーションを作ろう

3-1 アプリケーション作成の準備をしよう

3-1-1 作成するアプリケーションの内容を考える

3-1-2 アプリケーションの名前を決める

3-1-3 アプリケーションのひな形を作成する

3-1-4 データベースの環境ごとの使い分け

3-1-5 ビュー層を効率良く書くためにSlimを使えるようにする

3-1-6 アプリケーションの見栄えを良くするためにBootstrapを導入する

3-1-7 Railsのエラーメッセージなどを日本語で出せるようにする

3-2 タスクモデルを作成する

3-2-1 タスクモデルの属性を設計する

3-2-2 タスクモデルのひな形を作成する

3-2-3 マイグレーションでデータベースにテーブルを追加する

3-3 コントローラとビュー

3-3-1 新規登録機能を実装する

3-3-2 一覧表示機能を実装する

3-3-3 詳細表示機能を実装する

3-3-4 編集機能を実装する

3-3-5 削除機能を実装する

3-3-6 シンプルなCRUD機能の完成

＜レベルアップ編＞

Chapter4 現実の複雑さに対応する

4-1 さまざまなマイグレーション操作を使いこなす

4-1-1 マイグレーションの適用を理解しよう

4-1-2 マイグレーションではバージョンの上げ下げ両方を意識しよう

4-1-3 マイグレーションの名前の付け方に注意する

4-1-4 schema.rb

4-1-5 マイグレーションに関する主なコマンド

4-1-6 マイグレーションの適用中にエラーが出たときは

4-2 データの内容を制限する

4-2-1 データ型

4-2-2 NOT NULL制約

4-2-3 文字列カラムの長さを指定する

4-2-4 ユニークインデックスを作成する

4-3 モデルの「検証」を使う

4-3-1 モデルの検証の仕組み

4-3-2 検証の書き方

4-3-3 必須かどうかの検証を追加する

4-3-4 コントローラとビューで検証エラーに対応する

4-3-5 文字列長の検証を追加する

4-3-6 オリジナルの検証コードを書く

4-3-7 検証が行われない登録・更新操作もある

4-4 モデルの状態を自動的に制御する―「コールバック」

4-4-1 コールバックの仕組み

4-4-2 コールバックの実装

4-4-3 トランザクション

4-5 ログイン機能を作る

4-5-1 セッションとCookie

4-5-2 User モデルを作る

4-5-3 パスワードを受け付けてdigestを保存する

4-5-4 ユーザー管理機能一式を追加する

4-5-5 ログイン機能を実装する

4-5-6 ログインのフォームを表示する

4-5-7 ログインの実行

4-5-8 ログイン状態の取得を簡単にする

4-5-9 ログアウト機能を実装する

4-5-10 ログインしていなければタスク管理を利用できなくする

4-5-11 ログインしているユーザーのデータだけを扱えるようにする

4-5-12 管理機能を管理者ユーザーだけに利用させるようにする

4-5-13 最初の管理者ユーザーを作る

4-6 データを絞り込む

4-6-1 絞り込みの起点

4-6-2 絞り込み条件

4-6-3 実行部分

4-7 タスク一覧を作成日時の新しい順に表示する

4-8 scopeを活用する

4-9 フィルタを使い重複を避ける

4-10 詳しい説明に含まれるURLをリンクとして表示する

4-10-1 まとめ

Chapter5 テストをはじめよう

5-1 テストについて

5-2 テストを書くことのメリット

5-2-1 テスト全体にかかるコストの削減

5-2-2 変更をフットワーク軽く行えるようになる

5-2-3 環境のバージョンアップやリファクタリングの必須条件

5-2-4 仕様変更の影響の大きさを簡単に把握することができる

5-2-5 仕様を記述したドキュメントとしても機能する

5-2-6 仕様やインターフェイスを深く考えるきっかけとして役立つ

5-2-7 適切な粒度のコードになりやすい

5-2-8 確実性を高めることで開発効率を上げる

5-3 本章で利用するテスト用ライブラリ

5-3-1 RSpec

5-3-2 Capybara

5-3-3 FactoryBot

5-4 本章で記述するテストの種類

5-4-1 モデルのテスト

5-4-2 結合テスト

5-4-3 ルーティング、メーラー、ジョブのテスト

5-4-4 あまり利用しないテスト

Column System Specとは？

5-5 System Specを書くための準備

5-5-1 RSpecのインストールと初期準備

5-5-2 Capybaraの初期準備

5-5-3 FactoryBotのインストール

5-6 RSpecの基本形

5-7 FactoryBotでテストデータを作成できるように準備する

5-8 タスクの一覧表示機能のSystem Spec

5-8-1 ユーザーAを作成しておく

5-8-2 作成者がユーザーAであるタスクを作成しておく

5-8-3 ユーザーAでログインする

5-8-4 作成済みのタスクの名称が画面上に表示されていることを確認

5-9 他のユーザーが作成したタスクが表示されないことの確認

5-10 beforeを利用した共通化

5-11 letを利用した共通化

Column letとlet!

5-12 詳細表示機能のSpecを追加する

5-13 shared_examplesを利用する

5-14 新規作成機能のSystem Spec

5-15 letの上書き

5-16 Specが失敗したときの調査方法

5-16-1 Specが失敗するとき

5-16-2 Specが失敗したときに確認すべき情報

5-16-3 失敗場所とエラーメッセージを手がかりに原因を探す

5-16-4 コンソールを使って調査する

5-16-5 スクリーンショットを活用する

Chapter6 Railsの全体像を理解する

6-1 Railsを取り巻く世界

6-2 ルーティング

6-2-1 「ルート」を構成する5つの要素

6-2-2 1つのルートを定義する

Column URLヘルパーメソッドは使わなくてはダメ？

6-2-3 「 RESTful」の概要をつかんでおこう

6-2-4 RESTfulにするための Railsの流儀

Column RESTfulはどの程度追求すべき？

6-2-5 resourcesでCRUDのルート一式を定義する

6-2-6 routes.rbの構造化

Column routes.rbの整理のコツ

6-3 国際化

6-3-1 ユーザーごとに言語を切り替える

6-3-2 翻訳ファイルの扱い方

6-4 日時の扱い方

6-4-1 日時の扱い方に関する設定

6-4-2 taskleafアプリケーションのデフォルトのタイムゾーンを日本時間にする

6-4-3 Time.currentやDate.currentを利用する

6-5 エラー処理のカスタマイズ

6-5-1 Railsのエラー処理の概要

6-5-2 デバッグ用/本番用のエラー画面の切り分け

6-5-3 Railsの本番用エラー画面のカスタマイズ

6-5-4 アプリケーション固有のエラー処理の追加

6-6 Railsのログ

6-6-1 ログの利用方法

6-6-2 ログ（ロガー）の設定

6-7 セキュリティを強化する

6-7-1 意図しないパラメータを弾く「Strong Parameters」

6-7-2 CSRF対策を利用する

6-7-3 インジェクションに注意する

6-7-4 Content Security Policy（CSP）を設定する

6-8 アセットパイプライン

6-8-1 環境による挙動の違い

6-8-2 ブラウザにアセットを読み込ませる

6-8-3 連結結果のファイルをどうやって生成するか

6-8-4 マニフェストファイルを記述する

6-8-5 アセットの探索パス

6-8-6 アセット関連の設定

6-9 production環境でアプリケーションを立ち上げる

6-9-1 アセットのプリコンパイル

6-9-2 静的ファイルの配信サーバを設定する

6-9-3 production環境用のデータベースを作成する

6-9-4 config/master.key が存在することを確認する

6-9-5 productionモードでサーバを起動する

6-9-6 production環境用の秘密情報の管理

6-9-7 秘密情報の暗号化・復号

Column secret_key_base

Column カスタム暗号化ファイル（Encrypted）

Chapter7 機能を追加してみよう

7-1 登録や編集の実行前に確認画面をはさむ

7-1-1 確認画面を表示するアクションを追加する

7-1-2 新規登録画面からの遷移先を変える

7-1-3 登録アクションで「戻る」ボタンからの遷移に対応する

Column 確認画面があるほうが良いとは限らない

7-2 一覧画面に検索機能を追加する

7-2-1 Ransackのインストール

7-2-2 名称による検索

7-2-3 検索時のSQLの確認と検索マッチャー

7-2-4 登録日時による検索

7-2-5 検索条件を絞る

7-3 一覧画面にソート機能を追加する

7-4 メールを送る

7-4-1 メイラーの実装

7-4-2 テンプレートの実装

7-4-3 メール送信処理

7-4-4 動作確認

7-4-5 メイラーのテスト

7-5 ファイルをアップロードしてモデルに添付する

7-5-1 タスクに画像ファイルを添付する

7-5-2 Active Storage

7-5-3 Active Storageの準備

7-5-4 タスクモデルに画像を添付できるようにする

7-6 CSV形式のファイルのインポート/エクスポート

7-6-1 タスクをCSV出力（エクスポート）する

7-6-2 CSVデータを入力（インポート）する

7-7 ページネーション

7-7-1 kaminariのインストール

7-7-2 ページ番号に対応する範囲のデータを検索するようにする

7-7-3 ビューにページネーションのための情報を表示する

7-7-4 動作確認

7-7-5 デザインの調整

7-7-6 表示件数を変更したいとき

7-8 非同期処理や定期実行を行う（Jobスケジューリング）

7-8-1 非同期処理ツールの導入

7-8-2 ジョブの作成、実行

7-8-3 実行日時指定

7-8-4 ７章の終わりに

＜発展編＞

Chapter8 RailsとJavaScript

8-1 JavaScriptでページに変化をつける

8-2 AjaxでRailsサーバと通信する

8-2-1 Ajaxでタスクを削除する

8-2-2 rails-ujsの果たしている役割

8-2-3 コントローラからJavaScriptを返して実行する（SJR）

Column CoffeeScriptは使わないことも検討する

Column jQuery

8-3 Turbolinks

8-3-1 Turbolinksの発行するイベント

8-3-3 Turbolinksが有効な環境での注意点

8-3-4 Turbolinksを無効化するには

8-4 モダンなJavaScript管理を行う

8-4-1 Yarn

8-4-2 Webpacker

8-5 taskleafにReactを導入してみる

Column Webpackerのメリット・デメリット

Chapter9 複数人でRailsアプリケーションを開発する

9-1 チーム開発の風景（導入編）

9-1-1 ソースコードの変更を管理する

9-1-2 GitHubなどの開発プラットフォームを使う

9-1-3 GitHubを使うには？

9-1-4 Pull Requestベースの開発

9-1-5 Gitに入れるファイル、入れないファイル

Column database.ymlとセキュリティ

9-1-6 Pull Requestの変更差分を最新状態との比較にする

9-1-7 Gitのpush -fに気をつける

9-1-8 GitHubとチャットツールを連携させる

9-2 チーム開発の風景（コードレビュー編）

9-2-1 コードレビューではどんな点を見て、何をコメントする？

9-2-2 コーディング規約

Column コーディング規約との付き合い方

9-2-3 Lintツールの活用

Column コードレビューは素晴らしい、だが万能ではない

9-2-4 CIツールとGitHubを連動させる

9-3 チーム開発の風景（分担編）

9-3-1 チームで開発するときの分担の仕方

9-4 開発環境の構築方法をわかりやすくしておく

9-4-1 誰でも簡単にセットアップできるようにする

9-4-2 仮想化環境を利用する

9-4-3 初期データ・テスト用データの共有

9-5 マイグレーションに注意する

9-5-1 ロールバックできることを確認しよう

9-5-2 「redo」を習慣にしよう

9-5-3 完全なロールバックができないとき

9-5-4 過去のマイグレーションファイルの変更には慎重になろう

Column 「きれいなマイグレーション」を追求しない

9-5-5 マイグレーションファイルが多くなってきたら

9-5-6 直接DBを変更したら必ずマイグレーションファイルも追加しておこう

9-5-7 データメンテナンス

Column Rakeタスクでのデータメンテナンス

Chapter10 Railsアプリケーションと長く付き合うために

10-1 バージョンアップにどう取り組むか

10-2 小さなバージョンアップ

10-2-1 bundle updateとは

10-2-2 bundle updateの際に行うべきこと

10-3 bundle update はチーム全体で行う

10-4 bundle updateを自動化でサポートする

10-5 大きなバージョンアップを行う際に気をつけること

10-6 アプリケーションの複雑性に立ち向かう

10-7 第一の鍵─しかるべきところにコードを書く

10-7-1 コントローラに入り込む複雑さ

10-7-2 モデルに書くべきコードをモデルに寄せる

10-7-3 ビューに入り込んだビジネスロジックをモデルに寄せる

10-7-4 Decoratorパターンでモデル固有の表示ロジックを分離する

10-8 第二の鍵─上手に共通化する

10-9 モデルの共通化

10-9-1 共通機能のモジュールを複数のモデルクラスにMix-inする

10-9-2 STI（単一テーブル継承）で共通機能を基底クラスに持たせる

10-9-3 全モデルクラスに共通の処理をApplicationRecordに書く

10-9-3 ApplicationRecordとモデルクラスの間に抽象的なクラスを挟む

10-10 コントローラの共通化

10-10-1 共通機能のモジュールを複数のコントローラクラスにMix-inする

10-10-2 基底クラスを追加して共通機能を持たせる

10-10-3 ApplicationControllerに共通機能を記述する

10-10-4 第一の鍵を使わない状態で第二の鍵を使ってはいけない

10-11 ビュー（プレゼンテーション）の共通化

10-11-1 パーシャルテンプレートで画面の一部を共通化する

10-11-2 レイアウトで画面の大枠を共通化する

10-11-3 カスタムヘルパーに共通処理を記述する

10-11-4 カスタムヘルパーは小さく作る

10-11-5 特定のモデルに依存する処理をカスタムヘルパーに含めない

10-12 第三の鍵─新しい構造を追加して役割を分担する

10-12-1 ActiveModel

10-12-2 共通処理を担当するオブジェクトを別につくって連携させる

10-12-3 意味のあるパラメータの集合からクラスを生み出す

10-12-4 外部サービスのロジックを閉じ込める

10-12-5 複数のモデルが絡む特定処理の専門家を作る

10-12-6 サブリソース単位でコントローラを分割する

Column 何でも屋のアクションを実装しない

10-13 モジュールを上手に利用するために

10-13-1 構造として分かりやすい意味を持たせる

10-13-2 利用元クラスの一部として違和感がないかを検討する

10-13-3 利用元クラスと内部データを共有していることを意識する

10-13-4 独立的にして利用条件を分かりやすくする

10-13-5 追加部品であるという節度を守る

10-14 おわりに

Appendix

Index

Gradle徹底入門次世代ビルドツールによる自動化基盤の構築

Sat, 13 Jun 2020 00:00:00 GMT

Gradle徹底入門次世代ビルドツールによる自動化基盤の構築

理解したこと

書籍情報

形式：書籍発売日：2014年11月04日 ISBN：9784798136431 価格：本体3,800円＋税仕様：B5変・592ページ分類：プログラミング・開発シリーズ：徹底入門

日本語初のGradle解説書、ついに刊行！ Groovyベースのビルドツール「Gradle」は、SpringやHibernateなどの著名なOSSで利用されているほか、Androidの公式ビルドツールとして採用されており、これからの開発者やビルド職人には無視することのできないツールのひとつと言えるでしょう。本書は、GradleのインストールからJavaアプリケーションのビルドやテスト、依存関係の管理、ビルド成果物の公開などのGradleの主要な機能の解説に加え、詳細なスクリプトファイルの記述方法からCIツールやIDEとの連携といった実業務で必要となる範囲までをカバーした日本語初のGradleの解説書となります。有識者によるGradle 2.0ベース（1.x系ベースの章や2.1のトピックなどもあります）で書き下ろされた500ページを超える本書は「徹底入門」の名に恥じない内容で、これだけ充実したGradle解説書は、日本語ではもちろん英語でも類を見ません。これからGradleを始める人、Gradleをもっと使いこなしたい人、GradleとJenkinsでCIをやりたい人、AntやMavenからの移行を考えている人…などなど、多くの開発者やビルド職人にお勧めできる一冊です。

サンプルコード
- https://www.shoeisha.co.jp/book/download/9784798136431/detail

第1部［導入編］

第1章 Gradle の世界

1.1 Gradleとは

次世代のビルドツールとして注目を集めているオープンソースのプロダクト
Gradleが注目されている理由
- 既存のビルドツールに比べて優れている点が多い
- Gradleのビルドスクリプトは非常にシンプルに記述できるという点
- 具体的には本書を読みすすめると実感できる
NOTE
- 特に、肥大したAntのビルドすくリプの保守に苦労された方や、Mavenに入門しようとしたものの敷居の高さに挫折した方にはおすすめ
もう１つの利点
- AntやMaavenといった既存のビルドツールのエコシステムを最大限活用しているという点がある
- Gradleは既存のAntタスクやAntビルドスクリプト、さたにMavenリポジトリを利用できるので、過去に蓄積してきた資産は無駄にならない
- それらの資産を最大限利用して段階的にGradleに移行していくことが可能

1.1.1 ビルドツールとは

ビルドツールとは
- 定型的な作業を自動化するためのソフトウェア

1.1.2 ビルドツールの歴史

ビルドツールの進化は比較的緩やかですが、時代とともに着実に発展しています。
ここでは、その進化の流れをたどってみたいと思います。
元祖ビルドツールMake
- 元祖はUnix系OSにおけるMakeといって差し支えない
JavaのためのビルドツールAnt
- Antは当時流行のJavaとXMLを採用することで、Makeの弱点であったプラットフォーム依存から脱却することに成功
- シンプルで使いやすい反面、ちょっと複雑なことをしようとするとビルドスクリプトが長大になる
- メンテナンスが困難になる
- ライブラリの依存関係を管理する仕組みが無い
ビルドツールの革新者Maven
- JavaとXMLによるプラットフォーム独立のアーキテクチャはAntと同じですが、ビルドツールにビルドライフサイクルとプロジェクトオブジェクトモデル（POM）という概念を持ち込むことで、Antの弱点であったビルドスクリプトの冗長化を解消
- また、POMにメタデータをもたせることで、ライブラリの依存関係を自動的に解決する仕組みを構築することに成功
そしてGradleへ

1.1.3 Gradleの概要

GradleプロジェクトのWebサイトでは、Gradleとは、Build Automation Evolved すなわち、「ビルド自動化ツールの進化系」であると紹介されている
Gradleの特徴
- 拡張可能なGradleビルド言語（GSL）の提供
- ビルドの分割や共通部品抽出などの体系化の容易さ
- IDEなどと連携するため、Gradleを外部からコントロールするためのAPIを提供
- インクリメンタルビルドや並列ビルドなどでビルドを効率化
- マルチプロジェクトサポートの柔軟性
- Maven/Ivyリポジトリからローカルファイルシステムまで多用な依存関係管理手法に対応
- Antタスクだけでなく、Antプロジェクト全体とのインテグレーションに対応
- ビルドスクリプトの記述言語としてGroovyを利用
- GradleラッパーによってGradleがインストールされていない環境でもビルドが実行可能
- 互換性への配慮
Gradle User Guid
- http://www.gradle.org/documentation
Gradleユーザーガイド（日本語翻訳版）
- http://gradle.monochromeroad.com/docs/

1.1.4 Gradleの事例

Gradleが普及している例が紹介されている
AntやMavenと比較するとIDE連携やアプリケーションサーバー連携などが課題らしい

1.2 なぜGradleなのか？

1.2.1 ビルドスクリプトの生産性の高さ

GradleはMavenと同じく、規約ベースのビルドというアプローチを採用している
これにより、規約に従ったプロジェクト構造（ディレクトリ構造）を使う限りにおいては、ビルドスクリプトの記述を大幅に省略可能
GradleはJVM言語であるGroovyをベースに構築されている
GroovyはJavaにはない、リストリテラル/マップリテラル/クロージャといった機能が使える
GradleはたんにGroovyの文法を利用するだけでなく、ビルドスクリプトをより簡潔に記述するための独自の文法（DSL）も提供している
NOTE
- XMLは静的な構造を表現することは得意ですが、ビルドスクリプトのような手順（手続き）を表現することには適していない

1.2.2 ビルド手順の制御の容易性

Mavenの偉大な業績として
- 大半のプロジェクトに適用できる標準的なビルド手順
- メタデータによるビルド手順の制御
  - という考え方を導入し、それを実現する具体的なアイデアとしてPOMを導入したことが挙げられる

1.2.3 マルチプロジェクト対応

サブプロジェクトに共通するビルドの設定など
- マルチプロジェクトに含めるサブプロジェクトを定義する機能
- サブプロジェクトに共通のビルドスクリプトを集約する機能
- サブプロジェクト間の依存関係を定義する機能
- 依存関係を考慮してインクリメンタルビルドする機能
機能を列挙してみるとやや複雑そうな印象を受けますが、実際のビルドスクリプトは非常にシンプル
HibernateがGradleに乗り換えた理由も「マルチプロジェクト対応が優秀だったから」だそう

1.2.4 部品化の手軽さ

部品化も簡単だよーという説明

1.2.5 個別インストール不要

AntやMavenを使う際には、利用者の環境にインストールしなければならない
ことのあるバージョンを導入してしまう可能性がある
このような問題に対処するために、GradleはGradleラッパーという仕組みを提供している
Gradleラッパーはプロジェクト内にGradleのブートストラップを仕込むことで、指定されたバージョンのGradleを必要に応じて自動的にインストールして実行してくれる機能
使い方は簡単で、あらかじめGradleのwrapperタスクを実行してブートストラップを生成しておくだけです。
それをそのままSubversionやGitなどのバージョン管理システムに登録しておけば、利用者はバージョン管理システムからプロジェクトをチェックアウトし、gradlewコマンドを実行するだけで、Gradleのバイナリがダウンロードされ、ビルドが行われます。
Note
- このGradleラッパーは優れたアイデアで、最近のビルドツールは同様にインストールレスで使えるようにしているものが増えてきているそう

1.2.6 互換性への配慮

互換性への方針
- 既存の機能が突然使えなくなるような変更は行わない
- 機能を除去する場合は、将来的に廃止される可能性を明示して段階的に除去する
- 新機能は十分なフィードバックを受けて安定してから固定化する
ライフサイクル
- 非公開
- 実験的
- 公開
- 廃止

1.3 他のビルドツールとの比較

1.3.1 Make vs Gradle

優位性
- クロスプラットフォーム対応
- 依存関係解決の機能

1.3.2 Ant vs Gradle

優位性
- 依存関係解決の機能
- 規約が無いため再利用性が損なわれる
- 基本機能がシンプルであるがゆえに複雑なことをしようとすると冗長になる

1.3.3 Maven vs Gradle

第2章インストールと設定

2.1 Gradleのインストール

2.1.1 前提条件

Gradleを利用するためにはJDK6以上が必要 Gradleは内部にGroovyのライブラリをバンドルしているので、別途Groovyをインストールする必要はない

2.1.2 GVMによるGradleのインストール

MacOSXやLinux、CygwinなどでBashが使える環境であれば、
おすすめのインストール方法はGVM（the Groovy enVironment Manager）を利用することです。
GVMとは、GroovyやGrailsなどいわゆるGroovyエコシステムに付随するプロダクトのインストールやアップデートを一元的に行うためのツール

// 事前準備
// curl と unzipは使えること

// GVMのインストール
curl -s get.gvm.net | bash

// プロキシ設定されていたら
export http_proxy = htpp://<proxyhost>:<port>/

// インストール後は、 `~/.bashrc`が書き換えられ、GVMが利用可能な状態になるので
// .source ~/.gvm/bin/gvm-init.sh を実行して環境設定を更新してください

// インストールされていることを確認
gvm help

// GVMのオフラインモード切り替え
gvm offline enable
gvm offline disable

// Gradleのインストール
gvm install gradle

// インストール可能なGradleのバージョン確認
gvm list gradle
gvm install gradle <version>

// 複数のバージョンのGradleをインストールしている場合切り替えることができる
gvm default gradle <version>

2.1.3 ZIPファイル展開によるインストール

Windowsのインストール方法を説明

2.2 基本的な設定と動作確認

2.2.1 環境変数の設定

環境設定
- gradleコマンドへパスが通っていること
- java コマンドが実行できること
JAVA_OPTS、GRADLE_OPTSの設定についても言及

2.2.2 gradleコマンドの実行

gradle -v

第3章スタートアップGradle

3.1 Groovy特有の文法

Gradleのビルドスクリプトは、実際にはGroovyのスクリプトしかし、Gradleの提供するDSLのおかげで、Groovyのことはあまり意識せずにビルドスクリプトが記述できるようになっている Groovyの文法はJavaと互換性があるので、Javaを知っていれば文法的に難解な箇所はそれほどないでしょう

とはいえ、Groovy特有の文法を知らないと、Gradleのビルドスクリプトを読み書きするのが難しいのも事実 Gradleでよく使われるものに絞って文法を説明

3.1.1 文字列

文字列の表記方法として大きく２通りの方法が利用できる

シングルクォート：Javaの文字列とほぼ同等の利用方法
ダブルクォート：文字列の内部に$記号で動的な内容を埋め込むことができる。内部的には、GroovyのGStringというクラスが使われる

3.1.2 メソッド呼び出し時のカッコ省略

3.1.3 defによる型指定の省略

// 型を指定した変数定義
String name = 'John'
// 型を省略下変数定義
def name = 'John'

// Javaにおいて、Object型を指定した場合と同等になる
// ただし、Groovyの場合はダックタイピングの機能があるため、型としてdefを指定した場合でもオブジェクトのメソッドやプロパティは参照できる

3.1.4 クロージャ

Groovyは言語機能としてクロージャを提供している Java8で導入されたラムダや、他のプログラム言語で言うところの関数オブジェクトのようなものと理解しておいて

クロージャは中括弧を利用して定義し、<クロージャ名>.call()または、通常のメソッド呼び出しと同様に<クロージャ名>()で実行できる

// クロージャ定義
def clos1 = { mes -> println "Hi, $mes"}
// 引数と省略した場合は、暗黙引数itを利用
def clos2 = { println "Hi, $it"}

// クロージャ実行
clos1.call('John')
clos2('Bob')
// メソッド呼び出しと同様にカッコ省略可能
clos2 'Alice'

Gradleはクロージャを多用しており、例えば次のようなタスク定義はクロージャによって実現されている

task hello << {
  println 'Hello Gradle world!'
}

// 上記を個別に定義した場合は下記のようになる

// タスクへ追加する処理をクロージャとして定義
def clos = { println 'Hello Gradle world!' }

// タスクを定義
task hello {}
// タスクにクロージャを追加
// << は leftShift()の省略形なので以下と等価
hello.leftShift(clos)

3.2 Hello Gradle world

3.2.1 ビルドスクリプトの作成と実行

task hello doLast {
  println 'Hello Gradle world!'
}
task hello2 doLast {
  println 'Hello Gradle world!(hello2)'
}
// doLast欠かないとConfigure扱いになって起動時に処理はしるらしい

MEMO: Gradle3以降ぐらいから、leftShiftが非推奨になりつかなくなった様子
- 代わりにdoLastを使うのだとかhttps://qiita.com/ossan_pg/items/608134f44ccf4542edf2

3.2.2 ビルドスクリプトと実行結果の解説

実行結果について説明しているだけ

3.2.3 組み込みタスク

Gradleはビルドスクリプトで特に何も指定していなくても利用可能なタスクを提供しているこれらのタスクのことを「組み込みタスク（built-in tasks）」と呼びますタスクの一覧はgradle tasks で確認できる

E:\XXX_POKET\020_資格・学習\JAVA\20200613_Gradle徹底入門\practice\chap3>gradle tasks

> Task :tasks

------------------------------------------------------------
Tasks runnable from root project
------------------------------------------------------------

Build Setup tasks
-----------------
init - Initializes a new Gradle build.
wrapper - Generates Gradle wrapper files.

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'chap3'.
components - Displays the components produced by root project 'chap3'. [incubating]
dependencies - Displays all dependencies declared in root project 'chap3'.
dependencyInsight - Displays the insight into a specific dependency in root project 'chap3'.
dependentComponents - Displays the dependent components of components in root project 'chap3'. [incubating]
help - Displays a help message.
model - Displays the configuration model of root project 'chap3'. [incubating]
projects - Displays the sub-projects of root project 'chap3'.
properties - Displays the properties of root project 'chap3'.
tasks - Displays the tasks runnable from root project 'chap3'.

To see all tasks and more detail, run gradle tasks --all

To see more detail about a task, run gradle help --task <task>

BUILD SUCCESSFUL in 1s
1 actionable task: 1 executed

initタスクは「Build Setup tasks」に属しており、ビルドの初期化を行うタスクであるということが読み取れます
プラグインを追加することで利用できるタスクも追加されるので、gradle tasksで利用できるタスクを一覧で見れるということを覚えておく

また、よく使う組み込みタスクとして、gradle propertiesがあるこれはGradleのビルドスクリプトに定義されているプログラムの一覧を表示するタスク

3.2.4 主要なコマンドラインオプション

ログ出力量の少ない順にGradleのコマンドラインオプションを並べると次のようになる
- -i (--info)
  - ログレベルがINFOになり、ビルドスクリプトのファイル名などの情報が表示されるようになる
- -s (--stacktrace)
  - 例外発生時にユーザー例外部分のみスタックトレースを表示
- -S (--full-stacktrace)
  - 例外発生時にすべてのスタックトレースを表示
- -d (--debug)
  - ログレベルがDEBUGに設定され、非常に詳細な情報が表示される様になる
デフォルトのbuild.gradleファイル以外のファイル名のビルドスクリプトを指定する場合
- gradle -b build-new.gradle

3.3 プロジェクト自動生成とビルド

3.3.1 initタスクによるプロジェクト自動生成

gradle init --type java-library
// 生成される
// 途中、使用するDSLなどを聞かれる

Gradleの規約はMavenに倣って定義されているので、プロダクションコードは、
- src/main/java以下
- テストコードは
  - src/test/java以下に配置される
NOTE
- Gradleは、規約とは異なる場所にJavaソースを配置することもできる

/*
 * This file was generated by the Gradle 'init' task.
 *
 * This generated file contains a sample Java Library project to get you started.
 * For more details take a look at the Java Libraries chapter in the Gradle
 * User Manual available at https://docs.gradle.org/5.5.1/userguide/java_library_plugin.html
 */

plugins {
    // ★Javaプラグインが適用されている
    // これによりjavaプロジェクトに対する規約（プロダクションコードをsrc/main/javaに配置するなど）やJavaプロジェクトのビルドに必要なタスクが追加されます
    // Apply the java-library plugin to add support for Java Library
    id 'java-library'
}
// 昔の書き方として以下があったらしい
apply plugin: 'java'


repositories {
    // ★Maven Centralリポジトリを指定
    mavenCentral()
    // Use jcenter for resolving dependencies.
    // You can declare any Maven/Ivy/file repository here.
    jcenter()
}

dependencies {
    // 'group:name:version'という省略記法でプラグインが記載されている
    // compileやtestCompileというキーワードがありますが、これはJavaプラグインによって定義されているコンフィグレーションを意味している 詳しくは第４章で解説

    // This dependency is exported to consumers, that is to say found on their compile classpath.
    api 'org.apache.commons:commons-math3:3.6.1'

    // This dependency is used internally, and not exposed to consumers on their own compile classpath.
    implementation 'com.google.guava:guava:27.1-jre'

    // Use JUnit test framework
    testImplementation 'junit:junit:4.12'
}

3.3.2 ビルド実行と結果確認

先程自動生成したJavaプロジェクトをそのままビルドしてみましょう

gradle tasks
// 様々なタスクが追加されていることを確認

// ビルド実行
gradle build

ビルド実行直後再度ビルドすると、[UP-TO-DATE]と判断されて、処理がスキップされる様になっている

3.3.3 テスト実行と結果確認

buildタスクの実行によって、testタスクも実行されている
今回の場合、自動生成されたテストコードがコンパイルされ、テストが実行されている

レポートを確認してみる HTML形式レポートが出力されていることを確認

build/test-resultsディレクトリ以下を確認してみると、TEST-LibraryTest.xmlというファイルが生成されていることがわかるこれはJUnit4が出力するXML形式のテストレポートで、Jenkinsなど他システムとの連携が必要な場合にはこちらを利用することになる

NOTE
- じつは、先程確認したHTML形式のテストレポートは、このXML形式のテストレポートをGradleのJavaプラグインが加工して生成したもの

3.4 Webアプリケーションのビルド

WebアプリケーションをビルドしてTomcat上で実行するビルドスクリプトを作成してみる

NOTE
- Gradleの標準プラグインにJettyプラグインがあり、そちらを利用して組み込みJettyによるWebアプリケーションのテストを行うことも可能
- しかし、このプラグインで起動されるJettyバージョンがJetty6と古く、Servlet3.0など新しいAPIに対応していません。
- そのため、ここではサードパーティのプラグインを利用する手順を紹介しています。

3.4.1 Webプロジェクトの作成

前回のjavaプロジェクトの、build.gradleを修正してWebプロジェクトへ発展させる

gradle init --type java-library

/*
 * This file was generated by the Gradle 'init' task.
 *
 * This generated file contains a sample Java Library project to get you started.
 * For more details take a look at the Java Libraries chapter in the Gradle
 * User Manual available at https://docs.gradle.org/5.5.1/userguide/java_library_plugin.html
 */

// (1) Tomcatプラグイン利用のための設定
buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.bmuschko:gradle-tomcat-plugin:2.0'
    }
}


plugins {
    // Apply the java-library plugin to add support for Java Library
    id 'java-library'
    // WARプラグイン追加
    // id 'war'
    // Tomcatプラグイン適用
    // id 'com.bmuschko.tomcat'
    // id 'com.bmuschko.tomcat-base'
}
apply plugin: 'war'
apply plugin: 'com.bmuschko.tomcat'


repositories {
    // セントラルレポジトリ追加
    mavenCentral()
    // Use jcenter for resolving dependencies.
    // You can declare any Maven/Ivy/file repository here.
    jcenter()
}

dependencies {
    // (4) 依存関係にJava EE 6のAPIを追加
    // ビルド時には参照するが、ビルド生成物からは除外する　用に指定している
    providedCompile 'javax:javaee-web-api:6.0'
    compile 'org.slf4j:slf4j-api:1.7.5'

    // This dependency is exported to consumers, that is to say found on their compile classpath.
    api 'org.apache.commons:commons-math3:3.6.1'

    // This dependency is used internally, and not exposed to consumers on their own compile classpath.
    implementation 'com.google.guava:guava:27.1-jre'

    // Use JUnit test framework
    testImplementation 'junit:junit:4.12'
    
    
    // (5) Tomcat実行に必要な依存ライブラリの設定
    def tomcatVersion = '7.0.52'
      tomcat "org.apache.tomcat.embed:tomcat-embed-core:${tomcatVersion}",
             "org.apache.tomcat.embed:tomcat-embed-logging-juli:${tomcatVersion}"
      tomcat("org.apache.tomcat.embed:tomcat-embed-jasper:${tomcatVersion}") {
        exclude group: 'org.eclipse.jdt.core.compiler', module: 'ecj'
    }
}

gradle tomcatRunWar
gradle tRW

Buildエラーは出力されるが、アクセスできたhttp://localhost:8080/chap3-java-web/

3.4.3 WARファイルの生成

gradle war

3.5 Gradleの便利な機能

Gradleを使うにあたって知っておくと便利な機能を本章の最後に紹介

3.5.1 Gradleデーモン

Gradleを本格的に使い始めると、まず気になるところが、gradleコマンドの起動に時間がかかること

この起動時間を解消するために、Gradleは「Gradleデーモン」という機能を提供している Gradleデーモンを利用すると、毎回JavaVMを起動/停止するのではなく、JavaVMを常駐させておくことができる

gradleコマンドを事項してGradleデーモン(JavaVMプロセス)を常駐させてしまえば 2度目以降のビルドは非常に高速に実行される用になります。

gradle --daemon hello

// デフォルトでデーモンを有効にしたい場合
// GRADLE_OPTSに追加する
GRADLE_OPS="-Dorg.gradle.daemon=true"
// gradle.propertiesに追加する
org.gradle.daemon=true

// デーモンは一定時間で停止されるが、明示的に停止する場合以下を実行
gradle --stop

3.5.2 Gradleラッパー

新しいツールを現在進行中のプロジェクトに適用したい場合、以下の試練がある

Gradleの良さを紹介する
インストール方法を説明する
使い方を説明する
慣れるまでサポートする

この問題はGradleラッパーで解消できる

このメリット
- 利用するGradleのバージョンを固定できる
- JenkinsなどのCIツールを実行する環境にGradleをインストールしなくてよい

第2部［基礎編］

第4章 Java プロジェクトのビルド

4.1 Javaプロジェクトになぜプラグインが必要なのか？

標準機能だけでJavaプロジェクトのビルドもできないの？と疑問に思われるかもしれない実は、Gradleのコア機能は次の２つのみで構成されている

定型的に繰り返し行う作業を自動化するための仕組み
自動化された処理を実行するための部品

Gradleの看板機能であるビルド例外ではなく、自動化の対象となる具体的な作業はすべてプラグインとして実装されており、コア機能からは分離されている厳密に言えば、Gradleは「ビルドツール」ではなく、「拡張可能な自動化ツール」と呼ぶのが適切なのだと思います。

このように、JavaプロジェクトのビルドにJavaプラグインが必要である背景には、Gradleのアーキテクチャに起因する理由がある

4.2 Javaプラグインとは

Javaプラグインがどのようなものかを見ていきましょう

Javaプラグイン
- タスク：Javaのビルドに必要
- 規約：設定を簡略化する
- プロパティ
- ソースセット
  - がパッケージングされたビルド機能のコンポーネント

4.2.1 ソースセット

最も重要なソースセットについて説明

ビルド対象となるソースの種類として、・プロダクションコード・テストコード　・ユニットテスト　・インテグレーションテストと、様々ある

このような構成に対応するためにソースセットという仕組みを提供している

特徴
- ビルドスクリプト内に自由に追加できる
- ユニークな名前を持つ
- コンパイルの入力となるJavaソースおよびリソースのセットが指定できる
- コンパイルの出力（クラスファイルなど）を生成するパスが指定できる
- コンパイル時のクラスパス、及び実行時のクラスパスが指定できる
- ソースセットごとに専用のタスクを提供する
- ソースセットごとに専用のプロパティを提供する

例えば、テストコードのコンパイルを行う前にプロダクションコードをコンパイルしておく必要がある場合、テストコードに対応するソースセットのコンパイルタスクの依存関係にプロダクションコードのコンパイルタスクを設定するだけで済みます

Javaプラグインにはあらかじめmainとtestという２つのソースセットが定義されている２種類のソースセットだけで対応可能なJavaプロジェクトであれば、独自にソースセットを追加する必要はない

4.2.2 タスク

ビルドに必要な作業
- ソースファイルのコンパイル
- テスト
- Javadocの生成
- JARファイルなどへのアーカイブ
GradleのJavaプラグインには、そのすべての機能がタスクとして定義されている
主要なタスク
- clean
- build
- javadoc
- jar

4.2.3 規約

規約＝約束事

Javaプラグイン規約
- プロダクションコードのソース・ファイルはsrc/main/javaディレクトリ配下に配置していること
- プロダクションコードのリソースはsrc/main/resourcesディレクトリ配下に配置していること
- テストコードのソースファイルはsrc/test/javaディレクトリ配下に配置していること
- テストコードのリソースはsrc/test/resourcesディレクトリ配下に配置していること
Mavenを使ったことのある人には馴染みの深いもの
規約に関してはMavenという先輩の知恵を有効活用している

4.2.4 プロパティ

多くのプロパティにはデフォルト値が設定されている

4.3 Javaプロジェクトへの適用

本章ではJavaプラグインの仕組みを理解するために、あえて手作業で作成

4.3.1 基本的なビルドの定義と実行

4.3.2 テストコードを含むビルドの定義と実行

4.3.3 その他の作業

コンパイルオプションの設定
- compileJavaタスクやtestCompileJavaタスクなどのJavaCompile型のタスクに対しては、optionsプロパティを利用して詳細なコンパイルオプションを設定できます。

compileJava {
  // forkした別プロセスでコンパイルを行う
  options.fork = true

  // lint を無効化する
  options.compilerArgs << '-Xdlint:unchecked'
}

JARファイルの設定

jar {
  baseName = 'example'
  appendix = 'bin'
  version = '0.1'
  classifier = 'jdk17'
}

// 直接指定する場合
jar {
  archiveName = 'example.jar'
}

MANIFEST.MFのカスタマイズ
Javadoc生成

javadoc {
  destinationDir = file("${buildDir/dist/javadoc}")
  title = 'example library V0.1'
}
// @linkタグでJava標準APIのJavadocへリンクする場合など、外部のJavadocへのリンクを生成したい場合は次の用にする
javadoc {
  options.links << 'http://docs.oracle.com/javase/jp/7/api/'
}

ビルド出力のクリーンアップ
- 削除したい場合
- Javadocのみ削除したい場合、gradle cleanJavadocを実行

4.4 Javaプラグインの詳細

Gradleの規約に適合していれば、そこまで深くJavaのプラグインを知らなくてもよいが、適合していない場合、独自のタスクを組み込んだりカスタマイズしていかなくてはならない

4.4.1 Javaプラグインのタスクの依存関係

タスクはそれぞれ依存関係を持っている
- http://gradle.monochromeroad.com/docs/userguide/java_plugin.html
dependsで指定されている

4.4.2 つくの詳細

Javaプラグインが提供するタスクのうち、重要なものについて説明

テストに関連するタスクは第８章、アーティファクトの公開に関連するタスクは第１２章で詳しく説明しているのでここでは割愛

compileJavaタスク/compileTestJavaタスク
- JavaCompile型のタスク
- javacコマンドによりJavaソースをコンパイルし、クラスファイルを生成します。
- 対象
  - compileJavaタスク
    - ソースセットmainのjava.srcDirsプロパティで指定したディレクトリに含まれるJavaソース
  - compileTestJavaタスク
    - ソースセットtestのjava.srcDirsプロパティで指定したディレクトリに含まれるJavaソース
- 拡張子が.javaのファイルのみがコンパイル対象となる
processResourcesタスク/processTestResourcesタスク
- Copy型のタスク
- プロダクションコードのリソース(.propertiesなど)をクラス出力先にコピーする
- 対象
  - processResourcesタスク
    - ソースセットmainのresources.srcDisプロパティで指定したディレクトリに含まれるファイル
  - processTestResourcesタスク
    - ソースセットtestのresources.srcDisプロパティで指定したディレクトリに含まれるファイル
jarタスク
- Jar型のタスク
- JARファイルを生成します
- dフォルトではアーカイブ対象はソースセットmainのoutputプロパティ、すなわちcompileJavaタスクとprocessResourcesタスクの出力です。
javadocタスク
- Javadoc型のタスク
- Javadocを生成します

4.5 規約に合わないプロジェクトへの適用法

新規で作成するプロジェクトはできるだけGradleの規約に合わせることをおすすめします。既存のプロジェクトにGradleを適用する場合や、プロジェクト特有の事情によってGradleの規約に合わせることができない場合に対応する方法を説明

4.5.1 ディレクトリ構成の変更

src/main/java以下にxmlやpropertiesなどを配置している場合

TODO: 処理の意味が理解できていないので再確認なぜこれで実現できるのか腑に落ちない

4.5.2 コンフィグレーションによる依存関係の変更

Gradleには依存関係をグループ化して分類するコンフィグレーションという仕組みがある依存ライブラリによってはコンパイル時のみ必要で実行時には不要であるものがあるこのような状況に対応するための仕組みがコンフィグレーションです

Javaプラグイン標準コンフィグレーション
- compile: ソースセットmainのコンパイル時クラスパス。compileJavaタスクが参照
- runtime: ソースセットmainの実行時クラスパス。デフォルトではコンフィグレーションcompileと同内容が設定
- testCompile: ソースセットtestのコンパイル時のクラスパス
- testRuntime: ソースセットtestの実行時クラスパス。
- archives: このプロジェクトのアーティファクトを表すコンフィグレーション
- default このプロジェクトに依存するプロジェクトが利用するデフォルトのクラスパス
MEMO: implementationとかの説明がない..

4.5.3 ソースセットの追加

Javaプラグインは標準でmainとtestの２つのソースセットを提供しているこの２つだけでは足りない場合新しく追加できるインテグレーションテスト用のソースセットがほしいと仮定して作成してみる

sourceSets {
  integrationTest
}

Javaプラグインの規約ではソースセットごとのプロパティにもデフォルト値が定義されている

Javaソースの配置先はsrc/integrationTest/javaディレクトリ
リソースの配置先はsrc/integrationTest/resourcesディレクトリ

作成すると勝手に上記のような規約に沿った形で定義されるみたい規約に合わない場合は以下の用に定義して対応する

sourceSets {
  integrationTest {
    java.srcDir file('src/intTest/java')
  }
}

TODO: 残りは、IntegrationテストとUnitテストを明確に分けたい場合参照すべし

4.6 Applicationプラグイン

ApplicationプラグインはJavaアプリケーションを実行したり、配布したりするためのプラグインで、Javaプラグインを拡張して作られている

用途
- ビルドスクリプト内でメインクラスを指定し、Gradleからアプリケーションを実行する
- アプリケーションを実行環境に配布するためのアーカイブ(ZIPファイル)を作成する

4.6.1 Applicationプラグインの利用方法

// applicationプラグインを適用する
apply plugin: 'application'
// メインクラスのFQCN名(完全修飾名)を指定する
mainClassName = 'com.example.cli.SimpleCalc'

apply plugin: 'java'
apply plugin: 'application'

def defaultEncoding = 'UTF-8'
compileJava.options.encoding = defaultEncoding

sourceCompatibility = 1.7
targetCompatibility = 1.7

mainClassName = 'com.example.cli.SimpleCalc'
applicationName = 'SimpleCalc'

repositories {
	mavenCentral()
}

dependencies {
  compile 'commons-cli:commons-cli:1.2'
}

run {
  standardInput = System.in
}

javadoc {
  options.links << 'http://docs.oracle.com/javase/jp/7/api/'
}

runブロックの内容について
- 実行するアプリケーションが標準入力を必要とする場合は必須
- ビルド実行中はGradleが標準入力を処理しているため、アプリケーションに標準入力を渡すために、このようなおまじないが必要になります。

4.6.2 ビルドスクリプトからのアプリケーション実行

Applicationプラグインを適用することで、runタスクが加わります
このタスクを実行するとGradleによって指定したアプリケーションが実行されます。

4.6.3 アプリケーション実行用アーカイブの作成

アプリケーション実行用アーカイブを作成この機能もApplication プラグインによって提供されるアーカイブにドキュメントを追加したい場合は、プロジェクトのsrc/distディレクトリに、それらを配置しておけば自動的にアーカイブに含まれる

gradle distZipを実行する

build/libsディレクトリ
- JARファイルが生成される（実際にJARファイルを生成しているのは
build/scriptsディレクトリ
- アプリケーション実行用のシェルスクリプトとバッチファイルが生成される
- distZipタスクと連動して実行した、startScriptsタスクが生成
build/distributionsディレクトリ
- build/libsディレクトリやbuild/scriptsディレクトリの出力を含んだアーカイブが作成される

後は、アーカイブを配ってバッチ叩けば実行できるというもの GUIアプリとか配ると便利そうローカルで起動する系のWEBアプリもこれで配れそう

必要な依存ライブラリを添えろ得て配布物に含める
環境変数や、JavaVMオプションなどを設定するための起動スクリプトを準備する

これらの手間がなくなるのでApplication プラグインは便利

4.7 Warプラグイン

WarプラグインはJavaベースのWebアプリケーションのビルドを行うためのプラグインで、Application プラグインと同じ句、Javaプラグインを拡張して作られています

4.7.1 Warプラグインの挙動

Warプラグインの主な機能はWARファイルを生成すること warタスクが実際にwarファイルを生成する

warタスクはJavaプラグインのjarタスクに相当しますが、次のような違いがある

ソースセットmainのコンパイル結果（クラスファイル）をWARファイルのWEB-INF/classesに配置する
コンフィグレーションruntimeに設定されている依存ライブラリ（JARファイル）をWARファイルのWEB-INF/libに配置する
webAppDirNameプロパティに設定されているディレクトリ以下をWARファイルの/に展開する
- このプロパティに指定するディレクトリは、HTMLファイルやCSSファイルといったWebリソースの置き場を指す

4.7.2 プロパティ

Warプラグインが提供するプロパティは次の２つ

webAppDirName
- HTMLファイルやJSPファイルなどのWebアプリケーションコンテンツの配置先を、プロジェクトのルートから相対パスで指定
webAppDir
- 前述のwebAppDirNameの設定に基づき、絶対パスが設定される（参照専用）

4.7.3 コンフィグレーション

Warプラグインが提供するコンフィグレーションは次の２つ

providedCompile
- ソースセットmainのコンパイル時クラスパスのうち、WARファイルへのコピー対象外としたいもの
providedRuntime
- ソースセットmainの実行時クラスパスのうち、WARファイルへのコピー対象外としたいもの

これらのコンフィグレーションは、WARファイルの実行環境が提供している依存ライブラリを指定するときに使う典型的な利用方法は、ServletAPIなどアプリケーションサーバーに含まれる依存ライブラリをビルド時のみ参照にし、WARファイルからは除外するという使い方

4.7.4 warタスクの設定

ビルドスクリプトにwarブロックを追加して、warタスクの挙動をカスタマイズできる

例えば、web.xmlを別名で用意しておき、ビルド時にweb.xmlとしてWARファイルにコピーする場合

def env = 'dev'
war {
  webXml = file("src/web-${env}.xml")
}

Eclipse WTPプラグイン
- Warプラグインを適用したプロジェクトをEclipseで開く場合、Eclipseプラグインを適用して、gradle eclipseでEclipseプロジェクトを作っただけではEclipseのWTPプロジェクトとして認識されない
- この場合、Eclipseプラグインを使うのではなく、EclipseWTPプラグインを利用してください

第5章 Gradle の基礎

本章では、Gradleのアーキテクチャや主要な機能など、理解しておくべきGradleの基礎について解説

5.1 Gradleにおけるビルド

Gradleでのビルドが何なのかについては明らかにしていませんでした Gradleのビルドが何を指し、どのように実行されるのかを説明する

5.1.1 ビルドとはなにか

wiki
- ソフトウェアのビルドは、ソースコードファイルを独立したソフトウェア成果物に変換するコンピュータ上で実行されるプロセス、またはその結果を指す。

なにかしらのアクションを実行すること、それがビルドツールにおけるビルドであると言える

Gradleでは実行する処理の単位をタスクと呼び、このタスクを実行することがGradleにとってのビルドであり、ビルドを実行するための仕組みがGradleの根幹

5.1.2 ビルドの入力情報

ビルド実行時に、Gradleが参照するファイルやディレクトリ、パラメータにどのようなものがあり、それらがどのような役割を果たしているかを理解しておきましょう

初期化スクリプト
- ビルドの最初で実行されるGroovyスクリプト
- デフォルトのファイル名はinit.gradleになる
- 主にユーザー情報や実行環境などの初期設定を行うために使う
- 初期スクリプトはいくつか指定方法があり、複数のスクリプトファイルを使い分けることができる
設定スクリプト
- ビルド対象のプロジェクトの設定を行うGroovyスクリプト
- デフォルトのファイル名はsettings.gradleとなります
- 主にビルドに参加するプロジェクトを定義する用途で使用
- マルチプロジェクトでは必須のスクリプトファイル
ビルドスクリプト
- ビルドの入力情報の中で一番大切な「ビルドの定義」を記述するGroovyスクリプト
- デフォルトのファイル名はbuild.gradleになります
- 当該プロジェクトの依存関係やタスク定義などをするのが主な用途で、通常のビルドであればこのファイルだけで事足ります。
プロパティファイル
- Gradleが標準で参照するプロパティファイルで、ファイル名はgradle.propertiesとなる
環境変数/コマンドライン引数
buildSrcプロジェクト

これらのうち、以下の３つのスクリプトファイルは特に重要記述した内容がビルド実行時にGradle固有のドメインオブジェクトに移譲される

スクリプトファイル	Gradleドメインオブジェクト
初期化スクリプト	Gradleオブジェクト
設定スクリプト	Settingsオブジェクト
ビルドスクリプト	Projectオブジェクト

5.1.3 ビルドの流れ

コマンドラインからgreetタスクを実行するときの処理の流れについて見ていく

task greet doLast { println 'hello,' + user }

gradle -Puser=kotetsu greet

Gradleビルドの流れ
- コマンドの解析：
- スクリプトファイルの初期化：初期化フェーズ
- プロジェクトの設定：設定フェーズ
- タスクの実行：実行フェーズ

5.2 アーキテクチャと主要な機能

5.2.1 物理構造

Gradleは40近くのJARファイルで構成されるが、大きく分類するとGradle本体、プラグインの２つに分けられる

スクリプトファイルの中で適用されない限りは、基本的にGradleにプラグインはロードされないプラグインを取り除いてスリムにしたGradleを使用することもできる

このプラグイン機構はGradleの特徴の１つと言える

5.2.2 実行基盤を支える仕組みと標準機能

ビルドで実行する処理の主体はプラグイン側にある Gradle本体が提供するのは、ビルドの実行基盤を支えるための仕組みと標準的な機能になる

実行基盤を支える仕組み
- 設定の自動ロード
- プロジェクトの探索
- タスクグラフ
Gradleの標準機能
- ファイル操作：コンパイル後のファイルの出力先ディレクトリを作成したり、ビルド中の中間ファイルを削除したりとファイルシステムの操作をよく行う
- ロギング：ビルドの実行中の状態を知るには、処理状態や処理中に起きた問題について出力する機能が必要
  - Gradleではロギングフレームワークを内包した独自のロギング機能により、ログの出力を制御できる

5.3 設定の自動ロード

5.3.1 初期化スクリプトによる設定

初期化スクリプトはビルドライフサイクルの初期化フェーズの先頭でロードされるため、ビルド実行時に環境設定を行うのに適している

例えばMavenCentralリポジトリを参照する設定を初期化スクリプトに定義して、実行ユーザーのホームディレクトリの.gradleに配置しておくと、同ユーザーが実行するすべてのGradleのビルドでMaven Centralリポジトリを参照できるようになります。

初期化スクリプトの規約
- コマンドライン引数 -I (--init-script)で指定する
- <HOME>/.gradleディレクトリに配置：init.gradleが対象
- <HOME>/.gradle/init.dディレクトリに配置：.gradleが対象
- <GRADLE_HOME>/.gradle/init.dディレクトリに配置：gradleが対象

5.3.2 プロパティファイルによる設定

Gradleが自動的にロードするプロパティファイルは、環境に関する設定を記述する場合に適している gradle.propertiesファイルに記述しておくと、初期化フェーズでロードされ、記述したプロパティが適用される

プロパティファイル
- <PROJECT_HOME>ディレクトリに配置する：gradle.propertiesが対象
- <HOME>/.gradleディレクトリに配置する：gradle.propertiesが対象
- コマンドライン引数-D(--system-prop)で指定する：規約なし

5.4 プロジェクトの探索

5.4.1 プロジェクト構成と探索の関係

Gradleはビルドを実行する際にプロジェクトと言う概念で対象領域を特定する通常、gradleコマンドを実行するカレントディレクトリがビルド対象のプロジェクト（カレントのプロジェクト）となる

Gradleはシングルプロジェクトとマルチプロジェクトをサポートしていることもあり、ビルドを実行する前に、カレントのプロジェクトがシングルプロジェクトなのかマルチプロジェクトなのか探索する必要があるこのプロジェクトの判定は設定スクリプト（settings.gradle）を利用して行うこの設定スクリプトはプロジェクトを特定する上で重要な役割を担っている

設定スクリプトの決まり
- 設定スクリプトはルートプロジェクトの直下に配置しなければならない
- マルチプロジェクトの場合には、必ず設定スクリプトを容易しなければならない

5.4.2 設定スクリプトに基づいた構成の特定

プロジェクトを探索するためには設定スクリプトの有無が最初のポイント

読み込み方法
- コマンドライン引数の-c(--settings-file)オプションで、ファイルを指定する
  - 引数で指定された場所にあれば読み込む
- Gradleの規約に従った場所に配置する
  - 1.カレントディレクトリにsettings.gradleがあれば読み込む
  - 2.カレントディレクトリの親ディレクトリにsettings.gradleがあれば、それを設定スクリプトとみなす
  - 3.カレントディレクトリと同じ階層にmasterディレクトリがあり、その配下にsettings.gradleがあればそれを設定スクリプトとみなす
    - ※ただし、コマンドライン引数に-u(--no-search-upward)オプションが含まれていた場合、2,3は行われない
    - カレントディレクトリに設定ファイルが存在しなければシングルプロジェクトとして扱う

5.5 タスクグラフ

5.5.1 タスクグラフの概要

Gradleのタスクグラフは、グラフ理論の無閉路有効グラフの考えに基づいて設計されている

5.5.2 タスクグラフの制約

タスクグラフは基本的に指定されたタスクとそのタスクの依存関係によって構築されますが、依存関係以外にも次の制約によりタスクグラフが制御される場合がある

同一のタスクが実行対象タスクとして指定された場合
タスクが順序付けられている場合
ファイナライザータスクが設定されている場合
同一のタスクが実行対象タスクとして指定された場合
- Gradleでは、１つのタスクは１回しか実行されないことが保証されている
- 同じタスクを複数指定していたり、複数のタスクから依存されているタスクがあったりしても、タスクグラフには１つしか存在しないように制御される
- 例えば、greetタスクを２回実行する用にしても１回しか実行されない
- gradle greet greet
タスクが順序付けられている場合
- 明示的に実行対象として指定された場合のみ有効になる
- タスクの順序付けについては次章で説明
ファイナライザータスクが設定されている場合
- 順序付けのほかに、ファイナライザータスクという指定されたタスクの後に自動で必ず実行される特殊なタスクを定義できる
- ファイナライザータスクを設定しているタスクを実行した場合には、タスクグラフの構築の際にファイナライザータスクも自動的に追加されることになります。

5.6 ファイル操作

5.6.1 Gradle標準のファイル操作機能

Gradleのファイルシステムの操作として次の機能を提供
- ファイルの参照
- ファイルのコピー
- ファイルの削除
- ディレクトリの作成

このうち、ファイルの参照とコピーに関しては提供されているAPIも多く、使い勝手がいい

5.6.2 単一ファイルの参照

file()を使用する通常はルートプロジェクトのディレクトリを起点とした相対パスか、Fileオブジェクトを指定する

File javaFile = file('src/main/java/Main.java')

ファイルパス以外からのファイル参照
- file()はファイルパス以外にも、URL/URIオブジェクト、Callableインターフェースやクロージャなどを引数として、ファイルへの参照を取得できる

File index = null

URL url = new URL('file:/index.html')
index = file(url)

URI uri = new URI('file:/index.html')
index = file(uri)

import java.util.concurrent.Callable

index = file(new Callable<String>() {
  String call() {
    '/index.html'
  }
})

index = file { '/index.html' }

PathValidationによるファイルの検証

File existDir = file('src/main/existDir', PathValidation.DIRECTORY)

PathValidationには、DIRECTORY,FILE,EXISTS,NONEが定義されている指定しない場合はNONEが設定されている

5.6.3 ファイルコレクションによるファイルの参照

複数のファイルを扱う場合には、files()を使用するビルドスクリプトからfiles()を呼ぶことで、Fileの集合であるファイルコレクションを取得できる

ファイルコレクションはConfigurableFileCollectionインターフェースを実装していますが、操作するためのAPIは親のFileCollectionインターフェースで定義されていることから、このFileCollection インターフェースを中心に説明

FileCollection
- Gradleには、ビルドスクリプト上の記述を簡潔にするためのインターフェースがいくつか用意されている
- FileCollection はそのインターフェースの一つで、これによりファイルのコレクション操作を簡潔に行える
- 使用頻度の高いと思われるものを中心に紹介
ファイルコレクションの取得
- files()の引数はfile()が許容する型のオブジェクトを複数渡すようなかたちになります。
- 引数に渡すパラメータには、ファイルパスのおじ列、File、URL、URIなどを組み合わせることもできる

FileCollection collection = files('file1.txt', 'file2.txt')

collection = files('file1.txt', new File('file2.txt'), new URL('file:/index.html'))

List fileList = [new File('file1.txt'), new File('file2.txt')]

collections = files(fileList)
collections = files(fileList as File[])

ファイルコレクションの変換

FileCollection collections = files('file1.txt', 'file2.txt', 'file3.txt')

// as 演算子による変換
List list = collections as List
Set set1  = collections as Set
File[] array = collections as File[]

// getFiles() のGroovy簡略記法
Set set2 = collections.files

// ファイルコレクションに含まれるファイルが１つの場合は、getSingleFile()が使える

File file = collections.singleFile

遅延評価によるファイルコレクションの取得
- Callableの場合遅延評価されます→実際に参照されたときに実行されるということ
ファイルコレクションの演算
- ファイルコレクションの操作に加算と原産が利用できるらしい
ファイルコレクションのフィルタリング
- ファイルコレクションに条件を指定することで、条件に一致したファイルだけにフィルタリングをすることができる
- フィルタリングはfilter()にクロージャを渡します

FileCollection collections = files('file1.txt','file2.txt',new URL('file:/index.html'))
FileCollection textFiles = collections.filter{ collectionFile -> 
  collectionFile.name.endsWith .txt
}

assert textFiles.files.size() == 2

その他の機能
- getAsPath() : ファイルコレクションに含まれているファイルのパスを取得できる
  - このメソッドはファイルごとのパス環境に応じたパス区切り文字で連携つして出力するため、javaコマンドにクラスパス形式でJARファイルのパスを渡すような場合に便利

5.6.4 ファイルツリーによるファイルの参照

複数のファイルを木構造のファイルツリーとして扱う場合にはfileTree()を使用

FileTree sourceTree = fileTree('src')

FileTreeとは
- FileTreeインターフェースもファイルコレクションを簡潔に操作するためのインターフェースの１つ
- FileTreeインターフェースはFileCollectionインターフェースを継承しており、階層的にファイルを巡って処理するような機能が拡張されている
ファイルのマッチング
クロージャによるファイルツリーの取得
マップによるファイルツリーの取得
条件に一致するファイルツリーの取得
ファイルツリーの探索

TODO: あとで纏めるすぐ使える用にスニペットにする？

5.6.5 ファイルのコピー

ファイルをコピーするには、デフォルトで提供しているCopy型タスクから、独自のタスクを作成する方法と、ビルドスクリプト上でcopy()を使う方法の２通りある

ここでは後者のcopy()を使用したファイルのコピーについて述べる copy()はクロージャを引数としていますが、実際のコピーに関する記述はクロージャ内でCopySpecというインターフェースを使用して行います

copy {
  // CopySpec インターフェースのメソッドを使用する
}

CopySpecとは
- ファイルのコピーに特化したGradleが提供するインターフェースの１つ
- Copyタスクを始めとする、ファイル操作を行うタスクの内部ではCopySpecインターフェースを使用しており、ファイルのコピーを伴うタスクではこのインターフェースを通じて処理が行われる

TODO: 使用する際に詳細見直すテンプレートはクラス自動生成時に有用だと思った

5.6.6 ファイルの削除

ファイルの削除jは、デフォルトで提供しているDelete型のタスクを使って独自のタスクを作成する方法と、ビルドファイル上でdelete()を使う方法の２通りがある

delete 'target.txt'

// 可変長なので複数指定できる
delete 'target1.txt','target2.txt','target3.txt'

5.6.7 ディレクトリの作成

ディレクトリを作成するにはビルドスクリプト上でmkdir()を使用する

mkdir 'parent/child/grandchild'
mkdir '../outOfTheProject'
mkdir '/gradle-book/absolutePathDir'

Gradleでのファイルの作成方法
- Gradleにはファイル作成のメソッドはありません。
- Groovyによって拡張されたFileクラスで作成する

File newFile = file('newFile.txt')
newFile.write('ビルドスクリプトからファイルの生成を行います','UTF-8')

5.7 ロギング

5.7.1 Gradleでのロギング

GradleはSLF4Jを拡張したロガーを包含しています。通常、Gradleを実行した際に出力されるログはこれによるもの

TODO: Gradle用に、QUIETとLIFECYCLEというログレベルが追加されているらしい。時間があるときに抑える

5.7.2 loggerプロパティを使用したロギング

ビルドスクリプトでログ出力を定義する場合には、loggerプロパティを使用

logger.error = ''
logger.quiet = ''
logger.warn = ''
logger.lifecycle = ''
logger.info = ''
logger.debug = ''

標準出力とloggerプロパティの使い分け
- 標準出力は一時的に局所のログを出力したい場合にとどめ、
- 恒久的にログを出力する場合はloggerプロパティを利用することをおすすめ

5.7.3 外部ロギングフレームワークとのマッピング

TODO: 他のロギングAPIとの対比表を掲載。時間があればみる

5.7.4 ログレベルマッピングの変更

標準エラーは通常GradleではERRORレベルにマッピングされていますが、運用上の都合からERRORではなくINFOレベルに引き下げて出力させたいといった場合に対応する方法

logging.captureStandardError LogLevel.INFO
println '標準出力'
System.err.println '標準エラー'

MEMO: あまり使わないかも

第6章スクリプトファイルの記述

Gradleのスクリプトファイルに記述された内容は実行時にGradleドメインオブジェクトに移譲される記述したものが内部でどのクラスに異常されてどのように振る舞うのかを知っていると、スクリプトファイルもより理解しやすくなります。また、実際のプロジェクトでの多用な要求に対応するためには、タスクの詳細やマルチプロジェクトでのビルドスクリプト記述方法などについても知って置かなければなりません

6.1 スクリプトファイルの構造と共通要素

6.1.1 スクリプトファイルの構造

Gradleのスクリプトファイル
- ステートメント
- スクリプトブロック
ステートメント
- ローカル変数やプロパティの設定、メソッドの実行など、
- 一般的なプログラミングでのステートメントと同じ意味合いのもの
スクリプトブロック
- Gradle独自の概念で、ある設定をおこなナウための領域を示すもの
- 実際にはたんにクロージャを引数とするメソッドであり、そんなに難しいものではない

// ステートメント
xxx = ''

// スクリプトブロック
設定 {
  // 設定のための領域
}

Groovyスクリプトがベースで有ることには変わりませんので、通常のGroovyスクリプトと同様にクラスやクロージャを定義することもできる

class Descriptor {
  String show() {
    '*** これはGroovyスクリプトです。 ***'
  }
}
println new Descriptor().show()

6.1.2 スクリプトファイルの共通要素

変数は欠かせない共通要素 Gradleにはプロパティが手軽に使える仕組みが用意されているので、さまざまな場面で重宝するでしょう

4つの変数

名称	概要	使用可能なスクリプトファイル
ローカル変数	宣言されたスコープで有効な変数	すべてのスクリプトファイル
システムプロパティ	システムの情報を保持するためのプロパティ	すべてのスクリプトファイル
拡張プロパティ	ドメインオブジェクトを拡張するためのプロパティ	すべてのスクリプトファイル
プロジェクトプロパティ	プロジェクトで使用するためのプロパティ	ビルドスクリプト

ローカル変数

def message = 'ローカル変数'
String stringMessage = 'ローカル変数'
// def でも 型指定でもいいよ

型宣言の無いものはGradleでは変数ではなく、移譲されるドメインオブジェクトのプロパティとみなす変数として宣言するのではなく、オブジェクトにプロパティとして追加したい場合は、後述する拡張プロパティを使用する必要がある →ここイマイチ腑に落ちない

システムプロパティ
- システムプロパティをコマンドライン引数で指定する場合は-D(--system-prop)を使用する
- これだけならJavaと同じ
- Gradleには他の指定方法もある
- Gradleのプロパティファイル（gradle.properties）にsystemPropをプレフィックスとしてつけてプロパティを記述すると、システムプロパティとして識別される

# gradle.properties
systemProp.message=Hello

拡張プロパティ
- Gradleには、スクリプトファイル上からドメインオブジェクトのプロパティを追加する仕組みとして、
- 拡張プロパティというものがある
- 拡張プロパティはextという名前で暗黙的に定義されており、使用にあたって特別な制約はない
- 詳細は後述のGradleドメインオブジェクトExtraPropertiesExtensionで説明
- 基本的に通常のキーバリュー方式でプロパティの追加と取得ができる

ext {
  key1 = 'value1'
  key2 = 'value2'
}

プロジェクトプロパティ
- もう1つGradle固有のプロパティとして、プロジェクトプロパティというものがあります。
- プロジェクトプロパティはビルドスクリプトで使用可能
- ビルド対象のプロジェクトのプロパティとして利用
- 拡張プロパティの仕組みを使用しているので、内部的には拡張プロパティとの違いはありません
- 拡張プロパティと違うところは設定方法で、
  - プロジェクトプロパティはプロパティファイル、環境変数、コマンドライン引数のどれでも設定できる
- プロパティファイルの場合は、<プロパティ名>=<値>と定義するだけで追加される
- 環境変数の場合は、ORG_GRADLE_PROJECT_<プロパティ名>=<値>という形式で設定できる
- コマンドライン引数の場合は、-P<プロパティ名>=<値>または、--project-prop <プロパティ名>=<値>で設定
- システムプロパティの場合は、org.gradle.project.をプレフィクスでつけることで設定できる

TODO: プロジェクトプロパティのロード順を記載してくれている

6.1.3 スクリプトブロックとドメインオブジェクト

スクリプトブロックはクロージャを引数とするメソッド

println 'デフォルトの依存関係：'
repositories.each { println it.name }

repositories {
  mavenCentral()
}

println 'リポジトリ追加後：'
repositories.each { println it.name }

// このリポジトリブロックをGroovyのプログラム風に記述すると
def closure = { mavenCentral() }
this.reporitories(closure)

スクリプトファイルはGradleのドメインオブジェクトに移譲されています thisはまさにその移譲されたドメインオブジェクトを表しており、この例で言えば、thisはドメインオブジェクトであるProjectオブジェクトになる

6.1.4 主要なスクリプトブロック

スクリプトファイルに記述するスクリプトブロックがドメインオブジェクトと関係していることがわかったと思いますので、主要なスクリプトブロックと移譲されるドメインオブジェクトを列挙しておきます

スクリプトブロック	概要	ドメインオブジェクト
initscript	初期化スクリプトのクラスパスの設定を記述する	ScriptHandler
buildscript	ビルドスクリプトのクラスパスの設定を記述する	ScriptHandler
allprojects	当該プロジェクトとそのすべてのサブプロジェクトに関する設定を記述する	Project
subprojects	当該プロジェクトのサブプロジェクトに対する設定を記述する	Project
configurations	コンフィグレーションの設定を記述する	ConfigurationContainer
dependencies	依存関係の解決のための設定を記述する	DependencyHandler
repositories	リポジトリの設定を記述する	RepositoryHandler
artifacts	ビルド成果物（アーティファクト）を公開するための設定を記述	ArtifactHandler

6.2 Gradleドメインオブジェクト

重要なドメインオブジェクトについて
- Project
- Task
- Gradle
- Settings
- ExtensionAware
- ExtraPropertiesExtension

6.2.1 Projectオブジェクト

ProjectオブジェクトはGradleでの処理対象となる１つの領域を表すドメインオブジェクトビルドスクリプトからProjectオブジェクトに移譲される

Projectオブジェクトはビルドスクリプト上のすべてのドメインを統括する、Gradleのなかで最も重要なドメインオブジェクト

Projectオブジェクトの構造
- Gradleでなにかを自動化するときには、プロジェクトが必ず１つは存在する
- マルチプロジェクトを扱うためにはコンポジットな構造である必要があるため、自分自身の親プロジェクト、起点となるルートプロジェクト、自分の下にぶら下がっているプロジェクトのリストを保持する用になっている
プロパティ
- Projectオブジェクトはビルドに必要なすべての情報にアクセスできなければなりません。
- そのためプロパティも多数存在する

プロパティ	概要
name	プロジェクト名。論理名のため物理的なディレクトリと異なる場合もある
description	プロジェクトの説明
group
path
projectrDir
status
state
version

プロジェクト参照属性
- 自分に該当するプロジェクトや、自身が属しているルートプロジェクトなど、プロジェクトを参照するためのプロパティ

プロパティ	概要
project	当該プロジェクトの参照を保持する
rootProject	ルートプロジェクト参照を保持する。
parent	上位プロジェクトの参照
childProjects	子プロジェクトの参照をMapコレクションで保持
allprojects	当該プロジェクトに含まれるすべてのプロジェクトの参照をSetコレクションで保持
subprojects	当該プロジェクト配下のすべての参照をSetコレクションで保持

rootProjectはシングルプロジェクトの場合は自分自身、マルチプロジェクトの場合は、settings.gradleが置かれたディレクトリのプロジェクトとなる

コンテナタイプ属性
- コンテナタイプのプロパティには、repositoriesやtasksなどビルドスクリプトで定義されたドメインを管理するためのものがある
- これらの多くはスクリプトブロックが用意されており、スクリプトブロックによって設定を記述する
defaultTasksプロパティ

defaultTasks 'showProjectName'
project.description = 'デフォルトタスクの説明のためのプロジェクトです。'
task showProjectName doLast {
  println project.name
}

task showDescription doLast {
  println project.description
}

// 実行タスクが指定された場合は、デフォルトタスクは実行されない
// 複数のタスクを指定する場合は、
defaultTasks = ['showProjectName','showProjectDescription']

主要なAPI
- ビルドスクリプトを記述する際には、ProjectオブジェクトのAPIは欠かせません
- プロパティと同様にAPIも用意されているので使用頻度の高いAPIに絞って紹介
プロジェクト参照API

def childInstance = project(':child')
childInstance.description = '子プロジェクトの説明を設定'

// パスとクロージャを引数とするオーバーロードメソッドを使用した場合
project(':child') {
  description = '子プロジェクトの説明を設定'
}

タスク定義API
- タスクを定義する際のAPIはtask()です
- task()はオーバーロードメソッドになっていますが、よく利用されるのはタスク名を引数とするもので、これは本書ですでに何度も登場しています

task hello doLast {
  println 'hello gradle world!'
}

コールバックAPI
- Gradleがビルド処理を実行している最中にビルドフェーズ内からコールバックされるAPIとして、beforeEvaluate()とafterEvaluate()の２つがある
- beforeEvaluate()はプロジェクトの評価前ににコールバックされるため、ビルドスクリプトに記述した処理は参できない
  - →よって、プロジェクトの評価前に独自の処理を割り込ませるには、初期化スクリプトもしくは設定スクリプトに記述しておく必要がある
TODO: イマイチ使いみちがわからなかった
その他のAPI
- javaexec(): Javaのメインクラスを実行する
- exec(): 外部のOSコマンドを実行する
- tarTree(): 指定されたTARファイルを基にしてFileTreeを生成する
- zipTree(): 指定されたZIPファイルを基にしてFileTreeを生成する
この他にも５章で紹介したファイル操作やロギングAPIもあるし他にもある

6.2.2 Taskオブジェクト

TaskオブジェクトはGradleでの対象作業を表すドメインオブジェクトで、ビルドスクリプトで記述されたタスクの定義がProjectオブジェクトを通じてTaskオブジェクトに移譲される
つまり、ビルドスクリプトでのタスクに関する記述は、Taskオブジェクトのプロパティへの設定やAPIの呼び出しになるということになります。
プロパティ

プロパティ	概要
name	タスク名。定義名がそのまま設定される
description	タスクの説明。tasksタスクで説明が表示される
group	タスクが属するグループ。tasksタスクの出力時のタスクのグルーピングに使用される
path	タスクのパス。プロジェクトも含めた場合は「：」がセパレータとなる

nameとpathはタスク定義の際に自動的に決まるが、descriptionとgroupは名自適に設定する必要がある

その他のプロパティ

プロパティ	概要
enabled	タスクの実行可否情報を保持する
state	タスクの実行ステータスを保持する
inputs	このタスクの入力情報を保持する
outputs	このタスクの出力情報を保持する
dependsOn	このタスクが依存するタスクを保持する
mustRunAfter	必ず先に実行されなければならないタスクを保持する
shouldRunAfter	先に実行されなければならないタスクを保持する
finalizedBy	このタスクの後に実行されるファイナライザータスクを保持する

これらのプロパティを使用することで、タスクの実行順を制御したり、状態によって実行をスキップさせたりできる

他に、直接プロパティを操作することはないが、acrionsという重要なプロパティがあるので触れておく acrionsプロパティは、Gradle内部での最小処理単位であるActionオブジェクトのリストになっており、タスクの定義で記述された作業をActionオブジェクトとして保持しているこのactionsプロパティ内のActionオブジェクトを順次実行することでタスクの処理は行われている

主要なAPI

TaskオブジェクトのAPIは
- タスクの処理のためのもの
- タスクの実行に関するもの
- プロパティのアクセサー
  - の３種類で占めている

API	概要
doFirst()	タスク処理をActionオブジェクトとしてactionsの先頭に追加
doLast()	タスク処理をActionオブジェクトとしてactionsの最後に追加
leftShift()	タスク処理をActionオブジェクトとしてactionsの最後に追加
deleteAllActions()	actions内のActionオブジェクトを削除

task myActionTask {
  doFirst {
    println 'First'
  }
}
// これらはGradleのDSL記法で
// Groovyで書くと以下になる

List<Action> actions = new ArrayList<Action>()

Closure doFirstAction = { println 'First' }
actions.add(0,doFirstAction)

Closure doLastAction = { println 'Last' }
actions.add(doLastAction)

actions.each{ action ->
  actions.execute()
}

6.2.3 Gradleオブジェクト

実行環境であるGradleを表すドメインオブジェクトで、初期化スクリプトから移譲される他にも後述するProjectオブジェクトやSettingsオブジェクトがプロパティとして保持しており、すべてのスクリプトファイルからアクセスできる

println gradle.gradleVersion

プロパティ

プロパティ	概要
gradleHomeDir	Gradleホームディレクトリを保持する
gradleUserHomeDir	ホームディレクトリを保持する
gradleVersion	実行するGradleのバージョンを保持する
rootProject	ルートプロジェクトを保持する
startParameter	ビルド実行時のパラメータを保持する
taskGraph	当該ビルドのタスクグラフを保持する

主要なAPI
- イベントリスナーについて紹介
- TODO: 処理順などまとめる

6.2.4 Settingsオブジェクト

Settingsオブジェクトは設定スクリプトを表すドメインオブジェクトで、設定スクリプトから移譲される設定スクリプトはマルチプロジェクトのためだけのものではない

プロパティ
- Settingsオブジェクトは設定フェーズで生成されて使用されますが、
- その段階で扱える情報は自分自身の情報を除くと、Gradleオブジェクトとルートプロジェクトの情報ぐらい

TODO: マルチプロジェクト作成時に再度確認しておく

6.2.5 ExtensionAwareオブジェクト

ビルド実行時にGradleドメインオブジェクトを他のオブジェクトで拡張可能にするためのドメインオブジェクト

ExtensionAwareオブジェクトには、extensionsという拡張プロパティを格納するためのコンテナがあり、 Projectオブジェクト、TaskオブジェクトなどのGradleドメインオブジェクトの多くは、これに独自のプロパティ追加できる

TODO: メリットがいまいちつかめなかった

6.2.6 ExtraPropertiesExtensionオブジェクト

ProjectオブジェクトやTaskオブジェクトなどで、extの名前で定義されている拡張プロパティの実態クラス ExtraPropertiesExtensionオブジェクトをはpropertiesというプロパティを持ち、そこにキーとバリューで任意のオブジェクトを保持そして、has(),set(),get()の３つのAPIを提供し、propertiesに指定のキーが存在するかの確認、キーと値の設定や取得ができる

project.ext.property = 'extに追加下プロパティです。'
println '拡張プロパティの値 :' + project.property

project.ext['property'] = 'extに追加したプロパティです。'
println '拡張プロパティの値:' + project.ext['property']

project.ext {
  prop1 = 'aaa'
  prop2 = 'bbb'
}
println project.ext.prop1 + project.ext.prop2

6.3 タスクの記述

6.3.1 タスクの定義方法

ビルドフェーズ
- 初期化フェーズ
- 設定フェーズ
- 実行フェーズ

task hello doLast {
  println name + ': Hello Gradle World!'
}

// 設定のためのブロックとなるため設定フェーズで実行される
task hello2 {
  println name + ': Hello Gradle World!'
}

// descriptionプロパティを出力する例

showDescription doLast {
  println description
}
task showDescription.description = 'showDescriptionタスクです。'
// 順序に違和感があるかもしれないがこの順番で記述しないと行けない

Task型を使用した定義
- Gradleにはあらかじめ特定のアクションを行うための汎用のタスクが数多く用意されている
- それらは独自のタスクを定義する際に利用できる
- 汎用タスクはGradle本体が提供する標準のものと、
- プラグインを適用することで追加されるおのがある

タスク型	概要
Copy	ターゲットとするディレクトリにファイルをコピーする
Delete	指定されたファイルまたはディレクトリを削除する
Exec
JavaExec
Sync
Tar
Zip

// これはmyCopyというタスクをCopy型で定義するという記述
task myCopy(type: Copy) {
  from 'original'
  to 'target'
}

task myCopyExtension(type: Copy){
  from 'original'
  to 'target'

  File newFile = file('original/newFile.txt')
  doFirst {
    println 'コピー元のファイルに書き込みします'
    newFile.write('コピー用のファイルです。','UTF-8')
  }
  doLast {
    File copied = file('original/newFile_copied.txt')
    if (newFile.renameTo(copied)) {
      println 'コピーが完了しました。'
    } else {
      println 'コピーできませんでした。'
    }
  }
}

動的なタスクの定義
- 複数のサーバーインスタンスをしよいうしている場合に、サーバーごとにIPアドレスを出力するタスクを作成したい場合

def instances = ['AppServer':'192.0.2.10','DBServer':'192.0.2.20','MailServer':'192.0.2.30']

instances.each { serverType, ipAddress ->
  task "show${serverType}" doLast {
    println ipAddress
  }
}

// 便利な記載方法だが、Groovyの書き方なれてないと理解出来なさそう

6.3.2 依存関係の定義方法

dependsOnというプロパティを使って定義ができる


doing.dependsOn todo
done.dependsOn doing

done.dependsOn doing, reviewing

done.dependsOn {
  tasks.findAll { task -> task.name ==~ /.*ing/}
}

6.3.3 タスクルールの定義方法

異なる設定やパラメータに対して同じような処理を指せる場合には、似た名前のタスクを必要な数だけ作成する必要があるそのような場合はタスクにルールをもたせることで簡潔に記述できる

javaのCleanの例

gradle cleanTest gradle cleanJar などと指定すると、それぞれのディレクトリのみ削除できる

これは、clean<タスク名>というルールを定義することで実現している

tasks.addRule('Pattern: show<TASKS_NAME>: Show task name.') { taskName ->
  if (taskName.startsWith('show')) {
    task(taskName) doLast {
      println '*** ' + taskName + ' ***'
    }
  }
}

定型的な処理はこのようなルールを作成して定義しておくとよい！！ MEMO: これは便利だと思う

6.3.4 タスクの制御

タスクの制御方法
- 処理内容の制御：組み込みタスクの処理内容は、タスクを再定義して処理を上書くことで既存の処理内容を変更できる
- 実行可否の制御：タスクの事項条件を判定し、タスクの実行可否を制御できる
- 実行順の制御：依存関係以外にも順序付けやファイナライザータスクの指定などで、タスクの実行順を制御できる

6.3.5 タスクの上書き

タスクを上書きする場合、同じタスク名でoverwriteプロパティを有効にして処理を定義するだけ

apply plugin: 'java'

task assemble(overwrite: true) doLast {
  println '上書きしました。'
}

6.3.6 タスクの条件実行

条件によって実行するかしないか制御したい場合

onlyIf()を使用する

task specialTask doLast {
  println '特別な処理を実行'
}

specialTask.onlyIf {
  buildType == 'partial-build'
}

gradle -PbuildType=partial-build specialTask

6.3.7 タスクの順序付け

mustRunAfterとshouldRunAfterの使い方 MEMO: あまり意識することなさそうなので割愛

6.3.8 ファイナライザータスク

// 例外が起きても実行される
normalTask.finalizedBy finalizerTask

6.4 プラグインの記述

6.4.1 Gradleにおけるプラグイン

apply()を呼ぶことでプラグインが提供するタスクやプロパティが当該のビルド処理で利用できるようになる

6.4.2 プラグインの適用方法

apply plugin: 'java'

project.apply(plugin:'java')

このように記述すると「このビルドスクリプトのProjectオブジェクトにJavaプラグインを適用させている」ということがわかる 'java'はプラグインIDと呼ばれるもの万が一プラグインIDがなければ、Pluginインターフェースを実装下クラスを指定することで、そのプラグインを適用できる

apply plugin: org.gradle.api.plugins.JavaPlugin

プラグインにはGradle標準以外にも、GithubやMaven Centralリポジトリなどで公開されているものがあります Gradleからみて外部にあるプラグインを利用するには、そのプラグインをダウンロードして読み込む必要があり、プラグインの適用方法も異なります

外部のプラグインを適用する場合は、buildscriptスクリプトブロックにプラグインのある場所とプラグインへの依存関係を設定し、通常のapply()でプラグインを適用

buildscript {
  repositories {
    mavenCentral()
  }
  dependencies {
    classpath 'org.hidetake: gradle-ssh-plugin:0.1.10'
  }
}

apply plugin: 'ssh'

Gradle2.1 のプラグイン適用方法
- 今後はこれが主流になるので覚えておきましょう

// Javaプラグイン
plugins {
  id 'java'
}

plugins {
  id 'org.gradle.java'
}

plugins {
  id 'com.example.exampleplugin' version: '1.0'
}

6.5 マルチプロジェクトでのスクリプトファイルの記述

6.5.1 レイアウトと記述方法のバリエーション

TODO: 直近使わないので一旦飛ばす

第7章依存関係の管理

7.1 依存関係管理の目的

Gradleを始めとする多くのビルドツールや統合開発環境において、依存関係とは、「そのビルドの外で作成された成果物への参照」のことを指す

依存関係解決の自動化
- 設定を書いておくと、任意の場所から必要なファイルをダウンロードまたはコピーしてきてプロジェクトに取り込んでくれる
推移的な依存関係の管理
- 必要な外部ファイルが、さらに別の外部ファイルを必要としていないか把握したり、管理したりできる
依存関係の可視化
- プロジェクトがどの外部ファイルのどのバージョンに依存しているか、かんたんに表示できる

これら３つの目的を達成するのが本章のテーマ

7.2 依存関係解決の自動化

これら順を追って、ビルドスクリプトの依存関係の設定で使っている
- configrations
- dependencies
  - といった設定項目について紹介

7.2.1 コンフィグレーション

多くのビルドツールでは依存関係をグループに分けて設定しており、Gradleもグループの概念がある

Mavenにはスコープという概念があり、すべての依存関係はcmpileスコープ、runtimeスコープといったグループに属すように定義することになっている GradleにはMavenのようにあらかじめ定義されているグループはないので、まずどのようなグループが必要化をビルドスクリプトで定義しなければいけない

この依存関係を分類するグループをGradleではコンフィグレーションと呼びますこれを使って、依存関係を分類します。これはMavenのスコープとほぼ同義です

configurations {
  conf1
}

7.2.2 依存関係の定義

コンフィグレーションを定義しｔら、次はそのコンフィグレーションに割り当てる依存関係を定義


dependencies {
  conf1 files("libs/sample-lib.jar")
}

依存関係の指定方法
- 外部モジュール依存関係
  - インターネット上のMavenリポジトリなどからファイルをダウンロードする。リポジトリの定義が別途必要
- ファイル依存関係
  - ファイルシステム上のファイルを参照
- プロジェクト依存関係
  - あるプロジェクトから別のプロジェクトの成果物を参照
- GradleAPI依存関係
  - 現在使用しているGradleのAPIが含まれるライブラリファイルへの依存関係
- ローカルGroovy依存関係
  - 現在使用しているGradleが同梱しているGroovyへの依存関係
外部モジュール依存関係
- おおよそ理解できているので割愛
ファイル依存関係
- おおよそ理解できているので割愛
プロジェクト依存関係

dependencies {
  compile project(':shared')
}

ルートプロジェクトの直下にあるsharedプロジェクトへの依存関係を宣言しているプロジェクト階層は:区切り

GradleAPI依存関係
- ビルドに使用しているGradleのAPIを参照するための依存関係
- Gradleのプラグインやタスクを作成するときなど、Gradle自体を拡張するときに使う

dependencies {
  conf1 gradleApi()
}

task showDeps doLast {
  configuration.conf1.each {
    println it.absolutePath
  }
}

ローカルGroovy依存関係
- ビルド似使用しているGradle似同梱されているGroovyを参照するための依存関係で、次の用にlocalGroovyを呼び出して指定

dependencies {
  conf1 localGroovy()
}

task showDeps doLast {
  configurations.conf1.each {
    println it.absolutePath
  }
}

7.2.3 コンフィグレーションの継承

依存関係のコンフィグレーションは、ほかのコンフィグレーションを継承できる


configurations {
  conf1
  testConf1.extendsFrom conf1 // testConf1はconf1の依存関係も含む
}

dependencies {
  conf1 group: 'org.codehaus.groovy', name: 'groovy-all', version: '2.3.1'
  testConf1 group: 'junit', name: 'junit', version: '4.11'
}

task showDeps doLast {
  configurations.testConf1.each {
    println it.absolutePath
  }
}

★用途
- テスト用のコンフィグレーションにプロダクト用のコンフィグレーションも含めたい
  - といった用途によく利用される

7.2.4 リポジトリ定義

外部モジュールの依存関係は、依存関係を取得する外部リポジトリを設定しなくてはいけない

Mavenリポジトリ

repositories {
  maven {
    url 'http://'
  }
}

Maven Central リポ維持鳥
- よく利用される一部のリポジトリについては、URLを指定しなくてもリポジトリを指定できる

repositories {
  mavenCentral()
}
// ローカルリポジトリも以下の様に記載できる
repositories {
  mavenLocal()
}

// jcenter mavenリポジトリも
repositories {
  jcenter()
}

// Ivyリポジトリも
// 使う予定はあまりないので一旦割愛

パスワードで保護されたリポジトリ

repositories {
  maven {
    url 'http://xxxx'
  }
  credentials {
    username 'user'
    password 'pass'
  }
}

セキュリティ上、認証情報はビルドスクリプトに直書きするのではなく、どこかバージョン管理システム似コミットされない外部ファイルに記述してそれを参照するのがいい

gradle.propertiesに記述例を紹介

フラとディレクトリリポジトリ
- ローカルファイルシステム上の単純なディレクトリをリポジトリとして指定できる
- ファイルシステムで共有している場合だったり、ライブラリをバージョン管理システムにあげている場合だったり

7.2.5 動的バージョンと変更性モジュール


configurations {
  conf1
}

dependencies {
  conf1 'org.slf4j:slf4j-api:1.7.+' // 1.7系のうち最新版を取得
  conf1 'commons-cli:commons-cli:latest.integration' // 不安定版も含めて最新版を取得
  conf1 'junit:junit:latest.release' // 不安定版の最新版を取得
}

7.3 推移的な依存関係の管理

依存関係に指定したJARファイルなどが更に別のファイルを必要としている場合について名自適に指定した依存関係から依存関係が再帰的に派生することを「推移的な依存関係」とよびます

7.3.1 競合の解決

推移的な依存関係を管理する場合、避けて通れない問題が、依存関係のバージョン競合

同じ依存のあるモジュールのバージョン違いをどのように解消するか
２つ解決策がある
- Newest戦略（デフォルト）
  - 取得した依存関係のバージョンが競合した場合、最も新しいバージョンの依存関係を使用
- Fail戦略
  - 競合した場合は例外を発行してビルドを失敗させる

// Fail戦略を使う場合
configurations.testConf1 {
  resolutionStrategy {
    failOnVersionConflict() // Fail戦略を採用する
  }
}

7.3.2 推移的な依存関係の除外設定

// Fail戦略を使う場合
configurations.testConf1 {
  resolutionStrategy {
    failOnVersionConflict() // Fail戦略を採用する
  }
}

dependencies {
  conf1 group: ''
  testConf1(group: '',name: '',version:''){
    exclude module: 'groovy-all' // 依存関係から除外する！
  }
}

7.3.3 使用するバージョンの強制

バージョン指定して記載するってこと
forceで強制している？
TODO: 必要になった際に再確認

クライアントモジュール依存関係

用途
- 依存しているモジュールのメタデータが誤っていたので上書きたい
- 導入したモジュールに依存している別のライブラリがあった
あまり使わないとおもったので割愛

7.4 使用しているモジュールの調査

ここでは、さらに依存関係を管理する目的の一つ、使用しているモジュールの調査方法を紹介

具体的には、Gradleが用意している依存関係のレポート用タスク、dependenciesタスクが本節のテーマ

gradel dependencies で実行できる

依存関係をグラフ化して表示することができる

7.5 キャッシュ制御とオフライン実行

7.5.1 キャッシュ制御

ビルドツールでは、一般的に一度解決した依存関係を再利用できるよう、ローカルマシンに依存関係をキャッシュするただGradleのキャシュ管理は他のビルドツールに比べて複雑

次に該当する場合、ネットワークへのアクセスが派生する場合がある
- repositoriesブロックで、ネットワーク上にあるリポジトリが定義されている
- 依存関係のうち、「外部モジュール依存関係」が使用されている

できるだけネットワークアクセスを削減できるように、チェックサムと一致するファイルがキャッシュにあれば、それを使用するような仕組みになっている

7.5.2 オフライン実行

gradle --offline showDeps オフラインで、キャッシュを使ってビルドするキャッシュをつかってビルドできなければ、失敗する

外部ネットワークとつながらない状態でビルドすることもできる
イントラネット内にリポジトリサーバーを立てる方法紹介

第3部［実践編］

第8章 Gradle でのテスト

Gradleのビルドタスクはプロダクションコードのコンパイルだけでなく、テストコードの粉ピルとテストの実行も行う Gradleを導入してビルドを行うだけで、テストを自動化できる環境が手に入ることになるテストを自動化するにあたって、どのような要件があり、Gradleでどう解決できるかを把握しておく必要がある

8.1 テストの自動化とビルドツール

8.1.1 テストを取り巻く状況

8.1.2 自動テスト似おけるビルドツールの要件

CI導入が一般的になったことで今やCIツールとの親和性は必須の要件

特に以下の３点は重要
- 環境の差異が吸収できること
- 特定の範囲でテストを実行できること
- スローテストを軽減できる仕組みをもっていること
  - 実行に非常に時間がかかるテストは「スローテスト」と呼ばれ、
  - 開発プロジェクトを妨げる問題として、しばしば取り上げられるようになった
  - ビルドツールがあれば暫定対応が容易にできるでしょう

8.2 Gradleによるアプローチ

Gradleは前述のビルドツールの要件をすべて満たしているかんたんにかけるので紹介します

8.2.1 環境差異の吸収

ビルドツールなら環境差異を吸収する仕組みを持っていることはあたりまえだが、
Gradleならシンプルにかける
方法は２つ
- 環境ごとにファイルを用意する
- １ファイル内でグループ化して切り替える


// dev
ext.app_url = 'localhost'

// pro
ext.app_url = 'xxx.xxx.xxx.xxx'

// build.gradle
apply from: "environments/${env}/env.gradle"

task showURL << {
  println "App Server: ${app_url}"
}

// env.conf
environments {
  dev {
    app_url = 'localhost'
  }
  production {
    app_url = 'xxx.xxx.xxx.xxx'
  }
}
// build.gradle
task showURL << {
  def url = new File('config/env.conf').toURL()
  def config = new ConfigSlurper("$env").parse(url)
  println 'App Server: ' + config.app_url
}

8.2.2 特定の範囲でテストを実行できること

種類
- パターンマッチングで特定して実行する
- テスティングフレームワークの機能を利用して実行する
- ソースセット単位で実行する

apply plugin: 'java'

sourceCompatibility = 1.7
targetCompatibility = 1.7

def defaultEncoding = 'UTF-8'
[compileJava, compileTestJava]*.options*.encoding = defaultEncoding

repositories {
    mavenCentral()
}

dependencies {
    testCompile 'junit:junit:4.11'
}

test {
	filter {
		includeTestsMatching '*UT'
	}
	reports.html.destination = file("${reports.html.destination}/unit")
	reports.junitXml.destination = file("${reports.junitXml.destination}/unit")
}

task integrationTest(type: Test) {
	filter {
		includeTestsMatching '*IT'
	}
	reports.html.destination = file("${reports.html.destination}/integration")
	reports.junitXml.destination = file("${reports.junitXml.destination}/integration")
}

TODO: 残りの説明割愛、必要になったら見返す

8.2.3 スローテスト対策

第9章 Android プロジェクトでの適用

第10章統合開発環境（IDE）との連携

第4部発展編

第11章 Jenkins との連携

第12章アーカイブの作成とファイルの公開

第13章エキスパートへの道

第14章ほかのビルドツールからの移行

付録 Gradleリファレンス

SpringBoot2徹底活用

Sun, 07 Jun 2020 00:00:00 GMT

現場至上主義SpringBoot2徹底活用

理解したこと

Gradleを使ったビルドができる

書籍情報

著者
- 廣末丈士／宮林岳洋著、高安厚思監修
定価
- 3,456円（本体価格　3,200円）
発売日
- 2018年11月30日
ISBN
- 978-4-8026-1185-5
目次
- 第1章 Spring Bootの構成
- 第2章 Webアプリケーションにおける共通処理
- 第3章データアクセス
- 第4章セキュリティ
- 第5章画面開発
- 第6章 API開発
- 第7章チーム開発
- 第8章運用
- 第9章（Spring Bootアプリケーションが想定している）システム構成
- 第10章 Spring5/Spring Boot2の新機能
- 第11章ローカル開発環境の構築について
- 第12章サンプルアプリについて
サンプルプログラム
- https://github.com/miyabayt/spring-boot-doma2-sample

第1章 Spring Bootの構成

1.1 SpringBootの基礎

SpringBootとは「Spring Frameworkベースのアプリケーションを手軽に作成することができるフレームワーク」
- それ自体で完結するフレームワークではない
- Spring MVCやSpring Batchなどの様々なフレームワークを組み合わせて素早く簡潔にアプリケーションを開発する機能を提供
- SpringBootの中にTomcatが同梱されており、デフォルトでjarファイルをして、java -jarコマンドで引数に指定すると組み込まれたtomcatが立ち上がり開発したアプリケーションを実行できる
代表的な特徴
- スターター
  - 依存関係をシンプルに定義するためのモジュール
- ビルドツール
  - バージョン解決など、開発を効率化するためのプラグイン
- コンフィグレーションクラス
  - XMLではなく、アノテーションとJavaで設定が書ける
- オートコンフィグレーション
  - デフォルトのコンフィグレーションが適用されて、必要なところだけを設定すればよくなる
- メインアプリケーションクラス
  - Javaコマンドで組み込みのTomcatを起動できる
- 設定ファイル
  - プロパティを外部ファイルに定義でき、動作使用を簡単に変更できる

スターター

一連の依存関係をセットとしてそろえるためのモジュール
必要なライブラリを準備したり、それぞれのバージョンを選定したりする煩わしい作業から解放される
たとえば、spring-boot-starter-webを１つ依存関係に追加するだけで、SpringMVCやTomcatなど、Webアプリケーションに必要なライブラリがセットになって追加される
以下はスターターの例
- spring-boot-starter-web : SpringMVC Tomcatが依存関係に追加される
- spring-boot-starter-jdbc : SpringJDBC Tomcat JDBC Pool が依存関係に追加される
スターターリファレンスページ
自分でスターターを作成する際は、*-spring-boot-starterという命名規則が定められていることに注意

ビルドツール

Spring Bootの推奨ビルドツール
- ApacheMaven
- Gradle
本書ではGradle
- メリット
  - スクリプトを記述するタイプのビルドツールのため、Antのようにタスクを自由に記述することができる
  - マルチプロジェクト構成の場合は、サブプロジェクトに対して一括設定して、必要に応じて個別に設定することができるため、記述量がMavenよりも少なくなる
  - Mavenの場合は、特殊な処理が必要になった時に独自プラグインを実装する必要があるのに対し、Gradleはスクリプトを書くだけで対応できる
Maven
- Mavenを利用する場合、spring-boot-starter-parentプロジェクトを親プロジェクトとして継承することで、プラグインのデフォルト設定、依存ライブラリのバージョンの定義、Javaコンパイラー準拠レベル、文字コードを引き継ぐことができる
親プロジェクト設定


<!-- Inherit defaults from Spring Boot -->
<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.0.6.RELEASE</version>
</parent>

Gradle
- Spring Boot2.0.xはGradle4.0以降に対応している
- GradleはMavenと違って、設定を引き継ぐための親プロジェクトが存在しないため、単に、スターターを依存関係として追加します
- spring-boot-gradle-pluginというGradleプラグインが用意されており、実行可能なJarファイルを作成するためのタスクを利用できる
ビルドスクリプトの処理内容
1. spring-boot-gradle-plugin をビルドスクリプトの依存関係に追加する
2. spring-boot-gradle-plugin と dependency-management プラグインを利用することを宣言
3. Javaコンパイラー準拠レベルをデフォルトの1.8から11に変更
4. 文字コードはUTF-8であることを指定する
5. スターターをアプリケーションの依存関係に追加する
6. テスト用のスターターをアプリケーションの依存関係に追加する

依存関係の管理

すべてのライブラリのバージョンを１つずつ指定するというような作業をする必要はない
依存関係に定義されているライブラリも一緒にバージョンアップする
Spring Bootのバージョンを上げる場合は、Project Wikiに載っているリリースノートを確認すること

コンフィグレーションクラス

Spring BootはJavaベースのコンフィグレーションが好まれる
従来通りXMLファイルに記述できるが、推奨されるのは@Configurationアノテーションを付与したクラスによるコンフィグレーション
MVCの設定のこと？再度確認する

オートコンフィグレーション

Spring Bootは設定を変更しなければ、あらかじめ敷かれたレールに沿って動作するようになっている

メインアプリケーションクラス

SpringBootのアプリケーションを起動するメソッドを呼び出すクラス
Javaアプリケーションのエントリポイントとなるmainメソッドの中で、SpringApplicationクラスのrunメソッドを呼び出すと、組み込みのTomcatが立ち上がり、SpringIoCコンテナの初期化が行われる
※再読

設定ファイル

アプリケーションを起動すると、次の場所にあるapplication.properties設定ファイルを読み込む
1. カレントディレクトリの/configサブディレクトリ
2. カレントディレクトリ
3. クラスパスの/configパッケージ
4. クラスパスのルート
上から順番に優先度が高くなる
プロファイルという単位で別々の設定を持たせることも可能
設定ファイルはyml形式でもOK
application.ymlを配置することで使用可能
設定ファイルの値を参照するのも簡単

Colum 外部設定ファイルの種類

環境変数
システムプロパティ
コマンドライン引数
いろんな渡し方がある
けど、アプリケーションプロパティしか使わないのではと思う

アプリケーションの起動

コマンドラインで起動 gradle bootRun
InteliJ IDEAを使って起動する

1.2 Spring BootによるWebアプリケーション開発

Intelij IDEA 起動
- Cntl + Shift + A -> compiler.automake.allow.when.app.running を ON にすることでファイル変更時に自動更新する
リソースの除外
- 静的リソースの変更は単に再読み込みするだけで再起動は不要
- デフォルト設定では、
  - /META-INF/maven
  - /META-INF/resources
  - /resources
  - /static
  - /public
  - templates
  - に含まれるファイルへの変更は再起動がかからないようになっている

// 再起動のトリガーから除外するファイルを設定する
spring.devtools.restart.exclude=static/**,public/**

LiveReload

// LiveReloadを無効化する
spring.devtools.livereload.enabled=false

Restart vs Reload

JVM hot-swapping をよりよいものにしたい場合
- JRebel(有償)または、Spring Loaded(無償:Grails2の内部で利用されている) の利用を検討する
もう一つの方法として、Dynamic Code Evolution VM(DCEVM) HotSwapAgentを使ったJVM hot-swapping がある
- JDKにパッチをあててクラスの再定義機能を強化してくれる
- Spring Loadedでは対応していないクラス追加に対してもhot-swappingが働く
DCEVM + HotSwapAgentの導入方法
- jarファイルをインストール http://dcevm.github.io/
- java -jar DCEVM-*-installer.jar 実行
Intelij IDEA プラグイン設定
- HotSwapAgent をインストール
- Settingより設定する

1.3 サンプルプロジェクトの構成

マルチプロジェクト

本書で用いるサンプルプロジェクトは複数のモジュールで構成されるマルチプロジェクト
メリット
- ビルドスクリプトを共通化することができるので記述量が減る
- ローカル・リモートリポジトリにアーティファクトをアップロードしなくてもソースコードの変更が反映される
- それぞれのプロジェクトを関連付けてタスクを実行できる

アプリケーション・アーキテクチャ

プレゼンテーション層
- プレゼンテーション層は、入力された値を受け取って、値をチェックしたり、値の変換を行ったりする層
- WebモジュールのFormクラス、FormValidatorクラスが該当
アプリケーション層
- プレゼンテーション層から受け取った値をドメイン層に渡す層で、WebモジュールのControllerが該当する
- ビジネスロジックは含まれないが、画面遷移先を制御したり、セッションを用いて、次画面に値を渡したりといった処理を行う
ドメイン層
- ドメインオブジェクトを持ち、ビジネスロジックを処理するメインの層で、ドメインモジュールのServiceクラスが該当する
- ドメインオブジェクトはすべての層から利用されるが、逆にドメイン層はほかの層に依存してはならない点に注意する！
インフラストラクチャ層
- インフラストラクチャ層では、ドメイン層から渡されたデータを永続化する層
- ドメインモジュールのRepositoryクラスが該当する
- アプリケーション層の影響を受けないように、汎用的な部品としてつくるようにすること！

サンプルプロジェクトのビルドスクリプト

Spring Bootのバージョンを拡張プロパティにセット
テストコードはSpockフレームワークを利用するため、Groovyを扱えるようにする
すべてのサブプロジェクトにおいて spring-boot-gradle-plugin を利用できるようにする
すべてのサブプロジェクトにおいて dependency-management プラグインを利用できるようにする
Javaコンパイラー準拠レベルを１１に変更する
src/main/resources をクラスパスに追加して、開発中の変更がすぐに反映されるようにする
リソースファイルの出力先をソースファイルの出力先に変更する
コンパイルの前に、リソースファイルの出力を行うようにする
Domaの依存関係にあるバージョン違いの Spring Boot を除外する
Spring Session モジュールを使ってセッション情報をデータベースに格納する
Gradleのプロジェクトプロパティを bootRun の引数に渡せるようにする


// メインアプリケーションクラスを持たないモジュールの場合（build.gradle）
bootJar {
  enabled = false
}

Lombokを利用する

ボイラープレートコードの削減のため
アプリケーションの実行時には不要なので、スコープはcompileOnlyに設定
型valが使用できる
- MEMO: これを使うと長い型を３文字でかけるよっていうことらしい

第2章 Webアプリケーションにおける共通処理

サンプルプロジェクトにおける共通処理、その実装方法について説明

種別	説明
バリデーション	単項目・相関チェックを効率よく実施する
オブジェクトマッピング	入力値を他のエンティティに効率よく詰め替える
ログ出力	共通的に処理の開始・終了をログ出力する
ファイルダウンロード	CSV、Excel、PDFなどのファイルをダウンロードする
ファイルアップロード	アップロードされたファイルを、Domaを使ってデータベースに保存する
メール送信	本文をテンプレート処理してメールを送信できるようにする

2.1 バリデーション

Spring MVC では単項目チェックを行うためのBean Validatorが用意されている
相関チェックのためのアノテーションはないので、効率よく相関チェックを行うために共通処理を実装する
Spring Bootでは spring-boot-starter-validationスターターを依存関係に追加することで、Bean Validation 2.0 と Spring Validatorが利用できる
バリデーションのポイント
- メッセージの設定
- バリデーションの種類
- 単項目チェック
- 相関項目チェック

メッセージの設定

Bean Validator はメッセージを外部ファイルで管理するためのMessageSourceを内包している
デフォルトでは文字コードがUTF-8 になっていないので、エラーメッセージを表示する際に文字化けてしまう
application.yml

# 共通の設定を定義する
spring:
  messages:
    # メッセージ定義ファイルのパスを含めて設定する
    basename: messages,ValidationMessages
    cache-duration: -1
    encoding: UTF-8 # P40. デフォルトのままだと文字化けするため指定

Colum メッセージを定義するファイルを分割する

application.ymlのbasenameにカンマ区切りで複数指定可能
- ValidationMessage:バリデーションのエラーメッセージを定義する
- PropertyNames:エラー項目の項目名を入力フォームごとに定義する
- messages:バリデーションとは関係ないシステムメッセージなどを定義する

バリデーションの種類

バリデーションの種類
- クライアントサイド
- サーバーサイド
本書はサーバーサイドのバリデーションについて説明
単項目チェック：Bean Validation APIで提供されるアノテーションを利用できる
相関項目チェック：org.springframework.validation.Validatorインターフェースの実装クラスを作成するか、自作のアノテーションを実装する

単項目チェック

javax.validation.constraintsパッケージに定義されている

アノテーション	チェック内容
Min,DecimalMin	数値の最小値を下回らないこと
Max,DecimalMax	数値の最大値を超えないこと
NotNull	NULL値ではないこと
Pattern	正規表現を満たすこと
NotBlank	値があること（空白を許さない）
NotEmpty	値があること（空白を許す）
Digits	数値であること
Past	過去であること
Future	未来であること

spring-boot-starter-validationスターターは Bean Validationの実装ライブラリーとして、Hibernate Validatorを依存関係に追加しているので、Hibernateで定義されたアノテーションも使うことができる

アノテーション	チェック内容
CreditCardNumber	正しいクレジットカード番号であること
Length	NULL値ではないこと
Range	範囲内の値であること
SafeHtml	妥当なHTML書式であること
URL	正しいURLであること

参考URL
- https://beanvalidation.org/2.0/
Formオブジェクトに@NotEmptyなどのアノテーション付与
Controllerの@PostMapping("/new")を付与したメソッドの引数に@Validatedを付与し、Formオブジェクトを第一引数に指定
チェック結果が、第二引数のBindingResultに入るので結果をチェックする

Column PRGパターンについて

PRGパターンでは、Post-Redirect-Getメソッドを組み合わせて、以下の流れで登録処理を行う実装パターン

保存ボタンを押したとき、POSTメソッドを使い、サーバーにリクエストする（P:Post）
入力値をDBに保存するといった一連の処理を行い、詳細画面にリダイレクトする（R:Redirect）
GETメソッドで詳細画面が表示される（G:Get）

サンプルプロジェクトはほぼすべての機能において、PRGパターンを適用している
メリット
- ブラウザの戻るボタンを押しても、フォーム再送信のダイアログを表示しないようにすることができる

相関項目チェック

2.2 オブジェクトマッピング

ModelMapperを使用した詰め替え例の紹介
Dozerなどもあるのでお好みで使用すること
Strictモードにしないと意図しない詰め替えが発生する可能性があるので注意
MEMO: ここはOrikaを採用することにしたので割愛

2.3 ログ出力

MDCを使ってログに値を埋め込む設定
- コントローラに関数名を返却する処理を埋め込む
- リクエストごとに乱数を生成して埋め込む（リクエストトラッキング）
ログローテーションの設定について

2.4 ファイルダウンロード

ファイルの出力処理を共通処理にするとソースコードの記述量を削減市、統一された方法に揃えることで微妙な動作の違いを生まない用にすることができます。

ファイルダウンロード機能は、エンタープライズのアプリケーション開発に限らず、とてもよくある機能の１つ

org.springframework.web.servlet.Viewインターエースを実装することで、汎用的なロジックで様々なファイルダウンロードに対応できる用になる

PDFファイルのダウンロード

帳票出力の代表的なライブラリとして、JasperReportsがある JasperReportsは、.jrxmlという拡張子のXMLファイルで帳票のレイアウトをテンプレートとして定義して帳票を出する際に対象データを引数に渡すことで帳票を出力します。テンプレートファイルはJasperSoftStudioというEclipseベースの帳票デザインツールを使って作成

SpringMVCには、JasperReportsをサポートするViewクラスが提供されていたが、SpringFramework5から機能が除外されている

そのため、JasperReportsライブラリを直接使ってPDF出力するPDFViewクラスを実装して、引数にデータを渡すだけでPDF出力ができるようにします。

CSVファイルのダウンロード

CSVファイルのダウンロードは、jackson-dataformat-csvを利用するとシンプルに実装することができる

CsvViewクラス
Entityクラス
Controllerクラス

Excelファイルのダウンロード

Excelファイルのダウンロードの場合は、org.springframework.web.servlet.view.document.AbstractXlsxViewを利用 AbstractXlsxViewはApachePOIに依存しているのでバージョンまで指定して依存関係を記述します PDFファイルの場合と同様で、ファイル名に日本語文字が含まれると文字化けが生じてしまうので、子クラスを作成して対応

2.5 ファイルアップロード

ファイルダウンロードと同様によく実装する機能の１つ

SpringBootでは、アップロードファイルのサイズ上限などの設定を適切に行わないと、オートコンフィグレーションによるデフォルトの動作仕様では要件を満たせないこともありえるので注意が必要 SpringBootでは、ServletAPI3.0で利用できるjavax.servlet.http.Partを内包するMultipartResolverがオートコンフィグレーションされるので、なにもしなくてもMultipartFileインターフェースを使ってファイルを受け取ることができる

ファイルサイズの設定

１ファイルのサイズ上限は１MBで、１リクエストで受け付ける上限は１０MBになっている

spring:
  servlet:
    multipart:
      max-file-size: -1 # デフォルトは1MB　-1だと無制限
      max-request-size: 20MB # デフォルトは10MB

ファイルの取扱

ファイルのデータベースへの格納

TODO: 後で画像保存する処理実装する

2.6 メール送信

MEMO: 省略

第3章データアクセス

本chapterでは、O/RマッパーとしてDomaを使った実装方法を説明 Domaは2way-SQLと呼ばれるSQLテンプレートを利用できるので、SQL分の見通しがよくなるという特徴がある

実行時にSQLテンプレートとJavaソースコードとの不整合を検知して間違いを指摘する機能も備わっていて、とても使い勝手がよいO/Rマッパーです

3.1 スターター

2way-SQLとは
- SQLのコメントに条件分岐を記述することで、プログラムのSQLテンプレートとしての利用と、囲うせずにそのままツールでの利用という２通りの使い方が可能になっているSQL文

3.2 Domaの使い方

3.3 エンティティ共通処理

すべてのエンティティにシステム固有のシステム制御項目（作成者、作成日時、更新者、更新日時、削除者、削除日時）を用いて、エンティティを取り扱うときに、すべてのテーブルに共通のルールを適用する場合の共通処理について説明

エンティティ基底クラス

エンティティ基底クラスを用意し、共通的に使うフィールドを定義することができる

@Entityアノテーションにリスナーを指定すると、更新・登録・削除のタイミングで共通的な処理を実行することができる

TODO: 共通項目実装

3.4 ページング処理

DOMAはページング処理を行うための仕組みとして検索オプションを提供している
TODO: 要実装

3.5 排他制御

楽観的排他制御

データ不整合を保険的に防ぐ方法複数人が同じデータを編集してしまった場合に、先に保存したほうの編集内容が後から保存した内容で上書きされてしまうといったことを防ぐことができる

Domaを使って楽観的排他制御を行うには以下の条件を満たす必要がある

エンティティのフィールドに@Versionアノテーションが付与されている
Daoインターフェースに付与したアノテーションのignoreVersionをtrueにしていない
テーブルに数値型の改定番号カラムが定義されている
流れ
1. Formオブジェクト二改定番号のフィールドを定義する
2. コントローラに@SessionAttributeアノテーションを付与する。
3. 編集画面の初期表示処理で改定番号を含めてデータを取得して、Formオブジェクトに詰め替える
4. 更新処理で、更新対象データを取得して、そのデータをFormオブジェクトの値で上書きする
5. Daoの更新処理を呼び出す（ここで排他制御がかかる
6. 不要になったFormオブジェクトをセッションからクリアする
TODO: 楽観的排他制御について深堀り、実装→悲観的排他制御だけでアプリとしては回せそう
Column セッション情報の格納先について
- 楽観的排他制御の説明の中でSessionAttributeを使ってFormオブジェクトをセッション情報に保存する方法を紹介しました。サンプルプロジェクトでは、SpringSessionモジュールを依存関係に追加しているので、SpringBootによるオートコンフィグレーションが行われます。SpringSessionには、以下の格納先に対するオートコンフィグレーションが用意されています。
  - JDBC
  - Redis
  - Hazelcast
  - MongoDB
- セッション情報の格納先を変更したい場合は、設定ファイルにリスト3.11を記述することで変更することができます。
  - redisにする場合：spring.session.store-type=redis
TODO: セッションの格納先はREDISにする

悲観的排他制御

データベースの行ロック機能を使った排他制御で、在庫数のような頻繁に同時更新がかかるようなデータの整合性を担保する方法として利用される

Domaでは、悲観的排他制御を行うための仕組みも用意されていて、ページング処理の説明と同じ用に検索オプションを使う

悲観的排他制御を行うときに注意すべきなのは、検索結果が０件になるような条件で検索すると、行ロックではなくテーブルロックがかかる点です！！！処理時間が長い処理でテーブルロックがかかってしまうと、処理の滞留が発生してしまい、システム全体が不安定な状態二なることもあるので注意する

3.6 論理削除

DBのレコードを削除するのではなく、削除フラグによってレコードの削除を表すという方法

更新機能による実現

@Update(excludeNull = true) // Nullの項目は更新対象にしない

エンティティリスナーによる共通処理

リスナーの中のpreUpdateメソッドの中で、メソッド名が論理削除のメソッド名と一致するかを確認する

論理削除レコードの除外

論理削除を行うことをアプリケーション内で統一している場合は、データ取得のSQLに、論理削除フラグによる削除データの除外が行われる用にする必要がある
Column 参考文献
- BLOG.IK.AM https://blog.ik.am/
  - 初めてのSpringBoot著者
- SlideShare Toshiaki Maki https://www.slideshare.net/makingx

第4章セキュリティ

本chapterでは、SpringSecurityを使った認証・認可とそれらにまつわる課題を解決する実装方法を説明

4.1 スターター

  compile group: 'org.thymeleaf.extras', name: 'thymeleaf-extras-springsecurity5', version: '3.0.4.RELEASE'
  compile 'org.springframework.boot:spring-boot-starter-security'

4.2 認証

認証情報の取得

UserDetailsServiceをimplementsして実装する方法
TODO: 権限周りが実装できていないので見ておく

ログイン機能

ログイン機能のコントローラを実装します。デフォルトでも組み込みのログイン画面を表示することが可能ですが、ほとんどの場合において画面を変更する必要があるので、Thymeleafテンプレートを使ってログイン画面を表示する用に実装し、それ以降の処理はSpringSecurityと連携するようにします。

TODO: タイムアウト処理やログイン成功処理など実装の必要があればサンプルを基に実装する
- /authorize　にfowardできなくて、formオブジェクト経由のエラーチェックが実装できなかった

4.3 RememberMe

一般的なWebサービスでは、ログイン画面に「ログインしたままにする」というチェックボックスがあることがしばしばある一定期間内であればセッションがタイムアウトしても自動ログイン処理が行われる機能が提供されるので、何度もログイン画面でパスワードを入力する不便さを解消することができる

ログイン記録の永続化

TODO: 自動ログイン機能は必要になれば実装しておきたい
- 合わせて不要なレコードを削除する機能も実装する必要がある

4.4 認可

管理機能を備えたWebアプリケーションにおいては、ログインユーザーごとに権限を付与して、特定のユーザーのみが操作することができるように制御することがよくあるこのようなアクセス制御を行う場合は、以下の要件が満たされていると汎用的に使えるためとても便利

要件
- システムを利用するユーザーは、複数のロール（役割）を持つことができる
- 特定リソースの操作を識別する単位として権限を定義することができる
- ロールは、複数の権限を持つことができる
- システムの移動中にロールの持つパーミッションや対象のリソースを変更することができる
SpringSecurityを使った認可の実装方法としては、アノテーションを使う方法と、JavaConfigでURLベースの条件式をていk技する方法がある
これらの方法では、システムの稼働中に新たに役割に権限を追加したり、することが困難
認証処理の中でデータベースからロール権限を取得して、コントローラのメソッドレベルでの認可制御を行うようにしている

権限管理データをロード

権限とメソッドの紐付け

認可制御のインターセプター

TODO: 権限管理はあとで見直す

4.5 CSRF対策

// 以下を追加するとformにhiddenでcsrfトークンが埋め込まれる
http.csrf()
  .csrfTokenRepository(new CookieCsrfTokenRepository());

4.6 二重送信防止

二重送信防止するためのチェック方法
- JavaScriptでボタンを連打できないようにする
- PostRedirectGetパターンを適用
- トークンを使った送信済みチェックをする
TODO: ここで紹介されているやり方だと、二重送信防止チェックをするのは、UPDATEが伴う処理のみに限定できる
- ページ遷移や検索処理で二重送信が行われた場合は除外できるという仕組みになっている
- ここの実装方法の方がより現実的なので後で真似る

第5章画面開発

5.1 Thymeleaf

SpringMVCといえばJSP一択だったが、HTML5に準拠した形で管理できる方が望ましい

メリット
- Spring推奨
- HTML5準拠
- デザイナとの分業がしやすい
- ブラウザで直接参照できる

5.2 Formバインディング

FormBeanの定義方法とバリデーション方法

5.3 事前評価

アプリケーションで扱うデータは特定の変換処理をかけたいことがよくある Thymeleafでは事前評価をサポートしている

事前評価の実装例

表示する言語を翻訳する例が紹介されている
FormBeanの値と、実際に表示したい値が異なる場合に有用だと思う
<p th:text="${@myapp.translator.Translator@translateToEnglish(textVar)}">some text here ...</p>

5.4 テンプレート共有

テンプレートの部品化

includeとreplaceの話

テンプレートの共通化

レイアウトという機能でテンプレートの共通化をサポートします HTMLのレイアウトやJavaScriptおよびCSSのインクルードを一元管理できる本機能を用いてテンプレートの共通化を採用することでソースコードの保守性や品質も向上するため、積極的に導入すべき機能

  compile('nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect:2.3.0') {
    exclude group: "org.codehaus.groovy", module: "groovy"
  }

@Configuration
public class WebConfig extends WebMvcConfigurer {
  @Bean
  public LayoutDialect layoutDialect() {
    return new LayoutDialect();
  }
}

レイアウト機能を利用するために、xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"を指定する
layout:fragment="任意の文字列"で各ページで差し替えるエリアを指定する
MEMO: Spring徹底入門でも紹介されていたが、画面の全体像がわかりづらくなりやすいためincludeを用いることにする

5.5 Thymeleafのその他の機能

エスケープなしのテキスト

通常、クロスサイトスクリプティング対策のためSpringはタグ文字列をエスケープして表示している
場合によってはエスケープしないで、文字列を表示したいケースがある
<p th:utext="#{home.welcom}">Welcom to our grocery store!</p>
このutextを利用する場合は、XSSの脆弱性を含まない用に注意が必要

日付操作拡張

Thymeleafでは、Date/TimeAPIをデフォルトでサポートしていないため拡張ライブラリーを使用する必要がある

  // https://mvnrepository.com/artifact/org.thymeleaf.extras/thymeleaf-extras-java8time
  compile group: 'org.thymeleaf.extras', name: 'thymeleaf-extras-java8time', version: '3.0.4.RELEASE'

<input class="form-control" type="text" name="holidayDate"
 th:value="${(value != null) ? #temporals.format(value, 'yyyy/MM/dd') : '' }" />

※その他にもThymeleafは各種の拡張機能をサポートしている

5.6 静的コンテンツ管理

BtoCのアプリケーションを構築する際、UI/UXの向上が欠かせないため、クライアントサイドライブラリを有効活用する必要がある JavaScriptやCSSを適切に管理していない状況では、次の問題が発生することがありました。

JavaScriptやCSSが適切にバージョニングされていないため、ブラウザキャッシュにより、リリース時に古いバージョンが提供されてしまう。
JavaScriptやCSSライブラリが構成管理されていないため、安易な外部ライブラリの利用により障害が発生してしまう
本節では、Webアプリケーションの静的コンテンツについて
- 配置場所
- キャッシュ制御
- アクセス制御
- クライアントライブラリの構成管理方法
  - を解説！！

静的コンテンツの配置場所

SpringBootでは、SpringMVCのオートコンフィグレーションに以下の設定がされており、デフォルトでは次の４点のパスに静的コンテンツを配置できる

/resources/
/static/
/public/
/META-INF/resources/

キャシュ制御

キャッシュする時間は、application.(properties|yml) や ResourceHandlerRegistryのオーバーラードで調整

spring:
  resources:
#    cache-period: 86400 # 1日間キャッシュさせる
    chain:
      strategy:
        content:
          enabled: true # 静的コンテンツのキャッシュ無効設定 MD5ハッシュが計算される バージョン管理戦略と呼ばれるらしい
          paths: /**

TODO: バージョン管理戦略を実施した場合のキャッシュの挙動を確認しておく

アクセス制御

Faviconなどの画像ファイルやクライアントライブラリは未認証、認証にかかわらずアクセスできる必要がある SpringBootでは、SpringSecurityのオートコンフィグレーションにリストの設定がされており、デフォルトで次の５点のパスはpublicアクセス可能

しかし、SEOに必要なrobots.txtやsitemap.xmlは含まれないため、これらのファイルをPublicアクセス可能とするには、JavaConfigで設定を上書きする必要がある

デフォルトで許可されている５点
- /css/
- /js/
- /images/
- /webjars/
- favicon.ico
TODO: SEO対策に必要な知識を習得しておく必要がある

  private static final String[] STATIC_RESOURCES = {
      "/favicon.ico", "/css/**", "/js/**", "/img/**", "/lib/**", "/font/**"
  };
  @Override
  public void configure(WebSecurity web) {
    // セキュリティ対策が不要なリソースがある場合、SpringSecurityの処理を適用しないようにする
    //    web.ignoring().antMatchers("/resources/static/**");
    web.ignoring().antMatchers(STATIC_RESOURCES);
  }

クライアントライブラリの構成管理

サーバサイドエンジニア中心のチーム構成だとフロントライブラリの管理が抜けてしまうことがよくある

本項では、WebJarsを用いてクライントライブラリを管理する方法を紹介

Dependenciesの追加方法を説明

  // https://mvnrepository.com/artifact/org.webjars/webjars-locator-core
  compile group: 'org.webjars', name: 'webjars-locator-core', version: '0.45'

第6章 API開発

金融機関でのAPI公開の動きが急激に加速しているように、APIというキーワードはビジネス領域でもよく目にする用になってきているシステム開発でも迅速に機能をリリースしていくためにはAPI連携は書かせず、API連携の重要度は日に日に高まってきている

6.1 Spring でのAPI開発

MSA(Micro Service Architecture)開発やSPA開発ではAPI連携が必須一方小売業界ではオムニチャネルといった言葉が生まれている

チャネルの違いを意識しないようにするには、バックエンドのサービスをAPI化し、PC/スマホ/他サービスなどの複数のチャネルから透過的に利用できるようにする必要がある

API仕様

リソース実装

コントローラ実装

エラーハンドリング実装

@RestControllerAdviceアノテーションを指定して作成

6.2 SpringでのAPI連携

現在のシステム開発でアジリティを追求するためにはAPI連携は欠かせません

RestTemplate

SpringではRestTemplateというRESTクライアントを提供している RestTemplateを用いると、Javaオブジェクトとレスポンスボディの変換も容易に実現できる

ユーザー一覧取得APIへの連携

ユーザー作成APIへの連携

6.3 API開発効率の最大化

API開発でクライアント側でモックを用意して実装をすすめる必要がある

API定義をExcelなどのドキュメントで管理し、Excelなどのドキュメントに基づきクライアント側でモックの準備をすすめると、仕様の認識齟齬が発生することが多くなってしまいます。

またAPIの仕様変更時の連携のオーバーヘッドも大きくなってしまいます。

本節では、現在の開発での必須要素であるAPI連携をより円滑にすすめるためにAPI管理にSwaggerを用い、API開発の効率を上げる方法を説明

Swaggerとは

OpenAPI仕様に基づくAPI開発ツールのフレームワークであり、APIのライフサイクル全体に渡って、設計から文書の管理、テストおよびデプロイまでを可能にします。

大きな利点は以下の４つ
- OpenAPI準拠
- YAMLを用いた宣言的な記法
- コード自動生成
- エコシステムの充実（SwaggerHub）
OpenAPI準拠
- マイクロソフト、Googleなどの大手の企業を含むOpenAPIInitiativeがLinuxFoundationの協力のもとで結成され、APIの記述のために採用したのがSwagger
- API管理のデファクトスタンダードと呼ばれるほど普及している
YAMLを用いた宣言的な記法
- SwaggerはAPI定義をYAML(JSON)により宣言的に記載できます。
- また、定義したYAMLからSwaggerUIというツールを用いると、HTMLベースの定義書やモックを作成できます。
- SwaggerUIを利用し、APIを公開すると、クライアント側は動く仕様としてAPIを参照できるため、API連詠によるコミュニケーションコストを低下させることができます。
コード自動生成
- Swaggerには、Swagger CodegenというSwaggerUIで公開されたAPI仕様を基にコードを自動生成するツールがある

TODO: Dockerを用いてSwaggerCodegenを用いたスタブサーバーの起動例　確認しておく

エコシステムの充実(SwaggerHub)
- SwaggerCodegenを用いてスタブサーバーを起動し、開発チームで共有する方針も悪くないですが、ホスト環境の管理やAPI仕様の変更の都度、コードの再生成および再起動が必要になります。
- Swaggerはエコシステムも充実しており、SwaggerHubというAPI管理のプラットフォームがあります。
- SwaggerHubはSwaggerを使ったモックサーバーやテスト環境などAPI管理に関するサービスをまとめて提供しているため、APIの管理工数を下げることが可能です。
- SwaggerHubはAPIドキュメントの編集/表示、モックサーバーの立ち上げ、SwaggerCodegenの機能などをブラウザベースで提供しています。

TODO: SwaggerHubは一回使ってみる必要あり！！！ →お金かかるから断念... チーム開発に有用かも？

Springでの利用(SpringFox)

SwaggerでのAPI管理がデファクトスタンダードになっていること、Swaggerを利用することのメリットを説明しました。本項では、SwaggerをSpringで利用する方法を説明します。

Springでは、SpringFoxを用いるとAPIドキュメントの自動生成が可能 SpringFoxはSwaggerUIの提供もサポートしているため、APIを用いたチーム開発を円滑にすすめることができる次の手順に従い、SpringFoxの利用方法を説明

依存関係の設定
共通設定カスタマイズ
個別エンドポイントのカスタマイズ
静的ドキュメント生成

依存関係の設定

// https://mvnrepository.com/artifact/io.springfox/springfox-swagger2
compile group: 'io.springfox', name: 'springfox-swagger2', version: '2.9.2'
// https://mvnrepository.com/artifact/io.springfox/springfox-swagger-ui
compile group: 'io.springfox', name: 'springfox-swagger-ui', version: '2.9.2'

共通設定カスタマイズ(JavaConfig)

@Configuration
@Import({ ThymeleafConfig.class, // Thymeleafを使用することを明示
    GoogleAutoConfiguration.class })
@EnableSwagger2
public class AppConfig implements WebMvcConfigurer {

APIControllerのみグルーピングする方法を紹介

個別エンドポイントのカスタマイズ

アノテーションでAPIごとの説明を追加できる

静的ドキュメント生成

SwaggerUIを動的に生成する方法は、API連携開発の効率を上げてくれるため、開発フェーズでは導入しておくと効果的

しかし本番サービス稼働後に上述の手順を有効化しておくと、SwaggerUIの外部公開制御が必要になります

本項では、別のアプローチとして、SwaggerのAPI定義から静的ドキュメントを生成する方法を紹介

依存関係の設定
テストクラスの追加
HTML変換
依存関係の設定
- SwaggerからAsciiDocへの変換をサポートしているSwagger2Markupというライブラリがある
- Swagger2MarkupをSpring向けにカスタマイズした、springfox-staticdocsを依存関係に追加する
テストクラスの追加
- テストコードを作成し、CIサイクルに含めておくと、静的なドキュメントのAsciiDocが自動生成される
HTML変換
- HTMLへの変換はasciidoctorを利用する

TODO: HTMLへ変換するCI構築する

Spring REST Docs

Springでのドキュメント生成の自動化には、Spring REST Docsを採用する方法もある

利点
- テストをパスしないドキュメントは作成されないため、「動く仕様書」として信頼できる。
- asciidoctorを用いた簡潔な記法
手順
- 依存関係の設定
- 雛形生成
- テストコード生成

第7章チーム開発

システム開発では、１人ですべての作業を簡潔させることはできません。

最近のシステム開発で主流となってきている機能ごとに分割して開発する手法のMSA(MicroServieceArchitecture)開発でも、５～８人でのチーム開発（Two Pizza Team）が良いとされています。

7.1 インフラの構成管理

ローカルPC、検証環境、本番環境（オンプレミスもしくはクラウド）など、プログラムは様々な環境で動く可能性があります。

本節では、特定の環境にロックインされないようにする方法を紹介旧来のシステム開発では、Excelなどで作成された手順書を用いて、半日～２日かけて開発環境を構築することが当たり前でしたしかし最近では、Infrastracture as Code(IaC)やDockerをはじめとするコンテナ技術が広く普及してきたことにより、上述のような方法を採用することはとても効率的とは言えません

Docker

「私のローカル環境では再現しません」をなくそう秘伝のたれ的な作業が影響して、このような環境差異によるトラブルが発生しがち

コンテナ技術のDockerを用いて、環境構築手順をコード化してGithubなどにコミットし、環境の使い捨てができる状態にしておくことで、上述のようなトラブルを抑制できる

メリット
- インフラ構築手順のコード化（Dockerfile）
- 環境依存性による問題の排除
- 廃棄容易姓
Column クラウドベースの統合開発環境（AWS Cloud9）
- ここ数年、ブラウザのみでコードを記述、実行、デバッグできる統合開発環境の利用が活発化している
- ブラウザベースの統合開発環境の有名なサービスとして、AWS Cloud9がある
- AWS Cloud9を利用すると、開発には非力なマシン（ipadなど）でも、いつでもどこでも開発が可能
インフラ構築手順のコード化（Dockerfile）
- 開発に関わる全ての文書は構成管理の対象とすることが望ましい
- チーム開発では、アプリケーションプログラムは必然的に構成管理の対象となりますが、設計文書やインフラ構築手順は構成管理の対象外になってしまうことがある
- インフラ構築手順のコード（Dockerfile）をSCMにコミットすることで、利用しているディストリビューション、設定ファイルの状態がコードで明確化されるため、インフラに関わるトラブルを抑制できる
環境依存性による問題の排除
廃棄容易姓
Column Tweleve-Factor App
- コンテナ開発が活発になってきているのと同時に、クラウドアプリケーション開発のベストプラクティスの１つとして、The Twelve-Factor Appが取り上げ垂れることが多くなってきています。
- The Twelve-Factor Appは、Herokuのプラットフォーム開発での治験をプラクティスに落とし込んだもので、コードベース、依存関係、プロセス、並行性、廃棄容易姓、開発/本番一致などの１２の要素から構成されます。
- アプリケーションをThe Twelve-Factor Appに適用させることができれば、コンテナベースの開発に適用していることになるため、オンプレミス、クラウドなどの実行環境に関わらずアプリケーションをデプロイできます。

TODO: The Twelve-Factor Appについて深堀り

Windows10proではHyper-Vを有効化することでDockerを利用できます。
ここでは、Windows10 Pro以外でDockerを利用する方法を紹介します
VagrantとVirtualBoxでDocker環境を構築

TODO: VagrantとDockerのコマンドについて説明しているので再度理解した上で読んで見る SpringBootで利用するための設定についても記載があるので組み込んでおく

7.2 データベースの構成管理

データベースの構成管理をするための、OSSのDBマイグレーションツールのFlywayを紹介

Flywayの利用

SpringBootで利用するための設定
- 依存下院系の設定
- プロパティ設定
- マイグレーションファイルの準備

7.3 メンテナブルなテストコード

テストコードは重要本節では、GroovyベースのテスティングフレームワークのSpockを用いてテストコードの可読性を上げる方法を紹介

Spock

言語仕様に、RSpecやScalaなどのよい点を取り入れており、大きく次の３点の利点がある

可読性
データ駆動テスト
Power Assertions

TODO: SpringでのSpockの利用方法を紹介 GroovyやScalaなどをキャッチアップする必要がありそう

7.4 ドキュメント生成ツールの活用

設計書が適切に管理できていない例
- 詳細設計書がそもそもない
- Textファイル、Excel、Wikiなどにドキュメントが散乱している
- Excelなどで納品ドキュメントとして管理されているが、ソースコードと乖離している、および設計書がないプログラムがある
本節では、チーム開発で共有するドキュメントについて述べる
ドキュメント管理ツールのSphinxを紹介

Sphinx

Sphinxはドキュメントを簡単に作ることができるようにするツール
セットアップ
- Pythonを利用しているため、Pythonの実行環境が必要
- Dockerを用いた方法を紹介

TODO: 後ほど実施

Sphinxの特徴
- テキスト(MarkDown)形式
- CIとの相性がよい
- 様々な出力形式をサポート

7.5 ソースジェネレータ

SpringMVCに基づいた画面開発では、１つの機能を追加するために、多岐にわたるファイルの作成が必要画面開発のたびに発生するファイル作成作業を効率化することで開発生産性を向上させることができる

通常のプロジェクト開発では多くの画面を開発する必要があり、大規模なプロジェクトだと数百画面もの開発が必要になってくるプロジェクト開発で必要になってくる画面開発にかかる以下のコストを削減することで、開発生産性をさらに向上させることができる

開発メンバー参画の際のパッケージ構成のベストプラクティスの共有
新規画面開発の際の必要なソースコード一式の作成作業

この方法論は古くから知られており、有名なプロダクトとしては、YEOMANやAngularJSでも同様のツールセットが用意されている → AngularCliのことか

ここでは、Thymeleafを用いて、Gradleのカスタムプラグインとして、ソースジェネレータを作成する方法を紹介

ソースジェネレータプラグインの導入

次の手順で導入
- GradlePluginの実装
- GradlePluginの利用

TODO: 余裕があればソースコード生成の自動化を組めたら

メンバー全員に自動生成の仕組みが浸透していない状態で導入すると、ごちゃごちゃするのであまりおすすめできないらしい

第8章運用

システム開発は、「開発を完了させること」＝「業務やサービスの提供が滞りなく進むこと」ではないシステムは、システムトラブルなどの望まない状態を排除・軽減し、利用者に継続的に使われていくことではじめて価値を生んでいきます。 IPAによると、運用コストはシステム開発の全体の3/4以上のコストを占め、運用の重要性が高まってきている

8.1 環境ごとの設定管理

Spring Profiles

開発/本番環境の柔軟な切り替え

環境ごとの設定管理

ファイルを分ける方法を記載→理解しているので飛ばす

8.2 アプリケーションサーバー設定

本設では、SringBootで提供している組み込み型のWebサーバー（Embedded Web Servers）を配備するサーバーの設定方法を紹介

実行可能Jar

以下を加えることでビルド時に依存下院系のあるライブラリを梱包したJarを容易に作成できる

bootJar {
  launchScript()
}

アプリケーションサーバーの設定及びリリース

systemdを用いたアプリケーションサーバーの設定

TODO:　jarファイルの生成とDocker組み合わせまでできたらやってみる

8.3 アプリケーションの状態確認

システム開発では、利用者に見える機能開発や画面デザインが優先されてしまい、SLAの検討が後回しになることが少なくありません。

本設では、SpringBootでのアプリケーションの状態の確認方法について紹介

SpringBootActuator

SpringBootには、Actuatorという安定運用に寄与する強力な機能があるActuatorを有効にすると、HTTPやJMX経由でアプリケーションの状態を確認でき、自前でヘルスチェックのエンドポイントを実装する必要はなくなる

SpringBootActuatorを有効化する

  // https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-actuator
  compile group: 'org.springframework.boot', name: 'spring-boot-starter-actuator', version: '2.3.0.RELEASE'

上記の設定だけで、デフォルトではシャットダウンを除く全てのエンドポイントが有効になります

主要なエンドポイント

Beans
- アプリケーションに登録されたBeanの一覧を取得します。Curlでのリクエスト例を紹介
Environment
- アプリケーションで利用している環境変数の一覧を取得
Health
- アプリケーションのヘルスチェック。AutoConfigurationの状態をもとにデータベース接続やDiskFullのチェックを実施します
HeapDump
- ヒープダンプファイルをHTTPエンドポイントから取得できる
Mappings
- アプリケーションのエンドポイントとリクエストパスのマッピング情報を出力します。SpringFoxなどを導入しなくてもアプリケーションのエンドポイントの詳細な情報が取得できる
Metrics
- アプリケーションの現在の状態を出力
Thread Dump
- スレッドダンプを取得します
Prometheus
- インフラサービス監視ツールのPrometheusへ連携するメトリクスを出力するエンドポイント
- 2018/10現在、Prometheusエンドポイントを有効にするためには、ライブラリを追加する必要があるらしい
Column Prometheusとは
- サーバーやインフラなどのメトリクスを取得できるOSSの統合監視ソリューション
- Prometheusはインストールや設定が容易で、かつ十分な機能を持ち管理しやすいという特徴を持ちます。
- Go言語で開発されており、バイナリと設定ファイルを用意するだけで利用できる他、Zabbixなどと異なり、データを格納するデータベースを別途用意する必要もありません。
- また、DockerやKubernetesといったコンテナ/クラスター管理ツールとの連携機能もあり、容易に監視対象を設定できるため、マイクロサービス開発を推進している企業での導入が増加

エルスチェックのカスタマイズ

Actuatorのデフォルトのヘルスチェックも強力ですが、ヘルスチェックをカスタマイズすることも可能

システム独自のチェックをすることができる

HealthIndicatorインターフェースを実装するBeanを登録することで実現できる

SpringBootActuatorのセキュリティ制御

アプリケーションの機密情報を取得できるため、システム管理者以外からのアクセスは遮断する必要がある

Spring Boot 2系では、/info, /health以外のエンドポイントはデフォルトで認可ありとなります。認可なしにしつつ、Listenポートの変更及び接続元IPを制限する設定は以下

8.4 アプリケーション監視

システムを運用していくためには、アプリケーション状態の可視化およびアプリケーション異常を迅速に検知する必要がある

クラウドを用いた開発が普通（ニューノーマル）となった現在では、監視設計についてもクラウドに適したものにしていく必要があります。本設では、システム運用に欠かせないアプリケーション監視について、Prometheusを用いる方法を説明

Prometheus

メリット
- 導入の敷居の低さ
- クラウドネイティブ時代に適した設計
- オープンソース

なお、本番環境のトータルの運用コストを見据える場合は、有償の監視サービスのMackerelやDatadogも検討対象にしてみる

Prometheusの導入

インストール方法は次の３つ
- バイナリのダウンロード
- Docker
- ソースビルド
PrometheusのDownloadページよりターゲットOSのファイルをダウンロードし、展開するだけでインストールは完了

Prometheusのサービスディスカバリー

Prometheusにはサービスディスカバリ機能が備わっており、サービスの拡張に自動で追従します。例えば、AWS EC2を利用している場合、サーバーの増減に自動で追従します

Springアプリケーションとの連携

SpringActuatorとPrometheusは連携できる
設定する方法を記載

メトリクスの可視化

単体でもメトリクスの可視化はできるが、Grafanaと連携すればより強力にビジュアライズできる

ダウンロード
- バイナリのダウンロード
- パッケージマネージャインストール

アラート通知

Prometheusは複数のコンポーネントで構成されており、アラート通知もオプション構成となっている

AlertManagerのインストール
- アラート通知を実現するためには、Prometheus本体のPush通知を処理するAlertManagerのインストールが必要
- バイナリファイルをダウンロードして展開する
Slack通知設定
- 本書では、Slack通知の設定方法を説明
- AlertManagerはメール、HipChatなどの連携をデフォルトでサポートしています

TODO:　このあたりは見返して設定していきたい

8.5 リクエスト追跡

本番環境では、可用性要件を考慮の上、アプリケーションサーバーを冗長化することが多く行われます。また並行性を考慮するとアプリケーションサーバーは状態をNoSQLやRDBに保持させるステートレス構成とし、スケールアウト及びスケールイン構成とすることも多く行われます。

アプリケーションが多層で連携する場合、各層でリクエストを処理するサーバーが不定となるため、ユーザーの行動履歴をトレースするためには、リクエスト追跡の仕掛けを導入する必要があります。本節では、リクエスト追跡の方法としてnginxを用いる方法を紹介

nginxトレース

静的コンテンツ配信の最適化やプロキシ用途でnginxを導入することは多く行われる

nginxは以下の用に設定すると、リクエストIDがCookieに付与される

userid           on;
userid_name      uid;
userid_domain    example.com;
userid_path      /;
userid_expires   365d;

nginxとのトレースIDの統合

前項では、ミドルウェア（nginx）でリクエスト追跡IDを発行する方法を紹介リクエスト追跡を切れ目なく実現するために、nginxとリクエスト追跡IDの統合の方法を紹介

リクエスト追跡機能は横断的関心事（cross-cutting concerns）のため、SpringAOPで実装する方針が望ましいと言えます

RequestTrackingInterceptor.javaに実装した内容のことを説明していた
Column ログ集約ソリューション
- 複数台構成のアプリケーションをステートレスにと持つことを望ましい構成とすると、各アプリケーションサーバーにSSH接続してログを確認する方法では運用が大変
- 上述の課題に対応するためには、ログ集約の仕組みを導入する方法がよい
- ログ集約のソリューションとしては、商用のSplunk、DatadogやOSSのFluentd、Logs、AzureではLogAnalyticsなどの仕組みがある。アプリケーションを複数台で運用する際はこれらのソリューションの導入も検討してみて

TODO: OSSのFluentdは使ってみたい

8.6 レイテンシ分析

リクエスト追跡が可能な構成で、かつ応答遅延が発生した場合は、ボトルネック箇所を特定し対応を検討する必要があるまた、MSA開発では、多層、多数のサービスが連携するため、サービスのどこがボトルネックであるか特定できる仕組みの導入が望ましいと言えます。

本節では、SpringエコシステムであるSpringCloudプロジェクトのSpringCloudSleuthを用いてレイテンシ分析する方法を紹介

Spring Cloud Sleuth

FrontentとBackendで同じIDを出力して処理を追うことができますよっていう説明 RestTemplateを使用する必要があるみたい

ここでレイテンシが図られる様子 Zipkinで可視化できるみたい

8.7 無停止デプロイ

BtoCサービス開発の場合、サービスに影響をおよぼさず無停止でアプリケーションをデプロイする必要が多くあります。特に利用者が多い場合は、必須の要件となります。

本節では、オンプレミスの条件付きで、無停止でアプリケーションを更新する方法を紹介

ローリングデプロイ

ローリングデプロイ作業フロー

Step1. アプリサーバー#1へのデプロイ
- プロキシサーバーからアプリサーバー#1へのリクエスト振り分けを停止
- アプリサーバー#1のアプリケーションをデプロイ

ローリングデプロイ作業手順

TODO: nginxの設定ファイルの変更方法も記載しているので後で参考にして設定しておきたい

8.8 コンテナオーケストレーションツールへのデプロイ

コンテナをデプロイする基盤としてのコンテナオーケストレーションツールは、激しい開発競争が繰り広げられましたが、Kubernetesがデファクトスタンダードとなっている

本節では、SpringBootアプリケーションを、Dockerコンテナを用い、コンテナオーケストレーションツールのKubernetesを用いてデプロイする方法を紹介

コンテナイメージの作成

TODO: Kubernetesを使ったコンテナ管理...後でDockerを一通り使い倒した後確認する

第9章（Spring Bootアプリケーションが想定している）システム構成

どんなにアプリケーションコードが優れていても、システム・アーキテクチャ設計が適切でないと安定的にサービスを提供できません。本ChapterではSpringBootで作成したアプリケーションを中心とした本番環境のシステム・アーキテクチャ構成について検討します。

9.1 システム・アーキテクチャ考察

データベースを用いるSpringBootで作成したアプリケーションの場合、１つの仮想サーバーにアプリケーションおよびデータベースを構築することで、最小限の構成によるサービスの提供は可能

クラウドネイティブが常識となった現在では、クラウドベンダーが提供するマネージドサービスの特性を理解し、適切なアーキテクチャ設計を行う必要があります。

システムが必要とする要件

要件
- 可用性：稼働率は99.9%以上を目標とすること
- 拡張性：スループットの増加に対して、サービスが低下しない性能を維持するための資源の追加が容易に行えること
- 完全性：データの操作にはACIDを保証し、データの堅牢性を実現すること

システム要件の検討

可用性
- システム構築ではSLAが明記されることが普通
- サービス品質がSLAの保証値を著しく下回った場合には、ペナルティが発生することもあります。
- SLAに可用性99.9%と記載されている場合、数値として年間にして９時間弱、月間にして４４分弱以内の停止しか許さないシステム構成を検討する必要がある
拡張性
- システム構築では、サービス特性によりシステムへの負荷がばらついたり、突発的な高負荷が発生したりすることがあります。
- 可能な限りシステムリソースのスケールアウト及びスケールインできるように設計することが望ましいと言えます。
完全性
- システム構築では、システムじの状態をRDBなどのデータストアに保管することが普通
- システムで保管した情報資産が正当な権利を持たない人により変更されていないことを確実にしておくよう設計する必要があります。また、データの消失を防ぐための対策も実施していく必要があります
コスト
- Capter8で解説したように、運用コストはシステム開発全体の3/4以上のコストを締めます。
  - システムリソースの運用コスト（ハードウェアコストやライセンスコストなど）
  - システム運用のコスト（人件費など）

9.2 システム・アーキテクチャ案

AWSを利用したアーキテクチャ例を記載している

構成要素一覧

可用性

拡張性

コスト

9.3 構築チュートリアル

Teraformを利用した環境構築を紹介している

第10章 Spring5/Spring Boot2の新機能

2017年にリリースされたSpring5,2018年にリリースされたSpringBoot2の新機能のうち、今後重要になると考えられるWebFluxについて説明

10.1 WebFlux

HTTPを利用したシステムの範囲が拡大し、同時アクセスが増えていくにつれて、Webアプリケーションにおけるコンピュータリソースに対して待ちが多いことがわかってきました。そのため非同期処理を用いたWebアプリケーションが求められる様になりました。その解決案の１つとしてリアクティブプログラミングが選ばれ、Srping5/SpringBoot2においてはWebFlux飛ばれるリアクティブプログラミングを用いたWebプログラムを書くことができるようになりました。このプログラムは同期ではないのでブロックされることなく、実施されてI/O待ちのような状態にはならず、I/Oが発生したタイミングで実施されることになります。

TODO:　実装ハードル高そう。色々考えること多いので後で見返す

第11章ローカル開発環境の構築について

第12章サンプルアプリについて

Spring徹底入門

Fri, 01 May 2020 00:00:00 GMT

Spring徹底入門

目次
- 第1章　Spring Frameworkとは
- 第2章　Spring Core（DI×AOP）
- 第3章　データアクセス（Tx、JDBC）
- 第4章　Spring MVC
- 第5章　Webアプリケーションの開発
- 第6章　RESTful Webサービスの開発
- 第7章　Spring MVC の応用
- 第8章　Spring Test
- 第9章　Spring Security
- 第10章　Spring Data JPA
- 第11章　Spring ＋ MyBatis
- 第12章　Spring＋Thymeleaf
- 第13章　Spring Boot
- 第14章　チュートリアル
形式：書籍
発売日：2016年07月20日
ISBN：9784798142470
価格：本体4,000円＋税
仕様：B5変・744ページ

第1章　Spring Frameworkとは

Spring Frameworkの概要
- 「Spring Frameworkは、開発当初より古いインフラ環境上でも新しいインフラ環境上でも、最新のプログラミング思想で開発出来ることを設計思想にしている」
Spring Frameworkの歴史
- 2003年：Interface21 Framework → Spring Frameworkへと変更になった (Expert One-one-One: J2EE Design and Development)
- 2004年：EJBを使わずにSpringFramework1.0で開発する方法
- 2005年：SpringFramework1.2 の機能をカバーした書籍が刊行 SpringをStruts,Hibernateと組み合わせて使う（SSH）
- 2006年：SpringFramework2.0がリリース
- 2007年：SpringFramework2.5 アノテーションベースのDIやMVC
  - 米国に拠点を移す SpringToolSuiteなど統合開発環境の提供が始まる
- 2009年：SpringFramework3.0がリリース JSR330に対応
- 2013年：SpringFramework4.0がリリース WebsocketやWebメソッドなどをサポート
  - Pivotalという新しい会社にスピンオフ
- 2014年：昨今注目されているSpringBootやSpringIOPlatformプロジェクトが始まる
Springの各種プロジェクトについて
- SpringMVC: Webアプリケーションを開発するためのフレームワークであり、MVCパターンを利用している
  - MVCパターンには、「アクションベースフレームワーク」と「コンポーネントベースフレームワーク」の２パターンある
    - アクションベースフレームワーク
      - リクエストによって実行する処理（アクション）を決定し、処理の結果としてレスポンスを返すフレームワーク
    - コンポーネントベースフレームワーク
      - リクエストやレスポンスを抽象化（隠蔽）し、画面を構成するコンポーネントをベースにWebアプリケーションを開発するフレームワーク
      - JSFはコンポーネントベースのフレームワーク
        
        MEMO: JavaEE徹底入門読んで理解した！
  - 各種サードパーティとの連携機能もある
    - Jackson
    - ApacheTiles
    - FreeMarker
    - Rome
    - JasperReports
      - また、Thymeleafなど、サードパーティ自体がSpringMVCをサポートしているケースも有る
Spring Security
- Authentication(認証)
- Authorization(認可)などのセキュリテイ要件を用意に実現するためのフレームワーク
  - 非常に多くの認証方式に対応している
    - Basic認証
    - ダイジェスト認証
    - X.509クライアント証明証
    - LDAP
    - OpenID
Spring Data
- Spring Dataはリレーショナル・データベースやNoSQL、Key-Valueストアなど様々なデータストアへのデータアクセスを用意にするためのもの
  - Spring Data Commons
  - Spring Data JPA
  - Spring Data MongoDB, Spring Data Redis, Spring Data Solr, etc...
Spring Batch
- バッチアプリケーション向けの軽量フレームワーク
- 大容量のデータ処理に必要な共通機能を提供している
- もともと、Accentureが開発したバッチアプリケーション向けのフレームワークをベースとしており、2008年にSpringBatchとしてバージョン1.0がリリース
Spring Integration
- Enterprise Integration Patterns(EIP)としてよく知られているさまざまなシステム間を連携させるアーキテクチャパターンに基づく開発をサポートするフレームワーク
- 同様の機能を実現するOSSとして、ApacheCamelが有名です。
Spring Cloud
- 分散環境でCloud Nativeなアプリケーションを開発するためのフレームワーク及びツール群
  - SpringCloudConfig
  - SpringCloudBus
  - SpringCloudConnectors
  - SpringCloudNetflix
Spring tool Suite
- Eclipseベースの統合開発環境
Spring IO Platform
- 依存関係を管理するためのライブラリー
Spring Boot
- 最小限の設定でプロダクションレベルのSpringアプリケーションを容易に開発するためのSpringプロジェクト
JavaEEとの関係
- 差は縮まっている
- Springのほうが新しい技術を取り込むサイクルが早い

第2章　Spring Core（DI×AOP）

DIコンテナメリット
- インスタンスのスコープを制御できる
- インスタンスのライフサイクルを制御できる
- 共通機能を組み込める
- コンポーネント間が疎結合になるため、単体テストがしやすい
SpringFramework以外の有名なDIコンテナのフレームワーク
- CDI(Contexts&DependencyInjection) ：JavaEE6で導入されたコンテキストに対応したDIの仕様
- Google Guice
- Dagger
ApplicationContextとBean定義
- SpringFrameworkではApplicationContextがDIコンテナの役割を担う
  - DIコンテナに登録するコンポーネントのことを「Bean」
  - Configurationのことを「Bean定義」
  - DIコンテナからBeanを取得することを「ルックアップ」という

UserService userService = context.getBean(UserService.class);
UserService userService = context.getBean("userService",UserService.class);
UserService userService = (UserService)context.getBean("userService");

代表的なBean定義の方法
- JavaベースConfiguration
- XMLベースConfiguration
- アノテーションベースConfiguration
それぞれ１つだけを使用して実装もできるが、通常は
- JavaベースConfigurationとアノテーションベースConfigurationの組み合わせ、または
- XMLベースConfigurationとアノテーションベースConfigurationの組み合わせを用いてBean定義を行う
Configuration方法
javaベース、XMLベース、アノテーションベースの説明
インジェクションの種類
- セッターインジェクション
- コンストラクタインジェクション
- フィールドインジェクション
オートワイヤリング
- @Beanメソッドや<bean>要素で明示的にBean定義しなくても自動的にＤＩコンテナにインジェクションさせる仕組み
- 解決方法は２つ
  - 型によるもの（by Type）
  - 名前によるもの（by Name）
型による解決
- デフォルトでインジェクションされる事が必須
- 対象の型を持つBeanが１つも登録されていないとorg.springframework.beans.factory.NoSuchBeanDefinitionExceptionが発生

required = false を指定するか

Spring4からは、required = falseの代わりに、JavaSE8から導入された、java.util.Optionalを使用することが出来る
- MEMO: Optional<T>で実装できる！絶対こっちのほうがいい　関数型プログラミングの本で知った。
名前による解決
- 同じ親クラスを持つ２つの実装クラスにBean定義をして、インジェクションする場合
- @Qualifierで名前を指定してあげないといけない
- @Primaryを使えば、名前を指定しなかった時にインジェクションされるデフォルトを指定できる
- 名前には、実装クラス名を記載するべきではない。呼び出し側で実装を特定してしまうとDIの意味がなくなる。用途名を指定するべき。
- 用途は文字列ではなく、アノテーションでも指定できる。
[ ] 用途を指定するためのアノテーション作成してみたい
[ ] 独自アノテーションを作成してみる
名前によるオートワイヤリング
- @Resourceを付与
- フィールド名がBean名に一致するパターン
- プロパティ名がBean名に一致するパターン
コレクションやmap型によるオートワイヤリング

2.1.6 コンポーネントスキャン

デフォルトのコンポーネントスキャン
- 以下のアノテーションが付いたクラスがＤＩコンテナに登録される
  - @org.springfrwamework.stereotype.Component
  - @org.springfrwamework.stereotype.Controller
  - @org.springfrwamework.stereotype.Service
  - @org.springfrwamework.stereotype.Repository
  - @org.springfrwamework.context.annotation.Configuration
  - @org.springfrwamework.web.bind.annotation.RestController
  - @org.springfrwamework.web.bind.annotation.ControllerAdvice
  - @javax.annotation.ManagedBean
  - @javax.inject.Named
コンポーネントスキャンは広範囲な程処理が遅くなるので不適切
- @ComponentScan(basePackages = "com")
- @ComponentScan(basePackages = "com.example")
対象のアプリケーションのトップレベル、あるいはもう１階層下をスキャン対象にすべき
- @ComponentScan(basePackages = "com.example.demo")
- @ComponentScan(basePackages = "com.example.demo.app")
value属性は basePackages属性の別名であり、どちらを使用しても構いません。この属性を省略した場合、コンフィグレーションクラスと同じパッケージ配下をスキャンすることに注意する事
スキャン対象のアノテーションとしては以下の４種類がよく使われる

アノテーション	説明
@Controller	MVCパターンのC(Controller)の役割を担うコンポーネントであることを示すアノテーション。このアノテーションを付与したコンポーネントでは、クライアントからのリクエストとクライアントへのレスポンスに関わる処理を実装する。ビジネスロジックは、`@Service`を付与したコンポーネントで行う
@Service	ビジネスロジック（ビジネスルール）を提供するコンポーネントであることを示すアノテーション。このアノテーションを付与したコンポーネントでは、ビジネスルールが関わる処理を実装する。データの永続化に関わる処理は`@Repository`を付与したコンポーネントで行う。
@Repository	データの永続化に悪化÷処理を提供するコンポーネントであることを示すアノテーション。このアノテーションを付与したコンポーネントでは、ORM(Object-Relational Mapper)などの永続化ライブラリ等を使用して、データのCRUD処理を実装する
@Component	上記３に当てはまらないコンポーネント（ユーティリティクラスやサポートクラスなど）に付与するアノテーション

フィルタを明示したコンポーネントスキャン
- アノテーションによるフィルタ
- 代入可能な型によるフィルタ
- 正規表現によるフィルタ
- AspectJパターンによるフィルタ
[ ] フィルタを駆使するパターンについてメリットがあまり分からないため飛ばす.. あとで調べる

2.1.7 Beanのスコープ

DIコンテナを使用するメリット
- Beanのスコープ（生存期間）の管理をコンテナに任せる事が出来ること

スコープ	説明
singleton	DIコンテナの起動時にBeanのインスタンスを生成し、同一のインスタンスを共有して利用する。デフォルトの設定であり、スコープを設定しない場合はsingletonとして扱われる
prototype
session
request
globalSession
application
カスタムスコープ(独自の命名)

覚書
- @Beanアノテーションの使いどころ
  - @Configurationクラスの中に定義しているメソッドに付与して使う
  - DIコンテナに登録され、デフォルトではsingletonで参照出来る

2.1.8 Beanのライフサイクル

初期化フェーズ
利用フェーズ
終了フェーズ

2.1.9 Configurationの分割

DIコンテナで管理するBeanが多くなるとConfigurationも肥大化してしまう
Configurationの範囲を明確にし、可読性を上げるために、必要に応じてConfigurationの分割を行う
@importを使えば複数のConfigurationクラスに分割ができる
- MEMO: importでまとめなくても、@Configurationでコンポーネントスキャンされるので関係ないと思う
- Contextから取得してわざわざアクセスしていた際に有用な方法だったと考える

2.1.10 Configurationのプロファイル化

Springでは異なる環境や目的ごとにConfigurationをグループ化することができる
このグループを「プロファイル」といいます。
例えば、環境ごとに「developmentプロファイル」「testプロファイル」などを作成することが考えられる

@Profileアノテーションを使用して指定する

使用するプロファイルの選択方法
- JVM引数 -Dspring.profiles.acrive=production
- 環境変数 export SPRING_PROFILES_ACTIVE=production
- WEB.xmlに記載することもできる（割愛）
- application.yml に指定することもできる（割愛）
MEMO: 環境ごとの情報を定義するためのJavaクラスにアノテーションを付与して実現するのは微妙だと思うので、
- application.ymlで管理するのが良いだろうと思う

2.1.11 JSR 330: Dependency Injection for Java

Springで、Java標準のJSR330で定められたAPI（主にアノテーション）を使用することができる

Spring	JSR	説明
`@Autowired`	`@Inject`	`@Inject`には必須チェック（required属性）がない
`@Component`	`@Named`	Springの場合はデフォルトでSingletonスコープであるが、JSR330の場合はデフォルトでprototypeスコープである
`@Qualifier`	`@Named`	`@Named`が兼用される
`@Scope`	`@Scope`	JSR330の`@Scope`はスコープを定義するカスタムアノテーションを作るためのメタアノテーション

Springを使うのであれば、特にこだわりがなければ、Springのアノテーションを使うのがいいでしょう

2.2 AOP

ロギング処理、キャッシュ処理など本質的ではない処理がいろいろなロジック中に散在するようになる
複数のモジュールにまたがって存在する処理は、「横断的関心事（Cross-Cutting Concern）」と呼ばれる
代表的なものとしては以下
- セキュリティ
- ログ出力
- トランザクション
- モニタリング
- キャッシュ
- 例外ハンドリング
プログラムの中から横断的関心事を取り除き、一箇所に集めることを「横断的関心事の分離（Separation Of Cross-Cutting Concerns）」と呼び
これを実現する手法をアスペクト指向プログラミングといいます

2.2.1 AOPの概要

AOPはDIと並ぶSpringFrameworkの重要な機能
AOPのコンセプト
- Aspect
  - AOPの単位となる横断的な関心事を示すモジュールそのもの
- Join Point
  - 横断的な関心事を実行するポイント（メソッド実行時や例外スロー時など）
  - Join PointはAOPライブラリーによって使用が決められている
  - SpringのAOPでは、Join Pointはメソッドの実行時
- Advice
  - 特定のJoin Pointで実行されるコードのことで、横断的な関心事を実装する箇所
  - Adviceには、Around,Before,Afterなど複数の種類が存在する
- PointCut
  - 実行対象のJoin Pointを選択する表現式のこと
  - SpringAOPではBean定義ファイルやアノテーションを利用してPointCutを定義
- Weaving
  - アプリケーションコードの適切なポイントにAspectを入れ込む処理のこと
  - AOPライブラリにはWeavingをコンパイル時に行うもの、クラスロード時に行うもの、実行時に行うものがあり、SpringAOPは実行時にWeavingを行う
- Target
  - AOP処理によって、処理フローが変更されたオブジェクトのこと
  - TargetオブジェクトはAdvisedオブジェクトと呼ばれることもある

2.2.2 Spring AOP

SpringAOP は現場で広く使われているAOPフレームワークであるAspectJを利用している

2.2.3 Adviceの実装方法

Before
After Returning
After Throwing など記載していく
括弧にPointCut式を記載する

2.2.4 XMLでAdviceの実装

XMLに記載する方法について

2.2.5 Pointcut式

Joint Pointを指すPointCutとしてexecution(* *..*ServiceImple.*(..))という式を使ってきたがその打ち合わけを記載

                                                ↓メソッド
@After(execution(* com.example.domain.*Service.find*(..)))
                 ↑戻り値　↑パッケージ   ↑型、クラス     ↑引数

PointCut式で利用可能なワイルドカード
- *
- ..
- +
名前付きポイントカットの書き方

2.2.6 Springプロジェクトで利用されているAOP

トランザクション管理処理：メソッドに@Transactionアノテーションを付与
認可処理：@PreAuthorizeアノテーションを付与
キャッシュ処理：@Cacheable("key")ですでにキャッシュがある場合はメソッドを実行せずにキャッシュされた値を返す
非同期処理：@Asyncをメソッドに付与、指定された戻り値（CompletableFuture<Result>）を指定することで非同期実行ができる
リトライ処理：@Retryable(maxAttempts=3)をメソッドに付与。信頼性をコントロールできない外部接続先の呼び出しなどで有用

2.3 データバインディングと型変換

本来であれば、HttpServletRequestクラスからパラメータをgetしてBeanに１つ１つ設定しなければ行けないが、
型変換しなければ行けない場面もあり面倒でミスが起きやすい
Springのデータバインディングを利用するとこれらの問題を解消できる

2.3.1 Springのデータバインディング

EmployeeForm form = new EmployeeForm();
ServletRequestDataBinder dataBinder = new ServletRequestDataBinder(form);
dataBinder.bind(request);

これを記載することで、３行でデータバインディングができる
また、SpringMVCの機能を使えば１行で済む（恐らく、@ModelAttributeを付与することを言っているのだと思う）

2.3.2 Springの型変換

型変換を行うための仕組みとして以下の３つを提供している
- PropertyEditor
- Type Conversion
- Field Formatting

2.4 プロパティ管理

ハードコーディングを避けるためにプロパティから値を読み込む仕組みがある
Strutsを使用していたときはプロパティファイルの値取得はResourceBundleでUtilクラス経由で取得していたのに対して、
SpringのDIであれば、@Value(xxxx)を引数やフィールドに指定するだけで取得できる
MEMO: これは必ず使用する
- :で区切って記載すればデフォルト値も指定できる！
- @Value(xxxx:5)などのように

2.5 Spring Expression Language(SpEL)

Spring Expression Language (SpEL)は、SpringFrameworkが提供しているExpression Language
MEMO: 使用しないことにする

2.5.1 SpELのセットアップ

pom.xmlの例

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-expression</artifactId>
</dependency>

2.5.2 SpEl APIの利用

直接APIを使用するケースはないと思うが、SpELの仕組みを理解するために使用方法を説明

2.5.3 Bean定義でのSpELの利用

SpELで定義した値をコンストラクタの引数に渡す方法の説明
アノテーションの場合は、@Value("#{T(java.util.UUID).randomUUID().toString()}") String idのような形で定義する
SpELは様々なアノテーションの中で利用することができる
- @EventListener
- @TransactionalEventListener
- @Cacheable
- @CachePut
- TODO:後で調べる

2.5.4 SpELで使用可能な式の表現

リテラル値
オブエジェクトの生成
プロパティへの参照
メソッドの呼び出し
型の解決
変数の参照
Beanの参照
演算子
テンプレート
コレクションの操作
MEMO:テンプレートエンジン使うなら、SpELいらないのは説

2.6 リソースの抽象化

アプリケーションは様々なリソースにアクセスする必要がある
これらのリソースが格納されている場所は
- ファイルシステム上のディレクトリ
- クラスパス上のディレクトリ
- サーブレットコンテナ上のwarファイル
- jarファイル
- 別のWebサーバー
  - など多岐に渡る

2.6.1 Resourceインターフェースと実装クラス

Resourceインターフェース実装クラス
- ClassPathResource
- FileSystemResource
- PathResource
- UrlResource
- ServletContextResource
TODO: Resourceインターフェースを実装しているクラスをいくつか紹介してくれているが、
- 実際にこれらのクラスを使ってみる必要あり

2.6.2 ResourceLoaderインターフェース

MEMO: ResourceLoaderインターフェースと上記のつながりが理解できてないので再確認
- ResourceLoader経由のほうがよい？
- 上記の実装クラスを使わなくて済むならこっちのほうがよいと考える

2.6.3 Resourceインターフェースを利用したリソースアクセス

TODO: 実際に使ってみる必要あり

2.6.4 XMLファイル上でのリソースの指定

割愛
MEMO: リソース取得先の指定はプロパティファイルにまとめるべき！
- すべて@Value()で記載すればよい

2.7 メッセージ管理

説明文や項目名などの固定文言
処理結果に通知するメッセージ
エラーメッセージなどを表示する際に
プロパティファイルなどの外部定義から取得することが求められるケースも多いはず
メッセージの外部化のメリット
- 多言語サポートする要件を満たす
- 一箇所で一元管理する

2.7.1 MessageSourceインターフェースと実装クラス

MessageSource
- メッセージの格納先を抽象化するためのインターフェース
MessageSourceResolvable
- メッセージ解決に必要な値（code,args,defaultMessage）を保持していることを示すインターフェース
MessageSourceの実装クラス
- ResourceBundleMessageSource
- ReloadableResourceBundleMessageSource

2.7.2 MessageSourceの利用

MessageSourceのBean定義

@Bean
public MessageSource messageSource() {
  ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();
  messageSource.setBeannames("messages"); // クラスパス上に格納されているプロパティファイル（拡張子は除く）を指定する
  return messageSource;
}

メッセージの定義ファイルを作成
MessageSourceのAPI利用
- DIコンテナに登録したMessageSourceをインジェクションしてgetMessageメソッドを呼び出す
MEMO: 感じたこと
- 標準のクラスをDIコンテナで管理したい場合@Beanをメソッドにつけているのかなと思った
- 独自のクラスを作るのであれば、@Componentでよいのではと
MessageSourceResolvableの利用
- メッセージ引数もメッセージ定義で管理したい場合に利用するみたい

第3章　データアクセス（Tx、JDBC）

データアクセス機能について解説
- JDBC関連の機能
- トランザクション管理機能
- データアクセスエラーのハンドリング機能
- その他ライブラリの機能（JPA、Hivernate、MyBatisといったORM）は以降の章で解説

3.1 Springによるデータアクセス

まずはSpringが扱うことができるデータソースの種類について

3.1.1 データソースについて

データソースは、データベースにアクセスするためのコネクションをアプリケーションに提供する役割を担う

Springが提供するデータベースアクセス機能では、以下に示す３つのデータソースを利用することができる
- アプリケーション内に定義したデータソース
  - アプリ内にユーザや接続情報などを記載するパターン
- アプリケーションサーバーに定義したデータソース
  - APサーバーに定義されたデータソースを利用するパターン
    - MEMO: JavaEE徹底入門ではこのパターンでサンプル実装されていた
- 組み込みデータベースのデータソース
  - HSQLDB、H2、Apache Derbyといった組み込みデータベースをデータソースとして利用する
MEMO: Commons DBCP はコネクションプール機能付きのデータソースを提供するライブラリー
- 実際に定義を作成していく際に、コネクションプール設定方法について確認しておく

3.1.2 データソースのコンフィギュレーション

<!-- https://mvnrepository.com/artifact/org.springframework/spring-jdbc -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
    <version>5.2.3.RELEASE</version>
</dependency>

アプリケーション定義のデータソース
- アノテーション定義の例（詳細略）
- XML定義の例（詳細略）
アプリケーションサーバー定義のデータソース
- Jndiを指定して参照する（詳細略）
組み込みデータソース
- （詳細略）
TODO: 実際に上記の３種類で接続をしてみる必要がある

3.2 Spring JDBC

前節ではSpring JDBCを使用するために必要となるデータソースのBean定義方法を紹介した
データアクセス処理を記述するための中心的な役割を持つJdbcTempleteクラスの使用方法を紹介
- SQLを実行する方法
- SQLへ値をバインドする方法
- SQLの実行結果からデータを取得する方法

3.2.1 Spring JDBCとは

SQLの内容にかかわらす共通に行われる定型的なJDBCの処理をSpringが代替する機能

定型的な処理
- コネクションのオープンやクローズ
- SQLステートメントの実行
- 処理結果行の繰り返し処理
- 例外ハンドリング
SpringJDBCを利用することで、実装範囲を以下のような重要な処理に限定できる
- SQLの定義
- パラメータの設定
- ResultSetの取得結果において、各レコードに対して実行したい処理

3.2.2 JdbcTempleteクラスを利用したCRUD操作

JdbcTempleteクラスを用いたCRUD操作の説明
MEMO: ORMを使用したほうが効率が良さそう
- 念の為読んでおく程度で、覚えておかなくても良いと考える

3.2.3 取得結果の変換処理

SpringJDBCでは取得結果を変換できる３つのインターフェースを用意している
- RowMapper
  - ResultSetの１行を特定のPOJOインスタンスに変換する
- ResultSetExtractor
  - 複数行から１つのインスタンスを生成できる
- RowCallbackHandler
  - ResultSetを参照してなんらかの処理を行うためのインターフェース
  - 戻り値を返さない。取得結果のファイル出力や、データのチェックなどを行う場合に利用します。
RowMapperの実装方法
- RowMapperインターフェースを実装したクラスにメソッドを作成して使用する
- BeanPropertyRowMapperクラスを利用することもできる
  - 制約はありルールに沿ってBean定義すればかんたんにResultSetを設定可能
ResultSetExtractorの実装
- 割愛
RowCallbackHandlerの実装
- 割愛

3.2.4 応用的なCRUD操作

SQLのバッチ実行
- batchUpdate()メソッドを利用する
ストアドプロシージャの呼び出し
- JdbcTemplateのcallメソッドやexecuteメソッドを利用することで呼び出すことができる
- TODO: ストアド・プロシージャ使ってみる。使ったことないので。。

3.3 トランザクション管理

アノテーションを用いたトランザクション管理方法
プログラム内に直接commitメソッドやrollbackメソッドを記述する明示的なトランザクション管理について説明

3.3.1 トランザクションマネージャ

PlatformTransactionManager: Springのトランザクション管理の中心となるインターフェース
トランザクションマネージャの定義
- PlatformTransactionManagerのBeanを定義する
- トランザクション対象とするメソッドを定義する
ローカルトランザクションを利用する場合
- 単一データベースに対する複数の操作
- XMLにTransactionManagerの定義を記載する方法を紹介
- BeanIDはtransactionManagerを指定することを推奨
グローバルトランザクションを利用する場合
- 異なるデータベースに対する複数の操作
- グローバルトランザクションの仕組みはJTAというJavaEEの仕様として標準化されておりアプリケーション・サーバーからJTAの仕組みが提供されている
- 実装クラスとしてJtaTransactionManagerを使用する
- ただし、製品ごとのJtaTransactionManagerが提供されているのでそちらを使う自動的に最適なクラスを使う仕組みが用意されているらしい

3.3.2 宣言的トランザクション

宣言的トランザクションとは
- 事前に宣言されたルールに従い、トランザクションを制御する方法のこと
- メリット
  - トランザクションの開始やコミット、ロールバックなどの典型的な処理をビジネスロジックの中に記述する必要がなくなる
- 利用方法
  - @Transactional
  - XMLコンフィギュレーション
@Transactionalを利用した宣言的トランザクション
トランザクション制御で必要となる情報
- アノテーションの引数について説明（割愛）
- クラスに付与するかメソッドに付与するか
コンフィギュレーションクラスに定義する方法も紹介している
XMLコンフィギュレーションによる宣言的トランザクション
- 割愛

3.3.3 明示的トランザクション

明示的トランザクションとは
- コミットやロールバックといったトランザクション制御に関する処理をソースコードに明示的に記述する方法
PlatformTransactionManagerを利用した明示的トランザクション制御
- commit(),rollback()などを直接書く
TransactionTempleteを利用した明示的トランザクション制御
- @ConfigurationクラスにBean定義する際にトランザクションを設定
MEMO: 明示的トランザクションはどちらも使いにくいような印象

3.3.4 トランザクションの分離レベルと伝播レベル

TODO: ★見返して実装に組み込む
トランザクション分離レベル
- TODO: トランザクション分離レベルについて復習すべし
トランザクション伝播レベル
- MEMO: 伝播レベルについて意識したことはなかった
- トランザクション処理が入れ子になったときに初めて意識することになる。
- 通常の処理の場合はデフォルトのRequiredで問題ないような気がする。
- TODO: 逆に入れ子にするパターンってどのような要件が考えられるか確認する
  - →本書に解説があった。
    - 業務ロジックのトランザクションとは別に、ログ出力用の処理でDBアクセスがある場合
    - 業務ロジックでロールバックが発生すると、ログ出力用のデータもロールバックされてしまう。
    - こうならないように、ログ出力用のトランザクションはREQUIRES_NEWで生成しておく必要があるとのこと
    - そもそもDBにログを貯める仕様が良くないのではと思う

3.4 データアクセスエラーのハンドリング

データアクセス処理でエラーが発生した際のハンドリング処理を実装しておく必要がある
Springにおけるデータアクセス例外の抽象化の考えかたを理解した上で、エラーハンドリング処理の実装方法や抽象化のカスタマイズ方法を紹介

3.4.1 Springが提供するデータアクセス例外

DataAccessExceptionを親クラスとするデータアクセス例外の階層構造
- MEMO: かなり多くの種類のエラーが、DataAccessExceptionから切られていることを確認した
非検査例外によるDataAccessExceptionの実装
- DataAccessExceptionはRuntimeExceptionが親クラスなので、例外ハンドリングが強制されてませんよという説明
実装を隠蔽したデータアクセス例外
- DBごとに例外コードが異なるが、Springのデータアクセス機能で共通の例外クラスに変換している
- MEMO: これは画期的ですごい便利だと感じた→当たり前でもあるか..

3.4.2 データアクセス例外のハンドリング

非検査例外のため、ハンドリングを行いたい場所だけcatchする、行いたくない場所は何もする必要が無い
データアクセス例外のハンドリングを行う実装例
- Springが提供している例外でcatchできるようにtry-catchで囲む
- catch後は、プロジェクトの例外を再throwする

3.4.3 データアクセス例外の変換ルールのカスタマイズ

各データベースのエラーコードとデータアクセス例外の対応はspring-jdbc-xxx.jarに含まれるsql-error-codes.xmlに定義されているが、クラスパス直下にsql-error-codes.xmlを配置することでこの定義をカスタマイズすることができる

第4章　Spring MVC

第三章までで得た知識で開発できるのは、データベースにアクセスするスタンドアロンアプリケーション
本章から７章までにかけて、SpringMVCの機能を利用したWebアプリケーションの開発方法について解説
本章
- SpringMVCの特徴を簡単に説明
- シンプルなサンプルアプリケーションを作成しながらSpringMVCの基礎を学ぶ
- SpringMVCのアーキテクチャについて説明

4.1 Spring MVC とは

フレームワークのアーキテクチャとしてMVCパターンを採用している
- TODO: MVC以外のアーキテクチャについて理解を深める
Springは正確に言うと、フロントコントローラパターンを採用しているらしい詳細は4.3SpringMVCのアーキテクチャで解説

4.1.1 Webアプリケーション開発における特徴

SpringMVCはWebアプリケーションをストレスなく快適に開発することができるフレームワークで、次のような特徴がある
- POJO（Plain Old Java Object）での実装
  - フレームワーク独自のインターフェースを実装する必要が無いため、作成するクラスの単体テストのテスタビリティを確保
- アノテーションを使用した定義情報の指定
- 柔軟なメソッドシグネチャの定義
  - Controllerに渡す引数や戻り値も様々な形がサポートされている
- ServletAPIの抽象化
  - ServletAPI（HttpServletRequest,HttpServletResponse,HttpSessionなどのAPI）を抽象化する仕組みを提供
  - テスタビリティを確保
- Viewの実装技術の抽象化
  - コントローラはView名（Viewの論理名）を返却し、SpringMVCのフレームワーク処理が呼び出すViewを決定
  - ControllerはViewの実装技術（Thymeleaf,ServletAPI,FreeMarkerなど）を意識する必要がなくなる
- SpringのDIコンテナとの連携
  - SpringMVCはSpringのDIコンテナ上で動作するフレームワーク
  - DIやAOPなどの仕組みを活用できる
MEMO: この辺は開発で感触をつかめているのですんなり理解できた

4.1.2 MVCフレームワークとしての特徴

豊富な拡張ポイントの提供
- 処理の役割に応じてインターフェースを定義している
エンタープライズアプリケーション向けの機能の提供
- メッセージ管理
- セッション管理
- 国際化
- ファイルアップロードといったエンタープライズアプリケーション向けのWebアプリケーションを開発する際に必要となる機能も提供
サードパーティのライブラリとの連携部品の提供
- ★Jackson(JSON/XML操作) → JSON操作は他に、org.jsonがあるみたいだが、Jacksonの方が良さそう
- Apache Tiles(レイアウトエンジン) → レイアウトを組める。Thymeleafのincludeで十分なので使わない
- FreeMarker(テンプレートエンジン) → 変数を持つ定型文言を作成しておき（*.ftlファイル）
- ★Rome(RSS/Feed操作) → 他に、Informaというのがあるらしい。
- ★JsperReports(帳票出力) → 他にも色々なライブラリがあるみたいだが、一旦これを使用したい
  - https://weblabo.oscasierra.net/java-pdf-lib-2017/
- ★Apache POI(Excel操作)
- ★Hibernate Validator(Bean Validation)
- Joda Time(日付操作) → Java7時代の日付操作
- など
- サードパーティ自体がSpringMVCとの連携部品を提供しているケースもある。
  - Thymeleaf(テンプレートエンジン)
  - ★HDIV(セキュリティ強化)
TODO: ★つけたライブラリーは使用したい

4.2 はじめてのSpring MVCアプリケーション

4.2.1 開発プロジェクトの作成

InteliJ IDEA でプロジェクトを作成することにした
mavenプロジェクトをstartarのアーキタイプで作成
pom.xmlをサンプルアプリに合わせる
- mavenがうまく動かない不具合発生
- 原因: urlがmavenレポジトリを向いていなかったため
  - 結果: 解消しなかった
Intelijだとうまくいかないと判断し、Eclipseで実施
Eclipseでサンプルプログラムを配置
mavenの設定をサンプルに合わせる
javaeeのモジュールがデフォルトで読み込めなくなったみたいなので、pomに定義を入れる
tomcat9サーバーを立ち上げる
context-pathはデフォルトでプロジェクト名？になるみたいなので、http://localhost:8080/firstapp4-2でアクセスするとうまく行った
Web.xmlにjsp-configというものを定義すると、すべてのjspに対してデフォルトでincludeさせることができるみたい
TODO: spring bootで生成したプロジェクトだと、web.xmlが必要ない？そのあたりの仕組みが理解できていない

4.2.2 Spring MVCの適用

4.2.3 トップ画面表示処理の実装

4.2.4 入力画面表示処理の実装

4.2.5 送信処理の実装

4.2.6 入力チェック処理の実装

ここまででサンプルアプリケーションの説明終了
- Controllerクラス
- フォームクラス
- View(JSPなどのテンプレートファイル)
本来であれば、JSPではなくThymeleafとかを使うべきだと思うので、詳細な実装はサラッと流し読み

4.2.7 XMLファイルを使用したBean定義

割愛

4.3 Spring MVCのアーキテクチャ

4.3.1 フレームワークのアーキテクチャ

Spring MVCは「フロントコントローラパターン」と呼ばれるアーキテクチャを採用している
- クライアントからのリクエストをフロントコントローラと呼ばれるコンポーネントが受け取り、リクエストの内容に応じて実行するHandler(Controller)を選択するアーキテクチャ
フロントコントローラが担う処理
- クライアントからのリクエストの受付
- リクエストデータのJavaオブジェクトへの変換
- 入力チェックの実行（Bean Validation）
- Handlerの呼び出し
- Viewの解決
- クライアントへのレスポンスデータの応答
- 例外ハンドリング
TODO: Springフレームワークの全体を把握したときにもう一度見直す

第5章　Webアプリケーションの開発

5.1 Webアプリケーションの種類

SpringMVCは大きく分けて以下の２種類のアプリケーションを作成するための機能を提供
- 画面を応答するアプリケーション
- データのみを応答するアプリケーション（RESTful Webサービス）
メモ
- SpringMVCの仕組みは使用していないが、Spring4.0よりWebSocketの連携モジュールが提供されている
- フロントとサーバーサイドの双方向通信用
- TODO: 使ってみる
Hamdlerメソッド作成
- @RequestMapping()は使用せずに、@GetMapping()を使用する
Handlerメソッドの引数に指定可能な型、アノテーションを紹介
- TODO: 再度確認する
暗黙的な引数の解決！覚えておく
- 引数の型がStringやIntegerといったシンプル型の場合、引数名に一致するリクエストパラメータの値を取得
- 引数の方がJavaBeansだった場合、デフォルトの属性名に一致するオブジェクトをModelから取得する
  - 該当するオブジェクトがModelに存在しない場合、デフォルトコンストラクタを呼び出して新しいオブジェクトを生成
ServletAPI(HttpServletRequest,HttpServletResponse,HttpSession,Partなど)や低レベルのJavaAPI(InputStream,Reader,OutputStream, Writer,Map)なども指定できるが、これらのAPIを自由に使うとメンテナンス性を低下させる可能性があるので、使用しないようにする必要がある
TODO: コーディング規約として利用を制限していくべき！

5.3.5 Handlerメソッドの戻り値

Handlerメソッドは戻り値として様々なオブジェクトを返却できる
メモ
- 返却できるオブジェクトはorg.springframework.web.method.support.HandlerMethodReturnValueHandlerインターフェースの実装クラスを作成することで拡張できる
SpringMVCがサポートしている主な型
- java.lang.String
- Model
- ModelAndView
- void
- ResponseEntity<?>
- HttpHeaders

5.3.6 View Controllerの利用

Viewを呼び出すだけであれば、SpringMVCが提供しているViewControllerの仕組みを利用することができる

5.4 リクエストマッピング

@RequestMappingの属性値を使ってリクエストマッピングの条件を指定する
指定可能な属性
- value
- path
- method
- params
- headers: リクエストヘッダー
- consumes: Content-Typeヘッダー
- produces: Acceptヘッダー
- name
value,pathは複数指定することができる
- or条件として扱われる
パスパターンの使用
- URIテンプレート形式のパスパターン
- 正規表現も使える
- Antスタイルのパスパターン
paramsはメソッドが実行される条件としてパラメータの有無も入る

5.5 リクエストデータの取得

種類
- @PathVariable
- @RequestParam
- @RequestHeader
- リクエストパラメータ値の一括取得

5.5.4 コンパイルオプションの注意点

@PathVariable,@RequestParam,@RequestHeader,@CookieValueのvalue属性を省略する場合、
-gオプションまたはJavaSE8から追加された-parametersオプションのどちらかのコンパイルオプションを有効にしておく必要がある
- TODO: バインドされないとき確認

5.5.7 アノテーションを使用したフォーマットの指定

@org.springframework.format.annotation.DateTimeFormat
@org.springframework.format.annotation.NumberFormat
JSR354 : Money and Currency APIというものがあるらしい
- TODO: 後で確認する

5.6 フォームクラスの実装

5.6.1 フォームオブジェクトのスコープ

スコープの種類
- リクエストスコープ
- フラッシュスコープ：PRGパターンのリクエスト間でオブジェクトを共有するためのスコープ
- セッションスコープ：HttpSessionに格納され、明示的に破棄するまで残り続ける
フラッシュスコープ
- RedirectAttributesのaddFlashAttribute()メソッドを使用して詰める

@RequestMapping(path = "create", method = RequestMethod.POST)
public String create(
  @Validated AccountCreateForm form, BindingResult result,
  RedirectAttributes redirectAttributes) {
    redirectAttributes.addFlashAttribute(form);
    return "redirect:/account/create?complete";
  }

5.6.2 フォームクラスの作成

@Data
public class LoginFormRequestDto implements Serializable {
  private static final long serialVersionUID = 1L;
  private String id;
  private String password;
}

Serializableインターフェスを実装しておく。これが必要なのはオブジェクトをセッションスコープで管理する場合だが、スコープに関係なく定義しておくのが無難

5.7 入力チェック

SpringMVCではBeanValidationの仕組みを利用して、リクエストパラメータ値がバインドされたフォームクラス（またはコマンドクラス）に対して入力チェックを行う

5.7.1 入力チェックの有効化

入力チェックを行う場合、
- 入力チェックを行うメソッドの引数にフォームクラスを定義して、
  - @org.springframework.validation.annotation.Validatedまたは
  - @org.springframework.validation.annotation.Valid を指定する
    - @Validatedを使用すると、BeanValidationのバリデーショングループの仕組みが使用できるらしい

5.7.2 入力チェック結果の判定

BindingResultで処理する

5.7.3 未入力の扱い

未入力は許容するが、入力された場合は６文字移譲であること
- という要件をBeanValidation標準アノテーションを使用して満たすことができない
この場合は、Springが提供しているorg.springframework.beans.propertyeditors.StringTrimerEditorを使用することを検討
TODO: 普通に独自アノテーションを作成した方がシンプルなような気がする

5.7.5 ネスト下JavaBeansの入力チェック

ネストしたJavaBeansやコレクション内のJavaBeansに定義したプロパティに対して入力チェックを行いたい場合は、@Validを指定する
- チェック対象とすることを明示する必要がある
@Validと@Validatedの違い
- http://moondream.hatenablog.com/entry/20131006/1381031027

5.7.6 入力チェックルールの追加

独自の入力チェックツール追加方法２つ
- 既成ルールを合成して作成する方法
- 独自のバリデータを実装して作成する方法
既成ルールを合成して作成する方法
- →こっちは使った方がよい

import static java.lang.annotation.ElementType.*;
import static java.lang.annotation.RetentionPolicy.*;

import java.lang.annotation.Documented;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;

import javax.validation.Constraint;
import javax.validation.Payload;
import javax.validation.ReportAsSingleViolation;
import javax.validation.constraints.Pattern;

@Documented
@Constraint(validatedBy = {})
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
@Retention(RUNTIME)
@ReportAsSingleViolation
@Pattern(regexp = "[a-zA-Z0-9]*")
public @interface AlphaNumeric {

  String message() default "{validation.AlphaNumeric.message}";
  Class<?>[] groups() default {};
  Class<? extends Payload>[] payload() default {};

  @Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
  @Retention(RUNTIME)
  @Documented
  public @interface List {
    AlphaNumeric[] value();
  }

}

メモ TODO: 覚えておく
- 上の例では１つしか既成ルールを使用していないが、既成ルールを複数まとめた合成アノテーションを作成することもできる
  - なお、既成ルールをまとめた合成アノテーションを作成する場合、@ReportAsSingleViolationも付与するのが一般的で、付与すると、message属性で指定したメッセージが利用される用になる。付与しない場合は、既成ルールに指定したメッセージが利用される
独自のバリデータを実装して作成する方法
- →冗長になりがちだと思うので作成しないほうが良いのでは？
  - 相関チェックも実装できそうだが、@AssertTrueを使用したほうがシンプル
@AssertTrueの使用方法
- https://qiita.com/t-iguchi/items/ea3dd8691d52d7abe695

5.7.7 入力チェックツールの切り替え

コントローラーのメソッドでパラメータ指定して、呼び出すメソッドを変更することで実現する例を記載している

5.7.8 エラー情報の表示

<form:errors path="name">
- このように記載することでエラー情報取れますよという説明がある
エラーメッセージ要素の構成案

<div class="error-message d-none">
  <form:errors path="name">
</div>

document.querySelectorAll(".error-message").forEach(el=>{
  if(el.innerText) el.classList.remove("d-none");
})

みたいな感じにすればいいのではなかろうかと

5.7.9 エラーメッセージの解決

エラーメッセージの定義方法
- Springが提供するMessageSourceで読み込んだプロパティファイルにメッセージを定義する
- BeanValidation管理のプロパティファイルにメッセージを定義する
- 制約アノテーションのmessage属性に直接メッセージを定義する
Spring管理プロパティファイル
- 制約アノテーションのクラス名＋「.」＋フォームオブジェクトの属性名＋「.」＋プロパティ名
- 制約アノテーションのクラス名＋「.」＋フォームオブジェクトの属性名
- 制約アノテーションのクラス名＋「.」＋プロパティ名
- 制約アノテーションのクラス名＋「.」＋プロパティの型名（FQCN）
- 制約アノテーションのクラス名
BeanValidation管理のプロパティファイルにエラーメッセージを定義
- クラスパス直下のValidationMessages.propertiesにメッセージを定義する
  - →あまり使用する機会無いのではと思う

5.7.10 BeanValidationのカスタマイズ

java configに設定
- →あまりメリットが理解できなかったのでスキップ

5.7.11 Spring Validatorの利用

割愛

5.8 画面遷移

5.8.1 遷移先の指定方法

View名をHandlerメソッドの戻り値として返却することで実現

5.8.2 リクエストパスへのリダイレクト

View名に「redirect: + リダイレクト先のリクエストパス」
RedirectAttributesを使用してパラメータを設定する
パス変数を指定することもできる

5.8.3 リクエストパスへのフォワード

「forward: + 転送先のリクエストパス」
return "forward:/auth/authenticate";
MEMO: 使い所が知りたい

5.8.4 Viewとのデータ連携

JavaオブジェクトをModelに格納する方法は、以下の２つがある
- ModelのAPIを直接呼び出す
- ModelAttributeアノテーションを付与したメソッドを用意する

5.8.5 リダイレクト先とのデータ連携

RedirectAttributesのフラッシュスコープの説明

5.9 Viewの解決

jspとかいろいろ使えるよ
JSP使うなら、ViewResolverRegistryに登録する必要があるよっていう説明

5.10 JSPの実装

JSP使用しないため割愛

5.11 SpringのHTMLフォーム用タグライブラリの利用

JSP使用しないため割愛

5.12 Springの汎用タグライブラリの利用

Springで使用できるタグについて説明
- MEMO: 必要であれば読み返す
- できるだけthymeleafだけの方が良いのではと思う

5.13 例外ハンドリング

5.13.1 例外の種類

Webアプリケーションで発生する例外は大きく３つある
- システム例外:処理を継続することができない例外
  - アプリケーション自体のバグ
  - 依存ライブラリのバグ
  - ミドルウェアやハードウェアの故障
  - システムリソースの枯渇
  - ネットワーク障害
- リクエスト不正を通知する例外：リクエストの内容が不正なときに発生する例外
  - 存在しないパスへのリクエスト
  - バインディングエラー
  - 入力チェックエラー
- アプリケーション例外：ビジネスルールに違反したときに発生する例外
  - ユーザー登録時のIDの重複エラー
  - 排他エラー
  - 在庫数の不足エラー

5.13.2 例外の発生箇所とハンドリング方法

以下の箇所で例外が発生する可能性があり、それぞれ例外ハンドリングの方法も異なる
- 1. Servlet Fileter
  - サーブレットコンテナへのエラーページ機能（web.xmlの<error-page>要素）を使用してエラー処理を実装する
- 1. DispatcherServlet: SpringMVCが提供する例外ハンドリングの仕組み（HandlerExceptionResolver）
- 1. アプリケーション(Controller, Service, Repositoryなど)：SpringMVCが提供する例外ハンドリングの仕組み（HandlerExceptionResolver）
- 1. View（JSPなど）
  - Viewの中で発生した例外は、サーブレットコンテナのエラーページ機能を使用して絵r-あ処理を実装

5.13.3 サーブレットコンテナのエラーページ機能を利用

web.xmlにerror-pageを記載する方法を紹介

5.13.5 @ExceprtionHandlerメソッドの利用

複数のController間で共通の処理
- @ControllerAdviceを用いる
- https://terasolunaorg.github.io/guideline/5.0.1.RELEASE/ja/ImplementationAtEachLayer/ApplicationLayer.html#id160
@ExceptionHandlerメソッドの引数
- Exception
- HandlerMethod
- java.util.Locale
- java.util.Timezone
- java.time.ZoneId
- java.security.Principal
戻り値について
- String
- ModelAndView
- void
- ResponseEntity<?>

5.13.6 @ResponseStatusを指定した例外クラスの利用

@ResponseStatus(HttpStatus.NOT_FOUND)
public class ResourceNotFoundException extends RuntimeException {
  // *****
}

TODO: 独自Exceptionを作成していくべきかどうか

第6章　RESTful Webサービスの開発

6.1 REST APIのアーキテクチャ

RESTは「REpresentational State Transfer」の略で、クライアントとサーバー間でデータをやり取りするアプリケーションを構築するためのアーキテクチャスタイルの１つ
最も重要なのは「リソース」という概念
REST APIはデータベースなどで管理している情報の中から、クライアントに提供する情報を「リソース」として抽出
抽出したリソースはWeb上に公開し、リソースにアクセスするための手段としてRESTAPIを用意します

6.1.1 Resouce Oriented Architecture (ROA)

6.1.2 フレームワークのアーキテクチャ

割愛 TODO: 詳細を知りたくなったら読む

6.2 アプリケーションの設定

6.2.1 ライブラリのセットアップ

リソース形式としてJSONを使用する際に利用する「FasterXML Jackson Databind」を依存ライブラリに追加する
- MEMO: SpringBootだと不要みたい

6.2.2 サーブレットコンテナの設定

HiddenHttpMethodFilterの適用
- RESTAPIを提供する場合、HTTPメソッドとして、PUT、PATCH、DELETEなども使用するが、
- Webブラウザなどクライアントの実装によっては、GETとPOSTしか使用できなかったりする
- そこをサポートするためにorg.springframework.web.filter.HiddenHttpMethodFileterクラスを利用する
  - _method=putというパラメータでリクエストが送られると、サーブレットコンテナ内で行われる処理はPUTメソッドでアクセスしたときとおなじになる
HttpMessageConverterのカスタマイズ
- MEMO: Converterの設定をしているが、SpringBootだと不要だと思うので飛ばす

6.3 @RestControllerの実装

大きく２つ種類がある
- メソッドシグネチャを参照してフロントコントローラが処理を行う「宣言型」の処理
- Controllerクラスのメソッド内に処理を実装する「プログラミング型」の処理
MEMO: クライアントへ返却するオブジェクトは共通で作成しているもの（クラス）を使用するのが良いと思った
以下、割愛

第7章　Spring MVC の応用

SpringMVCの機能を利用したWebアプリケーションの開発方法を学びましたが、
典型的なWebアプリケーションの開発では、
- セッションの利用
- ファイルアップロード
- 画面やメッセージの国際化
- 共通処理の適用
- 静的リソースのキャッシュ制御　などへの考慮も必要になる
- 非同期処理（SSE(Server-Sent Events)）

7.1 HTTPセッションの利用

セッション管理する方法３つある
- セッション属性（@SessionAttributes）の使用
- セッションスコープのBeanの利用
- HttpSessionのAPIの利用

7.1.1 セッション属性（@SessionAttributes）

１つのController内で扱う複数のリクエスト間でデータを共有する場合に有効な方法
- 入力画面が複数のページで構成される場合や、複雑な画面遷移を伴う場合は@SessionAttributesを使用することを検討
シンプルな画面構成の場合（入力画面→確認画面→完了画面とかの場合）は、HTMLフォームのHiddenで値を持ち回る方法を検討すること

7.1.2 セッションスコープBean

複数のControllerをまたぐ画面遷移において、Controller間でデータを共有する場合に有効な方法

7.2 ファイルアップロード

SpringMVCでファイルをアップロードする場合は、以下のいずれかの方法を利用する
- Servlet標準のアップロード機能
- ApacheCommonsFileUploadのアップロード機能

7.2.2 ファイルアップロード機能のセットアップ

web.xmlに<multipart-config />を追加するとのこと
Servlet標準のファイルアップロード機能をデフォルトのまま利用するとアップロードできるファイルのサイズに上限がないため、上限を設けたい場合は、ファイル単位の最大サイズ、アップロード時のリクエスト全体の最大サイズ、一時ファイル出力有無の閾値サイズの３つを指定する必要がある
上限に引っかかると、MultipartExceptionが発生するので、Handlerでハンドリングすること
メモ
- SpringMVCのDispatcherServletより前にリクエストパラメータにアクセスする処理があると、MultipartExceptionが発生しない可能性がある
- SpringWEBから提供されているフィルターを利用すると制御できるとのこと
  - TODO: SpringBootだとどのように記載するか確認

7.2.3 アップロードデータの取得

Formクラスの作成
- 普通にFormクラスの作成 MultipartFile型で変数定義する
Viewの作成
- input type="file"で作成して送るだけ
Controller
- ファイルを取得して永続化操作
Validation
- ファイルサイズや、コンテンツタイプ、ファイル名などをチェックする場合は、Validatorを作成してチェック
TODO: 実際にアイコン画像などをDBで保持できる永続化ロジックまで書く

7.3 非同期リクエスト

7.3.1 非同期リクエストの仕組み

非同期実行が終了してからHTTPレスポンスを開始
- 勘違いしやすいのが、HTTPレスポンスは非同期実行している処理が終了したあとに行うため、クライアント側から見ると、同期処理と同じ動作になる
SpringMVCはこのパターンの非同期処理をサポートするために以下の２つの方法を提供
- SpringMVC管理のスレッドを使用した非同期処理
- SpringMVC管理外のスレッドを使用した非同期処理
非同期実行の処理中にHTTPレスポンスを開始
- ロングポーリングを使用した非同期処理
- SSE（Server-Sent Events）に準拠した非同期処理

7.3.2 非同期実行を有効にするための設定

web.xmlに設定追記
java configにBean定義追加

7.3.3 非同期処理の実装

以下の２つの非同期処理の実装方法を紹介
- CompletableFutureを使用した非同期処理
- SseEmitterを使用したPush型の非同期処理
@Asyncの利用
- 本書で説明する非同期処理は、どちらもSpringMVC管理外のスレッドを使用した非同期処理
- SpringFrameworkは、特定のメソッドを別スレッドで実行する仕組みを提供しており、別スレッドで実行したいメソッドに、org.springframework.scheduling.annotation.Asyncを付与するだけ
MEMO: SpringBootでの利用に参考
- https://qiita.com/mitsuya/items/c21907ab10919111e773
CompletableFutureを使用した非同期処理の実装
- CoompletableFuture<String>を返却する
SseEmitterを使用したPush型の非同期処理の実装
- new SseEmitter();でイベント処理を行う
  - 具体的な使用方法について説明なし

7.3.4 非同期実行の例外ハンドリング

DeferredResultを使用して結果を設定する
TODO: 結果を非同期で画面に通知する方法確認

7.3.5 非同期実行に対する共通処理の実装

CallableProcessingInterceptorもしくはDeferredResultProcessingInterceptorのAdopterを実装したクラスを作成
現在は、interfaceにデフォルトメソッドが定義できるようになったので、Adopterではなくて、interfaceの方を使用すべきとのことで、@Deprecatedになっている
CallableProcessingInterceptorインターフェース

7.4 共通処理の実装

ControllerのHandlerメソッドの呼び出し前後に共通処理を実行する方法について説明します。

7.4.1 サーブレットフィルタの利用

SpringMVCの呼び出し前後に共通する処理を実行するには、javax.servlet.Filterインターフェースの実装クラスを作成する
Filterクラスを直接実装してもよいが、ここではSpringが提供しているサポートクラスを利用する方法を紹介
サポートクラス
- GenericFilterBeanクラス
- OncePerRequestFilterクラス
DIコンテナで管理しているBeanのインジェクション方法
- サーブレットフィルター内の処理でDIコンテナ管理しているBeanを利用したい場合は、サーブレットフィルタをDIコンテナに登録し、DelegatingFilterProxy経由でサーブレットフィルタの処理を実行する
- DelegatingFilterProxyは、SpringのDIコンテナに登録されているサーブレットフィルターに処理を移譲するサーブレットフィルタクラス

7.4.2 HandlerInterceptorの利用

Controllerでハンドリングする処理に対してだけ共通処理を実行したい場合は、
- org.springframework.web.servlet.HndlerInterceptorインターフェースの実装クラスを作成する
メソッド
- preHandle：実行前
- postHandle：例外時は呼び出されない
- afterCompletion：実行後

@Slf4j
public class LoggingInterceptor extends HandlerInterceptorAdapter {

  public void postHandler(HttpServletRequest request, HttpServletResponse response, Object handler,
      ModelAndView modelAndView) {
    if (log.isInfoEnabled()) {
      HandlerMethod handlerMethod = (HandlerMethod) handler;
      Method method = ((HandlerMethod) handler).getMethod();
      log.info("[SUCCESS CONTROLLER] {}.{}", method.getDeclaringClass().getSimpleName(), method.getName());
    }

  }
}

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LoggingInterceptor())
                .addPathPatterns("/**")
                .excludePathPatterns("/resources/**");
    }

7.4.3 @ControllerAdviceの利用

Controllerクラスには、Handlerメソッドとは別に、Controller専用の特殊なメソッド（@InitBinderメソッド、@ModelAttributeメソッド、@ExceptionHandlerメソッド）を実装することができる
これらのメソッドを複数のControllerクラスで共有するには、@ControllerAdviceを付与したクラスを作成する

@Slf4j
@ControllerAdvice
public class ErrorController {

  @GetMapping("/error")
  public String handleError() {
    return "error";
  }

  @ExceptionHandler(Throwable.class)
  public String handleThrowable(Throwable exception, Model model) {
    model.addAttribute("", "");
    return "error";
  }

  @ExceptionHandler(Exception.class)
  public String handleException(Exception exception, Model model) {
    model.addAttribute("", "");
    return "error";
  }

  @ExceptionHandler(IOException.class)
  public String handleIOException(IOException exception, Model model) {
    model.addAttribute("", "");
    return "error";
  }
}

7.4.4 HandlerMethodArgumentResolverの利用

SpringMVCのデフォルトでサポートされていないオブジェクトをControllerのHandlerメソッドの引数に渡したい場合は、org.springframework.web.method.support.HandlerMethodArgumentResolverインターフェースの実装クラスを作成します。
あまり利用するシーンがわからないため割愛する

7.5 静的リソース

ルートから任意のディレクトリに配置した静的リソースにアクセスできますという説明

7.5.1 デフォルトサーブレットとDispatcherServletの共存

Servletの使用では、ルートパス（）にマッピングされたサーブレットのことを「デフォルトサーブレット」と呼び、デフォルトサーブレット経由でWebアプリケーションのドキュメントルート配下のファイルにアクセスすることができる
SpringMVCアプリケーションでは、DispatcherServletをルートパスにマッピングするスタイルを採用することがよくあるが、DispatcherServletをルートパスにマッピングすると、Webアプリケーションのドキュメントルート配下のファイルにアクセスできなくなってしまいます。
この動作を変更するには、SpringMVCが提供している「DispatcherServletで受けたリクエストをデフォルトサーブレットへ転送する機能」を有効化する必要がある

7.5.2 SpringMVC独自の静的リソース解決の仕組み

HTTPのキャッシュ制御
ResourceResolverとResouceTransformerの利用
- ResourceHttpRequestHandlerには
  - バージョン付き公開パスを使用した静的リソースへのアクセス
  - Gzip化された静的リソースへのアクセス
  - WebJars内の静的リソースのバージョン番号の隠蔽
    - を行う機能がある
ResourceResolverインターフェース
- 静的リソースにアクセスするための公開パス
- サーバー上の物理的な静的リソースを相互に解決するためのメソッドを提供
ResourceTransformerインターフェース
- 静的リソースのコンテンツデータを書き換えるためのメソッドを提供
バージョン付きの公開パスを使用した静的リソースへのアクセス
Thymeleafでのアクセス方法について確認する
- ここで紹介されていたhttps://ksoichiro.blogspot.com/2015/04/spring-boot_14.html
- th:href="@{/css/main.css}"などと記載する

7.6 国際化

7.6.1 ロケールの解決

アプリケーション内で扱うロケール解決には、org.springframework.web.servlet.LocaleResolverインターフェースを使用する
SpringMVCは、ロケールの保存場所に応じて以下の実装クラスを提供しており、デフォルトではAcceptHeaderLocaleResolverが有効になっている
提供されているLocaleResolverの実装クラス
- AcceptHeaderLocaleResolver
- SessionLocaleResolver
- CookieLocaleResolver
- FixedLocaleResolver
クライアントからロケールの指定がない場合、デフォルトロケールが利用され、
- LocaleResolverに指定したデフォルトロケール
- JVMに指定したロケール
- OSに指定したロケール
  - の順番で解決されます。

7.6.2 ロケールの利用

VIEWからロケールにアクセスするときはSpringのタグを使用する
Handlerメソッドからロケールにアクセスするときは引数にLocaleを指定する
Handler以外の場所からロケールにアクセスするときは、RequestContextUtilsのgetLocaleメソッドを使用する

7.6.3 UIを使用したロケールの切り替え

画面などのUIを使用してロケールを切り替える方法について説明
ロケールの切り替えは、org.springframework.web.servlet.i18n.LocaleChangeInterceptorを利用することで簡単に行うことができる
LocaleResolverのBean定義
LocaleChangeInterceptorのBean定義
ロケール切り替え用の画面要素の表示

<a href="?locale=en">English</a>
<a href="?locale=ja">Japanese</a>

このリンクをクリクすると、LocaleChangeInterceptorが呼び出され、リクエストパラメータで指定されたロケールがSpringMVCアプリケーションに反映される

第8章　Spring Test

本章では、SpringFrameworkが提供するテスト支援モジュールを利用して、Springアプリケーションに対してテストを行う方法について解説していく
紹介を行うテスト
- DIコンテナに登録したBeanへのテスト
- データベースアクセスを伴う処理へのテスト
- SpringMVC上で動くControllerへのテスト
第９章では、SpringSecurityの機能を利用した処理へのテストを紹介

8.1 Spring Testとは

Spring Testとは
- Spring Framework上で動かすために作成したクラスのテストを支援するモジュール
単体テスト
- テスト対象のクラス内で実装しているロジックのみをテスト
- 単体テストを行う際には、テスト対象のクラスの中で依存している他のコンポーネントはモックやスタブを使用し、実行結果が他のコンポーネントの実装内容に左右されないようにする
結合テスト
- 基本的にモックやスタブは使わず、プロダクション環境で使用するクラスを結合してテストを行います。
- ポイントは、システムやアプリケーション全体が正しく動作するかを検証するのではなく、開発者が作成したクラスがSpringのフレームワーク上で正しく動作するかをテストするという点
提供されている機能
- JUnitやTestNGといったテスティングフレームワーク上でのSpringのDIコンテナを動かす機能
- トランザクション制御をテスト向けに最適化する機能
- アプリケーションサーバーを使わずにSpringMVCの動作を再現する機能
- テストデータをセットアップするためのSQLを実行する機能
- RestTemplateを使用したHTTP通信に対してモックレスポンスを返却する機能

8.2 DIコンテナ管理のBeanに対するテスト

junitを使用する前提で説明

8.2.1 Beanの単体テスト

Serviceクラスをテスト
依存しているコンポーネントはできるだけモック化することを検討する
- 外部ファイル参照サービスやDBアクセスなど

8.2.2 DIコンテナ内のBeanに対する結合テスト

Springの機能を使用して、DIコンテナ内のリソースを取得してテストを行う
単体テストは本当にクラス単体の観点なのに対して、結合テストはプロジェクト内のリソースを結合したテストとみなしている

8.2.3 Spring Testcontext Framework

他のランナーとSpringを併用したい場合は、@ClassRuleと@Ruleを使用すれば実現できるという説明
TODO: 使用するランナーによって何が違うのかを後で確認する必要ある

8.2.4 DIコンテナのコンフィギュレーション

DIコンテナを作成するには、 @org.springframework.test.context.ContextConfigurationをテストクラスケースに付与する

デフォルトのBean定義ファ入りう
Webアプリケーション向けのDIコンテナのコンフィギュレーション
- @WebApplicationConfiguration付与について説明
  - Webアプリケーション向けのDIコンテナに加えて、
  - ServletAPIに依存する各種モックオブジェクトなどをテストケースクラスにインジェクションできる

8.2.5 DIコンテナのライフサイクル制御

Spring TestContext Framework上に生成されたDIコンテナは、テスト実行時のJavaVMが終了するまでキャッシュされ、必要に応じてテストケース間で共有される仕組みになっています。
DIコンテナのキャッシュ
- デフォルトの動作では、同一テストケースクラスのテストメソッドで同じDIコンテナが使われる
- さらにテストケースクラスが別の場合でも、@ContextConfigurationなどに指定した属性値が同じであれば、キャッシュ済みのDIコンテナが利用される
DIコンテナの破棄
- 割愛...TODO: 実際のテストケースの組み方について調査する必要あり

8.2.6 プロファイルの指定

Springのプロファイル機能を使用しているアプリケーションに対してテストを行う場合は、@org.springframework.test.context.ActiveProfilesを使う

8.2.7 テスト用のプロパティ値の指定

テスト用のプロパティ値を設定できる
- @org.springframework.test.context.TestPropertySourceを使う
プロパティ値の指定には２つの方法がある
- アノテーションに直接指定する
- プロパティファイルに指定する

8.3 データベースアクセスを伴う処理のテスト

データベースへアクセスするBeanに対するテスト方法について説明
データベースにアクセスするBeanに対してテストを行う場合、以下の作業が必要になる
- テスト用のデータソースの設定
- テストデータのセットアップ
- テストケース用のトランザクション制御
- テーブルの中身の検証

8.3.1 テスト用のデータソースの設定

Test用のConfigクラスを作成して、既存のコンフィグクラスを上書きする説明

8.3.2 テストデータのセットアップ

@Sqlを使用すると、テストケース・メソッドの呼び出し前に任意のSLQを実行できる

  /**
   * Sqlを付与することで、テストメソッド実行前に任意のSQL文を実行することができる
   */
  @Test
  @Sql({ "/account-delete.sql", "/account-insert-data.sql" })
  final void testFindOne() {
    Account account = accountRepositry.findOne("001");
  }

メモ
- @SqlにはJavaSE8で追加された@Repeatableが付与されているため、JavaSE8以降を使う場合は同じ箇所に複数指定できる
  - JavaSE7以前のJavaでも、@org.springframework.test.context.jdbc.SqlGroupを使うことで、複数のSQLを指定できる

8.3.3 テストケース用のトランザクション制御

デフォルトではテストデータをセットアップする際に使用するトランザクションと、
テスト対象のデータアクセス処理で使用するトランザクションは別々になってしまう
テストが途中で失敗して、レコードが更新されてしまったり、データの状態が変わってしまうため注意が必要
このような事故を防ぐには、JUnit専用のデータベースを用意しておくと確実
ローカルなんかも優位だと思う
あるいは、SpringTestが提供しているテスト用のトランザクション制御の仕組みを利用して防ぐこともできる
トランザクション境界の移動
- SpringTestでは、、JUnit実行時のトランザクション境界を、テストケースメソッドの呼び出し前に移動する仕組みを提供している。
- この仕組を利用すると、@Sqlで指定したSQLファイルの実行とテストを同一のトランザクション内で行うことができる
- @Transactionalをクラス、メソッドに指定する
トランザクション境界でのロールバック/コミットの制御
- 処理が完了したあと、ロールバックするのではなくコミットしたい場合、@Commitを付与すれば実現できる
永続コンテキストをフラッシュ
- JPAやHibernateがEntityへの更新操作を永続コンテキストと呼ばれるインメモリ領域に蓄積しておき、トランザクションのコミット時にSQLを発行する仕組みになっているため、明示的にSQLが発行されるようにフラッシュする必要がある

8.3.4 テーブルの中身の検証

JdbcTemplateを使用して検証する
DIコンテナに入っている同じオブジェクトを使用すること

8.4 Spring MVC のテスト

SpringMVC上で動くControllerに対するテスト方法について説明
Controllerに対するテストの話をするときにいつも出てくる話題がある
- →「Controllerに対する単体テストは必要か？」という話題
Controllerの主な役割は、
- リクエストマッピング
- 入力チェック
- リクエストデータの取得
- ビジネスロジックの呼び出し
- 遷移先の制御
これらは、SpringMVCのフレームワークと結合しないと妥当性を検証することができないので、単体テストではなく、結合テストとして行ったほうがよい
では、SpringMVCのフレームワーク機能と結合した状態でControllerをテストするにはどうすればよいのでしょうか？
最もオーソドックスな選択肢は、Webアプリケーションをアプリケーションサーバーにデプロイし、E2E（End to End）テストとして実施する方法
E2Eテストとして実施すると、Viewが生成したレスポンスデータの妥当性を検証できるのがメリット
一方、以下のようなデメリットがある
- アプリケーションサーバーやデータベースの起動が必須となる
- トランザクションがコミットされるため、テスト実施前の状態に戻すことができない
- 回帰テストを実行するために、Seleniumなどを利用したテストケースの実装が必要になる
- Seleniumを使うと、テストの実行時間が長くなる
SpringTestはE2Eテストのデメリットを解消しつつ、SpringMVCのフレームワーク機能と結合した状態でControllerをテストするためのプラットフォームとして、org.springframework.test.web.servlet.MockMvcというクラスを提供している

8.4.1 MockMvcとは

アプリケーションサーバー上にデプロイせず、SpringMVCの動作を再現する仕組みを提供するクラス
流れ
1. テストケース・メソッドは、DispatcherServletにリクエストするデータ（リクエストパスやリクエストパラメータなど）をセットアップする
2. MockMvcは、DispatcherServletに対して擬似的なリクエストを行う。実際に使われるDispatcherServletは、テスト用に拡張されている、org.springframework.test.web.servlet.TestDipacherSevletとなる
3. DispatcherServletは、リクエスト内容に一致するHandlerのメソッドを呼び出す
4. テストケースメソッドは、MockMvcが返却する実行結果を受け取り、実行結果の妥当性を検証する
動作モードには２つある
- ユーザー指定のDIコンテナと連携するモード
- スタンドアロンモード
SpringMVCのコンフィギュレーションも含めてテストしたい場合、ユーザー指定のDIコンテナと連携するモードを利用すること
メモ
- 本書では扱わないが、SpringTestは、MockMvcとHtmlUnitを連携する機能も提供している
- HtmlUnitと連携することで、テンプレートエンジンが生成したHTMLを検証することができる
- さらに、SeleniumWebDriverやGebと連携すると、Page Object Patternを活用した可読性および再利用性の高いテストケースを記載することも可能
- TODO: あとで確認してみる

8.4.2 MockMvcのセットアップ

ユーザー指定のDIコンテナと連携するモード
スタンドアロンモード
- SpringMVCのコンフィギュレーションはSpringTest側が行い、SpringTestが生成したDIコンテナを使用してSpringMVCの動作を再現
サーブレットフィルタの追加
- MockMvcには、サーブレットフィルタを追加することができる
staticメソッドのインポート
- テストを書く前に、MockMvcを使用したテストをサポートしてくれるstaticメソッドをインポートします。

// よく使用するstaticメソッド
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;
import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.*;

8.4.3 テストの実行

テストを実行する際は、Controllerを呼び出すために必要なリクエストデータをセットアップし、MockMvcにリクエストの実行依頼を行います。

  public void testHome() throws Exception {
    mockMvc.perform(get("/"))
        .andExpect(status().isOk())
        .andExpect(forwardedUrl("/WEB-INF/index.jsp"));
  }

8.4.4 リクエストデータのセットアップ

リクエストデータのセットアップは、
- org.springframework.test.web.servlet.request.MockHttpServletRequestBuilder
- org.springframework.test.web.servlet.request.MockMultipartHttpServletRequestBuilder
- のファクトリメソッドを使用して行います。

  @Test
  public void testBooks() throws Exception {
    mockMvc.perform(get("/books")
        .param("name", "Spring")
        .accept(MediaType.APPLICATION_JSON)
        .header("X-Track-Id", UUID.randomUUID().toString()))
        .andExpect(status().isOk());
  }

8.4.5 実行結果の検証

MockMvcResultMathcersの主なメソッド
- status
- header
- cookie
- content
- view
- forwardedUrl
- redirectedUrl
- model
- flash
- request
メモ
- ResultMatcherでサポートされていない検証を行いたい場合は、以下のいずれかの方法で検証ロジックを実装する
  - 独自のResultMatcherを作成する
  - ResultActionsのandReturnメソッドを呼び出して、MvcResultを取得し、テストケース内で検証ロジックを実装する
- MEMO: 検証ロジックを複数のテストケースで共有したい場合は、ResultMatcherを作成すること

8.4.6 実行結果の出力

実行結果をログなどに出力する場合は、org.springframework.test.web.servlet.ResultActionsのandDoメソッドを使用する
andDoメソッドの引数には、実行結果に対して、任意の処理を行うorg.springframewok.test.web.servlet.ResultHandlerを指定する

    mockMvc.perform(get("/books"))
        .andExpect(status().isOk())
        .andDo(log());

log: 実行結果をデバッグレベルでログ出力する
pring: 実行結果を任意の出力先に出力する

第9章　Spring Security

SpringSecurityの「セットアップ方法」と「アーキテクチャ」について説明したあと、
セキュリティ対策の基本となる
- 「認証」と「認可」、
さらにセキュリティを強化するために必要となる
- 「CSRF対策」
- 「セッション管理」
- 「ブラウザのセキュリティ対策機能との連携（セキュリティヘッダーの出力）」について説明
最後に、SpringSecurityが提供する支援モジュールを使用して、セキュリティ対策が正しく適用されているかをテストする方法についても紹介

9.1 SpringSecurityとは

アプリケーションにセキュリティ対策機能を実装する際に使用するフレームワーク

9.1.1 SpringSecurityの特徴

豊富なオプションの提供
- SpringSecurityのデフォルト実装の動作をカスタマイズするためのオプションが豊富に提供されている
- このため、デフォルトの動作がセキュリティ要件に合致しない場合であっても、オプションの値を変更することで要件にあった動作に変更できるケースがある
豊富な拡張ポイントの提供
- SpringSecurityは動作をカスタマイズするための拡張ポイントを豊富に提供します。
- SpringSecurityのデフォルト実装を使って要件を満たせない場合は、拡張クラスを作成することで要件にあった動作にカスタマイズすることができます。

9.1.2 基本機能

セキュリティ対策の基本機能として「認証機能」と「認可機能」の２つを提供しています。
認証機能：アプリケーションを利用するユーザーの正当性を確認する機能を提供する
認可機能：アプリケーションが提供するリソースや処理に対するアクセスを制御する機能を提供する

9.1.3 強化機能

SpringSecurityでは認証と認可という基本機能に加え、
Webアプリケーションのセキュリティを強化するための機能をいくつか提供している
セキュリティ対策の強化機能
- セッション管理機能
- CSRF対策機能
- ブラウザのセキュリティ対策機能との連携機能
- ※他にある！TODO: 他のセキュリティ機能も確認しておく

9.2 Spring Securityのセットアップ

9.2.1 ライブラリのセットアップ

pom.xmlに設定を追加する手順の説明

9.2.2 SpringSecurityのBean定義

SpringSecurityのコンポーネントをBean定義します

コンフィギュレーションクラスの作成

// SpringSecurityが提供しているコンフィギュレーションクラスがインポートされ、SpringSecurityを利用するために必要となるコンポーネントのBean定義が自動で行われる仕組み
@EnableWebSecurity
public class AppSecurityConfig extends WebSecurityConfigurerAdapter { // 継承すると、デフォルトで適用されるBean定義を簡単にカスタマイズすることができる

  @Override
  public void configure(WebSecurity web) {
    // セキュリティ対策が不要なリソースがある場合、SpringSecurityの処理を適用しないようにする
    web.ignoring().antMatchers("/resources/**");
  }
}

web.xmlへの設定追加方法説明
- TODO: SpringBootだと必要？

9.2.3 サーブレットフィルタの設定

最後に、SpringSecurityが提供しているサーブレットフィルタクラス（FilterChainProxy）をサーブレットコンテナに登録する
TODO: SpringBootだとConfigでフィルター追加する
- https://qiita.com/R-STYLE/items/61a3b6a678cb0ff00edf
- https://qiita.com/opengl-8080/items/c105152c9ca48509bd0c
メモ
- Sevlet3.0以降のサーブレットコンテナでは、サーブレットコンテナの初期化処理をJavaのコードで行うことができる
- SpringSecurityでは、サーブレットコンテナの初期化処理をJavaを使って行うためのサポートクラス説いて、
- AbstractSecurityWebApplicationInitializerという抽象クラスを提供しています
- 以下の初期化処理を自動で行ってくれる
  - ContextLoaderListenerをサーブレットコンテナに登録する処理
  - SpringSecurityのサーブレットフィルタクラスをサーブレットコンテナに登録する処理
  - 参考：https://qiita.com/opengl-8080/items/c105152c9ca48509bd0c

9.3 Spring Security のアーキテクチャ

各機能の詳細な説明を行う前に、SpringSecurityのアーキテクチャ概要とSpringSecurityを構成する主要なコンポーネントの役割を見ていく
メモ
- ここで紹介する内容は、SpringSecurityが提供するデフォルトの動作をそのまま利用する場合や、
- SpringSecurityのコンフィギュレーションをサポートする仕組みを利用する場合は、開発者が直接意識する必要ない
- そのため、まず各機能の使い方を知りたい場合は、本説を読み飛ばしてOK
- カスタマイズする際に必要になってくるので、アーキテクトを目指す方は一読しておくことをおすすめします。

9.3.1 Spring Securityのモジュール構成

提供しているモジュールを紹介
コンポーネントの役割などに応じてモジュール分割されており、標準的なWebアプリケーションに対してセキュリティ対策を講じる際に必要となるモジュールは以下の４つになる
- spring-security-core: 認証と認可機能を実現するためのコアなコンポーネントが格納されている
- spring-security-web: Webアプリケーションのセキュリティ対策を実現するためのコンポーネントが格納されている
- spring-security-config: 各モジュールから提供されているコンポーネントのセットアップをサポートするためのコンポーネント（Java ConfigをサポートするクラスやXMLネームスペースを解析するクラスなど）が格納されている
- spring-security-taglibs: 認証情報や認可機能にアクセスするためのJSPタグライブラリが格納されている
本書で使い方を紹介しないが、上記以外にも以下のようなモジュールがある
- 一般的に利用される認証方法（LDAP、OpenID、CASなど）をサポートするためのモジュール
- ACL（AccessControlList）を使用したドメインオブジェクトの認可制御を行うモジュール
- SpringのWebSocket機能に対してセキュリティ対策を追加するためのモジュール
- SpringSecurityの機能を用いる処理に対するテストを支援するためのモジュール
メモ
- SpringSecurityのモジュールではないが、OAuth2.0の仕組みを使用してAPIの認可を実現するためのモジュール（spring-security-oauth2）などが姉妹ライブラリとして提供されている

9.3.2 フレームワークのアーキテクチャ

処理の流れ
1. クライアントはWebアプリケーションに対してリクエストを送る
2. SpringSecurityのFilterChainProxyクラスがリクエストを受け取り、HttpFirewallインターフェースのメソッドを呼び出して、HttpServletRequestとHttpServletResponseに対してファイアウォール機能を組み込む
3. FilterChainProxyクラスはSecurityFilterChainに設定されているセキュリティ対策用のSecurityFilterクラスに処理を移譲する
4. SecurityFilterChainには複数のSecurityFilterが設定されており、SecurityFilterの処理が正常に終了すると皇族のSecurityFilterが呼び出される
5. 最後のSecurityFilterの処理が正常に終了した場合、後続処理を呼び出し、Webアプリケーション内のリソースへアクセスする
6. FilterChainProxyクラスは、Webアプリケーションから返却されたリソースをクライアントに返却する
FilterChainProxy
- FilterChainProxyクラスは、フレームワーク処理のエントリーポイントとなるサーブレットフィルタクラス
- このクラスはフレームワーク処理の全体の流れを制御し、具体的なセキュリティ対策処理はSecurityFilterに移譲するスタイルとなっている
HttpFirewall
- HttpFirewallインターフェースは、HttpServletRequestとHttpServletResponseに対して、ファイアウォール機能を組み込むためのインターフェースです。デフォルトでは、DefaultHttpFirewallクラスが使用され、ディレクトリトラバーサル攻撃や、不正なリダイレクト先の指定によるHTTPレスポンス分割攻撃に対するチェックなどが実装されている
SecurityFilterChain
- SecurityFilterChainインターフェースは、FilterChainProxyが受け取ったリクエストに対して適用する「SecurityFilterリスト」を管理するためのインターフェース
- デフォルトではDefaultSecurityFilterChainクラスが使用され、以下のようなBean定義を行うと、指定したパスパターンごとに異なるセキュリティ対策が適用できます。
Security Filter
- SecurityFilterクラスは、フレームワーク機能やセキュリティ対策機能を提供するサーブレットフィルタクラスです。
- SpringSecurityは、複数のSecurityFilterを連鎖させることで、Webアプリケーションのセキュリティ対策を行う仕組みになっています。
コアなSecurityFilter
- SecurityContextPersistenceFilter
- UsernamePasswordAuthenticationFilter
- LogoutFilter
- FilterSecurityInterceptor
- ExceptionTranslationFilter

9.4 認証処理の適用

認証処理は、アプリケーションを利用するユーザーの正当性を確認するための処理
最も標準的な方法はアプリケーションを使用できるユーザーをデータストアに登録しておいて、利用者が入力した認証情報と照合する方法
利用者に認証情報を入力してもらう方式もいくつかあり、
- HTMLの入力フォームを使う方式
- RFCで定められているHTTP標準の認証方式（BASIC認証やDigest認証など）を利用するのが一般的
- OpenID認証、シングルサインオン認証などの認証方式を利用するケースもある
本節では、HTMLの入力フォームで入力した認証情報とリレーショナルデータベースに格納されているユーザー情報を照合して認証処理を行う実装例を紹介しながら、SpringSecurityの認証機能を解説

9.4.1 認証処理の仕組み

認証処理の流れ
1. クライントは認証処理を行うパスに対して資格情報（ユーザー名とパスワード）を指定してリクエストを送信する
2. Authentication Filterはリクエストから資格情報を取得し、AuthenticationManagerクラスの認証処理を呼び出す
3. ProviderManager（デフォルトで使用されるAuthenticationManagerの実装クラス）は、実際の認証処理をAuthenticationProviderインターフェースの実装クラスに移譲する
メモ
- Authentication FilterとAuthenticationProviderの実装クラスは複数用意されており、要件に合わせて使用するクラスを選択する仕組みになっている
- TODO: 選択できるクラスについて確認
Authentication Filter
- 認証方式に対する実装を提供するサーブレットフィルタ
- 本書では、フォーム認証用のサーブレットフィルタクラス（UsernamePasswordAuthenticationFilter）をシヨすうる前提で説明しますが、SpringSecurityはBasic認証、Digest認証、Remember Me 認証用のサーブレットフィルタクラスも提供しています
AuthenticationManager
- 認証処理を実行するためのインターフェース
- SpringSecurityが提供するデフォルトの実装（ProviderManager）では、実際の認証処理はAuthenticationProviderに移譲し、AuthenticationProviderで行われた認証処理結果をハンドリングする仕組みになっています。
AuthenticationProvider
- 認証処理の実装をて依拠するためのインターフェース
- 本書では、データストアに登録しているユーザーの資格情報とユーザーの状態をチェックして認証処理を行う実装クラス（DaoAuthenticationProvider）を使用する前提で説明しますが、SpringSecurityは認証方法別の実装クラスも提供している。
  - ※DBだけでなく他の認証方式にも対応しているという意味だと理解

9.4.2 フォーム認証

SpringSecurityは以下のような流れでフォーム認証を行う
1. クライアントは、フォーム認証を行うパスに対して資格情報（ユーザー名とパスワード）をリクエストパラメータとして送信する
2. UsernamePasswordAuthenticationFilterクラスは、リクエストパラメータから資格情報を取得して、AuthenticationManagerの認証処理を呼び出す
3. UsernamePasswordAuthenticationFilterクラスは、AuthenticationManagerから返却された認証結果をハンドリングする。認証処理が成功した場合は、AuthenticationSuccessHandlerのメソッドを、認証処理が失敗した場合は、AuthenticationFailureHandlerのメソッドを呼び出し、画面遷移を行う
フォーム認証の適用
- Bean定義

// SpringSecurityが提供しているコンフィギュレーションクラスがインポートされ、SpringSecurityを利用するために必要となるコンポーネントのBean定義が自動で行われる仕組み
@EnableWebSecurity
public class AppSecurityConfig extends WebSecurityConfigurerAdapter { // 継承すると、デフォルトで適用されるBean定義を簡単にカスタマイズすることができる

  @Override
  public void configure(WebSecurity web) {
    // セキュリティ対策が不要なリソースがある場合、SpringSecurityの処理を適用しないようにする
    web.ignoring().antMatchers("/resources/**");
  }

  // ★追加！！
  @Override
  public void configure(HttpSecurity http) throws Exception {
    http.formLogin();
    // formLoginメソッドを呼び出すと、フォーム認証が有効になり、FormLoginConfigurerのインスタンスが返却される。
  }
}

デフォルトの動作
- SpringSecurityのデフォルトの動作では、/loginに対して、GETメソッドでアクセスするとSpringSecurityが用意しているデフォルトのログインフォームが表示され、ログインボタンを謳歌すると/loginに対してPOSTメソッドでアクセスして認証処理を行います。
ログインフォームの作成
- SpringSecurityは、フォーム認証用のログインフォームをデフォルトで提供しているが、そのまま利用するケースは殆どないと思う
- ここでは、自身で作成したログインフォームをSpringSecurityに適用する方法を紹介する
- まず、ログインフォームを表示するためのJSPを作成
- ここでは、SpringMVCのViewResolverに指定しているベースパス（src/main/webapp/views/）の直下にJSPを配置し、SpringMVC経由でログインフォームを表示する前提で説明
ログインフォームをSpringSecurityに適用するために以下のようなBean定義を行う
1. loginPageメソッドを呼び出し、ログインフォームを表示するためのパスを指定する
  - 匿名のユーザーが認証を必要するリソースにアクセスした場合、ここで指定したパスにリダイレクトしてログインフォームを表示する仕組みになっている。loginPageメソッドに与えられた引数によって、認証パス（loginProcessingUrl）も連動して変わる
2. permitAll()メソッドを呼び出して、すべてのユーザーに対してログインフォームへのアクセス件を付与する

  @Override
  public void configure(HttpSecurity http) throws Exception {
    //    http.addFilter(this.preAuthenticatedProcessingFilter());
    //    http.formLogin();
    http.formLogin()
        .loginPage("/login") // 認証を必要とするURLに遷移した場合、このURLにリダイレクトしてログインフォームを表示する仕組み
        .permitAll(); // すべてのユーザーに対してログインフォームへのアクセス件を付与する
    http.authorizeRequests()
        .anyRequest()
        .authenticated();
    // formLoginメソッドを呼び出すと、フォーム認証が有効になり、FormLoginConfigurerのインスタンスが返却される。
  }

デフォルト動作のカスタマイズ
- フォーム認証処理のカスタマイズポイントとして
  - 認証パス
  - 資格情報を送るリクエストパラメータ名の変更方法を紹介

    http.formLogin()
        //.loginPage("/login")
        .loginProcessingUrl("authenticate")
        .usernameParameter("uid")
        .passwordParameter("pwd")
        .permitAll();

loginPageもloginProcessingUrlもやっていることは同じらしい
- http://www.ne.jp/asahi/hishidama/home/tech/java/spring/boot/web/form-auth.html

9.4.3 認証成功時のレスポンス

SpringSecurityは、認証成功時のレスポンスを制御するためのコンポーネントとして、AuthenticationSuccessHandlerというインターフェースと実装クラスを提供している
AuthenticationSuccessHandlerの実装クラス
- SavedRequestAwareAuthenticationSuccessHanlder: 認証前にアクセスを試みたURLにリダイレクト（デフォルト）
- SimpleUrlAuthenticastionSuccessHandler: コンストラクタに指定したURLにリダイレクトまたはフォワードする
デフォルトの動作
- 認証前にアクセスを拒否したリクエストをHTTPセッションに保存しておいて、認証が成功した際にアクセスを拒否したリクエストを復元してリダイレクトする仕組みになっている
デフォルト動作のカスタマイズ
- 認証成功時のレスポンスのカスタマイズポイントとして、認証成功時に遷移するデフォルトのパスの変更方法を紹介

    http.formLogin()
        .loginPage("/login") // 認証を必要とするURLに遷移した場合、このURLにリダイレクトしてログインフォームを表示する仕組み
        .defaultSuccessUrl("/menu") // 認証成功時のデフォルトアクセスはルート。カスタマイズするために記載
        .permitAll(); // すべてのユーザーに対してログインフォームへのアクセス件を付与する

9.4.5 データベース認証

データベース認証の仕組み
- SpringSecurityはクライアントからの認証依頼を受け、DaoAuthenticationProviderの認証処理を呼び出す
- DaoAuthenticationProviderは、UserDetailsServiceのユーザー情報取得処理を呼び出す
- UserDetailsServiceの実装クラスは、データストアからユーザー情報を取得する
- UserDetailsServiceの実装クラスは、データストアから取得したユーザー情報からUserDetailsを生成する
- DaoAuthenticationProviderは、UserDetailsServiceから返却されたUserDetailsとクライアントが指定した認証情報との照合を行い、クライアントが指定したユーザーの正当性をチェックする。クライアントが指定したユーザーが正当なユーザーでない場合は、認証例外をスローする
メモ
- SpringSecurityはユーザー情報をリレーショナルデータベースからJDBC経由で取得するための実装クラスを提供しているが、最低限の認証処理しか行わないため、そのまま利用できるケースは少ないと思われる
- そのため本書では、UserDetailsとUserDetailsServiceの実装クラスを作成する方法を紹介します。
UserDetailsの作成
- MEMO:※細かいのでソースを確認後で追記
認証処理の適用

9.4.6 パスワードのハッシュ化

いくつか、パスワードを扱う実装クラスが提供されている
MEMO:※細かいのでソースを確認後で追記

9.4.7 認証イベントのハンドリング

SpringSecurityは、SpringFrameworkが提供しているイベント通知の仕組みを利用して、
認証処理の結果を他のコンポーネントへ連携する仕組みを提供しています
この仕組を利用すると以下のようなセキュリティ要件をSpringSecurityの認証機能に組み込むことができます
- 認証成功、失敗などの認証履歴をデータベースやログに保存したい
- パスワードを連続して誤った場合にアカウントをロックしたい
認証イベントの通知は以下のような仕組みで行われる
認証イベントの通知の流れ
1. SpringSecurityの認証機能は、認証結果をAuthenticationEventPublisherに渡して認証イベントの通知依頼を行う
2. AuthenticationEventPublisherインターフェースのデフォルトの実装クラスは、認証結果に対応する認証イベントクラスのインスタンスを生成し、ApplicationEventPublisherに渡してイベントの通知依頼を行う
3. ApplicationEventPublisherインターフェースの実測クラスは、ApplicationListenerインターフェースの実装クラスにイベントを通知する
4. ApplicationListenerの実装クラスの１つであるApplicationListenerMethodAdaptorは、@org.springframework.context.event.EventLintenerが付与されているメソッドを呼び出してイベントを通知する
メモ
- Spring4.1まではApplicationListenerインターフェースの実装クラスを作成して、イベントを受け取る必要があった
- Spring4.2からは、POJOに@EventListenerを付与したメソッドを実装するだけでイベントを受け取ることができる
- Spring4.2以降も、従来と同じ用にApplicationListenerインターフェースの実装クラスを作成してイベントを受け取ることができる
認証成功イベント
- 認証が成功したときにSpringSecurityが通知する主なイベントは以下の３つです。
- この３つのイベントは途中でエラーが発生しなければ、以下の順番ですべて通知されます
  - AuthenticationSuccessEvent
    - AuthenticationProviderによる認証処理が成功したことを通知する。
    - このイベントをハンドリングすると、クライアントが正しい認証情報を指定したことを検知することができるが、後続の認証処理でエラーになる可能性がある
  - SessionFixationProtectionEvent
    - セッション固定攻撃対策の処理（セッションIDの変更処理）が成功したことを通知する。このイベントをハンドリングすると、変更後のセッションIDを検知することができる
  - InteractiveAuthenticationSuccessEvent
    - 認証処理がすべて成功したことを通知する。このイベントをハンドリングすると、画面遷移を除くすべての認証処理が成功したことを検知することができる
認証失敗イベント
- 認証が失敗したときにSpringSecurityが通知する主なイベントは以下の通り
- 認証に失敗した場合は、以下のいずれか１つのイベントが通知される
  - AuthenticationFailureBadCredentialsEvent
  - AuthenticationFailureDisabledEvent
  - AuthenticationFailureLockedEvent
  - AuthenticationFailureExpiredEvent
  - AuthenticationFailureCredentialsExpiredEvent
  - AuthenticationFailureServiceExceptionEvent
イベントリスナの作成
- 認証イベントの通知を受け取って処理を行いたい場合、@EventListenerを付与したメソッドを実装したクラスを作成し、DIコンテナに登録するだけ



/**
 * - 認証イベントの通知の流れ
 *    1. SpringSecurityの認証機能は、認証結果をAuthenticationEventPublisherに渡して認証イベントの通知依頼を行う
 *    2. AuthenticationEventPublisherインターフェースのデフォルトの実装クラスは、認証結果に対応する認証イベントクラスのインスタンスを生成し、ApplicationEventPublisherに渡してイベントの通知依頼を行う
 *    3. ApplicationEventPublisherインターフェースの実測クラスは、ApplicationListenerインターフェースの実装クラスにイベントを通知する
 *    4. ApplicationListenerの実装クラスの１つであるApplicationListenerMethodAdaptorは、`@org.springframework.context.event.EventLintener`が付与されているメソッドを呼び出してイベントを通知する
 *
 * - `@EventLitener`を付与したメソッドを実装するだけで認証成功/失敗時の処理を実装できる仕組み
 * @author Tomo
 *
 */
@Slf4j
@Component
public class AppSecurityEventListener {

  // ==============================
  //  SUCCESS EVENT HANDLERS
  // ==============================

  /**
   * AuthenticationProviderによる認証処理が成功したことを通知する。
   * このイベントをハンドリングすると、クライアントが正しい認証情報を指定したことを検知することができるが、
   * 後続の認証処理でエラーになる可能性がある。
   * @param event
   */
  @EventListener
  public void handleAuthenticationSuccess(AuthenticationSuccessEvent event) {
    //
  }

  /**
   * セッション固定攻撃対策の処理（セッションIDの変更処理）が成功したことを通知する。
   * このイベントをハンドリングすると、変更後のセッションIDを検知することができる。
   * @param event
   */
  @EventListener
  public void handleSessionFixationProtection(SessionFixationProtectionEvent event) {
    //
  }

  /**
   * 認証処理がすべて成功したことを通知する。
   * このイベントをハンドリングすると、画面遷移を除くすべての認証処理が成功したことを検知することができる。
   * @param event
   */
  @EventListener
  public void handleInteractiveAuthenticationSuccess(InteractiveAuthenticationSuccessEvent event) {
    //
  }

  // ==============================
  //  FAILURE EVENT HANDLERS
  // ==============================

  @EventListener
  public void handleBadCredentials(AuthenticationFailureBadCredentialsEvent event) {
    log.info("BAD Credentials is detected. username : {}", event.getAuthentication().getName());
  }

  @EventListener
  public void handleDisabled(AuthenticationFailureDisabledEvent event) {
    log.info("Disabled user is detected. username : {}", event.getAuthentication().getName());
  }

  @EventListener
  public void handleLocked(AuthenticationFailureLockedEvent event) {
    log.info("Locked user is detected. username : {}", event.getAuthentication().getName());
  }

  @EventListener
  public void handleExpired(AuthenticationFailureExpiredEvent event) {
    log.info("Expired user is detected. username : {}", event.getAuthentication().getName());
  }

  @EventListener
  public void handleCredentialsExpired(AuthenticationFailureCredentialsExpiredEvent event) {
    log.info("CredentialsExpired is detected. username : {}", event.getAuthentication().getName());
  }

  @EventListener
  public void handleServiceException(AuthenticationFailureServiceExceptionEvent event) {
    log.info("ServiceException is detected. username : {}", event.getAuthentication().getName());
  }
}

9.4.8 ログアウト

SpringSecurityは以下のような流れでログアウト処理を行う
1. クライアントは、ログアウト処理を行うためのパスにリクエストを送信する
2. LogoutFilterは、LogoutHandlerのメソッドを呼び出してログアウト処理を行う
3. LogoutFilterは、LogoutSuccessHandlerのメソッドを呼び出して画面遷移を行う
LogoutHandlerの実装クラス
- SecurityContextLogoutHandler: 認証情報のクリアとセッションの破棄を行う
- CookieClearingLogoutHandler: 指定したクッキーの削除するためのレスポンスを行う
- CsrfLogoutHandler: CSRF対策用のトークンの破棄を行う
こららのLogoutHandlerは、SpringSecurityが提供しているBean定義をサポートするクラスが自動でLogoutFilterに設定する仕組みになっているので、基本的にはアプリケーションの開発者が直接意識する必要はない
ログアウト処理の適用
- ログアウト処理を適用するには、以下のようなBean定義を行う必要がある

    http.authorizeRequests()
        .antMatchers("/", "/find", "/login", "/signup", "/error", "/login-error").permitAll()
        .anyRequest().authenticated()
        .and()
        // Login処理
        .formLogin()
        .loginPage("/login") // 認証を必要とするURLに遷移した場合、このURLにリダイレクトしてログインフォームを表示する仕組み
        .defaultSuccessUrl("/menu") // 認証成功時のデフォルトアクセスはルート。カスタマイズするために記載
        .failureUrl("/login") // 認証失敗時ログイン画面に戻す
        .usernameParameter("id")
        .passwordParameter("password")
        .and()
        // Logout処理
        .logout()
        .logoutRequestMatcher(new AntPathRequestMatcher("logout**"))
        .logoutSuccessUrl("/login")
        .permitAll(); // すべてのユーザーに対してログインフォームへのアクセス件を付与する

デフォルトの動作のカスタマイズ
- 遷移先を変える logoutSuccessUrlの引数を変えてあげる

9.4.10 認証情報へのアクセス

認証済みのユーザーの認証情報は、SpringSecurityのデフォルト実装では、セッションに格納される
セッションに格納された認証情報は、リクエストごとにSecurityContextPersistenceFilterクラスによって
SecurityContextHolderというクラスに格納され、同一スレッド内であればどこからでもアクセスすることができる用になる
Javaからのアクセス
- 一般的な業務アプリケーションでは、「いつ」「誰が」「どのデータに」「どのようなアクセスをしたか」を
- 記録する監査ログを取得することがある。この要件を実現する際の、「誰が」は、認証情報から取得できる

// 認証情報（Authenticationオブジェクト）を取得する
Authentication authentication =
    SecurityContextHolder.getContext().getAuthentication();

String userUuid = null;
// Authentication#getPrincipal()メソッドを呼び出して、UserDetailsオブジェクトを取得する
// 認証済みでない場合は、匿名ユーザーを表す文字列が返却されるので注意
if (authentication.getPrincipal() instanceof AccountUserDetails) {
    AccountUserDetails userDetails = AccountUserDetails.class.cast(authentication.getPrincipal());
    // UserDetailsから処理に必要な情報を取得する
    userUuid = userDetails.getAccount().getUserUuid();
}

アノテーションでアクセスした方が良さそう
- https://qiita.com/Hyuga-Tsukui/items/81990938e43c7dff35cf
JSPからのアクセス
- 一般的なWebアプリケーションでは、ログインユーザーのユーザー情報などを画面に表示することがある。

<% taglib prefix="sec" uri="http://www.springframework.org/security/tags" %>
<%-- ... --%>
ようこそ
<sec:authentication property="principal.account.lastName" />
さん。

追記：thymeleafからのアクセス

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org"
      xmlns:sec="http://www.thymeleaf.org/thymeleaf-extras-springsecurity4"> <!-- これを追加してThymeleafからSpringSecurityを利用 -->

<!-- 省略 -->
<body>
  <h1>こんにちは、<span sec:authentication="principal.userId"></span>さん</h1> <!-- principal.メンバ変数名　で参照できる　-->
</body>

9.4.11 認証処理とSpringMVCの連携

SpringSecurityは、SpringMVCと連携するためのコンポーネントをいくつか提供している
ここでは、認証処理と連携するためのコンポーネントの使い方を紹介
SpringSecurityは認証情報（UserDetails）をSpringMVCのコントローラーのメソッドに引き渡すためのコンポーネントとして、AuthenticationPrincipalArgumentResolverというクラスを提供している
これを使用すると、コントローラーのメソッド引数として、UserDetailsインターフェースまたはその実装クラスのインスタンスを受け取ることができる

@Controller
public class Controller {

    @RequestMapping("/")
    public index(@AuthenticationPrincipal UserDetailsImpl userDetails) {
        System.out.println(userDetails.getUserId) // userId
        System.out.println(userDetails.getPassword) //password
        System.out.println(userDetails.getHoge) //hoge
    }

9.4.12 エラーメッセージ

認証に失敗した場合、SpringSecurityが用意しているエラーメッセージが表示されます
このエラーメッセージは内容を変更したり、表示しないようにすることができます。
エラーメッセージの変更
- 認証失敗時に表示されるエラーメッセージを変更したい場合は、MessageSourceで読み込んでいるプロパティファイルに
- SpringSecurityが用意しているメッセージの定義を追加してください

AbstractUserDetailsAuthenticationProvider.badCredentials = 入力した認証情報に誤りがあります。
AbstractUserDetailsAuthenticationProvider.credentialsExpired = 認証情報の利用期限が切れています。
AbstractUserDetailsAuthenticationProvider.disabled = 無効なアカウントです。
AbstractUserDetailsAuthenticationProvider.expired = アカウントの期限が切れています。
AbstractUserDetailsAuthenticationProvider.locked = アカウントがロックされています。

この他にも多数のメッセージが用意されている
種類を確認するには、spring-security-coreモジュールのjarファイルの中のorg/springframework/security/message.propertiesファイルを確認してください
メッセージ定義定数クラスは自動生成するべきな件
- https://terasolunaorg.github.io/guideline/1.0.x/ja/ArchitectureInDetail/MessageManagement.html
メモ
- MessageSourceの中でプロパティファイルをISO 8859-1(デフォルト)で読み込んでいる場合は、マルチバイト文字は
- Unicodeコード（\udddd表記）形式に変換する必要がある。
- なお、プロパティファイルを任意の文字コードで読み込む場合は、MessageSourceのdefaultEncodingプロパティに文字コードを指定してください。

  @Bean
  public MessageSource messageSource() {
    ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();
    messageSource.setBasenames("i18n/messages"); // クラスパス上に格納されているプロパティファイル（拡張子は除く）を指定する
    messageSource.setDefaultEncoding("UTF-8"); // ★ここのこと！
    return messageSource;
  }

システムエラー時のメッセージ
- 認証処理の中で予期しないエラー（システムエラーなど）が発生した場合、InternalAuthenticationServiceExceptionという例外が発生する。InteractiveAuthenticationServiceExceptionが保持するメッセージには、
- 原因例外のメッセージが設定されるため画面にそのまま表示するのは好ましくない
- システムエラーの例外メッセージを画面に表示しない用にするには、ExceptionMappingAuthenticationFailureHandlerやDelegatingAuthenticationFailureHandlerを使用して、InternalAuthenticationServiceExceptionが発生したときの遷移先をシステムエラー画面にするのが良いでしょう。
TODO: この辺見て実装する
- https://qiita.com/rubytomato@github/items/6c6318c948398fa62275

9.5 認可処理

認可処理は、アプリケーションの利用者がアクセスできるリソースを制御するための処理
最も標準的な方法は、リソース毎にアクセスポリシーを定義しておいて、利用者がリソースにアクセスしようとしたときにアクセスポリシーを調べて制御する方法
アクセスポリシーには、どのリソースにどのユーザーからのアクセスを許可するかを定義します
SpringSecurityでは、Webリソース、Javaメソッド、ドメインオブジェクトに対してアクセスポリシーを定義できる

※ドメインオブジェクトに関する認可処理は本書では扱わない興味がある場合は、下記参照 http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#domain-acls

9.5.1 認可処理の仕組み

SpringSecrityが提供する認証処理の仕組みを理解しましょう
以下のような流れで認可処理を行います
1. クライアントが任意のリソースにアクセスする
2. FilterSecurityInterceptorクラスは、AccessDecisionManagerインターフェースのメソッドを呼び出し、リソースへのアクセス権の有無をチェックする
3. AffirmativeBasedクラス（デフォルトで使用されるAccessDecisionManagerの実装クラス）は、AccessDecisionVoterインターフェースのメソッドを呼び出し、アクセス件の有無を投票してもらう
4. FilterSecurityInterceptorは、AccessDecisionManagerによってアクセス権が付与された場合に限り、リソースへアクセスする
ExceptionTranslationFilter
- 認可処理（AccessDecisionManager）で発生した例外をハンドリングし、
- クライアントに適切なレスポンスを行うためのサーブレットフィルタ
- デフォルトの実装では、未認証ユーザーからのアクセスの場合は、認証を促すレスポンス、認証済みユーザーからのアクセスの場合は、認可エラーを通知するレスポンスを返却する
FilterSecurityInterceptor
- HTTPリクエストに対して認可処理を適用するためのサーブレットフィルタで、実際の認可処理はAccessDecisionManagerに移譲しています。
- AccessDecisionManagerインターフェースのメソッドを呼び出す際には、クライアントがアクセスしようとしたWebリソースに指定されているアクセスポリシーを連携します。
AccessDecisionManager
- アクセスしようとしたリソースに対してアクセス権があるかチェックを行うためのインターフェース
- SpringSecurityが提供する実装クラスでは、このあと紹介するAccessDecisionVoterというインターフェースのメソッドを呼び出してアクセス権を付与するか否かを投票するしくみになっており、デフォルトで適用されるクラスはAffirmativeBasedクラスです。AffirmativeBasedクラスは、いずれかのAccessDecisionVoterが付与を投票した場合にアクセス権を与える実装クラス
AccessDecisionVoter
- アクセスしようとしたリソースに指定されているアクセスポリシーを参照し、アクセス権を付与するか否かを投票する（付与、拒否、棄権）するためのインターフェース
- SpringSecurityではいくつかの実装クラスを提供しているが、4.0からデフォルトで適用されるクラスは、WebExpressionVoterに統一されている
- WebExpressionVoterはSpring Expression Languageを使用して、利用者が持つ、権限情報とリクエスト情報を参照して投票を行う実装クラス

9.5.2 アクセスポリシーの記述方法

SpringSecurityは、アクセスポリシーを指定する記述方法として、SpringExpressionLanguage（SpEL）をサポート
SpELを使わない方法もあるが、本書では、Expressionを使ってアクセスポリシーを指定する方法で解説する
CommonExpressions
- ※割愛

9.5.3 Webリソースへの認可（JavaConfig編）

JavaConfigを使用して、Webリソースに対してアクセスポリシーを定義する方法について説明
アクセスポリシーを適用するWebリソースの指定
- まずは、アクセスポリシーを適用するリソースを指定
- アクセスポリシーを適用するリソースの指定は、ExpressionInterceptUrlRegistryクラスの以下のメソッドを呼び出して行います。
  - antMatchers
  - regexMatchers
  - requestMatchers
  - anyRequests

  @Override
  public void configure(HttpSecurity http) throws Exception {
    //    http.addFilter(this.preAuthenticatedProcessingFilter());
    //    http.formLogin();
    http.authorizeRequests()
        .antMatchers("/", "/find", "/login", "/signup", "/error", "/login-error").permitAll()
        // ★記載順には気をつける必要がある
        .antMatchers("/admin/accounts/***").hasRole("ACCOUNT_MANAGER")
        .antMatchers("/admin/***").hasRole("ADMIN")
        .anyRequest().authenticated()

アクセスポリシーの指定
- 次に、アクセスポリシーを指定します。
- アクセスポリシーの指定は、AuthorizedUrlクラスのメソッドを使用して行います。

    http.authorizeRequests()
        .antMatchers("/", "/find", "/login", "/signup", "/error", "/login-error").permitAll()
        //        .antMatchers("/admin/accounts/***").hasRole("ACCOUNT_MANAGER")
        //        .antMatchers("/admin/***").hasRole("ADMIN")
        .antMatchers("/admin/***").access("hasIpAddress('127.0.0.1') and hasRole('CONFIGURATION_MANAGER')")
        .antMatchers("/admin/***").hasRole("ADMIN")
        .anyRequest().authenticated()

9.5.4 Webリソースへの認可（XMLファイル編）

割愛

9.5.5 メソッドへの認可

SpringSecurityは、SpringAOPの仕組みを利用して、アプリケーションコンテキスト内で管理しているBeanのメソッド呼び出しに対して認可処理を行う仕組みを提供しています。
- メソッドに対応する認可処理を使用すると、メソッドの引数や戻り値のオブジェクトの状態を参照できるため、よりきめ細かいアクセスポリシーの定義が行える
- メソッドへの認可を使用する場合は、メソッド呼び出しに対して認可処理を行うためのコンポーネント（AOP）を有効にしてから、アクセスポリシーをクラスやメソッドのアノテーションに定義します。
  - つまり
    - AOP有効化
    - メソッドにアノテーション定義
SpringSecurityがサポートしているアノテーションは以下
- @PreAuthorize,@PostAuthorize,@PreFilter,@PostFilter: SpringSecurityのアノテーション
- @Secured: SpringSecurityのアノテーション
- JSR250(javax.annotation.securityパッケージ)のアノテーション（@RolesAllowedなど）
本書では、アクセスポリシーの指定にExpressionを使用することができる @PreAuthorizeと@PostAuthorizeを紹介する
メソッド認可の有効化
- まず、メソッドに対して認可処理を行うAOPを有効化します

@EnableGlobalMethodSecurity(prePostEnabled = true) // メソッドに対して認可処理を行うAOPを有効化 prePostEnabled属性にtrueを指定すると、Expressionを使用してアクセスポリシーを定義することができるアノテーションが有効になる
public class AppSecurityConfig extends WebSecurityConfigurerAdapter {
}

メソッド実行前に適用するアクセスポリシーの指定
- メソッドの実行前に適用するアクセスポリシーを指定する場合は@PreAuthorizeを使用する
- @PreAuthorizeのvalue属性に指定したExpressionの結果がtrueになるとメソッドの実行が許可される

// 管理者以外の人間が他人のアカウント情報にアクセスできないように定義している
@PreAuthorize("hasRole('ADMIN') or (#username == principal.username)")
public Account findOne(String username) {
  return accountRepository.findOne(username);
}

ここでポイントになるのが、Expressionの中からメソッドの引数にアクセスしている部分
具体的には、#usernameの部分が引数にアクセスしている部分になる
Expression内で「# + 引数名」形式のExpressionを指定するとメソッドの引数にアクセスすることができる
メモ
- SpringSecurityは、クラスに出力されているデバッグ情報から引数名を解決する仕組みになっているが、
- アノテーション（@P）を使用して明示的に引数名を指定することもできる
- 以下の場合は、明示的に引数名を指定してあげる必要がある
  - 引数のデバッグ情報を出力しない
  - Expressionの中から実際の引数名とは別の名前を使ってアクセスする（例：短縮した名前）

@PreAuthorize("hasRole('ADMIN') or (#username == principal.username)")
public Account findOne(@P("username") String username) {
  return accountRepository.findOne(username);
}

JavaSE8から追加されたコンパイルオプション（-parameters）を使用すると、メソッドパラメータにリフレクション用のメタデータが生成されるため、アノテーションを指定しなくても引数名を解決してくれる
メソッド実行後に適用するアクセスポリシーの指定
- @PostAuthorizeを使用する

@PreAuthorize("hasRole('DEPARTMENT_MANAGER')")
@PostAuthorize("(returnObject == null) or (returnObject.departmentCode == principal.account.departmentCode)")
public Account findOne(@P("username") String username) {
  return accountRepository.findOne(username);
}

9.5.6 JSPの画面項目への認可

SpringSecurityはJSPタグライブラリを使用してJSPの画面項目に対して認可処理を適用することができる

※管理者の場合、この項目を表示するなどの制御
- このURLへ遷移させるなどの制御

9.5.7 認可エラー時のレスポンス

SpringSecurityはリソースへのアクセスを拒否した場合、以下のような流れでエラーハンドリング、レスポンスを行う
1. SpringSecurityは、リソースやメソッドへのアクセスを拒否するために、AccessDeniedExceptionをスローする
2. ExceptionTranslationFilterクラスは、AccessDeniedExceptionを捕捉し、AccessDeniedHandlerまたは、AuthenticationEntryPointインターフェースのメソッドを呼び出してエラー応答を行う
3. 認証済みのユーザーからのアクセスの場合は、AccessDeniedHandlerインターフェースのメソッドを呼び出してエラー応答を行う
4. 未認証ユーザーからのアクセスの場合は、AuthenticationEntryPointインターフェースのメソッドを呼び出してエラー応答を行う
AccessDeniedHandler
AuthenticationEntryPoint
認可エラー時の遷移先

    http.exceptionHandling().accessDeniedPage("/accessDeniedError");

デフォルト動作のカスタマイズ
- TODO: 認証エラー時にメッセージを出す処理を作るときに記述しないと行けない気がする

9.6 CSRF対策

9.6.1 Spring SecurityのCSRF対策

Spring Securityはセッション単位にランダムなトークン値(CSRFトークン)を払い出し、払い出されたCSRFトークンをリクエストパラメータ（HTMLフォームのhidden項目）として送信することで、そのリクエストが正規のWebページからなのか、それとも攻撃者が用意したWebページからなのかを判断する機能がある
SpringSecurityのデフォルト実装では、POST,PUT,DELETE,PATCHのHTTPメソッドを使用したリクエストに対して、CSRFトークンチェックを行います

9.6.2 CSRF対策機能の適用

CSRF対策機能はSpring3.2から追加された機能で、SpringSecurity4.0からデフォルトで適用されるようになりました。
そのため、CSRF対策機能を有効にするための特別な定義はありません。
なおCSRF機能を適用したくない場合は、明示的に無効にする必要がある

  @Override
  public void configure(HttpSecurity http) throws Exception {
    http.csrf().disable();
  }

HTMLフォーム使用時のトークン値の連携
- JSPでの設定を紹介しているため割愛
- Thymeleafだとこんな感じhttps://qiita.com/nenokido2000/items/22a97a26a5858ddb164f
Ajax使用時の連携
- Ajaxを使ってリクエストを送信する場合は、SpringSecurityから提供されている<sec:csrfMetaTag>要素を使用して、HTMLの<meta>要素としてCSRFトークンの情報を出力し<meta>要素から取得したトークン値をAjax通信時のリクエストヘッダーに設定して連携します。
- Thymeleafの場合、以下を参考に、Cookieからcsrfトークンを取り出して、詰めて送る
  - https://qiita.com/nenokido2000/items/22a97a26a5858ddb164f
  - CookieにCSRFトークンを詰める処理は以下で行えるようになっている
  - http.csrf().csrfTokenRepository(new CookieCsrfTokenRepository());

9.6.3 トークンチェックエラー時のレスポンス

CSRFトークンチェックでエラーが発生した場合、SpringSecurityはAccessDeniedHandlerインターフェースを使用してエラーのレスポンスを行う
CSRFトークンチェックでエラーが発生したときに専用のエラーページに遷移させる場合は、SpringSecurityから提供されているDelegatingAuthenticationFailureHandlerクラスを利用して、それぞれの例外にAccessDeniedHandlerインターフェースの実装クラスを指定してください
CSRFトークンチェックで使用される例外クラス
- InvalidCsrfTokenException
- MissingCsrfTokenException
  - TODO: この例外処理を実装する必要がある XMLで記載している例はあるけど、Javaで書いている例がない..

9.6.4 CSRF対策機能とSpringMVCとの連携

自動でFormにcsrfトークンが入りますよという説明

9.7 セッション管理

9.7.1 セッション管理機能の適用

セッション管理機能を使用するには、以下のようなBean定義を行う

  @Override
  public void configure(HttpSecurity http) throws Exception {
    http.sessionManagement();
  }

sessionManagementメソッドを呼び出し、SessionManagementConfigurerのインスタンスを取得する
SessionManagementConfigurerには、セッション管理機能のコンポーネントの動作をカスタマイズするためのメソッドが定義されている。なお、WebSecurityConfigurerAdapterを継承して、コンフィギュレーションクラスを作成している場合は、sessionManagementメソッドは親クラスの処理で呼び出されるため、デフォルトでセッション管理機能が適用されている
RESTAPIなどセッションを使用しない場合は、セッションの作成方式を stateless に変更する必要がある

http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)

セッションの作成方式は以下のオプションから選択することができる
- always
- ifRequired (デフォルト)
- never
- stateless

9.7.2 URL Rewriting抑止機能

URL Rewritingが行われると、URL内にセッションIDが露出してしまうため、セッションIDを盗まれるリスクが高くなります。

SpringSecurityでは、URL Rewritingを抑止するための仕組みも提供しており、この機能はSpringSecurity4.0以上ではデフォルトで適用されます。

TODO: Cookieを許可しない設定になっているとどのような挙動になる？クエリに埋め込まれない？

9.7.3 セッション固定攻撃対策機能

セッション管理機能を適用すると、デフォルトでセッション固定攻撃機能が有効になる
セッション固定攻撃対策機能を使用すると、ログイン成功時に新たセッションIDを払い直すため、攻撃者が事前に払い出したセッションIDが使われることはありません。
セッション固定攻撃への対策オプション
- changeSessionId: Servlet3.1で追加されたHttpServletRequest#changeSessionIdメソッドを使用してセッションIDを変更する（Servlet3.1以上のコンテナでのデフォルト動作）
- migrateSession: ログイン前に使用していたセッションを破棄し、新たにセッションを作成する。ログイン前にセッションに格納されていたオブジェクトは新しいセッションに引き継がれる
- newSession: migrateSessionと同じ方法でセッションIDを変更するが、ログイン前に格納されていたオブジェクトは新しいセッションには引き継がれない
- none: SpringSecurityはセッションIDを変更しない
指定方法


http.sessionManagement().sessionFixation().newSession();

9.7.4 多重ログインの制御

SpringSecurityは同じユーザー名（ログインID）を使った多重ログインを制御する機能を提供しているが、
SpringSecurityが提供しているデフォルト実装にはいくつかの制約や注意事項がある
本書では、これらの制約と注意事項について紹介するが、具体的な使い方は扱わない、リファレンス参照
SpringSecurityが提供しているデフォルト実装では、ユーザー毎にセッション情報をアプリケーションサーバーのメモリ内で管理します。
そのため、複数のアプリケーションサーバーを同時に実行するシステムでは利用することができません。
また、アプリケーションサーバーを停止または再起動するとメモリ内で管理していたセッション情報はクリアされます。
使用するアプリケーションサーバーによっては、停止または再起動時のセッション状態を復元する機能を持っているため、実際のセッション状態とSpringSecurityが管理しているセッション情報に不整合が生じる可能性がある
TODO: Redisで管理する方法探る

9.7.5 無効なセッションを使ったリクエストの検知

SpringSecurityは無効なセッションを使ったリクエストを検知する機能を提供している
無効なセッションとして扱われるリクエストの大部分は、セッションタイムアウト後のリクエストです。
以下の例では、無効なセッションを検知した際の遷移先として "/error/invalidSession"を指定することで、この機能を有効化している


http.sessionManagement().invalidSessionUrl("/error/invalidSession");

9.8 ブラウザのセキュリティ対策機能との連携

ブラウザが提供するセキュリティ対策機能の一部は、サーバー側で、HTTPのレスポンスヘッダーを出力することで動作を制御することができる

9.8.1 セキュリティヘッダー出力機能の適用

Spring3.2から追加された機能で、Spring4.0からデフォルトで適用されるようになった

// 無効にする方法
    http.headers().disable();

9.8.2 デフォルトでサポートしているセキュリティヘッダー

SpringSecurityがデフォルトでサポートしているレスポンスヘッダーは以下の５つ
- Cache-Control（Pragma, Expires）
  - コンテンツのキャッシュ方法を支持するヘッダー
  - 保護されたコンテンツがブラウザにキャッシュされないようにすることで、権限のないユーザーが保護されたコンテンツを閲覧できてしまうリスクを減らすことができる
- X-Frame-Options
  - フレーム（<frame>または<iframe>要素）内でコンテンツの表示を許可するか否かを支持するためのヘッダー
  - フレーム内でコンテンツが表示されないようにすることで、クリックジャッキングと呼ばれる攻撃手法を使って機密情報を盗み取られるリスクを無くすことができる
- X-Content-Type-Options
  - コンテンツの種類の決定方法を指示するためのヘッダー
  - 一部のブラウザでは、Content-Typeヘッダーの値を無視して、コンテンツの内容を見て決定します。
  - コンテンツの種類を決定する際にコンテンツの内容を見ないようにすることで、クロスサイトスクリプティングを使った攻撃を受ける可能性をへらすことができます。
- X-XSS-Protection
  - ブラウザのXSSフィルタ機能を使って有害なスクリプトを検知する方法を支持するためのヘッダー
  - XSSフィルタ機能を有効にして有害なスクリプトを検知するようにすれば、クロスサイトスクリプティングを使った攻撃を受ける可能性をへらすことができる。
- Strict-Transport-Security
  - HTTPSを使ったアクセスをしたあとに、HTTPを使ってアクセスしようとした際に、HTTPSに置き換えてからアクセスすることを支持するためのヘッダー
  - HTTPSでアクセスした後に、HTTPが使われないようにすることで、中間者攻撃と呼ばれる攻撃手法を使って悪意のあるサイトに誘導されるリスクをへらすことができる
TODO: 攻撃手法と対策について再度整理する必要あり

9.8.3 セキュリティヘッダーの選択

出力するセキュリティヘッダーを選択したい場合は、以下のようなBean定義を行います。
ここではSpringSecurityが提供するすべてのセキュリティヘッダーを出力する例になっていますが、実際は必要なものだけ指定する

    http.headers()
        .defaultsDisabled()
        .cacheControl().and()
        .frameOptions().and()
        .contentTypeOptions().and()
        .xssProtection().and()
        .httpStrictTransportSecurity();

不要なものだけ無効化する方法もある

9.9 Spring Securityのテスト

MockMvcを使用して「認証処理」や「認可処理」などのテストを行うための機能
テスト時に適用する認証情報をアノテーションで指定できる機能

9.9.1 Spring Security Testのセットアップ

依存ライブラリーの追加

// build.gradle
  testImplementation 'org.springframework.security:spring-security-test'

SpringSecurityのサーブレットフィルタの追加
TODO: テスト環境が作れて無いため一旦スキップする

第10章　Spring Data JPA

10.6 Repositoryの作成と利用

10.6.4 ページネーション

TODO: DOMAにあるかどうか

10.6.6 監査情報の付与

TODO: DOMAにあるかどうか

第11章　Spring ＋ MyBatis

XMLに記述しないといけないので採用したくない

第12章　Spring＋Thymeleaf

SpringBootを始め、ViewにJSPではなくテンプレートエンジンであるThymeleafを使用するケースが増えている
まずはThymeleaf自体や、Springとセットで開発する際に欠かせない連携ライブラリーの概要を紹介

12.1 Thymeleafとは

Thymeleafは、Webアプリケーションと親和性の高いテンプレートエンジン
テンプレートエンジンとは
- 雛形となるドキュメント（テンプレート）に対して、可変データを埋め込むことで動的にドキュメントを生成する仕組み
- この仕組は、MVCフレームワークのModelとViewを分割する考え方と親和性が高く、しばしばMVCフレームワークのVIEWとし利用される
特徴
- XHTMLやHTML5に準拠した形で記述できること
JSPはブラウザが認識できないタグライブラリなどが含まれるため、開発中のJSPを直接ブラウザ上で正確に表示させることが難しいという問題があった
一方ThymeleafのテンプレートはHTML5に準拠しているため、テンプレートをブラウザで直接表示させたり。HTMLをデザイナーとプログラマの間で共有することができる
MEMO: パーツをIncludeする際はうまく表示できない問題はあると思う

12.1.1 Thymeleafのテンプレート

ThymeleafはXHTMLやHTML5などで書かれたテンプレートをDOMに変換してから処理を行う仕組みになっている「処理対象のDOMノード」と「DOMノードに適用する処理」をthネームスペースの属性（th属性）を使用して指定します。

th属性が指定されているDOMノードは「プロセッサ」と呼ばれるコンポーネントによってDOM操作（追加、削除、変更）が行われる。th属性の属性値には、OGNL（Object-Graph Navigation Language）と呼ばれる式言語を指定でき、式の中から、ユーザー定義のオブジェクトやThymeleafが提供する暗黙オブジェクトにアクセスすることができる

以下３つのことをDialectと呼ぶ
- DOM操作を行うプロセッサ
- th属性の属性値に指定された式を解釈するコンポーネント
- 暗黙オブジェクトを生成するコンポーネント
  - →デフォルトでは、StandardDialectクラスが使用される
Dialectは拡張可能な仕組みになっており、本書で紹介するthymeleaf-spring4を使う場合は、StandardDiarectクラスを継承した、SpringStandardDialectクラスが使用される

12.1.2 ThymeleafとSpringの連携

連携する場合、Thymeleafが提供するthymeleaf-spring4モジュールを利用
SpringMVCがJSP向けに提供しているタグライブラリと同様の機能を、Thymeleafで利用することができる
実現できる機能
- Thymeleafが管理するテンプレートをSpringMVCのViewとして扱うことができる
- テンプレート内でSpringELを利用することができる
- テンプレートと、フォームクラスおよび入力値チェック結果のバインドが可能となる
- Springが管理するメッセージリソースを利用し、国際化対応のメッセージを表示することができる

12.2 Spring + Thymeleafのセットアップ

12.2.1 ライブラリのセットアップ

thymeleaf-spring4を入れる

12.2.2 SpringとThymeleafを連携するための設定

SringBootだと書かなくても動くっぽいけど明示する意味で


@Configuration
@Import(ThymeleafConfig.class) // Thymeleafを使用することを明示
public class AppConfig implements WebMvcConfigurer {
}

@Configuration
public class ThymeleafConfig {

  @Bean
  public ClassLoaderTemplateResolver templateResolver() {
    ClassLoaderTemplateResolver resolver = new ClassLoaderTemplateResolver();
    resolver.setPrefix("/WEB-INF/templates/");
    resolver.setSuffix(".html");
    resolver.setTemplateMode("HTML5");
    resolver.setCharacterEncoding("UTF-8");
    return resolver;
  }

  @Bean
  public SpringTemplateEngine templateEngine() {
    SpringTemplateEngine templateEngine = new SpringTemplateEngine();
    templateEngine.setTemplateResolver(templateResolver());
    return templateEngine;
  }

  @Bean
  public ViewResolver viewResolver() {
    ThymeleafViewResolver viewResolver = new ThymeleafViewResolver();
    viewResolver.setTemplateEngine(templateEngine());
    viewResolver.setCharacterEncoding("UTF-8");
    return viewResolver;
  }

}

12.3 Thymeleafを利用したViewの実装

12.3.1 はじめてのThymeleaf

Thymeleafを利用したViewへの変更
テンプレートの実装

12.3.2 テキストの出力

th:text --- 属性値に指定した値をXHTMLサニタイジングして出力する
- ユーザからの入力を表示する際はこちら
th:utext --- 属性値に指定した値をXHTMLサニタイジングせずに出力する
- プロパティファイルでHTML要素を使用して意図的に装飾しているような場合は、th:utext属性を使用してXHTMLサニタイジングせずに出力する必要がある

12.3.3 式の構文

基本的な式
- 変数式
- 選択変数式
- メッセージ式：これは利用しておきたい
- リンクURL式
リテラル
基本的な演算子
テキスト演算子
条件演算子

12.3.4 th属性による属性値の設定

Thymeleafのテンプレートエンジンとしての機能は、th属性に指定された式を解釈し、HTMLの各要素の属性値を設定または上書きすることです。
特定の属性に値を設定する方法
現在の属性値の前後に値を追加する方法
存在有無が重要な属性の出力を制御する方法
複数の属性に同じ値を設定する方法：AltとTitleに同じ値を入れたりとか
任意の属性に値を設定する方法：独自データ属性に値を設定したい場合に使用する
- <button th:attr="data-product-id=${product.id}">削除</button>

12.3.5 HTML要素の出力制御

ここまでth属性を使ってHTML属性の属性値を動的に設定する方法を見てきましたが、動的にHTML要素の出力を制御する必要が出てくる場合がある

例えば、特定の条件下の場合のみメッセージを表示したり、
データの件数だけ行を追加して出力したりする場合などです。
JSPでは、それらの専用タグライブラリが用意されていましたが、Thymeleafでも相当する機能がth属性として提供されている
条件による出力有無の制御
- th:if
- th:unless
- th:switch
- th:case
繰り返し出力の制御
- th:each
  - java.util.Listの実装クラス
  - java.util.Iterableの実装クラス
  - java.util.Mapの実装クラス
  - 配列

12.3.6 インライン記述

th属性を利用しない方法であるインライン記述について説明

[[ ${user.name} ]]でかけるよ
インライン記述はデフォルトで無効になっている
有効にするには、 th:inline属性をインライン記述を利用する要素、もしくは親要素に付与する必要がある
インライン記述のでメリット
- テンプレートファイルをブラウザ上で直接表示した際に、インライン記述のテキストがそのまま表示されてしまう点
- th:textの用にサンプルデータを表示することができないため、デザイナーとの分業に支障をきたす可能性がある
メモ
- インライン記述はJavascriptなどのスクリプト内でも利用することができる
- これを利用すると、テンプレートをブラウザで静的に表示した場合や、アプリケーションサーバーにデプロイして動的に表示した場合、その両方においてスクリプトを正常に動作させられる。
MEMO: 結論（個人的な）
- インライン記述は原則禁止したほうがよいと思う（コーディング規約などで明記すべき）

12.3.7 コメント

<!-- 
  このブロックはThymeleafの処理後もテンプレートに残ります。
 -->
<!--/*
  このブロックはThymeleafの処理後に削除される。
*/-->

12.3.8 Springとの連携

本項では、thymleaf-springが提供しているSpringとの連携機能に焦点を当てる

フォームオブジェクトのバインディング
- th:object属性
- th:field属性
入力エラーの表示
- SpringMVCの入力チェック機能で発生したエラーの表示は、
  - th:errors属性 --- エラーメッセージの出力対象を指定するための属性
  - th:errorclass属性 --- エラー時に適用するCSSを指定するための属性
  - th:fieldsオブジェクト --- エラー情報にアクセスするための便利なメソッドを提供するオブジェクト
    - を使用して行う
TODO: エラー処理について設計する必要あり
SpELの利用
- Thymeleafは数式をOGNLとして解釈しますが、thymeleaf-springを利用すると、
- 変数式はSpELとして解釈されます。
- これにより、テンプレート内から、DIコンテナ内に登録されているBeanにアクセスできるようになる

<span th:text="${@appSettings.passwordValidDays}">60</span>
<!-- @Bean名でアクセスできる -->

ConversionServiceとの連携
- SpringMVCに適用されているConversionServiceと連携して、値の型変換を行うことができる

public class AppSettings implements Serializable {
  @Value("${vasicPostage:1250}")
  @NumberFormat(style = NumberFormat.Style.NUMBER)
  private int basicOneDayCost;
}

<span th:text="${@appSettings.basicOneDayCost}">1300</span>円
<span th:text="${{@appSettings.basicOneDayCost}}">1300</span>円

12.3.9 テンプレートの共通化

テンプレートのフラグメント化
- 共通な内容を別ファイルに切り出す
テンプレートのレイアウト化
- 複数のテンプレートで同じデザインレイアウトを適用する場合は、通常、共通的なレイアウトを定義して共有することになる。このような場合に有効なライブラリとして、Thymeleaf Layout Dialectがある
テンプレートのフラグメント化
- テンプレートの一部を分割して別ファイルに切り出すことができる
- ヘッダー、フッター、メニューがフラグメントとしてよく利用されるが、特定のUIコンポーネントをフラグメントとして切り出すことも可能
  - フラグメントの利用方法
    - フラグメントの定義と参照という２つの作業が必要になる
    - 定義方法には以下の２つの方法がある
      - Thymeleafのth:fragment属性を利用したフラグメント定義　★個人的にこっちがわかりやすくていいと思う
      - CSSセレクタと同様、id属性を利用したフラグメント定義
    - 定義したフラグメントを読み込む方法として以下の２つ
      - Thymeleafのth:include属性を利用したフラグメントのインクルード
      - Thymeleafのth:replace属性を利用したフラグメントのち缶
テンプレートのレイアウト化
- Thymeleaf Layout Dialectを利用したテンプレートのレイアウト化について説明
セットアップ
- thymeleaf-layout-dialectのリポジトリ追加
- コンフィギュレーションクラスの実装

  @Bean
  public SpringTemplateEngine templateEngine() {
    SpringTemplateEngine templateEngine = new SpringTemplateEngine();
    templateEngine.setDialect(new LayoutDialect());
    templateEngine.setTemplateResolver(templateResolver());
    return templateEngine;
  }

Thymeleaf Layout DialectによるViewの実装
- 共通レイアウトとなるテンプレートを「Decorator」
- 共通レイアウトを適用する側の個別のテンプレートを「Fragment」と呼ぶ
MEMO: 画面の全体像がわかりづらくなりやすいので、この方法は採用したくないため割愛

12.3.10 SpringSecurityとの連携

SpringSecurityが提供する画面表示に関する機能をThymeleafで利用するためには、
SpringSecurityDialectを利用します。
以下の機能
- 認証情報にアクセスする機能を持つ sec:authentication属性を提供
- SpringSecurity expression を利用した認可処理と同等の機能を持つ sec:authorize属性を提供
- URLベースの認可処理を行う sec:authorize-ur属性を提供する
- ACL(Access Control List)を利用した認可処理を行う sec:authorize-acl属性を提供
- CSRFトークンにアクセスする機能を提供
SpringSecurityDialectのセットアップ
- thymeleaf-extras-springsecurity4
認証情報へのアクセス

<!doctype html>
<html xmlns:th="http://www.thymeleaf.org"
  xmlns:sec="http://www.thymeleaf.ort/extras/spring-security"
  th:with="title=トップページ">
  <span sec:authentication="principal.username">テストユーザ名</span>

画面項目への認可
- 適用する画面項目とアクセスポリシーの指定
  - sec:authorize="hasRole('ADMIN')"属性を付与
  - Trueの場合、HTMLを表示
- Webリソースとして指定したアクセスポリシーとの連動
  - sec:authorize-url="/admin/accounts"にアクセスできることを条件として表示非表示を設定している
CSRFトークンへのアクセス
- Spring Security Dialectを適用するだけでOK hidden項目としてHTMLに埋め込まれます
- ajax通信の際は取得してあげる必要がある
  - headerのmeta要素に設定しといて、JSで取得してあげる感じにする
    - TODO: 取得してPOSTする処理は実装考えてみる

12.3.11 JSR 310: Date and Time APIの利用

Thymeleafは、テンプレート内でJSR310:Date and TimeAPIのオブジェクトを操作するための機能を標準ではサポートしておらず、Thymeleafが提供する拡張ライブラリが必要になる
依存ライブラリの追加
- thymeleaf-extras-java8timeを利用する
- なお、thymeleaf-extras-java8timeはSpringIO Platformで管理されていないため、バージョンの指定が必要
Bean定義の追加

  @Bean
  public SpringTemplateEngine templateEngine() {
    SpringTemplateEngine templateEngine = new SpringTemplateEngine();
    templateEngine.setDialect(new Java8TimeDialect());
    templateEngine.setTemplateResolver(templateResolver());
    return templateEngine;
  }

ユーティリティオブジェクト（temporals）を利用

<title th:text="|${#temporals.format(date, 'yyyy/mm/dd')}の会議室|">2020/05/19の会議室</title>

第13章　Spring Boot

機能が豊富な事による課題があるどう組み合わせていいかわからなかったり、ちょっとしたWebアプリケーションを作成するだけでも、数多くの設定が必要であったりする点です。

SpringBootを利用することでこられの課題を解決することができる

13.1 SpringBootとは

SpringBoot
- ２０１３年　　：開発開始
- ２０１４年４月：1.0リリース
- ２０１６年６月：1.3.5
- ２０２０年５月：2.3.0
SpringBootを使えば、何も設定しなくてもデフォルトで様々な機能が利用可能
XMLまたはJavaConfigによるBean定義、ログの設定、Servletの設定などが不要になる
アプリケーションサーバーをデプロイする必要もなくなり、Javaのmainメソッドを実行すればアプリケーションを実行できる

13.1.1 SpringBootで作るHello Worldアプリケーション

13.1.2 AutoConfigureに夜自動設定

自動設定の詳細を知りたい場合は、spring-boot-autoconfigureプロジェクトの◯◯AutoConfigurationクラスのソースを読むことをおすすめします。

13.1.3 Starterによる依存ライブラリの解決

starterライブラリの説明

13.1.4 実行可能jarの作成

実行可能jarとしてパッケージングされる

13.2 SpringBootでSpringMVC

13.2.1 RESTful Webサービスの作成

13.2.2 画面遷移型アプリケーションの作成

SpringBootの自動設定では、TemplateResolverがビュー名につけるプレフィックスとサフィックスのデフォルト値は、
それぞれ、classpath:/templates/と.htmlになる
テンプレートからメッセージを取得する方法

<title th:text="#{app.title}"> <!-- ${変数名}ではなく#{メッセージキー名}-->

13.3 SpringBootでデータアクセス

13.3.1 SpringJDBC

これまで必要だったがSpringJDBCでは不要な定義
- データソースの定義
- トランザクションマネージャの定義
- JdbcTemplateの定義
SpringBootのデフォルトの挙動としてクラスパス直下にschema.sqlが存在すると起動時にそのSQLファイルを実行

13.3.2 Spring Data JPA

13.3.3 MyBatis

13.3.4 コネクションプールライブラリの変更

SpringBootではDatasourceを定義する必要はなく、自動で生成されます。コネクションプーリングの仕組みも自動で決まり、以下のライブラリのうちクラスパス上にあるものが利用されます。
- TomcatJDBC
- HikariCP
- Commons DBCP
- Commons DBCP2
TODO: HikariCPが一番速いとのこと

13.4 SpringBootでSpring Security

Spring Security用のプロジェクトも当然用意されています。

13.4.1 Basic認証

デフォルトで有効になるらしい
デフォルトユーザーはuser
パスワードはランダムに設定される

13.4.2 認証・認可のカスタマイズ

SpringSecruityの認証・認可の設定はorg.springframework.security.config.annotation.web.configuration.WebSecrityConfigurerAdapterを用いて行う

13.5 Spring Bootで型安全なプロパティ設定

application.propertiesから値を取得できる

TODO: EnumによるConst管理とどっちがいいか
- メッセージのとり方確認
- 定数管理方法のベストプラクティス

13.5.1 @ConfigurationPropertiesを用いたプロパティの設定

プロパティを多用するSpringBootでは、安全にプロパティを扱うための仕組みとして、
@ConfigurationPropertiesアノテーションが用意されている
TODO: プロパティ管理はこれが良さそう

13.5.2 Bean Validationに夜プロパティ値のチェック

プロパティ値も、起動時にBindされる際、@NotEmptyなどで値の検証ができる

13.5.3 IDEによるプロパティの補完

@ConfigurationPropertiesを用いて定義したプロパティはIDEで補完が効く
補完させるためにプロパティのメタ情報を生成する必要がある
spring-boot-configuration-processorの説明
SpringBootでプロパティを外部化する際は積極的に使用していくとよい

13.6 SpringBootAcruatorで運用機能強化

SpringBootでは開発を容易にする機能が提供されるだけでなく、アプリケーションの運用面を考慮した機能も提供されている
これを提供するのがSpringBootActuator
これだけでアプリケーションの状態を検査するためのエンドポイント（HTTP,JMX,SSH）が追加されたり、ヘルスチェック機能やメトリクス取得機能が有効になる
TODO: 有効にして活用したい

13.6.1 HTTPエンドポイントの追加

HTTPエンドポイント
- /autoconfig
- /beans
- /env
- /configprops
- /dump
- /health
- /info
- /logfile
- /metrics
- /mappings
- /shutdown
- /trace
- /flyway
- /liquibase
エンドポイントのコンテキストパスやポート番号などはプロパティを使用して変更できる

management.context-path=/manage
management.port=8081
management.address=127.0.0.1 # localhostからのみアクセスを許可する

# 個別のエンドポイントの有効無効を次のプロパティで設定
endpoints.shutdown.enabled=true
endpoints.mapping.enabled=false
endpoints.trace.enabled=false

# エンドポイントはHTTPだけでなくJMXでもアクセスできる これらの無効にもできる
management.port=-1 # HTTPエンドポイントを無効にする
endpoints.jmx.enabled=false # JMXエンドポイントを無効にする

13.6.2 ヘルスチェック

SpringBootActuatorはヘルスチェック機能を持っている

13.6.3 メトリクス

SpringBootActuatorはメトリクス取得機能も備えている
次の２つのメトリクスがサポートされている
- gauge: 絶対値を記録する
- counter: 差分値を記録する
TODO: メトリクスは収集して管理できる用にしておく

第14章　チュートリアル

会議室予約システムを作成していく手順を記載

Java EE 7徹底入門標準Javaフレームワークによる高信頼性Webシステムの構築

Sun, 12 Apr 2020 00:00:00 GMT

Java EE 7徹底入門標準Javaフレームワークによる高信頼性Webシステムの構築

形式：書籍
発売日：2015年12月15日
ISBN：9784798140926
価格：本体3,800円＋税
仕様：B5変・584ページ
分類：プログラミング・開発
シリーズ：徹底入門
書籍ページ https://www.shoeisha.co.jp/book/detail/9784798140926
サンプルプログラム https://www.shoeisha.co.jp/book/download/9784798140926/detail

Chapter 1 Java EEの基礎知識

1.1 Java EEのこれまで

1995年 Sun Microsytems,Inc
- JDK1.0 α版
1998年 Sun JPEと呼ぶプロジェクトを立ち上げ
- サーバー側の企業アプリケーション開発にJavaを利用できるようにするために立ち上げ
1999年12月フレームワーク提供(J2EE 1.2)
- 10個の機能から構成
  - JSP+Servlet → 急速に普及
  - EJB
2001年 J2EE 1.3
2003年 J2EE 1.4
- XML対応
このころ、オープンソースのフレームワークも台頭
2006年5月簡単開発(Ease of Development)をテーマに、名前を改名
- Java Platform Enterprise Edition(JavaEE)と改め新バージョンをリリース
- Java EE 5
  - 普及には至らず
  - 改善をすすめる
2009年12月 JavaEE5をさらに大幅改善したJavaEE6をリリース
- CDI
- プロファイル：全仕様に対するサブセットを提供
- プルーニング：使われなくなって古くなった使用を整理するための仕組み
- → ミッションクリティカルな企業システムでも採用されるようになった

1.1.3 Java EE 7 へ --- 3つのテーマ

JavaEE6のリリース後、すぐに次期バージョンの検討
- 目をつけたのは「クラウド」
- より簡単にJavaEEアプリケーションをスケールするような機能を考え、GlassFishというアプリケーション・サーバー上で実際に動作するサンプルも作成
  - 外部からのフィードバックやスペックリードが集まって再検討した結果次期が早いと判断し見送り
Column JavaEE7 におけるクラウド対応の見送り
- 2012年8月12日開発の遅れと、仕様化に対する十分な経験、検討が足りなかったため見送りを決定
- 期待があった分失望の声もあったが
- 有識者やベンダーの多くはこの決断を支持
新しいテーマを考えた
- HTML5対応
- 開発用意/生産性の向上
- エンタープライズニーズへの対応

1.2 Java EEの全体像

Java EEに含まれる機能の全体像を把握してください
JavaEEは企業システムのアプリケーション開発に必要なさまざまな機能を１つにまとめた包括仕様（umbrella specification）の総称
大小さまざまな39個の仕様から構成されています。
主に
- インテグレーションテクノロジー
- ビジネスロジックテクノロジー
- プレゼンテーションテクノロジー
  - を組み合わせながらシステムを構築する
インテグレーションテクノロジー
- 外部システムと連携するための機能を提供
- 外部システム
  - データベース
  - メールサーバー
  - メッセージングプロバイダ（OpenMQ,WebShereMQ）
  - エンタープライズ情報システム（ERP,メインフレーム）等がある
ビジネスロジックテクノロジー
- 外部システムと連携するプログラムの実装とユーザーインターフェースのプログラムの実装の間に入り、企業システムの業務で必要とされる処理を実装
  - トランザクションの処理や業務のフローの実装など
プレゼンテーションテクノロジー
- 様々なデバイスからアクセスされることを考慮する必要がある
- 人だけでなく、物も含め、企業システムに対してアクセスするためのインターフェースを提供

1.2.2 Java EEに含まれる機能

Java Persistence API(JPA)
- ORM機能
- JavaSEでも利用可能
Java Messagge Service(JMS)
- 外部のメッセージングプロバイダを経由して非同期でテキストメッセージやバイナリメッセージを送受信
- JavaSEでも利用可能
Batch Applications for the Java Platform
- データをまとめて一括処理する場合に利用
- JavaSEでも利用可能
Java Mail API
- 電子メールクライアントを作成するために必要な機能を提供
Java EE Connector Architecture(JCA)
- EAIを行うために必要な機能を提供
DI/CDI
- JavaEEに含まれる技術を疎結合で結び合わせるための技術
Enterprise JavaBeans(EJB)
- もともと、分散コンポーネントを作成するための技術として作られました
- JavaEE5以降、EJBはビジネスロジックを簡単に実装するための技術として大きく生まれ変わりました
- XMLの設定は不要で、クラスに対して宣言的に定義できるようになっています。
Java Transaction API(JTA)
- トランザクション管理を行うための技術
JavaServer Pages(JSP), JSP Standard Tag Library(JSTL)
- JSPは動的ページ作成
- JSTLは、ページ内のループ処理やSQLを使用したデータベースアクセスなど、JSPで共通する機能を隠蔽して利用できるようにした専用タグ
  - JSFの導入以降は徐々に置き換えが進む
JSON-P
- JavaEE7から新たに導入されたJavaEEでJSONを扱うための機能
- 次期バージョンでは、JSONデータとJavaオブジェクトをマッピングするJSON Bindingの提供も予定されている
  - → もう対応されている？
Expression Language(EL)
- 簡単な式や変数などを用いて、記述内容の評価が行える言語として作られました
Servlet
- ServletのプログラムはServletコンテナ（Webコンテナとも呼ばれる）と呼ばれる実行環境上でどうsあ
- HTTP/1.0及び1.1のリクエストに応答する
- ServletはHTTP処理に対する低レベルAPIしか提供しないため、現在はServletのAPIだけでプログラミングを行う場面は少ない
- JSFのようなServletコンテナ上で動作する上位フレームワークへ処理を以上するための仲介役として利用されることが多い
WebSocket
- HTTPプロトコルをアップグレードした、双方向/全二重通信が可能なプロトコル
- HTTPと比べてメッセージ送受信の際のオーバーヘッドが少ないため、効果的にリアルタイムメッセージの送受信ができる
Java API for RESTful Web Services(JAX-RS)
- RESTアーキテクチャに基づいてWebサービスを実装するための機能を提供
- 従来、Webサービスの実装にはSOAP Webサービス(JAX-WS)とXMLを用いるのが主流だった
- 現在は、分散システム間連携を行うために、RESTful WebサービスとJSONを組み合わせて実装する場面が多くなっている
- JAX-RSの仕様は、HTTPの仕様と密接に関連しており、HTTPメソッドに対応するアノテーションを用いて処理を実装する
  - JAX-WSからJAX-RSへと主流が変わってきたことを理解した
JavaServer Faces(JSF)
- コンポーネントベースで開発が可能なWebアプリケーション開発フレームワーク
- 画面は、フェースレット（Facelets）と呼ばれるXHTML形式のテキストファイルに、HTMLタグやJSF専用タグを記入してデザイン
- バックエンドの処理はマネージドビーン（Managed Bean）と呼ばれるPOJOクラス、もしくはCDIクラスで処理を実装
- JSFは標準でHTML5やAjaxへも対応しており、Javascriptの知識がなくても簡単にAjaxプログラミングが行えます
ビーンバリデーション
- データの整合性を検証するための機能
Common Annotation
- JavaEE5でMetadata facility for Javaという機能が追加された
- これに関連して、JavaSE環境、JavaEE環境の両方で共通して利用可能なアノテーションが定期された
- 例えば
  - インスタンスの生成時、破棄時になんらかの処理を行うことを規定したもの
  - 処理に対する実行権限を規定したもの
  - データベース設定を規定したもの
- これらのアノテーションを利用して宣言的にプログラミングを行う
Managed Bean
- Common Annotationの中に、Managed Beanというアノテーションがある
- JavaEE環境で管理されているBeanであることが明示される
- Managed Beanは、アプリケーション・サーバーで管理されているリソースの参照や、インスタンスのライフサイクル管理ができる
- 通常、Managed Beanのアノテーションを付加したクラスを実装することはほとんど無い
  - しかし、Managed Beanの機能を持つ上位機能（CDI、EJB）でManaged Beanの機能を利用する
Interceptors
- 複数の機能間で横断的な関心事の実装を行うための機能です。
- 例えば
  - ログの出力や各処理時間の計測、セキュリティの検査などは、特定部分の実装に限らず、システムの全体で必要な実装
Concurrency Utilities for Java EE
- JavaEE環境で新たにスレッドを生成するための機能
- JavaEE6まではサーバー環境上で新たなスレッドを生成することは非推奨でした。なぜならば、作成されたスレッドがアプリケーション・サーバーから管理できないスレッドとして動作するためでした
- たとえば
  - セキュリティ情報や、トランザクション情報、コンテキスト情報などを一切含まないため、アプリケーション・サーバーから制御することは不可能
- そこで、サーバーが管理できるスレッドを作るために、JavaEE7からConcurrency Utilities for Java EEが新たに導入された

1.2.3 Java EE の仕様策定

Javaの仕様はJCP(Java Community Process)という団体で管理
- Java Specification Requests(JSR)と呼ぶ仕様のリクエストに対して、一意の番号を割り当てて管理している
JSRをJCPに提出するために必要な成果物について記載（割愛）

1.2.4 Java EEの実行環境とプロファイル

割愛

1.3 Java EEアプリケーション開発の基本

1.3.1 Java EEアプリケーションモデル

3階層アプリケーションの開発モデルを採用している
- ビジネスロジックとユーザーインターフェースを切り分けて実装することが大事
- 柔軟性の高いシステムを構築していくことが大事

1.4 開発環境の準備

サンプルアプリケーション
- JavaSE8
- JavaEE7
- GlassFishv4.1.1 (JavaEE参照実装)

1.4.1 Oracle JDKのインストール

1.4.2 NetBeansのインストール

1.4.3 NetBeansの起動

1.5 サンプルアプリケーションの概要

1.5.1 ナレッジバンク

個人が保有する知識情報（ナレッジ）を共有するためのWebアプリケーション
JavaEE7で一般的なWebアプリケーションを実装するために必要な機能を使用して構築されている
画面遷移などの説明

1.5.2 ナレッジバンクのセットアップ

プロジェクトを読み込み

1.6 まとめ

この章のまとめを記載（割愛）

Chapter 2 プレゼンテーション層の開発――JSFの基本

以下の３層に分けて開発を行う
- プレゼンテーション層
- ビジネスロジック層
- インテグレーション層

2.1 JSF概要

2.1.1 JavaSErver Faces(JSF)とは

JSFとはJavaEE5から追加されたプレゼンテーション層を作成するための仕様
- 今まではServletを使用していた
  - サーブレットとは：ブラウザとHTTP通信を行う基礎的な仕様で、最小限の機能を提供
    - 入力値とJavaオブジェクトのマッピング
    - 入力値のチェック
    - エラーメッセージのハンドリング
      - など多くの機能が不足していた
Column MVC1.0
- 次のバージョンのJavaEE8には、「MVC1.0」というプレゼンテーション層を開発する新しい仕様が加わる予定
- Webアプリケーションを開発するフレームワークには、HTTPの通信に紐付けて処理を記述するアクションベースのフレームワーク
- 入力フィールドやボタンに紐付けて処理を記述するコンポーネントベースのフレームワークがある
- 本書で記述するJSFはコンポーネントベースのフレームワーク
- そのため開発者から、アクションベースの選択肢も必要という意見があがり、JavaEE8でアクションベースのフレームワークである「MVC1.0」を追加することになった

2.2 JSFの構成要素

2.2.1 画面と処理（フェースレットとマネージドビーン）

フェースレットとは
- 画面レイアウトを記述するXHTMLベースのテンプレートエンジン
- XHTMLとは、HTMLをXMLの文法に適合するように定義し直したもの
フェースレットとBeanがどのように紐付いているかを確認
Column マネージドビーンとバッキングビーン
- フェースレット似バインドするJavaクラスはマネージドビーンといいますが、
- フェースレットの裏側で処理を行うという意味で、バッキングビーンと呼ばれることもあります。
- マネージドビーンがCDIでも代用できるようになった頃からJSFで使用するマネージドビーンをバッキングビーンと呼ぶことが多くなった

2.2.2 マネージドビーンとスコープ

スコープ：マネージドビーンのデータをいつまで保有するかを指定する
スコープの一覧の紹介

2.3 JSFの画面遷移

2.3.1 画面遷移の方法

JSFで次の画面に遷移する場合、遷移先の名前を文字列で指定
- この画面遷移に使用する文字列を「outcome値」といいます
- 遷移するフェースレットのパスを指定
静的な遷移
- マネージドビーンの処理を行わずに直接次の画面に遷移する方法
動的な遷移
- マネージドビーンで処理を行い、その結果を基に任意の画面へ遷移する方法
- EL式でメソッドをバインドしている

2.3.2 画面のリダイレクト

画面遷移
- フォワード：処理後に直接Web画面を生成して結果を返す
- リダイレクト：一度ブラウザに処理を返した後にサーバーに再アクセスしてWeb画面を生成する
JSFではリダイレクトを使用して次の画面に遷移する方法を提供している
- １画面前のURLを表示することを避けるためにこの機能を提供
  - ?faces-redirect=trueというパラメータを付与すると動くらしい
- 問題：リクエストスコープが効かなくなる
  - 対策：フラッシュスコープという特別なスコープを提供している

2.4 JSFの内部処理

2.4.1 コンポーネント指向

JSFではWebアプリケーションをより直感的に開発するためにコンポーネントという考え方を導入している
メリット
- Web画面と処理の紐付けを直感的に行える（HTTPの理解が不要）
- コンポーネントが再利用しやすい
- Web画面のプロトタイプ作成が容易に行える
コンポーネントツリーとしてアクセスできるJavaクラスが存在するらしい

2.4.2 ライフサイクル

ビューの復元(Restore View)
リクエスト値の適用(Apply Request Values)
入力チェック(Process Validations)
モデル値の更新(Update Model Values)
アプリケーションの実施(Invoke Application)
画面の生成(REnder Response)

最初のアクセスの場合
- ①の復元フェーズ終了後に、⑥の画面生成フェーズに進み、画面を表示
ポストバックの場合
- すでにコンポーネントツリーがあり、値の入力やボタンの操作が実施されているので、
- ①→⑥まで順番に実施

2.5 JSFの基本設定

2.5.1 フォルダ構成

JSFを使用したWebアプリケーションを作成するにはWAR形式のプロジェクトを作成
EAR形式もある
- 複数のWARファイルやJARファイルを１つにまとめてZIPにしたもの

2.5.2 設定ファイル

必要な設定ファイル
- web.xml
- faces-config.xml
- アプリケーションサーバーの設定ファイル
web.xml
- デプロイメントディスクリプタというWebアプリケーションの設定を記述するファイル
  - webアプリケーションの初期設定
  - サーブレットの設定
  - セキュリティの設定
- WebアプリケーションでJSFを使用する場合は、web.xmlにJSFが提供するFacesServletを設定
サーブレットの定義
- JSFは内部でサーブレットを使用している
- そのためJSFを使用するにはJSFのサーブレット指定が必要
- ロードオンスタートアップの指定はサーバーの起動時にサーブレットのインスタンス化と初期化を行うという指定
サーブレットのマッピング定義
- URLパターンとサーブレットの定義で指定したサーブレット名を指定
- URLパターンは「/faces/*」という指定がJSFでは一般的らしい
- facesで始まっている場合に、JSFのアクセスであるとみなされる
faces-config.xml
- JSFの設定を記述するファイル
  - 国際化のせてい
  - フェーズリスなのクラス指定など
アプリケーション・サーバー用の設定ファイル

2.5.3 リソースフォルダ

JSFの仕様でresourcesフォルダに配置するフォルダ構成が決められているらしい
resouces/[ローカルプレフィックス]/[ライブラリ名]/[ライブラリバージョン]/[リソース名]/[リソースバージョン]
- →わかりにくいと感じた

2.6 フェースレットタグライブラリ

2.6.1 タグライブラリの種類

タグライブラリ
- 画面レイアウトで使用するタグを定義したもの
種類
- コアタグライブラリ：他のタグライブラリのサポート的な機能を提供するタグライブラリ
- HTMLタグライブラリ：HTMLのタグを生成するタグライブラリ
- フェースレットテンプレーティングタグライブラリ：画面のテンプレート処理や繰り返し処理などを提供するタグライブラリ
- コンポジットコンポーネントタグライブラリ：コンポジットコンポーネントの作成に使用するタグライブラリ
- JSTLコア/ファンクションタグライブラリ：JSPで使用するタグライブラリ
最も使用頻度が高いのは「HTMLタグライブラリ
JSTLコア/ファンクションタグライブラリ：JSPというJavaEEの仕様で使用するライブラリでJSFでも使用できるが、他のフェースレットが提供するタグライブラリとの実行タイミングが違うため不具合が発生しやすく、基本的に利用しない
※ここで再確認
- JSF
  - フェースレット
    - フェースレットタグライブラリ
    - EL式
  - マネージドビーン
タグライブラリを利用するには、冒頭でネームスペースの宣言が必要

2.6.2 HTMLタグライブラリ

一覧を表で記載（割愛）

2.6.3 ヘッダーとボディ

<h:head> <h:body>

2.6.4 リソース

2.6.5 文字の出力

2.6.6 リンクとボタン

(割愛)

2.7 EL（Expression Language）

2.7.1 ELとは

ELとは、演算の結果や値の参照結果を返却するための簡易記法
#または、$で始まり、波括弧で囲んだ中に式を記述
- $を使用した場合：ページがレンダリングされた時点で即時評価
- #を使用した場合：コンポーネントに式として渡され、ライフサイクルのタイミングで遅延評価される
  - JSFでは基本的に$を使用せずに、#を使用する

2.7.2 オブジェクトの参照

@Namedを付与したマネージドビーンの名前はEL式から参照できる

2.7.3 暗黙オブジェクト

暗黙的に参照可能なオブジェクト一覧を記載（割愛）

2.7.4 演算子

算術演算子
関係演算子
論理演算子
三項演算子
空演算子
- empty a : aがNullまたは空文字の場合trueを返す

2.7.5 メソッドの呼び出し

メソッドも呼び出せるよって言う説明（割愛）

Chapter 3 プレゼンテーション層の開発――JSFの応用その1

3.1 入力チェック

3.1.1 入力チェック（バリデーション）とは

JSFのライフサイクルの中にある
JSFでは入力した値をチェックする機能を提供している
バリデーションの方法として以下の２つを提供
- JSFの初期から提供されているJSFのバリデーション
- JavaEE6で導入されたビーンバリデーション★

3.1.2 JSFのバリデーション

バリデーションタグを利用する（割愛）

3.1.3 JSFのカスタムバリデータ

細かなチェックをするために独自でバリデータを作成する方法
- メソッドを作成する方法
- クラスを作成する方法

3.1.4 ビーンバリデーションとは

ビーンのフィールドにアノテーションを付与するだけでチェックができる

3.1.5 ビーンバリデーションのバリデータ

ビーンバリデーションのアノテーション一覧
- @NotNull
- @Null
- @Max
- @Min
- .....
point: 入力値が空文字の場合NULL値として扱う場合、web.xmlにパラメータを追加する必要がある
- javax.faces.INTERPRET_EMPTY_STRING_SUBMITED_VALUES_AS_NULL

3.1.6 ビーンバリデーションのエラーメッセージ変更

メッセージを変更する方法は２つある
- アノテーションに、message属性を指定する
- propertiesファイルで管理する
  - 多言語対応などする場合、こちらが得策

3.1.7 ビーンバリデーションのバリデータ統合

MEMO: ★このテクニックは覚えておきたい
入力チェックに複数の条件がある場合には、フィールドに標準のアノテーションを複数設定するが、同じような条件を何度も設定するのは面倒なので、アノテーションを作成してまとめる

3.1.8 ビーンバリデーションのカスタマイズバリデータ

ビーンバリデーションのカスタマイズも可能
- MEMO:（実装方法省略）

3.2 コンバータ

3.2.1 コンバータの役割

Web画面に表示する文字列とマネージドビーンのプロパティで保持するJavaのオブジェクトを変換するための仕組み
JSFにより自動的に変換されるオブジェクトも存在する
- short
- int
- long
- float
- double
- boolean
- byte
- char
- BigInteger
- BigDecimal
JSFでは任意のフォーマットで画面表示を行うため、標準のコンバータを提供している

3.2.2 標準のコンバータ

JSFが標準で提供するコンバータは、日付や数値とおじ列を相互に変換するコンバータ
- f:convertDateTime
- f:convertNumber

3.2.3 カスタムコンバータ

独自で作成したクラスなどの標準のコンバータでは対応できないクラスでは、独自にコンバータを作成する
- JSFが提供するjavax.faces.convert.Converterインターフェースを実装したクラスを作成する
MEMO: 確かに変換が必要な場面は絶対あるはずなので、thymeleafとかがどのように変換を持っているか確認する
- 他のフレームワークでも、convertを実装する方法を書いていた
  - https://qiita.com/alpha_pz/items/21c6eda2fe227abfa403
MEMO: DBSlectした結果をList(category)にかかえているような書き方をしている

3.3 コンポーネントのカスタマイズ

JSFではフェースレットが提供するコンポーネントを使用してWeb画面を作成
独自のコンポーネントを作成することもできる
方法として２つある
- コンポーネントクラスを作成するカスタムコンポーネント
- フェースレットでコンポーネントを組み合わせて作成するコンポジットコンポーネント★

3.3.1 コンポジットコンポーネント

１つのフェースレットファイルを作成するだけで、複数の画面で使い回せるコンポーネントを作成することができる
- MEMO: thymeleafでincludeしている感じと同じ

3.3.2 より高度なコンポジットコンポーネント

<!-- テンプレート側 -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://xmlns.jcp.org/jsf/html"
      xmlns:knowledge="http://xmlns.jcp.org/jsf/composite/knowledgecomp">
    <h:head>
        <meta charset="UTF-8" />
        <h:outputStylesheet library="css" name="style.css" />
        <h:outputScript name="jsf.js" library="javax.faces"/>
        <h:outputScript library="js" name="application.js" />
        <title>Knowledge Bank</title>
    </h:head>
    <h:body>
        <div id="top_content">
            <h:form id="form">
                <h1><h:graphicImage library="img" name="logo.png" /></h1>
                <div class="notice">
                    #{flash.notice}
                </div>
                <knowledge:login userId="#{loginBean.userId}" password="#{loginBean.password}" loginButtonAction="#{loginBean.login()}"/>
                <div>
                    <h:link outcome="account/register" value="アカウント登録"/>
                </div>
            </h:form>
        </div>
    </h:body>
</html>

<!-- 利用する側 -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://xmlns.jcp.org/jsf/html"
      xmlns:knowledge="http://xmlns.jcp.org/jsf/composite/knowledgecomp">
    <h:head>
        <meta charset="UTF-8" />
        <h:outputStylesheet library="css" name="style.css" />
        <h:outputScript name="jsf.js" library="javax.faces"/>
        <h:outputScript library="js" name="application.js" />
        <title>Knowledge Bank</title>
    </h:head>
    <h:body>
        <div id="top_content">
            <h:form id="form">
                <h1><h:graphicImage library="img" name="logo.png" /></h1>
                <div class="notice">
                    #{flash.notice}
                </div>
                <knowledge:login userId="#{loginBean.userId}" password="#{loginBean.password}" loginButtonAction="#{loginBean.login()}"/>
                <div>
                    <h:link outcome="account/register" value="アカウント登録"/>
                </div>
            </h:form>
        </div>
    </h:body>
</html>

Column: コンポーネントで利用可能な暗黙オブジェクト
- カスタムコンポーネント内でよく利用する暗黙オブジェクト
  - cc: コンポジットコンポーネントの情報が取得できる
  - component: 現在のコンポーネントの情報や、親や子のコンポーネントの情報にアクセスすることができる

3.4 フェースレットテンプレート

3.4.1 フェースレットテンプレートの利用

ヘッダーやサイドバーなどはテンプレート化して管理する説明
- こっちがthymeleafのincludeに近い

3.5 HTML5フレンドリマークアップ

JavaEE7(JSF2.2)からHTML5の進化へ対応するためにフレンドリマークアップという機能が導入された
- 以前のJSFでは任意の属性をHTMLとして出力する場合にコンポーネントをカスタマイズして提供していた
画面デザインをWebデザイナーが行い、リッチなWeb画面を作ることが一般化

3.5.1 パススルーアトリビュート

3.5.2 パススルーエレメント

3.6 Ajax

3.6.1 JSFのAjax対応

一般的なAjaxの作りでは、データの取得処理や画面の再描画処理をJavascriptで記述する必要がある
JSFのAjax機能を利用するとJavascriptをほとんど記述せずにWeb画面の部分更新が可能
Ajax専用のタグを使用して、結果をRenderingしている
MEMO: 専用のタグでAjax処理ができるのは、コンポーネントベースのフレームワークであるJSFの特徴だと感じた

3.6.2 Ajaxを使用した入力チェック

3.6.3 Ajaxのイベントハンドリング

イベント実行中や完了、エラー発生時の処理を記述するための方法
共通化するための方法を紹介

Chapter 4 プレゼンテーション層の開発――JSFの応用その2

4.1 認証／認可

4.1.1 認証/認可の仕組み

JavaEEのログイン機能を実現するための認証認可の仕組みについて
ログイン機能を利用する手順
1. アプリケーションサーバーの認証/認可設定をする。
2. アプリケーションの認証/認可設定をする。
3. プログラムでログイン/ログアウト機能を作成する。

4.1.2 アプリケーションサーバーの認証設定

アプリケーション・サーバーに認証の設定を行う必要がある
- 認証データの指定先に
  - ファイル
  - データベース
  - LDAPサーバー　などを指定する
ナレッジバンクではデータベースを指定している
Glasfishを使用した認証の設定方法を説明
Glasfishの管理コンソール
- http://localhost:4848/
認証設定を行うには
- Configurations＞server-config＞Security＞Realms＞New
ナレッジバンクではJDBCレルムを使用するので
- ClassNameにJDBCRealmを選択する

4.1.3 アプリケーションの認証設定

アプリケーションサーバーの認証設定が終了したら、
今度はアプリケーションの認証設定を行う

4.1.4 ログイン/ログアウト機能の作成

Oracle18cで接続を試していたがどうしてもうまく行かなかった
Oracle11gだとすぐにうまく行った
ログインの仕組みを作って、
実際にloginのfaceletでコンテキストのログインメソッドを呼び出して、認証を済ませる
- MEMO: springsecurityみたいなやつ　認証設定は必ず実装しておく

4.2 国際化

4.2.1 JSFの国際化

プロパティファイルでロケール管理して、faces-config.xmlで切り替え
UIViewRootクラスのgetLocaleメソッドやsetLocaleメソッドでも切り替えることができるみたい
- MEMO: ロケール切り替えは実装しておくべき

4.3 ブックマーカビリティ

4.3.1 ブックマーカビリティとは

JSFでは最初にブラウザからアクセスが来た際に、処理をせずに画面を表示する
しかし、Webアプリケーションでデータの一覧や詳細を表示する画面では、なにかしらの事前処理やデータの取得処理が必要
- そこで、JSFでは初回アクセス時に処理を実施する機能を提供している
使い方について説明（割愛）

4.4 フェーズリスナ

JSFのライフサイクル
1. ビューの復元(Restore View)
2. リクエスト値の適用(Apply Request Values)
3. 入力チェック(Process Validations)
4. モデル値の更新(Update Model Values)
5. アプリケーションの実施(Invoke Application)
6. 画面の生成(REnder Response)
フェーズ前後で横断的に行う処理はフェーズリスナを使用する

package knowledgebank.web.listener;

import java.util.logging.Logger;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;

public class KnowledgePhaseListener implements PhaseListener {

    Logger logger = Logger.getLogger(KnowledgePhaseListener.class.getName());

    @Override
    public void beforePhase(PhaseEvent event) {
        logger.info(event.getPhaseId() + " beforePhase");
    }

    @Override
    public void afterPhase(PhaseEvent event) {
        logger.info(event.getPhaseId() + " afterPhase");
    }

    @Override
    public PhaseId getPhaseId() {
        return PhaseId.ANY_PHASE;
    }
}

4.5 Java EE 7で導入されたJSFの機能

4.5.1 JSF 2.2 の追加機能

JSF2.2の仕様には大きな特徴として以下の４つが紹介されている
- HTML5フレンドリマークアップ（パススルーアトリビュートと、パススルーエレメント）
- リソース・ライブラリコントラクト
- Faces Flows
- ステートレスビュー

4.5.2 リソース・ライブラリコントラクト

リソースの塊を簡単に切り替えることができる仕組み

あまり便利に思わなかった

4.5.3 Faces Flows

フロー処理について記載されている
スコープを設定ファイルやJavaアノテーションで保持できるみたい
- MEMO: 他のフレームワークではどのようにスコープ持っているのか確認

4.5.4 ステートレスビュー

状態を保持しないビューを作成する機能
JSFでは画面を表示する際にサーバー側似コンポーネントツリーを作成し、同一画面を表示している間はそのコンポーネントツリーを保持していると説明しました。
ステートレスビューを使用すると、そのコンポーネントツリーを毎回破棄市、アクセスが来るたびに再作成する動きに変わる
ステートレスなアプリを作る上で欠かせない
- MEMO: 他のフレームワークの場合は、redisなどでセッション管理している

4.6 まとめ

ここまでの内容を理解していれば、十分JSFを使用してWebアプリケーションを作成することができる
紹介していないライブラリ
- PrimeFaces
- RichFaces
- OmniFaces
MEMO: 時間があれば見てみる程度で良いかも

Chapter 5 ビジネスロジック層の開発――CDIの利用

本章と次章ではCDIとEJBについて解説
本章ではCDI
- CDIとEJBの違いについて解説
- CDIがJavaEEに採用された経緯
- CDIの機能　について解説

5.1 CDIとEJB

5.1.1 ビジネスロジック層の部品

CDI,EJB
- いずれも「ビジネスロジック」を記述するための部品である
CDI
- JavaEE6から採用された新しい技術
EJB
- Java2Enterprise Edition（J2EE）の頃から存在する歴史ある技術

5.1.2 CDIとEJBの違い

CDIとEJBの違いは「設計の柔軟性」
CDIの方が自由度が高い

5.2 DI（Dependency Injection）

CDIについて知る前にDIについて理解しておく必要がある
DIが考案された歴史的な背景をたどって、CDIの意義について知ることにする

5.2.1 DIとは

DI
- 部品間の依存関係を少なくすることで、部品の分離と結合をコントロールするための考え方、及びその仕組みのこと
「依存」とは、クラス同士が強いつながりを持つことを意味している
直接クラスを宣言し、インスタンス化している強い依存関係は、それ自体で処理が完結しているプログラムモジュール、例えば、
ビジネスロジック層でしか動かないクラス間の依存については問題ありません。
一方で各層をまたがる依存関係はできる限り弱い方がよいという考えがある
依存関係を弱く保つことができれば、変更点は少なくてすむ

5.2.2 DIによる依存関係の解消

DIコンテナがあれば、実行時に動的にクラスを選択できる
用途としては以下
- ある条件において別の実装クラスを必要とするケース
  - 処理の流れ自体は変わらないが、ユーザーやリクエストの状況に応じて手続きが異なる、あるいは出力先が異なる
- テストや開発中のモック入れ替え
  - 層をまたぐ処理や開発中のクラスを利用しなければならないときに、仮となるモックを利用し、将来的に完成したクラスを入れ替える場合。
  - あるいはテストデータを返却するテスト用のモックと完成したクラスを入れ替える場合
COLUMN ファクトリメソッドパターン
- DIが実現している実装の入れ替えは、ファクトリメソッドパターンと呼ばれるデザインパターンを採用することでも実現可能
- ファクトリメソッドパターンはオブジェクトの生成を管理するクラスを設けることで、任意の振る舞いを持つオブジェクトを取得する方式
- ただし、ファクトリメソッドパターンを利用していても、結局返却するインスタンスを選択する処理をソースコードに記述しておく必要があり、
- インスタンスをソースコード外で管理するには、プロパティファイルなどを用いる必要があるので、そうするよりはDIコンテナを利用するほうが楽
- MEMO: 再読

5.2.3 JavaEEへのDI取り込み

( 割愛 )

5.3 CDI

CDIとはJavaEE6から導入されたJavaEEアプリケーションサーバー上でDI機能を提供するための仕様
CDIを使用するために必要な定義
- インジェクションポイント：@Injectが指定された変数
- CDIビーン：スコープに関するアノテーションが付与されたクラス
Column 設定ファイル beans.xml
- JavaEE7 からCDIを使うための設定ファイルであるbeans.xmlは特定の用途を除き不要になりました
- beanx.xmlはインジェクションポイントとCDIビーンの関係性を記述するためのものでしたが、現在では自動的に解決する用になっている
CDIの利点
- インジェクションを行うのが簡単（アノテーションのみで設定ファイル不要）
- DIを基礎とした様々な機能があらかじめ準備されている

5.4 CDI基本編

CDI限定子：複数のインジェクション候補クラスが存在する場合に、クラスを特定するためのアノテーション javax.inject.Qualifier

5.4.1 CDIコンテナによるインジェクション

CDIコンテナに存在するスコープを過ぎたオブジェクトは破棄される

5.4.2 CDIの型解決方法

CDIがインジェクションポイントに対して注入する対象となるインスタンスを解決する方法は２通りある
- インジェクションポイントと対象インスタンスが１対１の場合（自動解決）
- CDI限定子もしくは、beans.xml(@Alternative)で解決する方法
結論：CDI限定子（Qualifier）を使用して書いていくのがよい
- 設定ファイルも必要ないし、ソースコードを柔軟に変更しながら開発ができるため
Column インターフェースを利用するべきか
- 結論：インターフェースは準備しておくべき

5.5 CDI応用編

CDIに関わる応用的な利用方法について記述
CDIの付加機能
- イベント処理：CDIビーン上である条件を満たした場合に、別のクラスに対して通知を行う機能
- ステレオタイプ：複数アノテーションをまとめて定義する機能
- プロデューサ/ディスポーザ：クラスではなく、フィールドそのものやメソッドの戻り値をインジェクションポイントに注入する機能
- インターセプター/デコレータ：処理の前後に別の処理を入れ込んだり、追加したりする機能

5.5.1 イベント処理

イベント処理とは
- 設定した閾値を超えるなど、特定の条件を満たす情報が発生したとき、その通知と情報をやりとりすることを指す
- CDIではイベント発火はCDIビーン上で行い、それを処理するクラスを特別な呼び方として「オブザーバ」と呼ぶ
イベント処理の実装
- イベント情報を格納するクラスを準備する
- イベントを発火するCDIビーンを作成する
- オブザーバクラスを作成する
イベント処理の留意事項
- イベント発火からオブザーバの処理までがすべて同期で実行される
- 非同期だと勘違いしないように
- 参照関係を持たず、プログラムモジュール間似おける情報のやり取りを非同期で実行したい場合には、次章で説明するJMSを利用するなど別の方法を検討する必要がある

5.5.2 ステレオタイプの利用

複数のアノテーション定義をまとめて管理できる
@StereoTypeを付与してまとめていく
上書きもできるが、あまり上書きしすぎると良くない
MEMO: 管理方法について
- パッケージ名をstereotypeで切って管理する
- クラス名称の接尾字にTypeをつけておくとアノテーションがステレオタイプで有ることを明示できる
MEMO: Springでもまとめていくアノテーションあるか

5.5.3 プロデューサ/ディスポーザの利用

プロデューサを利用すると、インジェクションポイントに注入するオブジェクトをプログラム上で動的に変更することができる
プロデューサにより作成されたオブジェクトが終了処理の必要なオブジェクトである場合、ディスポーザを利用することで終了処理を記述することができる
プロデューサアノテーションをメソッドに付与して戻り値に@Inject指定した変数と同じ型を指定してあげる
メソッドで処理されたあとのオブジェクトがDIコンテナに格納され、インジェクションされる
Disposesアノテーションは、Producerメソッドで提供されたクラスの終了処理を行うためのディスポーザ
MEMO: Springにもこの概念があるかどうか確認

5.5.4 インターセプタとデコレータ

インターセプターとデコレータについて解説
- すでに作成済みのメソッドの処理に対して、外部のクラスを用いてその処理の前後や、処理内容に変更を加えることができる技術
インターセプター：対象となる処理の前後やライフサイクルに応じて処理を行うための仕組み
定義方法
- @Interceptorを付与したクラスを作成、メソッドに特定のアノテーション付与して機能に関与しない処理を実装
- 利用側のメソッドで@Interceptors()の引数に作成したインターセプタークラスを追加する
- または、beans.xmlに使用するインターセプターを定義する
Column どこでインターセプターを定義する？
- 機能処理内にインターセプター（非機能処理）を記載するのはナンセンス
- beans.xmlで管理する方が良いのではという意見が記載されている
デコレータ：機能追加をするための仕組み
- 共通のインターフェースを実装したクラスに処理を委譲する
MEMO: デコレータの使い所について確認
- Springで同様の機能あるかどうか
- インターセプター＝AOP？こちらも使い所についてまとめておく

5.6 まとめ

機能が非常に豊富であることと、ルール似基づいた設計と実装が必要であることをご理解いただけたと思います。

Chapter 6 ビジネスロジック層の開発――EJBの利用

6.1 Enterprise Java Beans（EJB）

6.1.1 EJBとは

アプリケーションサーバー上で動作するJavaのプログラムのうち、特に「ビジネスロジック」を担当する部品を指す
EJBは
- サーブレットやJSF、Webサーバーなどアプリケーションサーバー外からのリクエストを受け付ける層と
- データベースなどへ情報の永続化を行う層の中間の層の部品として機能する
機能 EJB3.2
- トランザクション制御
- Java Persistence APIを介した永続化処理
- Java Messageing Serviceを介したメッセージ駆動処理
- 非同期実行制御
- 同期実行制御
- スケジュールに基づいた実行
- JNDIを介したインスタンス取得（現在はアノテーションを利用）
- リモートクライアントからの実行
- セキュリティ

6.1.2 EJBの利点

JavaEETutorialを参考
EJBの利点
- EJBコンテナがシステムレベルのサービスを提供してくれるため、開発者はビジネスロジックの構築に集中できる
- クライアントとの分離。クライアントにはビジネスロジックを実装する必要がない
- JavaEE準拠のアプリケーションサーバー上であればどこでも動く

6.1.3 EJBの種類

３種類ある
- セッションビーン
- メッセージドリブンビーン
- タイマー

6.2 セッションビーン

6.2.1 セッションビーンとは

EJBの中核を成すコンポーネント

6.2.2 セッションビーンの種類

セッションビーンの種類
- ステートレスセッションビーン
- ステートフルセッションビーン
- シングルトン
- タイマー

6.2.3 ステートレスセッションビーン

一番良く利用されるEJBであり、ごくシンプルで基本的なEJB
ステートレスセッションビーンのクラスに@Statelessを付与
利用側は@EJBを付与して使用する
@Statefulアノテーションを利用する
留意点
- クライアントごとにステートフルセッションビーンのインスタンスが作成される
サーブレットからステートフルセッションビーンを呼び出す場合、
通常サーブレットは１リクエストスレッドにより１つのインスタンスが利用されるモデルであるため、
状態を保持できない
ライフサイクルの制御
- 生成
- 活性化
- 非活性化
- 破棄
非活性化されると、メモリ外にシリアライズ処理され出力される。
必要になるとデシリアライズされ、メモリ上に復帰する

6.2.5 シングルトンセッションビーン

@Singletonアノテーションを付与
設定ファイルの読み出しの管理などで使う
COLUMN @Startupアノテーション
- デプロイされたアプリケーションが有効化されたタイミングですぐにオブジェクトを生成するよう、アプリケーションサーバーに支持するもの
- @DependsOnというアノテーションもある
  - 初期化の依存関係を解消するためのもの
- MEMO: Springの場合初期化のアノテーションは何を使っているか

6.2.6 非同期処理

実装には「@Asynchronousアノテーション」を使用
クラスかメソッドに定義する
- クラスの場合はすべてのメソッドが非同期になる
- メソッドの場合は対象メソッドのみ非同期になる
MEMO: Futureインターフェースを介した操作について理解する
Column 非同期処理の再実行
- EJBの非同期実行には処理の再投入（再実行）のためのAPIは定義されていないので
- 自前で実装するか、他のアーキテクチャを利用する方法も検討する
- キューを利用して後述のメッセージドリブンビーンを使うなどが考えられる

6.2.7 トランザクション

@TransactionManagementアノテーション
@TransactionAttributeアノテーションを使用するらしい

詳しい使い方については割愛

6.3 メッセージドリブンビーン

メッセージドリブンビーン（Message Driven Bean: MDB）について解説していく
- メッセージと呼ばれるものを受け取ることで起動するという用途が限定的なコンポーネント

6.3.1 メッセージドリブン便とは

MEMO: JMSも理解を深める必要あり
JMS
- キューまたはトピックと呼ばれる方式を利用して、主にシステム間やアプリケーション間の情報を受け渡しを行うための仕組み
Column キューとトピック
- キューとトピックの違いは、送信元と受取側の数の違いにある
  - キュー：１対１
  - トピック：N対M（多対多）
メッセージの受取を担当するのがメッセージドリブンビーン
MDBは常にキューまたはトピックにメッセージが配信されるのを待機し、監視している

6.3.2 実装例

割愛

MEMO: JMSの使用方法とSpringJMSを使う

6.4 タイマー

6.4.1 タイマーとは

EJBには時間を指定して起動するための「タイマーサービス」というものが定義されている

タイマーはバッチ処理とは異なるので、むやみに使用するべきではない

使用方法は以下の２種類存在する
- TimerServiceAPIから登録する
- @Scheduleを使って登録する

6.4.2 タイマーサービスのサンプル

割愛

6.4.3 @Scheduleの実装サンプル

割愛

6.5 EJBの設計

EJBというのはあくまでビジネスロジックの実装を任されているコンポーネント
アプリケーションはビジネスロジックだけでは成り立たない
ブラウザの画面などのプレゼンテーション層
Webサービスなどのロジック呼び出し部分、データベース接続などの永続化層、外部サービスの呼び出しなどもある
EJBはこれらの処理の中間に位置することになる
EJBを設計する上でまず考える必要があるのは、この「外部の層との接点」

6.5.1 EJBメソッドの呼び出しに関する設計

（１）やり取りする情報を保持するクラスを作成し、サーブレットとEJB双方から共通のクラスとして参照する
- あまりにも多くの情報を保持し、データベースへの永続化が終わるリクエストの最後まで保持し続けるような長寿クラスにならないように注意する必要
（２）引数が増えた分についてはメソッドをオーバーロードして対応する
- 注意：公開するメソッドが増えて、Webサービスのエンドポイントになるような場合はWSDLの変更が発生するため注意
Column JSPからのEJB呼び出し
- 画面生成とビジネスロジックの分離ができないためやめた方がいい

6.5.2 ローカル呼び出しとリモート呼び出し

リモート呼び出しは可能な限り使わないことをおすすめする
リモート呼び出しが必要なパターン
- バッチの実装
- GUIを持つクライアントからのビジネスロジック呼び出し
- 多段アプリケーションサーバー構成（処理量による業務分離、接続形態によるレイヤー分割）
代替手段としてはEJBはローカル使用のみにしておき
- JAX-RSなどを使用した層を準備することが考えられる
MEMO: JAX-RS層について深堀り

6.5.3 同期/非同期

基本的に非同期にするメソッドはいかに絞るとよい
- すぐに結果を必要としないもの
- 結果を得るのに相応の時間がかかる処理

6.5.4 負荷量

MEMO: 設計する際の負荷について考えるべき

6.5.5 データベースアクセス

JPA
JPA以外のO/RマッピングもしくはDAOフレームワーク
JDBCの直接呼び出し
通常はEJBと親和性が高いJPAをEJBトランザクション管理下に置くのが容易

6.6 EJBのテスト

6.6.1 EJBのテストの必要性と難しさ

EJBの最大の弱点はテストがしづらいものであった
JavaSEでも必要な資材を準備すれば動くようになったが、一部対応していないらしい

6.6.2 EJBテストの準備

EJBContainerからEJBモジュールを取得し、Junitなどでテストを実施する説明

6.7 まとめ

CDIとEJBをうまく組み合わせて設計していこうという説明

Chapter 7 データアクセス層の開発――JPAの基本

本章と次章では、JavaEEのにおけるデータベースへのアクセス方法であるJPAについて解説

エンティティやクエリといったJPAの構成要素と、JPQLとCriteriaAPIの２種類のクエリについて説明

7.1 JPAの基礎知識

永続化：Javaのプロセスが終了しても、データが消えずに残るような状態にすること

7.1.1 JPAの構成要素

エンティティクラス（データのレイアウトを規定）とエンティティオブジェクト（データを保持）
エンティティマネージャ
- エンティティオブジェクトとレコードの紐付けを管理
クエリ
- データを操作
永続化ユニット
- データベースへの接続情報などJPAの設定を記述する

7.1.2 エンティティクラスとエンティティオブジェクト

そのまま、クラスとオブジェクトという理解
テーブルとレコード　になぞらえて考えられる

7.1.3 エンティティマネージャ

エンティティオブジェクトを取得したり、データベースへ反映、削除したりする
永続化コンテキストの配下にないものは、データベースへは反映されない
persist()メソッドで管理下におくみたい

7.1.4 クエリ

エンティティマネージャが持つ基本的なメソッドを利用する他に、より自由度の高いクエリを用いる方法がある
JPAが用意しているクエリの定義方法
- JPQL: SQLに似た記法で記載でき、DBMSを意識しなくて良い
- Criteria API: APIを使ってクエリを組み立てて行く手法。DBMSを意識しなくて良い
- ネイティブクエリ: SQL文をかいていく必要があるので、DBMSが変わればここも変更しないと行けない
理由がなければJPQLを用いるのが良いだろう

7.1.5 永続化ユニット

永続化似関する設定をまとめたもので、実態はpersistence.xmlという名前のXMLファイル
設定項目としては以下のようなものがある
- 永続化ユニットの名前
- トランザクションマネージャの設定
- 永続化プロバイダ（JPAの実行エンジン）のクラス名
- 永続化プロバイダに与えるプロパティ
- 接続先データソースの名前★
- エンティティクラスの名前★
データベースの接続先を設定する方法
- アプリケーションサーバーで定義されているデータソースの名前を指定する方法
- 永続化プロバイダのプロパティとして、接続先アドレスやユーザー名、パスワードなどを設定する方法　が挙げられる
JPAの実行エンジンにどれがエンティティクラスなのか検知してもらう設定も入れる

7.1.6 JPAのメリット

ResultSetからDTOにうつして..という処理を記述しなくてよい
メソッドかクエリでアクセスできる
コード量が従来よりも少ない
メモリ上にキャッシュされたエンティティオブジェクトを利用できる
- アプリ開発者はキャッシュの有無を意識する必要はない

7.2 エンティティの基本

（割愛）

7.2.1 エンティティクラスの実装

エンティティクラスには@Entityを付与する
publicでなければならず、finalであってはならない
引数のないコンストラクタを作成しとくべき
Column Serializableについて
- EJBのリモート呼び出し
- 複数のアプリケーションサーバーでJPAの２次キャッシュを構成する場合
- MEMO: 他のORMはSerializableに定義しているか確認

7.2.2 ID

エンティティクラスはIDとして定義したフィールドを使用してhashCodeメソッド、
equals(Object)メソッドを実装しなければ行けない→通常IDEで自動生成できる
toString()をオーバーライドしておくとデバッグに役立つ！
MEMO: 他のORMでもtoString()オーバーライドしたりしてるか確認

7.2.3 リレーション

@OneToMany等によるエンティティの紐付け型を説明
MEMO: 他のORMでも存在するか確認
１対１のリレーションについて
- 通常１対１のリレーションだと、同一エンティティに保持してしまうことが望ましい
- ただし、ライフサイクルが異なるデータだと、別のエンティティに分けた方が良いケースがある
- 例）アカウント情報とアカウントに紐づく会社情報
  - アカウント情報：作成されてから削除されるまで
  - 会社情報：入社して初めてできる、会社に所属しなければレコードがない
    - などのような状況

7.3 エンティティマネージャの基本

エンティティマネージャの実態は javax.persistence.EntityManagerインターフェース
このインターフェースに用意されているメソッドを通してエンティティを操作する
EntityManagerのインスタンスはCDIを用いてアプリケーションサーバーからインジェクションで取得する
@PersistenceContextアノテーションを付与し、属性似unitNameを指定
persistence.xmlの<persistence-unit>タグのname属性と一致した名前を指定

7.3.1 エンティティのライフサイクル

ライフサイクル
- NEW
- MANAGED
- REMOVED
- DETACHED

7.3.2 エンティティオブジェクトの作成と永続化

// NEW状態でまだ永続化コンテキストと紐付いてない
Account account = new Account();

// MANAGED状態になる 次のコミットのタイミングでデータベースに反映される
EntiryManager em = xxx;
em.persist(account);

7.3.3 エンティティオブジェクトの取得と更新

// 取得したいEntityクラスとIDを指定
// MANAGED状態で取得される
Account account = em.find(Account.class, 0);

// setter経由で値を設定するとデータベースに反映される（コミットしたタイミングで）
account.setName('てらだよしお');

7.3.4 エンティティの削除

em.remove(account);

7.3.5 デタッチ

EJBのメソッドの外へ出るとDETACHED状態になる

MEMO: 通常アプリでEntityクラスをそのまま画面で使用することは良くないと考える

7.4 クエリAPI

JPQLとCriteriaAPIを使ったQuery作成方法を記載

7.4.1 パラメータ

JPQLとCriteriaAPIはパラメータを取ることができるパラメータは位置で指定する方法と名前で指定する方法があるが通常は名前で指定した方がよい

MEMO: 名前で指定するルールを作った方が良さそう

7.4.2 サンプルデータ

ダウンロードデータの中にあるサンプルデータについての説明

7.5 JPQL

JPQL(Java Persistence Query Language)

7.5.1 JPQLの基本構文

7.5.5 フェッチ

取得するエンティティにリレーションが定義されている場合、リレーション先のエンティティを
どのタイミングでデータベースから取得するかを決めることができる
これを「フェッチ戦略」という
- Eagerフェッチ
- Lazyフェッチ
Eagerフェッチ
- findメソッド実行時に、リレーション定義されている参照先のオブジェクトも取得する
- リレーション先のエンティティオブジェクトを同時に使用することの多い場合は、
- Eagerフェッチを使用する
Lazyフェッチ
- 取得処理時には、リレーション先のエンティティオブジェクトを取得せず、
- リレーション先にはじめてアクセスする際に取得する
- リレーション先のエンティティオブジェクトを頻繁に使用しない場合はLazyにすべき
- デメリット
  - どこでエンティティの取得が行われたか分かりづらい
  - 性能の劣化の場所を特定しづらい
N+1問題とJOINフェッチ
- １回のクエリを発行したあとにN回のクエリの発行を必要とすることをN+1問題という
- リレーションが増えるほど、発行するクエリの数が増える
- これに対応するためにJOIN FETCH節を利用する
- JOIN句の後ろにFETCHがつくだけ

7.5.6 エンティティオブジェクトの集計

シンプルにCountなどを使う方法
型を意識する必要がある場合、コンストラクタ式を利用する必要があるらしい
- 割愛））

7.5.7 名前付きクエリ

開発者はJPQLのクエリに名前をつけることができる
名前をつけられたJPQLのクエリを「名前付きクエリ」と呼ぶ
@NamedQueriesと@NamedQueryを使って名前定義しておく方法
- MEMO: 他のORMはSQLファイルで管理するのではと思う

7.6 CriteriaAPI

Criteriaクエリを利用してクエリを構築していく
JPQLと役割は同じであるため、JPQL同様に以下の要素から構成
- SELECT
- FROM
- JOIN
- WHERE
- ORDERBY

7.6.1 Criteria APIの基本構文

（割愛）

利用のメリットがあまりわかない
- 発行されているSQLが分かりづらい
- SQLNativeでかけない
- メソッドなど覚えなくては行けない

Chapter8 データアクセス層の開発 JPAの応用

エンティティとデータベースの関連付け
キャッシュなどJPAの応用的な使い方について紹介

8.1 高度なエンティティの利用方法

日時を指定する日時型、
連続した一意の数字を設定するシーケンス、
リレーション先のエンティティへ処理を伝播するカスケードを紹介

8.1.1 フィールドに関する応用

日時
- JPAで日時を使用するには、エンティティクラスのフィールドにjava.util.Date型を指定
- @Temporalアノテーションを付与して、引数にTemporalTypeを指定
シーケンス
- エンティティのIDにはサロゲートキーを使用するのが　一般的
- サロゲートキーは人工的に作成されたキーであり、業務上の意味がないもの
- MEMO: 一般的にサロゲートキーが使われているのか確認
- @SequenceGeneratorアノテーションを付与し、作成したシーケンスからエンティティフィールドに自動で値を設定するには
- @GeneratedValueアノテーションを使用する
- MEMO: DBとどのように絡んでくるのか、DB定義側も自動的にシーケンス定義が作成されるのか
  - どのDBもだいたいシーケンス定義を作成できるのか
カスケード
- エンティティオブジェクトに任意の操作をしたあと、リレーション先までその操作を反映させるための機能
- MEMO: 他のORMはどのようにこの機能を持っているか確認
複合ID
- @IdClassか@EmbeddedIdを使用して実装する
  - どちらも主キークラスとして定義する必要あり

8.2 ライフサイクルコールバック

JPAではコールバックメソッドを使用することで、エンティティオブジェクトの操作に対応した処理を実行することができる
実装方法は２種類
- エンティティクラスに実装
  - エンティティの値を変更する場合にとどめてく
- エンティティリスナに実装
  - エンティティの値を変更する処理は実装せず、共通で使用するような処理にとどめておく
- →あまり複雑にならないように注意
MEMO: 他のORMにはコールバックメソッドの仕組みある？どんな処理を実装するのがベター？

8.3 エンティティクラスとテーブル構造

Javaアプリケーション開発者がエンティティクラスを作成すると、JPAはエンティティクラスの定義を読み込み、データベースへテーブルを作成する

MEMO: 他のORMはテーブル自動作成とかされるのか確認

8.3.1 テーブル名とカラム名

エンティティの変数とカラム名を変更する方法について記載

多対多の中間表の名前の付け方
LOB定義 @Lob

8.3.2 索引

索引を作成する方法について記載
- @Index(columnList = "xxxxx,xxxxx,xxxxxx")

8.3.3 制約

精度とスケール、長さ
- @Column(precision=15, scale=0)
- @Column(length=500)
一意制約
MEMO: 他のORMでもDBMSの方言を吸収しながらテーブル定義ができるか確認、できなければJPAってすごい
- 他のシステムも同じDBを参照していた場合、衝突する可能性あるので、AP:DBが対になるようなシステムであればよいかも

8.4 トランザクション

JavaEEには
- EJBコンテナにより自動的に開始されるトランザクション
- Java開発者が任意で開始するトランザクション
  - がある

8.5 キャッシュ

8.5.1 これまでのデータアクセス

8.5.2 キャッシュを使用したデータアクセス

Column 複数アプリケーションによるデータ更新
- 複数のアプリケーションが同一のデータベースを更新する場合や他のノードやデータベースでデータが更新されると、
- キャッシュされているエンティティに伝播されないので、整合性が取れなくなる
- MEMO: かなり致命的な問題だと思う... マスタテーブルに使うとか？
- MEMO: 今キャッシュされているエンティティ情報をログに出力する方法などがあれば可視化されてわかりやすいが、ある？

8.5.5 プリロード

EJBの@Startupなどを利用してアプリケーション起動時に１回だけSQLを実行したり、
JSFやWebサービスを利用して外から初期化処理を起動できるようにすること
- １回読み込んでおくことでキャッシュに乗せて処理を早くする

8.5.6 EclipseLink

GlassFishではJPAの実行エンジンとして、EclipseLinkを使用している
EclipseLinkには
- エンティティキャッシュ
  - エンティティオブジェクトをキャッシュする機能
- 問い合わせキャッシュ　の２種類が存在する
  - クエリの結果をキャッシュする機能
MEMO: EcllipseLink以外の実行エンジンなどが存在する？

8.6 永続化ユニット

http://itdoc.hitachi.co.jp/manuals/link/cosmi_v0870/APKC/EU070266.HTM

アプリケーションからJPAを使用する場合，次のような情報を定義する必要があります。

アプリケーション内のエンティティクラスの情報エンティティクラスとデータベーステーブルとのマッピング情報 JPAプロバイダがデータベースコネクションを取得するためのデータソースの情報これらの情報を定義したものを永続化ユニットといいます。

APサーバーにJNDIを定義し、APサーバー経由で接続→こちらを推奨しますとのこと
設定ファイルをアプリケーションに保持して直接接続
Column JavaSEでJPAを使う
- jarファイルをクラスパスに追加して、persistence.xmlを用意すれば使えますとのこと
- EJBコンテナがないので、EntityManagerFactory経由でEntityManagerオブジェクトを取得する

8.7 環境構築手順

割愛

8.8 アプリケーション開発手順

8.8.2 JPQLの開発

IDE上で試しにSQL流せる機能

MEMO: 他のORMにも同様の機能あるか確認する

Chapter9 RESTful Webサービスの開発

9.1 Webサービスの基礎

9.1.1 Webサービスとは

サーバーで行われたなんらかの処理の結果をHTMLではなく、処理結果だけで返すものをWebサービスと呼びます
Webサービスを実現するために使われる技術
- SOAP: 信頼性を必要とする企業間でのWebサービスで多用されている
- REST: 一般に公開されているWebサービスでよく使用されている
  - RESTベースのWebサービスをRESTfulWebサービスと呼ぶ
JavaEEでもSOAPとRESTを利用したWebサービスを作成するためのAPIを提供している
- SOAPを使用したWebサービスを作成するAPIがJAX-WS
- RESTful Webサービスを作成するAPIが、JAX-RS

9.1.2 RESTful Webサービスとは

RESTful Webサービスとは、RESTに則ったWebサービス
REST原則
- a.すべてのリソースに一意なアドレス（URI）を与える
- b.情報の操作には予め定義された命令体型（統一インターフェイスという）を使用する
- c.プラットフォームに応じて複数の表現（データ形式）を使用する
- d.セッションなどの状態管理を行わず、ステートレスに通信する
- e.アプリケーションはリンクによって、次の状態に遷移する
上記のすべてを守る必要はないが、少なくとも、aとbは守っておくべき
制約がゆるいので、かんたんに実装できる
一方、SOAPは定義が厳密なので実装ハードルが高い

9.1.3 RESTとHTTP

HTTPヘッダー
HTTPメソッド
- GET
- POST
- PUT
- DELETE
URI
- MEMO: マトリックスパラメータは初めて聞いた
ステータスコード

9.2 JAX-RSの基本

9.2.1 JAX-RSとは

リクエストパラメータ
- マーシャル：XML形式やJSON形式→Javaオブジェクト
- アンマーシャル：Javaオブジェクト→XML形式やJSON形式
- JAX-RS2.0仕様の参照実装はJersey
- JerseyはGlassFishサーバーでも使用されている
主に５つの機能を提供
- １．HTTPメソッド/URIパターンとリソースメソッドとのバインド機能
- ２．メッセージボディのデータ形式指定機能
- ３．リクエスト情報のインジェクション機能
- ４．リクエスト/レスポンスのメッセージボディの変換機能
- ５．例外のレスポンスマッピング機能

9.2.2 サンプルアプリケーションにおけるJAX-RSの機能

9.3 RESTful Webサービス作成のための事前準備

9.3.1 RESTful Webサービスの認証方式

ナレッジバンクのRESTサービス機能ではWEBアプリケーション機能で採用しているFORM認証ではなく
BASIC認証で認証を行う
BASIC認証を行うための設定を記載
- web.xmlに追記するみたい
MEMO: 他のフレームワークでBASIC認証を行う方法について整理

9.3.2 データクラス（DTO）

クライアントからのリクエストをJavaオブジェクトに変換する際に受け皿クラスを作成
- @XMLRootElementアノテーションなどを不要しないと行けないらしく、不便そう

9.3.3 Application サブクラス

作成するリソースクラスなど、JAX-RSで使用する一連のファイルをJAX-RSランタイムに通知するためにApplicationサブクラスをクラスパス上に配置
このファイルの存在により、作成するリソースクラスをRESTful Webサービスとして公開できる
ApplicationConfig.javaに@ApplicationPath("xxxxxx")を指定することでOK

9.4 RESTサービスクラス（サーバー側）の作成

9.4.1 リソースクラスの構成要素

RESTful Webサービスで提供する処理を定義するRESTサービスクラスを作成します。
RESTではすべてをリソースとして扱うため、リソースクラスとも呼ばれる
- MEMO: Springの場合、Controller

9.4.2 エンドポイントURIの設定

@Path("{id}")
などと指定

9.4.3 HTTPメソッドとリソースメソッドのバインド

@GET,@POSTなどを指定

9.4.4 メッセージボディのデータ形式指定

@Consumes({}): クライアントから受け取るデータ形式
@Produces({}): クライアントに返却するデータ形式
MINEタイプの抽象化：javax.ws.rs.core.MediaType
- APPLICATION_XML = "application/xml";
- などの定義がある
Column コンテンツネゴシエーション
- クライアントがサーバーにリクエストする際に、返してもらいたいメッセージボディのデータ形式やエンコード方式などをリクエストヘッダーで要求できる
- これを「HTTPコンテンツネゴシエーション」といいます。
- コンテンツネゴシエーションはAcceptヘッダーに要求するデータ形式を指定して行う
- 要求されたデータ形式をサーバーが提供できない場合、「406 Not Acceptable」のステータスコードをクライアントに返す
  - Accept-Charsetヘッダー、Accept-Languageヘッダー、Accept-Encodingヘッダーなど
MEMO: 見たことはあったが用語として抑えれてなかったので覚えておく
メッセージボディとJavaオブジェクトとのマッピング
- アンマーシャル：javax.ws.rs.ext.MessageBodyReader
- マーシャル：javax.ws.rs.ext.MessageBodyWriter

9.4.5 リクエスト情報のインジェクション

@javax.ws.rs.PathParamアノテーション：{id}などのパスパラメータを取得
@javax.ws.rs.QueryParamアノテーション：クエリパラメータを取得
@javax.ws.rs.MatrixParamアノテーション：URIのマトリクスパラメータを取得する
@javax.ws.rs.FormParamアノテーション：HTMLのフォームから送信された情報を取得する
@javax.ws.rs.HeaderParamアノテーション：リクエストヘッダーから値を取得する
@javax.ws.rs.CookieParamアノテーション：リクエストのCookieヘッダーから値を取得する
@javax.ws.rs.core.Contextアノテーション：リクエストURIやリクエストヘッダー、セキュリティ情報などのコンテキスト情報を取得する汎用的なアノテーション
@javax.ws.rs.BeanParamアノテーション：リクエストのパラメータ一式をビーンとして取得する
@javax.ws.rs.DefaultValueアノテーション：対象に値が入らなかった場合、デフォルト値を指定するアノテーション

9.4.6 リクエストのメッセージボディの受取

リクエストの引数にアノテーションを付与しなければ、メッセージボディを受け取れる

9.4.7 入力チェック

リクエストのメッセージボディにマッピングしているJavaオブジェクトをバリデーションするには@Validアノテーションを使用する

9.4.8 レスポンスの定義

return する時に javax.ws.rs.core.Responseクラスを用意している
Response.created(URI.create("/knowledge" + knowledge.getId())).build()
- みたいな感じで生成して返却する
レスポンスメッセージボディのみを指定するときは、Response型以外のオブジェクトを戻り値にするとよい
エンティティプロバイダ（MessageBodyWriterインターフェース実装クラス）がリクエストのAcceptヘッダーに指定されているデータ形式に変換し、レスポンスのメッセージボディに書き出します
成功時のレスポンスにメッセージボディが含まれている場合、「200 OK」
メッセージボディが含まれていない場合、「204 No Content」
- MEMO: レスポンスの 204 No Contentは覚えておく

9.5 HTTPメソッドに応じた処理

9.5.1 ナレッジの検索（GETメソッドによる操作）

9.5.2 ナレッジの登録（POSTメソッドによる操作）

9.5.3 ナレッジの更新（PUTメソッドによる操作）

9.5.4 ナレッジの削除（DELETEメソッドによる操作）

9.5.5 例外クラス

JAX-RSの例外クラスを使用する
JAX-RS2.0の例外体系
- 非チェック例外である、WebApplicationExceptionを用意している
  - コンストラクタにステータスコードを指定すると、アプリケーションからスローされた際にステータスコードを含んだResponseインスタンスをクライントに返す
  - 何も指定しなかったら 500 Internal Server Error
- JAX-RS2.0ではこのクラスを継承した例外クラスが追加された
ClientErrorExceptionを継承した例外クラス
- BadRequestException(400)
- NotAuthorizedException(401)
ServerErrorExceptionを継承した例外クラス
- InternalServerErrorException(500)
- ServiceUnavailableException(503)
MEMO: 他のフレームワークでもこの標準エラーを使用しているような気がする。あとで確認しておく
独自例外の作成方法
- RuntimeExceptionを継承して例外クラスを作成
- マッパークラスを作成し、JAX-RSに認識させる
MEMO: 独自例外を作成することは必ず必要になってくるので、ここ後で見返しておく
- Responseが持っているステータスについても覚えておく
MEMO: 標準提供の例外をマッピングすることも可能！
- 標準のExceptionはステータスコードしかクライアントに返却しないため、ここでマッピングして再定義しておくと、メッセージも合わせて返却できるということ

9.6 RESTクライアントクラス（クライアント側）の作成

9.6.1 データクラス（DTO）

9.6.2 RESTクライアントクラス

MEMO: Javaクライアント側でJAX-RSのWebサービスを利用したい場合の実装方法
- BASIC認証にサードパーティのクラスを使う

9.7 メッセージフィルタクラス

9.7.1 メッセージフィルタとエンティティインターセプタ

JAX-RS2.0では新たに、
- メッセージフィルタ：リクエスト/レスポンスヘッダーの編集などに使用
- エンティティボディインターセプター：エンティティボディの編集などに使用

割愛

MEMO: Logging用のフィルタの実装について考えるベストプラクティスは？
- FileterとInterceptorの違いhttps://meetup-jp.toast.com/698

9.8 まとめ

JAX-RS
- アノテーションでRESTful-Webサービスを作成できる

Chapter10 バッチアプリケーションの開発

JavaEE7では、Javaにおけるバッチ処理の標準化仕様が盛り込まれました。

この仕様はJSR352(Batch Applications for the Java Platform)で規定されている

通称「jBatch」と呼ばれている

10.1 jBatchの基本

10.1.1 バッチ処理とその特徴

バッチ処理とは
- 複数のデータや複数の処理を一括して実行する方式のこと
- 一方、Webブラウザなどの画面を介して入力と応答が繰り返される処理をリアルタイム処理、オンライン処理と呼ぶ
特徴
- 一度に多くのデータが処理される
- 実行時間が長い
- 非対話型（人間による画面での入出力操作を伴わない）
- リクエストに従って起動されることよりも、実行する時刻を指定して起動されることが多い

10.1.2 jBatchとは

jBatchとは
- 前項で述べたような特徴を持つバッチ処理をJava言語で実装するためのフレームワーク
- 業務システムにおけるバッチ処理は、全体的な処理の流れや設計時に注意すべきポイントなど、
- 時代や言語を伴わない共通点が多く見られる
- jBatchはこうした業務システムのバッチ処理似求められる要素を盛り込んだ「以前から培われている雛形」を標準として提供
- jBatchを使わなくてもバッチ処理を実現できるが、活用することで、理解が容易で考慮漏れの少ないバッチ処理を効率よく提供刷ることができる
jBatchの機能と構成要素
- 大まかに言うと
  - ジョブ
  - ステップ
    - で構成される
- ジョブ：全体の流れを記述
- ステップ：ここの処理を実装する
- ジョブとステップの分離により、業務の変更に対して柔軟に対応できる仕組みになっている
jBatchのアーキテクチャはオープンソースのSpringBatchから多くを受け継いでいるが
ジョブとステップの分離は、メインフレーム時代から受け継がれているもの
メインフレームでは、全体の流れはジョブとしてJCLによって記述され、
業務ロジックはステップとして、COBOLやPL/Iなどの言語で記述されたプログラムを用いて実装される
jBatchの機能と構成要素
jBatchにはジョブとステップ以外にいくつか保s所的な機能がある
- リスナ：ジョブやステップの開始直前または終了直後に処理を差し込む
- ジョブリポジトリ：ジョブやステップの状態を永続的に保持する
- コンテキスト：一時的に保持する
- メトリック：統計的な情報を確認刷る

10.1.3 ジョブ

ジョブはステップの入れ物
- １つのジョブの中には１つ以上のステップが必要
- XMLで記述する
  - 各ステップの呼び出し先クラス
  - 実行順序
  - ジョブ全体や各ステップに対する設定、エラー発生時の挙動なども記述
  - 記述のルールを示した仕様は、JSL(Job Specification Language)と呼ばれる
  - ジョブを記述したXMLファイルはJob XMLファイルと呼ばれる
- JSLには処理の実行順序を制御するために、以下のXML要素が用意されている
  - フロー（flow）
  - スプリット（split）
  - デシジョン（decision）
  - 遷移要素（Transition Elements）
全体図が記載されている（書籍を見たほうが良い）
フロー：複数のステップをまとめる要素
スプリット：複数のフローを同時実行させることができる
デシジョン：ジョブ内部で次の遷移先を細かくカスタマイズするための機能
遷移要素
- next: 遷移先には、ステップ、フロー、スプリット、デシジョンが指定できる
- end: 正常終了
- stop: 中断
- fail: 異常終了
リトライとスキップ
- リトライ：チャンク型ステップの処理中に特定の例外が発生した場合に、再度そのデータの処理を試みる
- スキップ：チャンク型ステップの処理中に特定の例外が発生した場合に、データを飛ばして次に進む
- リトライもしくはスキップ対象の例外クラスをJob XMLの中に定義
ジョブオペレータ
- ジョブ自体の開始や停止の全体的な制御を行う
ジョブオペレータの呼び出し方法
- バッチ処理の特徴として、「実行する時刻を指定して起動されることが多い」という点をあげたが、
- jBatchの仕様にはバッチを決まった時間に起動する方式に関する規定や、それを実現するAPIも含まれていない
- この部分に関しては、ジョブスケジューラを連携させる方式が一般的に
  - Linuxなどであればcron
  - Windowsであればタスクスケジューラ
  - その他市販のジョブスケジューラを使用する...など
- ジョブを臨時で実行したい場合や、何らかの異常が発生し、人間が介入して原因を取り除いたあとに再実行する場合は、リクエストに従って起動することになります。（これを「アドホックな実行」と呼びます）
  - そういった場合、画面などのユーザーインターフェースがあると便利だが、この点に関してもjBatchは規定ない
- 実装する際には、オペレータの運用も考える必要がある
MEMO: 手動実行されたジョブか、スケジュールで実行されたジョブかを識別する方法を仕込んでおいた方が良いと思った

10.1.4 ステップ

バッチ内部の個々の処理を実装する部分
- ステップの実態は、jBatchのAPIの中で定義されているJavaインターフェースであり、実装テンプレートを提供している
ステップには２種類ある
- チャンク型：複数のデータを逐次的に処理するために使われる
  - ItemReader,ItemProcessor,ItemWriterの３つで構成される
  - ItemReaderとItemProcessorを繰り返したあと、ItemWriterが呼ばれる（デフォルトで１０回）
  - この塊（１０回などの処理の塊）をチャンクと呼ぶ
- バッチレット型：単体で完結する処理で使われます
  - データの加工や計算を１件ずつ繰り返すような処理ではなく、データに依存しない処理やコマンド実行などの処理を担います。
  - 例えば、ディレクトリ作成やファイル圧縮、送受信処理などの処理
  - 「タスク志向のステップ」と呼ばれる場合もある
  - MEMO: このような単純な処理であれば、スクリプトで完結しそうな気もする..

10.1.5 補助機能

リスナ
- リスナを用いることで、バッチ処理の進行に応じた特定のタイミングで任意の処理を実行することができる
- 「特定のタイミング」には、ジョブやステップの開始及び終了、リトライやスキップの発生などがある
各処理のタイミングごとにリスナが用意されている
リスナの設置は任意で、設置したい場合、リスナのクラス名をJob XMLの中で記述
ジョブリポジトリ：開発者が意識して操作したりしない部分みたい
- 実行中のジョブの情報や、実行が終わったジョブに関する情報が保存される
- 情報の更新はコンテナによって自動的に行われ、情報の取得は、前述のジョブオペレータや、後述するコンテキスト、メトリックAPIを利用する
コンテキスト
- 種類
  - ジョブコンテキスト
  - ステップコンテキスト
- それぞれ、実行中のジョブやステップに関する情報を提供する役割を担う
  - 名前やID、ステータスなどがある
  - コンテキストへのアクセスは、jBatchAPIのJobContext、StepContextインターフェースを経由して行います
メトリック
- チャンク型のステップに対して、実行時の統計情報を提供するのがメトリック
- 情報
  - 読み取りレコード数
  - 書き込みレコード数
  - スキップが発生した数
  - など、処理量に関するもの
- メトリックへのアクセスには、jBatchAPI似あるMetricインターフェースを経由して行う

10.2 jBatchの利用――基本編

実際に実装してみる
- JobXMLの実装
- チャンク型ステップの実装
- バッチレット型ステップの実装
- ジョブ実行部分の実装
- 実行結果の確認

10.2.1 JobXMLの実装

バッチの全体を表すJobXMLを作成刷る
ファイル名から拡張子を取り除いた部分がそのままジョブの名前となります。
ジョブの名前は実行時にJobOperatorクラスのメソッドにわたす形で利用される
それぞれの要素説明
- job
- step
- chunk
- batchlet

10.2.2 チャンク型ステップの実装

10.2.5 バッチレット型ステップの実装

Batchletを実装
- prosess,stopを実装して処理を書くだけ
- 保守性を高い状態に保つためにも、１機能の実装にとどめておくべき

10.2.6 ジョブ実行部分の実装

JobInstanceとJobExecution
- 最初にジョブを実行すると、コンテナ内部ではこの２つのインスタンスが生成される
  - JobInstanceはジョブの１回分を表現
  - JobExecutionはジョブの実行そのものを表現している
パッケージング
- jBatchでもWebアプリケーションと同様に、構成するファイル群をwarファイル形式にまとめてコンテナにデプロイ刷る
- ここで注意が必要なのは、JobXMLファイルの配置場所
  - JobXMLは、warファイル内部のWEB-INF/classes/META-INF/batch-jobsディレクトリの配下に「ジョブ名.xml」という名前で配置しなければ行けない
MEMO: パッケージングする際には一般的にどのようにしているか確認、Gradleとかの前処理で調整している？

10.2.7 実行結果の確認

バッチログを掲載

10.3 jBatchの利用――応用編

10.3.1 サンプル概要

ナレッジ件数ランキング集計バッチ
コメント件数ランキング集計バッチ
Column キーブレイク処理について
- マスタ表から１件読み込み、トランザクション表を操作して処理するという一連の流れ
- 業務におけるバッチ処理では大変多く見られるパターンの１つ
- jBatchのチャンク形式のステップは、このようなキーブレイク処理を念頭においたものと言えるので、本書でも取り上げた
- MEMO: チャンク形式が業務で応用されている例を確認しておくべき
  - SQL一本で済ませる場合が多いのでは？

10.4 ジョブの作成

10.4.1 Job XMLの実装

property要素を利用する方法を記載
- 感覚的にはmavenみたいな感じ

10.4.2 チャンクの実装

※実際に実装刷る際に必要なった時に見返す

10.5 ジョブのフロー制御

※実際に実装刷る際に必要なった時に見返す

10.6 まとめ

終了！

Web製作者のためのSassの教科書

Thu, 09 Apr 2020 00:00:00 GMT

Web製作者のためのSassの教科書

・Sassって聞いたことはあるけど、導入が面倒そう
・Sassをはじめたいけど、あと一歩が踏み出せない
・勉強コストとの天秤にかけて、Sassのメリットが見えない
・周りでSassを使いはじめた人がいて、焦りを感じている
・CSSを今よりも効率的に書きたいと思っている

こうした方がSassを導入するきっかけとなり、
ひと通りSassの機能を使いこなせるようになるのが本書の目標です。

本書では、HTML+CSSの基本的な知識は必須ですが、
Sassにまったく触れたことがない方も対象としています。

CSSをHTMLの構造に合わせて入れ子で書いていく「ネスト」や
便利な「変数」や「演算」などのSassの基本機能はもちろん、

筆者が実際に仕事の現場で使っている実践的なテクニックから
新機能もカバーした全機能リファレンスまで、この一冊で網羅しています。

発売日：2017/9/15
ページ数：296
サイズ：B5変形判
著者：平澤隆（Latele）　著/森田壮　著
ISBN：9784295002352
URL: https://book.impress.co.jp/books/1117101020
目次
- 第1章 Sassのキホン
- 第2章 Sassの利用環境を整えよう
- 第3章これだけはマスターしたいSassの基本機能
- 第4章高度な機能を覚えてSassを使いこなそう
- 第5章現場で使える実践Sassコーディング
- 第6章もっとSassを便利にするフレームワークやツール
- 第7章 Sass全機能リファレンス
公式サポートサイト：https://book2.scss.jp/

第1章 Sassのキホン

1-1 まずはSassって何なのかを知ろう

Sassは学習コストもあるけれど、CSSを覚え始めた頃のワクワク感や楽しさを思い出させてくれるよっている説明
Sass＝CSSを拡張したメタ言語
Sass(Syntactically Awesome Strylesheets)
Sassには２つの記法がある
- SASS記法：CSSと互換性が無い。インデントの深さで分ける
- SCSS記法：CSSと互換性がある。ネストで記載
SCSSファイルはコンパイルが必要だよという説明
魅力的な機能
- 記述の簡略化（ネスト）
- コメントに、//が使える！
- 変数定義で同じ値を使い回すことができる
- １度使ったセレクタを使い回せる（エクステンド）
- コードの再利用が可能
  - スタイルをまとめてテンプレートやモジュールのように定義し、簡単に読み込んで使うことができる
  - ミックスインと呼ばれており、Sassの中でも最も強力な機能の１つ
- １つのCSSファイルにまとめることができる（パーシャル）
- 条件分岐などのプログラム的な処理ができる
- 関数で様々な処理を実行できる
  - Sassにはかなり多くの関数が用意されている
- CSSファイルを圧縮できる
- 他にも魅力が沢山
Sassの歴史について説明（割愛）

1-2 Sassを導入する前の疑問や不安

環境構築に黒い画面を操作することに対しての不安説明
運用時にSassは導入ハードルが高いのではという不安説明
- expandedというフォーマットがあり、これを指定してコンパイルすると、普通にCSS書いたみたいになる
- //コメントは削除されてしまう
- なので納品後はCSS編集という運用でも問題ない

1-3 何はともあれSassを触ってみよう

使ってみる
- 「SassMeister」で検索
- https://www.sassmeister.com
meister = 師匠

Sassを入力するとCSSが出力されるプレイグラウンド

Sassに対応しているソースコード共有サービス
- CodePen
- Create a new Fiddle - jsFiddle
- jsdo.it Share Javascript, HTML5 and CSS
- HTML5, CSS3, JS Demos, Creations and Experiments | CSSDeck

第2章 Sassの利用環境を整えよう

2-1 本書で使用する環境について

本書では、node-sasssを使用する
Sassは大きく分けて２つのSassが存在する
- Ruby Sass：Rubyで開発されたもの
- LibSass：C/C++で開発されたもの
node-sass
- LibSassをNode.jsで動作できるようにしたライブラリ
Node.jsについて：Javascriptで作られたサーバーサイド環境
Gulp: タスクランナー

2-2 Node.jsをインストールする

Webからインストールする手順を記載
バージョン管理ツールの説明
- Windowsならnodist
- Macならndenv

2-3 黒い画面を使ってみよう

コマンドプロンプトを開く手順を記載しているだけ（割愛）

2-4 セットアップ済みの環境をインストールする

サンプルファイルコピー
- https://book2.scss.jp/dl/c2/
gulp-cliをインストール
- npm install --global gulp-cli
モジュールをインストールする
- npm install

2-5 Sass をコンパイルする

gulpfile.jsに記載された処理を実行
- gulp sass
アウトプットスタイルを指定
- Nested
- Expanded
- Compact
- Compressed
ファイルの更新を監視する
- gulp.watch('./sass/**/*.scss',['sass']);

2-6 セットアップ済みの環境を作成する方法

npm と gulp の説明(割愛)
gulpfile.jsのジェネレータについて
- https://steelydylan.github.io/gulp-generator/

2-7 GUIコンパイラ（Prepros）でSassを使う

https://prepros.io/
割愛する

2-8 DreamweaverでSassを使う

割愛する

第3章これだけはマスターしたいSassの基本機能

3-1 ルールのネスト（Nested Rules）

ネストでCSS定義ができる
セレクタも使える
使いすぎるとインデントが深くなり可読性が悪くなる
@mediaのネストもできる

3-2 親セレクタの参照&（アンパサンド）

&を使えば親セレクタを参照できる
BEMやMindBEMingなどBEMの設計思想に近いCSS設計を行っている場合、記述量が大幅に削減される

3-3 プロパティのネスト（Nested Properties）

プロパティもネストさせてかけるよっていう説明
ショートハンドでかけるところをネストさせる
慣れないうちは可読性が下がる原因にもなるので、普通に書いたほうが無難
Column: -(ハイフン)があるプロパティはすべてネストできる

3-4 Sassで使えるコメント

javascriptのコメント//が使える
通常のCSSコメント /* */ だとコンパイルされても残る
スタイルが「compressed」だとコメントは残らない
- 「compressed」でも残るコメント
  - /*! */ !を追加すれば残るらしい

3-5 変数（Variables）

変数宣言ができる

// 赤色の変数を宣言
$red: #cf2d3a;

変数名で使える文字と使えない文字

$width10: 10px;
$w-10: 10px;
$w_10: 10px;
$Ｗｉｄｔｈ１０: 10px;
$横幅10px: 10px;
$１０px: 10px;
$___w10___: 10px;
$-_-______----w:10px;
$変数はSassの便利な機能の１つです:black;

// 使えない文字
$10width: 10px; // 数字から始まっている
$@width10: 10px; // @など使えない記号
$--width: 10px; // 連続したハイフンから始まっている

ルールセット内で変数を宣言することもできる
変数を参照できる場所
- セレクタから参照したり、他の文字列と結合してパスを作成したい場合などに気をつける必要あり

$セレクタ名: '.pickupContentsArea, section.main';
$IMG_PATH: '../img/bg/';

#{$セレクタ名} {
  background-color: url(#{$IMG_PATH}pickup.png);
}

3-6 演算

+ - * %などの演算子が使える
コンパイル後は、演算結果が出力される

// paddingの値が変わった時に変数として持っておくとwidthに反映できる
article {
  $padding: 7px;
  width: $main_width - $padding * 2;
}

色の演算も算術演算子でできるが将来的には廃止予定らしい
- rgba()を使おうとのこと

3-7 Sassの@import

SassではCSSで使える@importの他に、Sass独自の@import機能がある
CSSファイルを生成しないパーシャル
- importしたSassファイルなど、特定のSassファイルをCSSファイルとして生成したくない場合、
- Sassファイルのファイル名の最初に_アンダースコアをつけることで、コンパイルしてもCSSファイルが生成されなくなる
- この機能のことをパーシャル(partial)という

第4章高度な機能を覚えてSassを使いこなそう

4-1 スタイルの継承ができるエクステンド（@extend）

エクステンド＝指定したセレクタのスタイルを継承することができる機能
あまり継承しすぎると、プロパティがバッティングしてしまう可能性が高くなる
エクステンドの連鎖
- 継承を連鎖して記載可能
エクステンドが使えないセレクタの紹介
- .item p 子孫セレクタ
- #main > article 子セレクタ
- h2 + h3 隣接セレクタ
- h3 ~ h3 間接セレクタ

// 子孫セレクタ
.item p { ... }

// 子セレクタ
#main > article { ... }

// 隣接セレクタ
h2 + h3 { ... }

// 間接セレクタ
h3 ~ h3 { ... }

エクステンド専用のプレースホルダーセレクタ

// エクステンド専用のプレースホルダーセレクタ
%boxBase {
    padding: 15px;
    border: 1px solid #999;
}

// プレースホルダーセレクタを継承
.item {
    @extend %boxBase;
    margin-bottom: 20px;
}
section {
    @extend %boxBase;
    margin-bottom: 60px;
}

@media内ではエクステンドは使用できない

// これはコンパイルエラーになってしまう
%btnBase {
    display: inline-block;
    padding: 5px 10px;
    background: #eee;
}

@media all and (orientation:landscape) {
    a {
        @extend %btnBase;
    }
}

// こちらに書き直すとうまくいく
@media all and (orientation:landscape) {
    %btnBase {
        display: inline-block;
        padding: 5px 10px;
        background: #eee;
    }
    a {
        @extend %btnBase;
    }
}

警告を抑止する !optionalフラグ

.btn {
    @extend %btnBase !optional;
}

4-2 柔軟なスタイルの定義が可能なミックスイン（@mixin）

スタイルの集まりを定義しておき、それを他の場所で呼び出して使うことができる
また、引数を指定することで、定義したミックスインの値を一部変更して使うといった、非常に柔軟で強力な処理が可能

// ミックスインを定義
@mixin boxSet {
    padding: 15px;
    background: #999;
    color: white;
}
// 定義したミックスインを呼び出し
.relatedArea {
    @include boxSet;
}

エクステンドと違ってコンパイル後に、展開されて出力されることを確認

// 定義したミックスインを呼び出し
.relatedArea {
    @include boxSet;
}
// 別のルールセットでも呼び出し
.pickupArea {
    @include boxSet;
}

.relatedArea {
  padding: 15px;
  background: #999;
  color: white;
}
.pickupArea {
  padding: 15px;
  background: #999;
  color: white;
}

引数を使ったミックスイン

// 引数を使ったミックスインを定義
@mixin kadomaru($value) {
    -moz-border-radius: $value;
    -webkit-border-radius: $value;
    border-radius: $value;
}
.box {
    @include kadomaru(3px);
    background: #eee;
}
.item {
    border: 1px solid #999;
    @include kadomaru(5px 10px);
}
// 可変でプロパティを定義できる

引数に初期値を設定することもできる

@mixin kadomaru($value: 3px) {
    -moz-border-radius: $value;
    -webkit-border-radius: $value;
    border-radius: $value;
}
.boxA {
    @include kadomaru;
    background: #eee;
}
.boxB {
    @include kadomaru();
    background: #f1f1f1;
}

.boxA {
  -moz-border-radius: 3px;
  -webkit-border-radius: 3px;
  border-radius: 3px;
  background: #eee;
}
.boxB {
  -moz-border-radius: 3px;
  -webkit-border-radius: 3px;
  border-radius: 3px;
  background: #f1f1f1;
}

引数を複数指定することもできる

@mixin boxBase($margin: 30px 0, $padding: 10px) {
    margin: $margin;
    padding: $padding;
}

.boxA {
    @include boxBase;
    background: #eee;
}
.boxB {
    @include boxBase(0 0 50px, 20px);
    background: #f1f1f1;
}

,(カンマ)を使うプロパティには可変長引数を利用する

@mixin shadow($value...) {
    text-shadow: $value;
}

h2 {
    @include shadow(8px 8px 0 #999, 15px -10px 0 #eee);
}

複数の引数があるミックスインを読み込む際に可変長引数を使う

@mixin boxBase($w: 250px, $pd: 15px, $bg_c: #fff, $bd_c: #ccc) {
    width: $w;
    padding: $pd;
    background-color: $bg_c;
    border: 1px solid $bd_c;
}

$values: 300px, 20px; // こういう変数定義もできるんだと知った

.item {
    float: left;
    @include boxBase($values...);
}

ミックスインのスコープ（利用できる範囲）を制限する

.main {
    @mixin margin {
        margin: 50px 0;
    }
    .item {
        @include margin;
    }
}
// あまりスコープを制限する例は無いが一応覚えておく

ミックスインにコンテントブロックを渡す @content
- →これは便利！

@mixin media($width-media: 768px) {
    @media only screen and (max-width: $width-media) {
        @content;
    }
}
 
.item {
    .image {
        float: left;
        @include media {
            float: none;
        }
    }
    .text {
        overflow: hidden;
        margin-left: 15px;
        @include media {
            margin-left: 0;
        }
    }
}

.item .image {
  float: left;
}

@media only screen and (max-width: 768px) {
  .item .image {
    float: none;
  }
}

.item .text {
  overflow: hidden;
  margin-left: 15px;
}

@media only screen and (max-width: 768px) {
  .item .text {
    margin-left: 0;
  }
}

ミックスイン名で使える文字と使えない文字

@mixin shadow1 { ～ }
@mixin shadow-1 { ～ }
@mixin shadow_1 { ～ }
@mixin 影 { ～ }
@mixin ｓｈａｄｏw { ～ }
@mixin _shadow { ～ }
@mixin -shadow { ～ }

// 使えない文字
@mixin 01shadow { ～ } // 数字から始まっている
@mixin shadow@2 { ～ } // @など使えない記号
@mixin --shadow { ～ } // 連続したハイフンから始まっている

4-3 ネストしているセレクタをルートに戻せる @at-root

あまり使い所が無いと感じたが、使える場面があるらしい

.block {
    .element-A {
        width: 80%;
    }
    @at-root .element-B {
        width: 100%;
    }
}

.block .element-A {
  width: 80%;
}

.element-B {
  width: 100%;
}

使い所は５章で確認する

4-4 Sassのデータタイプについて

Sassのデータ・タイプについて

.DataTypes {
    /* Number型 */
    property: type-of(10%);
    /* Color型 */
    property: type-of(red);
    /* String型 */
    property: type-of(sans-serif);
    /* Boolean型 */
    property: type-of(true);
    /* Null型 */
    property: type-of(null);
    /* List型 */
    property: type-of(1.5em 1em 0 2em);
    /* Map型 */
    $map:(key1: value1, key2: value2);
    property: type-of($map);
    /* Function型 */
    property: type-of(get-function("lighten"));
}

.DataTypes {
  /* Number型 */
  property: number;
  /* Color型 */
  property: color;
  /* String型 */
  property: string;
  /* Boolean型 */
  property: bool;
  /* Null型 */
  property: null;
  /* List型 */
  property: list;
  /* Map型 */
  property: map;
  /* Function型 */
  property: function;
}

@function example($value) {
    @if type-of($value) == number {
        処理
    }
}
// typeで判断して関数を作れますよという説明

4-5 制御構文で条件分岐や繰り返し処理を行う

@if,@for,@while,@eachを使って表現

4-6 関数を使ってさまざまな処理を実行する

Sassには予め用意された関数がある
使用頻度の高いものをピックアップして紹介
参照 https://book2.scss.jp/code/c4/06.html

4-7 自作関数を定義する@function

自作関数の定義方法そんなに変わったことはしていない

$width: 105px;
@function halfSize($value:$width) {
    @return round($value / 2);
}
.boxA {
    width: halfSize();
}
.boxB {
    width: halfSize(200px);
}

4-8 テストやデバックで使える@debug、@warn、@error

変数のデバッグに使用できる機能もある

@debug 10em + 12em;

test.scss:1 DEBUG: 22em

// WARNで警告
$value: 1000px;
@function warnTest(){
    @if unitless($value) {
        $value: $value + px;
    }
    @else {
    @warn "#{$value}は駄目！$valueに単位は入れないで！";
    }
    @return $value;
}
.box {
    width: warnTest();
}

// ERROR で処理を中断
$value: 1000px;
@function errorTest(){
    @if unitless($value) {
        $value: $value + px;
    }
    @else {
    @error "#{$value}は駄目！$valueに単位は入れないで！";
    }
    @return $value;
}
.box {
    width: errorTest();
}

4-9 使いどころに合わせて補完（インターポレーション）してくれる#{}

インターポレーションとは
- 変数が参照できない場所でも使うことができるようにする機能
- #{}←これ
演算しないようにする
- font: #{$font-size}/#{$line-height}
演算できない場所で演算する
- .mt#{$i * 5} {

4-10 変数の振る舞いをコントロールする !default と !global

!defaultフラグ
- デフォルト値とは上書きされることを前提にした変数の初期値
- このフラグを使用していると、先に宣言されている変数が優先される
  - →ライブラリで使用しているの確認済み。よく使われる
!globalフラグ
- ローカル変数をグローバル変数にするフラグ
- グローバル変数とはドキュメントルートで宣言した、どこからでも参照できる変数のこと
- ネスト内からグローバル変数を上書きしたい場合や、ローカル変数をスコープ外から参照したい場合などに使用する

第5章現場で使える実践Sassテクニック

5-1 管理／運用・設計で使えるテクニック

ネストが深すぎると生じる問題を把握して、バランスを見ながら利用する
ネストが深すぎて可読性が落ちてしまう
セレクタが長くなってしまうことの弊害
- CSSが肥大化する
Column: ネストは何階層までがよいか
- 2～3階層程度にするのがよい
- HTMLのツリー構造に沿った形でCSSを指定するストラクチャタイプの設計の場合は、
- ある程度ネストを深くしたほうがよい
CSSとは違うパーシャルによるSassファイルの分割
- _mixin.scssなど分けて作成して、@importでまとめる
サイトの基本設定を変数にして一元管理する
複数人で制作する場合は各自のSassファイルを用意する
- Gitなどが汚れるのではとも感じる...
コメントを活用してソースをわかりやすくする
大規模サイトで活用できる@importのネスト
&(アンパサンド)を活用してBEM的な設計を快適に

.navigation {
    width: 100%;
    &__item {
        color: #666;
        &_state_active {
            color: #000;
        }
    }
}

@keyframesをルールセット内に書いて関係性をわかりやすくする

.example {
    @keyframes anima-example {
        0% {
            transform: translate(0%, -100%);
        }
        100% {
            transform: translate(0%, 0%);
        }
    }
    animation: anima-example 0.9s linear 500ms 1;
}

@keyframesはルートに書き出してくれる

.example {
  animation: anima-example 0.9s linear 500ms 1;
}
@keyframes anima-example {
  0% {
    transform: translate(0%, -100%);
  }
  100% {
    transform: translate(0%, 0%);
  }
}

EditorConfigとStylelintでコーディングルールを統一する
- EditorConfig：拡張機能を入れて、.editorconfigファイルを作成
- Stylelint：拡張機能を入れる
  - npm install --global stylelint
  - .stylelintrcという設定ファイルをおけばOK
Column: 他の人を思いやってSass設計をしよう
- 本書のシリーズ「Web製作者のためのCSS設計の教科書」はFLOCSS（フロックス）を提唱しているらしい

5-2 レイアウト・パーツで使えるテクニック

clearfixをミックスインで活用する

@mixin clearfix {
    &::after {
        content: "";
        display: block;
        clear: both;
    }
}
// include
.item {
  @include .clearfix;
  background: #eee;
  .image {
    float: left;
    width: 100px;
  }
  .text {
    float: left;
  }
}

変数を使って、サイドバーの幅を自動的に計算する

// 全体の幅
$wrap-width: 960px;
// メインエリアの幅
$main-width: 640px;
// サイドバーの幅
$side_width: $wrap_width - $main_width - 20;
#contents {
    width: $wrap_width;
}
#main {
    width: $main_width;
}
#side {
    width: $side_width;
}

nullで簡単に条件分岐してレイアウトする
- nullを指定するとコンパイルした時にプロパティごと生成されない
calc と Sass を組み合わせて四則演算を便利に使う
- calcと組み合わせる際の注意点について
@forを使って余白調整用のclassを生成する

$spaceClass: true !default;
$spacePadding: false !default;
$endValue: 10 !default;

@if $spaceClass {
    @for $i from 0 through $space_endValue {
        .mt#{$i * 5} {
            margin-top: 5px * $i !important;
        }
        .mb#{$i * 5} {
            margin-bottom: 5px * $i !important;
        }
        @if $spacePadding {
            .pt#{$i * 5} {
                padding-top: 5px * $i !important;
            }
            .pb#{$i * 5} {
                padding-bottom: 5px * $i !important;
            }
        }
    }
}

.mt0 {
  margin-top: 0px !important;
}
.mb0 {
  margin-bottom: 0px !important;
}
.mt5 {
  margin-top: 5px !important;
}
.mb5 {
  margin-bottom: 5px !important;
}
...（略）...
.mt50 {
  margin-top: 50px !important;
}
.mb50 {
  margin-bottom: 50px !important;
}
// あまり作成しすぎるとCSSコード量も増えるので程々に

リストマーカー用の連番を使った class名を作成する
連番を使ったclass名のゼロパディング（0埋め）をする
文字リンクカラーのミックスインを作る

@mixin link-color2($n) {
    color: $n;
    &:hover {
        color: lighten($n, 30%);
        text-decoration: none;
    }
}
a {
  @include link-color2(#f00);
}

複数の値を@eachでループし、ページによって背景を変更する
シンプルなグラデーションのミックスインを作る
Map型と@eachを使ってSNSアイコンを管理する
値が比較しづらい z-index をMap型で一括管理する
メディアクエリ用のミックスインを作成して楽々レスポンシブ対応

$breakpoints: (
    xs: "only screen and (max-width: 320px)",
    s: "only screen and (max-width: 575px)",
    m: "only screen and (max-width: 767px)",
    l: "only screen and (max-width: 991px)",
    xl: "only screen and (max-width: 1199px)",
);
@mixin media($breakpoint) {
    @media #{map-get($breakpoints, $breakpoint)} {
        @content;
    }
}
body {
    background-color: white;
    @include media(l) {
        background-color: blue;
    }
    @include media(m) {
        background-color: green;
    }
    @include media(xs) {
        background-color: red;
    }
}

5-3 スマホ・マルチデバイス、ブラウザで使えるテクニック

5-4 gulpのタスクを追加してもっと便利な環境にする

パーシャルファイルを一括で読み込む
ソースマップでコンパイル前のソース場所を知る
エラー時にWatchを停止させずに、自動コンパイルを継続させる
エラーに気づきやすくするために通知を出す

5-5 PostCSSでSassをさらに便利にする

PostCSSとは
- Node.js製のCSSの変換ツール
ベンダープレフィックスを自動付与する
- 対象ブラウザを確認するには
  - https://browserl.ist/
画像名だけで画像のパスやサイズを取得する
CSSプロパティの記述順を自動でソートする
- 並び替えオーダーの種類
  - alphabetically
  - smacss
  - concentric-css
バラバラになったメディアクエリをまとめてコード量を削減してスッキリさせる

第6章もっとSassを便利にするフレームワークやツール

6-1 Sassのフレームワーク紹介

6-2 SassのGUIコンパイラ

第7章 Sass全機能リファレンス

7-1 Sassの基本と高度な機能

7-2 Sassの関数一覧

7-3 Sassの拡張

付録

コマンド一覧

用語集

Javaによる関数型プログラミングJava8ラムダ式とStream

Wed, 01 Apr 2020 00:00:00 GMT

Javaによる関数型プログラミングJava8ラムダ式とStream

著者：vankat subramaniam
訳：株式会社プログラミングシステム社
2014年10月発行
オライリー本

まえがき

はじめに

対象者

Java5経験者
他の言語で関数型プログラミングを行っていて、Javaで実施したい人
すでにラムダ式に詳しい人は、チームメンバーのトレーニングに使用できる

本書の内容

最初から最後まで通して読むことをおすすめする（前の章で紹介した内容を後ろの章で使ってる）

使用するJavaのバージョン

Java8が必要

サンプルコードの読み方

サンプル
- https://pragprog.com/titles/vsjava8/source_code

オンラインリソース

サンプルコード
- https://pragprog.com/book/vsjava8/functional-programming-in-java

1章　Hello、ラムダ式

1.1 考え方を変える

ラムダ式の紹介

1.2 関数型のコードによる大きな利益

1.3 なぜ関数型で記述するのか

1.4 革命ではなく、進化

1.5 簡単にするためのほんの少しの砂糖

1.6 まとめ

第一章はラムダ式の紹介をしていたので流し読み

2章　コレクションの使用

2.1 リストをイテレート

今までの書き方から徐々にエレガントに進化させていく

// 自殺点パターンと呼ぶ
    for(int i = 0; i < friends.size(); i++) {
      System.out.println(friends.get(i));
    }
// 冗長でエラーが発生しやすいから
// <i だったかな？ <=i だったかな？と悩む

// 上記よりは儀式が少なくなっている
// 特定のインデックスに対する操作がなければ、上記より優れているパターン
    for(String name : friends) {
      System.out.println(name);
    }

// これら両方とも命令形のコードであり、モダンなJavaでは捨て去ることができる

関数型へ移行を進める理由
- forループは本質的にシーケンシャルであり、並列化が極めて難しい
- このようなループはポリモーフィックではなく、命令した通りのことを実行される。コレクションに対して（ポリモーフィックな処理を行う）メソッドを呼び出すのではなく、forループに渡している
- 設計レベルで、コードは「伝えろ、聞くな」という原則を破っている。forループではイテレーションの詳細をライブラリに任せるのではなく、特定のイテレーション処理を実行するよう要求している
Tell, Don't Ask https://www.jabba.cloud/20150912232135/

    System.out.println("//" + "START:INTERNAL_OUTPUT");
    friends.forEach((final String name) -> System.out.println(name));
    System.out.println("//" + "END:INTERNAL_OUTPUT");

    friends.forEach((name) -> System.out.println(name));

    // 型推論されたパラメータはfinalが保証されなくなる
    // 引数を変更しない習慣を開発者自身が身につける必要がある
    friends.forEach(name -> System.out.println(name));

    friends.forEach(System.out::println);

2.2 リストの変換

2.2.1 ラムダ式を使う

map()メソッドについて：連続した入力を連続した出力に変換します

// こうじゃなくて
    final List<String> uppercaseNames = new ArrayList<String>();
    friends.forEach(name -> uppercaseNames.add(name.toUpperCase()));
    System.out.println(uppercaseNames);

// こう書く
    friends.stream()
           .map(name -> name.toUpperCase())
           .forEach(name -> System.out.print(name + " "));

2.2.2 メソッド参照を使用

    friends.stream()
           .map(String::toUpperCase)
           .forEach(name -> System.out.println(name));

メソッド参照の使い所
- ラムダ式が非常に短い場合や、ラムダ式がインスタンスメソッドやstaticメソッドをシンプルで直接的に呼び出している場合における優れた代替手段
- 映画「Offiece Space」のTom Smykowskiのようなもの...　著者が例えている
- →個人的に「Offiece-spaceパターン」とよんでいる

2.3 要素の検索

fileter()
- コレクションから要素を抜き出すために用いる
- map()メソッドと同様にイテレーターを返すが、同じ要素数返すとは限らない

{
    final List<String> startsWithN = new ArrayList<String>();
    for(String name : friends) {
      if(name.startsWith("N")) {
        startsWithN.add(name);
      }
    }
    System.out.println(String.format("Found %d names", startsWithN.size()));
}
{
    final List<String> startsWithN =
      friends.stream()
             .filter(name -> name.startsWith("N"))
             .collect(Collectors.toList());
    System.out.println(String.format("Found %d names", startsWithN.size()));
}

2.4 ラムダ式の再利用

ラムダ式を定義しておいて重複をなくそうという説明

    final Predicate<String> startsWithN = name -> name.startsWith("N");

    final long countFriendsStartN =
      friends.stream()
             .filter(startsWithN)
             .count();
    final long countEditorsStartN =
      editors.stream()
             .filter(startsWithN)
             .count();
    final long countComradesStartN =
      comrades.stream()
              .filter(startsWithN)
              .count();

DRYの原則

2.5 静的スコープとクロージャ

ラムダ式内は実質的にfinalな変数しか使えない
Predicate<T>はT型を引数に取り、関数が行う検査の結果としてbooleanを返却。候補値の取捨選択を行う際に利用できる。
Function<T,R>はT型の引数を取り、R型の結果を返す関数。常にbooleanを返却するPredicate<T>より汎用的。
Optionalクラスは、結果が存在しない可能性がある場合に便利

    final Function<String, Predicate<String>> startsWithLetter =
      letter -> name -> name.startsWith(letter);

    final long countFriendsStartN =
      friends.stream()
             .filter(startsWithLetter.apply("N")).count();
    final long countFriendsStartB =
      friends.stream()
             .filter(startsWithLetter.apply("B")).count();

MEMO: Functionで囲うメリットがいまいち理解できていない（2020-04-26 14:52:51）

2.6 要素を 1つ選択

Null初期化は、Nullであることを確認する作業が必要になって来る
- これを忘れるとNullpointerExcepiton

// エレガントな例
  public static void pickName(
    final List<String> names, final String startingLetter) {
    final Optional<String> foundName = 
      names.stream()
           .filter(name ->name.startsWith(startingLetter))
           .findFirst();
    System.out.println(String.format("A name starting with %s: %s",
      startingLetter, foundName.orElse("No name found")));
  }

OptionalはNull脱臭剤

2.7 コレクションを単一の値に集約（reduce）

本節では、要素の比較や計算状態をコレクションに渡って持ち越して使用する方法を学ぶ

System.out.println("//" + "START:SUM_OUTPUT");
      System.out.println("Total number of characters in all names: " +
        friends.stream()
               .mapToInt(name -> name.length())
               .sum());
    }
System.out.println("//" + "END:SUM_OUTPUT");

System.out.println("//" + "END:AVERAGE_OUTPUT");
System.out.println("//" + "START:REDUCE_OUTPUT");
    final Optional<String> aLongName =
      friends.stream()
             .reduce((name1, name2) ->
                name1.length() >= name2.length() ? name1 : name2);
    aLongName.ifPresent(name ->
      System.out.println(String.format("A longest name: %s", name)));
System.out.println("//" + "END:REDUCE_OUTPUT");

    final String steveOrLonger =
      friends.stream()
             .reduce("Steve", (name1, name2) ->
                name1.length() >= name2.length() ? name1 : name2);

    System.out.println(steveOrLonger);

2.8 要素の結合

StringJoinerの説明

System.out.println("//" + "START:MAP_JOIN_OUTPUT");
    System.out.println(
      friends.stream()
             .map(String::toUpperCase)
             .collect(joining(", ")));
System.out.println("//" + "END:MAP_JOIN_OUTPUT");

2.9 まとめ

コレクションはプログラムにおいてはありふれたもので、
ラムダ式によりJavaにおけるコレクションの利用は従来よりも遥かに簡単で単純になりました
記述するコード量が減少し、保守性が高くなる

3章　文字列、コンパレータ、フィルタ

ラムダ式とメソッド参照を使用してSringをいてレートし、Comparatorを実装し、ディレクトリのファイルリストを取得し、
そしてファイルやディレクトリを監視します

3.1 文字列のイテレーション

    System.out.println("//" + "START:ITERATE_OUTPUT");

    final String str = "w00t";

    str.chars()
       .forEach(ch -> System.out.println(ch));
    System.out.println("//" + "END:ITERATE_OUTPUT");

    str.chars()
       .forEach(System.out::println);

    System.out.println("//" + "START:FIX_OUTPUT");
    str.chars()
       .forEach(IterateString::printChar);
    System.out.println("//" + "END:FIX_OUTPUT");

        str.chars()
           .mapToObj(ch -> Character.valueOf((char)ch))
           .forEach(System.out::println);

    System.out.println("//" + "START:FILTER_OUTPUT");
    str.chars()
       .filter(ch -> Character.isDigit(ch))
       .forEach(ch -> printChar(ch));
    System.out.println("");
    System.out.println("//" + "END:FILTER_OUTPUT");

    str.chars()
       .filter(ch -> Character.isDigit(ch));

    str.chars()
       .filter(Character::isDigit);

    str.chars()
       .filter(Character::isDigit)
       .forEach(IterateString::printChar);

インスタンスメソッドのメソッド参照（String::toUppercase）と、staticメソッドのメソッド参照（Character::isDigit）は構造的に同じように見えるが異なる
インスタンスメソッド： 引数.toUppercase();
staticメソッド： Character.isDigit(引数);
インスタンスメソッドとstaticメソッドの定義が衝突すると、
どちらを使用していいかコンパイラが判断できなくなりコンパイルエラーとなる
- →この場合はラムダ式を使う！
- ラムダ式とメソッド参照を自由自在に切り替えられるようになる

3.2 Comparatorインタフェースを実装

Listのsort()メソッドだと戻り値がvoidなので、リスト本体が変更されてしまう
コピーを取得した上で、変更する必要があったが、面倒
代わりにStreamの力を借りて処理する方法を考える

people.sorted((person1,person2) -> person1.ageDifference(person2)).collect(toList());
// ↓改善
people.stream().sorted(Person::ageDifference).collect(toList());

逆順にしたい場合


people.stream().sorted((person1, person2) -> person2.ageDifference(person1)).collect(toList());
// パラメータの順番が引数受け渡しの規約に従っていないため、メソッド参照を使うようにリファクタリングすることはできません。

事前にComparatorを定義しておいて、使用することで簡潔に記載できる

  
  public static void main(String[] args) {
    final List<Person> people = Arrays.asList(
      new Person("John", 20),
      new Person("Sara", 21),
      new Person("Jane", 21),
      new Person("Greg", 35));

{  
    System.out.println("//" + "START:AGE_ASCEND_OUTPUT");
    List<Person> ascendingAge = 
      people.stream()
            .sorted((person1, person2) -> person1.ageDifference(person2))
            .collect(toList());
    printPeople("Sorted in ascending order by age: ", ascendingAge);
    System.out.println("//" + "END:AGE_ASCEND_OUTPUT");
}

{  
  // メソッド参照（Method Reference）
    System.out.println("//" + "START:AGE_ASCEND_MR_OUTPUT");
    List<Person> ascendingAge = 
      people.stream()
            .sorted(Person::ageDifference)
            .collect(toList());

    printPeople("Sorted in ascending order by age: ", ascendingAge);
    System.out.println("//" + "END:AGE_ASCEND_MR_OUTPUT");
}

{
    System.out.println("//" + "START:AGE_DESCEND_OUTPUT");
    printPeople("Sorted in descending order by age: ",
      people.stream()
            .sorted((person1, person2) -> person2.ageDifference(person1))
            .collect(toList()));
    System.out.println("//" + "END:AGE_DESCEND_OUTPUT");

    System.out.println("//" + "START:REVERSE_ORDER_OUTPUT");
    Comparator<Person> compareAscending = 
      (person1, person2) -> person1.ageDifference(person2);
      // reversed()を使うことで降順の関数を事前に用意できる
    Comparator<Person> compareDescending = compareAscending.reversed();

    printPeople("Sorted in ascending order by age: ",
      people.stream()
            .sorted(compareAscending)
            .collect(toList())
    );
    printPeople("Sorted in descending order by age: ",
      people.stream()
            .sorted(compareDescending)
            .collect(toList())
    );
    System.out.println("//" + "END:REVERSE_ORDER_OUTPUT");

    // 名前の昇順に並び替え
    System.out.println("//" + "START:NAME_ASCEND_OUTPUT");
    printPeople("Sorted in ascending order by name: ",
      people.stream()
            .sorted((person1, person2) -> 
               person1.getName().compareTo(person2.getName()))
            .collect(toList()));
    System.out.println("//" + "END:NAME_ASCEND_OUTPUT");
}

{
    // min()メソッドはOptionalを返す！
    System.out.println("//" + "START:YOUNGEST_OUTPUT");
    people.stream()
          .min(Person::ageDifference)
          .ifPresent(youngest -> System.out.println("Youngest: " + youngest));
System.out.println("//" + "END:YOUNGEST_OUTPUT");
}

{
    System.out.println("//" + "START:ELDEST_OUTPUT");
    people.stream()
          .max(Person::ageDifference)
          .ifPresent(eldest -> System.out.println("Eldest: " + eldest));
    System.out.println("//" + "END:ELDEST_OUTPUT");
}

3.3 複数のプロパティによる流暢な比較


{
    // 名前のアルファベット順にするために以下の関数を用意した
    // 従来の内部クラス構文と比較すると非常に簡潔
    people.stream()
          .sorted((person1, person2) -> 
             person1.getName().compareTo(person2.getName()));

    printPeople("Sorted in ascending order by name: ",
    people.stream()
          .sorted(comparing((Person person) -> person.getName()))
          .collect(toList()));

    // Comparatorインターフェースのコンビニエンス関数を使用することで、より自由にコードの目的を表現できる
    // Comparaotrインターフェースのcomparing()メソッドを静的にインポートしました。comparing()メソッドは与えられた
    // ラムダ式のロジックを使用してComparatorを生成する！
    // つまり、関数（Function）を引数に取り、関数（Comparator）を返す高階関数
    final Function<Person, String> byName = person -> person.getName();
    people.stream()
          .sorted(comparing(byName));
}

{
    System.out.println("//" + "START:SORT_NAME_AND_AGE_OUTPUT");
    
    final Function<Person, Integer> byAge = person -> person.getAge();
    final Function<Person, String> byTheirName = person -> person.getName();
    
    printPeople("Sorted in ascending order by age and name: ",
      people.stream()
            .sorted(comparing(byAge).thenComparing(byTheirName))
            .collect(toList()));
    System.out.println("//" + "END:SORT_NAME_AND_AGE_OUTPUT");
}

このように、Comparatorの実装をラムダ式やJDKの新たなユーティリティクラスを使用して簡単に合成できる
- MEMO: 少し納得してないので再度確認

3.4 collectメソッドとCollectorsクラスの使用

これまでに、Streamの要素をArrayListに変換する例でcollect()メソッドを数回使用している
- このメソッドは、あるコレクションを可変コレクションなど他のデータ型へ変換する際に便利な集約処理を行います
- collect()関数はCollectorsクラスのユーティリティメソッドと組み合わせるととても便利

// 20歳以上の人を抽出してリストを取得する
{  
    // 従来の書き方
    System.out.println("//" + "START:MUTABLE_OUTPUT");
    List<Person> olderThan20 = new ArrayList<>();
      people.stream()
            .filter(person -> person.getAge() > 20)
            .forEach(person -> olderThan20.add(person));
    System.out.println("People older than 20: " + olderThan20);
    System.out.println("//" + "END:MUTABLE_OUTPUT");
    // 問題点：
    // ターゲットとするコレクションに要素を１つずつ追加する保s理はとても低レベルなもので、宣言型ではなく命令形のコード
    // 並列に実行させる場合にはスレッドセーフ問題を適切に処理しなければならない
    // 可変性を持つコードを並列化するのは難しいものです。
}

// この問題はcollect()を使うことで緩和できる
// collect()メソッドの以下の３つについて知っておく
// サプライヤ　　：結果を収めるコンテナの精製方法（例えば、ArrayList::new）
// アキュムレータ：結果コンテナに単一の要素を追加する方法（例えばArrayList::add）
// コンバイナ　　：結果コンテナを他のコンテナと結合する方法（例えばArrayList::addAll）

{  
    // 便利な書き方！
    System.out.println("//" + "START:COLLECT_OUTPUT");
    List<Person> olderThan20 = 
      people.stream()
            .filter(person -> person.getAge() > 20)
            .collect(ArrayList::new, ArrayList::add, ArrayList::addAll);
    System.out.println("People older than 20: " + olderThan20);
    System.out.println("//" + "END:COLLECT_OUTPUT");
}
// メリット：
// より明確で意図を持ったプログラミングを行っている→ArrayListに処理結果を集めることがこのコードの目的
// コード内で状態変更を行っていないため、イテレーションを簡単に並列化できる

次は基本のcollect()メソッドよりも簡潔で便利な、オーバーロードされたcollect()メソッドを見ていく
このメソッドはCollectorを引数に取ります
Collectorはcollect()メソッドに設定された３つの異なるパラメータをカプセル化した、より簡単で再利用可能なインターフェース
様々なCollectorの実装を提供するCollectorsクラスにtoList()というコンビニエンスメソッドがある
このメソッドはArrayListに要素を蓄積するメソッドで、Collectorインターフェースの実装

{  
    System.out.println("//" + "START:COLLECT_TO_LIST_OUTPUT");
    List<Person> olderThan20 = 
      people.stream()
            .filter(person -> person.getAge() > 20)
            .collect(Collectors.toList());
    System.out.println("People older than 20: " + olderThan20);
    System.out.println("//" + "END:COLLECT_TO_LIST_OUTPUT");
}

他にも色々集計できるよっていう説明!
- https://docs.oracle.com/javase/jp/8/docs/api/java/util/stream/Collectors.html


{  
    System.out.println("//" + "START:GROUP_BY_OUTPUT");
    Map<Integer, List<Person>> peopleByAge = 
      people.stream()
            .collect(Collectors.groupingBy(Person::getAge));
    System.out.println("Grouped by age: " + peopleByAge);
    System.out.println("//" + "END:GROUP_BY_OUTPUT");
}

{  
    System.out.println("//" + "START:GROUP_BY_AGE_NAME_OUTPUT");
    Map<Integer, List<String>> nameOfPeopleByAge = 
      people.stream()
            .collect(
              groupingBy(Person::getAge, mapping(Person::getName, toList())));
    System.out.println("People grouped by age: " + nameOfPeopleByAge);
    System.out.println("//" + "END:GROUP_BY_AGE_NAME_OUTPUT");
}

{  
    System.out.println("//" + "START:OLDEST_IN_EACH_LETTER_OUTPUT");
    Comparator<Person> byAge = Comparator.comparing(Person::getAge);
    Map<Character, Optional<Person>> oldestPersonOfEachLetter = 
      people.stream()
            .collect(groupingBy(person -> person.getName().charAt(0),
               reducing(BinaryOperator.maxBy(byAge))));
    System.out.println("Oldest person of each letter:");
    System.out.println(oldestPersonOfEachLetter);
    System.out.println("//" + "END:OLDEST_IN_EACH_LETTER_OUTPUT");
}

MEMO: 集計関数を実際に色々使ってみる！！

3.5 ディレクトリの全ファイルをリスト

Fileクラスのlist()メソッドを使うと、ディレクトリにある全ファイル名を簡単にリスト化できる
ファイル名だけでなくすべてのファイルを取得する場合はlistFiles()メソッドが使える
ファイルを取得したあとの処理が大変
ここでは、従来のくどい外部イテレータを使用するのではなく、エレガントな関数型スタイルの機能を使ってリストをイテレートしていく

  // 以下の２つとも古いjavaより格段にシンプル
  Files.list(Paths.get("."))
       .forEach(System.out::println);
  }
  Files.list(Paths.get("."))
       .filter(Files::isDirectory) // filterはPredicateを期待する
       .forEach(System.out::println);
  }

3.6 ディレクトリの特定のファイルだけをリスト

特定のファイル名取得のためにオーバーロードされたFileクラスのlist()メソッドを提供してきました
このlist()メソッドはFilenameFilterインターフェースを引数に取ります

  final String[] files =
    new File("fpij").list(new java.io.FilenameFilter() {
      public boolean accept(final File dir, final String name) {
        return name.endsWith(".java");
      }
    });

これをラムダ式に置き換える！

    Files.newDirectoryStream(
         Paths.get("fpij"), path -> path.toString().endsWith(".java"))
     .forEach(System.out::println);
  }

3.7 flatMapで直下のサブディレクトリをリスト

与えられたディレクトリ直下のサブディレクトリを探索する方法を解説する
最初に原始的な方法を説明し、次により便利なflatMap()メソッド（Streamクラス）を使用する

  public static void listTheHardWay() {
    List<File> files = new ArrayList<>();

    File[] filesInCurrentDir = new File(".").listFiles();
    for(File file : filesInCurrentDir) {
      File[] filesInSubDir = file.listFiles();
      if(filesInSubDir != null) {
        files.addAll(Arrays.asList(filesInSubDir));
      } else {
        files.add(file);
      }
    }

    System.out.println("Count: " + files.size());
  }

  public static void betterWay() {
    List<File> files =
      Stream.of(new File(".").listFiles())
            .flatMap(file -> file.listFiles() == null ? 
                Stream.of(file) : Stream.of(file.listFiles()))
            .collect(toList());
    System.out.println("Count: " + files.size());
  }

MEMO: モナド合成という言葉が出てきたが、いまいち意味がわからない

3.8 ファイルの変更を監視

ファイルが生成・変更・削除される際のアラートも簡単に実現できる
Java7で追加されたWatchServiceの機能を紹介

  public static void main(String[] args) throws Exception {
    new Thread(() -> watchFileChange()).start();
    final File file = new File("sample.txt");
    file.createNewFile();
    Thread.sleep(5000);
    file.setLastModified(System.currentTimeMillis());
  }
  
  public static void watchFileChange() {
    try {
      final Path path = Paths.get(".");
      final WatchService watchService = 
        path.getFileSystem()
            .newWatchService();
        
      path.register(watchService, StandardWatchEventKinds.ENTRY_MODIFY);
      
      System.out.println("Report any file changed within next 1 minute...");

      final WatchKey watchKey = watchService.poll(1, TimeUnit.MINUTES);
      
      if(watchKey != null) {
        watchKey.pollEvents()
                .stream()
                .forEach(event ->
                   System.out.println(event.context()));
      }
    } catch(InterruptedException | IOException ex) {
      System.out.println(ex);
    }
  }

3.9 まとめ

文字列操作やファイル処理、カスタムコンパレータの生成などの定型タスクはラムダ式とメソッド参照によって非常に楽に、簡潔になりました。

4章　ラムダ式で設計する

本章では、ラムダ式が巧妙なデザインアイデアに生命を与える
これまではオブジェクトを使用していた箇所を軽量関数で代用できる

4.1 ラムダ式を使った関心の分離

コードの再利用のためにクラスを生成することは良い心がけですが、それが常に正しいとは限らない
クラスの代わりに高階関数を使うことで、クラス階層を必要とせずに同じことが達成できる

4.1.1 デザイン問題の探求

// JavaBean
public class Asset {
  public enum AssetType { BOND, STOCK }; 
  private final AssetType type;
  private final int value;
  public Asset(final AssetType assetType, final int assetValue) {
    type = assetType;
    value = assetValue;
  }
  public AssetType getType() { return type; }
  public int getValue() { return value; }
}
// Utilクラス
  public static int totalAssetValues(final List<Asset> assets) {
    return assets.stream()
                 .mapToInt(Asset::getValue)
                 .sum();
  }

ラムダ式を使って、totalAssetValues()メソッドを書き、流暢なイテレータと好むべき不変性を使いました
しかし今はメソッド自身の設計に目を向けましょう
このメソッドでは
- どのようにイテレーションを行うか
- 何を合計するか
- どのように合計するか
  - といった３つの問題が絡み合っている

4.1.2 問題でがんじがらめ

資産のうち、債券（bond）だけを合計したい場合を考える

  public static int totalBondValues(final List<Asset> assets) {
    return assets.stream()
                 .mapToInt(asset -> 
                    asset.getType() == AssetType.BOND ? asset.getValue() : 0)
                 .sum();
  }

  public static int totalStockValues(final List<Asset> assets) {
    return assets.stream()
                 .mapToInt(asset -> 
                    asset.getType() == AssetType.STOCK ? asset.getValue() : 0)
                 .sum();
  }

こんなふうにコピペで増やしていって良いでしょうか？
DRYの原則に従ってもう少しましな設計をしましょう

4.1.3 主要な関心の分離

イテレーションと合計を求める方法は同じですが、「何を」合計するかが異なります
この「何を合計するか」部分はメソッドから切り離す良い候補

  public static int totalAssetValues(final List<Asset> assets,
    final Predicate<Asset> assetSelector) {
    return assets.stream()
                 .filter(assetSelector)
                 .mapToInt(Asset::getValue)
                 .sum();
  }
  
  public static void main(final String[] args) {
    List<Asset> assets = Arrays.asList(
      new Asset(Asset.AssetType.BOND, 1000),
      new Asset(Asset.AssetType.BOND, 2000),
      new Asset(Asset.AssetType.STOCK, 3000),
      new Asset(Asset.AssetType.STOCK, 4000)
    );

    System.out.println("Total of all assets: " + 
      totalAssetValues(assets, asset -> true));

    System.out.println("Total of bonds: " + 
      totalAssetValues(assets, asset -> asset.getType() == AssetType.BOND));

    System.out.println("Total of stocks: " + 
      totalAssetValues(assets, asset -> asset.getType() == AssetType.STOCK));
  }

個々まではメソッドレベルでの関心の分離を行いましたが、次はクラスレベルで応用します

4.2 ラムダ式を使った委譲

4.3 ラムダ式を使ったデコレーション

Cameraクラスのフィルター設定

4.4 defaultメソッドを覗く

interfaceがdefaultメソッドを持てる
実装の衝突を防ぐためにルールが存在する
実際にinterfaceにdefaultメソッドが記述できるメリットがあまり浮かばないような気がする

4.5 ラムダ式を使った流暢なインタフェース

MEMO: ここは参考になる実装だと感じた
- 用途例：メーラの設定、データベース設定パラメータの設定、インスタンスの連続した状態を管理下におきつつ構築する必要のある場合
- ローンパターンと言うらしい

  private FluentMailer() {}
  
  public FluentMailer from(final String address) { /*... */; return this; }
  public FluentMailer to(final String address)   { /*... */; return this; }
  public FluentMailer subject(final String line) { /*... */; return this; }
  public FluentMailer body(final String message) { /*... */; return this; }
  
  public static void send(final Consumer<FluentMailer> block) {
    final FluentMailer mailer = new FluentMailer();
    block.accept(mailer);
    System.out.println("sending...");
  }

  //...
  public static void main(final String[] args) {
    FluentMailer.send(mailer ->
      mailer.from("build@agiledeveloper.com")
            .to("venkats@agiledeveloper.com")
            .subject("build notification")
            .body("...much better..."));
  }

4.6 例外処理

ラムダ式の例外処理について
- MEMO: 再読する必要あり

4.7 まとめ

5章　外部リソースを扱う

Java仮想マシン（JVM）は、自動的にガベージコレクション（GC）を行っているものだと信じているかもしれません。
内部リソースだけを扱っている場合はJVMにGCを任せられることは事実
しかし、
- データベース接続
- ファイルやソケット
- ネイティブリソースといった外部リソースを使用する場合は
  - GCは開発者の責任範囲
本章では、ラムダ式を使って、execute around method(EAM)を実装します。
連続操作をより効率的に制御できます。そしてこのパターンを使ってロック管理と書き込み例外テストを行います

5.1 リソースの解放

finalize()なんて使ったらGCされずに貯まるでしょ？
close()メソッドで閉じる？→閉じ忘れたらどうするの？→エラー発生したらclose()呼ばれないままになるよね？
try-with-resources構文使う？Java7から追加された便利な構文だけど、開発者が下記忘れたら元も子もない、AutoClosableの実装もしておかないと行けないでしょ？
- →ラムダ式で解決しましょう！という説明

5.2 ラムダ式でリソース解放

ラムダ式で設計して、開発者にこれを使うように共有すれば問題なし


public class FileWriterEAM  {
  private final FileWriter writer;
  
  private FileWriterEAM(final String fileName) throws IOException {
    writer = new FileWriter(fileName);
  }
  private void close() throws IOException {
    System.out.println("close called automatically...");
    writer.close();
  }
  public void writeStuff(final String message) throws IOException {
    writer.write(message);
  }
  //...

  public static void use(final String fileName,
    final UseInstance<FileWriterEAM, IOException> block) throws IOException {

    final FileWriterEAM writerEAM = new FileWriterEAM(fileName);
    try {
      block.accept(writerEAM);
    } finally {
      writerEAM.close();
    }
  }

  public static void main(final String[] args) throws IOException {
  
    System.out.println("//" + "START:EAM_USE_OUTPUT");
    FileWriterEAM.use("eam.txt", writerEAM -> writerEAM.writeStuff("sweet"));
    System.out.println("//" + "END:EAM_USE_OUTPUT");

    FileWriterEAM.use("eam2.txt", writerEAM -> {
        writerEAM.writeStuff("how");
        writerEAM.writeStuff("sweet");
      });

  }

}

// interface
// @FunctionalInterfaceは関数型インターフェースであることの宣言
// 例外を考慮する必要がなければ、Consumerインターフェースを使えばよかったが、ラムダ式は、合成されるabstratメソッドのシグネチャの一部として定義されたチェック例外を投げることができるため実装
@FunctionalInterface
public interface UseInstance<T, X extends Throwable> {
  void accept(T instance) throws X;
}

MEMO: execute around methodパターンの構造らしい
- この仕組はファイル読み込みを行う際に見習うべき
- そもそも標準のjavaでファイル読み込み時に自動的に開放するような書き方ができないか確認すべき
- 実際には読み込みファイルと書き込みファイル両方を開いて処理を行う場合が多いのでは？
  - そのような場合どうやって書いていく？
- Transactionという形でUTIL作成して、複数ファイルをオープンして操作していけば行ける？

5.3 ロックの管理

コンカレントなJavaアプリケーションにおいてロックは重要な役割を果たす
ここでは、ラムダ式を使って細かなロックの制御を行い、重要なセクションの適切なロックの単体テストの可能性を開く

public class Locker {
  public static void runLocked(Lock lock, Runnable block) {
    lock.lock();

    try {
      block.run();
    } finally {
      lock.unlock();
    }
  }
}

MEMO: Lockの使い方確認このロジックレベルでロックする使い所がいまいちピンとこない
- 使い所があれば、synchronizedを使用するより、こちらの方が単体テストもしやすいメリットがあるみたい

5.4 簡潔な例外テストの生成

Junitフレームワークなどでアノテーションを使用した、例外テストを実施する場合は、
ラムダ式で書き換えた方が良いという例

public class RodCutter {
  private boolean mustFail;
  
  public RodCutter(final boolean fail) { mustFail = fail; }

  public void setPrices(final List<Integer> prices) {
    //...
    if(mustFail) 
      throw new RodCutterException();
  }

  public int maxProfit(final int length) {
    if (length == 0) throw new RodCutterException();
    
    return 0;
  }
}


public class RodCutterTest {
  private RodCutter rodCutter;
  private List<Integer> prices;
  
  protected RodCutter createCutter() {
    return new RodCutter(false);
  }
  
  @Before public void initialize() {
    rodCutter = createCutter();
    prices = Arrays.asList(1, 1, 2, 2, 3, 4, 5);
  }

  @Test public void VerboseExceptionTest() {
    rodCutter.setPrices(prices);
    try {
      rodCutter.maxProfit(0);
      fail("Expected exception for zero length");
    } catch(RodCutterException ex) {
      assertTrue("expected", true);
    }
  }

  @Test(expected = RodCutterException.class) 
  public void TerseExceptionTest() {
    rodCutter.setPrices(prices);
    rodCutter.maxProfit(0);
  }

  // Lamda式を利用したテスト方法
  @Test 
  public void ConciseExceptionTest() {
    rodCutter.setPrices(prices);
    assertThrows(RodCutterException.class, () -> rodCutter.maxProfit(0));
  }
  
  public static void main(String[] args) {
    junit.textui.TestRunner.run(new JUnit4TestAdapter(RodCutterTest.class));
  }
}


// HELPERの実装
public class TestHelper {
  public static <X extends Throwable> Throwable assertThrows(
    final Class<X> exceptionClass, final Runnable block) {

    try {
      block.run();
    } catch(Throwable ex) {
      if(exceptionClass.isInstance(ex))
        return ex;
    }
    fail("Failed to throw expected exception ");
    return null;
  }
}

MEMO: 現在のフレームワークでラムダ式を利用したメソッドが提供されていないかどうか確認する

5.5 まとめ

アプリケーションが外部リソースを使用する場合、全面的に自動ガベージコレクションに頼ることはできません。
execute around methodパターンは実行フローのきめ細かい制御や外部リソースの開放に役立つ
- オブジェクト生存期間の制御
- ロック管理
- 簡潔な例外テストの記述

6章　「遅延させる」ということ

6.1 初期化の遅延

オブジェクト内部に重いリソースが存在する場合、その生成を後回しにできれば有益
オブジェクトの一部の生成をアトマwしにするという設計上の決断は、オブジェクトを使う開発者にとって重荷になるべきではなく、シームレスであるべき

public class Holder {
  private Supplier<Heavy> heavy = () -> createAndCacheHeavy();
  
  public Holder() {
    System.out.println("Holder created");
  }

  public Heavy getHeavy() {
    return heavy.get();
  }
  //...

  private synchronized Heavy createAndCacheHeavy() {
    class HeavyFactory implements Supplier<Heavy> {
      private final Heavy heavyInstance = new Heavy();

      public Heavy get() { return heavyInstance; }
    }

    if(!HeavyFactory.class.isInstance(heavy)) {
      heavy = new HeavyFactory();
    }

    return heavy.get();
  }

  public static void main(final String[] args) {
    final Holder holder = new Holder();
    System.out.println("deferring heavy creation...");
    System.out.println(holder.getHeavy());
    System.out.println(holder.getHeavy());
  }
}

virtual poroxyパターン
オブジェクトの生成に１レベル挟む次はラムダ式で実現する

6.2 遅延評価

短絡評価： fn1() || fn2()
メソッドの引数の場合は渡されたものすべてが評価される
- すべての引数を使用しない場合はその評価に費やした時間とリソースが無駄になる
- ここでもラムダ式を使って任意の引数の評価を遅らせることができる
メソッド実行時にある引数が使用されない可能性があることがわかっていれば、いくつかの引数、またはすべての引数を遅延実行するようにメソッドのインターフェースを変更できる


public class Evaluation {
  public static boolean evaluate(final int value) {
    System.out.println("evaluating ..." + value);
    simulateTimeConsumingOp(2000);
    return value > 100;
  }
  //...

  public static void simulateTimeConsumingOp(final int millseconds) {
    try { 
      Thread.sleep(2000); 
    } catch(Exception ex) { throw new RuntimeException(ex); }
  }

  public static void eagerEvaluator(
    final boolean input1, final boolean input2) {
    System.out.println("eagerEvaluator called...");
    System.out.println("accept?: " + (input1 && input2));
  }

  /**
  * 遅延評価のためのメソッド
  * ラムダ式を引数に取り、実行自体はこのメソッドの中で行う
  */
  public static void lazyEvaluator(
    final Supplier<Boolean> input1, final Supplier<Boolean> input2) {
    System.out.println("lazyEvaluator called...");
    System.out.println("accept?: " + (input1.get() && input2.get()));
  }
  
  public static void main(final String[] args) {

    System.out.println("//" + "START:EAGER_OUTPUT");
    eagerEvaluator(evaluate(1), evaluate(2));
    System.out.println("//" + "END:EAGER_OUTPUT");

    // ４秒かかっていた処理が２秒でfalseを返却するようになる
    System.out.println("//" + "START:LAZY_OUTPUT");
    lazyEvaluator(() -> evaluate(1), () -> evaluate(2));
    System.out.println("//" + "END:LAZY_OUTPUT");
  }
}

デメリット
- ラムダ式をわざわざ書かないと行けないので面倒（場合によってはメソッド参照を利用できる）
- コード量は多くなる
MEMO: フレームワークで遅延処理を行うためにはどのようにするべきか

6.3 Streamの遅延処理を活用

Streamの遅延評価について説明

6.3.1 中間処理と終端処理

Streamには２種類のメソッドがある
- 中間処理
- 終端処理
Streamの遅さは複数の中間処理をチェーンし、最後に終端処理を行うことで実現している

  List<String> names = Arrays.asList("Brad", "Kate", "Kim", "Jack", "Joe",
    "Mike", "Susan", "George", "Robert", "Julia", "Parker", "Benson");
  System.out.println("//" + "START:CHAIN_OUTPUT");
  {

  // ここの処理はコレクションの変換に多くの作業を費やしている働き者に見えますが、実は見かけによらず怠け者です。
  final String firstNameWith3Letters = 
    names.stream()
          .filter(name -> length(name) == 3)
          .map(name -> toUpper(name))
          .findFirst()
          .get();

  System.out.println(firstNameWith3Letters);
  }
  System.out.println("//" + "END:CHAIN_OUTPUT");

本当に必要な処理以外は実施していないらしい
その詳細を次で！述べる
中間処理、終端処理まで考慮された上で、初めて処理が実行される
- filter 12処理
  - map 2処理
    - findFirst 1処理
- ではなく！
- filter 3 処理！！
  - map 1処理
    - findFirst 1処理
- という形で評価される
JDKが裏で結合（fusing）処理を行うことで実現している
データの通り道は１本ということ
要素の抽出、マッピング、選択が１度に行われる

6.4 無限の「遅い」コレクションを生成

MEMO: スキップ

6.5 まとめ

7章　再帰の最適化

再帰は魅力的で強力な問題解決方法
再帰はとても表現力に富んでいます
大きな問題の再帰処理を可能とする末尾呼び出し最適化（tail-call optimization TCO）を説明

7.1 末尾呼び出し最適化を使う

再帰を使う上で最も高いハードルは、巨大な入力値によるスタックオーバーフローのリスク
しかし、末尾呼び出し最適化（TCO）という優れたテクニックがこの心配のタネを取り除く
末尾呼び出しとは
- 最後の処理が自身の呼び出しとなるような再帰呼び出しのことを言います
JavaはTCOをコンパイラレベルで直接サポートしていませんが、ラムダ式を使って数行で実装できる
このソリューションはトランポリンとも呼ばれrます。

// 通常の実装
  public static int factorialRec(final int number) {
    if(number == 1)
      return number;
    else
      return number * factorialRec(number - 1); 
  }
  // 大きい数を渡すとStackOverflowErrorが発生

この再帰関数は大きな入力値を扱えず、落ちてしまう
再帰が強力で表現力豊かであっても使えません。
この問題は再帰そのものにあるわけではない
再帰の完了を待つ間、部分的な計算結果をすべて保存しているためです。
スタックに積み上げずに再帰を行う方法が必要

7.1.2 末尾再帰に変換する

遅延評価させるために
- TailCall関数型インターフェース
- TailCallsクラスを設計する

  public static TailCall<Integer> factorialTailRec(
    final int factorial, final int number) {
    if (number == 1)
      return done(factorial);
    else
      return call(() -> factorialTailRec(factorial * number, number - 1));
  }

MEMO: TCOについて理解できていない... 再帰処理設計が必要になったら読み返す

7.2 メモ化でスピードアップ

7.3 まとめ

8章　ラムダ式で合成

Java8には、オブジェクト志向アプローチと関数型スタイルという２つの強力なツールがある
組み合わせて使っていこう！
本章では、
- 関数合成を詳しく説明し、実践的なMapReduceパターンを例として実装
- MapReduceパターンでは、独立した計算処理を分散し、それらの処理結果を集約して最終的な結果を計算します
- 最後はJDKの力を借りて、この計算処理を簡単に並列化します。

8.1 関数合成の利用

オブジェクト指向＋関数型スタイル複合アプローチでは、状態が変化するのではなく、軽量なオブジェクトが別のオブジェクトに変換される
可変性がないことで、エラー発生の可能性を減らし、並列実行家より簡単
リストからStreamを作成し、オリジナルのリストは変更されず、新しくオブジェクトを生成するということが言いたいだけ

8.2 MapReduceの使用

MapReduceパターンは２つの操作がある
- コレクションの各要素で実行する操作
- これらの実行結果を組み合わせて最終結果を導き出す
このパターンでマルチコアプロセッサを有効活用可能であることから注目をされつつある
Tickers.symbols.parallelStream()は裏側に隠れているスレッドプールで管理された複数のスレッドで、
map()やfilter()のようなメソッドを並列処理します。
stream()とparallelStream()のどちらを使用するかを決める際には、いくつかの問題を考えなければいけません
- 本当にラムダ式を同時に実行したいのか？
- 対象コードは副作用や競合状態が発生しない、独立した動作を行える？
- 実行順序に影響を与えることはないか？
map()やfilter()のように、計算を行って、その結果を次の処理に回すようなメソッドは並列化に向いている
MEMO: 闇雲に並列化はしないほうがよい！！
並列ストリームを選択すべきか？
- ライブラリは簡単に並列化を行ってくれるが、並列化が常に正しい選択であるとは限らない
- データと、実行する計算内容によっては、並列計算はシーケンシャルな計算より遅くなることもあり得る
- 並列化実行処理のためのコストもかかる
- コレクションが小さいのであれば、シーケンシャル実行のほうが早くなるかも
- 速度を計測して実装していくべき

8.3 並列化への飛躍

8.4 まとめ

9章　すべてをまとめて

本書を通してJava8のラムダ式を紹介しました
コレクションのイテレーションを行い
軽量でよりよい設計を実現し、コードを簡単に合成、そして並列化しました。
この最終章ではまとめとして、関数型スタイルのプログラミングを使って、最大の効果を上げるために
磨いておくべきことを説明し、関数型スタイルを採用して成功するための推奨事項を最後に取り上げる

9.1 関数型スタイルで成功するために実践すべきこと

新機能のメリットを十分に活かし、簡潔で軽量なアプリケーションを生成するには、設計、コーディング、そして考え方まで変えなければいけません。

これまでのJavaを使ってきた命令形や、オブジェクト指向のパラダイムとは違うもの

ここでは根本的に変えるべきアプリケーション開発手法や、その変更によって得られる利点について説明

9.1.1 宣言的により近く、命令型からより遠く

価格リストを与えられていて、その中から最大値を選ぶようにと依頼されたとしたときに、
命令型のfor文で最大値を探すのではなく、ラムダ式を使ってstream経由で取得する

9.1.2 普遍性の尊重

状態変更が可能な(mutable)変数はあまり上品とは言えません。
そしてそのような変数の共有は単なる害悪
開発者は変数の状態変更によって混乱させられてしまい、時には変更を見逃してしまいます。
したがって、変更可能な変数が多いほど、より多くのエラーが発生する可能性があるということ
正確な並列化が非常に難しくなるということもデメリット
関数型スタイルの導入がそれを簡単にしてくれる
純粋な関数型言語は値しか持っていません。つまり１回しか書き込みができない、初期化後は全く変更を受け付けない変数です。
しかしJavaはそのような言語とはことなり、不変性(immutability)を強制しないため、不変性を尊重する責任は開発者にある

9.1.3 副作用の削減

副作用を減らそう
所感：時間や状態などの外部要員によって関数の処理結果が異なることが無いように作成すること

9.1.4 文より式を優先

文：アクションを実行するが何も返さない
式：アクションを実行して結果を返す
文は何も返さないため、目的を遂行するためには副作用を起こしメモリを書き換える必要がある
一方式は、参照透明性を保つように設計できるため、これまでに述べたメリットを得られる
式を使うメリット
- 関数合成ができるということが挙げられる
- チェーンでコードを記述することで、文章を読むように簡単にコードを読めるようになる

9.1.5 高階関数を利用して設計

これまでは匿名内部クラスを単一メソッドのインターフェースに渡していたような場所で、
ラムダ式やメソッド参照を渡すことができる様になり、コードがより簡潔になります。
メーラーを関数で設計することでローンパターンを適用する例
Colorフィルターを関数で表現する例
関数を引数に渡してDRYな設計をしよう

9.2 パフォーマンスの問題

命令型のコードと比較してもパフォーマンスは劣らない
- メリット
  - 直感的に見やすい
  - 並列化も容易
関数型を採用しましょう
MEMO: 処理時間の違いはむやみに信頼できるものではないのでやめましょうと書かれている...

9.3 関数型スタイルを採用

実際に使ってみて、試して、より良い設計を考えていこう！

付録A 基本的な関数型インタフェース

JDK8には様々な関数型インターフェースを持っている
ここでは頻繁に出現する基本的なインターフェースをいくつか紹介

A.1 Consumer`<T>`

入力を受け入れ、戻り値を返さない操作を表すインターフェース
有効活用するためには副作用を伴う必要がある
抽象メソッド
- accept()
defaultメソッド
- andThen()
主な利用方法
- forEach()メソッドの引数
特注なプリミティブ
- IntConsumer, LongConsumer, DoubleConsumerなど

package java8sample;

import java.util.function.Consumer;

public class Java8Sample {
    public static void main(String[] args) {
        Consumer<String> hoge = string -> System.out.println("hoge : " + string);
        Consumer<String> fuga = string -> System.out.println("fuga : " + string);

        Consumer<String> piyo = hoge.andThen(fuga);

        piyo.accept("piyo");
    }
}

A.2 Supplier`<T>`

新しいインスタンス、またはあらかじめ生成しておいたインスタンスを返すファクトリ。
抽象メソッド
- get()
defaultメソッド
- なし
主な利用方法
- 遅延実行を行う無限Streamの生成
- OptionalクラスのorElseGet()メソッドの引数
特殊なプリミティブ
- IntSupplier, LongSupplier, DoubleSupplierなど

package java8sample;

import java.util.function.Supplier;

public class Java8Sample {
    public static void main(String[] args) {
        Supplier<String> supplier = () -> "hoge";
        System.out.println(supplier.get());
    }
}

遅延初期化で少し出てきた程度

A.3 Predicate`<T>`

入力値が何らかの条件に該当するかを確認するために有効。
抽象メソッド
- test()
defaultメソッド
- and(), nagate(), or()
主な利用方法
- Streamのfilter()やanyMatch()メソッドなどの引数
特殊なプリミティブ
- IntPredicate, LongPredicate, DoublePredicateなど
anyMatchはリストのStreamのうちどれか１つでも一致する条件であればtrueを返却する動きになるみたい
- →終端操作
filterは中間操作

A.4 Function<T, R>

引数をとって適切な結果値を返す操作を表す変換インターフェース
抽象メソッド
- apply()
defaultメソッド
- andThen(), compose()
主な利用方法
- Streamのmap()メソッドの引数
特殊なプリミティブ
- IntFunction、LongFunction, DoubleFunction, IntToDoubleFunction, DoubleToIntFunction

package java8sample;

import java.util.function.Function;

public class Java8Sample {
    public static void main(String[] args) {
        Function<String, String> wrapDoubleQuotation = str -> "\"" + str + "\"";
        Function<String, String> wrapSingleQuotation = str -> "'" + str + "'";

        Function<String, String> wrapDoubleAndSingleQuotation = wrapDoubleQuotation.compose(wrapSingleQuotation);
        String result = wrapDoubleAndSingleQuotation.apply("hoge");

        System.out.println(result);
    }
}

付録B 構文の基礎

関数型インターフェスのクイック・リファレンス

B.1 関数型インタフェースの定義

関数型インターフェース
- interface実装して、@FunctionalInterfaceを付与する
- 実装されていないabstractメソッドを必ず１つ持つ
- 必要に応じて実装されたdefaultメソッドを持つ
- staticメソッドも持つことができる

B.2 パラメータを持たないラムダ式の生成

B.3 パラメータ 1つのラムダ式の生成

型推論は効くが、明示した場合は (final String str) -> System.out.println(str);などとする

B.4 ラムダ式のパラメータ型を推論する

通常、型推論されるが、１つでも型を明示的に記載する必要がある場合、
すべて引数の型を記載する必要がある

B.5 パラメータ 1つのラムダ式では括弧を省略可能

(name) -> ;とかいても name -> ;とかいてもよい

B.6 複数パラメータを持つラムダ式の生成

複数のパラメータを持つ場合はカッコが必須 frinends.stream().reduce((name1,name2) -> name1.length() >= name2.length() ? name1 : name2);

B.7 複数の型のパラメータを持つメソッドを呼び出す

ラムダ式やメソッド参照を引数に渡せる

B.8 ラムダ式を変数に格納

再利用するためにラムダ式を変数に格納できる

B.9 複数行のラムダ式を生成

ラムダ式は複数行に渡って記載できる
必要に応じて、return文を記載しないといけない

B.10 ラムダ式を返す

メソッドの戻り値型として関数型インタフェースを指定できる

B.11 ラムダ式からラムダ式を返す

ラムダ式を返すラムダ式をかける

B.12 クロージャにおける静的スコープ

B.13 インスタンスメソッドのメソッド参照を渡す

B.14 メソッド参照をstaticメソッドに渡す

B.15 メソッド参照を他のインスタンスのメソッドに渡す

B.16 複数の引数を取るメソッドの参照を渡す

B.17 コンストラクタ参照を使う

B.18 関数合成

付録C Web上のリソース

Cutting Stock問題
- https://en.wikipedia.org/wiki/Cutting_stock_problem
- メモ化テクニックを使って解決できる最適化問題
依存関係逆転の原則
- クラスの実装で拡張するのではなく、抽象（インタフェース）とカップリングすることによる拡張方法を説明している
DRY原則
- https://ja.wikipedia.org/wiki/Don't_repeat_yourself
本質と儀式について（Essence vs. Ceremony）
- →古いからやめようと思う
Execute Around Methodパターン
ローンパターン(Loan Pattern)
- Scalaにおけるローンパターンの紹介
- 記事がなかった
  - https://docs.scala-lang.org/
伝えろ。聞くな。
- https://pragprog.com/articles/tell-dont-asks
- 伝えろ、聞くなという原則を説明するコラム
書籍サイト
- https://pragprog.com/

付録D 参考文献

訳者あとがき

索引

１分で話せ

Sun, 01 Mar 2020 00:00:00 GMT

１分で話せ

立ち読みレベル


プレゼンのゴールを設定する
相手に動いて欲しいのか？
相手に賛成、許可をして欲しいのか
意見が欲しいのか、教えて欲しいのか

ロジカルな１分ストーリーを考える
主張　結論がある
複数の根拠がある　意味が結論に通じている

根拠は３つ必要
あのお店美味しいから行こう！
じゃあ、美味しいお店は他にもあるよ、、
あのお店美味しくて、安くて、雰囲気いいから行こう！
そこまでいうなら行ってみようか！

より聞き手に伝わるように削った文章を話す
基本的に、は、例外を離さないならいらない
念頭に、は、~すべく
横文字は伝わりやすいか考える
先ほど述べたように、も、いらない

頑張ったことは話すな
結論だけ話すこと！

聞き手の数や会議室の広さを考えて
パワポの文字サイズを考える
1番後ろの席の人が見えるように

聞き手が行動するもう一歩をイメージさせる
ポイントについての深掘りをするために
たとえば、具体的に、などで繋げて話す

人は80%のことを聞いていない
キチリクルンの例
私という人間はどういう人間かを伝えることが大事
覚えてもらうことが大事
会社の上司に説明してもらうことが大事
そのためには短い言葉で印象に残らせる必要がある

人前で話すときの4つのポイント
視線　しっかり相手を見る
手振り　多少、動きをつける
声　相手と対話するように声を届ける
間合い　話の区切りで普段より3秒ほど長く間をとってみる

メタ認知は優秀なビジネスパーソンに共通するスキル

■人から話しかけられた時
◯状況判断
・目的は何なのか（連絡されるのか、相談されるのか、何かしてほしいのか）
・相手の目的を満たす回答をする
・この話はどれくらいかかるのかを考える（場合によっては後に回してもらう）

■人に話しかける時
◯目的別
・報告、連絡
・相談、解決策やアドバイスが欲しい
・依頼、何かをして欲しい
・説得、自分はこう思う、理由はこうです
・雑談
◯ジェスチャー、振る舞い
・視線 しっかり相手の目を見る
・手振り 多少動きをつける
・声 相手に声を確実に届ける、聞こえているか、理解しているかを確認しないままだらだら話さない
・間合い 話の区切りで3秒ほど長く間をとる
◯構成
・結論ファースト
・要点をまとめておく
◯振り返り
・メタ認知
・反省

AngularWebアプリ開発スタートブック

Sat, 15 Feb 2020 00:00:00 GMT

Angularアプリケーションプログラミング

電子書籍購入
説明書
学習ログ

こちらの書籍は 2019/06/19 紙版の3刷に対応するため更新をおこないました。
（概要）
本書は，JavaScriptの定番SPA開発フレームワーク「Angular」の解説書です。データバインディング，コンポーネント，依存性注入といったAngularを理解するための基本要素をはじめ，ディレクティブ／パイプ，フォーム，ルーティング，モジュール／コンポーネントの技術解説，ディレクティブ／パイプ／サービスの自作やテストなどの応用的なテーマまでを網羅。また，Angular 4に対応し，5以降のアップグレードにも留意した解説を行っています。Angularによる動的Webアプリケーション開発に必要となる知識が，この1冊で身に付きます！

（こんな方におすすめ）
・Angularを利用したSPAアプリケーション開発に興味のある人

（目次）
導入編
第1章イントロダクション

第2章Angular の基本

第3章データバインディング

基本編
第4章標準パイプ／ディレクティブ

第5章フォーム開発

第6章コンポーネント開発

第7章サービス開発

応用編
第8章ルーティング

第9章パイプ／ディレクティブの自作

第10章テスト

第11章関連ライブラリ／ツール

AppendixTypeScript簡易リファレンス

フォーマット： Kindle版
ファイルサイズ： 56752 KB
推定ページ数： 838 ページ
出版社: 技術評論社 (2017/8/4)
販売： Amazon Services International, Inc.
言語: 日本語
ASIN: B074M54GM5
Text-to-Speech（テキスト読み上げ機能）: 有効 
X-Ray:
有効
Word Wise: 有効にされていません
カスタマーレビュー: 5つ星のうち 4.7   14件のカスタマーレビュー
Amazon 売れ筋ランキング: Kindleストア 有料タイトル - 21,411位 (Kindleストア 有料タイトルの売れ筋ランキングを見る)
1165位 ─ 工学 (Kindleストア)

書籍情報ページhttps://wings.msn.to/index.php/-/A-03/978-4-7741-9130-0/

AngularWebアプリ開発スタートブック

Sun, 29 Dec 2019 00:00:00 GMT

AngularWebアプリ開発スタートブック

電子書籍購入
学習ログ

書籍情報

著者
- 大澤文孝
出版社
- ソーテック社; B5変形版 (2018/4/7)
定価
- 3,025円
発売日
- 2018/4/7
ISBN-13
- 978-4-8026-1185-5
ISBN-10
- 4800711975
目次
- Chapter1 Angularって何?
- Chapter2 開発環境を整えよう
- Chapter3 Angularプロジェクトを作ろう
- Chapter4 Angularの基本
- Chapter5 入力フォームを作ってみよう
- Chapter6 入力エラーを検知するバリデータ
- Chapter7 リアクティブフォーム入門
- Chapter8 さまざまな入力コントロール
- Chapter9 ページの割り当てと遷移
- Chapter10 検索機能を実装する
- Chapter11 Webサーバで動かす
サンプルプログラム
- http://www.sotechsha.co.jp/sp/1197/
こんな方に
- ○「将来、Webアプリ開発に取り組みたい」
- ○「Angular特有の機能について学びたい」
- ○「TypeScriptの作法について学びたい」
- ○「新しいフレームワークの作法をざっと知りたい」
はじめに
- 次の２点を重点的に解説
  - Angularの動作の仕組み
  - 何をどのような書式で記述しなければならないのか

コンサル一年目が学ぶこと

Sun, 03 Nov 2019 00:00:00 GMT

コンサル一年目が学ぶこと

学習ログ

学んだこと

結論ファースト、PREP法で話す、言い訳から取り繕った話し方をしない（Talk Straight）
出来ないときは出来る方法を提案することが大事（何があればできるのか、何人いればできるのか、いつまでならできるのか）
相手の期待値を把握することの重要性
数値を用いて説明する
考えてから仕事を進める（道筋決めてから）
ロジックツリーを使いこなす（ケース問題の紐解き方法と同じだと感じた）
「雲雨傘」提案法事実、解釈、アクションの区別をつける
議事録のエッセンス（日時・場所・参加者・アジェンダ・決まったこと・決まらなかったこと・確認が必要な事・次回TODO・キーパーソンの意見）
説明資料はワンスライド・ワンメッセージの構成にすること
余計なことをやらない・価値のあることだけする
しゃべらないなら会議に出るな
コミットメント力の高い人の傍にいること
フォロワーシップは部下としてのリーダーシップ

手に取った理由

コンサルタントとしての考え方の基礎的な要素が知りたかった

Azure実践ガイド

Fri, 01 Mar 2019 00:00:00 GMT

Azure実践ガイド

学んだこと

※読書中..
学習メモ

手に取った理由

業務でAzure環境を使用することになり、基礎知識を養うために購入

Github実践入門

Fri, 01 Mar 2019 00:00:00 GMT

Github実践入門

学んだこと

そもそも「Githubとは」という部分
Githubの基本的な使い方を手を動かしながら確認できた
途中、UIがそもそも変わっており、情報として古さを感じたため、さっと確認で済ませている

手に取った理由

業務でGitの構成管理方針を決定する立場となったため、今一度基礎から情報を取得する必要があると考えたため

Googleアシスタントアプリ開発入門

Tue, 01 Jan 2019 00:00:00 GMT

Googleアシスタントアプリ開発入門

目次
- ●chapter1 GoogleアシスタントとAction
  - 1.1 AIアシスタント～対話型のインタフェースで問題を解決～
  - 1.2 Googleアシスタントとは？
  - 1.3 Googleアシスタントから呼ばれる機能「Action」を使いこなそう
- ●chapter2 Googleアシスタントのアプリ「Action」の作り方
  - 2.1 アプリ開発エコシステム「Actions on Google」で快適開発
  - 2.2 簡単な会話アプリを作ってみる
  - 2.3 やまびこアプリを作ろう（会話アプリのはじめの一歩）
- ●chapter3 しっかり作るGoogleアシスタントアプリ
  - 3.1 標準的なアプリ実行環境を知ろう
  - 3.2 基本的な処理フローをおさえよう
  - 3.3 アプリのテーマと会話内容を決めよう
  - 3.4 スピーカー向けアプリを作ろう1（静的会話をDialogflowで実装してみる）
  - 3.5 スピーカー向けアプリを作ろう2（「じゃんけんアプリ」に動的会話を実装）
  - 3.6 シミュレータや実機でしっかりテストしよう
  - 3.7 アプリの会話音声をチューニングしよう（SSMLを使う）
  - 3.8 UIを視覚的にリッチにしよう（Rich Responses）
  - 3.9 最終的なプログラムコードを確認しよう
  - 3.10 column：アプリのアルファリリース、ベータリリース
- ●chapter4 いろいろな機能を活用してアプリを作ってみよう
  - 4.1 ToDoリストアプリを作ろう（データベースを利用する）
  - 4.2 位置情報を音声で返すアプリを作ろう（位置情報を利用する）
  - 4.3 天気予報アプリを作ろう（位置情報を利用して周囲の天気予報を応える）
  - 4.4 アラームアプリを作ろう（Push APIを使う）
  - 4.5 column：Actions on Googleのさまざまな機能
- ●chapter5 アプリが世の中に出るまで／出たあと
  - 5.1 作ったアプリを配信しよう（Google社の審査）
  - 5.2 Googleアシスタントにアプリをおすすめしてもらおう
  - 5.3 船出のあと……

学んだこと

Googleアシスタントアプリ開発に必要な用語
※業務で必要な箇所のみ拾い読み
あとで再読したい

手に取った理由

Googleアシスタントアプリの運用/保守に携わっていく上で必要なスキルを習得するため
スピーカー開発関連の知識を増やすため

Javascript本格入門

Tue, 01 Jan 2019 00:00:00 GMT

Javascript本格入門

学んだこと

Javascript開発の体系的な知識
細かく理解できていなかった構文に関する知識
学習メモ

手に取った理由

Nodejs環境でがっちりJavascriptを開発していくにあたり、現在の知識確認とより効率的な開発方法の知識を得るため

徹底攻略AWS認定ソリューションアーキテクト-アソシエイト教科書

Tue, 01 Jan 2019 00:00:00 GMT

徹底攻略AWS認定ソリューションアーキテクト-アソシエイト教科書

学んだこと

AWS サービスについて、Well-architectedフレームワークに沿った５つの観点から説明されておりとても参考になった。（学習メモ参照）
学習メモ

手に取った理由

AWSサービスについて、どんなサービスがあって、どんな使われ方をして、どのように便利なのかなど、基本的な知識を習得するため
AWS SAA資格取得のため

AmazonAlexa開発ガイド

Tue, 01 Jan 2019 00:00:00 GMT

AmazonAlexa開発ガイド

目次
- Chapter 1 Amazon AlexaとAmazon Echo
- Chapter 2 Amazon AlexaとAWSの準備
- Chapter 3 スキル開発入門
- Chapter 4 スキルのデバッグから公開
- Chapter 5 Webサービス連携アプリの開発
- Chapter 6 スマートホームスキルの開発
- Chapter 7 AVSを利用したアプリケーションの構築方法
- Appendix SSML/CLI

学んだこと

AmazonAlexaSkillKitを利用したスキル開発方法
AWS Lambda にサンプルをデプロイし実際に動作させる方法
AlexaSkillKitについての基礎知識
- インテント・スロットなど
- SSML
※本書では、後半、AVSについても述べられているが、直近で必要な知識ではなかったため割愛

手に取った理由

Alexaスキル開発の基礎知識を習得するため

学習メモ


# はじめに

□付属データ（amazon_alexa_sample.zip）の内容
付属データには、以下の内容が含まれています。

Chapter2～7、Appendixで紹介しているサンプルデータ
Chapter7の04節のコマンド入力用テキスト（一部修正用テキスト含む）
Chapter5の02節（P.137）：補足資料1「Twitter developer accountへのアプリ登録」（PDFファイル）
Chapter7の04節（P.210）：補足資料2「Raspberry Pi 3の初回起動時のセットアップ」（PDFファイル）
Chapter7の04節（P.248）：補足資料3「Lチカを行うための配線」（PDFファイル）
□付属データのテスト環境
OS：macOS 10.13.5
Node.js：8.11.1
npm：5.6.0
Alexa開発者コンソール
URL https://developer.amazon.com/alexa/console/
AWS
URL https://aws.amazon.com/jp/
ASK SDK for Node.js：2.0.5
Amazon Echoデバイス
Amazon Echo dot
URL https://www.amazon.co.jp/dp/B072B5BTLK
Homebrew: 1.6.7
AVS Device SDK：1.8.1
□Chapter7 04節で利用した機材
サンワサプライUSBマイクロホンMM-MCU02BK
URL https://direct.sanwa.co.jp/のサイトで「MM-MCU02BK」で検索
Raspberry Pi 3（Model B）
Raspberry Pi 3 Model Bケース+ヒートシンク
https://www.physical-computing.jpのサイトで「Raspberry Pi 3」で検索
ブレッドボード　マイコンボード用実験パーツセット　KP-PRTSET01
URL http://eleshop.jp/shop/g/g402534/
※補足1：上記の「ブレッドボード　マイコンボード用実験パーツセット」には、ジャンプワイヤ（オス・オス）しかありませんので、別途ジャンプワイヤ（オス・メス）をご購入ください。
ジャンプワイヤ（オス・メス）の購入先例
例：ELEGOO 50 PCS オスメスジャンパーワイヤ200mm (無料 170 タイポイント ブレッドボード)
URL https://www.amazon.co.jp/dp/B06ZZXH4XT/
□Chapter7 04節に関するコマンドやリンク先（著者提供サイト）
紙面コマンド & リンクまとめ
URL https://gist.github.com/ShinjiKobayashi/1383691df9d43edd60267e44f6e2e923

# Chapter 1 Amazon AlexaとAmazon Echo

##### Echo Show
2018/08時点では発売されていないがecho show という製品があったりする（画面がついている）

スマートフォンやブラウザ上で実行できるAlexaアプリへカードを表示する機能はあるが、別のデバイスに取り出す必要があり、シームレスな体験でない

##### Echo Look
360度の3Dスキャンが可能な衣装のコーディネートの良し悪しを判断してくれる機能をもつ製品

##### 車載Alexa
BMWやToyotaがプレスリリース

手がふさがっていてもVUIであれば操作可能

##### Alexa Mobile Accessory Kit
スマートフォンのAlexaアプリを介してAlexaの機能を利用できるようにするアプリ

##### Amazon Lex
AWSサービス

Alexaに採用されている深層学習の技術と同等の技術を利用できるサービス

### Alexaスキルキット（ASK）
開発者がAlexaを通じて公開できるアプリケーションのような機能

### Alexaの特色

- スキルの種類
    * カスタムスキル
        + 料理レシピやしりとりゲームな一般的なAlexaスキル
        + Alexaを通じて商品の購入ができるようになったりする
    * スマートホームスキル
        + カメラや証明、鍵等のスマートホームデバイスを制御するスキル
    * フラッシュブリーフィングスキル
        + ※言及なし

## 02カスタムスキルの開発事例
### Alexaスキルの動きを確認する
##### インテント
音声入力の内容を解釈して、キーワードに合わせたタグ付けのようなことを行い、対話モデルを作成

##### スロット
対話モデルをより柔軟に活用することができる（プログラミングにおける変数に近い役割）

「*東京タワー*の天気を教えて」という発話があった場合、*東京タワー*がPlaceスロットに格納されて、インテントと同じくタグ付けされる

この要素を参照すれば、ユーザがどこの天気を知りたいのか把握できる

##### マルチターン会話とダイアログ

まるで本当に会話している様に実装できる

### Alexaスキルの開発事例

##### 人気のあるスキルについて
スキル順位を記載している

##### ユーザーストーリーの作成

##### スキルの目的を決める
##### 明確なユーザ操作をイメージする


## チャプターまとめ
- Alexaを取り巻く世界観やスキルを用いて実現できること
- Alexaの機能や大まかな挙動
- スキル開発をするときに気をつけておくとよいこと

# Chapter 2 Amazon AlexaとAWSの準備

## 01Alexaの開発環境の準備
※割愛
### 全体の構成
### Amazon開発者コンソールの登録方法
### AWSの登録方法

## 02Amazon Echo を使って Hello World

### カスタムスキルの開発工程
- Amazon開発者コンソールの設定
- Lambdaの実装及び設定
- 動作確認

### Amazon 開発者コンソールの設定およびLambdaの実装
1. スキルの基本情報設定
2. Alexaデバイスの応答設定
3. Lambdaの設定及び実装
4. LambdaとAlexaデバイスの応答設定と紐付け

～実際に操作してハローワールドを表示～

# Chapter 3 スキル開発入門

## 01カスタムスキルの開発方法

### カスタムスキルの開発環境構築
### カスタムスキル開発の基本
- Amazon開発者コンソールの設定
- Lambdaの実装

### Amazon開発者コンソールの設定方法

命令文をインテントと呼ばれるものに変換して該当のスキルにわたす

アニマルブックスという架空のスキルを作成する例

### Lambdaの実装方法

npm install --loglevel=error ask-sdk-core ask-sdk-model

##### 実装について見ていく

### 対話型のカスタムスキル開発

repromptを使用して「本のおすすめでよろしいですか？」と聞き返す実装

### 会話内容の一部を扱うスキル開発

##### スロットの実装

## 02Alexaアプリにカードを表示させる
### カードの表示
Alexaではスキルでの発話と同時に発話内容の保管情報としてカードをAlexaアプリに表示することができます。

- カードの種類
    * シンプルカード
    * スタンダードカード

## 03AudioPlayerでスキルを開発する
### AudioPlayerとは
- MP3などのオーディオファイルをストリーミング再生するAlexaの仕組み
- 一時停止やシャッフル再生、ループ再生、キューイングなどもサポートしている
- 再生状態をモニタリングするための仕組みもある
- SSMLを用いることでオーディオファイルの再生をすることも可能だが、90秒の制限がある

### AudioPlayerを使ったスキルを作成する

# Chapter 4 スキルのデバッグから公開

## 01Alexaスキルのデバッグ方法
### Alexaスキルのデバッグ方法
- Alexa Skill Testing Toolについての説明

### Lambdaのデバッグ方法
- Cloud Watchで設定する
- 

## Alexaスキルの公開方法

## 多言語対応

# Chapter 5 Webサービス連携アプリの開発

## 01フラッシュブリーフィングの作り方
### フラッシュブリーフィングスキルとは
- 最新のニュースフィードを提供する機能
- インストールされているフラッシュブリーフィングスキルから提供される最新のニュースフィードをすべて収集し、ユーザに対して収集したニュースを提供する
- 作成手順について
    * フィード提供環境構築
    * フィードの登録

### フィード提供環境構築

amzon api gatewayの設定で躓いた！！

問いかけても「フラッシュニュースです」という内容しか返さない


## 02外部サービス連携アプリの作り方(Twitter連携)
※一旦とばす！

# Chapter 6 スマートホームスキルの開発
※一旦とばす！

# Chapter 7 AVSを利用したアプリケーションの構築方法
※一旦とばす！
端末メーカー様のコネクテット製品に、 簡単にAlexaを実装するためのSDK

# Appendix SSML/CLI

AWS認定ソリューションアーキテクトアソシエイト

Fri, 28 Dec 2018 00:00:00 GMT

書籍「AWS認定ソリューションアーキテクトアソシエイト」

著者　：大塚康徳（日立インフォメーションアカデミー）
単行本（ソフトカバー）: 168ページ
出版社: リックテレコム (2016/8/17)
言語: 日本語
ISBN-10: 486594043X
ISBN-13: 978-4865940435
発売日： 2016/8/17

第1章 AWSと認定プログラムーAWSクラウドとは何か、そして認定プログラムとは何か？ー

割愛
- 試験概要、AWSとはについて説明しているだけ

第2章リージョン／アベイラビリティーゾーンとAWSサービスーリージョンとAZ、そして各種サービスの提供レベルについてー

試験のポイント！
- サーバやデータはAZ間で冗長的に配置する
サービス種別
- リージョンサービス
- AZサービス
- グローバルサービス

※サービスの中のコンテンツ毎に種別が違ったりして掘り下げるとややこしい参考）https://stay-ko.be/aws/solutionarchitect-pro-aws-global-vs-resion-vs-az-resources

章末問題
- ELBはAZサービスでありリージョンをまたいで負荷分散できない！
- 複数のAZにEC2を配置して、ELBで負荷分散するのが鉄則

第3章責任分担セキュリティモデルとAWSにおける認証（IAM）

責任分担セキュリティモデル

責任分担セキュリティモデル
- 利用者とAWSが協力してセキュリティを高める考え方
サービス種別
- インフラストラクチャサービス
  - ハードウェア部分までAWSが管理
  - EC2など
- コンテナサービス
  - ハードウェア部分からミドルウェア部分までAWSが管理
  - RDSなど
- アブストラクトサービス
  - ハードウェア部分からソフトウェア部分までAWSが管理
  - S3やDynamoDB
試験のポイント！
- インフラストラクチャサービス、コンテナサービス、アブストラクトサービスの各サービスについて、利用者の責任範囲を明確にする

AWSにおける認証とアクセス制御

試験のポイント！
- 日常の操作にはルートアカウントを使用せずに、IAMユーザを使用する
試験のポイント！
- 各IAMグループ、IAMユーザには、最小権限のアクセス権を与える。
- IAMポリシーは最も厳しいポリシー（拒否）が優先される。
  - アクセス許可と拒否が相反する場合、拒否が優先
試験のポイント！
- EC2インスタンス上で実行されるプログラムの認証にはIAMロールを割り当てる
  - IAMロールを使用することでアクセスキーとシークレットアクセスキーがなくてもAWSサービスにアクセスできる
  - キーを使わないアクセスで、キーの流出を防ぐことが狙い

IDフェデレーション

事例
- 要求
  - 自社の従業員に各自の業務レポートを毎月月末にS3にアップロードさせるたい
- 問題
  - S3バケットへのアクセス権を付与したいが、毎月１回だけのために全従業員分のIAMユーザを作成するのは非効率すぎて現実的ではない。
- 解決策
  - AWS Security Token Service（STS）という一時的に認証情報を付与するサービスとIDブローカー（IDプロバイダー）を利用して、自社の認証基盤で認証が通ればS3バケットへのアップロードを一時的に許可することができる

→これを「IDフェデレーション」という！

他にも以下がある
- Security Assertion Markup Language(SAML)を使用したシングルサインオン
- GoogleやFacebookといったウェブIDプロバイダーを使用したシングルサインオン
試験のポイント！
- AWSの使用頻度が低いユーザは、IDフェデレーションで社内の認証基盤とIAMを連携する
章末問題
- 利用者の責任で実施しなければならないセキュリティ対策は？
  - S3上のデータの暗号化
  - EC2インスタンス上のOSのセキュリティパッチの適用
- AWSアカウント/認証情報の推奨される運用は？
  - S3バケットへのアップロードをEC2インスタンスで実行する場合は、S3バケットへのファイルアップロードが許可されたIAMロールをEC2インスタンスに割り当てる

第4章 AWSにおけるネットワーク（VPC）

VPCの機能と設定

VPC（Amazon Virtual Private Cloud）
- 利用者毎にプライベートなネットワーク空間を提供するサービス
１．VPCの作成
２．サブネットの作成
- 重要！
  - サブネットはAZをまたがることはできない。サブネットを選択することはAZを選択することと同じ
３．ゲートウェイの作成
- インターネットゲートウェイ（IGW）をVPCにアタッチ
- オンプレと通信するためのゲートウェイはバーチャルプライベートゲートウェイ（VGW）
４．ルートテーブルの設定
- 重要！
  - インターネットとのアクセスを許可するサブネット：パブリックサブネット
  - インターネットとのアクセスを許可しないサブネット：プライベートサブネット
- パブリックかプライベートはサブネットに適用されているルートテーブルによってきまる
  - パブリック：デフォルトゲートウェイ（送信先：0.0.0.0/0）のターゲットとしてIGWが設定
  - プライベート：上記でない
- VPCの内の通信はルートテーブルでは制御できないので、VPC内のサブネットであれば、通信が可能になっている
  - Webサーバ、DBサーバ、その他のサーバ、でサブネットを分けていても、相互通信可能な状態になっている
５．NATインスタンスの作成
- プライベートサブネット内のパッチ当て等
- NATインスタンスの実態はEC2インスタンス（※注意※最新ではNATゲートウェイというAWSサービスが存在する！）
  - 送信元/送信先チェック：宛先が自身のIPアドレスでなければトラフィックを破棄する設定。EC2インスタンスはデフォルトでON
  - NATインスタンスはこの機能を無効化している
試験のポイント！
- プライベートサブネット内のインスタンスがインターネットにアクセスするための設定を押さえる！

EC2インスタンスのIPアドレス

IPアドレスの種類
- Public IP
- Elastic IP
EC2インスタンスのプライベートIPアドレスとグローバルIPアドレスの紐付けは、VPCの仮想ネットワークで行われているので、EC2インスタンスのOSにログインし、ipconfigコマンドやifconfigコマンドを実行しても、プライベートIPしか確認できない

セキュリティグループとネットワークACL

ファイアウォール機能
- セキュリティグループ
- ネットワークACL

	セキュリティグループ	ネットワークACL
適用単位	EC2やRDS、ELBなどインスタンス毎	サブネット単位
作成可能なルール	許可のみ	許可/拒否
デフォルトルール	インバウンド：すべて拒否/アウトバウンド：すべて許可（ホワイトリスト方式）	インバウンド：すべて許可/アウトバウンド：すべて許可（ブラックリスト方式）
特徴	ステートフル	ステートレス

試験のポイント！
- セキュリティグループとネットワークACLの違いを抑えて、ファイアウォールによるトラブルシューティングに対応できるようにする

VPCピア接続

使い所
- 本番環境と開発環境で異なるVPCを構築したが、２つのVPCを接続して、プライベートIPで通信したい
接続が確立されると、PCXというゲートウェイに相当するものが作成される
ルートテーブルの設定で送信先のターゲットとして、PCXを設定することで、各VPC内のサブネット間でのプライベートIPでの通信が可能になる
ピア接続の制約
- 接続するVPCは同じリージョンに存在する必要がある
- 接続するVPCのプライベートネットワークアドレス空間は重複していない
  - 接続する可能性があるならはじめから分けておく必要性を示唆している
- １対１の接続
  - ここはAWS対策講座でも強調して説明されていた
試験のポイント！
- VPCピア接続の特徴/制約を押さえる
章末問題
- VPC内のすべてのサブネット間の通信はデフォルトのルーティングルールで許可されており、変更や削除はできない
- セキュリティグループはステートフルのため戻りのトラフィックを確認する必要ない
- VPCピア接続にあたってVPCが同一のリージョンに存在する必要がある点
- VPCピア接続は１対１

第5章 AWSにおけるコンピューティング（EC2／AMI／EBS／インスタンスストア）

EC2の初回起動と設定

【作成ステップについて】

Amazon Machine Image(AMI)の選択
インスタンスタイプの選択 3. インスタンスファミリー選択
ネットワーク/IAMロール/ユーザデータなどの設定（インスタンスの詳細設定） 4. ユーザデータ：シェルスクリプト 5. メタデータ：インスタンス自身に関するデータ
ストレージの設定 5. EBS 6. インスタンスストア：追加できるのはEC2インスタンスの初回起動時のみ
タグ付け 6. タグ付けができる。おおよそ、Nameをキーにサーバー名を値に設定したりする
セキュリティグループの設定 7. EC2には少なくとも１つのセキュリティグループを割り当てる必要がある
個々までの設定の確認
キーペアの選択

試験のポイント！
- ユーザデータおよびメタデータの用途と、メタデータで参照できる主要なデータを押さえる

EC2インスタンスのライフサイクル

ステータスチェック
- System Status Checks:インフラストラクチャ（HW、ハイパーバイザ）のチェック
- Instance Status Checks：OSのチェック
EC2のインスタンスがrunningになった時点から料金が発生し、stopped,terminatedになるまで発生

EBSとインスタンスストア

Amazoon EBS(Elastic Block Store)
- AZ内に作成されるネットワーク接続型のブロックストレージ
- 不揮発性
インスタンスストア
- EC2インスタンスの物理ホストの内蔵ストレージで、揮発性（一時的なデータボリューム）
- 揮発性：EC2が停止すると保存されていたデータは削除される
- EC2が停止して起動すると、物理ホストが変わるため、揮発性という特徴がある
重要！
- ブロックストレージにはEBSとインスタンスストアの２種類があり、不揮発性と揮発性という違いがある！
OSがどこにインストールされるかによる違い
- EBS-backedインスタンス
  - EBSにOSがインストールされる
- instance store-backedインスタンス
  - インスタンスストアにインストラクターされる
試験のポイント！
- EBS-backedインスタンスとinstance store-backedインスタンスの特徴を押さえる！

EBSのタイプ

EBSのタイプとして３種類言及しているが、情報として古いので、最新を確認したほうがよい
EBS最適化オプション（Black Beltより最新情報を記載）
- ネットワークのIO帯域とEBSのIO帯域を分け、EBS専用帯域を確保するオプション
試験のポイント！
- EBSボリュームタイプの性能の違いとEBS最適化インスタンス(今はEBS最適化オプション？)の使い所を押さえる

EBSスナップショット

試験のポイント！
- EBSスナップショットの特徴を押さえる！
試験のポイント！
- EBSスナップショットを介したAZ/リージョン間のEBSボリュームの複製の流れを押さえる
- リージョン-a/AZ-a → リージョン-a/S3 にスナップショット取得
- リージョン-a/S3 → リージョン-a/AZ-b にスナップショット復元
- リージョン-a/S3 → リージョン-b/S3 にスナップショットコピー
- リージョン-b/S3 → リージョン-b/AZ-c にスナップショット復元
  - S3間はリージョンをまたいでスナップショットをコピーすることができる点

プレイスメントグループ

初めて聞いた...

試験のポイント！
- プレイスメントグループ内にEC2インスタンスを起動することで、EC2インスタンス間のネットワーク接続を高速化できる

Dedicatedインスタンス

ソフトウェア・ライセンスの、ハードウェア制約を解消するために、EC2インスタンスを起動する物理ホストに、別のEC2インスタンスが起動しないことを保証
Dedicatedホストという、物理ホストをアカウントに割り当てておき、その中にEC2インスタンスを起動していくサービスが利用できるようになった
AWS参考 https://aws.amazon.com/jp/ec2/purchasing-options/dedicated-instances/
章末問題
- ユーザデータについて
- EC2の停止は「EBS-backedインスタンス」しかできない（instance store-backedインスタンスはできない）
- EC2の再起動は揮発性ボリュームデータを失わない
- スナップショット取得の留意事項（アンマウント＋取得後すぐにIO可能）
- EBSボリュームはAZ間コピーもリージョン間コピーもできない、S3にスナップショットを取得して適応する
- プレイスメントグループについて
- Dedicatedインスタンスについて

第6章オブジェクトストレージ（S3／Glacier）

S3バケット／オブジェクトとストレージクラス

S3（Amazon Simple Storage Service）
- スタンダード（標準）クラス
- 低冗長化（Reduced Redundancy Storage;RRS）ストレージクラス
※この本では言及してないが、Black Beltで最新は以下の４種類

ストレージクラス	特徴	耐久性
スタンダード	複数箇所にデータを複製。デフォルトのストレージクラス	99.999999999%(イレブン・ナイン)
STANDARD-IA（標準低頻度アクセスストレージ）	スタンダードに比べ格納コストが安価。いつでもアクセス可能だが、データの読み出し容量に対して課金。IA（Infrequent Access）	99.999999999%(イレブン・ナイン)
Glacier（アーカイブ）	最も低コストだが、データの取り出しにコストと時間を要する。ライフサイクルマネジメントにて指定する	99.999999999%(イレブン・ナイン)
低冗長化ストレージ（RRS）	RRSはReduced Redundancy Storageの略。Glacierから取り出したデータの置き場所として利用	99.99%

試験のポイント！
- S3のストレージクラスには、失われることが許されないデータを格納する用途に適したスタンダードクラスと、失われても再作成可能なデータを格納する用途に適した低冗長化クラスがある！

S3の整合性

S3はオンラインで頻繁に更新されるデータの格納先には向かない

格納されている静的データを何度も読み取るような用途に向いている

新規オブジェクトの追加は「完了」と表示されれば、画面上、lsコマンド上で確認できる

更新、削除は「完了」と表示されても、結果整合性をとるために、画面上、lsコマンド上で前のオブジェクトが表示されたり、削除できていなかったりする

試験のポイント！
- S3の各操作とデータ整合性について押さえ、整合性を考慮したS3の利用用途を押さえる！

S3のアクセス制限とセキュリティ

アクセス管理の方法
- アクセスコントロールリスト（ACL）
- バケットポリシー
- IAM(ユーザ)ポリシー
その他
- 署名（期限）付きURL
  - アクセス許可設定をしていない特定のオブジェクトを指定した期間に限定して公開
  - 用途）商品購入後、期間限定でURLに署名をつけて購入者に渡してダウンロードしてもらう際などに用いられる

オブエジェクトの暗号化とアクセスログ

試験のポイント！
- S3の暗号化やアクセスログの取得はデフォルトではなく、ユーザの責任の元に実施する！

S3の静的Webサイトホスティング機能

Webサイトホスティング機能
- エンドポイント
  - バケット名.s3-website-リージョン名.amazonaws.com
準備
- Route53やDNSドメインサービスで名前解決する必要がある

S3のバージョニング機能

バージョニング機能
- S3バケット単位で有効/無効にできる
- 誤って上書き、削除した場合でも、操作前のオブジェクトを復元できる
- 有効にした場合、キーの他にバージョンIDが付与される
試験のポイント！
- S3のバージョニング機能を利用すれば、誤操作などにより上書きや削除をしてしまっても、元のデータを復元できる！

S3のライフサイクル機能とGlacierへのアーカイブ

普段アクセスしないものは、より安く運用できる「Glacier」へ移動
格納方法
- ライフサイクル機能
  - 指定日数が経過したら、Glacierに格納、削除といった操作ができる機能
- SDKを利用して直接格納
試験のポイント！
- Glacierは参照する頻度の少ないデータを長期間保管するのに適している
章末問題 +

第7章データベース（RDS／ElastiCache／DynamoDB）

マネージド・サービス

マネージド・サービスとは
- 利用者が自身でOSやミドルウェア/ソフトウェアをインストールすることなくサービスを利用でき、サービスの可用性や拡張性、バックアップやパッチ適用といった管理作業の多くをAWSが管理してくれるサービスのこと
RDSはマネージド・サービスで、他にもELBやSQSなどが存在する

マネージド型データベースサービス

AWSが提供するマネージド型データベースサービス
- Amazon RDS：リレーショナルデータベースサービス
- Amazon DynamoDB：NoSQLデータベースサービス
- Amazon ElastiCache：インメモリキャッシュサービス
- Amazon Redshift：データウェアハウスサービス

※最新では、Amazon Neptuneというサービスも存在する（フルマネージドのグラフデータベースサービス）

RDS

種類
- Amazon Aurora
  - MySQLとPostgreSQLとの互換性のあるエンジン
- MySQL
- MariaDB
  - MySQLから分岐（フォーク）して作成された
- PostgreSQL
- Oracle
- Microsoft SQL Server
特徴
- １）マルチAZ配置
  - 複数のAZにRDSインスタンスを配置して可用性を高める機能（マスタ-スレーブ構成）
  - MySQL、MariaDB、PostgreSQL、Oracleでは同期物理レプリケーション、
  - SQL Server では同期論理レプリケーションを使用してマスタからスレーブにデータ同期
  - スレーブデータは完全にスタンバイ状態で、読み取りもできないので、読み取り性能を上げたい場合は、リードレプリカや、ElastiCacheを利用すること
  - マスタに障害や停止が発生した場合、フェイルオーバーが開始される。フェイルオーバーの過程で、RDSインスタンスのCNAMEがマスタースレーブに付け替えられます
  - AuroraのマルチAZ配置は、マスタ-スレーブ構成ではなく、３つのAZにまたがるクラスターボリュームが作成され、各AZにクラスターデータのコピーが格納される
- 試験のポイント！
  - RDSのマルチAZ配置の特徴、フェイルオーバー時の挙動を押さえる！
- ２）自動バックアップ機能
  - RDS標準機能で、１日１回自動的にデータのバックアップを取得する
  - 取得中は多少の読み書き遅延が発生する可能性があるので、利用者は、バックアップウィンドウと呼ばれる設定項目でバックアップが取得される時間帯を選択する
  - バックアップの保持期間はデフォルトで７日間。０～３５日間の間で指定する（０を選択するとバックアップが取得されない）
  - RDSはトランザクションログも自動的に取得しており、１日１回の自動バックアップとトランザクションログを利用して、設定している保存期間の特定時点のデータを持つRDSインスタンスを復元可能
  - トランザクションログは５分に１回永続ボリュームに書き込まれている
- 試験のポイント！
  - RDSの自動バックアップ機能のメリットを押さえる！
- ３）パッチ適用
  - 自動パッチ適用機能を有効にしておくと、メンテナンスウィンドウと呼ばれる設定項目で指定した曜日/時間帯にパッチが適用される。
  - パッチ適用時に数分のダウンタイムが生じることがあるが、RDSをマルチAZ配置にすることで、先にスタンバイにパッチがてきようされ、フェイルオーバーした後に旧マスタ-でパッチが適用されるため、その影響を軽減できる
  - 利用者がパッチ適用を有効/無効に設定できるが、重要なセキュリティ脆弱性が発生した場合は自動的に適用されることがある
- ４）ストレージ
  - RDSのストレージも、EBSのストレージと同様に、種類がある
  - General Purpose SSD
  - Provisioned IOPS SSD
  - Magnetic（Black Beltに「下位互換のためサポート」と記載あり）
  - （具体的な数値についてはBlack Beltを見たほうがよいため割愛）

DynamoDB

マネージド型のNoSQLデータベースサービス
特徴
- ストレージ容量が必要に応じて自動的に拡張
- 秒間あたりのI/O性能を指定できる
- ストレージはSSDのみで安定したI/O性能を提供
- データを３つのデータセンタに複製することで高可用性と高い耐久性を提供
- 読み込み整合性の強弱を指定することで、性能と整合性のバランスを選択
拡張性
冗長性
整合性（結果整合性）
ユースケース
- セッションデータ
- ゲームの点数
- 買い物リスト（買い物かご）
- センサーデータ

１つの項目の実データは最大400KBまで

１つ１つの項目に対応する実データサイズが大きくなる場合は、実データをS3に保管して、DynamoDBにはS3の格納先URLや格納日付といったメタデータを格納するということもできる

試験のポイント！
- DynamoDBのメリットとユースケースを押さえる！
DynamoDBはリージョンサービス
- プライベートサブネットからのアクセスはNATインスタンスを経由する
試験のポイント！
- DynamoDBのアクセス制御はIAMで行い、EC2インスタンス上で実行されるプログラムの認証には、IAMロールを活用する

ElastiCache

種類
- Memcached
  - Key-Value Store形式
  - キャッシュクラスタ構成
- Redis
  - Key-Value Store形式
  - マスタースレーブ構成
ElastiCacheはAZサービスでサブネットグループに配置
アクセス制御はセキュリティグループとサブネットのルーティングルール
試験のポイント！
- ElastiCacheのメリット/ユースケースを押さえる！
章末問題 +

第8章 AWSにおける監視と通知（CloudWatch／SNS）

CloudWatchによるモニタリング

CloudWatchとは
- モニタリングサービス
メトリックス（監視項目）
- EC2インスタンスのCPU利用料
- EBSのディスクI/O
- S33の格納オブジェクト総数
- RDSインスタンスのCPU利用率
- RDSインスタンスのメモリ空き容量
- RDSインスタンスのストレージ空き容量
- DynamoDBに書き込まれたユニット数
- など。。。
CloudWatchは各種AWSリソースから送られてきたモニタリングデータを保存し、メトリックス毎にグラフ化して表示することができる
保持期間は２週間、それ以降のデータは破棄されてしまうため、月次のモニタリングレポート必要な場合は、保持期間内にCloudWatchからモニタリングデータをダウンロードしておく必要があります。

EC2のモニタリング

CloudWatchはあくまで、AWSリソースから送られてきたデータを保存/可視化するサービスであるため、CloudWatchにデータを送る仕組み/機能をEC2インスタンスや、RDSインスタンスなどのAWSリソース側で用意する必要がある

RDSはマネージドサービスであり、デフォルトで様様なモニタリングデータを収集して、CloudWatchに送信するエージェントがインスタンスに導入されている

EC2はマネージドサービスではないため、デフォルトではハイパーバイザが収集できるモニタリングデータのみを収集してCloudWatchに送っている

標準（デフォルト）メトリックス：ハイパーバイザが取得してCloudWatchに送信するメトリックス
- CPUクレジット利用数（CPUCreditUsage）
- CPUクレジット累積数（CPUCreditBalance）
- CPU利用率（CPUUtilization）
- １秒あたりのDisk読み込み回数（DiskReadOps）
- １秒あたりのDisk書き込み回数（DiskWriteOps）
- インスタンスストレージの読み取りバイト数（DiskReadBytes）
- インスタンスストレージの書き込みバイト数（DiskWriteBytes）
- 受信したバイト数（NetworkIn）
- 送信したバイト数（NetworkOut）
- OS/インフラストラクチャステータスチェックの成功(0)/失敗(1)（StatusCheckFailed）
カスタムメトリックス：OSにインストールしたエージェントが取得して、CloudWatchに送信するメトリックス

参考）よくある質問「カスタムメトリックスとは」

https://aws.amazon.com/jp/cloudwatch/faqs/

カスタムメトリクスとは、Amazon CloudWatch でモニタリングするためにお客様自身が用意するメトリクスのことです。

カスタムメトリクスを使用してモニタリングできるものの例としては、ウェブページのロードに要する時間、リクエストエラー率、インスタンス上のプロセスやスレッドの数、アプリケーションで実行された作業の量などがあります。

カスタムメトリクスを使用するには、PutMetricData API を使用します。Windows および Linux 向けのモニタリングスクリプトのサンプル、CloudWatch プラグイン集が用意されているほか、AWS パ>ートナーからも多数のアプリケーションやツールが提供されています。

基本モニタリング
- ３種類のステータスチェックは１分間隔、その他は５分間隔
詳細モニタリング
- 標準メトリックスをすべて１分間隔（ただし、追加料金が必要）
試験のポイント！
- EC2の標準メトリックスや基本/詳細モニタリングを押さえる！

アラームとアクション

CloudWatchの各メトリックスに対して、アラームを設定することができる
- 閾値を超えた時に所定のアクションを呼び出す
アクション例
- メールなどの通知（Simple Notification Service）
- Auto Scalingポリシー（EC2インスタンス数の増減）
- EC2アクション（停止/削除/再起動/復旧）
アラームの３つの状態
- OK
- アラーム（ALARM）
- 不足（INSUFFICIENT_DATA）
設定例
- EC2インスタンスの１分間のCPU利用率の平均が閾値の７０％を３期連続（３分間連続）で上回っている場合に、EC2インスタンスを２台増やすAutoScalingポリシーのアクションを呼び出す
- など。。。
重要！
- CloudWatchのアラームとアクションについて、特徴と代表的な利用の流れを押さえる

SNS

SNS(Amazon Simple Notification Service)
- ユーザやアプリケーションにメッセージを送信できる
- CloudWatchのアラームアクションとしてメッセージを通知することもできる
押さえるべき３つの用語
- メッセージ
  - 通知するメッセージ
- サブスクライバ
  - 受信者を指し、サポートされているプロトコルは次の通り
    - Eメール
    - SMS
    - HTTP/HTTPS
    - SQS（Simple Queue Service）
    - Lambda（サーバ無しのプログラムコード実行サービス）
- トピック
  - 単一/複数のサブスクライバをまとめたもの
利用例
- １．SampleTopicというシステムのアラートが通知されるトピックを作成し、運用管理者のEメールアドレス/メーリングリストをサブスクライバとしてSampleTopicに登録
- ２．CloudWatchでシステムのEC2インスタンスをモニタリングし、１分間の平均CPU利用率が８０％を１回超えたというアラームが発生すると、SampleTopicにメッセージを通知するアクションを設定
- ３．該当するEC2インスタンスのCPU利用率が８０％を超えてあアラームが発生すると、「CPU利用率が８０％を超えてアラームの状態がOKからALARMに遷移した」というメッセージをSampleTopicに送信
- ４．SNSはSampleTopicに登録されている運用管理者のEメールアドレス/メーリングリスト（サブスクライバ）にメッセージを送信
章末問題
- WEbサーバとして利用しているEC2インスタンスの標準メトリックスとして正しいものは？
  - [誤]メモリ使用率
  - [誤]Webページへのロード時間
  - [誤]Webサーバのプロセス/スレッド数
  - [正]Network I/O

※デフォルトは、ハイパーバイザが取得できる値のみ。メモリの使用率は、OSで収集する必要があります。

第9章 AWSにおける拡張性と分散／並列処理（ELB／Auto Scaling／SQS／SWF）

密結合と疎結合

通常のオンプレでWeb-AP-DBサーバーの3Tier構成を組むと、サーバー間が密結合担ってしまう。
AWSではサーバ間を疎結合にするために、負荷分散装置を用いて、WEBサーバ、APサーバのインスタンスが入れ替わっても問題ないように３Tier構成を組む
そのためのサービスをELB（Elastic Load Balancing）という（マネージドサービス）
重要！
- コンポーネント間を疎結合にして伸縮自在性を実装し、AWSのメリットを活かすシステム構成にする！

ELB

機能
- 複数のAZにまたがる負荷分散
- EC2インスタンスのヘルスチェック
- ELB自体の自動スケーリング
- SSLのオフロード
- Connection Draining
- アクセスログ記録
- スティッキーセクション
(1)複数のAZにまたがる負荷分散
(2)EC2インスタンスのヘルスチェック
- 補足）EC2インスタンスを再起動した際、ELBのヘルスチェック間隔によってインスタンス異常と判定され、そのインスタンスのトラフィックが行われなくなり、再起動後もトラフィックの再開をしなかったが、2015/12にEC2インスタンスのELBへの自動再登録が可能になった
(3)ELB自体の自動スケーリング
- ELBは、受信するトラフィックの流量に合わせて自動的にその実態を増減させる
- ELBの実態はサブネットの中に作成される
- 割り当てられるIPアドレスはサブネットの中から採番されるが、同時にDNS名が付与され、DNS名で通信される
- 実態はサブネットの中にあるが、AZ間をまたいで通信されるため、AZの間にELBのアイコンを書くことがおおい
(4)SSLのオフロード
- SSL証明書はEC2インスタンスに配置するのではなく、ELBに配置して一元管理する
(5)Connection Draining
- ELBが配下のEC2インスタンスの登録解除をするときに、新規のリクエストについてはそのインスタンスへのトラフィックの送信を停止し、登録解除前にそのインスタンスで処理中だったリクエストについては完了まで待つようにする機能です。
(6)アクセスログ記録
- ELBにはアクセスログ収集機能があり、S3バケットに保存することで、アクセスログを一元管理できる
(7)スティッキーセクション
- ELBには、スティッキーセクションという、システムにアクセスしているクライアントを特定のEC2インスタンスに紐付けできる機能がある。
- 例）ユーザ認証が必要な会員WebサイトをEC2インスタンス上に構築し、その前段にELBを配置するとする。クラアイアンとは会員Webサイトにアクセスした際に、ELBに割り振られたEC2インスタンスのWebサーバ上でユーザ認証手続きを行います。ユーザ認証に成功すると、Webサーバ側でセッション情報が保持されるため、クライアントが会員Webサイト内で別ページを閲覧して、再度Webサーバに要求が送られても、Webサーバはセッション情報を参照することで、認証済みであることが確認でき、改めてユーザ認証を行わずにすむ
- →ただし、この方法は「伸縮自在性を実装」に影響を及ぼすので、注意が必要。
- 「各コンポーネントが特定の状態を持たいない（ステートレス）」であることが重要。スティッキーセクションの代わりに、DynamoDBや、ElastiCacheを利用するほうが懸命
試験のポイント！
- ELBの機能/特徴を理解して、ELBによるシステムの可用性向上メリットを押さえる！

分散／並列処理

ある１台のEC2インスタンスでは性能が不足する場合の対処方法２つ

(1) スケールアップ：インスタンスタイプを変更し、より高スペックに
(2) スケールアウト：EC2インスタンスの台数を増やして分散処理させる
スケールアップの問題点
- EC2インスタンスを一旦停止する必要があり、１台のインスタンスの場合は業務を停止する必要がある
- 最終的にはスペックの限界がある
- １台のインスタンスでは「故障に備えた設計で障害を回避」を実践できない構成になる
- システム負荷が減少した際に、スケールアップしたインスタンスタイプではオーバースペックになる。スケールダウンするためには再度EC2インスタンスを一旦停止する必要がある
試験のポイント！
- 分散/並列処理できる処理は並列化して業務を効率化する！

Auto Scaling

Auto Scaling
- EC2のインスタンスでAuto Scalingグループというグループを構成し、設定に従って自動的にEC2インスタンスの台数を増減させる
- 負荷が現象した際は、スケールインすることでコストメリットを図れる
- Auto Scalingの利用料金は無料で、起動したEC2インスタンスの利用料金のみ費用が発生する
ユースケース
- 負荷に基づいた利用
- スケジュールに基づいた利用
- 正常なEC2インスタンスの台数を維持するための利用
Auto Scalingのコンポーネント
- 起動設定（Launch Configration）
  - どんなEC2インスタンスを起動するのか？という設定
    - AMI
    - インスタンスタイプ
    - IAMロール
    - CloudWatch詳細モニタリング
    - ユーザデータ
    - IPアドレス
    - ストレージ（EBS、インスタンスストア）
    - セキュリティグループ
    - キーペア
    - など、、
- Auto Scaling Group（Auto Scalingグループとは異なり、設定項目）
  - どこに、どんな規模のグループ？という設定です
  - EC2インスタンスが起動するサブネットや特定のELB配下など、どこに？の設定
  - 最小/最大台数などグループの規模を定める設定
    - スタートのグループサイズ（EC2インスタンス数）
    - サブネット（AZ）
    - ELB（ヘルスチェック設定も含む）
    - 最小/最大グループサイズ（EC2インスタンス数）
    - など、、
- Auto Scaling ポリシー
  - いつ、何台増減させるか？という設定
  - 例えば、負荷に基づく設定であれば、CPU利用率のCloudWatchアラームを設定しておき、OKからアラームに状態遷移した際に、アクションとしてAuto Scalingポリシーを呼び出す
    - アラームXが発生した際
    - N台追加/削除
    - 猶予時間（インスタンスの増減後に、次の増減アクションが発生するまでのクールダウン時間）
補足
- 2015/7にAuto Scalingポリシーに「Step Scaliing」というタイプが追加され、それまでのポリシーは「Simple Scaling」というタイプになった
- Step Scaling
  - 複数ステップでの増減が可能。まずこうなったら１台増やす、さらに何秒後までに、何％だったら、もう１台増やすのような設定
- Simple Scaling
  - 条件が１つの設定
試験のポイント！
- Auto Scalingにおける３つの設定項目を押さえる！
Auto Scalingの２つの特徴
- 正常なEC2インスタンスを希望する台数（Desired Capacity）維持するため、インスタンスのヘルスチェックをかけている
- Auto Scalingグループが複数のAZにまたがるとき、AZ間でEC2インスタンス数を均等にする
Auto Scalingのシュミレーションが記載されている項目がある～
スケールアウト時のインスタンス削除ルール
- １．起動している台数が最も多いAZのインスタンス（大原則）
- ２．起動設定が最も古いインスタンス
- ３．次の課金タイミングが最も近いインスタンス
試験のポイント！
- Auto Scalingにおける大原則を押さえ、EC2インスタンスの増減がどの様に発生するかを押さえる！

SQS (Amazon Simple Queue Service)

ELBと並んでコンポーネントを疎結合にする要素で、AWSで分散/並列処理を行う上で重要なサービス
特徴
- (1)Pull型（ポーリングされる必要がある）
  - アプリケーションにポーリングされる必要がある
- (2)順序性の保証はしない（FirstInFirstOutが保証されない）
  - 順序性は保たれない
- (3)最低１回配信保証
  - メッセージはあるアプリケーションによって取得されてもキューから削除されることはなく、アプリケーションがバッチ処理の最後で明示的に削除する必要がある
  - メッセージを取得したアプリケーションがバッチ処理の最中で停止しても、他のノード上のアプリケーションが再度同じメッセージを取得して処理できる
- (4)可視性タイムアウト
  - あるメッセージを取得したアプリケーションがバッチ処理を実行中に、他のノード上のアプリケーションがキューに残っている同じメッセージを取得して島わあないように、可視性タイムアウトという機能が備わっている。デフォルトで３０秒、利用者による設定も可能
- (5)メッセージサイズは最大256KB
  - サイズが大きい場合はS3に保存して、SQSにはデータの格納先の情報を格納する
SQSはリージョンサービスで、プライベートサブネットからキューのポーリングやメッセージの格納といった操作を行うにはNATインスタンスが必要
EC2上でSQSへのアクセスがあるアプリケーションを動作させる場合は、IAMポリシーが設定されたIAMロールをEC2インスタンスにアタッチすることで安全に利用できる
試験のポイント！
- 分散/並列処理におけるSQSのメリット/特徴を理解し、SQSのユースケースを押さえる！

SWF（Amazon Simple Workflow）

マネージド型のタスクコーディネータ
重複が許されない、厳密に１回限りで順序性が求められる処理のコーディネータとしての利用に適している
構成要素
- ワークフロースターター
  - ワークフローを開始する
- ディサイダー
  - ワークフロー中の各処理を調整する
- アクティビティ・ワーカー
  - ワークフロー中の各処理を実行する
試験のポイント！
- 分散/並列処理における厳密に１回限りで順序性が求められる処理というSWFのユースケースを押さえる！
章末問題
- ELBのIPアドレスを直接指定してはいけない
- 予測できない負荷にたいするテストに時間をかけるのではなく、負荷ベースのAuto Scalingを利用することで、負荷に対応する
- １台のインスタンスを４０時間稼働させる利用料金と４０台のインスタンスを１時間可動させる利用料金は同じなので、可能な限り並列処理を実施する
- 一時的にAuto Scaling設定がされているEC2インスタンスの台数を増やしたいときに変更するのは？
  - Auto Scaling Group設定
- 動画トランスコード処理はSQSを利用するべき

第10章 DNSとコンテンツ配信（Route 53／CloudFront）

エッジロケーション

AWSにはリージョンとAZ以外に、エッジロケーションというデータセンタが世界に５０箇所以上あります。
エッジロケーションには、EC2やS3、RDSといったサービスでなく、Amazon Route 53のDNSサーバやAmazon Cloud Frontのキャッシュサーバが動作している
エッジロケーションは数が多いので、AWSインフラストラクチャページで確認する
重要！
- 世界５０箇所以上のエッジロケーションを利用して、DNSサービスやコンテンツ配信（CDN）サービスが提供されている！

Route 53

マネージド型のDNSサービス
DNSサービスが53番ポートを利用することからその名前がついている
Route53を使用してゾーン/ドメイン情報を登録すると、４箇所のエッジロケーションのDNSサーバにゾーン/ドメイン情報が格納される
Route53が管理しているドメインに対してクエリが発生すれば、その４箇所のうちエンドユーザに最も近いDNSサーバが応答する
４箇所のDNSサーバが同時に停止する可能性は限りなく低いため、Route53のSLAは１００％として提供されている
利用料金は、管理しているホストゾーン（従来のDNSゾーンファイル）の数とクエリ回数などの従量課金制となっており、低額から利用可能
Route53 レコードタイプ
- A
- AAAA(IPv6)
- CNAME
- MX
- NS
- PTR
- SOA（Ｓtart Ｏf Ａuthority）
- SPF
- SRV
- TXT
- ALIAS(エイリアス：AWS独自レコード)
Zone Apex（ゾーンエイペックス）：ゾーンの頂点のこと
試験のポイント！
- Route53の独自レコードであるALIASレコードは、CNAMEレコードでは対応できないZone Apexの名前解決をサポートする！
レコードに行える設定
- 荷重ラウンドロビン
- レイテンシーベースルーティング
- 位置情報ルーティング
- ヘルスチェックとフェイルオーバー
試験のポイント！
- Route53の各種機能による、リージョンレベルのユースケースを押さえる！

CloudFront

CloudFrontはCDNサービス（Contents Delivery Network）
全国５０箇所のエッジロケーションの中の地理的に近い場所からコンテンツをダウンロード
アクセス回数とデータ転送量による従量課金制、長期契約や最低利用料金はない
CloudFrontではエッジロケーションにキャッシュさせる時間を設定できる
- 静的なコンテンツについてはキャッシュ時間を長く
- 動的なコンテンツについてはキャッシュ時間を短く　といった具合
サービス提供側のメリット
- 大量のアクセスが各地のエッジロケーションに分散され、オリジンサーバの負荷が大幅に減少
- オリジンサーバのリソース削減
- S3バケットに直接アクセスされるよりもAWSの利用料金を抑えることができる
試験のポイント！
- CloudFrontの特徴/メリットを理解し、ユースケースを押さえる！
CloudFrontを利用したコンテンツ配信においても、CloudFrontのSSL証明書、あるいは利用者独自のSSL証明書を利用した暗号化通信が可能
CloudFront経由でエンドユーザに、S3へアクセスさせる際は、バケットポリシーでCloudFrontからのアクセスだけ許可する設定（OAI:Original Accesss Identity）を作成し、OAIからのアクセスだけを許可
試験のポイント！
- CloudFrontを利用したコンテンツ配信におけるセキュリティ/アクセス制限を押さえる
章末問題 +

第11章 AWSサービスのプロビジョニング／デプロイ／構成管理（CloudFormation／Elastic Beanstalk／OpsWorks）

CloudFormation

CloudFormation
- プロビジョニングサービス。利用者が用意した定義にしたがってAWSリソースを自動的にプロビジョニングする
- 自動化により、AWSリソースの構築/管理を効率化できる
- インフラストラクチャをコード化して、インフラのバージョン管理が可能
- 利用料は無料で、プロビジョニングされたリソースの利用料金のみ発生
押さえておく用語
- テンプレート
  - プロビジョニングするリソースを規定するJSON形式のテキストファイル
- スタック
  - CloudFormationによってプロビジョニングされるリソースの集合/管理単位
試験のポイント！
- CloudFormationを利用したインフラストラクチャのバージョン管理イメージを押さえる！
テンプレートの作成について
- AWSから提供されるサンプルテンプレートを元に利用者が編集したり、CloudFormerというツールを利用して作成することもできる
CloudFormer
- 利用者のアカウントで現在作成されているAWSリソースを元にテンプレートを作成することができるツール
JSONの書き方について～
試験のポイント！
- CloudFormationで設定できる項目や、エラー発生時の動きなどを押さえる！

Elastic Beanstalk/ OpsWorks

Amazon Elastic Beanstalk
- アプリケーションのデプロイツール
- アプリケーションのバージョニング管理ができ、既存の環境を以前のバージョンに戻すことができる
- CloudFormation同様、プロビジョニングされたリソースにたいする課金
OpsWorks
- AWS上のアプリケーションサーバの構成管理ツール
- ELBやEC2インスタンスを作成し、その後にChefのレシピを実行してソフトウェアのインストールや設定などを自動化できる
まとめると
- CloudFormation
  - VPC以下の構成をプロビジョニング
  - Elastic BeanstalkとOpsWorksを呼び出して一気に設定できる
- Elastic Beanstalk
  - アプリケーションのデプロイ関連（アプリケーションのバージョン管理）
- OpsWorks
  - アプリの設定（chefのレシピを実行してソフトウェアのインストールや設定）
章末問題 +

第12章 EC2の料金モデル（オンデマンドインスタンス／リザーブドインスタンス／スポットインスタンス）

オンデマンドインスタンス

デフォルトの課金形式
インスタンスが起動しているときに１時間単位で支払いが発生
料金は次の３要素で決まる
- リージョン
- インスタンスタイプ
- OS(Amazon Linux/RHEL/Windows Serverなど)
使用用途
- 開発/検証環境のサーバ
- Auto Scalingグループで増減するサーバ
- １年を通して常時稼働することが求められていないサーバ

リザーブドインスタンス

１年あるいは３年契約を結ぶことにより、オンデマンドインスタンスより割安にEC2インスタンスやRDSインスタンス、ElastiCacheノードやRedshiftノードを利用できる
RI(Reserved Instance)と略した名称で呼ばれることもある
DynamoDBやCloudFrontにも同様の割引方式がありますが、こちらはキャパシティを事前に予約するリザーブドキャパシティといいます
リザーブドインスタンスはEC2インスタンスの起動/停止にかかわらず、利用料金が発生
支払い方式
- 前払いなし
- 一部前払い
- 全額前払い
使用用途
- いつでも確実にインスタンスを立ち上げたい
- 長期間継続的に利用することが決まっている

スポットインスタンス

入札形式のEC2インスタンスの利用/支払い方式で、需要と供給のバランスによって決まるスポット価格（市場価格）を入札価格が上回ると、EC2インスタンスが利用できる
スポット価格の設定項目
- アベイラビリティゾーン（AZ）
- インスタンスタイプ
- OS(Amazon Linux/SUSE Linux/ Windows Serverなど)
入札価格をスポット価格が上回った時、インスタンスはターミネートされる
計算クラスタノードの一部や、Auto Scalingの増加部分のインスタンスなど、突然削除されても問題ないところで利用します。
スポットインスタンス上のデータについては、頻繁にチェックポイントを設けて、S3やEBS、DynamoDBといった不揮発性のストレージに書き出す必要があります。
EC2インスタンスをターミネートする２分前に通知があるため、その通知をトリガーに外部ストレージに書き出す
重要！
- スポットインスタンスは、単独で使用するのではなく、オンデマンドやリザーブドインスタンスと組み合わせて利用する！
試験のポイント！
- 業務（提供サービス）の継続とEC2のコスト最適化の業法を考慮して、オンデマンド/リザーブド/スポットインスタンスそれぞれのユースケースを押さえる！

HTML5プロフェッショナル認定試験レベル１問題集

Fri, 01 Jun 2018 00:00:00 GMT

LPIC Level1 教科書

目次
- 1章　Webの基礎知識
- 2章　CSS
- 3章　要素
- 4章　レスポンシブWebデザイン
- 5章　APIの基礎知識
- 6章　模擬試験

学んだこと

教科書で学んだことの復習
問題傾向の整理

手に取った理由

HTML5 Level1資格取得のため

LPIC Level1 教科書

Sun, 01 Apr 2018 00:00:00 GMT

LPIC Level1 教科書

目次
- 序章　LPI認定試験の概要
- 第1章　システムアーキテクチャ
- 第2章　Linuxのインストールとパッケージ管理
- 第3章　GNU＆UNIXコマンド
- 第4章　ファイルとプロセスの管理
- 第5章　デバイスとLinuxファイルシステム
- 第6章　101模擬試験
- 第7章　シェル、スクリプト、データ管理
- 第8章　ユーザーインターフェイスとデスクトップ
- 第9章　システム管理（1）
- 第10章　システム管理（2）
- 第11章　ネットワークの基礎
- 第12章　セキュリティ
- 第13章　102模擬試験

学んだこと

LinuxOSのシステムアーキテクチャ
パッケージ管理システムについて
OSの種類(Redhat系/Debian系)
シェルスクリプト（一般的なコマンドのオプション含めた使い方）
シェル起動時の環境設定ファイル

手に取った理由

LinuxOSについて体系的な知識を身に着けるため

LPIC Level1 問題集

Sun, 01 Apr 2018 00:00:00 GMT

LPIC Level1 教科書

目次
第1部　101試験
- 1章　基本コマンドとファイルの操作
  - 2章　正規表現とviエディタ
  - 3章　プロセス管理
  - 4章　ファイルシステムの管理
  - 5章　マウントとクォータ機能
  - 6章　ファイルの管理
  - 7章　ソフトウェア管理
  - 8章　システムアーキテクチャ
  - 模擬試験
- 第2部　102試験
  - 1章　シェル、スクリプト、SQLの基礎
  - 2章　X Windows System
  - 3章　ユーザアカウントの管理
  - 4章　システムサービスの管理
  - 5章　ネットワークの基礎
  - 6章　セキュリティ
  - 模擬試験

学んだこと

教科書で得た知識の再確認
問題の出題傾向の把握

手に取った理由

LPIC Level1資格取得のため

データベーススペシャリスト 2017年版 EXAM PRESS

Mon, 01 Jan 2018 00:00:00 GMT

データベーススペシャリスト EXAM PRESS

目次
- 序章　試験対策（学習方法と解答テクニック）
- 第1章　概念データモデル
- 第2章　関係スキーマ
- 第3章　SQL
- 第4章　重要キーワード

学んだこと

DBスペシャリストに出題される問題傾向
今までの業務経験等である程度理解はしていたが、得られるものがあった

手に取った理由

DB関連知識の深堀のため

Photoshopレタッチ・加工

Fri, 01 Sep 2017 00:00:00 GMT

Photoshopレタッチ・加工

学んだこと

Photoshopの加工テクニックを抜粋して拾い読み

手に取った理由

趣味で一眼レフにはまっており、row画像を加工・人の目を引く写真の作成方法を学習したかった

詳解 Amache Spark

Thu, 01 Jun 2017 00:00:00 GMT

詳解 Amache Spark

学んだこと

Sparkとは
Spark環境構築
Scalaを使用したハンズオン
- RDD操作
- Sparkを取り巻くエコシステムについて理解
※もう一回読みたい書籍

手に取った理由

ApacheSparkを使ってデータ予測ができる成果物を作成する機会があり、実際に開発/使用することになったが、前提知識がなかったため購入

応用情報技術者試験教科書

Thu, 01 Jun 2017 00:00:00 GMT

応用情報技術者試験教科書

学んだこと

基本情報の派生形知識の習得

手に取った理由

応用情報技術者資格取得のため

応用情報技術者試験問題集

Thu, 01 Jun 2017 00:00:00 GMT

応用情報技術者試験教科書

学んだこと

基本情報の派生形知識の習得

手に取った理由

応用情報技術者資格取得のため

データサイエンティスト養成読本

Thu, 01 Jun 2017 00:00:00 GMT

データサイエンティスト養成読本

学んだこと

データサイエンティストとは
Pythonの環境構築/使用
R言語の環境構築/使用
※もう一回読みたい書籍

手に取った理由

ApacheSparkを使ったデータ分析をする機会があり、データ分析関連知識の習得のため

SEの基本

Sat, 01 Apr 2017 00:00:00 GMT

SEの基本

目次
- 0章　SEって、いったい何をする人？
- 1章　SEには、どんなテクニカルスキルが必要か
- 2章　ソフトウェアエンジニアリングを意識したスキルを形成する
- 3章　プロジェクトに必要なリーダーシップとチームワーク
- 4章　プロジェクトを成功に導くマネジメントスキル
- 5章　これだけはマスターしたいヒューマン系スキル
- 6章　SEとしての自覚と心構え

学んだこと

テクニカルな情報というより、概念的、心構え的な知識を習得することが出来た

手に取った理由

２年間SEとして動いてきて、そもそもSEとしての基本とはなにか、振り返り、答え合わせがしたかったので購入

学習メモ

【読書】SEの基本
1 SE、プログラマーって何？
様々な職種のエンジニアを技術的に統括し、システム開発全体を制御、管理する職種
2 様々なシステム開発に関わる職種
プロジェクトマネージャー
テクニカルリーダー
スタッフ
チームリーダーはプロジェクトマネージャーを指すことが多い
SEがカバーする範囲は広いので求められる期待値は大きい
皆、SEを目指すことになるだろう
3 スキル標準における位置づけを知ろう
ITSS 情報システムの企画から運用 保守に至るまで必要とされる実務能力を明確化、体系化した指標
いろんな使われ方をする。企業が、個人が、教育機関が、行政が、、
対象は下記4種
ITアーキテクト
プロジェクトマネージメント
ITスペシャリスト
アプリケーションスペシャリスト
全てを習得する必要はない。
しかし、最低限必要な技術力やマネジメント能力があることも確か。
最低限必要な「テクニカルスキル」「マネジメントスキル」「ヒューマンスキル」についてみていく
4 SEがする仕事の全体像
SEの仕事は「システムに対する要求をヒアリングする」ところから始まるわけではない
作業
顧客 経営戦略策定
SE 戦略的情報化企画
SE 開発
SE 運用・保守
SEに求められるスキルは
・顧客のビジネス戦略・課題に対するITソリューションを構築するスキル
・さまざまな技術を用いて要件を満たす情報システムを構築するスキル
・プロジェクトをマネジメントするスキル
・上記３つを実行するためのヒューマンスキル
5 SEが活躍する会社
ユーザ企業
SI企業（元請け）・SI企業（下請け企業）
ベンダー企業
それぞれ経験できる領域が異なる。
初めはプログラミングを経験できる環境が良いでしょう。
6SEの最大のミッション
第1章 SEにはどんなテクニカルスキルが必要か
1 工学的手法をもってソフトウエア開発に臨む
場当たりシステム開発からの脱却
◎プロフェッショナルな開発
ソフトウエアの構造について説明がつかなければいけない。
大工でいうと犬小屋ではなく、高層ビルを建てているのです。
◎ソフトウエア工学
ソフトウエア開発を量的、質的に向上させるための学術的分野
企画から運用までを明確な行程にわけて工程ごとに課題を解決する工学的手法によって質を向上
◎SWEBOK
ソフトウエア工学に関する理論、方法論、ツール、ノウハウといった知識体系が整理されIEEEにより制定
安定した品質を提供できるようになろう
2 業務分析がシステム開発のカギ
まず、システム化戦略の策定が必要
アプローチ方法
・トップダウン
ビジョン⇨戦略 ITを武器に戦略を策定
・ボトムアップ
戦略⇨ビジョン 阻害要因を排除するため
BSCを用いる
3 ビジネスモデリング
システム要件を導く論理的手法
ビジネス構造を表現するというもくてきで使用する場合
作成する図をビジネスモデル、ビジネスモデルを作成する過程をビジネスモデリングという
◎ビジネスモデリングで表現するもの
外部ビュー 顧客パートナーに対してどのようなサービスを提供しているか
内部ビュー 製品 社員などの関係
◎ビジネスモデリングの目的
重要なのはなんのために実施するのか
目的を持って実施することになる
◎業務を支える情報システムを検討
現状のビジネス構造をモデル化し、システムを導入することで業務プロセスを最適化するスタイルでなければシステムは使いづらく、問題解決に繋がりません
◎業務パッケージの導入
業務に成熟していない組織に対しては一定の効果が見込めるが、パッケージに依存した業務構造となりそこからビジネス構造を変えることが難しくなる
◎ビジネスモデリング例
■ビジネスユースケースモデル（外部ビュー）
■ビジネス分析モデル（内部ビュー）
4 分析術！ コンサルティングツールの選択と活用
「超上流」 システム開発に入るまでにビジネス課題に適合したシステムを検討する上流工程
◎3C分析
市場（customer）
競合（competitor）
自社（corporation）
市場と競合からその事業に対する成功要因KSFを分析し、自社の現状とギャップから市場にどのように打って出るかを検討し、ビジョンや戦略を導きだします。
◎SWOT分析
企業の内部と外部の環境を適合させた戦略を立案するためのツール
企業の目標が明確になっている必要がある
◎7S分析
企業における7つの経営資源の頭文字を表したもの
企業の戦略を考えるときに考慮すべきポイントとされている
●ハードのＳ
戦略
組織
システム
●ソフトのＳ
価値観
スキル
人材
スタイル
◎5Force
業界に影響する5つの力（脅威）を分析することで、業界の収益構造を理解し、適切な事業参画や経営資源の投入を判断するためのツール

HTML5プロフェッショナル認定Level1 マイナビ

Sat, 01 Apr 2017 00:00:00 GMT

HTML5プロフェッショナル認定Level1 マイナビ

学んだこと

HTML/CSSの基礎
HTML要素、CSSのクラス、疑似クラスなど
セレクタの優先順位
手を動かしながら、実際にサンプルページを自分で作成しつつ少しずつ覚えた

手に取った理由

HTML5/CSSを活用したWeb開発のための知識習得
資格認定の為

学習メモ


######################################################################
# HTML5認定試験対策メモ
######################################################################


■Chapter1  HTMLの基礎知識
■====================================================================

■1-1.HTML5の基本文法
・空要素(void element)には終了タグを指定できない
・空要素のタグの>の直前にはスラッシュを入れても良い
・空白文字
半角スペース、タブ、改行(CR,LF,FFを含む)を纏めて空白文字と言います。
・属性を指定する際に「=」の前後には空白文字を入れることができ、属性値を
囲う引用符(「"」または「'」)は省略することが出来ます

・属性値を囲う引用符が省略できるのはその文書がHTML構文で書かれていて
属性値に空白文字の他に「=」「"」「'」「>」「<」「`(グレーブアクセント)」を含んでない場合に限ります
また属性値がからの場合は省略出来ません。

・HTML5文書の先頭にはオプションでBOM(バイトオーダーマーク)を入れることができる

・DOCTYPE宣言
ブラウザの表示モードを「標準モード」にする目的で指定することになっている

・文字参照
ソースコード内にそのまま記入出来ない文字などをテキストに書き入れられるようにするために、
HTMLでは文字参照という特別な書式を利用することが出来ます。

・グローバル属性
すべての要素に共通して指定できる属性のこと


◆練習問題
◆====================================================================
①HTML5のDOCTYPE宣言として妥当なもの
②状況によっては開始タグと終了タグの両方を省略できるものはどれか
・html
・head
・body
・colgroup
・tbody
のみ！
③空要素のタグ指定方法
/の後ろに空白スペースを記入できない
空要素には終了タグを記入できな
④DOCTYPE宣言の中でHTML5では使用できないもの

⑤HTML5のコメント記述方法として正しくないもの
「<!--」「-->」は続けて書く必要がある
コメント内部のテキストは - で終了することは出来ない

⑥論理型属性であるhidden属性の指定方法として間違っているものを選択
<div hidden="true"> ～ </div>
引用符も省略できるが、true,falseで指定することはできない

⑦HTML5のclass属性またはid属性の値の指定方法として間違っているものはどれか
id=""
id="abc xyz"
id属性は空文字は許さない
id属性は空白を含むことが出来ない


⑧HTML5で利用可能な属性のうち、任意の要素に指定可能でないものはどれか
data属性：object要素にしか指定できない





■Chapter2  HTML5で追加された要素
■====================================================================
◯セクショニングルート
・body要素
・blockquote要素
・fieldset要素
・figure要素
・td要素

◯セクションを表す要素の種類
・section
・article
記事を始めとする、「それだけで全部の/それだけで完結している」セクションを表す場合に使用します
単独で配布・再利用可能なコンテンツに対して使用し、記事のほかにもブログのコメントやフォーラムの投稿、
インタラクティブなウィジェットやガジェットなどをマークアップする際にも利用できます。
・aside
前後の内容とほぼ関係がなく、それらとは分離されたものであると考えられるセクション
・nav
そのページにおけるナビゲーションのリンクを含むセクションを表す場合に使用します。

◯構造を示す要素
・header要素

・footer要素

・main要素
main要素の内容には、そのページに特有のコンテンツのみを入れ、サイト内の複数のページで共有しているナビゲーションや
ロゴ、検索フォーム、著作権情報などのコンテンツは含めないようにする
main要素は1つのHTML文書につき1つしか配置出来ない

◯テキスト
・mark要素
黄色いマーカー線で表示して目立たせる
オリジナルの文書がそうなっていたわけではないが、
それを引用した人が読者に注目してもらいたいので目立つようにする場合などにも使用されます
その他、検索結果の一覧で、検索に使用した単語を目立つようにする場合などにも使用されます

・data要素
人が普通に読み取り可能な要素内容とともに機会読み取りが可能なデータも提供する要素
機械読み取りが可能なデータは、必須属性であるvalue属性の値として指定します

・time要素
data要素を日時での使用に特化させた要素

・wbr要素
通常、英単語やURLなどはいくら長くてもその途中で行を折り返すことはアリません。
英単語やURLの途中でも行を折り返すことができるようにする要素です。

・bdi要素
特定の範囲のテキストだけを意図的に分離・独立させることができる

◯ルビ
・ruby要素

・rt要素
ルビ(ひらがな)として小さい文字を表示させるテキスト
ruby関連要素の終了タグは省略可能

・rb要素
漢字の部分を示すための要素
なくてもいいが、細かく分ける場合は必要
<ruby><rb>漢字</rb><rt>かんじ</rt></ruby>
<ruby><rb>漢字<rt>かんじ</ruby>
<ruby><rb>漢</rb><rb>字</rb><rt>かん</rt><rt>じ</rt></ruby>
<ruby>漢<rb>字<rt>かん<rt>じ</ruby>

・rp要素
ルビ未対応のブラウザで表示させるときに、()カッコくくりでルビを表示させるための要素

<ruby>漢字<rp>(</rp><rt>かんじ</rt><rp>)</rp></ruby>
<ruby>漢字<rp>(<rt>かんじ<rp>)</ruby>
<ruby><rb>漢</rb><rb>字</rb><rp>(</rp><rt>かん</rt><rt>じ</rt><rp>)</rp></ruby>
<ruby>漢<rb>字<rp>(<rt>かん<rt>じ<rp>)</ruby>


・rtc要素
rt要素をグループ化する要素
ルビは↑だけでなく下(左)にもつけることが出来ます。

<ruby>漢字<rt>かんじ</rt></ruby>

◯動画・音声
・video要素
動画を再生させるための要素

・audio要素
音声を再生させるための要素

・source要素
代替データとして異なる形式のデータも併せて指定しておきたい場合

・track要素
動悸させる外部のテキストトラック(字幕などのテキストデータ)を指定する場合に使用します。

・embed要素
プラグインを使用する外部コンテンツを組み込む際に使用される要素


◯フォーム
・meter要素
メーターとして使用する要素です。
特定の範囲内での位置を示す場合に使用します。

・progress要素
タスク(コンピュータが行っている作業)の進み具合を表すための専用要素

・datalist要素
input要素にサジェスト機能を追加する(入力候補の選択肢を与える)要素
datalist要素の中に入れたoption要素が選択肢となります。

<p>
	<label>
		取得したい資格：
		<input type="text" name="c" list="certifications">
		<datalist id ="certifications">
			<option value="HTML5プロフェッショナル認定試験">
			<option value="ウェブデザイン技能検定">
		</datalist>
	</label>
</p>

・output要素
計算結果やユーザーの操作による結果を示すための要素
<form onsubmit="return false" oninput="sum.value=a.valueAsNumber+b.valueAsNumber">
	<input name="a" type="number"> + 
	<input name="b" type="number"> = 
	<output for="a b" name="sum"></output>
</form>


・keygen要素
公開鍵暗号における公開鍵・秘密鍵のペアを生成するフォーム部品
フォームを送信すると秘密鍵はローカルに保存され、公開鍵はサーバーに送られます
この要素は空要素です。


◯その他の新要素
・figure要素
figureという英単語は、図・図表、挿絵などの意味を持つ
それがメインコンテンツの本文から参照される図版のようなコンテンツであることを示します
具体的な要素内容としては、図表・写真・イラストソースコードの一部のような、
それ自身がまとまった一つの完結した内容になっているFlow content(一般コンテンツ)を入れます

<p>
CSSを使用すると、影を表示させることが出来ます。(<a href="#">図版01</a>)
</p>
<figure id ="fig01">
<figcaption>図版01：CSSでボックスに影を表示させる例</figcaption>
<pre><code>.sample {
	box-shadow: 3px 3px 10px #999;
	}</code></pre>
</figure>

・figcaption
figure要素で表す図版のキャプションや説明文部分をマークアップするための専用要素
figure要素の一番前か一番後ろにしか配置できない点に注意する

・template要素
その範囲がスクリプトによって生成(複製・挿入)される部分であることを示す要素

・canvas要素
スクリプトによって描画するビットマップの動的なグラフィックとなる要素






■Chapter3  HTML5で変更・廃止された要素
■====================================================================

◯HTML5で変更された要素
・hr要素
従来：横罫線を表示させるための空要素
コンテンツの内部的に「段落レベルで主題が変わるところ(区切り・変わり目)」を示す
話題が変わるところや、物語の場面が変わる所など

セクションはそれ自体が主題の区切りを示す為、セクショントセクションの間にhr要素を入れる必要はアリません
hr要素はセクション内部の段落レベルでの区切りを示すために使用します。

・small要素
従来：テキストを小さなフォントサイズで表示させるためのものでした
「一般的に小さな文字で示される付帯情報」をマークアップする為に使用します。
具体的には、Copyrightの表記や帰属、免責事項、警告と言った部分で使用されます


・strong要素
従来：em要素よりも強い協調を示す要素
「重要性」「重大性」「緊急性」のあるコンテンツをマークアップするために使用します

strong要素が重なれば重なる程その度合は強くなります。

・b要素
従来：テキストを太字で表示させるためのもの
重要性やその他の特別な意味合いは持たずに、実用的な意味で目立たせたほうが良いと思われる部分をマークアップする為に使用
具体的には、レビュー記事における製品名、概要説明に於けるキーワード、記事のリード文など

・i要素
従来：テキストをイタリックで表示させるためのもの
学名のほか英文中での船名、専門用語、言語が異なっている部分、小説などにおける頭のなかで考えていることの表現など、
普通のテキストとは違う性質のものに切り替わっているような部分を示す

・s要素
従来：取り消し線を引いた状態で表示させるためのもの
既に正しい情報ではなくなった部分、関係のない情報となってしまった部分を表すために使用します。

文書の編集によって削除された部分はs要素を使用せずに、del要素を使用します。


・u要素
従来：テキストに河川を引いた状態で表示させるための要素
耳で聞いてもわからないけれども表示上は明確に示される、テキスト以外で注釈的な表現をする
範囲をマークアップするために使用します。
用途は、中国語でテキストが固有名詞であることを示す場合や、スペルミスの箇所を示す場合などと限定的で、一般的なページでは
ほとんど利用されない要素

リンク付き要素とかぶってしまうため、それらの要素と混在するのは避けられる。


◯HTML5で廃止された要素
・center要素やfont要素といった表示指定の要素派廃止された
・small要素は利用可能だが、big要素は廃止された
・s要素は利用可能だが、strike要素は廃止された



◯HTML5で廃止された属性
・alignやbgcolorといった表示指定の属性は基本的にすべて廃止された
・一部の要素を覗いてname属性は廃止され、代わりにid属性が使用される
・あまり使われていなかった属性、他の機能で代用可能な属性の多くも廃止された



■Chapter4  HTML4.01以前からある要素
■====================================================================
◯基本構造
▼ココが重要
・html要素のversion属性は廃止され、新しくmanifest属性が追加された
・HTML5では、titile要素がなくても良いケースがある
・address要素はもっとも近いarticle要素またはbody要素の問合せ先

▼html要素
manifest属性：アプリケーションキャッシュマニフェスト(キャッシュさせるファイル、させないファイルなどの情報を
明記したテキスト形式のファイル)を指定するための属性

・補足
html要素の開始と終了タグは、その直後にコメントがなければ省略することも可能

・注意
HTML5にはHTML構文とXHTML構文がアリますが、タグの省略が可能なのはHTML構文だけである

▼head要素
HTML文書のMetadata content(文書情報コンテンツ)を入れるための要素

▼body要素
HTML文書のコンテンツを入れるための要素です。

▼title要素
HTML文書のタイトル、または名前であることを示す要素
head要素の中に記載する。

title要素は1つのhtml文書につき1つしか配置できない点に注意してください。


▼base要素
HTML文書内で指定されている相対URLの基準にするURLを設定する為の要素です。
必ずhead要素内で使用
target属性を使用することでデフォルトの表示先(ブラウジングコンテキスト)を
設定しておくことも出来ます。

・ブラウジングコンテキスト
HTML5の仕様書では、HTML文書を表示させるウィンドウやタブ、インラインフレームなどのことを
ブラウジングコンテキストと呼んでいます。

・注意
1つのHTML文書につき1つまで
少なくともhref属性かtarget属性のいずれか一方を指定する必要がある
base要素で指定した基準URLはhtml属性のmanifest属性で指定する
アプリケーションキャッシュマニフェストのURLには影響を与えない点に注意

▼meta要素
様々な種類のメタデータを指定できる要素
・メタデータ
あるデータに関するデータのことを指す一般的な用語で、
HTML文書でいうと、「HTML文書自身に関する情報」のことです。
HTMLのhead要素内に入れられる要素は基本的にすべてメタデータであるといえます。

・プラグマディレクティブ/プラグマ指示子
HTML文書の状態や挙動を支持する命令のこと
たとえばブラウザへの再読込や他文書への移動の命令、デフォルトのスタイルシート言語やスクリプト言語の設定、
文字コードの宣言などがこれに当たります。
meta要素にhttp-equiv属性が指定されているとき、そのmeta要素はプラグマディレクティブとなります。

▼address要素
自分自身に最も近いarticle要素またはbody要素の内容に関する問い合わせ先を示す要素

・ココに注意
address要素の内容に入れられるのは、問合せ先の情報だけです。
著作権情報や更新日のような問合せ以外の情報は入れられませんので注意してください

▼div要素
予め決められた役割や意味を持たない要素です。
似た要素としてspan要素があります
違いはインライン要素/ブロックライン要素でしたが、
HTML5ではそのような分類はされなくなりました。


▼span要素

◯テキスト
・h1～h6要素はセクションの見出しを表す
・blockquote要素の内部には、footer要素やcite要素を配置できる
・cite要素は作品のタイトル・作者名・参照先URLのいずれかを示す

▼h1～h6要素
セクションの見出しとなる要素

▼p要素
段落を表す要素

▼blockquote要素
要素内容が引用してきた文書であることを示す
ブロックレベル要素：blockquote
インライン要素　　：q
指定できる属性：cite属性


▼q要素
その要素内容が引用してきた文書であることを示す
インライン要素で使用

指定できる属性：cite属性

▼cite要素
創作物に言及する際にそのタイトルを示すための要素
要素内容には、作品の題名か作者の名前(個人・団体・組織も可)、参照先のURLのいづれかを含めなければなりません。

▼ins要素
文書に追加した部分(inserted text)を示す為に使用

◯指摘できる属性
・cite
・datetime

ins要素のコンテンツモデルはトランスペアレント

▼del要素
文書から削除した部分を示す

del要素のコンテンツモデル派トランスペアレント

▼em要素
強調されている部分を示すための要素

▼br要素
その位置で改行さえるための空要素
改行がコンテンツの一部であるような部分で使用します。
余白をとるために使用したり、段落のように見せるために改行として使用するものではアリません。


▼abbr要素
略語であることを示す。
省略していない状態の言葉を示すには、title属性を指定する。

※注意
title属性は補足情報を提供するグローバル属性ですが、
abbr要素で使用する場合、「省略してない状態の言葉を示す」以外の用途には使用できない点に注意

・すべての略語に対してabbr要素を指定する必要はない。使いたいときだけ！
・abbr要素の他にacronym要素も以前はあったが、使い分けに混乱が生じたので、廃止になった


▼dfn要素
その部分が定義の対象となっている用語であることを示す。

▼pre要素
その要素内容であるテキストが整形済み(performatted)であることを示す要素
ここで言う整形とは、半角スペースやタブ、改行を使って表示を整えているという意味で、
pre要素の要素内容は入力されているとおりにそのまま表示されます。
ただし具体的にどのように表示させるかはCSSで指定可能です。
・ソースコード
・アスキーアート
・メール内容

※注意
HTML構文の場合、pre要素の開始タグ直後にある改行は取り除かれる事になっている


▼code要素
その部分がコンピュータで使用されるソースコードであるということを示す要素

▼samp要素
コンピュータのプログラムやシステムからの(サンプル)出力であることを示す

▼kbd要素
ユーザーが入力する内容であることを示す要素

▼var要素
その部分が変数(variable)であることを示す要素

▼bdo要素
Unicodeの双方向アルゴリズムの文字表記の方向を上書きして指定する
要素内容のテキストを左から右へと表示するのか、右から左へと表示するのかをグローバル属性であるdir属性を使って設定する要素

▼sup要素
その部分が上付き文字要素であることを示す

▼sub要素
その部分が下付き文字要素であることを示す






◯リスト
※ココが重要
・HTML5ではul要素 / ol要素 / dl要素の内容はからでもOK
・HTML5のdl要素で用語をの定義をする場合、dfn要素も必要になる
・HTML5のdl要素は、会話・対談を表す場合には使用できない

▼ul要素
箇条書きのようなリスト

▼ol要素
連番つけられた項目を持つリスト

※指定可能な属性
・type
・start
・reversed

▼li要素
リストの各項目人なる要素

▼dl要素
内容となる各項目が「名前(dt要素)」「値(dd要素)」のペアになっている形式のリスト

※注意
・HTML5ではdl要素の要素内容はからでもOK。また必要に応じてtemplate要素とscript要素を配置することもできる

以前：dl要素 definition listを意味
HTML5:dl要素 description listを意味
これによってdl要素から「定義」の意味がなくなった為、dl要素を「用語の定義」に使用する場合には、
次のようにdfn要素(定義対象の用語であることを示す要素)を追加する必要がある点に注意

▼dt要素
名前(用語)などを示す

▼dd要素
値(説明文等)


◯リンク
※重要
・a要素のコンテンツモデル派条件付きのトランスペアレント
・a要素にはdownload属性が追加されている
・link要素にはsizes属性とcrossorigin属性が追加されている

▼a要素
要素内容がハイパーリンクになります。

▼link要素
関連する別の文書やファイルなどを示すための空要素href属性とrel属性は必ず指定する必要があります。
href属性とrel属性は必ず指定する必要があります。

◯画像とオブジェクト
※重要
・HTML5では、特別なケースにおいてはimg要素のalt属性を省略できる
・HTML5では、width属性とheight属性に％値は指定できない
・map要素とobject要素のコンテンツモデルはトランスペアレント

▼img要素
src属性で指定したアドレスの画像を表示させる空要素

▼map要素
イメージマップを定義するための要素

▼area要素
イメージマップでリンクする領域を定義する空要素

▼object要素
様々な形式の外部データを組み込むための要素
画像や別のHTML文書、プラグインを使用するデータなども組み込むことが出来ます。

▼param要素
object要素によって呼び出されるプラグインのパラメータを設定する要素

◯フォーム
※重要
・HTML5では、フォーム関連の属性が多数追加されている
・input要素で作成可能な部品の種類は、HTML5になって約2倍に増えた
・form要素の外部にある部品でも、form要素に関連付けることが可能となった
▼form要素
フォーム関連の要素をとりまとめ、ユーザーが入力・選択したデータをサーバーに送信するための要素

▼input要素
type属性で指定したキーワードによって様々な種類の入力・選択用部品となる要素

▼textarea要素
複数行のテキストフィールドとなる要素

▼button要素
要素内容がそのままラベルとして表示されるボタン

▼select要素
選択肢の中から選ぶ形式のフォーム部品になる要素

▼option要素
select要素またはdatalist要素の選択肢となる要素

▼optgroup要素
option要素をグループ化してそこにグループの名前をつける要素

▼label要素
その要素内容であるラベルとフォーム部品とを関連付けるための要素

▼fieldset要素
フォーム関連の要素をグループ化するための専用要素

▼legend要素
fieldset要素によってグループ化されたフォーム関連要素のグループ名(キャプション)を表示させるための要素
枠で囲われるやつね！


◯テーブル
※重要
・table要素のborder属性は、レイアウト用のテーブルではないことを示す
・tfoot要素は、tbody要素の前にでも後ろにでも配置できる
・table要素内で使用する要素の多くは、終了タグを省略できる

▼table要素
表形式のデータを表すための要素

※注意
table要素のborder属性は以前は表の線の太さを指定するために使用されていましたが、
HTML5ではレイアウト用のテーブルではないことを示す目的で使用されます。
その為、値には1か空文字以外は指定できなくなっている点に注意！！

※説明補足
HTML5の仕様書には、「テーブルをレイアウトのために使用するべきではない」と明確に記載されている
また、「もし、テーブルをレイアウトの為に使用するのであれば、role="presentation"を指定しなければならない」
とも書かれています。

▼tr要素
表の横一列を表すために使用

▼th要素
表の見出し用のセルを表すために使用

▼td要素
データ用のセルを表す要素

▼thead要素
見出しとなっているtr要素をグループ化する要素
簡単に言えば表のヘッダーを表す要素

▼tbody要素
表の本体部分を表す

▼tfoot要素
表のフッター部分を表す

※注意
以前はtfoot要素は必ずtbody要素よりも前に配置する必要が有りました。
HTML5ではtfoot要素はtbody要素の前でも後ろでも配置出来ます。
ただし1つのtable要素内に複数のtfoot要素を配置することは出来ません。

▼caption要素
table要素のキャプション(表のタイトル)となる要素


▼col要素
span属性のないcolgroup要素内に配置して、1列分以上の縦列を表す空要素
col要素にspan属性を指定していなければ、１列分の縦列を表し、span属性を指定して値に１以上の整数を指定していればその列分の
縦列となります。

▼colgroup要素
1列分以上の縦列をグループ化する要素
※注意
colgroup要素にspan属性を指定している場合は、colgroup要素の要素内容は空にします。
span属性を指定していない場合は、0個以上のcol要素かtemplate要素を入れます。


◯その他
※重要
・iframe要素のsrcdoc属性には、HTML文書全体を記入できる
・script要素のtype属性のデフォルト値は「text/javascript」で省略も可能
・noscript要素はXHTML構文では使用できない

▼iframe要素
HTML文書の中で、別の文書を表示させる領域(ブラウジングコンテキスト)となる要素
「iframe」は「inline frame(インラインフレーム)」の略


▼script要素
HTML文書内にスクリプトまたはデータブロックを組み込む為の要素

▼noscript要素
スクリプトが向こうの場合に利用されるコンテンツを要素内容としてもつ要素









■Chapter5  CSSの基礎知識
■====================================================================

◯CSSの基本文法と組み込み方
※重要
・CSSの書式には自由に空白文字を入れられるが、セレクタだけは例外
・HTML5では、link要素とstyle要素のtype属性が省略可能となった
・link要素とstyle要素のmedia属性と@importにはメディアクエリが指定可能

▼基本的な書式と各部の名称

▼link要素でHTMLに組み込む
head要素の中にlink要素を指定してHTMLに埋め込む方法

▼style要素でHTMLに読み込む
要素内容としてスタイルシート言語を組み込むことのできる要素

▼style属性でHTMLに組み込む
グローバル属性であるstyle属性を指定して、その値としてCSSを組み込む方法

▼@importでCSSに組み込む
@importの書式を使用することで、CSSの中で更に外部スタイルシートを読み込ませる事もできます。
最も簡単な方法は、次のように@importの後に外部スタイルシートのURLを文字列として指定する方法
文字列として指定するので、ダブルクォーテーションまたはシングルクォーテーションが必要です。

@import "style.css";

@import url(style.css);

URLの後には、link要素やstyle要素で指定可能なメディア型やメディアクエリを指定することもできる
@import "style.css" screen, print;


◯セレクタ
※重要
・属例セレクタと結合子の記号はしっかりと覚える
・擬似クラスの式「an+b」の指定方法をしっかりと覚える
・疑似要素の先頭のコロンはCSS3から2つになった


▼セレクタの種類と組み合わせのルール

▼タイプセレクタ
要素名をそのまま使って適用先を示すシンプルセレクタをタイプセレクタと言います。

▼ユニバーサルセレクタ
要素名の代わりに(*)を指定すると、すべての要素が適用対象となります。

▼クラスセレクタ

▼IDセレクタ

▼属性セレクタ　NEW!!
特定の属性が指定されている要素、またhあ特定の属性に特定の値が指定されている要素を適用対象として指定できるのが属性セレクタです。

img[src$=".jpg"] { border: 3px solid #f00 }


▼リンク関連の擬似クラス
ある要素が特定の状態にあるときなどに限定して適用対象とするのが擬似クラス
CSS3では23種類の擬似クラスが定義されていますが、はじめに使用頻度の高いリンク関連の擬似クラスを説明
・:link     リンク先をまだ見ていない
・:visited  リンク先を既に見た状態
・:hover    カーソルが上にある状態
・:active   マウスのボタン等が押されている状態

※注意
同時になる状態がある場合は、後に指定されたほうが有効になるので、
基本的に上記の順序で指定しなければならない！！


▼その他の擬似クラス

▼疑似要素
要素ではない部分(タグのつけられていない範囲)を適用対象とする
CSS3では次の4種類の疑似要素が定義されている

・::first-line     ブロックレベル要素の一行目
・::first-letter   ブロックレベル要素の1文字目
・::before         要素の直前にコンテンツを追加
・::after          要素の直後にコンテンツを追加


▼結合子
組み合わせたシンプルセレクタ同士を区切って使用する結合子には次の4種類がある

・空白文字  セレクタAの中に含まれているセレクタB
・>         セレクタAの直接の子要素であるセレクタB

・+         セレクタAの直後に現れるセレクタB
・~         セレクタAよりも後に現れるセレクタB


◯CSS適用の優先順位
※重要
・ユーザーエージェント・ユーザー・制作者の優先度は!importantで逆転する
・詳細度が最も高いのはstyle属性による指定
・セレクタの詳細度は、IDセレクタ・属性系セレクタ・要素系セレクタの3桁で示す

▼CSSの指定元による優先順位


▼!importantで優先順位を高くする

▼セレクタの詳細度による優先順位の計算方法






































■Chapter6  CSS3の主な新機能
■====================================================================
◯色
※重要
・CSS3からは色の値が指定可能なすべての箇所でtransparentが使用可能
・不透明度は0.0~1.0までの単位をつけない数値で指定する
・hslは、hue(色相)・saturation(彩度)・lightness(明度)の意味

▼色を示す値：16進数

▼色を示す値：キーワード

▼色を示す値：rgb(),rgba()
rgb()という関数形式の書式を使用すると、RGBの値を10進数のまま指定可能

▼色を示す値：hsl(), hsla()
直感的に色を指定したり変更できるようにするために作られたもの


▼colorプロパティ
テキストの文字色を設定するプロパティです。


▼opacityプロパティ
要素の不透明度を設定するプロパティ


◯背景
※重要
・CSS3では複数の背景画像が指定できる
・CSS3では背景の表示領域を変更できる
・CSS3では背景画像のサイズが指定できる

▼ボックスの構造

▼長さを表す単位

▼background-colorプロパティ
ボックスの背景色を設定するプロパティ

▼background-imageプロパティ

▼background-clipプロパティ
背景をボックスのどの領域に表示させるのかを設定するプロパティ

▼background-repeatプロパティ
背景画像を縦または横に繰り返し表示させるかどうかを設定するプロパティ

▼background-sizeプロパティ
背景画像の表示サイズを設定するプロパティ
1つ目が幅　2つ目が高さ

▼background-originプロパティ
clipの画像版プロパティ的なもの

※注意
背景色も含めた背景の表示範囲を設定するbackground-clipプロパティの初期値は

▼background-positionプロパティ
背景画像を表示させる領域内での画像の配置位置を設定するプロパティ

▼background-attachmentプロパティ
背景画像を表示領域に固定して、ページの内容をスクロールしても動かないようにすることができる

▼backgroundプロパティ
背景関連のプロパティの値を纏めて指定できる

※注意
backgroundプロパティで指定されていない値は現状が維持されるのではなく初期値に戻されるので注意　
backgroundプロパティの値もカンマで区切ることで、複数の背景画像のレイヤーを指定できます。
その際に、background-colorプロパティは一番下のレイヤー(書式上はカンマで区切られた一番右側の値)にしか指定できません


◯アニメーション
※重要
・transform関連プロパティでは、ボックスの回転・拡大縮小・移動などを行う
・トランジションは、値の切り替わりを滑らかに連続した動きで見せる機能
・アニメーションは、キーフレームでトランジションを連続実行させるようなもの

▼回転・拡大縮小・移動など
transformプロパティを使用すると、要素のボックスを回転させたり、
拡大縮小させたり、移動させることなどが出来ます。
しかもそれらは平面的な2次元空間だけでなく3次元空間デモ行える様になっているため、立体的な3D表現も可能


▼transformプロパティ
要素のボックスを回転・拡大縮小・移動・変形さえるプロパティ
値は関数形式になっており、空白文字で区切って必要なだけ指定できます。

▼transform-originプロパティ
transformプロパティの原点を指定するプロパティ

1つ目は横方向の位置
2つ目は縦方向の位置

transform-origin: top loft;
transform: translate(200px, 100px) scale(1.5, 1,5) rotate(45deg);


▼CSS3のトランジションとは
例えば、セレクタの:hoverを使って表示を変更すると、その表示は瞬時に切り替わります。
それを連続した動きで滑らかに変化させるのがCSS3のトランジション


▼transition-propertyプロパティ
「どのプロパティ」の値が変更されたときにトランジションを実行させるのかを設定するプロパティ

▼transition-durationプロパティ
どれだけの時間をかけて変化させるのかを設定する

▼transition-timing-functionプロパティ
トランジション機能で表示を変化させる際、最初から最後まで一定のスピードになっていると、
変化の種類によっては機械的で不自然な印象を与えてしまいます。
そこでゆっくりと変化を開始して徐々にスピードを上げ、だんだんとスピードを落としながら終了すると言ったように
様々なパターンで速度に変化をつけられるようになっています。
その指定を行うのがtransition-timing-functionプロパティです。

▼transition-delayプロパティ
トランジションの開始を遅らせるプロパティ

▼transitionプロパティ
トランジション関連のプロパティの値を纏めて指定できるプロパティ

▼CSS3のアニメーションとは
CSS3のアニメーションとは、ひとことで言ってしまえばトランジションを連続して実行させるようなもの

キーフレームを指定する

▼@keyframes
css3のアニメーションでは、決められた時間の中の度のタイミングでどの値がどう変化するのかをキーフレームと呼ばれる
書式で記入します。

@keyframes 名前 {
  0% {
     プロパティ: 値;
     プロパティ: 値;
     …
  }
  ?% {
     プロパティ: 値;
     プロパティ: 値;
     …
  }
  ?% {
     プロパティ: 値;
     プロパティ: 値;
     …
  }
  100% {
     プロパティ: 値;
     プロパティ: 値;
     …
  }


}


※補足説明
キーフレームの「0%」は「from」、「100%」は「to」と書くことも出来ます。

▼animation-nameプロパティ
アニメーションを実行させるためには、キーフレームを名前で指定し、
アニメーションの再生時間を指定する必要がアリます。animation-nameプロパティは、
キーフレームを名前で指定して実行させるためのプロパティ

▼animation-durationプロパティ
アニメーションの再生時間を設定するプロパティ
transition-durationプロパティと同様に値には時間を設定します。初期値は0sです。


▼animation-timing-functionプロパティ
アニメーションの再生速度の変化パターンを設定するのがanimation-timing-functionプロパティ


▼animation-delayプロパティ
アニメーションの再生を遅らせるプロパティ

▼animation-iteration-countプロパティ
アニメーションを何回繰り返して再生させるのかを設定するプロパティ
初期値は１
inifiniteを指定すると、止めるかウィンドウを閉じるまで再生を繰り返します。


▼animation-directionプロパティ
再生の際に逆再生させるかどうか、または繰り返し再生する中で度のタイミングで逆再生させるのかを設定するプロパティ
初期値はnormalです。


▼animation-paly-stateプロパティ
アニメーションの再生を一時停止させる際に使用するプロパティ
pauseを指定すると一時停止し、runningを指定すると再生が開始されます。

初期値はrunningです。


▼animation-fill-modeプロパティ
animation-delayプロパティによって再生の開始が遅延されている間の表示、及び再生終了後の表示を設定するプロパティ
初期値はnone

▼animationプロパティ
アニメーション関連のプロパティを纏めて指定できるプロパティ


◯マルチカラムとフレキシブルボックス
※重要
・CSS3のマルチカラムレイアウトはボックスの内部を複数の段に分割する
・columnsプロパティで段数を指定するだけで段組みになる。
・display: flex;を指定すると、その子要素は左から順に横に並ぶ

▼マルチカラムレイアウト
複数のボックスを横に並べるタイプのレイアウトではなく、
１つのボックスの内部を複数の段に分割するタイプのレイアウトです。

▼column-countプロパティ
何段組するのかを設定するプロパティ
値には段数を１以上の整数で指定しまうす。
初期値はautoです。

body { column-count: 3; }

▼column-width
段の幅を設定するプロパティ
初期値はauto

▼columnsプロパティ
column-countプロパティとcolumn-widthプロパティを纏めて指定できるプロパティ


▼column-gapプロパティ
段と段の間隔を指定する
初期値はnormal 1em


▼column-ruleプロパティ
段と段の感化kの中央にはボックスのボーダーと同様の線を表示させることが出来ます。
その線種・色・太さを個別に設定するのが次の３つのプロパティ
・column-rule-styleプロパティ
・column-rule-colorプロパティ
・column-rule-widthプロパティ

纏めて設定できるのがcolumn-ruleプロパティです。


▼column-spanプロパティ
指定された要素を段の中におさめて表示させるのではなく、
段組が設定されているボックスの幅いっぱいに(すべての段をまたいで)表示させるプロパティです。
値にはallとnoneが指定でき、初期値はnoneです。

▼フレキシブルボックスレイアウト


◯その他の新機能
※重要
・border-radiusの角丸の値は、角を1/4円に見立てたときの半径を指定する
・box-shadowとtext-shadowの影の指定方法はほぼおなじ
・グラデーション指定の基本形は、方向または中心位置と色を２色指定すればOK

▼border-radiusプロパティ
ボックスの角を丸くするプロパティ

▼box-shadowプロパティ
ボックスに影を表示させるプロパティ

▼text-shadowプロパティ
テキストに影を表示させるプロパティ

▼直線上のグラデーション
CSSの書式で画像が指定可能なところであれば、url()の代わりにlinear-gradient()またはradial-gradient()という関数を使用して
グラデーションを表示させることができる

background: linear-gradient(#ddd, #333);

▼放射状のグラデーション























■Chapter7  CSSの各種プロパティと値
■====================================================================
◯フォント
※重要
・Webフォントを使用するには、@font-face{} の書式を指定する
・CSS3では、font-variantは関連プロパティの値を一括指定するプロパティ
・fontプロパティは、値の指定順序に注意する

▼Webフォント
@font-faceという書式を使用してWeb上にあるフォントを指定することで、そのフォントがインストールされていない
環境でもそのフォントを表示させられるようになります。


▼font-familyプロパティ
フォントの種類を設定するプロパティ
フォントはより前に(左側に)指定されているものが優先して適用されますので、キーワードは最後に指定するように
p{
   font-family: "メイリオ", "ヒラギノ角ゴ pro W3", Helvetica, sans-serif;
   
}

▼font-sizeプロパティ
フォントサイズを設定することができる
初期値はmidiumです。

▼font-weightプロパティ
太さの異なる書体を選択するためのプロパティ
初期値はnormal
400が標準の太さ


▼font-styleプロパティ
同じフォントファミリーの中のイタリックまたは斜体の書体を選択するためのプロパティ

・italic   イタリック体専用にデザインされたフォントで表示。ない場合「oblique」と同様
・oblique  斜体で表示。ない場合標準のフォントを斜めに変換して表示
・normal   イタリック体や斜体ではない標準のフォントで表示

▼font-variantプロパティ

▼fontプロパティ
フォント関連プロパティの値を纏めて指定できるプロパティ

◯テキスト
※重要
・CSS3からは、下線・上線・取消線の色や線種が指定できる
・word-breakプロパティは、行の折り返しに関する設定をする
・hyphensプロパティは、ハイフネーションに関する設定をする

▼text-decoration関連のプロパティ

▼word-breakプロパティ
行の折り返しに関する設定

▼hyphensプロパティ
ハイフネーションの設定を行うプロパティ

▼white-spaceプロパティ
「連続する空白文字を１つの半角スペースに変換するかどうか」と「自動的な行の繰り返しを行うかどうか」を制御する

▼text-alignプロパティ
ブロックレベル要素に指定し、その内容の行揃えを設定

▼vertical-alignプロパティ
インライン要素の縦方向の位置を設定する

▼line-heightプロパティ
行の高さを設定するプロパティ

▼text-indentプロパティ
ブロックレベル要素の１行目のインデントを設定する

▼letter-spacingプロパティ
文字間隔を設定するプロパティ

▼word-spacingプロパティ
単語と単語の間隔を設定するプロパティ

▼text-transformプロパティ
アルファベットの大文字小文字を変換して表示させるプロパティ

▼directionプロパティ
文字表記の方向を設定する

ltr：左から右
rtl：右から左

▼unicode-bidiプロパティ
文字表記の方向に関する指示を組み込んだり上書きすることのできるプロパティ
よくわからない。。。


◯ボックス
※重要
・幅と高さの適用される領域は、box-sizingプロパティで設定する
・clearプロパティはブロックレベルの要素に指定する
・displayプロパティは、テーブル関連・ルビ関連の表示形式も指定できる

▼margin関連プロパティ

▼padding関連プロパティ

ORACLE MASTER Oracle Database12c DBA Bronze

Sat, 01 Oct 2016 00:00:00 GMT

ORACLE MASTER Oracle Database12c DBA Bronze

学んだこと

別書籍で知識を付けていたOracleDBAの再学習
プロセスやOracleが持っている機能について、別書籍では触れられていない部分を学ぶことが出来た。
学習ログ

手に取った理由

Oracle Master Bronze資格取得のため

Webを支える技術

Fri, 01 Jul 2016 00:00:00 GMT

Webを支える技術

学んだこと

WEBの歴史的なところ
リソースとURI
使用すべきメソッド
RESTについて
理解が難しかったので、もう一回読みたい本..

手に取った理由

業務でJavaからPUTで他社APIを呼び出す必要に迫られた際、なんでPUT？POSTじゃだめなの？と思い、理由を深堀すべく本書を見つけ、購入

ORACLE MASTER Oracle Database12c SQL Bronze

Fri, 01 Apr 2016 00:00:00 GMT

ORACLE MASTER Oracle Database12c Bronze

学んだこと

別書籍で知識を付けていたOracleDBAの再学習
プロセスやOracleが持っている機能について、別書籍では触れられていない部分を学ぶことが出来た。
学習ログ

手に取った理由

Oracle Master Bronze資格取得のため

Effective Java

Tue, 01 Mar 2016 00:00:00 GMT

Effective Java　第二版

著者：Joshua Bloch　ジョンシュア・ブロック　（sun → google[Chief Java Architect]）
訳　：柴田芳樹

Effective Java によせて

言語を使用するために習得しなければならない３つの事項

  1. 文法
  2. 語彙
  3. 日々の事柄を話すための慣習的で効果的な方法

教室では文法、語彙のみ教わることが多い

慣習的な方法を習わずに必死に話を伝えようとするして、ネイティブに笑われる

プログラミング言語も全く同じ

本書は３番目の要求に取り組んでいる

全体読んでわかったこと

基本的に言いたいことは、エラーについてコンパイル時に気づくことが正しく、実行時に気づくことは良くない

パフォーマンスに言及している

他、英語翻訳の片言的な書き方が目立つ

第１章　はじめに

ライブラリ - java.lang - java.util - java.util.concurrent - java.io
対象者 - Java使いこなしている人

そうでない人は入門書をお読みください

第２章　オブジェクトの生成と消滅

    - どのようにオブジェクトを生成スべきか
    - いつどのように生成を回避スべきか
    - オブジェクトが適切なタイミングで消滅することをどのように保証するか
    - オブジェクト消滅前に実行しなければならない後処理をどのように行うか

項目１　コントラクタの変わりにstaticファクトリーメソッドを検討する

Staticファクトリーメソッド

長所と短所が存在する

長所

メソッド名がつけられるので分かりやすい

 コンストラクタのように同じシグニチャを持つものが２つ以上存在できないという制約はないし、ドキュメントがなくても分かりやすい
 コンストラクタはドキュメントがないと、中身を見ないと何をしているかわからない

メソッドが呼び出されるごとに新たなオブジェクトを生成する必要がない

 不必要に重複したオブジェクトの生成を回避できる
 Flyweightパターンに似てる
 何度呼び出されても同じオブジェクトを返すことができる　インスタンス制御されている（incetance-controlled）
 equalsメソッドの代わりに==演算子が使用可能
 →パフォーマンスが大幅に上がる　Enum型はこの保証を提供している

戻り値の型の任意のサブタイプのオブジェクトでも返すことができる

 インターフェースに基づくフレームワーク（interface-based-framework）項目１８
 Collections Framework　コレクションのインターフェースの便利な実装が３２個ある
 概念的重みが軽くなっている　クライアントはインターフェースで返されたオブジェクトを受け取る
 EnumSetはenum型の要素数に応じて返却するインスタンスが異なる
 これらはクライアントには見えない

 Java Database Connectivity API (JDBC) などのサービス・プロバイダフレームワークの基本となるもの
 サービスインターフェース：プロバイダが実装する
 プロバイダ登録API：クライアント
 サービスアクセスAPI：サービスのインスタンスをクライアントが取得するためのもの

パラメータ化された型のインスタンス生成の面倒さを低減する

 new でもダイヤモンド構文でJava1.7から簡単に記述可能
 あまりすごいメリットでもない

短所
1. publicあるいはprotectedのコンストラクタを持たないクラスのサブクラスを作れないこと
```
  継承ではなくコンポジションを使おう
```
2. それらが容易に他のstaticメソッドと区別がつかないこと

項目２　数多くのコンストラクタパラメータに直面した時にはビルダーを検討する

staticファクトリメソッドもコンストラクタが持っている共通の制約

数多くのパラメータに対してうまく対応できない

これらの対処として、テレスコーピングコンストラクタパターンを利用していた

テレスコーピングパターン

    パラメータの数が増えるとすぐに手に負えなくなる
    クライアントがパラメータの値の２つを逆にしてしまっても、コンパイラは何も警告しませんが誤った振る舞いをしてしまう

JavaBeansパターン

    パラメータなしのオブジェクトを生成して、setメソッドでセットしていく

    生成過程で不整合な状態にあるかもしれない
    バグを含んでいるコードから離れた場所で失敗するかも

Builderパターン

    テレスコーピングコンストラクタの安全性とJavaBeansパターンの可読性を併せ持つ
    AdaやPythonにみたいな名前付きオプションパラメータをビルダーパターンは模倣しています

    パフォーマンスに影響がある可能性があるが、パラメータが４つ以上ある場面では大抵の場合メリットのほうが大きい
    途中でBuilderに替えると使われなくなったコンストラクタやStaticメソッドはゴミになってしまうので、最初からビルダーで始めたほうがよい

項目３　privateのコンストラクタかenum型でシングルトン特性を強制する

シングルトンとは

一度しかインスタンスが作成されないクラス

＊割愛＊再確認

現状、シングルトンを実装する最善の方法は、単一要素のenum型を用いること

項目４　privateのコンストラクタでインスタンス化不可能を強制する

ユーティリティクラスを作成する際は、public static メソッドを定義のうえ、

コンストラクタをprivateにして、明示的にインスタンス化できないかつ継承できないことをコメントに記すべし

コンストラクタの中に、throw new AssertionError(); を定義すると、誤ってクラス内からコンストラクタが呼び出されたときの保険になる

項目５　不必要なオブジェクトの生成を避ける

String s = new String("stringette"); //　これは絶対にやってはいけない

呼び出しごとに新しいインスタンスが生成されてしまう。

不変な値であれば、クラス定数としてprivate static finalで定義しておき、

初期化を　static{}でするべき

一度も呼び出されない場合は無駄な初期化になりえるが、遅延初期化を実装するのはもっと大変なので避けてもよい

自動ボクシング時にインスタンスが生成されるので気をつけて

項目３９「防御的コピー」との対比

必要な場所で防御的コピーをしなければ、悪質なバグやセキュリティホールを生み出しかねない

不必要なオブジェクトを生成するのは、単にスタイルとパフォーマンスに影響するだけ

項目６　廃れたオブジェクト参照を取り除く

配列の廃れた参照に対する配慮

スタックが大きくなったあとに小さくなるト、大きくなった部分のオブジェクトがガベージコレクトの対象にならない

Queオブジェクトでよいよねー

項目７　ファイナライザを避ける

ファイナラーザは予測不可能で大抵の場合は必要ない

不安定な振る舞い低いパフォーマンス移植性の問題原因

実行される保証がないファイナライザを持つオブジェクトの生成と開放は430倍遅い明示的に閉じる、inputStream,outputStreamオブジェクトもfinalizeメソッドを実装しており、GC対象になったときに呼び出されるが、あくまで保険的な意味合いなので、明示的にcloseするのが好ましい

ファイナライザを使用する場面安全ネット（closeシワスレの保険）ネイティブ資源の開放

結論ファイナライザは使用しない

第３章　すべてのオブジェクトに共通のメソッド

項目８　equalsをオーバーライドする時は一般契約に従う

equalsメソッドを誤ってオーバーライドしては行けない

次の条件に当てはまるときはオーバーライドしないのが妥当

クラスの個々のインスタンスは、本質的に一意である

論理的等価性検査をクラスが提供するかどうか関心がない

スーパークラスがすでにequalsをオーバーライドしており、スーパークラスの振る舞いがこのクラスに対して適切である

AbstractSetやAbstractListが実装しており、SetやListは継承している

クラスがprivateあるいはパッケージプライベートであり、そのequalsメソッドが決して呼び出されないことが確かである

このような場合は、偶然呼び出された時を考慮して、 throw new AssertionError(); を実装するべき

equalsメソッドは同値関係を実装する
- 反射的
- 対照的
- 推移的
- 整合的

咀嚼できていない

そもそもequalsメソッドを実装（オーバーライド）することが稀

いままでそのような処理を見たことがない

項目９　equalsをオーバーライドする時は、常にhashCodeをオーバーライドする

hashMapのキーにequalsメソッドを実装したクラスを設定する場合、new 対象オブジェクト名();で

設定すると、equalsメソッドではtrueを返却する場面で、hashCodeメソッドはことなる値を返却するためMapの値が取れない現象が発生するらしい

こちらも項目８同様あまり使用しないのではないか

equalsメソッドをオーバーライドするときに気をつけよう！

そもそもオブジェクトをキーにHashマップを作成する場面があまり想像できない

hash値を算出するにあたって「31」を使用するべきらしい

偶数だと乗算がオーバーフローしたときに情報が失われる？みたい

https://www.thekingsmuseum.info/entry/2015/08/28/000748

https://computinglife.wordpress.com/2008/11/20/why-do-hash-functions-use-prime-numbers/

項目10 toStringを常にオーバーライドする

デフォルトだと「クラス名@ハッシュコード」

一般的にユーザが見てもなんのメリットもない情報

返される文字列は「簡潔だが、人が読みやすくなっている有益な表現」であるべき！

実用的な場合には、toStringメソッドはオブジェクトに含まれる興味のある情報をすべて！！返すべき！

なお、返却する値の説明はJavadocコメントに記載すべき！

フィールド値をすべて出力したい際は、

commmons.langのToStringBuilder#reflectionToString(Object object)を使ってもよいのでは？

パフォーマンスが懸念...

どのくらい遅くてどんなデメリットがあるのか別途検証したい！

項目11　cloneを注意してオーバーライドする

cloneメソッドはObjectクラスで実装されている

Cloneableインターフェース自体は空である。

Cloneableインターフェースを実装しないと、cloneメソッド呼び出し時に

CloneNotSupportedExceptionがスローされる

Cloneableインターフェースを実装しているクラスは、適切に機能する、publicかprotectedのCloneメソッドを提供すべき

返却されるオブジェクトは自クラスにキャストすべき

x.clone () != x が true であり、

x.clone().getClass() == x.getClass() も true であるインスタンスを生成すること。

ただし、これらの項目は絶対的なものではなく、

x.clone().equals(x) は通常 true である。

ObjectクラスはJavaのNativeソースでCloneableの実装をしているみたい

http://stackoverflow.com/questions/12032292/is-it-possible-to-find-source-for-java-native-method

少し消化不良なので再確認

項目12　Comparableの実装を検討する

ソートしたい場合に検討

Comparableインターフェース compareToメソッドを実装する

自分自身が渡されたオブジェクトより小さければ負の値を返す

自分自身が渡されたオブジェクトより大きければ正の値を返す

自分自身が渡されたオブジェクトと等しければ 0 を返す

ので、こちらを順序だてて実装

ただ、実装クラスを拡張する場合は、継承ではなく移譲すること

補足

Comparatorインターフェースを実装することで並び替えを実現することもできる

違い

Comparableインターフェース：自クラスに実装

Comparatorインターフェース：他クラスに実装

Comparatorが比較処理を外だしできていい感じに思えるが、クラス作成するのが面倒。。

JavaSE8から、「Comparator.comparingメソッド」が使えるようになったので、キー項目を単純にソートするだけならラムダ式でスマートに実装可能

http://totech.hateblo.jp/entry/2017/01/10/123602

第４章　クラスとインタフェース

項目13　クラスとメンバーへのアクセス可能性を最小限にする

うまい設計と下手な設計の違い

どの程度内部データと実装の詳細を隠蔽しているか

情報隠蔽またはカプセル化と呼ばれる

ソフトウェアの再利用を促進

大規模システム構築の場合のリスク軽減

システムが成功しなくても、個々のモジュールとしては成功するかもしれません

各クラスやメンバーをできる限りアクセスできないようにするべき

メソッドをオーバーライドする際は、スーパークラスが実装しているメソッドより、広い範囲のアクセス修飾子を指定しないといけない

インターフェース内のすべてのメソッドは暗黙にpublic

インターフェースを実装するクラスは、オーバーライド時、絶対にpublicを指定しないと行けない

インスタンスフィールドは決して、publicにしては行けない

publicの可変フィールドを持つクラスはスレッドセーフではない！

スレッドセーフ関連について深く理解できていないので再確認

public static finalで可変オブジェクトを格納しているソースはありえない。しては行けない。

そのフィールドに入る値の不変性を保証できなくなる

配列をfinalで宣言しても変更できないのは配列のインスタンスであり、配列の要素を変更することは可能

リストやマップも通常finalで宣言しても変更可能

unmodifiableListを使わなければならない

https://www.sejuku.net/blog/20977

セキュリティホールになりうる例として紹介されている

項目14　publicのクラスでは、publicのフィールドではなく、アクセッサーメソッドを使う

セッターゲッタの話

publicなクラスの場合、フィールドをpublicで公開すると、

その内部的な表現を永久に変更できなくなる

クラスがパッケージプライベートかprivateのネストしたクラスならpublicにすることは本質的に問題ない

Javaライブラリーでいくつかのクラスはこの提言を無視している

Java.awtのPointクラスやDimensionクラス

フィールドが不変な場合、publicとして公開することは、害が少ないが、一般的にはゲッターとセッターを提供すべき

項目15　可変性を最小限にする

クラスを不変にするための５つの原則

１・オブジェクトの状態を変更するためのいかなるメソッドも提供しない

２．クラスが拡張できないことを保証する。

finalでクラスを定義

３．すべてのフィールドをfinalにする。

４．すべてのフィールドをprivateにする。

５．可変コンポーネントに対する独占的アクセスを保証する

クラスが可変オブジェクトを参照しているフィールドを持っている場合、クライアントが参照できないことを保証すること

この項目で言いたいことを掘り下げれてないのであとで見返す

項目16　継承よりコンポジションを選ぶ

継承はコードを再利用するための強力な方法

不適切に使用されると継承はもろいソフトウェアを作り出します

パッケージをまたがって普通の具象クラスから継承することは危険

ここでいう継承は実装継承を意味します

クラスがインターフェースを実装した場合や、

インターフェースが他のインターフェースを拡張した場合のインターフェース継承には適用しない

メソッド呼び出しと異なり、継承はカプセル化をやぶる

スーパークラスに変更があった場合、サブクラスは一緒に変更しなければ行けない可能性がある

HashSetを継承して、addメソッドが呼び出された回数をカウントするサブクラスを作成する

add時にカウントアップ

addAll時に、引数のサイズ分カウントアップしようとするが、HashSetクラスが内部的に

addAllメソッドの中でaddメソッドを呼び出しているので、２重カウントとなってしまう

このサブクラスはHashSetの実装に依存しており、脆いクラスになっていると言える

スーパークラスのメソッド追加も、サブクラスの実装メソッドと同じシグニチャで、戻り値が異なる場合、

サブクラスはコンパイルできなくなる

propertiesクラスの例

結論

継承はなるべく使わないようにしよう

経験則、Javaでバッチ処理を実装する際、ログを残すための設定、基本となる設定ファイルを読み込み値の保持をスーパークラスでやっているロジックをみたことがあるが、そういう場合は継承は効果的なのかもしれない。（処理をがつがつ書いているスーパークラスじゃないから）

項目17　継承のために設計および文書化する、でなければ継承を禁止する

クラスはオーバーライド可能なメソッドの事故利用を文書化しないと行けない

自己利用(self-use)の文書化

継承は慎重に

カプセル化を破壊する可能性がある

咀嚼しきれてないので再度見直す

項目18　抽象クラスよりインタフェースを選ぶ

複数の実装を許す型を定義するために

抽象クラスとインターフェースを定義している

違いは、抽象クラスはいくつかの実装を含むことが許されていて、インターフェースは許されていないこと

抽象クラスで定義された型を実装するためには、クラスはその抽象クラスのサブクラスでなければならない

複数のインターフェースを混ぜ合わせて実装することをミックスインという

このミックスインはインターフェースのみ許されていて、抽象クラスでは多重継承が許されていないため実現できない

P92の組み合わせ爆弾について不明

なんで抽象クラスではなく、インターフェースじゃないとだめなのか、具体的なデメリットが確立できていないので再確認が必要

以下に調査を書いていたが結論でてない

https://www.thekingsmuseum.info/entry/2015/09/26/165815

項目19　型を定義するためだけにインタフェースを使用する

インターフェースを実装するということは、そのクラスのインスタンスは何ができるかについて述べているべき

定数インターフェースはこの限りでない。定数管理にインターフェースを使うのはよろしくない

Javaのライブラリーにはjava.io.ObjectStreamConstantsなどの定数インターフェースがあるが、真似すべきではない！

定数を提供する場合、

クラスやインターフェースと強く結びついているならば、IntegerやFloatなどのように定数を提供

定数が列挙型のメンバーとしてみなされるべきなら、Enum型で提供すべき

そうでなければインスタンス化不可能なユーティリティクラスで定数を提供すべき

項目20　タグ付クラスよりクラス階層を選ぶ

タグ付きクラスは冗長で誤りやすく、非効率

タグ付きクラス：インスタンスが２以上の特性を持っていて、その特性を示すためのタグフィールドを持ったクラスのこと

円と四角形を表現したいと思い、２種類のタグ属性をフィールドに保持したクラス

コンストラクタでオブジェクト生成時に、生成しようとしているオブジェクトはどちらのタグに当たるのかを判断して、

フィールドに保持する。

タグ付きクラスを使用する事によるデメリット

一方のタグでは使わない、不要なフィールドにより、メモリ領域を抱えることになる

処理にswitchを用いる事になり、タグが増加した場合の修正が大変

タグフィールドを持つクラスを書きたくなったら、そのタグを取り除いてクラス階層で置き換えられないかを考えてください

タグフィールドを持つクラスに出くわしたら、クラス階層になるようにリファクタリングできないか検討してください

腑に落ちた。タグ付きクラスは設計しないようにする。できるだけ継承関係（階層）で表現する

項目21　戦略を表現するために関数オブジェクトを使用する

関数ポインタの主な使用方法は、戦略パターンを実装すること

戦略を表すインターフェースと、個々の具象戦略に関してそのインターフェースを実装しているクラスを宣言

具象クラスが１度しか使用されない場合はそのクラスは一般には無名クラスを使用して宣言及びインスタンス化すべき

繰り返し使用される場合は、そのクラスは一般的にprivate staticのメンバークラスであり、戦略インターフェースの型を持つpublic static finalのフィールドを通して提供されます

インターフェースを実装したフィールドを持たないステートレスなクラスを定義することは有用

ステートレスなクラスは、シングルトンで設計すべき、メモリ節約

項目22　非staticのメンバークラスよりstaticのメンバークラスを選ぶ

ネストしたクラスは、他のクラス内に定義されたクラスのこと

ネストしたクラスは、そのエンクロージングクラスに対して仕えるためだけに存在すべき

ネストクラスとしては以下の４種類がある

staticのメンバークラス

非staticのメンバークラス（内部クラス）

無名クラス（内部クラス）

ローカルクラス（内部クラス）

非staticな内部クラスはエンクロージングクラスへの参照を持っているので、

参照する必要がなければ、staticなメンバークラスを定義するべき

第５章　ジェネリックス

項目23　新たなコードで原型を使用しない

原型の使用は実行時例外の可能性があるため、使用しないこと
ジェネリクスが提供されるコードとの互換性を保つためだけに、原型の使用がサポートされている
原型のまま使用することは可能であるが、できる限りやめたほうが懸命

ジェネリクスの安全性と表現力をすべて失うことになる

    結論
    ジェネリクスの型を使用するとコンパイル時に誤りに気づくことができ、メリットのほうが多いため、
    必ず型宣言すること。

項目24　無検査警告を取り除く

- 無検査キャスト警告
- 無検査メソッド呼び出し警告
- 無検査ジェネリック配列生成警告
- 無検査変換警告

このような警告を放置しているソースを見るが、取り除くことが可能なすべての無検査警告は取り除いたほうがよい

もし、警告を起こしているコードが型安全だｓと明確に示すことができれば、そのときに限って

@SuppressWarnings("unchecked")アノテーションで警告を抑止してください

安全だとわかっているのに警告を放置するのもだめだし、安全じゃない警告も取り除くべき

SuppressWarningアノテーションを使用する際はできる限り最小のスコープで使用するべき

広範囲につけることも可能だが、意図せぬ警告を抑止してしまう可能性があるため

■まとめ

無検査警告は重要、無視しないでください
すべての無検査警告は実行時の ClassCastExceptionの可能性があることを表しています
コードが安全だと明確に示せるのであれば、最小スコープで@SuppressWarningアノテーションで警告を抑止してください
警告を抑止するときは抑止した理由をコメントで残してください

項目25　配列よりリストを選ぶ

配列は２つの重要な点でジェネリック型と異なる

[１]. 配列は共変　SubがSuperのサブタイプである場合、配列型Sub[]がSuper[]のサブタイプだということ

実行時にわかるよりコンパイル時にエラーになることがわかったほうがよい

// 実行時に失敗する
Object[] objectArray = new Long[1];
objectArray[0] = "I don't fit in"; // ArrayStoreExceptionがスローされる

/**しかし、次のコードは許されていない **/

// コンパイルされない！
List<Object> ol = new ArrayList<Long>();
ol.add("I don't fit in");

[２]. 配列は具象化されている

ジェネリックはイレイジャ（erasure）で実装されているのでコンパイル時のみ型制約を強制し、
実行時には要素の型情報を廃棄（すなわちイレイズ）することを意味している

これらの基本的な相違点により、配列とジェネリックスはうまく調和しません。

ジェネリック配列の生成は、型安全ではないから許されていない

もし許されていると、他の正しいプログラム内にコンパイラが生成したキャストが、実行時にClassCastExceptionで失敗することになる

これは、ジェネリック型システムが提供している、基本的な保証を破ることになる

この２つを調和させることは難しいので、設計する際は配列ではなく、リストを使用する

項目26　ジェネリック型を使用する

ジェネリック型はクライアントのコードでキャストが必要である型より、安全で使いやすい

新たな型を設計する場合、クライアントのコードでキャストが不要であることを確認してください

たいていの場合、型はジェネリックにすることを意味している

時間が許せば、既存の型をジェネリック化してください

そうすることで、既存のクライアントヲ動作させたまま、それらの型の新たなユーザをもっと楽にしてくれます

※再確認項目

項目27　ジェネリックメソッドを使用する

※再確認項目

項目28　APIの柔軟性向上のために境界ワイルドカードを使用する

ジェネリック型は本来であれば、継承関係問わずすべて一致していないと行けない

PECS　Producer Extends Consumer Super

APIの型を柔軟にしてくれる

※再確認項目

項目29　型安全な異種コンテナーを検討する

※再確認項目

第６章　enumとアノテーション

Java1.5より以下が追加された

Enum型（あらたな種類のクラス）
アノテーション型（新たな種類のインターフェース）

これらを活用する方法を紹介

項目30　int定数の代わりにenumを使用する

理解度：★★★★☆

int定数に対するenum型の利点は、否定できるものではなく、はるかに読みやすく、安全であり、強力

多くのEnum：明示的なコンストラクタやメンバを必要としない

他の多く：各定数にデータを関連付けたり、そのデータに依存して振る舞いが変わるメソッドを提供

自分自身の値によってswitchを実装するよりは、abstractメソッドを実装するように強制したほうがよい

複数のenum定数が共通の振る舞いヲ共有する場合は、abstractメソッドではなく、戦略enumパターンを検討するほうがよい

項目31　序数の代わりにインスタンスフィールドを使用する

理解度：★★★★★

ordinalメソッドが提供されているが、それはEnumSetやEnumMapなどの汎用のenumに基づくデータ構造によりしようされるように設計されているため、そのようなデータ構造を書いているのでなければ、ordinalメソッドは全く使用しないことが最善

フィールドに序数を関連付けたいときは、コンストラクタ引数を渡してインスタンスフィールドに保持すること！！

項目32　ビットフィールドの代わりにEnumSetを使用する

理解度：★★★★☆

ビットフィールドを用いた実装方法

public class Text {
    public static final int STYLE_BOLD   = 1 << 0; // 1
    public static final int STYLE_ITALIC = 1 << 1; // 2
    public static final int STYLE_UNDERLINE = 1 << 2; // 4
    public static final int STYLE_STRIKETHROUGH = 1 << 3; // 8

    public void applyStyles(int styles) {
        ...
    }
}

// 利用
text.applyStyles(STYLE_BOLD | STYLE_ITALIC);

定数の集合を引き回す必要がある場合にビットフィールドを使用することに固執している人もいる

デメリット
- int num定数のすべての短所を持っている（コンパイルされるとクラスに入り込む・名前空間がない）
- 数値として表示された場合は解釈が困難
- ビットフィールドすべてをイテレートする簡単な方法も存在しない

良い例）

// EnumSet - a modern replacement for bit fields (Page 170)
public class Text {
    public enum Style {BOLD, ITALIC, UNDERLINE, STRIKETHROUGH}

    // Any Set could be passed in, but EnumSet is clearly best
    public void applyStyles(Set<Style> styles) {
        System.out.printf("Applying styles %s to text%n",
                Objects.requireNonNull(styles));
    }

    // Sample use
    public static void main(String[] args) {
        Text text = new Text();
        text.applyStyles(EnumSet.of(Style.BOLD, Style.ITALIC));
    }
}

まとめ
- 列挙型が集合の中で使用されるというだけで、それをビットフィールドで表現する理由はない
- 短所としては、不変なEnumSetが生成できないことですが、1.6移行のリリースで改善できるだろう
- EnumSetをCollections.unmodifiableSetで包むことで対応可能
考察
- 不変のEnumSetはJava8でも追加されていない

項目33　序数インデックスの代わりにEnumMapを使用する

理解度：★★☆☆☆

相転移マップを作成する際の例

固体、液体、気体　の状態遷移

まとめ
- 配列インデックスのために序数を使用することが適切であることはめったにない
- 代わりにEnumMapを使用すること
- 表現使用している関係が多次元なら、EnumMap<..., EnumMap<...>>を使用してください

項目34　拡張可能なenumをインタフェースで模倣する

理解度：★★★☆☆

項目２９の境界型トークンと境界ワイルドカード型らへんが理解できていないので再確認

まとめ
- 拡張可能なEnum型を書くことはできませんが、基本のenum型に伴うインターフェースを書いて、そのインターフェースをその基本のenum型に実装させることで模倣できる
- そのインターフェースを実装している独自のenum型を実装させることができる

項目35　命名パターンよりアノテーションを選ぶ

理解度：★★★★☆

命名パターンとは
- testで始まるメソッドをテスト対象として抽出する、、、みたいなルールをつけておくこと
  - これは簡単に破られる、実行時まで気づかない、下手すると実行時も気づかず、正常終了したと思いこむ
アノテーションを使えば、アノテーションが付与されているものを抽出することが可能
まとめ
- 今はアノテーションが提供されているので命名パターンを使うのは避けること
標準提供のアノテーション例
- Override
- Deprecated
- SuppressWarnings

項目36　常にOverrideアノテーションを使用する

理解度：★★★★★

常にOverrideすること

問題のあるプログラム

package effectivejava.chapter6.item40;
import java.util.*;

// Can you spot the bug? (Page 188)
public class Bigram {
    private final char first;
    private final char second;

    public Bigram(char first, char second) {
        this.first  = first;
        this.second = second;
    }

    public boolean equals(Bigram b) {
        return b.first == first && b.second == second;
    }

    public int hashCode() {
        return 31 * first + second;
    }

    public static void main(String[] args) {
        Set<Bigram> s = new HashSet<>();
        for (int i = 0; i < 10; i++)
            for (char ch = 'a'; ch <= 'z'; ch++)
                s.add(new Bigram(ch, ch));
        System.out.println(s.size());
    }
}

eqalsメソッドのシグニチャがObjectではないため、オーバーライドではなく、オーバーロードになってしまっている

このことにプログラマは気づけない

常に@Overrideをつけることでこれを回避できる

package effectivejava.chapter6.item40;

import java.util.HashSet;
import java.util.Set;

// Fixed Bigram class (Page 189)
public class Bigram2 {
    private final char first;
    private final char second;

    public Bigram2(char first, char second) {
        this.first  = first;
        this.second = second;
    }

    @Override public boolean equals(Object o) {
        if (!(o instanceof Bigram2))
            return false;
        Bigram2 b = (Bigram2) o;
        return b.first == first && b.second == second;
    }

    public int hashCode() {
        return 31 * first + second;
    }

    public static void main(String[] args) {
        Set<Bigram2> s = new HashSet<>();
        for (int i = 0; i < 10; i++)
            for (char ch = 'a'; ch <= 'z'; ch++)
                s.add(new Bigram2(ch, ch));
        System.out.println(s.size());
    }
}

HashSetに格納しており、全てすべて異なるオブジェクトと判断されて、結果に誤りが生じているが、正しくequalsメソッドをオーバーライドすることで回避

例外
- 抽象クラスの抽象メソッドを実装するときは、実装していないことをコンパイラが警告してくれるので@overrideを記載しなくても大丈夫。記載して問題ない
まとめ
- スーパータイプの宣言をオーバーライドしているすべてのメソッド宣言にOverrideアノテーションを使用することでコンパイラは多くの誤りを指摘してくれる
- 具象クラスでは、抽象メソッド宣言をオーバーライドしているメソッドにアノテーションをつける必要はない

項目37　型を定義するためにマーカーインタフェースを使用する

理解度：★★★★☆

マーカーインターフェース
- メソッド宣言を１つももたいないインターフェース
- そのインターフェースを実装しているクラスがなにか特別な性質を持っていることを示す
- マークされたクラスのインスタンスが実装している型を定義することに意味を持っている
- 指摘：Serializableインターフェースを活用しなかった、ObjectOutputStream.write(Object)への指摘
マーカーアノテーション
- 型定義はしていない
- 何らかの特性を示すためのアノテーション
- アノテーション自体がメタデータを示すものなので、アノテーション全部がマーカーの役割を担っている
どちらを使うか決める方法
- クラスやインターフェース以外のプログラム要素に対してマーカーが適用されるのであれば「マーカーアノテーション」
- このマークを持つオブジェクトだけを受け付ける１個以上のメソッドを書きたいのであれば「マーカーインターフェース」　Serializableト同じ用法
- このマーカーの使用を特定のインターフェースの要素に永久に制限したい「マーカーインターフェースのサブインターフェースで使用」
まとめ
- マーカーインターフェースの使用を最初に検討
- 使用できないのであれば、マーカーアノテーションを使用する

第７章メソッド

この章について
- メソッド設計の側面について議論
- パラメータと戻り値をどの様に扱うか
- メソッドのシグニチャをどの様に設計するか
- メソッドをどの様に文書化するか
- 多くは、メソッドだけでなく、コンストラクタにも適用される
- 本章は利便性、頑強性、柔軟性に焦点を当てている

項目38　パラメータの正当性を検査する

理解度：★★★★☆

ほとんどのメソッド、コンストラクタはパラメータとして渡される値に関して、何らかの制約を持っている

Nullであっては行けない、負の値であっては行けないとか

このような制約は明確に文書化すべきであり、メソッド本体のはじめに検査することで制約を強制すべき

そうしないと、予想外の場所でエラーになり原因特定が困難になる

パラメタの検査をメソッドがしないと発生する問題
- メソッドが処理の途中でわけのわからない例外で失敗する
- メソッドは正常に終了するが、何も言わずに誤った結果を計算する
- いくつかのオブジェクトを不正な状態にして、あとになって全くコードと関係のないところでエラーを引き起こす

publicのメソッドに対しては、パラメータ値に関する制約が守られていない場合にスローされる例外を、Javadocの@throwsタグを使用して文書化すべき（項目６４）

アサート定義について

通常の正当性検査とは異なり、アサーションは条件が成り立たなければAssertionErrorをスローします。通常の正当性検査とは異なり、javaのインタプリタに-ea（あるいは、-enableassertions）を渡してアサーションを有効にしない限り、アサーションはなんの効果もなく基本的にコストは発生しません。

まとめ
- メソッド、コンストラクタを書く場合は、その都度、そのパラメータにどのような制約が存在するのか考えるべき
- それらの制約を文書化すべきだし、メソッド本体のはじめで、明示的に検査することで制約を強制すべき
- このような習慣を身につけることが大事
- この地道な作業は、正当性検査に初めて引っかかったときに報われます

項目39　必要な場合には、防御的にコピーする

Java言語は安全な言語

CやC++などの安全で内言語に感染するバッファーオーバーラン、配列オーバーラン、でたらめなポインタ、他のメモリ破壊エラーなどに対して、Java言語には免疫がある

これはメモリをすべて１つの巨大な配列として扱っている言語では不可能です

たとえ安全であっても、自分の方で何かしらの努力をしなければ他のクラスから防御されない

「クラスのクライアントは、クラスの不変式を破壊するために徹底した努力をすると想定して防御的にプログラムしなければなりません。」＝壊される想定で防御していかなければならない

あなたのプログラムを利用する、プログラマーの単純な間違いに対処するためにも、防御が必要

攻撃の可能性例)

package effectivejava.chapter8.item50;
import java.util.*;

// Broken "immutable" time period class (Pages 231-3)
public final class Period {
    private final Date start;
    private final Date end;

    /**
     * @param  start the beginning of the period
     * @param  end the end of the period; must not precede start
     * @throws IllegalArgumentException if start is after end
     * @throws NullPointerException if start or end is null
     */
    public Period(Date start, Date end) {
        if (start.compareTo(end) > 0)
            throw new IllegalArgumentException(
                    start + " after " + end);
        this.start = start;
        this.end   = end;
    }

    public Date start() {
        return start;
    }
    public Date end() {
        return end;
    }

    public String toString() {
        return start + " - " + end;
    }

//    // Repaired constructor - makes defensive copies of parameters (Page 232)
//    public Period(Date start, Date end) {
//        this.start = new Date(start.getTime());
//        this.end   = new Date(end.getTime());
//
//        if (this.start.compareTo(this.end) > 0)
//            throw new IllegalArgumentException(
//                    this.start + " after " + this.end);
//    }
//
//    // Repaired accessors - make defensive copies of internal fields (Page 233)
//    public Date start() {
//        return new Date(start.getTime());
//    }
//
//    public Date end() {
//        return new Date(end.getTime());
//    }

    // Remainder omitted
}

コンストラクタにオブジェクトを渡して、コンストラクタ側でメンバー変数として保持する場合、コンストラクタ内で新たにnewして（防御的にコピーして）メンバー変数に保持しなければならない

これを利用した攻撃を、コンピュータセキュリティのコミッティではtime-of-check/time-of-use攻撃と呼ばれている（TOCTOU攻撃）

まとめ
- クラスがそのクライアントから得たり、クライアントへ返したりする可変の要素を持っているならば、そのクラスはそれらの要素を防御的にコピーしなければならない
- もしコピーのコストが非常に高く、要素を不適切に変更しないということをでクラスがクライアントを信頼できるならば、影響を受ける要素を変更しないことがクライアントの責任であるとドキュメンテーションに概要を示すことで、防御的コピーの代わりとしても良いです。
パフォーマンス懸念について調査
- ArrayListのデフォルトコンストラクタで生成されるインスタンスのデータ容量は１０であり、大量データをAddすることが確定している場合は最初からサイズ指定してコンストラクタを使うべき
  - 参考）「Javaでプログラムを書く際に意識しておきたいこと」https://blog.y-yuki.net/entry/2017/06/07/130000

項目40　メソッドのシグニチャを注意深く設計する

理解度：★★★☆☆

本項目はAPI設計のヒントを集めたもの

メソッド名を注意深く選ぶ
- 標準命名規約（項目５６）に従うべき
- 目標：理解可能で、同じパッケージ内の他の名前と矛盾のない名前を選ぶこと
- 目標：存在する広範囲のコンセンサス（合致、合意）と矛盾がない名前を選ぶこと
  - 疑問がある場合はガイダンスとして、JavaライブラリのAPIを参考にしてください、矛盾が沢山ありますが、大きさと範囲を考えると避けられない矛盾。
  - かなりのコンセンサスがあることに注目してほしい
便利なメソッドを提供しすぎない
- 自分の役割を果たすべき
- 頻繁に使用される場合だけ、ある操作に対する速記（shorthand）を提供することを検討すること
長いパラメタのリストは避ける（４個以下を目標にする）
- ほとんどのプログラマは長いパラメータリストを覚えられない
- 同じ型のパラメータが何個も続くのは特に有害
- 長いパラメータを短くする方法
  - 1.メソッドを分割して、各メソッドはパラメータのサブセットだけを必要とする
  - 2.パラメータの集まりを保持するヘルパークラスを作成する（Staticのメンバークラス）（項目２２）
  - 3.ビルダーパターンをオブジェクト生成からメソッド呼び出しに適用すること
パラメータ型に関しては、クラスよりインターフェースを選ぶ（項目５２）
- HashMapパラメタに取るメソッドを作成する理由はなくて、Map型で定義しておく
- そうすれば、Hashtable、HashMap、TreeMapどれでも渡すことが可能となる
booleanパラメータより２つの要素を持つenum型を使用する。

public enum TemperatureScale { FAHRENHEIT, CELSIUS }

Thermometer.newInstatnce(true);

// より

Thermometer.newInstance(TemperatureScale.CELSIUS);

// のほうが分かりやすい
// TemperatureScaleに　KELVIN　を追加することも可能

項目41　オーバーロードを注意して使用する

理解度：★★★☆☆

// 不完全！　このプログラムは何を表示するでしょうか

package effectivejava.chapter8.item52;
import java.util.*;
import java.math.*;

// Broken! - What does this program print?  (Page 238)
public class CollectionClassifier {
    public static String classify(Set<?> s) {
        return "Set";
    }

    public static String classify(List<?> lst) {
        return "List";
    }

    public static String classify(Collection<?> c) {
        return "Unknown Collection";
    }

    public static void main(String[] args) {
        Collection<?>[] collections = {
                new HashSet<String>(),
                new ArrayList<BigInteger>(),
                new HashMap<String, String>().values()
        };

        for (Collection<?> c : collections)
            System.out.println(classify(c));
    }
}

// Unknown Collection　を３回表示することになる

まとめ
- オーバーロードできるからと言ってオーバーロードスべきではない
- 一般的には、同じ数のパラメータを持つ複数のシグニチャでメソッドをオーバーロードすることは控えるべき
  - 場合によっては、コンストラクタが関与すると従えない可能性もある..
  - そうなっても、キャストによって同じ組み合わせを異なるオーバーロードされたメソッドにわたすことができる状況は避けるべき
  - 避けられない場合は、オーバーロードされたメソッドが同じふるまいをすることを保証すべき

項目42　可変長引数を注意して使用する

理解度：★★★☆☆

可変長引数メソッド
- リリース1.5で言語に追加された
- ０個以上の引数を受け付ける

可変長引数のあたいは配列として初期化される

Java1.4の場合
- 基本型配列はArrays.toList(Object[] obj)メソッドの引数にとれない
- 渡すと、コンパイルエラーになる
Java1.5の場合
- コンパイルエラーにならない。しかし、、
- 配列はObject型のtoStringメソッドを継承しているので、呼び出すと、ハッシュ値が出力され、値が見れない
- 解決方法は Arrays.toString()メソッドを使用すること
まとめ
- 可変長引数メソッドは、可変長の引数を必要とするメソッドを定義する便利な方法だが乱用すべきではない
- 不適切に使用すると可変長引数メソッドは困惑する可能性がある

項目43　nullではなく、空配列か空コレクションを返す

メッソドの戻り値（オブジェクト）がnullかどうかを判定するロジックを見たことがありますか？

空（長さゼロ）配列や空コレクションの代わりに、nullを返すメソッドを使用する場合には必ず書かなければ行けない

クライアント側を書いているプログラマは戻り値nullを処理する特別なコードを書き忘れてしまう危険性がある

配列を生成するコストを回避できると主張されることもあるが、次の２点を理由に間違いだと言える
- 1.問題となっているメソッドがパフォーマンス上、本当の原因で有ることがプロファイリングにより示されない限り、ネックと言えない
- 2.項目を１つも返さない呼び出しすべてが、同一の長さゼロ配列を返すことが可能
  - 長さゼロ配列は不変であり、不変オブジェクトは制限なく共有して問題ないため

// コレクションから配列を返す正しい方法
private final List<Cheese> cheesesInStock = ...; // ここが空であれば、常に同じから配列が返却される仕組みを作れる

private static final Cheese[] EMPTY_CHEESE_ARRAY = new Cheese[0];

/**
* @return 店にあるすべてのチーズを含む配列
*/
public Cheese[] getCheeses() {
  return cheeseInStock.toArray(EMPTY_CHEESE_ARRAY);
}

// ドキュメント
// https://docs.oracle.com/javase/jp/8/docs/api/java/util/List.html#toArray-T:A-

// コレクションのコピーを返す正しい方法
public List<Cheese> getCheeseList() {
  if (cheeseInStock.isEmpty())
    return Collections.emptyList(); // 常に同一のリストを返す
  else 
    return new ArrayList<Cheese>(cheeseInStock);
}

// Collections.emptyList()のドキュメントは以下
// https://docs.oracle.com/javase/jp/8/docs/api/java/util/Collections.html#emptyList--

まとめ
- 配列やコレクションを返すメソッドが、空配列や空コレクションの代わりに、nullを返すべき理由は決してありません。

項目44　すべての公開API要素に対してドキュメントコメントを書く

APIを適切に文書化するためには、すべての公開されているクラス、インターフェース、コンストラクタ、メソッド、フィールド宣言の前にドキュメントコメントを書かなければなりません。
メソッドに関するドキュメントコメントは、メソッドとそのクライアント間の契約を簡潔に記述すべき
- メソッドが何を行っているかを記載するべき
- メソッドのすべての事前条件、事後条件を列挙すべき
  - 事前条件：@param　（引数の説明）　に記載する
  - 事後条件：@throws に記載する

↑この部分、書籍の記載不備だと思われ、咀嚼できていない

メソッドはいかなる副作用も文書化すべき
- たとえば、メソッドがバックグラウンドのスレッドを開始するとしたら、明記すべき
ドキュメンテーションガイド
- 公式）https://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
- Qiita）https://qiita.com/maku77/items/6410c67ce95e08d8d1bd
まとめ
- ドキュメンテーションコメントはAPIを標準化する最善で最も効率的な方法
- すべての公開APIでドキュメンテーションコメントは必須だとみなされるべき
- 標準に沿って記載されるべきで、メタタグはエスケープされるべき

第８章　プログラミング一般

項目45　ローカル変数のスコープを最小限にする

ローカル変数のスコープを最小限にする最も強力な方法は、ローカル変数が使用される前に宣言されること
ローカル変数は、初期化子を含んでいるべき
ループ変数の内容が、ループが終了したあとに必要ないものであれば、whileループよりforループを選択スべき
forループであれば、２つのループで異なった変数名を使用する理由はありませんので、コピペによる誤りを犯すことはない（コンパイルエラーになるから）
まとめ
- ローカル変数のスコープを最小限にすること
  - 変数使用前に宣言すること
  - whileよりforループをうまく活用すること
  - メソッドを切り分けてスコープを制御すること

項目46　従来のforループよりfor-eachループを選ぶ

for-eachループ＝拡張for文のことを言っている

// コレクションと配列をいてレートするための好ましいイデオム
for (Element e : elements) {
  doSomething(e);
}

for文がネストする際はなおさら、拡張For文の恩恵を受けられる
for-eachループにより、コレクションと配列に対してイテレートできるだけでなく、Iterableインターフェースを実装した、いかなるオブジェクトに対してもイテレートできる
利用できる場面であるならば利用するべき
利用できない場面については以下の通り
- 1.フィルタリング：選択された要素を削除する必要がある場合
- 2.変換：リストや配列をイテレートして、その要素のいくつかを変換、置換する場合
- 3.並列イテレーション

これらのケースに該当する場合は、通常のfor文を使用して、最善の方法で実装しているという認識を持つこと

項目47　ライブラリーを知り、ライブラリーを使う

0からある上限値までの整数の乱数を生成したい時、自分で実装するとうまくいかないケースがある

private static final Random rnd = new Random();

// よく見かけるが、欠陥がある！！
static int random() {
  return Math.abs(rnd.nextInt()) % n;
}

※欠陥の内容については、数学的な内容になるのでここ（今回の学習）では触れない

この機能を実現するためのライブラリーはもう既に提供されています。

Random.nextInt(int);

標準ライブラリを使用することで、それを書いた専門家の知識と、それをあなたよりも前に使用した人々の経験を利用することになる
自分の課題に少しばかりだけ関連している問題に対する場当たり的な解決策を書くことで、時間を無駄にする必要がない。アプリケーションに時間を費やすべき
自分では何もしなくても、時間とともにパフォーマンスが改善されたりする
Java標準ライブラリの中で知っておくべきもの(自分の道具箱に入れておくべきもの)
- java.lang
- java.util(コレクションフレームワーク)
- java.io
- java.util.concurrent
まとめ
- 無駄な努力はしないこと！
- ライブラリーに存在していないか、実装前に確認すること！
- 一般的なライブラリーは、頭の片隅においておくこと！
個人的な心がけ
- あえてライブラリーを実装していない、車輪の再開発実装を見かけたら、ライブラリーを使うとすると...ということを意識しておく

項目48　正確な答えが必要ならば、floatとdoubleを避ける

float型とdouble型は、特に金銭計算には適していない
- 正確に、0.1を表現することが不可能だから
この問題を解くために正しい方法は、金銭計算には、BigDecimal、int、あるいはlongを使用すること
留意事項
- BigDecimalのデメリット
  - 基本データの算術型を使用するよりは不便
  - 処理が遅い
まとめ
- 正確な答えを必要とする計算に、floatやdoubleを使用しないこと！
- BigDecimalの使用を検討する
  - BigDecimalは、小数点を扱っているかいなかという状態の管理と、処理速度が遅いというデメリットを持っている
- 桁数が９桁を超えないのであればintを用いる
- 桁数が１８桁を超えないのであればlongを用いる
- 桁数が１８桁を超えるのであればBigDecimalを用いる

項目49　ボクシングされた基本データより基本データ型を選ぶ

java1.5から、自動ボクシングと自動アンボクシングの機能が追加された

これは基本データ型とボクシングされた基本データ型の違いを不明瞭にしたが、決して同じものと見てはいけない！

３つの違い - 基本データ型は値だけを持つが、ボクシングされた基本データのインスタンスは値とは別のアイデンティティを持っている - 基本データ型は完全に機能する値だけを持っているが、ボクシングされた基本データ型は、機能する値＋nullを持つ - 基本データ型は、ボクシングされた基本データ型より時間と空間に関して効率的
ボクシングされた基本データ型に対して == 演算子を適用するのは、殆どの場合誤り
- オブジェクトの同一性を確認してしまうため
まとめ
- 基本的に基本データ型を使用すること
- 自動ボクシングの機能に依存しないこと
- ボクシングされた基本データ型に対して==演算子を用いることはない
- ボクシングされた基本データ型とアンボクシングされた基本データを含む混合型の計算を行うと、アンボクシングが行われる
  - アンボクシングの際にNullPointerExceptionをスローする可能性がある

項目50　他の型が適切な場所では、文字列を避ける

文字列は、他の値型に対する代替としては貧弱
- データが本質的に文字である場合にだけ文字列として扱うべき
- 「はい/いいえ」の問に対する答えならboolean型
- 数値なら、int float BigInteger
文字列は、列挙型に対する代替としては貧弱
文字列は、集合型に対する代替としては貧弱
- ある実態が複数の構成要素を持っているならば、その集合を示すクラスを定義することが懸命。たいていは private static のメンバークラスを書く
文字列は、ケイパビリティ（capability）に対する代替としては貧弱
- ThreadLocalに関する懸念点について咀嚼できていないので再確認する
まとめ
- 何も考えずに文字列ばかりを使用しないこと
- 基本データ型、enum、集合型が選べないか確認すること
所感
- たまにテーブルで数値、タイムスタンプで持っているのに、Java処理で文字列型として扱っているプログラムを見るが、そのようなプログラムは適切ではないと判断することができるのではないか

項目51　文字列結合のパフォーマンスに用心する

n個の文字列を結合するのに、文字列結合演算子を繰り返し使用すると、nに関して2次の時間を必要としていまいます
- この原因は、文字列が不変(immutable)であるという事実の不幸な結果
- 結合時に両方の内容がコピーされます
許容できるパフォーマンスを達成するためには、Stringの代わりにStringBuilderを使用する
- パフォーマンスの違いは５０倍～８５倍ほど違い
処理速度検証参考
- http://www.code-magagine.com/?p=2022
StringBufferは古い、StringBuilderを使用しましょうと記載があるが、スレッド処理をする場合はStringBuffer１択
上記の検証資料を見るとStringBufferもStringBuilderと速度の大差がない様に思う...
まとめ
- 文字列結合はStringBuilder、またはStringBuilderを用いる
- 繰り返さない、数の少ない結合に関しては+演算子を用いる場合もある
  - 例えば、 LOG.info("処理回数:" + count + "回目") とか局所的に使う場合

項目52　インターフェースでオブジェクトを参照する

適切なインターフェース型が存在するのであれば、パラメータ、戻り値、変数、およびフィールドはすべてインターフェース型を使用して宣言されるべき
型として、インターフェースを使用する癖を身に着けたならば、あなたのプログラムはかなり柔軟になる
注意点
- もとの実装がインターフェースの一般契約で要求されていない何らかの特別な機能を提供していて、コードがその機能に依存しているならば、新たな実装が同じ機能を提供することが重要
適切なインターフェースが存在しない場合には、インターフェースではなく、クラスでオブジェクトを参照することは適切
- 値クラス
- 基本的なデータ型としてインターフェースではなくクラスであるフレームワークに属しているケース
- インターフェースは実装しているが、そのインターフェースにない特別なメソッドをクラスが提供しているケース
まとめ
- 適切なインターフェースが存在する場合はインターフェース型で実装
- 適切なインターフェースが存在しない場合は、クラス改装中で必要な機能を提供しているクラスで実装

項目53　リフレクションよりインタフェースを選ぶ

コアリフレクション機構：java.lang.reflect はロードされたクラスに関する情報へのプログラムによるアクセスを提供している
- Classインスタンスで表されているクラスの、コンストラクタ、メソッド、フィールドを表しているConstructorインスタンス、Methodインスタンス、Fieldインスタンスを取得可能
- さらにこれらを反射的に操作できる
リフレクションはコンパイルされた時点で存在さえしない他のクラスを使用することを可能にする
- コンパイル時の型検査の恩恵をすべて失います
- リフレクションによるアクセスを行うコードは、ぎこちなく、冗長
- パフォーマンスが悪くなる
リフレクションは設計時のみ使用されるべき
- 一般に、実行時に普通のアプリケーション内で、オブジェクトはリフレクションによりアクセスされるべきではない
まとめ
- ある種の洗練されたシステムプログラミング処理に必要とされる強力な機構ですが、多くの短所を持っている
- コンパイル時に知られていないクラスと一緒に動作しなければならないプログラムを書くのであれば、できる限り、オブジェクトのインスタンス化のためだけにリフレクションを使用する
所感
- リフレクションはログ出力時に使用したい
- 実運用では積極的な利用は避けるべきで、ツールとかで使う分であれば問題ない
- 引数にクラス名を渡して、インスタンス化したあとに、スーパークラスやインターフェースに型を当てて使用する分には問題ないことを理解

項目54　ネイティブメソッドを注意して使用する

CやC++などのネイティブのプログラミング言語で書かれた特別なメソッドであるネイティブメソッドをJavaアプリケーションが呼び出すのを可能にするのがJava Native Interface(JNI)
JNIは以前パフォーマンスの改善等で使用されていたが、Java1.4以降のリリースあたりで、Javaで実装しチューニングしたクラスを提供し始めたため、現在あまり使われていない
リリース1.4
- java.util.prefs レジストリの機能
リリース1.6
- java.awt.SyustemTray デスクトップのシステムトレイ領域へのアクセスを提供
古いコードへのアクセスにネイティブメソッドを使用することは正当ですが、パフォーマンスの改善のためにネイティブメソッドを使用することは、全く勧められません。
BigIntegerも最初はCで書かれた高速な多倍精度算術ライブラリーを使用して実装されていた歴史があるが、リリース1.3でJavaに置き換えられて注意深くチューニングされた
まとめ
- パフォマンスの改善のために使用しないこと
- 古いコードへのアクセスで利用する場合は、最小限に留めること
所感
- ネイティブコードをJavaで意図的に使用するコーディングの実装経験がないが、以下で紹介されているようにC++のクラス、メソッドを呼び出しできるんだな程度で理解した
  - http://smys0515.hatenablog.com/entry/2015/05/27/075421
- 実務でネイティブメソッドを使用する場面は今後もないだろう。留意しておく

項目55　注意して最適化する

まとめ
- 早いプログラムを書く努力をしてはいけない、良いプログラムを書く努力をすること
- API設計、通信プロトコル、永続データ形式を設計しているときは、パフォーマンスについて意識すること
- システム構築を終えたあと、パフォーマンス測定し、十分に早ければそれでよい、早くなければプロファイラの力を借りて問題の特定、最適化
所感
- ビジネスレベルでパフォーマンスを意識した最適化をしようと思いすぎないこと
- API設計や、汎用的に使用されるようなクラスを作成する際は、パフォーマンスを意識すること（繰り返し呼び出される必要がある）
  - Javaプロファイラについて調査（jvisualvm）
  - http://www.techscore.com/blog/2017/12/11/identifying_performance_bottlenecks_with_jvisualvm/
  - Eclipse使用時、GUIでメソッドごとに処理時間を一覧できるため便利

項目56　一般的に受け入れられている命名規約を守る

命名規約
- 活字的規約
- 文法的規約
パッケージ名
- ピリオドで区切られた要素をもち、階層的であるべき
- 区切られた要素は小文字のアルファベット文字と稀に数字から構成されるべき
- 組織外で使用されるパッケージの名前は、トップレベルドメインを最初にした、その組織のインターネットドメイン名で始まるべき
  - java,javaxで始まる名前をもつパッケージはこの規約の例外です
- パッケージを記述する１つ以上の要素から構成されるべき、要素は短く一般的に８文字以下であるべき
  - 意味を持った省略形は推奨されている。例えば、utilitiesesよりはutilなど
クラス名、インターフェース名（enum型名、アノテーション型名）
- １つかそれ以上の単語から構成されるべきであり、個々の単語の最初の文字は大文字（パスカルケース）
- メソッド名はキャメルケースにすべき
- 定数フィールドは、大文字＋アンダースコア
まとめ
- 標準の命名規約を取り入れて学習することを意識する
- 長く維持されてきた観葉的な用法が別に定義されている場合、これらの規約に盲目的に従うべきではない
所感
- 命名が適切だと他者に伝わりやすい＋自分でも見返しやすい
- コーディング時に意識する
- 参考）https://qiita.com/rkonno/items/1b30daf83854fecbb814

第９章　例外

最適に使用された場合、例外はプログラムの読みやすさ、信頼性、保守性を改善

不適切に使用された場合、逆効果となる。ここでは例外を効率的に使用するためのガイドラインを定義

項目57　例外的状態にだけ例外を使用する

最悪な例

// 例外のひどい乱用。決して、行ってはならない！！！
try {
  int i = 0;
  while(true) {
    range[i++].climb();
  }
} catch (ArrayIndexOutOfBoundsException e) {
}

/** 
* これを書いた人は、ループ終了検査が冗長で、遅くなるからこうかいた！と
* 主張するかもしれないが、今のJVMは最適化されていて、このように書くほうが遅くなるし
* 何を意味しているのか、読み手が理解し辛い
*/

まとめ
- 例外は例外的状態で使用されるために設計されている
- 通常の制御の流れに対して例外を使用しないでください
所感
- この項目は明白。あるべきタイミングで例外処理を実装すること。例外処理実装のパターンみたいなものに言及されていないが気になる。。。

項目58　回復可能な状態にはチェックされる例外を、プログラミングエラーには実行時例外を使用する

３種類の例外
- チェックされる例外
- チェックされない例外（実行時例外）
- チェックされない例外（エラー）
  - 各例外がいつ使用するのが適切かについてプログラマの間で混乱がある。
呼び出し側が適切に回復できるような状況に対してはチェックされる例外を使用すること
プログラミングエラーを示す場合は実行時例外を使用してください。実行時例外の殆どは事前条件違反を示しています。
実装するすべてのチェックされない例外は、RuntimeExceptionをサブクラス化するべき
Exception,RuntimeException,Errorのサブクラスではない例外を定義することは可能だが、得られるものはないし、ユーザを混乱させるだけなのでやめたほうがよい
まとめ
- 回復可能な状態にはチェックされる例外を使用
- プログラミングエラーには実行時例外を使用

項目59　チェックされる例外を不必要に使用するのを避ける

まとめ
- プログラマがこれ以上どうしようもないのであればチェックしない例外が適切。常にチェックされる例外を実装すべきではない
- チェックされる例外呼び出しをbooleanで定義して呼び分けをする方法もある
  - このリファクタリングが常に適切とは限らないが、リファクタリング前より見やすくなるのはわかると思う
- 項目５７の状態検査メソッドと基本的に同じであり、同じ注意事項が課せられる
  - オブジェクトが外部同期なしに並行してアクセスされたり、外部要因により状態遷移したりするのであれば、このリファクタリングは適切でない
所感
- booleanを使った処理の成功、失敗の振り分けは実装したことあるが、戻り値がほしい場合はチェック例外を書かざるを得ない印象

項目60　標準例外を使用する

ここでは一般的に再利用されている例外について議論する
既存の例外を再利用することのメリット
- APIを学んで使用するのが容易になる
  - プログラマが既に熟知している確立された慣例と一致するから
- プログラムが見慣れない例外でごちゃごちゃしないので読みやすい
- 例外クラスが少ないと、より少ないメモリ量と、クラスロードに費やされる時間が少ない
一般的な例外
- IllegalArgumentException
  - パラメータ値が不適切
- IllegalStateException
  - メソッド呼び出しに対してオブジェクト状態が不正
- NullPointerException
  - パラメータ値が禁止されているnull
- ArrayIndexOutOfBoundsException
  - インデックスパラメータ値が範囲外
- ConcurrentModificationException
  - 禁止されているオブジェクトの並行した変更を検出
- UnsupportedOperationException
  - オブジェクトがメソッドをサポートしていない
まとめ
- 一般的な例外を、実装ケースに合わせて使用すること
所感
- できるなら、個別に例外クラスを実装するような文化を作らないようにする（個別に定義した例外クラスだらけのシステム（独自ライブラリ）を見たことがあるがよくない）
- 一般的な例外クラスを使いこなせる様にする
  - この場合はこの例外を使用するのが最適だと判断できるようにする

項目61　抽象概念に適した例外をスローする

上位レイヤは下位レベルの例外をキャッチして、上位レイヤの中で上位レベルの抽象概念の観点から説明可能な例外をスローすべき
まとめ
- 下位レイヤからの例外を防いだり下位レイヤの例外から上位レイヤを隔離剃ることが実現不可能であり、下位レベルのメソッドがスローするどれかの例外が上位レイヤに対して不適切ならば、例外翻訳を使用すること。
所感
- 例外翻訳は、メソッドで投げられた例外をキャッチして、別の例外をnewして投げ返すこと
- 投げ返すに適切な例外があれば使用すること
- そもそも投げ返すパターンについて整理する必要があるなと感じた

項目62　各メソッドがスローするすべての例外を文書化する

例外がthrowされる条件をjavadocの@throwsタグに明記して、正確に文書化してください
まとめ
- 作成する各メソッドがスローする可能性のあるすべての例外を文書化、チェックされない例外に対しても。また、具象メソッドだけでなく抽象メソッドに対しても
- 個々のチェックされる例外に対してthrows説を提供すること。チェックされない例外はthorows説を提供しないこと
- メソッドがthrowする可能性のある例外を文書化するのを忘れると、他の人がクラスやインターフェースを効果的に利用したりするのが困難だったり、不可能になる
所感
- @thorwsタグに、少なくともチェックされる例外の説明を記載する努力をする
  - どのような原因でその例外が発生するのかなど

項目63　詳細メッセージにエラー記録情報を含める

エラーを記録するためには、例外の文字列表現は、その例外の原因となったすべてのパラメータとフィールドの値を含んでいるべき
所感
- どの様にエラー情報を提供するのかについて言及していないように思える
- 再確認したい項目

項目64　エラーアトミック性に努める

エラーアトミック：一般的にいえば、失敗したメソッド呼び出しは、オブジェクトをそのメソッド呼び出しの前の状態にしておくべき
達成するためのアプローチ
- 不変オブジェクトを設計する
- 可変オブジェクトに対しては
  - 操作を行う前にパラメータの正当性を検査する。そうすることでパラメータの変更を行う前にエラーを投げることができる

public Object poo() {
  if (size == 0) 
    throw new EmptyStackException();
  Object result = elements[--size];
  elements[size] = null; // 廃れた参照を取り除く
  return result;
}

このように、size０のリストに、サイズを確認せずに要素の取り出しを行うと例外がスローされ、sizeフィールドが不整合な負の状態になり、オブジェクトを扱えなくなる

まとめ
- アトミック性をまもることは必須ではない。コスト、煩雑さとを伴うのであれば避ける
- APIドキュメントに、アトミック性を保持できないことを明記するべき
  - 残念ながら、既存のAPIドキュメントの多くはこの規則に従っていない
所感
- そもそもアトミック性を保持しなければならないようなクラスを実装する機会があまりなかった(変化するフィールド（加算/減算/ステータス定義の変化）を持つクラスを使い回すシチュエーションがないような気がする。あっても既存のライブラリクラス。Dateとか)
- バッチ処理等でサービス/ビジネスクラス内に処理回数をインクリメントする変数を定義した場合、変数を加算する前に対象の処理が正常終了しているかどうかを確かめるとか...

項目65　例外を無視しない

例外を無視するのはだめ！
- 火災警報器を無視して警報を切ってしまうのと同じ。誰も火災があるかどうかを知ることができない

try {
    obj.action(args);
} catch (SomeException e) {
}

まとめ
- 例外を無視するべきではない
- 例外を無視しても最低限コメントで説明をするべき

第10章　並行性

スレッドは同一プログラム内で複数の処理を並行して行うことを可能にしている
今日では当たり前になった、マルチコアプロセッサの恩恵を受けるためにも並行処理は必須
本章では明瞭で、正確で、きちんと文書化された並行プログラムを書くのに役立つ助言を含んでいます。

項目66　共有された可変データへのアクセスを同期する

壊れた同期

package effectivejava.chapter11.item78.brokenstopthread;
import java.util.concurrent.*;

// Broken! - How long would you expect this program to run?  (Page 312)
public class StopThread {
    private static boolean stopRequested;

    public static void main(String[] args)
            throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
            int i = 0;
            while (!stopRequested)
                i++;
        });
        backgroundThread.start();

        TimeUnit.SECONDS.sleep(1);
        stopRequested = true;
    }
}

１秒後に、メインスレッドがサブスレッドを終了させると思うかもしれませんが、実際そうならない

問題
- メインスレッドが行ったsropRequestedの値の変更をサブスレッドが検知できないため
以下、修正されたクラス

package effectivejava.chapter11.item78.fixedstopthread1;
import java.util.concurrent.*;

// Properly synchronized cooperative thread termination
public class StopThread {
    private static boolean stopRequested;

    private static synchronized void requestStop() {
        stopRequested = true;
    }

    private static synchronized boolean stopRequested() {
        return stopRequested;
    }

    public static void main(String[] args)
            throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
            int i = 0;
            while (!stopRequested())
                i++;
        });
        backgroundThread.start();

        TimeUnit.SECONDS.sleep(1);
        requestStop();
    }
}

期待通りに１秒でクラスが終了します。

読み込み操作と、書き込み動作の両方が同期されていなければ行けない。同期はなんの効果もない

以下のような書き方もできる

package effectivejava.chapter11.item78.fixedstopthread2;
import java.util.concurrent.*;

// Cooperative thread termination with a volatile field
public class StopThread {
    private static volatile boolean stopRequested;

    public static void main(String[] args)
            throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
            int i = 0;
            while (!stopRequested)
                i++;
        });
        backgroundThread.start();

        TimeUnit.SECONDS.sleep(1);
        stopRequested = true;
    }
}

だが、volatile修飾子では、加算処理などの同期がうまく取れないので、

場合により、AtomicLongを使用すること

// 不完全、動機が必要！
private static volatile int nextSerialNumber = 0;

public static int generateSerialNumber () {
  return nextSerialNumber++;
}

// ++演算子がアトミックではないことが問題　これは安全性エラーです

private static final  AtomicLong nextSerialNumber = new AtomicLong();abstract

public static long generateSerialNumber() {
  return nextSerialNumber.getAndIncrement();
}

まとめ
- 複数のスレッドが可変データを共有する場合には、そのデータを読み書きするスレッドは同期を行わなければなりません。
- スレッド間通信だけが必要で、相互排他が必要なければ、volatile修飾子は同期として受け入れられる形式
  - 正しく使用するのは難しい

項目67　過剰な同期は避ける

項目６６では不十分な同期の危険性を示唆したが、本項目はその逆

活性エラーと安全性エラーを回避するためには、同期されたメソッドやブロック内で決して制御をクライアントに譲ってはいけません。

項目68　スレッドよりエグゼキューターとタクスを選ぶ

項目69　waitとnotifyよりコンカレンシーユーティリティを選ぶ

項目70　スレッド安全性を文書化する

項目71　遅延初期化を注意して使用する

項目72　スレッドスケジューラに依存しない

項目73　スレッドグループを避ける

第11章　シリアライズ

項目74　Serializableを注意して実装する

項目75　カスタムシリアライズ形式の使用を検討する

項目76　防御的にreadObjectを書く

項目77　インスタンス制御に対しては、readResolveよりenum型を選ぶ

項目78　シリアライズされたインスタンスの代わりに、シリアライズ・プロキシを検討する

付録　初版に対応する項目

AccessVBAエキスパート

Mon, 01 Feb 2016 00:00:00 GMT

AccessVBAエキスパート

学習ログ

学んだこと

VBAの基礎構文
Excel版で掲載されていなかった多くのメソッドを学べた
AccessオブジェクトをVBAで扱う方法

手に取った理由

Excelの学習の延長と思い学習することにした

ExcelVBAエキスパート

Fri, 01 Jan 2016 00:00:00 GMT

ExcelVBAエキスパート

学習ログ

学んだこと

VBAの基礎構文
ExcelオブジェクトをVBAで扱う方法

手に取った理由

業務でVBAコードを書ければ自動化できるタスクがあったため、将来的にもExcelは使用していくことを考えて知識が欲しい
簡単なマクロなら数時間で実装できるスキルが欲しい

HTML5デザイン

Fri, 01 Jan 2016 00:00:00 GMT

HTML5デザイン

学んだこと

未読
- 優先度下げてしまってまだ全部読めてない
触りだけ読んだが、必要に迫られたときに持ち寄りたい

手に取った理由

HTML/CSS/JSのデザイン知識を蓄えたい
可能なことについて理解しておきたい

Junit実践入門

Fri, 01 Jan 2016 00:00:00 GMT

Junit実践入門

学んだこと

アサーションメソッド
- 評価する仕組みについて
テストランナー
- Enclosedクラス
- Theoriesクラス
※業務で必要となった箇所だけ拾い読みレベル

手に取った理由

Junitのフレームワークについて理解できていなかったため、体系的な知識を付ける目的で購入

JakartaCommonsクックブック

Fri, 01 Jan 2016 00:00:00 GMT

JakartaCommonsクックブック

学んだこと

未読
- 優先度下げてしまってまだ全部読めてない
触りだけ読んだが、必要に迫られたときに持ち寄りたい

手に取った理由

Commonsのライブラリーを業務で有効活用できておらず、どのようなものがあるか体系的に知りたかった
車輪の再開発反対派

Java言語で学ぶデザインパターン入門

Thu, 01 Oct 2015 00:00:00 GMT

Java言語で学ぶデザインパターン入門

目次
はじめに
UMLについて
デザインパターンを学ぶ前に
デザインパターンに慣れる
- 第1章 Iterator ― 1つ1つ数え上げる
- 第2章 Adapter ― 一皮かぶせて再利用
サブクラスにまかせる
- 第3章 Template Method ― 具体的な処理をサブクラスにまかせる
- 第4章 FactoryMethod ― インスタンス作成をサブクラスにまかせる
インスタンスを作る
- 第5章 Singleton ― たった1つのインスタンス
- 第6章 Prototype ― コピーしてインスタンスを作る
- 第7章 Builder ― 複雑なインスタンスを組み立てる
- 第8章 Abstract Factory ― 関連する部品を組み合わせて製品を作る
分けて考える
- 第9章 Bridge ― 機能の階層と実装の階層を分ける
- 第10章 Strategy ― アルゴリズムをごっそり切り替える
同一視
- 第11章 Composite ― 容器と中身の同一視
- 第12章 Decorator−飾り枠と中身の同一視
構造を渡り歩く
- 第13章 Visitor ― 構造を渡り歩きながら仕事をする
- 第14章 Chain of Responsibility ― 責任のたらい回し
シンプルにする
- 第15章 Facade ― シンプルな窓口
- 第16章 Mediator ― 相手は相談役1人だけ
状態を管理する
- 第17章 Observer ― 状態の変化を通知する
- 第18章 Memento ― 状態を保存する
- 第19章 State ― 状態をクラスとして表現する
無駄をなくす
- 第20章 Flyweight ― 同じものを共有して無駄をなくす
- 第21章 Proxy ― 必要になってから作る
クラスで表現する
- 第22章 Command ― 命令をクラスにする
- 第23章 Interpreter ― 文法規則をクラスで表現する
付録A 練習問題の解答
付録B サンプルプログラムの実行手順
付録C GoFによるデザインパターンの分類
付録D デザインパターンＱ＆Ａ
付録E 参考文献
学習ログ

学んだこと

デザインパターンとは、について
オブジェクト指向プログラミングの楽しさ
EffectiveJavaに通じるところがある
実際に現場で口にされるパターンは限りがある
- フレームワーク(Struts2やSpringなど)がうまいようにやってくれているので...
- フレームワーク内で様々なパターンを使用して実装しているな、というのがつかめれたのでよかった
時間を開けてもう一回読みたい

手に取った理由

初学者として、Javaを学んできたので、Javaを使ったデザインパターンの考え方を知りたかった
どんなパターンがあって、というのは共通語として押さえておきたかった

オラクル認定資格教科書JavaプログラマGoldSE7スピードマスター問題集

Wed, 01 Jul 2015 00:00:00 GMT

オラクル認定資格教科書 Javaプログラマ Gold SE 7 スピードマスター問題集

目次
- 1章　Javaクラスの設計
- 2章　高度なクラス設計
- 3章　オブジェクト指向の設計原理
- 4章　ジェネリックスとコレクション
- 5章　文字列処理
- 6章　例外とアサーション
- 7章　Java I/Oの基礎
- 8章　JavaファイルI/O (NIO.2)
- 9章　JDBCによるデータベースアプリケーションの作成
- 10章　スレッド
- 11章　並列処理
- 12章　口ーカライゼーション
- 模擬試験

学んだこと

Gold教科書で学んだことの整理
プラス、問題として問われやすいところの整理

手に取った理由

Gold資格取得

オラクル認定資格教科書JavaプログラマGoldSE7

Wed, 01 Apr 2015 00:00:00 GMT

オラクル認定資格教科書JavaプログラマGoldSE7

学んだこと

Silverのステップアップとして、JavaGold取得を決意
列挙型の使用方法
ネストクラスと匿名クラスについて
- １回読んだときはまだメリットについてあまり理解できなかった
デザインパターンの基礎知識
- コンポジション
- シングルトン
- DAOパターン
- ファクトリパターン
StringBuilder、StringBufferの違い
正規表現処理
コレクション、List、Set、Queue、Mapの利用
ジェネリックについて
- はじめ何のメリットがあってこんな複雑な事しているのかわからなかった
配列とリストについて
例外処理 SE7から追加された書き方など（try-with-resources）
ファイルIOライブラリー
JDBC、ResultSet
スレッド、排他制御、同期処理
Executorフレームワーク、アトミックとロック、Fork/Joinフレームワーク
- Javaにおいて業務であまり使用しないのでためになった

手に取った理由

Silverのステップアップとして、JavaGold取得を決意
より実用的な深い知識を習得するため

完全合格ORACLE-MASTER-DBA12c_Bronze

Wed, 01 Apr 2015 00:00:00 GMT

完全合格ORACLE-MASTER-DBA12c_Bronze

学んだこと

OracleDBの仕組み
- データベース管理概要
- ソフトウェアのインストール
- Oracle Enterprise Manager Database ExpressおよびSQL管理ツール
- Oracleネットワーク環境
- インスタンス管理
- データベース領域構造
- ユーザおよびセキュリティ
- バックアップリカバリ
- データベースの監視
DBMS機能ってこんなのがあるんだということを把握
この時期に発売されていた 12c の教科書がこれしかなかったので本書を選んだが、記載方法が自分好みではなかった..
学習ログ

手に取った理由

DBMSの一般的な知識がつけたかった
Oracleは１年目に業務で触っていたため、書籍で勉強を進めていくのに一番よいと判断した

電話はなぜつながるのか

Sun, 01 Feb 2015 00:00:00 GMT

電話はなぜつながるのか

学んだこと

電話回線網の仕組み
なぜ、「ぷー、ぷー」という音が鳴るのか
電話交換機の役割
IP電話について
携帯電話技術の世代

手に取った理由

業務で、電話回線を使用したダイヤルアップ接続をしなければいけない場面があり、そもそもの電話回線の仕組みに興味を持った
これまで何本か本を読んできて、なぜ～シリーズの本が読みやすいと感じたので

Javaでなぜつくるのか

Thu, 01 Jan 2015 00:00:00 GMT

Javaでなぜつくるのか

学んだこと

Javaとは
- プログラミング言語、というくくりだけでなくもっと広い捉え方をした方がよい
- 「仮想コンピュータの仕様とそれをとりまく社会環境」らしい反感買いそう..
Javaの歴史的部分
Javaの長所短所
コンパイラ言語ということ
JVMで動作するということ
- ヒープ領域などについて
オブジェクト指向について
基礎的な概念をまんべんなく学んだ印象
書籍は読みやすいので、遅くても2,3時間で読み切れると思う

手に取った理由

Javaの基礎的なところ、概念的なところについて理解を深めたかった

Windows7 上級マニュアルネットワーク編

Thu, 01 Jan 2015 00:00:00 GMT

Windows7 上級マニュアルネットワーク編

学んだこと

Windowsのネットワーク設定周りの理解を深めることができた
DLNAについて
自宅でネットワーク周りを整理するための知識
ルーター設定
PCの共有サーバー化
リモートデスクトップについて
FTPデーモンについて
ローカルPCにデーモンを入れ、ドメインを取得しインターネット公開する方法

手に取った理由

より、私生活により沿ったネットワーク関連の知識を深めたい
ネットワーク面でより効率的な自宅環境を構築したい
WindowsOSは業務で使っているのでなじみある

コンピュータはなぜ動くのか

Thu, 01 Jan 2015 00:00:00 GMT

コンピュータはなぜ動くのか

学んだこと

PCが動作する仕組みをハード面からソフト面まで説明
UML、DB操作、TCP/IP、暗号化技術、XMLなどについて説明
まんべんなく、浅く広くという印象

手に取った理由

PCの動作する仕組みについて深く理解できていないと感じ購入

基礎からのサーブレットJSP

Thu, 01 Jan 2015 00:00:00 GMT

基礎からのサーブレットJSP

目次
- PART01 入門編
  - CHAPTER01 サーブレット/JSPって何?
  - CHAPTER02 開発環境の準備
  - CHAPTER03 Webアプリケーションの動作原理を知る
  - CHAPTER04 はじめてのサーブレット
  - CHAPTER05 日本語の表示とコンテンツタイプ
  - CHAPTER06 web.xmlの基本
  - CHAPTER07 サーブレットを簡単に作る
  - CHAPTER08 はじめてのJSP
  - CHAPTER09 コンテキストパスを理解する
- PART02 基礎編
  - CHAPTER10 入力パラメータの取得
  - CHAPTER11 入力チェックと値の変換
  - CHAPTER12 フィルタの活用
  - CHAPTER13 画面遷移を行う
  - CHAPTER14 オブジェクトのスコープとリクエスト属性
  - CHAPTER15 セッションを使う
- PART03 もっとサーブレット
  - CHAPTER16 サーブレットクラスの詳細
  - CHAPTER17 外部ファイルから値を読み込む
  - CHAPTER18 HTTPリクエストとレスポンス
  - CHAPTER19 クッキーの利用
  - CHAPTER20 WARファイルのデプロイ
- PART04 クラスとオブジェクト
  - CHAPTER21 アクションクラスとディレクティブ
  - CHAPTER22 JSPの構成要素
  - CHAPTER23 JavaBeansとEL式
  - CHAPTER24 カスタムタグとJSTL
- PART05 データベースの利用
  - CHAPTER25 データベースの基礎知識
  - CHAPTER26 JDBCを使う
  - CHAPTER27 Webアプリケーションとデータベース
  - CHAPTER28 データベースアクセスの利用
  - CHAPTER29 データソースの利用
  - CHAPTER30 オリジナルアプリケーションの作成
- APPENDIX
  - APPENDIX01 EclipseによるWebアプリケーション開発
  - APPENDIX02 web.xmlの要素
学習ログ

学んだこと

Tomcatとは
Tomcat使い方
JavaWeb開発の基礎
アプリ開発の手順を順を追って理解できた
Web.xmlの役割について理解できた
JSPのタグ式の書き方
JSPからサーブレット、サーブレットからサーブレット、サーブレットからJSPまでのつながりが理解できた
実践的な内容まで踏み込めていない（FW未使用）ため、基礎的な事を習得しただけではある

手に取った理由

JavaSilverレベルの知識が身についたところで、Javaを使用したWebアプリの開発方法について理解したかった

Windowsはなぜ動くのか

Thu, 01 Jan 2015 00:00:00 GMT

Windowsはなぜ動くのか

学んだこと

PCが動作する仕組みをハード面からソフト面まで説明
UML、DB操作、TCP/IP、暗号化技術、XMLなどについて説明
まんべんなく、浅く広くという印象

手に取った理由

PCの動作する仕組みについて深く理解できていないと感じ購入

BIOS/UEFI 完全攻略

Mon, 01 Dec 2014 00:00:00 GMT

BIOS/UEFI 完全攻略

学んだこと

BIOSの仕組み
UEFIはBIOSの後継。GUI操作ができる。
すべて読み切れていないので時間あるときに戻ってくる

手に取った理由

業務でBIOS設定の変更などを行っていて興味がわいたから
LAN起動させるためにマジックパケットを許容する設定とかしていた

Windows 7 レジストリ徹底活用マニュアル

Mon, 01 Dec 2014 00:00:00 GMT

Windows 7 レジストリ徹底活用マニュアル

学んだこと

Windowsレジストリ操作で出来ること
驚きはあったが実用性はいまいちという印象
WindowsOSに対する理解は進んだと思う

手に取った理由

業務でレジストリ領域をいじる機会(※１)があり、興味を持ったため
- ※１OracleDBが参照しているレジストリ領域をいじらなければ解決していない事象があり..

ネットワークの知識と実務

Sat, 01 Nov 2014 00:00:00 GMT

ベテランが丁寧に教えてくれるネットワークの知識と実務 (IT ENGINEER’S Basic)

学んだこと

ネットワーク周りの基本知識の取得

手に取った理由

業務でTCP/IP関連の知識を必要とした

オラクル認定資格教科書JavaプログラマSilverSE7

Tue, 01 Jul 2014 00:00:00 GMT

オラクル認定資格教科書 Javaプログラマ Silver SE 7

目次
- 第1章　Javaプログラミング基礎
- 第2章　配列
- 第3章　演算子と分岐文
- 第4章　繰り返し文と繰り返し制御文
- 第5章　クラス定義とオブジェクトの生成・使用
- 第6章　継承とポリモフィズム
- 第7章　例外処理
- 模擬試験

学んだこと

Bronze本に引き続いて、Javaプログラミングの基礎知識を固めることができた
例外クラスの種別について意識しながら学ぶことができた

手に取った理由

JavaBronze本からのステップアップ
Javaプログラミングのスキルアップ
Silver資格取得

第1章　Javaプログラミング基礎

第2章　配列

第3章　演算子と分岐文

第4章　繰り返し文と繰り返し制御文

第5章　クラス定義とオブジェクトの生成・使用

第6章　継承とポリモフィズム

第7章　例外処理

模擬試験

オラクル認定資格教科書JavaプログラマSilverSE7スピードマスター問題集

Tue, 01 Jul 2014 00:00:00 GMT

オラクル認定資格教科書 Javaプログラマ Silver SE 7 スピードマスター問題集

目次
- 1章 Javaの基本
- 2章 Javaのデータ型の操作
- 3章演算子と決定構造の使用
- 4章配列の作成と使用
- 5章ループ構造の使用
- 6章メソッドとカプセル化を操作する
- 7章継承の操作
- 8章例外の処理
- 模擬試験

学んだこと

Silver教科書で学んだことの整理
プラス、問題として問われやすいところの整理

手に取った理由

Silver資格取得

1章 Javaの基本

2章 Javaのデータ型の操作

3章演算子と決定構造の使用

4章配列の作成と使用

5章ループ構造の使用

6章メソッドとカプセル化を操作する

7章継承の操作

8章例外の処理

模擬試験

オラクル認定資格教科書JavaプログラマBronzeSE7

Sun, 01 Jun 2014 00:00:00 GMT

オラクル認定資格教科書 Javaプログラマ Bronze SE7

目次
- 第1章　Java言語のプログラムの流れ
- 第2章　データの宣言と使用
- 第3章　演算子と分岐文
- 第4章　繰り返し文と繰り返し制御文
- 第5章　オブジェクト指向コンセプト
- 第6章　クラス定義とオブジェクトの生成・使用
- 第7章　継承
- 第8章　ポリモフィズムとパッケージ
- 模擬試験

学んだこと

基本型、参照型の違い
条件分岐の基本的な使い方
三項演算子、インクリメント
final,static,void
継承の概念、インターフェース定義の概念

NoccaLabs

Flutterアーキテクチャについて

概要

💻 前提環境

🏛️ Flutter のアーキテクチャ全体像

レイヤーモデル（Framework / Engine / Embedder）

アプリの構成要素

リアクティブ UI: UI = f(state)

ウィジェットと「合成（Composition）」

3 つのツリー（Widget / Element / RenderObject）

状態管理（State / InheritedWidget）

レンダリングパイプライン（Build → Layout → Paint）

⚙️ Flutter 内部の仕組み（なぜ高速なのか）

サブリニアなレイアウト

サブリニアなウィジェットビルド

線形の差分（reconciliation）と key

ツリーサージェリー（GlobalKey）

無限スクロール（Viewport / Sliver）

Element と RenderObject を分ける理由

📐 レイアウトの黄金ルール

親子の「交渉」の具体例

ボックスの 3 つのタイプ

tight 制約と loose 制約

🔥 ホットリロードの仕組み

仕組み

State が保持される

ホットリロードが効かない / 効きにくいケース

🏗️ ビルドモード

✨ ドットショートハンド構文（Dart 3.10 / Flutter 3.44）

Before / After

使える場所

🗺️ 理解を深めるためのロードマップ

Phase 1: 入門 — ウィジェットで画面を作る

Phase 2: 基礎 — レイアウトと状態管理

Phase 3: 内部理解 — 3 つのツリーとパイプライン

Phase 4: 実践 — 性能・最適化・運用

📚 参考リンク（公式ドキュメント）

OSPO（Open Source Program Office）とは？

概要

1. OSPO人材の全体像

2. どんな知識が必要か

2-1. 技術

2-2. 法務・コンプライアンス

2-3. セキュリティ・サプライチェーン

2-4. ソフトスキル

3. どうすればなれるか

4. 具体的なロードマップ

5. OSS活動で知っておくべきこと

5-1. コントリビュート前の確認

5-2. 良い PR・コミットの作法

5-3. ライセンス順守

5-4. メンテナー視点

5-5. 企業として参加する際の注意

6. まとめ & 次の一歩

参考リンク

短縮URL OSS 徹底比較 (Shlink / YOURLS / Kutt / Dub / Polr / Slash / Sink)

概要

想定読者とこの記事のゴール

まず全体像

各 OSS の概要

Shlink

できること (Shlink)

できない・苦手 (Shlink)

YOURLS

できること (YOURLS)

できない・苦手 (YOURLS)

Kutt

できること (Kutt)

できない・苦手 (Kutt)

Dub

できること (Dub)

できない・苦手 (Dub)

Polr

できること (Polr)

できない・苦手 (Polr)

Slash (補足)

できること (Slash)

できない・苦手 (Slash)

Sink (サーバーレス系)

できること (Sink)

リアクティブ UI: `UI = f(state)`

モバイルアプリ開発ディープリンクについて

BundleID/カスタム URI スキーム (`myapp://...`)

ベストプラクティス 1:モデルは `/model sonnet` を明示する

`.claude/settings.json` 最小テンプレ