- ねこのこべや -
- ねこのこべや -
前回の「打鍵振動論」はいかがだったでしょうか。
猫としてはかなり電波と自覚しつつもかなり気に入っているのも確かで、
ここから得られる結論は「猫自身かなり電波」になるのですが、
戦々恐々なのは
「打鍵振動論」について補足するならば、
切っ掛けは、
『ヒトは、鍵盤の「気持ちよさ」を評価するときに 音を情緒的に評価する仕組みを流用しているのでは？』
と思ったことで、発想の論拠としては
『「音」も「打鍵」も「思考を言葉で乗せる媒体」だから、 脳の同じような領域で処理をしていても不思議じゃないかも』
です。 結果、ヒトの脳は打鍵中に指に感じる「振動」を音的解析にかけて「気持ちよさ」として評価するといった 仮説を立ててみたわけです。
この仮説の結果、キーボードの気持ちよさの正体は、
鍵盤には固有振動があり、この振動を連続打鍵で上手く共振・増幅できると 心地よさを感じる。（連弾ハーモニー快楽説）
打鍵開始時に波形の外形が、打鍵の第一印象を決めている。（打色説）
なのよっ!・・という解を得るわけです。 ・・・我ながらなんとも電波な論理展開。でもでも、結構好きな考えなので困った、困ったです。
こういう、妄想にも近い思いつきの科学考証は、もちろん科学としては「とんでも科学」ですが フィクションの世界観を肉付けする要素として魅力的なものです。 猫の敬愛する皆川ゆか先生は一見オカルティックな世界に徹底的に「科学」的考証を加え、 恐ろしいまでの世界観を作り上げる、そんな小説家です。
今日の猫日誌は、そんな皆川ゆか先生の久方ぶりの新刊「真・運命のタロット8 ≪吊された男≫、そして…のお話です。
「運命のタロット」は皆川ゆか先生が1992年に開始した、SF小説(?)です。
タロットカードにやとる大精霊がアカシック・レコードに刻まれた運命を護る陣営「ティターンズ」と 運命を変える陣営「プロメテウス」に分かれ闘いを繰り広げる といった背景をもった作品なのですが、 これだけきくと、オカルティック・ファンタジーなお話を想像しがちです。
しかし、時の縦糸をさかのぼれる存在達ゆえ、未来に因がある因果律の許される舞台での 壮絶な複線劇と、おそろしいまでの運命の絡み合いといった 皆川ゆか先生の圧倒的な作劇力と、 「タロットに思念を転写される」とは、思念とは?という疑問にたいし、 「そういうものだから」とせずに徹底的にSFしてしまう 世界観の奥深さは、 この作品を希有の存在へと押し上げています。 真に「世界観」を持ち合わせる数少ない作品の一つです。
運命のタロットは、講談社X文庫という土俵の悪さも手伝って、 一度は打ち切りの憂き目にあいますが、X文庫の方針転換にともない 真・運命のタロットとして復活。 「少女小説」のくびきを離れた運タロは、第一部での主人公の波瀾万丈な生活が 幸せに思えてしまうぐらい過酷な運命を主人公に課します。 胸を締め付けられるような展開は、読者を深く深く惹きつけます。
皆川ゆか先生のガンダム・オフィシャルズ執筆と、その後のスランプ(?)、 講談社の判断期間などが重なって、実に5年ぶりのシリーズ再開となった 真タロですが、その出来は運命のタロット全22巻(とはいっても、今回の≪吊された男≫と≪世界≫は上下巻になってしまったので、 ホントは24冊なのですが・・・)のファイナルステップとして圧巻の出来でした。
興味をもった方は是非是非読んでくさいませ。
運タロの世界観は、運命決定論。その人間の意思で行っていることさえも、 すでに決められたことであるという世界で、 時の縦糸を超えることが出来るようになってしまった存在が 運命を変えようと必至にあがくお話です。
世界が何者かの手でつくられたとき、未来も過去も一つのピースとして 組み上げられねば世界自体が崩壊してしまいます。 この小説を読み始めたころの猫は「運命論」という言葉以上の感慨は得ませんでしたが、 今のプログラマな猫さんは、この世界観と似たものをよく目にするようになりました。 それはオブジェクト指向でつくられたプログラムです。
オブジェクト指向のプログラマは、小さなオブジェクトに小さな責務を持たせます。 責務とは、そのオブジェクトが「必ず行わなければならない務め」、 そしてオブジェクトはオブジェクトにメッセージ(お願い)を送ることが出来、 あることをお願いされたオブジェクトは 自身の持つ責務でその願いを果たすのです。
そんな風にプログラム全体を小さな責務をもった小さなオブジェクトの集合として 築き上げていくのがオブジェクト指向プログラミングです。 オブジェクト指向のプログラミングは、オブジェクトとオブジェクトの関連こそが プログラムを形作っていくのです。
ここで勘の良い方は気付かれたかと思います。 「お願いされたって、それを果たす責務をオブジェクトが持っていなかったらどうするの?」 この疑問は至極まっとうで、そのような場合プログラムは不具合を起こします。 いわば、小さなオブジェクトがたった一人責務を果たせないだけで、 プログラムという世界全体が崩壊するのです。
ですから、あたしたちプログラマは、世界が崩壊しないよう、 一つ一つのオブジェクトの運命をも決してしまいます。 それぞれのオブジェクトは、受け取った「お願い」に応じて自身の意思で 責務を果たしたように見えたとしても、 そこに「お願い」がいくこと、そして「お願い」がどのように果たされるかということまで、 全てあらかじめ「決まったこと」なのです。
これは、運タロの「世界」ととても似ているわ、と猫は思うのです。
「お願いされたって、それを果たす責務をオブジェクトが持っていなかったらどうするの?」
このとき、オブジェクトは「例外」を発します。 例外が発せられるとプログラムという世界はスタックを巻き戻しながら プログラムの根幹まで自身を破壊しながら巻き戻っていき、 プログラムのエントリポイントまで撒き戻ると、プログラムは例外で終了します。
この様は、運タロ作中でアルバトイが話した「世界の崩壊」ととてもよく似ています。 たった一つの禁忌で世界が崩壊してしまうということは、 逆に言えばその世界がその禁忌を犯さない「運命」を持っているとも言い換えられます。 猫たちプログラマは、プログラムという「世界」にその様な運命を課すことを仕事としています。
オブジェクト指向設計で構築するプログラムの「世界」は運タロ的な「運命決定論」な世界です。 オブジェクトは一見状況に対して主体的に選択をしているようにみえるのですが、 そのオブジェクトが選択を迫られる状況も、どのような選択を行うかも、 行った選択が「世界」に対してどのような影響を及ぼすかも、実はプログラムが開始された時点で すでに決まっていて、覆すことはできません。
と、まあこんな風に、猫は運タロ的な「世界」はとてもプログラマには身近なモノだわ〜、と思うのですが、 じゃあ、そもそもそんな「運タロ的世界」を設計するオブジェクト指向とはなんでしょう?
実はオブジェクト指向って、プログラムの中の世界だけでなく、現実世界の分析を行える、 そういうたぐいの手法なんです。 実際に業務システムを設計するときは、システムの中だけでなく、それを使う人、そのシステムに関連するモノ、人 全てを含めて「現実世界でのシステム」をオブジェクト指向的に分析したのち、 システムの部分だけプログラムとして設計、実装するんです。(乱暴な言い方ですがホントです)
オブジェクト指向的な世界って、実はあたしたちがいるこの「世界」なのではと、 ふと思えてしまうくらいオブジェクト指向は上手に世界を分析します。 もちろんオブジェクト指向分析は人間が世界を認識する仕組みを利用して物事を分析しようとする手法だからで、 世界の本質とは関係ないのかもしれません。
でも、現実の世界を人が認識するしくみは、自然淘汰的に世界の本質に沿ったものになっているかもしれません。 それを応用したオブジェクト指向分析・設計が導く世界が、運タロ的ならば、 もしかしたら私たちの「世界」もアカシック・レコードに沿って実行されるだけの、 「時間」にそって築かれていくものではなく、あらかじめそのような形でそこにあるだけのモノかもしれません。
・・ちょっと怖い話になってしまいました。(TT) 今日も猫のアンテナは絶好調です。
暇はあるものじゃなくってつくるもの。
この言葉を一番最初に言われた時、猫は「それはきれい事よっ!」と反発したものです。 ですが、 今は「ホントにそうだわ・・・・」と思っています。
猫は今、本当に時間が無い状態です。 お仕事が大変なことになっているからです。
常時休日出勤こそまだしていませんが、日頃の睡眠不足をまかなうための 睡眠時間だったり、会社では出来ないお仕事 ――参考資料を捜したり、過去の猫の仕事集を漁ったり、仕事用の勉強をしたりと、 休日自体も「平日の仕事」に間接的な影響を受けている状態で、 1日をまるまる使ってしまうサイトコンテンツ(猫のキーボードルーム、トラックボールルームなど)はちょっと無理、 なので更新が完全に止まってしまってます。
そんな愚痴を引っ張り出して、「だから、更新出来ないのです」と結ぶのは簡単なのですが、 でもでも、人間、暇を作れば作れちゃうものよね。 今の猫はそれでもサイト更新したり、PSOをやっちゃったりするのです。
そんなこんなで 今、この猫日誌を書いているのは、歯医者さんの待ち受け時間だったりします。
だから・・・、ドリルの音があたしの文章をかき乱すのは、 しょうのないことなんです。・・・たぶん。
世の中には2種類のキーボードがあります。 それは、「打ちたいキーボード」と「打ちたくないキーボード」です。
でも、その差を作り出す原因を特定するのはとても難しいことです。 高いキーボードだけが良い物ではないという事実があるからです。
良い物を味わうと、前の物が使えなくなる・・というのはよく言われます。 いわゆる舌が肥えるというものですが、 キーボードに関しては確かに所有台数が1桁台のときはそう言うことがあるようですが、 それ以上のキーボードを味わってしまうと、段々と悪食になるようです。
たとえは、猫の大好きな みみらぼ さんちは、 なんでもござれの総本山ですし(失礼)、 かく言う猫も人のこといえた口ではありません。 しかし、「悪食になった」 = 「良いもの悪いものの区別が付かなくなった」と言うわけではないですし、 もちろん「ボーダーラインが下がり切った」訳でもありません。
猫的には、「よりいろんなキーボードの良いところに気付く様になった」というのが しっくりきます。では新しく気付くようになった「良いの法則」とは なんなのよ?と聞かれてしまうと 猫はとても困ってしまいます。 「上手く説明できないけれど、何かある」としか、言えないのです。
新たな良いキーボードの法則は何か・・・。 これは猫がここんところ、ずっと考えてきたことです。 考えて、触って、思って、最近ようやく ちょっとしたアイデアが浮かんだので、猫はちょこっと日記にメモしておこうと考えました。
今日の猫日誌はそんな日誌です。それでは始めましょう。 キーワードは、「打鍵は振動する」です。
打鍵にはリズムがあります。単に思考の紡がれるタイミングで押下するのではなくって、 ある一定のリズムに乗せて文字を紡ぎ上げるほうがより気持ちよく打てます。
そしてキーボードには、どうやら個別のリズムを作り出す因子があって、 タカタカタカッと打つリズムは人だけでなく、キーボードにも依存します。 このリズムが持ち主の打ち方に合っているか ・・・これが主観的なキーボード評価において、高配点になっているのじゃないかしら、 というのが、「打鍵周波数論」(ああ、偉そうではずかし・・)のスタート地点です。
そして、猫がここから繋げたのは、 打鍵感とは「音」にとても近いのではないかしら・・と言うことです。
音には、「高低」「強弱」「音色」があります。
かいつまんで説明すると、音は「波」です。
空気を伝わる粗密の波、これが音の正体です。
音を発すると水面に石を投げ込んだようにきれいな粗密の波が作られて、
その空気の粗密波をあたしたちは「音」として認識します。
だから、「波」の「波形」こそ、音の性質を決める大切なものです。
伸びる音は周波です。伸びている間だけサインカーブな音の波が伸びていきます。 音の「高低」は、この波の「周波数」です。 早ければ高くって、遅ければ低い音になります。
では音の強弱は何かというと、音の振幅です。どれだけ波の高さが(空気の粗密のコントラストが) 高いかで、音の大きさが決まります。
では、最後の「音色」とは何なのかというと、 「最初に音の波が生じた、最初の波形の形」です。 最初に空気に力を加えたとき、複雑な形の波形が絡まり合います。 これらの全体の外観の形を、あたしたちは「音色」として感じています。 だから、音を録音して、音の先頭のインパクト部だけ消してしまって聞かせると、 音色が解らなくなるそうです。 ――音の世界ではこれをエンベロープ(外套)と言うようです。
というわけで、素人な猫の説明ですので、突っ込みどころ満載だったとおもいますが、 音の正体というのはこんなところ。
キーボードルームを続ければ続けるほどよくわからなくなるのが、 「打鍵の気持ちよさ」というパラメータです。
当初は、強いコントラストをもったタクタイル(触知性)――猫がキーボードルームで「打ったぞ感」と呼んだそれこそが、 打鍵の気持ちよさの最有力パラメータだと思っていました。 ThinkPad Xシリーズなどクリック感の強いメンブレン・ラバードーム機は、 それなりに評価が高いものですし、俗に言うカチカチ・メカニカルが一定の 評価を得ていることも、「打ったぞ感」こそが「気持ちよい」に直結するのではと 考えたわけです。
ところが、猫の長くもないキーボードマニア歴は それでもこの「打ったぞ感 = 気持ちよさの第一パラメータ説」に多くのイレギュラーを 教えてくれました。
例えば、Cherry MXリニアアクションなスイッチはタクタイルなどというものが存在しません。 しかし、猫の指はその気持ちよさを感じます。 また、東プレ Realforceシリーズは、全体の押下圧を下げ打鍵無音部のノイズを 極力排除したおかげで、ピークフォースこそ弱い物の高コントラストなタクタイルを実現しています。 猫論理によるとこれも「打ったぞ感」がしっかりあることになり、気持ちよいキーボードということに なるのでしょうが、現実にはRealforceは打ちやすいけれど、決して気持ちよいキーボードではありません。
打ったぞ感が気持ちよさの正体ではないとすると、 キーボードの気持ちよさとはなんなのでしょうか・・・。
キーを押下すると、その押下圧曲線に従ってキーが押し込まれていきます。
キーを押す力を緩めると、キーは自身の反発力で元の位置に戻っていきます。
―― 「キーの押下」という現象は、だいたいこんな感じですが、 実際の「キーを打つ」というのはこれが連続して起きることとイコールでは無い気がします。
キーボードの気持ちよさを語るときに、一つのキーだけをピョコンと押して、 「あぁ、気持ちいいわぁ〜・・・」とご満悦する、なぁんてことはありません。 タカタカタカッ、と連続して「あぁ、いいわぁ、これ・・・。」となるのです。 つまり、単体押しではないけれど、連続して押したときにある「何か」こそ、 打鍵の気持ちよさの正体なんじゃないかしら、と思ったわけです。
複数の連続打鍵にあって、単なるキーの押下にないもの、 それはリズムとか旋律とか言う物だと思います。 「音」が「音楽」になる為にある物。それこそが情緒的な気持ちよさを、 スペックシートでは語れない何かを鍵盤にもたらしているのではと、 猫は仮説を立てました。
気持ちよい打鍵というのは、多分「波にのれる」打鍵です。
1つめの押下が作り出す波に2つめの押下が乗れたとき、 つまり、前の押下の残響音に次の押下がうまくハモれたときに、 「気持ちよさ」が発生するのではないかしら? きっと、一つのキーを押すと、キーボードは(もしかしたら人も)「うゎんうゎんうゎん」と振動して、 その振動のリズムに次の入力が乗れると、気持ちよく打鍵が続いていく・・・。 それが「気持ちよい打鍵」の一つの形です、きっと。
そうなると、「打ったぞ感」の強いキーボードが気持ちよく打てるのは、 「リズムを作りやすい」そして「リズムに指を乗せやすい」から。 自分の意図したタイミングで入力を投入できるので、自分の気持ちよいように打てる・・、 それが気持ちよい打鍵感に繋がるのでしょう。
ただ、そういうキーボードの作り出すリズムは強制的で、 思考のスピードまでもキーボードが押しつけてくるから、 相性というものがあるし、「打鍵を楽しむ」ゆとりの無いケースでは 「打ったぞ感」の強いキーボードは 「リズムを強制される」点、そして、 「リズム誘導性の対価として、パワーや衝撃を支払っている」点がマイナスファクターとして働くため、 かえって打ちにくくなるケースもあるようです。
逆にRealforceの、「打ったぞ感」が強いのに気持ちよくない と言う特性は、 ピークフォースの弱さから、 ヒトの打ちたいリズムにキーボードの持つリズムが負けてしまうため、リズムを誘導してくれないし、 そうなるとキーボードのリズムと違うリズムで打たれるので、なんともハモらず気持ちよくない・・ということかもしれません。
きっとキーボードには「固有振動数」とでも言うべき特性があって、 その波形のコントラストが高く、振幅が大きいものは 人への干渉力が強く、リズム打鍵を誘導しやすいため「気持ちよい」という評価を得やすいのでは 無いのでしょうか。
キーボードも楽器と同じく、一つ高さの音(一つの周波数の音)しか出ないわけでなく、 打つときの力加減なのどによって、その振動数も変わってくるものでしょう。 もちろんある一定の力以上(または以下)でないと、上手く波形を刻めないものもありますし、 キーボードの持つ"リズム"が、個人の持つリズムとどうしても合わない場合もあるでしょう。
キーの押し込む重さや戻る強さが大きい と言う要素は、きっと打鍵振動の振幅に直結する要素で、 大きな波はヒトを飲み込みやすいものですし、 飲み込まれた結果が心地よい、というものなのかもしれません。
また、小さなさざ波にも、それを読みとって声を重ねてあげるのならば、 きっとクリアな美しいハーモニーが楽しめるのかもしれません。
メカニカルキーボードに話を持っていくと解りやすいのですが、 同じスイッチでも、筐体が変われば確かに打鍵感も変わります。 しかし、基本的な打鍵の性質が同じことも確かなようです。
前述の「残響」なイメージで考えると筐体の作りの違いが打鍵感に影響を及ぼすのも 説明付きそうですが、なんかそれだけではない気がします。 たとえば、ひっかがり感のあるキーボードでも (ひっかがり感をマイナスファクターとして認識しているにもかかわらず)気持ちよいというのは、 きっと「ひっかがり感」と「気持ちよさ」が独立した要素として人が認識可能だからでしょう。
「同じスイッチで違う筐体の場合の同じところと違うところ」、「良くない打鍵感でも気持ちよいキーボード」 これらを見るに、打鍵感にはもう一つ、分けられる要素がありそうです。 猫はこれは「打色」ではないかと考えました。
きっと、打鍵にも「音色」ならぬ「打色」なるものがあって、 それは打鍵版の「エンベロープ」とでもいうべき、押下圧曲線にでるような部分、 波形の最初の先頭部なんじゃないかしら。
そして「打色」はその他の要素よりも繊細で、筐体の作りなどの影響を受けやすいのでは と思うのです。
打鍵の気持ちよさとは、これらのキーボードの性質をうまくつかって 綺麗なハーモニーを奏でられるかと言うところにあります。
これは人の指のリズムと、鍵盤のリズムのハーモニーという意味の他に、 思考と打鍵のハーモニーという意味も被せてあります。
指と楽器の奏でるリズムに、 思考という波が綺麗にハモった時、 ヒトは得体の知れない気持ちよさを感じるのでしょう。
そして、気持ちよさこそ正義です。
その人にとって気持ちの良いキーボードは、他の誰が何を言おうと よいキーボードです。 また、キーボードとの付き合いが長くなると、 いろんなキーボードの持つ「個性」と上手くハモれるようになってきて、 楽しみの幅が広がります。
猫にはこれこそが、鍵盤収集の醍醐味なのよね、と思えるのです。
キーボードは言葉を紡げる道具です。
人は言葉を喋るときどうしても抑揚を付けてしまいますが、 キーボードの入力も言葉を紡ぐという作業ゆえ、きっと抑揚に感情の波を乗せたがるのが 人の性なのでしょう。
キーを打つ、と言う作業はキーボードと人のデュエットです。 だから、猫は「音」をヒトが認識する要素を、キーボードにそのまま喩えられるのではと 考えました。
今回のコラムで言う振動数とは、物理的なキーボードという物体の固有振動数という意味ではなく、 ヒトが打鍵を認識する上での「比喩」としての振動数です。 きっと、人は音と言語の結びつきとどこか似たようなところで 打鍵を認識しているハズです。だから、「音」の認識をキーボードに喩えた 猫のアイデアも、それほど大ハズレではないんじゃないかと、 あたし自身はうぬぼれています。
今はまだ仮説、思いつきです。 誰かが似たようなことを考えて、キッチリデータを積み重ねているのかもしれませんし、 積み重ねてないのかもしれません。 専門家さんにとっては、あまりに馬鹿げたお話で、検討以前の段階のネタなのかもしれませんし、 またデータを積み重ねた結果、間違いだと解っているのかもしれません。
でも、思いつくだけはタダです。 そしてここは「猫のプライベートな日誌」なのですから、 何を書いてもOKなハズ。その結果「電波さん」と呼ばれようとも・・・・。
自分が好きでないというのは、不幸で可愛そうなことです。 好きでない自分が世界に居ることの不幸と 世界に関わりたいという自分の気持ちの板挟みに 常にさらされるから、
でも、昔の自分のほうが今の自分より好きだという人は もっと不幸せなのかもしれないと、ふと思いました。
昔の自分に戻りたくても戻れないのだから、 昔の好きな自分と今の嫌いな自分を比べることは いつでもずっと自分のことが嫌いな人より よりリアルに重々しく感じるのかもしれません。
スイカにお塩を掛けるとより甘いように、です。
――最後の「おち」で間抜けになっちゃうのが あたしの あたしたる由縁かしらね・・・。(^^;
「えっ・・・?」
あたしは、最初何を言っているのか解らなかった。
プログラマの経験が浅いと言う彼に、現在の開発環境――Microsoft.NET環境で作るWebアプリケーション、そのための環境を 教えてあげるのがあたしの仕事だった。 だから、簡単な課題と一人でどうにかなるだけのヒントと時間をあげて、 あたしは彼がそれをこなせたかどうかを確認しに来たのだ。
「呆然」という空気を纏うあたしに、さすがにバツが悪くなったのか、それとも単に聞き取れなかったと思ったのか、 彼は同じ呪文を繰り返した。
「僕って、コードを読んだりはなんとか出来るんですけど、 自分で何かコードを書くことって出来ないんです。」
あたしは解ってしまった。「ああ、彼は初心者プログラマじゃない、プログラマ未満なんだ」
その思考はあたしの頭のフィールドの球をコツンと突いた。 突き動かされた球は他の二つの球にぶつかって、 そのふたつの球は それぞれ「ああ、これからこのプロジェクトをどうしたらよいのかしら」と、 「なんだか懐かしいな、あたしが駆け出したときは確か・・・」の二つのポケットにストンと落ちた。
あんまり綺麗に落ちたものだから、
あたしは思わずニコリと笑った。
彼にそんなことを聞いて、あたしが「大丈夫よ、安心なさい。」と笑ってみせることが出来たのは、
多分きっと、そういうことだ。
今、猫は.NETをつかった開発、というか、オブジェクト指向をつかった開発を初めて行おうとする 開発チームさんの水先案内人のようなお仕事をしています。
もともとは、開発チームの一員であればよかったのだけれど、 あれよあれよと言う間に引率の先生に祭り上げられてしまいました。 でもこれは相手だけが悪いのではなくって、一重にファールボールも取りに行きたい猫の性分も大きいのですから、 文句を言うのは筋違い。うーん、今苦労を背負わされちゃってる私としては、過去の自分をひっぱだいてあげたいわっ!
そんななか、さすがに人員不足はどうしようもないから 人を増やしてもらったのですが、 つれてこられた人材は「VBをやったことがある」「それほど開発経験は長くない」プログラマさんとの事。 本当はJavaとかでOOな開発プロセスを経験したことがある、出来れば分析設計のスキルのある開発者さんが 欲しかったのですが、贅沢は言えない状況ゆえ、まぁ、「乗り換え」は意外に楽だからと ちょっとしたトレーニングを始めた猫なのですが、 そんな営業から聞いた彼のプロフィールは嘘じゃないけどJAROに訴えられそうなものでした。
トレーニングで発覚したところによると彼のホントの経歴は、 VBで開発している現場に途中からはいって、 「これをベースにデータ構造にあわせて代入してるとこだけ差し替えて」みたいな、 ちょこっとソースの改変を指示どおりにやった経験があるというもの。 規模にかかわらず、自分だけでプログラムを作った経験はなかったのです。
――ああ、これでは、プログラマさん以外には解らないですね。 んーと、そうね。
『日本語で仕事の出来る人』という人を雇って、 なにかごくごく簡単な文章を書いてもらおうとしたら、 「私、日本語は読めるけど 作文は出来ないんです。」 と、彼。
「ほえっ!?」っと聞いたら、 「書けない、ってわけじゃないんですよ。」に続けて、
「今までは、請求書のような定型文書があって、宛名の部分だけ入れ替えればいい・・みたいな 仕事はこなしてきたので、日本語は出来ると思います。 でも、一から手紙を書いたり、ちょっとした文章をかいて、といわれても、 ちょっと出来ません。」
ですって。うーん・・これって「日本語で仕事出来る」なのかしら・・・。
――以上、たとえ話、終わりっ。
あたしとしては、既に手を顔の前でクロスした後のような心情なのですが(わかるかしら・・・(^^;) )、 悪いのは彼を放りこんだ会社の営業さんで彼ではないですから、責めてもなじっても始まりません。 今できる最善のことは、彼を早く半人前にすべく教育してあげること、それだけです。
そんなこんなで予期せずはじまった猫のオブジェクト指向プログラミング入門講座ですが、 あとでちゃんとした講座にまとめ上げるため、ちょっとメモしておいた方がいいかしらん、というのを とりあえず日誌にしたためようと思ったわけです。
んーっ、我ながら「ぽじてぃぶ・しんきんぐ」よね。 あとは、営業さんににっこり笑って「金属バットと釘付きバット、どっちが好き?」と 質問してあげれば万事OKというものです。えへへ。
愚痴が長くなりましたが、まったくの言語初心者に初めての言語としてOO言語を教えることになりました。 「初めてプログラム言語としての手続き言語」や「手続き言語ユーザの初めてのOO言語」ならいざ知らず、 「初めてのプログラム言語としてのOO言語」を教えるのは猫にとってもまったくの初めて。
記憶やひらめきを駆使しながら、直感的に「ピンッ!」と来てもらうために、 いろんなたとえ話をひねり出したのですが、 うーん、結構いろんなたとえを捻りだしたわぁ・・・、と我ながらビックリ。
良い
こういう「思いついたよしなきこと」を「内容の妥当性はともかく」として「とりあえず書き留める」のが 猫日誌の役目です。 ですので、ここはメモメモ、メモしておこうかしらん。
オブジェクト指向はポインタとの闘いです。
オブジェクト指向をプログラム言語に実装するに当たって言語設計者はポインタを多用しました。 でも、JavaとかC#、VB.NETは全てがオブジェクトの世界。 全てがオブジェクトの世界なら、変数は全てポインタになるじゃない、 だったら「ポインタ変数」の概念は要らないわね。・・と、 見かけ上ポインタを廃しました。
でも、これがなかなかオブジェクトのコード上の振る舞いを理解できなくするわけで。 「クラス」=「オブジェクトのひな型」という認識にすら、 なかなかたどり着けないのです。
三猫注：
「クラス = オブジェクトのひな形」は 解りやすいけど、厳密にいうと間違ってる考え方だと思います。 でも、まずはこの「円周率 = およそ3」的なイメージで理解したほうがいいんじゃないかしら、と思ったり。
良くあるプログラム言語のたとえ話に、「変数」という名の「箱」モデルがあります。
値をしまっておく箱が変数で、 受け取った値は、値だけの裸の状態でそこらへんに置いておくことはできないから、 かならず箱にしまわなくっちゃならない。 (または、すぐに使ってしまわなくちゃならない) という考え方です。
この箱モデルは、普段は解りやすくってよいのですが、 ことオブジェクト指向言語においては たとえ話の矛盾点が多いです。 なぜ矛盾が発生するかは、OO言語の変数は多くの場合ポインタであるからで、 それを意識させない文法を持っている場合、この矛盾を自己解決するのは 結構難しいのでは、と思うのです。
質問です。
一つのモノを、複数の箱に入れることは出来ますか?
(注意：モノは分割不能です。またコピーした場合は別のモノと見なし「一つのモノ」では無いとします。)
つまり、JavaとかC#とか、VB.NETとか言う オブジェクト指向言語で、 「変数=箱」という風に認識していると、どうしても理解できないのがココなんです。 最近のOO言語は良くできているから、大抵のシーンで、 「変数=箱」なモデルと同じようなソースが書けます。 そのつじつま合わせには、涙ぐましい努力のようなものを感じます。 (関数への引数渡しのとき、意識しなければ常にオブジェクトをコピーしてから渡すこととか・・・)
でも、所詮はポインタなんです。 ポインタだと最初から認識していれば、そうそう難しい概念では無いはずです。
三猫注：
ポインタじゃない、参照だ・・・なんて言うかもしれませんが、 どの言語で何と言おうが、ポインタはポインタだと、猫は思います。
逆に「参照」という用語のほうが、言語による意味の違いが多すぎて 使いにくくありません?(特にC++だと「ポインタ演算の出来ないポインタ = 参照」ですし・・)
猫的には、この手の「指し示す変数」はC言語に敬意を表し、すべてポインタ(丁寧な言い方をすると「ポインタ変数」ですね)と 言うことにします。
(「スーパークラス」も「基底クラス」も同じであるといえば同じだし、 そう呼んでいる言語の実装差異を用語の意味に取り上げれば違うものになるし、 そういう類のことでしょう。)
そこで、「箱」モデルに変わって猫が担ぎ出すのは「風船」モデル。 たとえばC#だとオブジェクトの生成はこんな感じになります。
//###################################### // // ※注意!! // // クラス「Yama」は定義済みとします。 // //###################################### // 変数の宣言 Yama mtFuji; // Yama専用変数を宣言します。 名前は"MtFuji"(富士山)です。 Yama mtAso; // 同じく。今度はMtAso(阿蘇山)。 // オブジェクトを生成して、変数に束縛。 mtFuji = new Yama(); // 山クラスのオブジェクトを新しく生成。それを変数mtFujiに束縛します。 mtAso = new Yama(); // 同じく山クラスのオブジェクトを生成して、今度は変数mtAsoに束縛。
「new」で作り出すのがオブジェクトです。 このコード例では「変数に格納」ではなくって「変数に束縛」と 書いてあります。
「えっ、なんで??」と思うかもしれません。 だって変数は値を格納するものと習ったし、ずっとそう言うモノだと思っていたし、 それで問題も起きなかったよ――と。
でも、OO言語の変数は「値を格納するモノ」じゃなくって、「オブジェクトを縛り付けるモノ」なんです。 つまりは、全然違う働きをするものなのです。
手続き言語であえて近いものを上げるならば「ポインタ変数」、「値の在処を指し示すモノ」です。 OO言語の変数も「オブジェクトを指し示すモノ」でもあるし、 言語実装上の本質も「OO言語の変数」と「手続き言語のポインタ変数」はだいたい同じモノです。でもちょっとだけ違う見方もあって・・・。
値(またはオブジェクト)を ポインタ変数で「指し示しているだけ」の状態な場合、 その値(またはオブジェクト)を 指し示しているモノが全て無くなってしまったとき、 値(またはオブジェクト)は、行方不明になってしまいます。
手続き言語の場合は、値を指し示すケース(ポインタ変数で指し示すケース)と 値を箱に入れるケース(変数に格納するケース)があるので、 「ポインタ(指し示すモノ)」という概念がしっくりくるのです。 (どこかの箱にはいってるモノを 他の所から指し示す・・なぁんて使い方が多いのです。)
ところがOO言語の場合は全ての変数が「いわゆるポインタ変数」ですので、 「指し示す」という見方をちょっと捻った方が理解しやすいかも・・。
そんな見方が「オブジェクト = 風船」モデルです。
オブジェクトは風船です。風船のゴム革は、多分風船工場が作ってくれるのですがそれはあまり深く考えないで、 丸い風船、細長い風船、黄色い風船、といった風船の種類(= クラス)が一緒のしぼんだ風船の皮は、 きっとお願いすればいくらでも手に入る状態なのでしょう。 (そう言う風にお膳立てしてくれるのは、言語とその実行環境なので、考えてもセンのないことです。)
あたしたちは、プログラム言語(ここでは、C#にしましょうか)で 「new」と書けば、そのクラスの風船を ぷ――っと膨らませて、オブジェクトを作ることが出来ます。 それはもう簡単に、オブジェクトは出来てしまうのです。
ところが、オブジェクトは風船なので、膨らませてから手を離してしまうと すぐにどこかに飛んでいってしまいます。 そして残念ながらプログラム言語の「手」は忙しく一つの「文」、つまり、
new Yama(); //←ココの文の間だけしか、持っていられない!!
の一行の間だけしか、膨らませた風船を持っていることが出来ないのです。
つまり、オブジェクトを作るだけ・・てのは出来るのですが、 1行の間で「作って、使って、もう用済みですサヨウナラ」とするのでなければ、 どこかに風船の紐を縛っておかなくちゃなりません。
その為の、風船がどっかにいかないように縛りつけとく「フック」が「変数」です。
Yama mtFuji; // フックを作りますよーっ mtFuji = new Yama(); // 作った風船をすぐにmtFujiフックに引っかけます。
だからフックを壊したり(つまり、変数を土台のオブジェクトごと破棄しちゃったり)、 フックから意図をハズしたり(nullを挿入したり、別の風船を引っかけるため、今の風船をはずしたりね) すると、そこにあった風船はどっかに飛んでいってしまうのです。
――これが、オブジェクト=風船モデルの 基幹
三猫注：
飛んでいった風船 (= 見失ったオブジェクト)がどうなるかというと、
の二通りになります。
ラピュタパターンでは、飛行石とヒミツの呪文「リテ・ラトバリタ・ウルス・アリアロス・バル・ネトリール」がないと、 もうラピュタにたどり着けません。 (呪文を唱えると飛行兵が暴れ狂いますが、それはそれ。)
でもラピュタはどこかにあるわけで、 ラピュタをどんどん作って、造る端から行方不明にしていると お空がラピュタだらけ――つまり「龍の巣」だらけになってしまうので、 いずれ世界は暴風のカタストロフに陥るでしょう。 (これを、メモリリークでシステムが落ちた!・・と言う・・・。)
つまりラピュタパターンの場合、 ラピュタが要らなくなったらプログラマが 滅びの言葉を「バルス!」と叫んでラピュタを崩壊させる 義務があるのです。
# 余談ですが「バルス」は「閉じよ!」という意味だそうで、なんかぴったりです。
# 「飛行石=変数」モデルも結構良さそうですし、真面目に「ラピュタで覚えるオブジェクト指向」もありかしら。(笑)
2のパターンは常にお空を巡回パトロールが飛んでいて、風船を見つけ次第撃墜するというもので、 このパトロール機が かの有名な「ガベージ・コレクタ」です。
では、変数こと「フック」は何処に止められているのでしょう。
オブジェクト指向では、所詮は全てオブジェクトなので、 フックをとめる土台もやっぱりオブジェクトです。 (風船に風船を繋げてるんじゃ、結局全部飛んでいってしまうんじゃない、ですって? きっと一番根本の風船「あなたのマシンのウインドウズ」をつなぎ止めているのは、 貴方の目の前にあるマシンなんです。)
オブジェクトにしっかりねじ込んである「フック」はインスタンス変数。 クラスのメンバとして直接宣言したアレです。
一方フックとは名ばかりの一時的な「縛り先」もあって、 これが自動変数。メソッド(関数)の中で宣言して、関数が終了したら 速攻で無くなってしまう、アレです。
こちらも実はオブジェクトにくっついているで、 メソッドにねじ込んであるフックではありません。
このフックはオブジェクトにくっついているモノの、グラグラゆらゆら、 メソッドが終わるまでくらいしか持ちそうもありません。 こんな頼りないものをフックというのは憚られますので、 もうこっちはセロテープとでも言った方が良いかしら。
class YumiFukuzawa
{
//----------------------------------------------------------------------
// インスタンス変数 ――オブジェクトにしっかりネジこんだフック
//----------------------------------------------------------------------
private string onesama; // お姉様をつなぎ止めるためのフック
// オブジェクトにしっかりねじ込んであって
// フックは決して外れない。
//----------------------------------------------------------------------
// インスタンスメソッド
//----------------------------------------------------------------------
//******************************************
// [メソッド名] FindOnesama
// [機能] お姉様を発見なさい。メッセージを
// 実現する手段です。
// 発見したお姉様はしっかり束縛します。
//******************************************
public void FindOnesama( World theWorld )
{
//--------------------------------------
// 福沢祐巳クラスは、
// どのような場所であっても
// 必ず祥子様を発見できます。
//
// 原理は不明(GetSachikoSamaは、
// 言語レベルで実装・・・。)
//--------------------------------------
// 祥子様を発見して私のお姉様として繋ぎ止める ------
this.onesama = ( GetSatchikoSama(theWorld) );
// 関数の終了 --------------------------------------
return;
}
//******************************************
// [メソッド名] SeyHellow
// [機能] ご挨拶なさい。メッセージを
// 実現しちゃう手段です。
//******************************************
public string SayHellow()
{
// 学級を取得する ----------------------------------
// 学級オブジェクトを生成
Gakkyu myGakkyu; // ←自動変数(っていっていいのかしら)の定義
// メソッドが実行されている間だけ、とりあえず
// 生成したオブジェクトを自分のオブジェクトに留めておければ良い
// 「フック」というより「セロテープ」みたいなもの。
myGakkyu = new Gakkyu; // 学級オブジェクトを生成して、用意したセロテープで自身に仮止め
// (このメソッドが終わるまでくらいは、剥がれませんが、
// その後のことは保証しません)
// 学級オブジェクトに私の学級になるように言う
myGakkyu.Init( this ); // 生徒(ここでは福沢祐巳)を渡すと、
// リリアン女学園オブジェクトに問い合わせて
// 福沢祐巳の学級として、自らを初期化します。
// 学級クラスの性質として、リリアン女学園オブジェクトの在処は
// 必ず知っています。
// 挨拶を作って返す --------------------------------
return( myGakkyu.GetGakkyuName() + "、福沢祐巳です。" ); // 生成例)"一年椿組、福沢祐巳です。"
}
}
ここで注意すべきは、セロテープの定義はメソッドの中でしか出来ないのですが、 セロテープが風船の紐を貼り付ける先は、「メソッド」ではなくって、 メソッドの所属するオブジェクトです。
また、セロテープの粘着力は、メソッドが終わるまでは保証されますが、 その後のことは保証されないのでご注意を。
セロテープはメソッドが呼ばれる度にピッピッと貼られていきます。 (同じメソッドを複数回よんでも、どんどん新しいセロテープが切られていきます。) 必要に応じて風船を気軽に沢山留められるのがセロテープの良いところですが、 その代わり粘着力が弱いので、余りながいこと留めておくことが出来ないのです。
風船が要らなくなったらフックからはずして上げればOKです。 フックから外れた風船は空高く舞い上がっていき、 どこかに見えなくなってしまうでしょう。 (そしてお空の巡回パトロールが見つけた端からパァンと割っていくので、 いつかちゃんと壊されるでしょう。)
では、風船がフックから外れるのはどんなときかというと、
というときです。 (留めているのがセロテープの場合は、なにもしなくてもメソッドが呼び終われば 飛んでいってしまいます。)
また、
場合も、結果的に同じことで親子繋がったまま ふわふわ空の彼方に風船は飛んでいってしまいます。
風船に紐を何本でも結びつけることができるので、 一つの風船を複数のフックに留めることが出来ます。 逆に一つのフックには一つの風船しか留められないのですが、 これは、そうですね――風船の紐のさきには結構おっきな輪っかがついていて、 フックの大きさから一つしか引っかけられない・・とでもしておきましょう(^^;
風船にとっての命綱が一本でも繋がっていれば、 ふわふわと浮き上がっていきませんから、風船の繋がっている 全部のフックをはずしさないと、風船を破棄できません。
三猫注：
ちなみに風船モデルの弱点は、 「親風船の紐が全部フックから外れたとき、 子風船が親とは別のフックに繋がっている時」です。
現実の風船を想像すると、子風船がアンカーになって親をかろうじて つなぎとめてくれそうですが、 オブジェクト風船のフックは性能が宜しくないらしく、 逆さになったフックは簡単に輪っかが外れてしまうようです。
変数モデルの場合、箱にしまうのは「値」でした。 だから、「使う時は、箱から値を取り出す」といったシンプルな仕組みです。
ところが、オブジェクト指向の場合、手元に収まっているわけでもなければ、 オブジェクト自体をどうこうしたい訳ではないので困ってしまいます。
オブジェクト指向の場合、もともとオブジェクトそのものをどうこうするわけではありません。 オブジェクトを束縛してまで遣りたいことは、「オブジェクトの持っている何か」を 利用することです。
オブジェクト指向において、「オブジェクトを使う」とは、 オブジェクトを直接どうこうすることではなく、 オブジェクトにお願いしてやってもらうになります。
三猫注：
ですので、本来オブジェクトは自分のもってる変数を 他の人に見せることはありません。
他の人が、その風船のフックに別の風船を引っかけたい場合も、 「この風船をあなたのフックに引っかけて。お願い」 としなければなりませんし、 そのオブジェクトのフックにひっかがっている風船が欲しいときも 「あなたのフックにひっかがっている風船をちょうだい。お願い」 としなければなりません。
ですが、「おまえのフックを直接俺様がいじりたい」という要望 (「めんどくさい(=実装効率)」から、実行速度、はたまた「Javaは使いたいけどオブジェクト指向はしたくない」などいろいろ) があり、C++やJava、C#といった言語は、そういったことも可能になっています。
が、オブジェクト指向で開発するなら、 フックの外部解放は、滅多なことではやるべきではありません。
オブジェクト風船は結構スゴイちからで浮き上がろうとしているらしく、 紐がピーンと張っています。 だから、フック側からオブジェクトの持つ何か(オブジェクトに何かさせたい、オブジェクトの持つ何か) に用がある場合、 フックとオブジェクト風船の間のピンと張った紐を利用して、 糸電話の要領でフックにオブジェクトにして欲しいこと「お願い」を叫びます。 (オブジェクト指向用語的には「メッセージを発行する」と言います。)
するとその「お願い」はピンと張った紐を通じて風船までとどきます。 「お願い」を聞いたオブジェクトは、 自分が知っている「お願い」を行う「手法」を使って、 そのお願いされたことを実行してくれます。 お願いしていることが「あなたのフックにひっかがってる風船をください」だったら、 風船の紐をこちらに垂らしてくれるかもしれません。
つまり、風船の紐は、風船を繋ぎ止めているだけでなく、 風船に対してなにかお願いをしたいときにも必要で、 そう言う目的で紐をフックに引っかけて置いているオブジェクトも あるのです。
三猫注：
糸電話で風船に「何かを頂戴」とお願いしたとき、 風船は何か――オブジェクト指向ですので「何か」は必ずオブジェクト(風船)ですね、その風船の紐を垂らしてくれます。
紐を垂らすだけなので、もともとの持ち主が紐を離さない限り、 頂戴した方とされた方が同じ風船を共有することになります。
この風船そのものを投げてよこす訳ではないのが「風船比喩」のミソなのですが、
たいがいのプログラム言語はこの「風船比喩」を台無しにする特別な種類の風船―intとかcharとかいった風船を持っています。
これらの風船は常に紐を一本しか垂らせない風船で、
もし「頂戴」されたなら、紐を垂らすためにその風船のコピーを作ってそれの紐を垂らさないとなりません。
(説明するのを忘れてましたが、一度フックに引っかけた風船は二度と手で持つことが出来ません。
バスケットのダブルドリブルと同じで、ルール違反になってしまうのです。)
相手がもしその紐をフックに引っかけなかったら、 せっかく相手の為に作った風船も空高く舞い上がってどこかへ行ってしまうわけです。 (そのかわり、相手が受け取った風船の中身を変えるお願いをしても、 自分のもっている風船に影響は及ばないのです。)
無理矢理「風船とフック」を使うと結構回りくどい説明になりますが こういった「特別な風船」はまさに「箱」モデルのほうがふさわしい動きになります。 (実際 言語実装上オブジェクトでは無い場合が多いです。) つまりこの手の風船は箱にしまっておくことしか出来ないもので、 「頂戴」すると相手から直接風船が投げつけられ(!)それを上手くキャッチして 箱にしまっておくのです。
さて、風船―糸電話方式ですが、具体的にどうやって言語に実装されているの?と いうと、実はこんな感じです。
オブジェクトはメソッドを持っています。 そして、オブジェクトはメッセージを受け取るとメッセージ名とそっくり同じ名前のメソッドを起動します。 これは、ソース的にはこんな感じです。
// オブジェクトを生成 ------------------------------------------
Yama mtFuji; // 束縛用に変数を定義
mtFuji = new Yama(); // オブジェクト(種類：山)を作成。 mtFuji変数に束縛
// 山オブジェクトの「山彦」処理を実行 --------------------------
string catchYamabiko; // 山彦をキャッチするための変数
catchYamabiko = mtFuji.ReturnYamabiko( "やっほーっ" ); // mtFuji変数を介して
// その先に繋がってるオブジェクト(種類：山)に
//「ReturnYamabiko(邦訳：山彦を返せ)」
// メッセージを送信
// ↓
// オブジェクト(種類：山)では
// 自身のメソッド(=「手法」の意)の一覧から
// メッセージと同名のメソッドを探し出して
// それを実行する。
// ↓
// 実行した結果、山彦(種類：string)が作られ、
// それが戻ってくるのですかさず変数に結びつける。
オブジェクト指向的にはコメントに書いた通りの流れで 処理が実行されている、と考えるわけですが、 C++の事情――実行効率と「既存文法に極力似せる」というポリシー のおかげで、 実装的にも文法的にも オブジェクトの関数を呼び出している 、になっています。
なので、この手のC++の子供達な言語を使っていると 「風船に糸電話でお願い」――メッセージという概念は、 なかなかイメージがわかないのです。
三猫注：
風船には糸電話メッセージしか送れなくって、
メッセージに応じた風船が持つメソッド(手段)をつかって
お願いを実行してあげる。
場合によっては新しい風船を返して上げる必要があって、
そのときは紐を垂らして上げるから、そっちでキャッチしてフックにとめてね。
――これが、ホントのオブジェクト指向なのですが、 OO言語の実装はそうでないものが多いです。 なぜなのかというと、いろいろ原因はあるのだけれど、一番大きいのはC++のせいかしら、と猫は思います。
C++はオブジェクト指向言語である。なぁんて言うことがありますが、ハッキリ言いましょう。嘘です。 C++は「オブジェクト指向」も「手続き型」を出来るハイブリット言語です。
船にもなるし、車にもなる――そんな水陸両用車をつかまえて、「これは車だっ!」と言うことは出来ます。 車が必要な人が水陸両用車を使ってもちゃんと車として使えるからです。(そりゃそうです。)
でも、「車ってなんですか?」と言う人に「ちょっと待ってて」と車の見本として水陸両用車を持ってくるのは、 どうかしらね、と思うのです。きっと誤解してしまうでしょう。
実はJavaもC#もC++をお手本としている面があって、 C++由来の(OO的には不純物だけど)便利だったもの・実行効率上有利なものなどを いっぱい引き継いでいるのです。
ここら辺は三猫の下手なたとえ話よりも、 あるOOPLな会話を読んで お腹をよじって覚えてくださいませ。(^^
「オブジェクトは風船です。」
この喩え話では「紐に繋げておく」部分が肝なんです。
紐で繋げた風船は、紐を切れば二度と取り戻すことは出来ません。 紐で束縛してると言っても、風船本体は直接手が届かない(声も届かない!)くらいには高いところに浮かんでますので、 フックに「もしもし」と叫んで、糸電話式で風船に「お願い」を出すしかありません。 何かを受け取りたい場合は、風船は浮力で下に放れなくても紐を垂らしてもらうことはできるので不便はしません。
そんな世界がオブジェクト指向です。 ですが、「出来ないお願いをしないか」「直接風船のフックを触りたい」 「紐が邪魔」などなどいろんな現実の欲望を受けて オブジェクト指向以上のことができるのが現在のOO言語です。 (または、その「以上」も含めてオブジェクト指向だ、という意見もあるのです。)
風船モデルはオブジェクト指向の始祖Smalltalkが描いた オブジェクト指向を上手く比喩しています。 このシンプルなOOの世界は、OOを初めて学ぶ人にこそ必要だわっ!と猫は思うのです。
異論はあるでしょうが、モノを教えるとき「シンプルなルール」を教えて、 あえて「例外的」な知識を持たせない、というのが有効だと猫は思っています。
猫は return文を書くとき、かならず 「return( value );」 の様に本来必要でない「()」を書くクセを付けてますが、 これは値を受け取るのに「()」を必要としないイレギュラーはreturnくらいだからです。
Cの構文は美しく、予約語による構文も関数も等しく「if()」「void main()」のような書式に統一されています。 演算子を除けばこの美しき世界がキープされるCの世界ですが、なぜか「return」だけ別ルールなのです。 別に覚えてしまえばどうと言うことのないルールですが、 無垢の初心者にCを教える時にシンプルなルールだけで済むようにすることは、 混乱を生みません。
このほかにも「配列を渡す時は "&arg[0]"」と言うルール (配列名の例外的解釈を教えない。それと、大きいモノを渡すときは必ず&が付くのですよ、というルール)とか、 「for文を使わない」ルール(forよりもwhileのほうがループ手続きを想像しやすいし、forの奇想天外な使い方を素人はしてしまう危険性が怖い)とか、 「関数ポインタやポインタのポインタは教えない」とか(只でさえ混乱のCのポインタ・アドレス周りの文法なので、「ポインタ返し(ポインタでCの習得を挫折する)」にならないように) とにかくルールをシンプルで限定的にします。
理解をスマートにするための選択子の限定。 「節度」を知らないで扱うのが危険なものの原則禁止。 そういう「最小版C」のようなルールを作り上げることで、 最小の期間で「とりあえず半人前」を作る期間を短縮すると言う為のやりかたです。 半人前には(なんとか)仕事を振れるけど、 それ未満だと仕事に関わらせること自体が危険だから。
だから猫は「半人前が加わるプロジェクト」向けのソースでは 限定文法で自身も記述するようにしているのです。 格好悪いし結構ストレスなのですがお仕事だしね、なりふり構ってられないのよっ! です。
もちろん正しさを要求される時(=「Cを学ぶことが自体が目的」とか「教わった人が目の届かないところに行ってしまう場合」など)に 「returnには()をつける」なんていったらもちろんNGです。 猫の目的は「一人前」ではなく「半人前」を作ること。 「半人前」とはあたしの手のひらで踊れる程度のスキルのこと。 手の上で怪我しないように気を配って上げられる状況で、はじめてやって良いことです。
もちろん何時までも半人前というのは誰もが不幸です。 半人前以上になるには、猫のついた嘘(というかしれっ、と教えなかったこと)を 「えーっ」と言ってのけるように自分でなってもらう。 私が教えるのは「自分で出来るようになるとっかかり」だけだから・・・。
だから、猫的には「最小版OO言語」を目指して、 あえて「クラス変数の宣言には必ずprivateを使います」のような「嘘(文法のフリしたルール)」を教えようと思うのですが、一体どうなることやら。
チャオ、ソレッラ! ごきげんよう皆さま♪
いよいよ4月です。学生さんは春休みがあって、学校のメンバも入れかわって あたらしい期を実感できるのですが、 社会人ですと昨日と変わらぬ明日という感じで 何気なくやってきてしまうのが4月1日ではないでしょうか?
猫めも、そんな感じでスルッと4月1日を迎えてしまったのですが、 気付けば今年もエイプリルフールのネタを仕込めなかったにゃあ。 うーん、4月め、侮りが足しです。
Kensingtonの次世代トラックボール Expert Mouse 7ですが、 以前猫日誌でお伝えしたとおり その初見は猫にとって望ましいものではありませんでした。
あれから一月、猫は職場でみっちりExpert Mouse 7を使い込んだのですが、 その評価は、一体どうなってしまったのでしょうか。 ――これは、三猫とExpert Mouse 7の愛と葛藤の記録である!、です。
前回の猫日誌でいろいろ文句を付けていたExpert Mouse 7ですが、 やはり人間なれるもの、だいたい好意的な印象に変わりました。
光学式、ルビー小球支持になったボールですが、 異様なまでの回転の軽さは慣れればこれも悦楽的で、 カクンカクンとした周りだしも、しばらく使いこんでこなれたら ぜんぜん気にならなくなりました。 (これは感覚的な「慣れ」というより本当にカクンカクンしなくなった様子で、 光学式点支持なトラックボールでは普通にある現象なのですが、具体的にはどんなメカニズムなんでしょう??)
また、悦楽的操作感が無いとオカンムリだったスクロールリングですが、 確かに改善の余地は認めるものの、有るのと無いのとでは大違い、 Expert Mouse 5を使っていても思わず カップの淵を撫でてしまうこの手が憎い。 骨の髄まで慣れきってしまった猫は、「いやぁ、スクロールリングって、ほんっとに、いいもんですね」状態、 多少の操作感の不満もアバタにエクボで、どうでも良くなってしまいました。 うーん、人間、便利の誘惑には弱いもの。つくづく怠惰な生き物よねぇ・・。(^^;
と、結局はおおむね好意的な印象にかわってしまったExpert Mouse7ですが、 たったひとつ、どうしても馴染めなかった物があります。 それはExpert Moues史上(たぶん)最も高くなってしまったボールの位置です。
Expert Mouse 7のボール位置は大変高いです。 これまでに比べボール経が小さくなったにもかかわらずボール受け自身を高い位置に置いたため 見事にそびえ立ってしまっています。
 |
| 大地割り、そそり立つ姿 |
これはスクロールリングがボール受け側面を占領してしまったため、 ボール受けの下に光学式エンコーダが滑り込ませるスペースを設けるためと 思われます。
実際、本機のボールは、ボール径が小さくなったにもかかわらず、 Expert Mouse 5よりも高くそびえ立ち、さすがにパームレスト無しでは つらいということをKensingtonも認識したか、(おそらく)初めて外付けパームレストが付属するようになりました。
しかし、このパームレストを装着したExpert Mouse 7は、デカイデカイといわれたExpert Mouse Pro (Expert Mouse 6)を上回る ボリュームで猫の猫の額ほどの机を圧迫します。う〜ん、できれば装着したくないのよねぇ。
Expert Mouse 5から大幅増量したボールの高さですが、 一番手っ取りばやい対策法は慣れること。 人体の神秘の力「慣れ」を持ってしてこの高さを克服できれば、 お金要らずの場所いらず、Expert Mouse 7の美しいデザインもそのまま堪能できると いい事ずくめです。
 |
| Expert Mouse 7 |
というわけで、本体のみの持込でバリバリ使い込んで慣れちゃえっ! と、 猫は張り切ってコロコロしたのですが、――わずか3日で限界が来ました(TT)
ボールが高いので、常時ボールに手をかけたポジションで待機したい猫の手は 常に手首がえびぞり状態。 しかも親指の付け根や小指の付け根でボタンをクリックするのが好きな猫は、 まさにフォークボールを投げようかというスタイルでボールを操ることになったのです。 ・・・結果、見事な腱鞘炎に・・。うう、手の甲が痛いよぉ(TT)
使うときは手首を浮かせば良いということは解るのですが、 ここまで高さがあると、手首を浮かすと肘も浮くような・・・。 ほとんど体育会系の筋トレになってしまうのも、「なんだかな〜」なのです。
そんなこんなで、猫は悟ったのです。――パームレストがなくちゃ、だめです(TT)
本来ならここで純正パームレストの出番なのでしょう。 でも猫は、単体のExpert Mouse 7のデザインが好きなのです。 こういうとき、役に立つのが サードパーティのパームレスト。 ジェル、シリコン、低反発ウレタンと、癒し系新素材が出るたびに バリエーションを増やしてきたパームレストですから もう「よりどりみどり」です。
そんななかで、猫がチョイスしたのは3Mのミニジェル。 ひんやりとした硬めのプニプニ感とクリアでスマートなデザインが演出する清潔感が素敵なパームレストです。 ちょうどExpert Mouse 7の弧を描いた下弦にぴったりマッチングして なかなかの可愛らしいさ。 早速お買い上げして装着(?)です。
 |
| Expert Mouse 7 with miniGel |
しかし、しかしです。 このジェルパッドをめいいっぱい本体に近づけても、手のひらの付け根には届かず、 どうしてもホントの手首(脈を取るような位置)で止まってしまいます。 そうするとなんだか手首が苦し痛い感じでどうも落ち着きません。
結果どうにもこうにも ポディションが決まらず、 効果を発揮する前にリタイヤ。・・・ExpertMouseがもう少し手前に短ければ などと思うのですが、基本的に線で触れるように狙ったミニジェルですから、これは猫の選択ミスというところ。 うーん、残念無念です・・。
いまいち安定感に乏しかった ミニジェルの反省を生かし、 もうちょっとソフトに変形するプニプニ感と、広い頂上面積の パームレストを選ぶことにします。 と、いうわけでELECOMのディンプゲル シングルパッド でリベンジです!
実は このdimp gelは猫が日ごろExpert Mouse 5で愛用しているもの。 同じExpert Mouseでの使用実績にいやがおうにも高まる期待。んーっ、勝利は我にあり! ですわっ!
 |
| Expert Mouse 7 with ELECOM dimp gel single pad |
さてさて、極楽Expert Mouse生活は送れるのかしらん、といろいろ試してみるのですが、 どうもこちらもしっくりこない・・・。 やはりボールとパームレストの距離が遠いと感じます。
Expert Mouse 5の手前絶壁をやめてなだらかに傾斜させたデザインのおかげで、 逆にパームレストが欲しいところが本体傾斜部になってしまった様子。 とはいえ本体やジェルパッドを削るわけにもいかず。うーん、困った、困ったわ。
・・・だから 付属のパームレストは本体の上に一部被さるデザインなのね、と至極納得。 純正品は良く考えてあるのねと納得すると同時に、 ああ、なんだか解りきった結論を出すのに無駄な投資をしちゃったわ、と ちょっとガックリモードな三猫です。へみぃ・・・。
結局、純正はすごいのね、という結論に至った猫です。 しかし純正と言う割には「ピタッと感」が今ひとつ。 アメリカさん的にはこの程度一致してれば実用上問題ないでしょ、 といったところなのでしょうが、日本人の猫的にはもっと一体感が欲しいところ。 ここはお国柄というものなのでしょうか?
 |
| Expert Mouse 7 "the Exceptional comfort" |
純正のパームレストは、乱暴に言えば 10cm四方の厚さ1cmのウレタンパッド。 その発想の基本はボールを沈められないなら机を上げちゃえです。
本当は机に穴をあけて本当に1cmばかり沈めてしまうのが理想なのでしょうけど、 その代わりとして机を底上げしてみましたなパームレストです。 このパームレストを装着すると、 Expert Mouse 7を1cmばかり水に沈めたウォーターラインを作り出し、 見事にボールの高さを相殺します。
いかにも後付設計といった感もあるこのパームレストですが、 さすが純正、なかなかご機嫌な操作感で、猫の実感としては「これならば慣れられる」といったところ。 ああ、はじめっから使っていればよかったわ。
このパームレストを装着すると、手前の2ボタンが若干ボールに対して低すぎる感もするのですが、 パームレスト無し / 有りを両立させるのには致し方なかったのかしら?とも思います。 猫的にはこのパームレスト、箱詰めの都合ではずせるようにしてある くらいの位置づけの かなり重要なパーツなのね、としみじみご納得です。
しかしながら、これで満足する三猫さんではありません。 確かに純正パームレストは良い出来です。すっぴんのExpert Mouse5 くらいの ポディショニングが実現されます。 でも猫的にはもうすこし高さが欲しいのも事実。 これは、親亀小亀方式しかありませんわっ!
 |
| Expert Mouse 7 with SANWA AUPPLY TOK-GELB16BK |
というわけで、見て解りやすい構成になりました。 サンワサプライのノートPC用ジェルパッドTOK-GELB16BKを、 純正パームレストの上に乗っけちゃいました。
純正パームレストはデザイン遊びとして中央上部に出っ張りがあるので、 ぴったり乗るわけではないのですがそこはご愛嬌、 5mm強の嵩増しですけど 三猫的フィット感は上々です。
ようやく満足のいくボールと手の高さを得ることが出来ました。 な、長かったわ・・。
もともとボールの高さが高くなっちゃう大玉機、 これまでのExpert Mouseが「出来るだけ低く」と企業努力を重ねてきました。
ところが本機Expert Mouse 7は いろいろな新機構と内部スペースの取り合いをした結果、 ボールのサイズは小さくなったのに、逆にボールの標高は高くなってしまいました。 「出来るだけ低く」のExpert Mouse でも「ボールの位置が高い」と言われることがあったくらいですから、 本機のボールの高さは(すくなくとも猫にとっての)「慣れ」のボーダーラインを割ってしまいまいた。
そこらへんはKensingtonもよく解っているようで、この問題は次世代Expert Mouseへの課題としておいて、 とりあえず本機ではパームレストを標準で付属させることで回避したといったところ。 実際、パームレスト付きの操作感は悪くないです。
しかしこれは、あくまで「手とボールの位置関係」のお話。 パームレストで机を嵩上げした分の辻褄は、肘や肩、腰で折り合いを付けなければならないわけで、 そこはまた一つの問題になるわけです。
これはもうどうしようも無いわけでして、 Expert Mouse独特の操作感と、スクロールリング、光学式エンコーダ & 人工ルビーの点支持と言う 他にはないメリットと、ちょっと右腕が高くなっちゃうというデメリットの ガチンコ勝負、取捨択一になるのかしら。
とりあえず新型での改善を望みつつ、それまではExpert Mouse 7を使おう。 なんだかとっても贅沢さんですが、 猫はそんな感じです。(ああ、バチがあたりそうです。)
なんのかんの言いながら、猫は毎日コレを使っているのです。
| SEO | [PR] おまとめローン 花 冷え性対策 坂本龍馬 | 動画掲示板 レンタルサーバー SEO | |
