運用・保守フェーズに入ってから、システムが安定していて特に作業が発生しなかったとしても、保守・運用のコストを下げてはいけない。

もしかしたら、次に発注するシステムの品質に影響する動機になるかもしれないからだ。

どのタイミングかはわからないんだけど、いろんなサイトを見ていると突然固まる。

Flashを使っているサイトの確率が高いかな。

勘弁してほしい。

全ての成果物の保守フェーズは、その成果物が発生した瞬間から始まる。

だから、

運用・保守フェーズで楽になるようにプロジェクトを設計して運営するという事は、各フェーズの成果物が発生した瞬間からの作業でも楽が出来るということである。

だから、運用･保守フェーズを重要視したプロジェクト設計が大切なのだ。

#長い文章を書くのがめんどくさいので要旨だけ。

プロセスを起動しているから？

プロキシの解決になぜか時間がかかったりする。

非力なマシンだと結構固まる。

・アプリケーションショートカットを利用して思ったこと

iPhoneのお気に入りを「ホーム画面に追加」みたいで便利。ただ、アドレスの表示を、どこかに残しておいてほしかった。

・プロセスについて

ウィンドウの数＋タブの数だけプロセスができる。

１ウィンドウ１タブで２プロセス。

一つ目のウィンドウ１タブ（２プロセス）＋２つ目のウィンドウ３タブ（４プロセス）＝６プロセス

ウィンドウを司るプロセスが落ちるとまとめて落ちるのかな？

Android携帯にAndroid Marketを計画するGoogleに続いて、マイクロソフトからはWindows Mobile向けのアプリケーション販売サービス「Skymarket」が登場するようです。シアトル近郊向け求人サイトに掲載されている「シニアプロダクトマネージャ募集」広告によれば、Skymarketは「Windows Mobileアプリケーションを配布・販売したい開発者のためのマーケットプレース」サービス。また要求される経験・技能の説明によると、Skymarketの開発者コミュニティ向け立ち上げはこの秋、商用サービス開始はWindows Mobile 7の発売と同時とされています。

マイクロソフト、Windows Mobile 7からApp Store風サービス Skymarketを開始 – Engadget Japanese

マイクロソフトのこういう、良い意味で節操が無いところが嫌いじゃない。

・要素へのアクセスにインテリセンスが使えない（つまり実行時解決）ような作り。

・下記のような、基本の機能をラッピングしただけで秩序も何も無い集合体。

ゴミのようなメソッド例

public static bool IsNullOrEmpty(string value)
{
return string.isNullOrEmpty(value);
}

・プログラミングしなくても良いが、良く分からない設定ファイルをガリガリ書く必要がある。（独自の設定ファイルを書く必要があるのでもちろんインテリセンスによる補助は無い。）

・無駄に例外をCatchする事を推奨しているようなログ機能。

・システム開発からフィードバックされた内容を元に作成するのではなく、想像で作ったものをシステム開発に適用し、不整合があってもアップデートしてくれない。

・フレームワークを利用するプログラマが複雑な処理を書くとき、その複雑さを気持ちよく分散させる方向に誘導できる構成にする。

　シンプルの組み合わせで複雑な処理が書けるように誘導する。

　運用・保守時に泣いて喜ぶ作りである。

　

結局のところフレームワークの役割とはプログラマがシステムを作るときに楽であれば良いわけではなく、設計するときの指針にも影響を与えるべきだし、運用・保守のサイクルを見据えた時にメンテナンスしやすいシステム開発に誘導する必要がある。

フレームワークが開発のベースにあることで全てのフェーズの整合性と方向性を決定づける必要がある。

また、フレームワークは生きている必要がある。

毎日でもフレームワークは整合性と方向性を一致させたまま改善されていく必要がある。

今年も始まったらしいTech.Ed 2008。

どうも時間割を見ても僕的に熱くなれるものがなかったのと、もちろん興味深いのはあった。

体力的な問題と、金銭的な問題で今回は見送り。

私がフレームワークを作るときの無意識に採用している指針を思いつきで羅列して改めて意識してみる試み。

・めんどくさい事や、高度なことは全てフレームワーク側の責務。

・ユーザ（ここで言うユーザとはフレームワークを利用して開発をする人）は決められたストーリーに沿ったコードを書けばよい。

・だからユーザにオブジェクト指向を意識させない。

・ユーザから見たインタフェースはシンプルでなくてはいけない。

・一言で言えばテンプレートベースの開発。

・○○対策等(SQL挿入等)は可能な限りフレームワーク側で処理を行う。ユーザに、そのためだけのコードを書かせない。

・インテリセンスを有効活用できるようにする。

・コードを書かなくても良いが、書くことも可能である。

・拡張可能である。

・ユーザはSQLを書かなくてよい。書けば拡張できる。

・ユーザはDB製品を意識しなくてもよい。

・複雑さを集中させないための制限を作る。

（例えばコードの中に複数のテーブルを結合するようなクエリはかけない。

そんなのは、問い合わせの目的を名前にしたビューやストアドにすればよいだけだから。）

・フレームワークにする意味がなくなるので、出来るだけルール等の運用に逃げない。