1. 配備 (インストール) 不要にすべき
1.1. コピーすればすぐ動く
1.2. お客様にメールで送ったらすぐ使える
1.2.1. クライアントをメールで送ったら自動的にサーバーに接続して使える
1.2.1.1. セキュリティはサーバー側で担保する
1.3. Web アプリ
2. 家のように作る
2.1. 全体のシステム化は少ない
2.2. ドアや窓はあとから変更可
2.3. コンセントに挿すと使える
2.3.1. 拡張
2.3.2. 根幹部分に影響を与えない
2.3.3. 付け替え自由
2.4. Web ならできるかも
2.4.1. 様々なサービスを Web サービスで準備する
2.4.2. JavaScript でクライアント側の特定の項目に組み込む
3. 詳細はメタデータに置く (達人プログラマー)
3.1. メタデータ＝スクリプト？
3.1.1. 機能部品はかっちり作る
3.1.2. それを呼び出して組み合わせるのはスクリプトで
4. 有向グラフで構成できるか？
4.1. ソース→ディスティネーション
4.2. あるグラフ経路を情報として知らせる
4.2.1. {ソース→ディスティネーション}→ディスティネーション
4.2.1.1. クロージャと同じ
5. 排他的ではなく協調的な分類ができるようにする
5.1. タグ付けは○
5.2. フォルダ分けは×
6. 雑多なアイデア
6.1. セキュアな システムを 作れるか?
6.1.1. 一般ユーザーに どこまで システムの 変更を 許すか
6.2. 溜め込んでも 使えなければ 意味が ない
6.2.1. 検索が 重要
6.2.2. 必要な 情報は 使う 場所の 近くに 表示されるように する
6.2.3. ポータルも 有用
6.2.3.1. ある 使用シーンや 特性で 絞り込んで 表示した もの
6.3. あらゆる 部分を ポータブルに する
6.3.1. インストール
6.3.2. DB
6.3.3. やりやすくなる
6.3.3.1. インストール
6.3.3.2. メンテナンス
6.3.3.2.1. 保守
6.3.3.2.2. 改修
6.4. ローカルで 機能追加できるように する
6.4.1. 従来システムへの 不満
6.4.1.1. 見積 マスター 2009 (MS Access 製の 見積 ソフト)
6.4.1.1.1. 印刷形式が 複数 ある
6.4.1.1.2. よく 使う ものは 限られて いる
6.4.1.1.3. 決まった 表紙, 決まった 明細の 順に 印刷したい
6.4.1.1.4. Access なので できない!
6.4.2. Web システムなら
6.4.2.1. ブラウザ上で JavaScript を 動かせる
6.4.2.1.1. Greasemonkey
6.4.2.1.2. 機能追加 できる
6.5. ドメインモデル, オブジェクトの うまい 作成方法
6.5.1. 1. まずは 関数で 考える
6.5.1.1. 必要な 情報を 引数に 取る
6.5.2. 2. 最初の 引数を オブジェクトと する
6.5.3. 3. 残りの 引数を 引数のまま, または インスタンス変数と する
6.6. アプリ間 権限は CRUD だけで よい?
6.6.1. 例
6.6.1.1. ソーシャルアプリから アドレス帳への アクセス
6.6.1.2. 2ch クライアントから カメラロールへの アクセス
6.6.2. REST の 考え方
6.7. 設計しすぎない
6.7.1. あまり 設計せず 作り始める
6.7.1.1. YAGNI (You aren't gonna need it)
6.7.1.2. 設計を 単純に する
6.7.1.3. 余分な 柔軟性を 作り込まない
6.7.2. 少し 作って リファクタリングする
6.7.2.1. 予定外の 拡張に 備える
6.8. トップダウン or ボトムアップ
6.8.1. ボトムアップだと 使わない 関数を 作っていたり する
6.8.2. トップダウンだと TDD しにくい
6.8.2.1. BDDが解決策となる
6.9. フリー版の機能制限は質でなく量でする
6.9.1. 量による 差別化の 利点
6.9.1.1. すべての 機能を 使うことが できる
6.9.1.2. 必要な 人だけが 課金する
6.9.2. 例
6.9.2.1. MindMeister
6.9.2.1.1. 保有マップ 5 個まで
6.9.2.2. Downloads / Lite
6.9.2.2.1. 保有ファイル 5 個まで
6.10. すべてを 自動化しては いけない
6.10.1. 手作業を 自動化するのは よい
6.10.2. 例
6.10.2.1. クライアントから 印刷ボタンを 押すと サーバーに 接続された プリンタから 資料が 印刷される
6.11. プラグインで拡張する
6.11.1. 基本機能と拡張機能を別に作成できる
6.11.1.1. 保守しやすい
6.11.1.2. 基本機能のバージョンアップ時に不具合が入りにくい
6.11.2. ユーザーに合わせて機能を追加できる
6.11.3. 開発協力者を増やしやすい
6.12. 開発やデバッグ時に呼び出しやすいようにモジュール化する
6.12.1. 例
6.12.1.1. 表示/編集モードの切り替え
6.12.1.1.1. ApplicationMode.Edit 等
6.12.1.2. DB からの値の取り出し、格納
6.12.1.2.1. model.load; model.name="ABC"; model.save
6.13. 緩く作る
6.13.1. 要件は常に変わる
6.13.2. お客の要望にその場で応えられる
6.13.3. かっちり作っても利用者から見たら同じ
6.13.3.1. 修正しやすく作った方がお客のためになる
6.13.4. ビジネスシステムをJava等でかっちり作るのは間違っている
6.14. サービス名は「よくある音でスペルが違う」ものがよい
6.14.1. flickr
6.14.2. clojure
6.15. 古いデーターは追い出せるようにする
6.15.1. 別途アーカイブもしくは破棄
6.16. アルゴリズムをなるべく共通にシンプルにして, 動作の詳細 (個別の違い) をパラメータに追い出す
6.16.1. パラメータさえあれば再現できる
6.16.2. 再コンパイル無しで動作の調整が可能
6.17. 専用アプリも全面的に Web 連携すべき
6.17.1. 例
6.17.1.1. Evernote Windows クライアント
6.17.1.2. Readability iOS アプリ
6.17.2. 連携内容
6.17.2.1. リンク
6.17.2.1.1. 本文中に URL, リンクを書ける
6.17.2.1.2. リンク先の内容を表示する
6.17.2.2. 取り込み
6.17.2.2.1. Web の内容, 画像
6.17.2.2.2. メールで受信したものを格納する
6.17.2.3. 混在して表示
6.17.2.3.1. Web の関連情報をアプリ内に表示する
6.17.3. 利点
6.17.3.1. Web 上にある無数のサービスと連携できる
6.17.3.1.1. 地図
6.17.3.1.2. カレンダー
6.17.3.1.3. メール
6.17.3.2. アプリ内で管理しきれない関連情報を, 別サービスで管理できる
6.17.3.2.1. マインドマップ
6.17.3.2.2. Evernote
6.18. テンプレート (ひな形) 化する
6.18.1. 何を入力すべきかわかりやすい
6.18.2. 素早く完成できる
6.18.3. 完成形がわかる
7. 公開 Web サービスの認証
7.1. メールアドレスで招待・認証
7.1.1. 登録時
7.1.1.1. 1. 招待メールを送る
7.1.1.2. 2. メールのリンクからアクセス
7.1.1.3. 3. 初期パスワードが届く
7.1.1.4. 4. アクセスしてパスワード変更
7.1.2. メールアドレス変更時
7.1.2.1. 1. 新しいメールアドレスを登録
7.1.2.2. 2. 新メアドに確認メールを送信
7.1.2.3. 3. メールのリンクからアクセス
7.1.2.4. 4. パスワードでログイン
8. 別マップ
8.1. 別マップ: Persistence層、DBに関するアイデア
8.2. 別マップ: プログラムのテストに関するアイデア
8.3. 別マップ: UI, 操作性に 関する アイデア
8.4. 別マップ: プログラミング言語、型に関するアイデア
8.5. 別マップ: プログラム構成法、ロジックの置き場所
8.6. 別マップ: オブジェクト指向と関数型
9. 印刷
9.1. PDF
9.1.1. 多くの環境で(ブラウザのみで)印刷できる
9.1.2. レイアウトをすぐに(たとえば客先で)修正するのは難しい
9.2. Word, Excel等への差し込み
9.2.1. テンプレートに差し込む
9.2.2. 文章を修正しやすい
9.2.3. 印刷前に加工できる
9.3. PXDoc/SVG
9.3.1. 正確な位置に印刷できる
9.3.1.1. PXDocは簡単に位置調整できる
9.3.1.1.1. A4に線が印刷されるので実測との差を入力する
10. 役立つことが重要
10.1. アジャイル
10.1.1. すぐ作り, すぐ出し, すぐフィードバックを受ける
10.1.1.1. 方向性が自動的に修正される
10.2. 作り方より使い方を重視する
10.2.1. 大切なのは顧客価値
10.2.1.1. いつまで開発のやり方ばっかり語ってるの？
10.2.1.2. 正しく設計されたプログラミングより, 顧客が価値を認めたものが残る
10.2.1.2.1. Worth Is Better
10.2.1.2.2. Worth Is Worth