たまには

投稿日：2012年06月28日

投稿カテゴリー： SE4

突然ですが、問題。
毎月２２日はショートケーキの日　なのだそうです。
なぜだか、わかりますか？

カレンダーを見ればわかるのですが・・・・・
２２日の上には必ず１５日が乗っています。つまり、１５が乗っている。いちごが乗っている。おあとがよろしいようで～

　ある本に、「日付の処理ができれば、君は、初心者脱出だ～！」ってなことが書いてありました。
　我々が使っている暦は、グレゴリウス暦というもので、ローマ教皇グレゴリウス１３世が制定したものだそうです。
それまでは、ユリウス暦を使っていました。この、ユリウスというのは、かの、ユリウス・カエサル（シーザー）のことで、７月をJulyというのは、彼にちなんでつけられました。ついでに、８月を、August というのは、初代ローマ皇帝アウグストスにちなんでつけられたそうです。
ちなみに、６月を、水無月といいますね、梅雨で水はた～くさんあるはずなのに、水が無い月とは、これいかに。興味のある方は調べてみてください。

日付の処理が・・・というより、入力チェックというのは、初心者のみならず、面倒なのです。
しかし、ここをちゃんとしないと、システムダウンの原因になってしまいます。水際で防ぐのが肝要。
入力値チェック（バリデーションといいます）がめんどくさいのは、入力は、文字型。文字型＝なんでもＯＫ　ってことですから、これをユーザに任せると、どえらいことになってしまいます。たとえば、未来から来たやつ、過去から来たやつ、「平成２４年」、「H24」、「平成二十四年」・・・・
これを、日付型の許容する範囲に誘導しなくてはなりません。そのためには、正規表現、日付型の特性、全角半角変換などが必要になります。
あなたの常識は、人類共通の、と、言わないまでも、日本人共通の常識　なんて、思っちゃいけません。
人は、間違いを犯すもの。だから、入力時、入力ミス、作り手の意図と反する入力に対応できる事が必要となります。
このことを、「fool proof」といいますが、直訳すると、愚か者にも耐えられるといったところでしょうが、これほど強い意味ではなく、何も分かっていない人が扱っても大丈夫　といったところでしょうか。つまりは、ユーザーフレンドリーなシステムということでしょう。
マン・マシン・インターフェースの設計は、ユーザーフレンドリーという観点から設計する必要があるのでしょうね～。
そうでなくても、「あんたの作ったシステムは、あんた自身使いやすいかい？」と、自問自答するだけでも違ってくると思います。

あ～、今やっているシステム、考えなおさなきゃな～。
使いにくいったらありゃしない。

H.I in SE04