# ワンストップ　アプリ開発目次検討メモ

## 目的
目次の作成が大事だけど、構造化したいので、まずはこちらでみんなで書いてみませんか？な意図。

## やり方
部、章、節、小節、本文のレベルで行きます。

それぞれのレベルで、この下に追記していってください。

また、本文は章レベルで書き始めてもらって構いません。下はあくまで案。みんなで調整してー

順番入れ替えはぜひやってください。三人寄れば文殊の知恵と申します。（誰が書いたかは問わない）。俺はこう思う、で移して構わないですが、書いてあるものを消すのはご注意ください。（下の「どこに入れるか悩むリスト」へ移すはOK。明らかに間違ってれば消すOK）

# 全体校正構成ここから

## まえがき

----
第1部 最初のやつ(作る前に押さえておくべきほんとに最小限のこと
■chap-appliction.md
# アプリケーションとは
## アプリケーションを作る流れの概要説明
## アプリケーションを作るには何が必要？
### プログラミング
### デザインツール
### ツクールとかHSPとか
### 書けるひといたらUnityとか
### アプリケーションを作る簡易ツール
#### [column] Excelだって立派なプラットフォーム
### 黒い端末
### テキストエディタ・IDE
### バージョン管理システム git
## ファイル
### テキストとバイナリ
### 文字コード
### 謎のフォーマット「ジェイソン」
## スネークケース、ハイフンケース、パスカルケース。キャメルケース
## case intensive / case sensitive

■chap-development-environment.md
# 開発環境を作る（ないと始まらん）
## 言語インストール
## Pythonの開発環境を作る
### Pythonのインストール
### Pythonの開発で必要なツールたち
## Node.jsの開発環境を作る
### anyenv + etc...

## Docker
### NVIDIA Docker
### Radeon Open Compute

## 開発手順書
### 自動で動く開発手順書
## フレームワークという誘惑
## 開発環境のインフラはどうつくる
### 本番とのスペック差
### コスト
### 本番じゃないと動かない機能という強敵
### Infrastructure as Code

開発のための環境が本番環境と違って、一部機能が動かないなどといったことはよくある話ですが、これは決して良いものではありません。個人のDockerでも開発環境でもステージング環境でも本番でも、何かしらのテクニック、たとえばダミーサーバーなどを作るなどして、同じように動くべきです。

## 自転車置き場の屋根の色議論の不毛
### 自動コードフォーマッタ
### Linter

## ロジックの話
どこから持ってくる？参考にする書籍とか古典的な手法とか？
ロジックはいつ決める？

----
第2部 能書きはええんや。作ってみよう

■chap-make-easy.md
# さくっと作る話（日常使いのスクリプトとか）
## ワンライナー
## ちょっとしたスクリプト
## botを作ってみようぜ

botは面白いテーマだし、読者も、抽象論ばかりだと飽きるから、1章独立でとって、
様々なbotの作り方で1章作ってもいいんでは？？？

## ツールを組み合わせる
#### [column] UNIX哲学
## Chrome Devtools
#### [column] Chrome系には3種類のブラウザがある

普段使いのChromeで開発すると不便なことになりやすいので、開発用に、Google Chrome Canary や Chromium も使うと便利というテクニック

■chap-handcopy.md
# 写経する

# 習作する
## お題があると良い
### 競技コーディングという頭のパズル
### お題サイト
（プログラミングの練習するならお題サイトを活用すると良い）

----
■chap-technique.md

# お勧めプログラミングテクニック
## まずは動くことを確認する
### バージョンが正しいことを確認する
#### [column] 問題があったらファイルを消す？リブートする？
## デバッグ
### printデバッグ
### assertion
### デバッガを活用する
### 二分探索式デバッグ法
## 小さなサンプルを作る
### スパイク
## 開発リズムの作り方
### Yak Shaving
#### [column] 同時に2つ以上のことをしない方がいい
## アルゴリズム

* アルゴリズム一つで速度の桁数は何桁も変わる（そもそも桁という単位ではないレベルで変わる）
* アルゴリズムを暗記する必要性はない

----

----
第3部 方法論（基本）

■chap-ui-design.md
# デザイン
## UI
#### [column] UI/UXいうなの話
## デザインはロジカルな作業である
## アクセシビリティ

----

■chap-coding.md

# コーディング
## 関数
## クラス
## 契約プログラミング

## 良いコード・悪いコード・普通のコード
### 名前がすべて
### 読みやすさとは
### DRY原則
### 間違ったDRY原則
### ソースコードコメントは最低限に

#### [column] ライオンさんは言いました

* コードはhow
* テストはwhat
* コミットメッセージはwhy
* ソースコードのコメントは why not
（だったかな）

## 文化圏
### パッケージングシステム
### ベターな書き方。よく使われる書き方

PythonだとPEPとか、RubyならRuby wayとか、そういう、
「界隈でよくあるやつ」

### 誤解を招くやり方、ネーミングを避けよう

----
■chap-testing.md

# 自動テスティング

## ユニットテスト
### テストで一番重要な要素「時間」
## テストモック
## 結合テスト・E2Eテスト
## スナップショットテスト
## 具象テスト（正しい呼び方ではないと思う）
### テストDBを用意して実際にSQL叩くあれ
### 本番データから、個人情報をマスキングして、ステージング環境やテスト環境にコピー

### 画像比較
## 画像認識型テスト (cygamesとかがやってるやつ)
## ランダムテスト
### Haskell Quickcheck

## TDD/BDD
#### [column] TDDという名の「設計論」
## テストファースト
## Power Assert

----

■chap-deploy.md
# デプロイ

## リリース作業どうする？
### CI
## 手順書を作る
## 自動でデプロイできるようにする
### CD
### 差し戻しはどうする？
## Blue/Green deploy
## コンテナという救世主
## ライブラリメンテナンス

----
ガチなやつ

■chap-requirements.md
# 要件
## 解決したいことはなに？
### 業務を改善する
#### 改善したい業務を知る
#### 開発をしないで解決できるかを考える
#### 改善するとインパクトのある業務を改善する
#### 改善したことで他の業務が発生していないかを考える
#### オレオレ改善になっていないかを考える
#### 機能が使われ続けていることを定期的に振り返る
### これまで出来なかったことをする
#### なぜ出来なかったのかを明確にする
#### 実現をすることが可能なのかを調査する
#### 出来た機能を使う人はどのような人なのかをはっきりとさせる。
## 作るのにはコストがかかる
## MVP（試すのに最低限のプロダクト）
### 仮説と検証サイクル
## UX
## サービスを作る
### 新規性は何？
### それが今まで無かった理由
## マネタイズどうする？
## 実は作らなくても解決できるなら、そもそも作らない
## ターゲットは誰？
### プラットフォームどうするの？
## ドメイン分析
### ビジネスロジック
### ユビキタス言語
## ユーザー目線にたつ
### ドッグフーディング（他のところにもあったな）
#### 利用を検討するときのことを考える
#### 利用をしているときのことを考える
#### 利用を終了したくなるときのことを考える
### ユーザーヒアリングをする
#### 実際のユーザーがいるなら会いに行く
#### 近くにいない場合は、アンケートを取る
#### 利用状況のデータから判断をする

* Web、Android、iOS、デスクトップ、組み込み…

■chap-team-development
# チーム開発
## 作業分担
### 分析・要件定義
### 設計
### 詳細設計・コーディング
### デザイン
### 音とかその他（雑でごめん）
## ステークホルダー・プロダクトオーナー
## 組織論
### コンウェイの法則（プログラムの構造は組織に類似する）
### 組織が定める手順
## 作法
### HRT
## Gitなど、共同開発ツールの話

■chap-software-design.md

# 設計論
## プログラミングは全工程が設計そのものである。どこまでいっても設計
## アプリ開発は、コストその他のバーター
## 技術的負債
### 循環的複雑度
### モジュール安定度
## 人類の知恵
### SOLID原則
### デザインパターン

* GoF
* PoEAA
* DSL

#### [column] パターンを暗記するな

### UML

## 境界線を引く

### モジュール
### コンポーネント
### サービス
### レイヤードアーキテクチャ
### モノリシック vs マイクロサービス

## 設計論は大体プログラミング言語に左右されてしまう話

### 手続き型
### OOP
### 関数型

## 型
### ダックタイピング
### 動的型付け言語にも型はある
### 型の魔術
### 型は安心感

## 抽象と具象

### 具象（詳細）の悪夢、昨日の常識は明日の非常識になる
### 詳細決定は、出来うる限り後に回せ
### 抽象化は、必ずしも共通項の括りだしとは限らない

#### [column] 式年遷宮

## スケールアウトとスケールアップ

----

# （どこにぶらさげる？） 開発期間
## 現代のアプリ開発で、1年単位は遅すぎる

# ライセンス・規約
## OSS・フリーソフトウェアのライセンス
## サービス規約
## 法律
### ヨーロッパのアレ
### 資金決済法

# アジャイル
## アジャイル宣言
## アジャイルの源流
### トヨタのKANBAN
### リーン
### エリヤフゴールドラッドのToC（制約条件理論）
## XP
## アジャイルプラクティス
#### [column] アジリティ
## 「アジャイルをやっています」
## よくある誤解

* ドキュメンテーションをサボる？
* 手順がない？

## それ以外の何か？
事前知識として欲しいものを列挙して。

SCRUMとか

----
エモなやつ

# モチベーション
## 作りたいから
### 再発明を恐れるな
#### [column] 今が最良の時代であり最後の時代である可能性

10年後、最後のプログラマが作ったものによって、人類が働く必要がなくなってるかもしれない
ここ数十年の科学進歩は過去数n年にも匹敵する話

だから作りたい気持ちがあるなら、今やらないと絶対に後悔するぞ？

## 新しい技術を試したい
## モチベーションを維持する方法
## モチベーションに頼らない方法

## エンジニアは言葉に厳密であれ

## 趣味で小さいものを作る(作りたい駆動)
### 作りたい駆動でちゃんと作る方法
## 趣味で大きいものを作る(チーム開発的な)
### チームでやるときに必要なもの
## なんのためにアプリ開発するのか?
### 作りたい駆動(中身は何でも良い)
### 不便を解消したい
## 開発メンバーの集め方
1人では難しいから仲間を集めたい…

## アーキテクチャ
### アーキテクチャが重要な理由
### どうやって選べばいいの？
## 実現方法
### やりたいことに対する言語、FW、ライブラリの選定方法
### ライブラリの選定ポイント(枯れてる?開発は活発?デファクトとは?)
## 見積

## モダンなコーディング、レガシーなコーディングって何？
## 開発体制(よい見出しが思いつかない…)
### 1人で
### ペアで
### モブで
これは設計でも使えるので場所が難しい。
両方に書いてもいい。設計と実装でやること違うし、両方に書きましょう。
## 続け方・モチベ維持(超読みたい)
### 新しい技術を学んで全部作り直したくなったとき
Javaで書いてたけどKotlinで書き直したい…とか
## CI/CDって最初からいるもの?

# 第5部　テスト・デバッグ
## TDDとかってこの辺で説明するの？
## テストの方法
## デバッグと一口に言っても…

# 第6部　リリース
## リリースとは
## 公開するだけじゃないよ
## リリースのお作法とアンチパターン
## 利用規約の作成方法
## 宣伝(もっと前の工程?)

# 第7部　運用
## バックアップ
## トラシュー
## エンハンス
## スケール
## 改修(のしやすさは設計?)

# どこに入れたらいいのかわからない話
#### GPL汚染って何？
#### オープンソースって使っていいの？
#### ブログのコードコピペしたらどうなる？
#### 【コラム】実際にプライベートでチーム開発しようとしたら失敗した話(FORTE)

----

# アプリケーション開発最速化理論
## 具象コードの研究と蓄積
## FigmaでUIコンポーネント素振り

----

# アプリ開発とセキュリティ

本章では、アプリ開発時に知っておくべき「セキュリティ」について説明します。

### セキュリティ対策を実行するタイミング

## 開発フェーズごとの「セキュリティ」

テスト（脆弱性診断）だけがセキュリティじゃない。
要件定義から運用まで、セキュリティの対象範囲は広い。

### セキュリティを考えるタイミング
* 要件定義・設計
* 実装
* テスト
* 運用
### 要件定義・設計
#### 危険は元から断つ
#### 言語・フレームワークの選定
#### プラットフォームの構成
#### Webシステム/Webアプリケーションセキュリティ要件書

### 実装
#### セキュアコーディングとは
#### セキュアコーディング規約のススメ
#### セキュアプログラミング講座
### テスト
#### 脆弱性診断
* 自動診断
* 手動診断
#### 誰が実施するのか
* 外部業者に依頼
* 脆弱性診断内製化
#### 外部業者に依頼する場合のコツ
* 診断対象選定
* 料金見積
* 診断前準備
* 診断中の作業
* 診断報告書の見方
* 報告会に臨む前に
* 脆弱性修正工数見積
#### 脆弱性診断内製化支援
* 脆弱性診断士スキルシート
* OWASPテスティングガイド
### 運用
#### 製品の更新
* プログラム言語
* フレームワーク
* CMS
#### セキュアなネットワーク構成
#### ファイアーウォール運用
#### 改竄検知
#### アクセス制御

#### [column] サイドチャネル攻撃

## 実際の開発ではどんなセキュリティを意識すればいいの？
### 機密性(1Confidentiality)
### 完全生(Integrity)
### 可用性(Availability)

### クラウドサービスにおけるセキュリティ注意事項
#### クラウドサービスへのアクセス管理
#### クラウドサービスはどこからでも、誰でもアクセスできる
#### 責任共有モデルと言う考え方
### サーバーレスアーキテクチャ・マイクロサービスアーキテクチャにおけるセキュリティ
#### サーバーレスアーキテクチャ・マイクロサービスアーキテクチャとは
#### サーバーレスアーキテクチャ・マイクロサービスアーキテクチャにおけるセキュリティ注意事項

### ソースコードレベルでのセキュリティ注意事項
#### プライベートリポジトリを利用する
#### 認証キーなどをハードコードしない
#### Webアプリケーションのコードは誰でも見ることができる
#### Gitの履歴は要注意！？

---

## 開発・実行環境はＰＣだけじゃない
### スマフォで始めるWebアプリケーション開発
### スマフォで動くIDE
### スマフォでサーバー管理

# 運営する
# 動作確認
## ドッグフーディング
## カオステスト

## 問題はなに？
### ワインバーグ的な話