development

• 希望と事実に基づいた混同をしない
  • 自分の能力がこうであってほしいという希望に基づきがち
• 確率で出す
  • 50%の確率で1週間以内に終わる。50%の確率で1ヶ月以内に終わる
• 関係者にとっては甘い見積もりをするインセンティブがある。なので客観性が必要
• 専門家の意見はあてにならない。なんでもいいから自分なりに数えることが大切
• 過去のデータがあれば、上司の圧力に抵抗できる

設計において、画像の作成はやっかいな仕事の1つだ。1度きりの作成ならいいが、あとで手直しすることを考えると、専用のソフトウェアを使うことにいきつく。drawioのVSCode拡張を使って、ローカルで書くのが最高。

ファイルの拡張子にdrawio.svgをつけると、画像をそのまま開いて編集できる。

• Git管理できる
• GitHubでは画像のdiffが表示できる
• 保存と編集が同じファイルで、編集のハードルが低い
• 単なるSVGなので、閲覧や配信がしやすい

• 開発体制確認
  • 担当範囲
  • 反映フロー
  • チームの調整フロー
    • ある機能を反映するために調整する必要がある範囲
• 要件定義
  • 疑問は必ずメモって片っ端から聞く
  • 会議を入れまくる
  • 目標期限とどこまでやるか決める
  • 共通のサーバ環境をどうするか決める
  • 不明瞭なところは聞いて確認してドキュメントに残す
  • 権限
• API設計
  • 先にレビューしてもらう日付を決める
  • エンドポイント決定
  • レスポンス設計
  • ここでOpenAPIで作ってモックを返せるようにするとフロントエンドの開発をブロックしない
• DB設計
  • 先にレビューしてもらう日付を決める
  • リソース・アクションを洗い出し
  • ライフサイクル考慮
  • 暗号化
  • スキーマドキュメント作成
  • ER図を見て確認
• 開発環境準備
  • デプロイ
  • 依存サービスのモック
  • 環境変数
  • テストアカウント
• 本番環境考慮
  • デプロイ
  • ログ
  • 環境変数

開発で役に立つツール群。

• 各言語のLinter
• 各言語のフォーマッタ
• DBドキュメント生成ツール(tblsなど)
  • 生成したMarkdownはmdbook+book-summaryでビルドする
• 設計書出力ツール(mdbookなど)
• 画像出力ツール(Mermaidなど)
• OpenAPI
  • バリデーション(openapi-validatorなど)
  • ドキュメント生成ツール(redocなど)
  • モックサーバ(prismなど)
  • 実装チェックツール(kin-openapiなど)

• Nodeの管理
• コンテナのスケジューリング
• ローリングアップデート
• スケーリング / オートスケーリング
• コンテナの死活監視
• 障害児のセルフヒーリング
• サービスディスカバリ
• ロードバランシング
• データの管理
• ワークロードの管理
• ログの管理
• Infrastructure as Code
• エコシステムとの連携や拡張

How To PLAN your Game as a Solo Developer - YouTube

• プロトタイプと本番用を分ける
• プロトタイプではゲームの機能、コードに集中する
• 本番用ではゲームのコンテンツ、データに集中する
• プレイできるゲームからフィードバックを得ることが重要

• 文化
• 自動化
• 測定
• 共有

管理権限で参考になる。

カオスエンジニアリング。

読もう。

devopsのわかりやすい概要。

DevOpsの説明。

コードレビューでの確認テンプレート。

Googleのギークたちはいかにしてチームを作るのか。

Googleのドキュメンテーションのスタイルガイド。

アジャイルの詳しい解説。