ニンニクたっぷりのラーメンを食べた後、前から気になっていた、ソールにスポーツシューズのテクノロジを採用した革靴であるRUNWALKを購入するべくアシックスの歩人館に向かう。
ちなみに店は銀座ＩＮＮ２の一階に入っているのだが、ステップとしては
３Ｄで足型計測
↓
それに合わせて自分にあった靴をいくつかチョイス
↓
はき比べて購入
という手順。
店員さんが異常に丁寧で好感が持てる。
ニンニクくさくてごめんなさい。
まぁ、
http://www.asics.co.jp/walking/bc/runwalk/tech/
このページを見て貰えばどんな特徴があるのか分かります。
ちなみに、ヘリオスクッションのタイプを購入。
http://www.asics.co.jp/walking/bc/runwalk/detail/~WAT614
明日からの通勤が楽しみです。
・フレームワークを利用するプログラマが複雑な処理を書くとき、その複雑さを気持ちよく分散させる方向に誘導できる構成にする。
シンプルの組み合わせで複雑な処理が書けるように誘導する。
運用・保守時に泣いて喜ぶ作りである。
結局のところフレームワークの役割とはプログラマがシステムを作るときに楽であれば良いわけではなく、設計するときの指針にも影響を与えるべきだし、運用・保守のサイクルを見据えた時にメンテナンスしやすいシステム開発に誘導する必要がある。
フレームワークが開発のベースにあることで全てのフェーズの整合性と方向性を決定づける必要がある。
また、フレームワークは生きている必要がある。
毎日でもフレームワークは整合性と方向性を一致させたまま改善されていく必要がある。
・要素へのアクセスにインテリセンスが使えない（つまり実行時解決）ような作り。
・下記のような、基本の機能をラッピングしただけで秩序も何も無い集合体。
ゴミのようなメソッド例
public static bool IsNullOrEmpty(string value) { return string.isNullOrEmpty(value); }
・プログラミングしなくても良いが、良く分からない設定ファイルをガリガリ書く必要がある。（独自の設定ファイルを書く必要があるのでもちろんインテリセンスによる補助は無い。）
・無駄に例外をCatchする事を推奨しているようなログ機能。
・システム開発からフィードバックされた内容を元に作成するのではなく、想像で作ったものをシステム開発に適用し、不整合があってもアップデートしてくれない。
最近というか2000年にさしかかる頃から「オンラインとオフラインを区別しないでもっとシームレスに意識できないものかな。」と思っている。
もうテクノロジ的には充分可能なことが実現出来ていないか限定的にしか実現できていない。
例えば新しい校舎たてるくらいなら、その予算でオンライン小学校とか中学校とかでもよいはずだ。
送り手と受け手。
この場合、先生と生徒だけど彼ら自体はオンライン上に生きているわけではない。
オンラインを利用して物理的な距離を回避しているだけだ。
人は物理的なこの世界に生きる以上、その制約を最大限に受ける。
ただそれをキャンセルしようというだけのことだ。
校舎の老朽化も、
先生の人手不足も、
先生の能力のばらつきも、
登校が困難な生徒も、
電車通学が苦痛な生徒も、
フィジカルないじめも、
(メンタルないじめは残るが)
物理的に一つの場所にいないといけないという制約から起きる様々な不都合から解放する事が可能だ。
学校を会社に置換えても良い。
ほかにも、喫煙者と非喫煙者のコミュニケーションに生じる物理的な不都合も完全に回避できる。
実現するために必要なことがあるとしたら、それは人の意識の変化だ。
今やそれこそが、最大のボトルネックになっている。
最近、こつこつと汎用でありながらインテリセンスが有効になるようにこだわったデータ検索とデータ更新のクラスを作成したが、
（MakeGenericTypeが無かったらもうちょっと大変だった。)
今日はそれを利用した簡単なメンテナンスデータアクセス向けサービスのクラス群を自動生成するツールがやっとできた。
コードジェネレータは難しくないけど、力業だと思った次第。
これで、簡単なデータメンテナンスサービスや検索サービスについては、自動生成で対応できる。
クライアントを実装するときもちゃんと項目名がインテリセンスで出てくるように作ってあるから項目名のミスもないだろうし。
インタフェースは具象だからＷＣＦテストクライアントでテストできるので楽ちん。
あとは認証部分のお勉強。
