本やネットの拾い読みで覚えた知識を、備忘録として自分なりに整理してみました。
心構え
- 「何を」作るかが一番大事。やってる内に気づいたら「何がつくりたかったんだっけ?」が危険。
- 手を動かす事を大事にする
- ぐだぐだ言ってないでコード書けよ、ハゲ
企画
- 企画に必要な7つの事(例:iPod)
http://blog.yusuke.be/entry/2012/05/07/112346- 哲学
- 個々人が持っているゆるがない気持ち。
- 例)音楽をもっと楽しみたい
- 個々人が持っているゆるがない気持ち。
- アイデア
- 哲学を実現するための個別具体的なアイデア。1サービスに複数のアイデアがあって良い。どんどん出して、後で精査すると良い。
- 例)所有している曲を持ち歩きたい
- 例)ディスプレイ、コントローラだけのミニマムなデバイスが欲しい
- 例)専用ソフトウェア(iTunes)で管理し曲を一括管理、デバイス同期が出来る。
- 例)コントローラは曲選択、プレイヤー操作だけ出来れば良い。
- 例)アルバム別、アーティスト別、ジャンル別で再生したい
- 例)再生中はアルバムジャケットをかっこよく表示したい
- 例)販売サイト(iTunesMusicStore)で曲を買ったらそのままデバイス同期されるようにしたい
- 哲学を実現するための個別具体的なアイデア。1サービスに複数のアイデアがあって良い。どんどん出して、後で精査すると良い。
- テーマ
- 哲学をより具体的にした勝負する領域のこと。
- 例)携帯音楽プレーヤー
- 哲学をより具体的にした勝負する領域のこと。
- コンセプト
- 何を作るかの具体的なイメージを一言で表したもの
- 例)専用の音楽ソフトを経由して所有する曲全てを持ち運べる携帯音楽プレーヤー
- 何を作るかの具体的なイメージを一言で表したもの
- 名前
- 仮でも良いからとりあえず名前をつけよう
- 例)iPod
- 仮でも良いからとりあえず名前をつけよう
- デザイン
- 具体的な絵を元に具現化する。見た目、使いやすさ、必要な機能を詰める。
- 例)紙にUI画面図を作る。
- 例)粘土でモックアップを作る。
- Webサービス「POP」が良さそう
- 具体的な絵を元に具現化する。見た目、使いやすさ、必要な機能を詰める。
- 内部設計
- Webアプリは結局「リソースへのCRUD操作」。後はそれをどう見せるか。
- リソース設計
- ER図
- クラス図
- URI設計
- API設計
- 哲学
- ※網羅できるように、上記必須7項目を抑えた入力フォームを作成してチェックする
実装
- 実装
- アプリケーション全体
- 1から全部手製で書くと大変なので、Webアプリ作成用の便利なライブラリ集である「WebApplicationフレームワーク(WAF)」を使う.
- WAF以外にも、デザイン、O/Rマッパー等、フレームワークを使う機会は多いが、至れり尽くせりの中身がよく分からない高機能ライブラリより、出来るだけシンプルなものを選ぶ。(内部構造が理解しやすいため。よく見て選定する) http://qiita.com/shukotang/items/055058b33b553b48c164
- Ruby
- Sinatra,Ruby on Rails,Padrino
- Python
- Django
- PHP
- CakePHP,FuelPHP,Symphony,ZendFramework,Laravel,CodeIgniter etc...
- Java
- Play,Spring etc...
- Javascript
- jQuery,Prototype.js,AnglarJS,Backbone.js,React.js etc...
- Node.js
- Meteor,Express,MEAN etc...
- Ruby
- MVCを意識する
- Model作成
- DBとの接続・操作はSQL直書きでも出来るが、様々なDBの差異を吸収して共通インターフェースである「O/Rマッパー」を使うと楽。
- Ruby
- DataMapper,ActiveRecord,Sequel etc...
http://datamapper.org/getting-started.html
- DataMapper,ActiveRecord,Sequel etc...
- Java
- Hibernate,H2Database,MyBatis etc...
http://krdlab.hatenablog.com/entry/20090503/1241331627
- Hibernate,H2Database,MyBatis etc...
- Ruby
- 直接DB触らないにしても、トランザクション(分離レベル)、インデックス辺りは把握しておいた方が良い。
- 一時データをKVS、永続データをRDBにj振り分ける。RDBはデータが残るが遅い、KVSはデータが残らないが早い。
- DBとの接続・操作はSQL直書きでも出来るが、様々なDBの差異を吸収して共通インターフェースである「O/Rマッパー」を使うと楽。
- View作成
- validationや削除確認メッセージなどクライアント側で出来る事は出来るだけクライアントに任せる。サーバー側に負荷をかけない。
- ブラウザとやりとりするWebサーバが必要
- Webサーバとアプリ間の窓口は、WSGIで一本化してやる。
- WSGI(Web Server Gateway Interface)
- Webサーバの種類によってアプリ毎に書き分けする必要が無いように、共通のインターフェースを提供するライブラリ。 DB接続で言うODBCみたいなイメージ。
言語によって呼び方が違うけど役割としてはどれも似ている。http://yone098.hatenablog.com/entry/20100115/1263525542Python - Python
- WSGI
- Ruby
- Rack
- Perl
- PSGI
- Java
- OSGI
- Webサーバの種類によってアプリ毎に書き分けする必要が無いように、共通のインターフェースを提供するライブラリ。 DB接続で言うODBCみたいなイメージ。
- Webサーバは例えば以下選択肢があり
- apache
- nginx
- この辺りのWebサーバ、アプリサーバ、WSGIの理解は以下がわかりやすい。
http://qiita.com/jnchito/items/3884f9a2ccc057f8f3a3
- デザイン
- 装飾はCSSフレームワークに頼るのが吉。というかBootstrapジェネレータでドラッグ&ドロップでまずは画面作った方が良いかも。
- bootstrapのcss、jsファイルのパスはpublic以下の相対パスで良い。layoutファイルからの相対パスではないので注意。
- フォント
- FontAwesome
プロモーション
- 最初の宣伝
- プレスリリース
- 自分のブログで紹介
- Twitterやはてなで拡散
運用
- パフォーマンスアップ
- Google PageSpeed Insight
- ベンチマークテスト
- ApacheBench
http://dev.classmethod.jp/tool/ab-tutorial/
- ApacheBench
- サーバー構成の見直し、分散環境の構築
- フロントエンドWebサーバ
- HTMLやJSON等の静的ページの配信担当。
- 動的な配信が必要だったらアプリケーションサーバに渡す。
- nginxがおすすめ。高速かつ設定記述がシンプル。
- アプリケーションサーバ
- キャッシュサーバ
- CDN
- フロントエンドWebサーバ
- 監視設計
http://tech.innova-jp.com/monitor-structure-for-startup/- 死活監視
- サービス監視
- リソース監視
- パフォーマンス監視(newrelicとか)
- ログ集約(fluented)