Software Design 202311
個人開発成功の必須条件
最速で開発・リリースして需要を見極める
- 個人開発のメリット
- モダンな技術を使える
- ソフトウェア開発の全体像が見える
- やりたいことをやれる
- 失敗しないためには
- 先に集客&マネタイズ
- Airbnb はサービス開発する前に自分たちのオフィスをレンタルして本当に人が来るか見極めたらしい
- インスタで DM 送って使ってもらって課金してくれそうか 様子を見るとか
- Google フォームで事前登録をしてもらい、連絡先を確保したうえ、課金してでも使いたいか聞いておくとか
- 休日 2 日〜3 日で開発してリリース
- コアのコアのコアだけを開発する
- 99%は失敗するので、正しい設計とか、スケールできる構成とか、自由度の高い設計とか、利益出てから考えるで十分
- 最初はほとんど手動でもいい、後で自動化する
- お金をかけない
- 先に集客&マネタイズ
長期的視点でスモールビジネスを続ける
- 個人開発の良さ
- 得た経験を本業に活かせる
- 次の仕事につながる
- すべての工程を体験できる
- 自分のサービスが使われる感動を得られる
- 作りきれない問題の原因と対策
- 構想が大きすぎる
- まずは 1 ヶ月で作れるものを
- 要件は削りまくってまずは MVP を作る
- なる早でユーザーに使ってもってフィードバックを得る(恐れるな)
- 技術的なハードルが高すぎる
- 未経験な技術は使っても 1 つまで
- 技術習得とサービス開発はわけて考える
- 技術習得している段階では進捗がないように見えて病むので
- まずは動かすことが最優先
- リファクタは後でやる
- 動的な 部分であっても一旦は静的にしておく
- PC だけ、iOS だけ、などデバイスを絞る
- CSS を一切書かない、あとで書く
- 外注する (Consumer Generated Media 等の場合は人が作ったデータがあるだけで完成度が違う)
- 先に似たサービスが出てしまった
- 気にしないでいい or 目に余る場合はピボット
- 誰にも使われなかった
- 自分でとにかく使う
- 自分がほしい部分をとにかく作る
- 恥を捨てて宣伝する
- 1 人でも使い続けるモチベーションがある仕組みにする
- 構想が大きすぎる
- 金銭的成功を目指すためには
- スモールビジネスをやる not スタートアップ
- お金のかからない構成にしておく
- 波が来るまでじっくり待つ
- アップデートをし続ける(これできてないひと多いよ!必須よ!)
- 他のことを捨てて時間を作る
- 収益を出せる前提のサービスにする(無料プランはやらない、とか)
1 つのアプリをじっくり育てる
- 仕事の種類
- フロー型の仕事 / 人月の切り売り / 受託
- ストック型の仕事 / お金を生み出す仕組みに投資する / 個人開発
- サービスを軌道に乗せるには
- ヘルプや初回起動時のガイドを作る
- 最大の敵は「わからない」
- 企業を超えたウェットなサポート
- 無料機能と有料機能のバランスをよく考える
- サブスクに一切お金を払わない日本人ばかりだったのは 10 年前の話
- 広告ほど不安定な収入源はない
- 新規アプリ作成に逃げずじっくり育てる
- 辛辣なレビューに向き合う
- ちゃんと直せば星 5 になおしてくれたりするよ
- ヘルプや初回起動時のガイドを作る
- 個人開発の成功とは、他人の評価軸に左右されず、自分のやりたいことをやり続けられること
理想のコンテナイメージを作る
理想のコンテナを目指すための基礎知識
- Docker コンテナ
- 完全にサンドボックス化されたプロセス
- カーネルを共有しているため、コンテナとホストマシンで以下を一致させる必要がある
- OS(Linux/Windows)
- CPU アーキテクチャ(x86/Arm)
- Docker イメージ / コンテナイメージ
- コンテナのひな形である
- 読み取り専用である
- Dockerfile をもとにビルドして作られる
- 仮想マシンイメージと比べてはるかに軽量
- ファイルシステムとメタデータから構成される
- ファイルシステムの作成は、ベースイメージというもととなるイメージ起点に、必要なアプリケーションやライブラリ等を段階的にインストールしていくことで行う
- メタデータとは、環境変数、デフォルトコマンド、ポート番号など
- イメージレイヤの集合体である
- Dockerfile に書かれた各手順ごとにイメージレイヤが作成される
- 複数の親子関係を持つレイヤ群が、最終的にあたかも 1 つのファイルシステムのように振る舞う
- 容量やセキュリティの観点からレイヤは少ない方がいい
- Dockerfile
- コンテナイメージを構築するための設計図
- ツールに寄っては Conteinerfile という名前であることもあるが、書ける命令は同じ
- 理想的なコンテナ
- 再現性
- バージョンは固定する
- セキュリティ
- 非特権ユーザで動作させる
- 不要なファイルを含めない
- 特にクレデンシャルファイルには要注意
- マルチステージビルドにより成果物のみ共有するのが有効
- distroless にする
- Go や Rust などバイナリが 1 つ動くものであれば使える
- 頻繁にビルドし直す
- セキュリティパッチが適用されているかもしれないので
--no-cache
を忘れずに
- 可搬性
- 環境依存をなくす
- コンテナイメージを軽量に保つ
- 再現性
- DockerFile の書き方おさら い
- (前半省略)
- パーサディレクティブ
- syntax
- Dockerfile のバージョンを指定する
- escape
- エスケープ文字を指定する
- syntax
- Dockerfile の記述で気をつけること
- ベースイメージの選択
- 軽量でセキュアなものを選ぶ
- 公式イメージや認定パブリッシャーのイメージが無難
- Docker Official Image / Verified Publisher / Sponsored OSS のバッジがあるもの
- アプリと同じプログラミング言語のランタイムがあらかじめ含まれたものを選ぶ
- alpine は良い選択だが、無思考で選んでいいわけじゃないので注意
- 以下に起因するトラブルが多い
- sh を始めとするコマンド群の実態が BusyBox の単一ライブラリである
- C ライブラリが glibc でなく musl である
- Ubuntu もいうほどデカくないぞ
- 以下に起因するトラブルが多い
- 選択できるなら distroless を選ぶ
- いくつか種類があるので適したものを選ぶ
- シェルがないと問題発生時にデバッグで死にそうな場合は debug タグの付いたものを選べ
- いくつか種類があるので適したものを選ぶ
- イメージサイズ・レイヤ数
- ライブラリをインストールする際は後でキャッシュを消すか、そもそもキャッシュを作らせないようにする
- マルチステージビルドによりセキュリティの向上、サイズとレイヤ数の削減ができる
- ビルドの速度
- 変更の少ない命令を先に書くことでキャッシュを効かせる
- ベースイメージの選択