うーん、賛否両論の、ちばデザイン
ここのニュース
千葉初の県ロゴに県民からブーイング！
http://www.nikkansports.com/general/p-gn-tp0-20061112-115958.html
などにかいてあるけど、洗練されているかどうかは別として、話題にはなりましたよね。
いっそのこと、ここまできたら、このデザインで、ひらがな全部つくってしまって、
ちば書体
として出したら、有名になるかも。。。
なんか、出てきそうな予感？？それはない？？
うーん、賛否両論の、ちばデザイン
ここのニュース
千葉初の県ロゴに県民からブーイング！
http://www.nikkansports.com/general/p-gn-tp0-20061112-115958.html
などにかいてあるけど、洗練されているかどうかは別として、話題にはなりましたよね。
いっそのこと、ここまできたら、このデザインで、ひらがな全部つくってしまって、
ちば書体
として出したら、有名になるかも。。。
なんか、出てきそうな予感？？それはない？？
ちょっと、あとで、話を広げたいために、基本的な話を考えます
（ちなみに、広げたい話というのは、View側（画面が普通だが、ロボットもあり得る）でどこまでの機能を持たせるのがいいかという話）
ＭＶＣとか、ＥＣＢとかいう考え方において、システム外からの入出力の機能は、Ｖ（Ｖｉｅｗ）が行う。ＥＣＢの場合はＢ（バウンダリ）が行う。
で、Ｃ（コントローラー、これはＥＣＢでも同じ）が、内部のＭ（モデル：ＥＣＢの場合はＥ（エンティティ））を、Ｖ（Ｂ）から受け取った値を渡して呼び出し、その結果を受け取って、Ｖ（Ｂ）に返していく
そして、Ｗｅｂシステムの場合、ブラウザが、Ｖｉｅｗにあたる。。。
って、ここまでは、当たり前に論じられるが、ちょっと待った。
ブラウザって、実は表示してるだけじゃなくって、汎用的なクライアントプログラムなんじゃないだろうか？それが証拠に、もし、クライアント側でもＪａｖａＳｃｒｉｐｔなどのプログラムが書け、この場合、
表示しているＨＴＭＬの内容がＶｉｅｗ
ブラウザが、OnLoadとか、イベント処理関数を呼び出すけど、この呼び出しプログラムが
Ｃ（コントローラー）
実際のＪａｖａＳｃｒｉｐｔプログラムは、モデルとも考えられる。
こう考えると、モデル部分を分離できるはずだけど、事実、プログラム的には分離できるし、分離したほうがいいかもしれない（ただ、ＪａｖａＳｃｒｉｐｔやＡＪＡＸを書く人は、そういう意識はないので、だらだらと、ＨＴＭＬの中に書き込まれてしまって、分けわかんなくなっちゃうことが多いんだけど）
仮にそうやって考えると、ブラウザ側も、ＭＶＣを構成している、ただし、サーバーから見た場合、クライアント入出力というのが、Ｖｉｅｗにあたっているということになる。
これを、図示すると、こんな感じになる
ここで、ＭＶＣを３重の円であらわすことはまずないが、ここではあえて３重の円であらわす。
そーすると、ブラウザからみれば、画面入出力もＶｉｅｗだが、サーバー通信も外部との入出力という意味ではＶｉｅｗと同じ話になる。このとき、コントローラーは、画面のコントローラーと、通信のコントローラーでは違うのが普通（ＡＪＡＸのXMLHttpRequestのonreadystatechangeで、かえってくるところを指定するが、ブラウザが、この指定された関数を呼び出す部分が通信のコントローラーになる）。
で、コントローラーから、内部のプログラム（ＪａｖａＳｃｒｉｐｔ）が呼ばれることがある。
そーすると、サーバープログラムも３重の円で表せる。このとき、ＶＩＥＷの画面表示側は、クライアントとの通信になる。
では、クライアント側における、「サーバーとの通信」は、サーバープログラムにおいて、なんになるかというとＳＯＡで、他サービスとの通信ということになる。
もちろん、サーバプログラムのＳＯＡの他サービスの通信がないものもある。
同様に、クライアント側でも、サーバーアプリとの通信をしないプログラムも作れる
（クライアント側で、計算だけするプログラムとか）
さらに、クライアント側のプログラムは、ブラウザじゃなくってもいいことになる。
たとえば、ロボットに繋ぐことを考えてみる。
アンケートをロボットが読み上げ、答えを言ってもらい、その答えを自動認識で文字にして、ＨＴＭＬのＣＧＩと同じような形で、書き出し、サーバプログラムを呼び出した場合、サーバプログラムから見たら、ブラウザと同じ呼び出し方をされているので、同じように処理することになります。
つまり、この場合、ブラウザかロボットかというのを問わない。
もう１つの例として、アンケートを考えると、複合機につないで、出力はＨＴＭＬの内容を、紙に出力し（白紙のアンケートができる）、入力は、その複合機でスキャンしてもらうと、書いた内容を自動認識して、ＨＴＭＬのＣＧＩと同じような形で、書き出し、サーバプログラムを呼び出した場合、サーバプログラムから見たら、ブラウザと同じ呼び出し方をされているので、同じように処理することになります。
つまり、この場合、ブラウザか複合機かというのを問わない。
ってかくと、Ｗｅｂの世界の人には、思考的な話であり得ない話と思うかもしれないが、じつは、これができると（いまは自動認識がそこまで言ってないと思うが、いってるのかな？）、便利なケースがある。セミナーのアンケートとか。。
セミナーのアンケートは、紙に書く。普通Ｗｅｂではない。なぜなら、会場できにゅうしてもらうとき、みんながパソコンにつながっているケースというのは、すくない。
じゃ、ケータイから入力してもらえばいいじゃん！っておもいかもしれないが、もし、セミナー会場で、ケータイから入力してもらうとなると、ケータイの電源をＯＮにしないといけないことになる。そーすると、みんなマナーモードにしてもらうというのは無理があるため、セミナー中にケータイがなってしまう。これはこまる。なので、セミナーでは、ケータイの電源をＯＦＦにしてもらうのがふつうだ。なので、ケータイからアンケート入力も難しい。
ま、現実的には自由文章入力のところは、文字認識が難しいので、無理と考えられがちだが、逆に言えば、ここだけは、スキャンして、白黒画像としてとって、Ｂａｓｅ６４で送信すれば、あとは、○×やチェックに対して、反応すればいいようにすればいい（塗りつぶしてもらう形にする？？）ので、将来的にあり得ないとは言い切れない。
っていうことで、サーバーもブラウザも、その他のクライアントアプリもＭＶＣで統一的に考えることができる。じゃあ、この考えの場合、どこまで、クライアントに機能をもたせ、サーバーにどこまでの機能をさせるか？ということになるけど、それについては、また別の機会に書きたいと思う。
情報処理とは何？から、Ｈｅｌｌｏ Ｗｏｒｌｄを各種言語で出力するまでの流れをかく、シリーズHello World以前のプログラム言語のつづきです（このシリーズは、土日に書きます）。
■ここまでのストーリー
ここまでのストーリーをまとめると、
●コンピューターは情報を処理する機械で、
●情報を処理するとは、
必要な入力データ（情報）をいれて、
なんらかの処理をさせて、
目的となる出力データ（情報）を得る
ことである。
●で、情報を処理するのには、処理内容を指示するわけですが、それがプログラムであり、
●そのプログラムは、以下の種類の文で構成される
・処理を命令する文
・条件によって、処理を分けるための文
単純に条件をわける文
繰り返しする文
・変数を宣言する文
●そのプログラムには、同じようなことを何度も書くところがあるので、
それらを何度も書かないでいいように、１回書いたら、次からそれを
呼び出す方法がある。それがサブルーチンや関数である。
●で、プログラムに対して、データを入力するが、そのデータは
従業員データなど、いろんなプログラムで何度も利用することが
ある。そこで、それらを、ファイルという形で保存している
●ファイルは入力だけでなく、ファイルに出力することもあるし、
プログラムもファイルのカタチで書いて保存する
●ファイルがいっぱい集まると、管理に困るので、まとまりにわけて
管理する。このまとまりがディレクトリ（フォルダ）となる。
●ファイルの中身は、データの集まりとなるが、従業員データの場合
従業員一人一人の名前、住所、担当部署、年齢が繰り返し出てくる。
このように、ファイルの中に、同じ形式のものが繰り返しでてくる
という場合、その繰り返しを構成する１つ１つをレコードという。
で、今日は、このレコードについてです。
■レコードと項目
で、前回、ファイルは、レコードの繰り返しになっているものと、そうでないもの
（たとえば、プログラムのソースファイルとか、テキストで文章を打ったものとか）
があるという話を書きました。
で、レコードの繰り返しになっているものについて書きます。
そのレコードとは、たとえば、従業員１人１人をあらわしているレコードの場合、そのレコードの中に、従業員の名前、住所、担当部署、年齢などのデータを含んでいます。
この名前、住所、担当部署、年齢を、項目ということにします（要素といったりすることもあるし、いろいろあるけど、ここでは、項目としておきます）
なお、レコードと項目の関係、実は、表で表せます。
項目１ 項目２ 項目３ ・・・・
レコード１
レコード２
レコード３
：
：
っていうかんじです。で、表を表現するソフトである表計算ソフト（スプレッドシート）の場合、レコードを行(あるいはロー）、項目を列（あるいはコラム、カラム）といいます。
■項目と型
で、年齢とか、名前とかは、具体的にあらわせるわけです。
たとえば。。
名前 菅山 かおる
生年月日 1978.12.26
身長 169cm
体重 56kg
出身校 古川商業高校（現・古川学園高校）
出身地 宮城県岩沼市
ポジション リベロ
最高到達点 293cm
とかとか。。
で、このとき、文字でずらずら、コンピュータで書いていますけど、ファイルとして、保存する場合、これは文字でずらずら書いているわけではなく、０と１で表現します（０と１で表現すると、電気的、磁気的に表現でき、保存できるようになる）
このとき、文字で表現するより、数字（整数）なら、もっと効率よく表現できる方法があります（２進数）
というか、まず、数字を０と１で表現する方法を決めて、
文字は、ある文字は、この番号と割り振り（コード）
日付は、ある時を０として、そこからの経過時間を数字で表現し
小数点付きの数字は、ある数＝あるかずＸ１０の何乗というかたちで、表現する
など、いろいろあります。
そこで、値を効率よく表現して、その値が、どういうように表現されたかをみんなにわかるようにします。
で、その「値がどういうように表現されたか」というのを型といいます。
整数の型は、Integerで、
文字はCharで
日付はDateで
小数点付き数字はfloat（あるいはDouble、表現する長さが違う）
などなどです。
■固定長レコード
そういう形で、上記のレコードの例を表現すると
名前 文字の複数あるもの
生年月日 日付(Date)
身長 整数（Integer)＊
体重 整数（Integer)＊
出身校 文字の複数あるもの
出身地 文字の複数あるもの
ポジション 文字の複数あるもの
最高到達点 整数（Integer)＊
（＊具体的な数字は、小数点つきかもしれないが、ここでは整数で扱っている）
っていうことになります。
ここで、型が整数とか日付は、ファイル上、どのような大きさにするか、きまっています。
問題は、「文字の複数あるもの」です。これは、どれくらいの長さか決まりません。
そーすると、このレコードの大きさが決まらないので、保存するときに、どのくらいの大きさを用意すればいいか、さらに処理するときに、どのくらい大きさを用意すればいいか、わからなくって不便です。
でも、たとえば、名前は、５０文字もある人はいません。たいてい２０文字以下です。
出身校も３０文字もあれば十分でしょう。
ってことで、予想できる最大限の大きさをとって、
名前 文字（２０文字）
生年月日 日付(Date)
身長 整数（Integer)＊
体重 整数（Integer)＊
出身校 文字（３０文字）
出身地 文字（２０文字）
ポジション 文字（２０文字）
最高到達点 整数（Integer)＊
ってすれば、大きさは確定します。
このように、１レコードの大きさが決まっているものを固定長といいます。
ここで、固定長のメリットをまとめておきます。
＜固定長のメリット＞、
・大きさが決まっているので、処理がかんたん。領域を取るのも簡単
＜デメリット＞
・想定外以上に長いとき、プログラム、ファイルをすべて修正しないといけない
でないと、入らない文字は切り捨てないといけない
・項目（の順番）と、型がわからないと、利用できない
っていうことになります。
■可変長レコード
逆に、１レコードの大きさが決まっていないものを可変長といいます。
これは、固定長の正反対。っていうことは、固定長とメリットデメリットが逆になります。
＜可変長のメリット＞
・想定外以上に長いときでも、プログラム、ファイルを修正しないでよい
・項目（の順番）と、型がわからなくても、利用できる
＜デメリット＞
・大きさが決まっていないので、処理が面倒。領域を取るのも面倒
っていうことになります。
でも、「処理が面倒。領域を取るのも面倒」といっても、前回いった、
サブルーチンで、だれかが、その処理部分を作ればＯＫなわけですし、
それより、メリットのほうが、意味が大きいので、最近では、可変長は良く使われます。
■可変長レコードの例１；ＣＳＶ、タブ区切り
では、問題は、可変長の表現の方法ですが、
名前 文字の複数あるもの
生年月日 日付(Date)
身長 整数（Integer)＊
体重 整数（Integer)＊
出身校 文字の複数あるもの
出身地 文字の複数あるもの
ポジション 文字の複数あるもの
最高到達点 整数（Integer)＊
とあるとき、
・項目はすべて「文字の複数あるもの」にする（整数も日付も文字で書ける）
・項目の区切りを、タブなど、その要素でありえないものを入れてしまい
・レコードの終わりにもその要素でありえないものを入れてしまえば
項目の値を取り出すことができます。
で、区切りをタブにしたものが、タブ区切り、カンマにした場合、ＣＳＶ（かんませぱれーてっどばりゅー：「値をカンマで分けた」って言う意味）となります。
（どちらもレコードの終わりは改行とします）
カオル姫の例をＣＳＶでかくと、こんなかんじ
菅山 かおる,1978.12.26,169,56,古川商業高校,宮城県岩沼市,リベロ,293
■可変長レコードの例２；ＸＭＬ
しかし、ＣＳＶの場合でも、項目（の順番）までわからなくてもＯＫというわけではありません。たとえば、カオル姫の例を
菅山 かおる,リベロ,169,1978.12.26,56,宮城県岩沼市,古川商業高校,293
と入れ替えられてしまったら、違う項目だと思ってしまいます
（上の場合、生年月日がリベロになってしまいます）
ということは、項目の順番は変えられない、省略できないということになります。
その結果、カオル姫の名前と最高到達点しかわからない場合、
菅山 かおる,,,,,,,293
と、カンマだけの項目を書き出さないといけません。
これが、１００も２００も続き、飛び飛びに入っていたりしたら、なにがなんだかわかんなくなります。
そこで、項目の順番入れ替え可（ただ、入れ替える人は少ないと思うけど）省略も可とし、項目の順番がわかんなくても処理できるようにしたのが、ＸＭＬです。
ＸＭＬの場合
＜名前＞菅山 かおる＜/名前＞
＜生年月日＞1978.12.26＜/生年月日＞
＜身長＞169＜/身長＞
＜体重＞56＜/体重＞
＜出身校＞古川商業高校＜/出身校＞
＜出身地＞宮城県岩沼市＜/出身地＞
＜ポジション＞ リベロ＜/ポジション＞
＜最高到達点＞293＜/最高到達点＞
（上記＜＞は、本当は半角）
ってかけば、たとえば、省略して
＜名前＞菅山 かおる＜/名前＞
＜最高到達点＞293＜/最高到達点＞
となっても、どこの項目が送られてきたかわかるので、処理できます。
自分の知らない項目なら無視すればＯＫです。
なので、このＸＭＬ、便利です。
たしかに、タグの部分が無駄なのですが、その程度の容量の無駄は、最近のディスク容量の大型化、通信速度の向上で問題ないということです。
で、さきほど、デメリットについて
「処理が面倒。領域を取るのも面倒」とかき、そのあとで、そういう処理をするサブルーチンがあればＯＫっていうことを書きましたが、ＸＭＬの場合
ＸＭＬの処理をするものがＸＭＬパーザー（Xalanなどがある）で、
ＸＭＬの領域を保持し、操作を提供するものの１つがＤｏｍです。
Ｄｏｍの操作方法は、このブログでも、書いています。
ということで、長くなりましたが、今回はおしまいです。
アクセス
トータル
ランキング
