- ねこのこべや -
- ねこのこべや -
先日の猫日誌に間違いがありました。
(訂正前)
すっかり疲れてしまった猫は もう一度2階に上がってExpertMouse7を購入しようという気力がうせてしまいました。 おかげでムダづかいしなくてよかったぁ。
(訂正後)
すっかり疲れてしまった猫は もう一度2階に上がってExpertMouse7を購入しようという気力がうせてしまいました。 おかげで後でお買い物する楽しみができてよかったぁ。
お詫びして訂正します。
――というわけで、ExpertMouse 7を買ってしまったのです。
とりあえず写真をば。 じゃ〜ん、これです。
 |
| Kensington Expert Mouse ver.7.0 |
超絶快楽生活を期待してお迎えにあがったのですが、 うーん、微妙、微妙なのよね･･･。
とり合えず、おことわりなのですが、 これはアクマで初見の感想です。 猫はExpert Mouse 5に慣れきっていますし、 今の猫は「Expert Mouse 7」に振り回されてる状態なのです。
そういった段階での、ファーストインプレッションなので、 これを元に「ダメポ」判定しないでくださいませ。
まず、驚かされたのはボールの回転の異様なまでの軽さ。
ベアリングからルビーに変わったため、 ボールと支持部の摩擦が減って軽い力で回ることは 勿論予想していたのですが、実際の操作感はこれを上回る軽さでした。
もう凄いを通り越して気持ち悪いまでに軽く回るので、 ボールの中が空なんじゃないの?なんて思って、ボールを持ち上げてみるのですが、 ちょっと小さくなったとはいえ ExpertMouse5の玉とどっこいどっこいの重量があります。
うう、これが マグネットコーティング――じゃなかった、人工コランダムの力かっ!? とKensington脅威のテクノロジーに猫は驚愕を禁じえません。
ボールの回転も 支持構造がエンコーダの都合に左右されなくなったために、 回す方向や力の掛け方に応じて跳ねたりするようなことも無くなり 総じて安定感がグンとアップした感じです。やはりシンプルストラクチャは強い!ということでしょうか
――と、ここまでは、いいことずくめのような感じで書いてきましたが、 実は現時点では猫はこの操球感、あまり良く思っていません。
まず、予想されたことですがルビーによる点支持になったため、 静摩擦と動摩擦のギャップのため、止まっている状態から 回転しだすまでにはある程度の力がいるのに、回り始めるといきなり 軽くなるため「カクン」「カクン」と動きだしてしまいます。 そしてこの大玉の慣性とこのカクカクっとしたストップ・スタートの 感触は、氷の上をソールの磨り減ったゴム靴で歩くかのような制動の難しさを感じます。 正直猫は、このボールに振り回されっぱなしです。うまくあやつれないよぉ・・・。
ただ、Microsoft の Trackball Explorerをはじめて使ったときも そんな印象を受けたので、猫自身がなれることと 使い込むことで状態がこなれることで 解決できるかも・・とも思っています。 この軽くて重いボールには 確かにクセになっちゃいそう片鱗が伺えるのよね〜。
ボールの回転について、もうひとつ。 確かに安定しますし、ベアリング支持にくらべて回転がウルトラノイズレスになったと 思います。でも、操球の面白みや悦楽性は減ってしまったなぁと思うのです。 つまり、実用度アップで趣味度ダウンと言った感じ。アクマで今のところの感想ですけど。
これは、しょうがないのかしらん・・・。残念。
今回ExpertMouseにスクロールリングが初めて搭載されました。
スクロールリングというアイデアはトラックボールにホイールを持ち込む手段として 非常に優れていると思うものの、まだこなれてないよね、とも思うのです。 操作をしていると、 実用ラインは超えているもののこのクラスの入力デバイスに見合った 感触はないのよね。ExpertMouse7のスクロールリングは 操作感がチープで気持ちよさにかけています。
Kensington自身もこのスクロールリングを扱いかねているところがあるようで、 リングを支持する摺動グレードの樹脂チップも トラックボールファンの記事を見ると初期型ExpertMouse7は 3点であったらしいのですが、 猫の購入したものは5点支持です。
また同様に初期型は ホイール回転時のクリックを演出するマグネットが 排除されているようです。(猫の購入したバージョンでは復活しています。)
ここら辺の構造については、将来の「トラックボールルーム 個別面談」に譲りますが スクロールリングが鬼子になっちゃってる原因は、マグネットによる回転ノッチの演出にありそうです。 マグネットがリング全体を引っ張ってしまうため、 常に片輪走行のような状態でリングが回ってしまい、 そのため、3点支持では結局安定した品質が出せず、場当たり的な修正として5点支持にしてマグネット復活・・ というシナリオだったんじゃないかしら、というのが猫の推測です。
正直ExpertMouse7のスクロールリングは未だ未完成といってよいと思います。 スクロールリングというアイデアはとてもよいものなので、 ここら辺はぜひ 次世代のExpertMouseで完成させて欲しいものです。
ExpertMouse7はついに標準でパームレストが付くようになりました。
これまでのバージョンもパームレストがあったほうがいいね、という声が いっぱいあったのですが、これはKensingtonがユーザの声にこたえた結果というより、 ExpertMouse7の拡張で、もはやパームレストが 「あったほうが良い」から 「必須」になってしまったからでしょう。 なぜならExpertMouse7は過去Ver.のExpertMouseよりボールが高い位置にくるように 成ってしまったからです。
ボールが小径化したのに高さが高くなってしまった理由は、 やはりスクロールリングで、 スクロールリングがボールソケットの側面を大きくとってしまったため、 光学エンコーダを底面側に配置せざるを得なくなってしまったからです。(多分)
またボタンのクリック方向もボール側に倒すように変更されました。 これもリングの関係でボタンのヒンジ部を移動させたからです。
猫の私的な感想では、ExpertMouseに接木した「スクロールリング」という枝は、 かなり上手にくっついている物の、まだまだ馴染んだとはいえない状態だと思います。 だから、親木であるExpertMouseに小さな歪みをもたらしてしまってますし、 リング自身も未だ発展中といった印象をぬぐい去ることができません。
猫は今回初めてMouseWorks6.03を使いました。 猫は今まで[oldver]を愛用していたのですが、これはこのバージョンはユーティリティタイプで あるからで、マウスのプロパティのタブとして組み込まれるのがあんまり好きじゃないからです。
しかし、Expert Mouse 7を買った以上はそうは言ってられず 最新版のMouseWorksをようやく試すことができたのですが・・・・、コレはちょっと頂けないです。
一つは、ボールでのスクロールが IEで変になってしまうこと。 レスポンスが非常にわるく、ボールを動かすのと実際にスクロール動作にそれが反映されるのとの 間に非常に不快なタイムラグがあります。 うーん、[oldver]ではそんなことなかったんですけどね〜。
それともう一つ、スクロールの速度調整が、 リングとボールとで、別々に設定できないこと。 かたっぽを立てればかたっぽが立たずで、 猫的にお気に入りだった 「Scroll when Mouse move」 の悦楽スクロールは あきらめざるを得ません。これはMouseWorksを使う理由の半分が吹っ飛んでしまったわけで、 正直かなりガッカリです。
猫が無知なだけで(というか無知であってほしい)なんか上手い方法があるのかも しれませんが、なんだか悲しくなってきます。
かなり辛口な批評になってしまうのは、猫がExpret Mouse 5が大好きだからです Proことver.6は「拡張」であって「後継」ではなく、今回の ver.7はようやく後継機種と言えるのでしょう。 だた、この後継は、今までの道を極めるのではなく、 新天地を求めて大胆に第一歩を踏み出してしまいました。 このExpert Mouse 7が踏み出した新しいExpert Mouse像は とても希望に満ち溢れ、 ver.7はそれを見事に現実の形にくみ上げました。
しかしながら、ver.7は あくまで第一歩、ゴールでは決してありませんし、 こうして見る限り まだまだ道のりは長そうです。
このExpert Mouse 7で、Expert Mouseの実用度は大きく上がりました。 6で実装に失敗したスクロールホイール機構の実装、 エンコーダの光学化、そして単なる色違いではない デザインのリフレッシュなど 非常に魅力的な製品に仕上がっています。
しかし過去の Expert Mouseが持っていた「完全を超えた何か」が 本機には見当たりません。 故に私は Expert Mouse 7 の性能に 十分な満足を覚えながらも、 Expert Mouse 7の先にあるものを ついつい想像してしまうのです。
Kensingtonにはこんなところで満足してもらっては困るのよね。 新生Expert Mouseの伝説は、まだ始まったばかりです。
と、言うわけで、実はこの雑文は Expert Mouse 7 の個別面談として 書き始めたものです。が、なんだかどうも読めば読むほどExpertMouse7が欲しくなくなってしまう 文章になってしまいました。う〜ん。 信じられないことにこんな文章を書いておきながら、 実は猫はExpertMouse7は「おすすめ」だと思っているんです。
基本的に 同じExpertMouseの名を冠しながらも ver.5とver.7はまったくの別物、 比較レビューするほど似ているトラックボールではないのですが、 それを比べて優劣を付けたがっている自分がいるのは、 きっとこの子をまだ良くわかっていないからなんでしょう。
というわけで、お仕事トラックボールにExpert Mouse 7を任命して、 しばらく使い込んでから、もう一回レビューを書いてみることにしました。
だって猫は、この子が大好きになれそうな予感をピンピン感じているのですもの。
今日は喫茶店でアーモンドキャラメルラテを飲みながら まったりと「萌える英単語〜もえたん〜」を読むという至福のひと時を過ごしました。
ああ、しゃーわせです♪
文章というのは面白いもので、 どうしても、どうしても、そのときの自分のスナップショットが見えてしまいます。 感情や気分。特にどろどろとしたストレスは、 真っ白なTシャツに赤インキをこぼしてしまったとき、 どんなに一生懸命洗濯しても、こぼした染みが見えてしまうように、 どんなに友好的で融和的な文章をと心がけても、 そのときの怒り、悲しさ、やるせなさがしつこく残ってしまい、 読む人に不快感を与えます。
こういう文章を愚痴といって、書いている本人にとってはストレス解消という 大きな効果をもたらすのだけれど、読む方にストレスを渡してしまうのですから、 負の感情のバケツリレーになってしまい、大変よろしくないです。
こういうのを出さないように書いても出てしまうのならば、 心のそこから楽しい時に文章を書けばいい。 世の中どこにだって小さな幸せが転がっているのだから、それを見つけて 「よかった」と思えるように日々暮らしていけば万事OKです。
――なぁんて戯言を書いてしまうのは、 世界名作劇場の「愛少女 ポリアンナ物語」をもう一回みたいな〜なんて考えているからなのです。 「よかったさがし」は難しいわぁ。
そんなこんなでせっかくの休日なので、 よかったを探しに、一路秋葉原に向かいました。 ・・・この辺から既に終わっているという突っ込みはなしですよ・・。
猫が回収したい「よかった」は、
といったところ。 なんだか微妙な感じですが、張り切って出発進行っ! 早速、運用系SEをやっている友達におさそいの電話をかけてみます。
・・・っと、なんと彼はPM7:00から朝まで勤務とのことで、 昼間は寝なくっちゃとのこと・・。お疲れ様です。 とり合えず「よかった」を探して見ましょう。う〜んと、う〜んと、 ――わたしじゃなくて よかった。(1)
と言うわけで、電車にのっていざ秋葉原。 ん〜っ、なんとも偏った「よかった」がいっぱい転がっていそう。 早速、「ビバ! 秋葉館」ということで、2階のMacフロアにレッツラゴーです。
お〜お〜あるある、ExpertMouse7とか7とか7とか。 とても物欲が刺激されますが、なぜだかPowerMateとiceMateが見つかりません。 うーん、どこかなどこかな、とMacフロアを探してみてふと、 ああっ、別にMac用じゃなかったのよねっ・・と思い至るに数十分。
1階フロアに入り口近くにあるのを見つけて、iceMateを購入です。 ああ、ようやく手に入れたわっ
 |
| iceMate with PowerMate |
見よ! この勇姿!この美しさ! ・・・ただのアクリルオブジェクトに2900円も・・なんてことは 微塵も思わせないこの品格! これを入手するのはPowerMateオーナーの義務でしょう!(キッパリ)
――ああ、本当に買ってよかったぁ・・。(2)
ちなみに、グルグル探しまわったおかげで、すっかり疲れてしまった猫は もう一度2階に上がってExpertMouse7を購入しようという気力がうせてしまいました。 おかげでムダづかいしなくてよかったぁ。(3)
というわけで、秋葉館では2pointも「よかった」を稼いでしまいました。
そんなこんなでラオックスです。
目的地は6階なのですが、 とりあえず2階でトラックボールをコロコロ。 ここのExpertMouseはいつ触っても状態がよくって嬉しくなってしまいます。
で、その足で6階BOOKフロアへ。 今日の猫の目的はCマガジン2003年5月号。「CRCカードによる簡単な設計手法」という 特集が読みたかったからなのですが、これは難なく発見できました。 他にもいろいろ物色して、最近ファンになったマーチン・ファウラーさんの「アナリシス・パターン」を購入。 さらに他にもいろいろ物色していると、なんと! ダイクストラさんの「構造化プログラミング」があるじゃないですかっ!
 |
| 構造化プログラミング |
この本は、構造化プログラミングを提唱したエズガー・ダイクストラさんの 本人による本で、猫は長らく読みたかったのですがなんといっても昭和50年の本。 (生まれる前ですよっ!) というわけで、現在好評絶版中だったのですが、 歴史的な本だけにず〜〜〜っと読みたかったのです。
というわけで、すごい「よかった」が転がり込んだものです(4)。ん〜〜っうれし♪
―後日談
ダイクストラの言う「構造化プログラミング」を
とてもよく要約しているサイトがありました。
かなり解りやすくも正確な出来栄えでお勧めです。
大規模開発に興味のあるかたは是非ご一読を。
というわけで、そのままヤマギワ火災跡へ。
 |
| ヤマギワ火災跡 |
もうずいぶん経つというのに、なんだかほこりっぽい臭いがします。 ずいぶん大きな火災だったのね、と実感。死者が出なくてホントよかったです(5)。 裏のクレバリー2号店も元気に商売していたのでこれまたよかった、と野次馬根性丸出しですが、 それもそれ、良いことにしましょう。
せっかくですので、その足でネオテックさんへ行ってきました。 いつ行っても怪しさ抜群の店舗で、Cherryのリニア鍵盤を打ち比べたりして 遊んでいたのですが、う〜ん、触っていると物欲が・・。買っちゃおうかなぁ、という気分で いっぱいになって、既にフェーズは「どれを買おうか」と悩むところまで行っちゃってた時に、 なんだかドヤドヤとおじ様達がいっぱい訪れて、なんだかダンボールから よくわかんないキーボードをいっぱい引きずり出し始めました。
そこに宅配便まで届きはじめ、狭い店内がいっぱいいっぱいになったところで、 ハッと正気に戻った猫は、とり合えず何も買わないでネオテックさんを後にしました。
う〜ん、ムダづかいしないで、ホントによかったです(6)。
せっかくアキバに来たのにハードウェアを一つも買わないなんて アレゲよね、と、今日はLogitechの親指トラックボールを買おうと心に決め、 ソフマップとかTowTopとかを徘徊、結局ポイントを貯めるぞ、ということで ラオックスにて ST-65UPiを購入しました。
 |
| logitech ST-65UPi |
実はトラックボールルームなぞを開きながらも、 親指トラックボールも、logitechのトラックボールも持っていなかったので、 ここは一石二鳥と狙っていたのです。 (CT-100をプレゼント用に買ったことはあったのですが・・・。)
そんなこんなで、一日まったりとお買い物を楽しみました。
ちょっと疲れたので、帰り道に喫茶店に寄ろうとして、 クレバリー2号店横のプロントが満席だったため、 ちょっと離れたドトールに変更。 おかげで 甘くて美味しい アーモンドキャラメルラテ と 小腹を満たす ジャーマンドックを美味しくいただけたので、結果的によかったかしら。(7)
美味しいアーモンドキャラメルラテをふ〜っふ〜っしながら、 実はラオックスのBOOKフロアで一緒に購入していた「もえたん」を 片手にまったり過ごしてから、帰路についたのでした。
今日は「7よかった」くらいの幸せな日々でした。 明日も幸せだといいにゃあ・・・。
よかった探し、それを人は現実逃避という・・・・。
ギャルゲーを潰そうとガンバってる人がいるそうです。 (ネタ元：TECHSIDEさん 2003/2/16,17のニュース)
どうもTVのディレクタのようで、ギャルゲーが犯罪を作る・・みたいな特番を放映したらしいのですが、 内容はともあれ、言論・表現の自由を侵害するのを「正義」と胸を張って言える人は、 きっと、ステレオタイプの中でしか生活できない人にちがいない、と猫は思ってしまいます。
一体アメリカが「イラクに戦争を仕掛けるのはおかしい」と発言できない世の中になってしまうと 同時多発テロ前に誰が思えたでしょうか? 「世論」とはそれほど「偏っている」ものだから、 たとえ民主的多数決で行おうとも、言論・表現の篩い分けなんて、絶対にやってはいけないことだと思うのです。
それと、オンラインギャルゲー販売会社の社長に「あんた 親にいまそんなことやってるって胸を張って言えるの?」と 言ったら黙ってしまった。――なぁんていってますが、 Hなマンガを描いている人も、 ヌード写真家も、 フィギュア原型師も、 社会的に認められるようになったのはつい最近のことです。
職務内容を社会の圧力ゆえに、告知できない状況に追い込まれている状態を 一般に「差別」といいます。 それが解らないから、胸をはって差別を出来るようになるのね、と思うのです。
猫はと〜〜っても疑問に思うのが「スクリプト言語」って何?ってことです。
言語名が「スクリプト」ってのは勿論無いですし、 「コンパイル言語」「インタプリタ言語」と言った翻訳形式での分類のことでもないです。 「手続き型言語」「関数型言語」「オブジェクト指向言語」といった、 言語構造による分類でもないです。
なんとなく解るような解らないような感じのする言葉なのですが、 よくよく考えると具体的になんなのかさっぱりわからないのが「スクリプト言語」です。 つまり、「 "スクリプト言語"とくくった場合 "スクリプト言語"じゃないのは何んて言うのさ?」と聞かれたら ・・・う〜ん、と考えてしまうのです。
困ったときは即調査、Webのおかげでこういう調査が取っても楽になったのは、 WWWは人類の作った文化の極みよね、としみじみ思う瞬間です。
まずは無難に IT用語辞典"e-Words"さんところの解説です。
機械語への変換作業を省略して簡単に実行できるようにした簡易プログラムを記述するためのプログラミング言語。スクリプト言語で作られたプログラムはスクリプトと呼ばれる。「簡易プログラミング言語」と呼ばれることもある。
一瞬わかったような気になるのですが、 よくよく考えると、「機械語への変換作業を省略」というのは インタプリタのことですし、「簡易プログラム」というけど、 ASP(アクティブ･サーバ･ページ サーバ側で処理行い動的にWebページを作り出す仕組みです。) で使われているのは VBScriptとかJavaScriptなので「スクリプト言語」なのですが、 とてもじゃないけど「簡易」かんかじゃぁありません。 (とはいえ、ここれはWebアプリケーションを「スクリプト」で作成しようとする方が無茶なわけで。 その為に「JSP/サーブレット」とか「ASP.NET」とかが登場したのですが。)
じゃあ、猫の日ごろ愛用するオンラインコンピュータ用語辞典さんの解説 だとどうなるかというと、
インタープリターのソースコードのこと。または簡易言語の一種。 JavaScript や VBScript など様々ものがある。
こちらだと歯に絹着せぬ実にいさぎのよいご説明。 インタープリタだと言い切っています。となれば、イメージのよくなくなった「インタプリタ」という言葉を 捨て去って、IT時代(←ってとても陳腐な響きなのよね)にあわせて衣替えしただけなのかしらん、と思います。
とても解りやすく納得できる説明なのだけれど、 でもでも、日ごろの使っている「ニュアンス」からすると、なぁんか、しっくりこないのよね。
というわけで、マニアックなまでな正確さをもとめるなら、やっぱりここ、 ウィキペディアさんの解説です。
様々な定義があるが、一般的に次のような性質をもったプログラミング言語を指す。台本（Script）の英訳が語源。
- 比較的単純なプログラムを記述するための簡易プログラミング言語。多くはインタープリタ方式を採用している。Perlやシェルスクリプトがこれに当たる。
- 特定のOS、アプリケーション、機能のために使用するプログラミング言語。例えば、C言語はUnixのスクリプト言語、Lispはemacsのスクリプト言語、JavaScriptはWebブラウザのスクリプト言語というように用いられる。
大抵の場合、前者の意味で用いられる。
なるほど、すっきりです。
ノートでは、「Unixのスクリプト = C」は変! と突っ込みが入っているのですが、 それはそれで置いといて、 ようするに「現在はこんなニュアンスで使われてますよ」と言う説明以上のことが出来ないということは、 定義が曖昧なまま広まって言って、語彙中に矛盾を孕んじゃっているのね。
基本になるイメージは、「人間がお気楽につかえる」(使い捨てで ちょこちょこっと書くプログラム、みたいな)、 「元となるシステムの機能を拡張する手段としての言語」がごった煮になってるのですね。 もやもやっとしたイメージ以上の意味が決まってないということです。 ここら辺がいかにも「自然言語」よね、と意外なところで関心したり。
猫は「スクリプト言語」とは「狭義のプログラム言語」――つまり、 アプリケーション、ドライバ、ファームウェアなどを作るための言語の対義語だと思います。
もちろん「プログラム」はその語源の通り、 最初は「コンピュータにやらせたいこと演目表」の意味だったのですが、 今の言葉の響きは、ずいぶんニュアンスが変わってしまったと思います。
プログラム言語が登場した当初、 プログラム言語はその考え方(=パラダイム)に於いて、以下のように分類されてました。
(えっと、他にもあったような・・・) ここで、注目するのは前者の「手続き型言語」の方で、 今の感覚だと、関数をバリバリつかうし、 「サブルーチン」と「ファンクション」の区分のない C言語 とその子供たちを「関数型言語」と思ってしまいがちなのですが、 これらも、手続き型言語です。
ちなみに余談ですが、手続き型と関数型の違いは、簡単にいうとプログラムのなかに「時間」の概念があるかです。 「時間」の概念があると、「状態」が「時間」の経過とともに変わって行きます。 つまり、逐次実行が出来るようになるわけです。
(以上：余談終り)
・・・、と。ところがプログラムの構造化手法が一般的になると、 手続き型言語がとても手続きとは言えない状態に進化してしまいました。 つまり、段階的詳細化法による、構造的なプログラム構造は、 「ソースを上行から下行まで順番に実行する」といった 手続き手法を上塗りしてしまったのです。
プログラムの作成規模が大規模化していく時代の出来事でした。
「プログラム言語」がシステムの組み上げを生業にするようになり、 それに適したパラダイム「オブジェクト指向」が生まれたりして、 大規模なシステムを、より効率よく実装する仕組みを強化されてきた 「プログラム言語」は、その代償として「お手軽さ」を失ってしまいました。
OSの代わりにBASICインタプリタが起動した時代、 確かにプログラム言語はユーザとコンピュータの対話を行う「ことば」でした。
ユーザはBASIC言語で語りかけることで、コンピュータに命令することが出来ました。 また、ある一連の手続き(=仕事)をBASICで記述して、仕事を覚えさせることが出来ました。 これは「ことば」をつかったコミュニケーションで、 コンピュータとは本質的にはそういうものです。 (とはいっても、猫はその時代を経験してはいないのですが)
ところが、今のコンピュータは「システム」を実現するためにだけあります。 決められたコマンドを実行するだけ、 新しい仕事は「アプリケーションのインストール」でシステムに組み込まれます。 だから、コンピュータとユーザが プログラム言語を使って 対等に対話する時代は とうに過ぎ、コンピュータはユーザの道具と成り下がってしまっているわけです。
そんななかで、「システム作成ツール」と成り果てたプログラミング言語を 再度シンプルにし、「お仕事を教える」だとか「ちょっとした対話をする」だとか そういうことが出来る「言語的なもの」としてスリムアップしたものが登場します。
コンピュータに「手続き(=プログラム)」を教えるために使う「ことば」は必要だから、 それで、意味の変質してしまった「プログラム言語」という語句の代わりに 用いられたのが「スクリプト言語」です。
いってみれば、法律を書くような言葉 と 口語の違いかしら。
以上が猫的見解。間違っているとか、意味がちが〜う! とかいろいろいわれそうですが、 猫は、
スクリプト言語とは、コンピュータとお気軽にお話できることば。
と認定します。(強引)
スクリプト言語は プログラミングを職業にしない方でも是非覚えるべき物です。 たとえば Windowsが標準でもつWSH(Windows Scripting Host)という仕組みは、 VBScriptとJScript(JavaScriptのマイクロソフト方言)をコンピュータが読める様にしてくれます。
だから、VBScriptでつらつらつらっ、と文章を書いて、 ".vbs"って拡張子をつけて クリクリッとダブルクリックすると、 コンピュータをそれを呼んで、文章の内容を行ってくれます。 文章が破綻してると、「読めないよ」っとエラーを出してくれます。 (こういう仕組みをインタプリタといいます。)
VBScriptは英語ベースなので、日本人にはとっつきにくいのですが、 それだったら 日本語ベースのプログラム言語 「ひまわり」だってあります。
コンピュータに「ひまわり」という言葉を教えるためにインストールが必要なのですが、
自然言語としての日本語に似せるように作られているため、
人間側にも「ひまわり」という言語をインストールしなくても、
それなりに「ひまわり語」で書かれた文章を読むことができるのが
最大のウリです。
(ただし、「読み書き」の「書き」は「読み」よりも難しいのが言葉の常。
「書き」をマスタするにはそれなりの お勉強が必要です。)
ひまわりの言語設計の巧みさは、たとえるならば、漢文です。 「レ点」とか「一二点」をつけて送り仮名を書けばあ〜ら不思議、 日本語として読めちゃうじゃないっ! ――なぁんて感じの「巧さ」がひまわりにはあります。
そんなこんなで、義務教育で 「読み・書き・ソロバン」にプラスワンしてもらいたいところなのですが、 プログラム言語の進化速度は速いので、教育勅語、じゃかった、教育指導要綱に 盛り込むのは無理っぽいですね。
Windowsユーザなら、猫的にはひまわりがおすすめ。 でも、インストールの権限が無かったりするのなら、 Windowsが最初から覚えている VBScriptやJScrpitを覚えるのもいいかしらん。
今月前半は、電波 病んでるコラムが多かったので、必死に取り返したいとおもっている
三猫です。一度出てしまったものは取り消せないけど、それでも必死に覆い隠そうとあがくのがヒトの
週刊 わたしのおにいちゃんがようやく完了しました。 (といってもまだ番外編が残っているのですが・・。)
「週刊 わたしのおにいちゃん」とは、昨今の妹萌えな時勢を反映して 展開されたフィギュア + ブックレット で、各家庭に萌えを提供するために作られた 5号限定の週刊誌です。 猫は妹萌えブームに乗るつもりはまったく持ってなかったのですが、 このフィギュアが殺人的にかわいいのです。 かわいいものにはめっぽう目がない性分もあってお試し版 + 全5号をコンプリートしてしまいました。
が、買ってみてビックリ仰天というかなんというか、 全長3cm程度のフィギュアのクセに、全6体中3体が脱衣可能になっているという 犯罪フィギュアでした。 (ちなみに脱がせられないのは、プレビューの下着姿、2号のスクール水着、5号の体操着 なんですから、 終わっています。)
と、いうわけで気になる型は こちらのわたおに回転いいんかいで ご確認を・・・。Flashで回りながら脱いでいきます。
このわたおに、一部のコアな方に大人気・・・ていどだったら日本もまだまだ安泰なのですが、 予約開始するやいなや、Amazon.co.jpで1位から5位を独占してしまったんだから 日本もいよいよアレなわけです。(ちなみに6位はナウシカDVDだったような)
猫的には90年代前半 ――エヴァンゲリオンが始まる前 までが、 日本人が 「萌えろ一億、火の車」にならないで済んだご時世だった気がします。 まだまだ コスプレもコミケも 一般認知度が低く(いや、上がりつつあったというべきでしょうか(^^;) ) 「萌え」という言葉自身生まれていない時期だったのですが、 あのころのフィギュア好きというのは、オタクさんの中でもさらに蔑視される傾向があったような 気がします。(特に固定ポーズのガレージキットではない、関節稼動系なんかは・・・)
ここで、普通ならば「一体なにが日本人を間違わせたのだろう・・・」となるのですが、 猫的にはああ、なんて良い未来が来てしまったのかしら・・と思ってしまいます。
うにゃうにゃ。だってですね、猫はコミケが大好きなのです。
それは 人々がネットを愛するのを一歩先取りした感覚で、 自分が読み手だけでなく書き手になれる喜びは、 本を買う人売る人が「販売人」と「お客」ではなく、 同じ趣味を持った仲間になれる楽しさは、 麻薬のように猫を蝕んでいたのに、「コミケ」という場は偏見で捕らえられ、 いつ中止に追い込まれてもおかしくない状態で、 「オタク」というのは隠れキリシタンのようで、 だからこそ、サバトに集まる魔女たちのように、 全国から集まった初対面さんが、仲間としてお付き合いできる。 そんな素晴らしい場所だったのです。
「萌え」がはびこるようになってから、なんか違うなぁとおもう様になったのも しばしばですが、それでも猫はあの場所が大好きなのだから、 三つ子の魂というのは恐ろしいものです。
猫がネットでこうしてサイトを開いているのも、こうした猫自身の嗜好が 強く反映してるのですが、 だからこそ猫は「読んでもらえてなんぼ」とかいうのは ちょっと頂けない気分になってしまいます。
本来「商売」というバイアスがかからなければ、 読み手も書き手も相対的、対等の人間だから 書き手は読み手にサービスをしているわけではありません。 猫はお仕事で書いているわけでもなにかの啓蒙活動をしている訳でもなく、 ただただ自分が書くのが楽しいから書いているのであって、 猫的には「気に入った人だけ読んでください」というレベルで十分なのです。
それはもちろん、多くの人が読んでくれると書く喜びも増してきます。 感想なんてもらえた日にはとてもとても嬉しいです。 でもでも、それは あたしの書きたい様に書いて、という前提付きの話です。 その為、アクセスの多さにはあまりこだわっていないのが正直なところ。
うーん、またもや話したいことが四散してしまっているのですが、 つまり、最近の三猫OnLineはちょっとだけ重荷に感じることがあったりなかったりするんです。
キーボードルームやトラックボールルームは趣味以上のなにものでもないのですが、 最近それなりにマイナーメジャーになってきていて、 ちょっとだけ影響力が出てきているようなのですが、最近レビューするのが少し怖い。
猫が「好きだーっ」、と叫んで「この子達はこんなに良い子なんですよっ! 」とレビューを書いて、 それを見た人たちが、「ふうん、じゃ、ためしに会ってみようかな?」と「ご縁」となるならいいのです。 でも、「三猫が良いといっていたから買ったのに、なんだい、コレ」と、 ご縁の無い方にまで無理矢理縁結びしてしまうのなら、それはとても嫌だなぁと思うのです。
日本人は民族的に「クレームはぐっと我慢」だけど 「賛同やありがとう系は是非伝えちゃう」な方が多い様な気がします。 猫のところも、最近少しずつ(本当に少しずつ)メールや掲示板、他人様のblogなんかで 「三猫さんが紹介してたから買ったよ〜。私も気に入ってます♪」的に言ってくださる方が増えてきて、 それはとてもとても嬉しいことなのだけれど、その影に「このバカ猫に乗せられて損した」と思っている人が 何人くらい草葉の陰でないているのかしらと思うと、「好きだよ〜っ」と叫ぶ声も 心なしか小さくなってしまうというか。
そうなると、レビューを書く手にもなんとなくへんな力が入ってしまって、 いろんなことを考えて表現があっちへふらふら〜、こっちへふらふら〜、としてしまうこともしばしば。 うーん、これはいけないわ。
――なぁんて時に、とても良く効く精神安定剤がアクセスカウンタだったりするのです。 だって、1日60〜120アクセス(ユニークビジター)。ぜーんぜん大したことありません。 こうして自意識過剰なのは自覚して、せっせとレビューを仕上げるのが 幸せってもんさぁね。
アクセスカウンタはそういうときの為にあるっ! 数字は客観的だわ。 そんなこんなで、猫がアクセスカウンタをつける理由は、客観的にどれくらい見てるのかな、と 思える基準が欲しいから。(それと、リファラでどんなサイトから飛んできてるかみるのが 楽しいからもあるのですが(^^;) )
というわけで、・・ええっと、なんだか話が纏まりませんでした。
ホントは、「サイトアクセス2万超えたよおめでとう > 私」 ・・・という話と、 「同人屋すぴりっつ を持った人がここ10年でとても増えて、こいつぁ世紀頭からめでてぇやっ! 」 ・・・という話を、「数が増えた」を接着剤にくっつけ合わせると一本雑文ができるかしら? という感じでスタートしたのですが、 いざ出来あがってみれば一体何がいいたかった自分でもさっぱり解らなくなってしまいました。(^^;
きっと何も話したいことが 猫の心の中に実は無かったからではないかと 思うのですが、 頭にうかぶよしなきことを 徒然のままに書き綴っただけというか、 意味が文章に込められているのではなく文章それ自身が在ることに意味があったり無かったり。
ああ、ますますもって訳がわかりません。
どこをどうしたら「わたおに」から「サイト運営」の話に転がるのかとか、 結局コミケが一般的になった話が知りきれトンボだぞ、とか、 で、サイトのアクセスが増えたほうがいいのは減ったことがいいのかどっちなんだ、 などなど、突っ込みどころは満載ですが、 無敵の呪文「そういうこともあるよね」を唱えて、そういうこともあることにしてしまいましょう。
あたしの迷走はまだまだつづく・・・。
何かとえらそうな三猫です。 寝ても覚めてもお仕事のことばかりを考えているので、 汚染度が凄いです。う〜ん、もっと愉快でくだらない事を考えないと・・。
というわけで、ブラックキャットの最新刊を買いました。 いえ、矢吹健太朗さんの漫画のほうではなく、 新井素子さんの小説の、最新刊です。
今回発行されたのは ブラックキャットの第四話「チェックメイト」、いよいよもって最終巻です。 と、いっても、ブラックキャットIII「キャスリング」が出たのは今から実に9年前、 ちなみにブラックキャットII「アンパッサン」が出たのがそれからさらに9年前と、 なんともインターバルの長いシリーズなんです。
猫は新井素子さんの本はとても好きなのでほぼ全部持っているのですが、 コバルトの素子さん本は「愛の狂気」に侵食されていないのが気軽によめていいですね。 (恋人をシチューにしちゃったりする話を書くんだ、この方は・・・) 前回のキャスリングも「ようやくでたよぉ」と思ったのですが、IIはリアルタイムで読んでいないので、 今回の「チェックメイト」は「よ〜〜〜〜〜〜〜〜〜〜っ、や、く!」といった感じ。 ああ、あたしも年をとったわ(TT)
ブラックキャットは「走れない泥棒」「人を殺せないスナイパー」「粗忽物のスリ」の3人組の 泥棒さんのお話です。 新井素子ワールドは全作品繋がっていて、特に本作は「星へ行く船」シリーズに子孫が登場し、 その他もろもろの作品で名前だけの登場が多かった「やまざきひろふみ」が レギュラー出演する意味でも注目の一作です。 (ですが、彼の「ぶっ壊し屋」ぶりは凄まじく、ブラックキャットのプロットすらそのキャラクタで ぶっ壊してしまうのです。) 本作はそんな「やまざきひろふみ」ファンに嬉しい名台詞「全ての物には壊れる目がある!!」 も楽しめる、同窓会のような集大成のようなそんな作品でした。
猫自身、新井素子さんの影響は強く、日ごろ書いている文体も 「新井素子 + 富野由悠季」というとても悪食なものとでも言うべきもので、 新井素子さんの文体は、口語調の字の文がデビュー当時は話題になったそうです。 が、本作はよほど締め切りに追われたか、よほど「やまざきひろふみ」に当てられたか、 普段の口語調を通り越して、ほとんど日記の域に達しています。
だってだって、字の文がですね、登場人物の誰でもない、作者の心情になっちゃってるんです。 もう「チェックメイト」という舞台劇を見せられて、その感想件ストーリレポートを書いているような、 あるいは「チェックメイト」という出来事を雲の上から眺めていた神様が、 「ねね、すごいの、すごいのよっ」と仲間の神様に喋っているような・・。 ああ、もうこれは「キャラが勝手に動きすぎ」ってやつですね(笑)
そんなこんなで、久しぶりのコバルト新井素子さんを堪能した猫でした。 感想は、感想は・・・、ええぃ感想なんて書いてたまるかぁっ!オチだってつけるもんかぁっ! 論理展開なんてくそくらえっ!です!!
おそまつさま。m(_ _)m
VガンダムのDVDボックスを買いました。
猫がもっとも愛する作品です。もちろんLDも持っていますし 放映当時のビデオも残してあります。 それでも猫はこのDVDボックスを買うのに躊躇しませんでした。 それは、この作品が本当に素晴らしいものだからです。
三猫は、このVガンダムで創作の道に踏み込み(踏み外した、ともいう(^^;)) そして、本作はあまりのレベルの高さ故に 評価されないで本日まで至った不遇の作品でもあります。
なぜなら Vガンダムは既に純文学で、アニメーションという大衆文学性の極みたる受け皿には マッチしなかったからです。
Vガンダム作成後、富野監督は精神病寸前まで追いつめられたといいます。
千住明の音楽と、戦場という狂気を描画しきったVガンダムは カタルシスなどどこにもないけれど、「凄い、凄い、」と画面に引き込む怖ろしい力があります。
Vガンダムは「リアル」の極地です。
ロボットものを成り立たせる条件として「少年 × 戦場 × エースパイロット」という
キーワードが設定されることがありますが、
本作品では、リアルな戦争描写のなかで、
敵の激しいうらみ、人を殺したくないのに殺せという味方のおぞましさ、
人間である敵をこの手で殺してしまう主人公、
消しくずのように死んでいきゴミのようになってしまう人間
戦場という狂気の渦のなかでスペシャルであることが出来てしまう少年
――こんなものをリアルに描写してしまうのです。
(この押しつけられたキーワードに対するアンチテーゼで
主人公に「嘘」という名前とつけたにも関わらず、律儀な方です。)
戦場の狂気は富野監督の狂気ともいえ、 狂気が渦巻く作品中では主要キャラでさえ 何もなさずに唐突に死んでいきます。 そのあまりにな様子に、キャラに移入していればしているほど あまりに余りな死に様に 怒りすら覚えることがあります。
つまり、見ていても辛いだけで何のカタルシスも残さない、 TVの中に「戦場とそこに巻き込まれる子供」なぞを リアルに描き出されてしまっても、楽しくなんかないのです。
でもその強烈な描写が、キャラ化(パターン化)されていない リアルな人間の生き様が、見るものをどんどんどんどん引き込んでいきます。
あらすじも書けないし、テーマも一言じゃ語れない。 なによりも見る人間のスキルを要求する、「本物の」作品であるVガンダムは、 猫はとても惹きつけられたのですが、 当時は全くと言っていいほど評価されていませんでした。
一億5000万層オタク時代の幕開け前の、1993年の出来事でした。
人々に心地よい思いをさせるのが大衆文学ですが、 それは人生の毒にも薬にもならないのだけれど、一時の癒しにはなります。 でもVガンダムにそれはありません。
エヴァンゲリオンの庵野監督は 「Vガンダムに反応できないのだから、もう日本のアニメ界はおしまいだ」 と語っていました。 当時のアニメ界は、オタク向けの記号化された作品ばかりが目立つ市場で、 パート2モノでないと売れないというおかしな風潮の下、 クリエータ達は 縮小再生産しか出来ない業界に絶望感すら持っていました。
Vガンダムという「本物」をみせられても、 評価が悪いとかではなく、評価すら出来ない業界。この閉塞感は'95年の エヴァンゲリオンのヒットまで続くのですが、 それまでは物語を受け止め、考えて、自分のものにする という姿勢で アニメーションを見る者が少なかったのかもしれません。
全てがハリウッド的心地よさにつつまれていないとダメだった、ということなのかもしれません。
そういう世間のなかで、Vガンダムは視聴にあまりにスキルを要求しました。 本作品は一度見ただけでは理解できないものがあり、 表面的に「楽しめない」だけで切って捨てる 論評者のあまりの不甲斐なさに 猫は本作品を評価するのなら、最低でも通して3回は見て欲しいと当時思ったものです。
だから、最初からVガンダムを面白い、凄いと言っていた猫も Vガンダムを見て、思わず感動して涙を流してしまったのは、 Vガンダム公開から実に4年目、何十回目の視聴の時でした。
メインキャラクタが無下に死んでいくのは戦場のリアルさだからだけれど、 そんな風に結果をなさずに死んでいくものたちが、 何を思い、どのように生きたか、その心の叫びに気が付いたとき、 はかなく絶望的な一筋の希望こそが、人の希望なんだとそう気づいた時、 猫は泣いてしまったのです。
・・・てなんだか凄い語りモードに入ってしまいました。 こっから先は 猫言で。(^^;
富野監督は近年制作スタイルを変えていて、 おそらくVガンダムほどダイレクトに監督が語る作品は もう現れないでしょう。
その一方的さ故に監督は自ら失敗作と呼ぶ本作ですが、 私には富野由悠季の一つの頂点だと思えて仕方がないのです。
本作はまぎれもない純文学です。
もし 一時の楽しみとして作品を求めるのなら、猫はVガンダムはお勧めしません。 でも真剣に作品を受け止め自分のものとしたい、そういう人なら猫はVガンダムを大いにお勧めします。
見てくださいっ!
先月、高校時代の友人と久しぶりに会いました。 そのころは二人ともコンピュータとは無縁の人間だったのに、 かたやプログラマ兼SE 、かたや SE兼プロダクトマネージャになっているとは、 いやな世の中です。
F社系の大手システム会社に勤務する彼は、客先から案件を受注して、 それを子投げ孫投げする1次受けをお仕事としています。 で、猫は投げられたものを実際に作り上げる方の仕事が多いです。
猫から見れば、親受け会社なんて いい加減なスケジュール、甘い顧客仕様の吸い上げで、現場に無理難題を押し付け、 自分たちは甘い汁だけ吸っている言語道断の搾取者、 友人側からみれば「出来る」といって受注していくのに、 品質も納期も守れない、無能労働者。
二人は現代社会の身分階級とでも言うべきもので区切られているのです。 つまり、二人は敵として再会したのでした!!
と、まあ、まるでこのまま「昔の友人と殺し合い」なんていうどこぞの陳腐なストーリが展開されるわけではなく、 ただ単にお酒をたしなみながら談話を交わしただけなのですが、 それにしてもこういう関係はいいものだと思うのです。
彼は「1次受け会社のSE」である前に猫の友人で、 猫は彼の人格や物の見方を良く知っています。 だから、見ず知らずのSEが同じ台詞を言おうともまったくもって取り合わなかったことを 真剣に考えることができるのです。 いわば、彼のおかげで猫はもう一つの視点を持つことが出来、これは大変有難いわと痛感しました。
猫はプログラム言語もUML(Unifired Modeling Language)も日本語も英語も 「言葉」だととらえています。 これらはみな「言葉」の性質をしっかり持っているため、 「言葉」以外の何者でもないからです。
けど、プログラミングと無縁の人が、CとかJavaとか(挙句のはてにLispとか)をみて、 「言葉」とはとても思えないでしょうね、とも思っています。 多分普通の人は「言葉」というのは言葉のあやだ、くらいに納得してるのかとおもいます。
int CountToken( const char* sentence )
{
int index;
int token_count;
index = 0;
token_count = 0;
while( 1 )
{
if( char[index] == '\0' )
{
token_count++;
break;
}
if( (char[index] == ' ') ||
(char[index] == ',') ||
(char[index] == '.') ||
(char[index] == '"') )
{
token_count++;
}
index++;
}
return( token_count );
}
・・・無理もない。こりは、普通の人がみたら言葉というより「式」という印象が強いです。(^^;
(というか、秘密の呪文??)
でもでも、プログラムをちょっとやれば、これがまぎれも無く「ことば」であることは 納得できるし、そういう認識は広くしられているから、 この業界に関わる人なら「ことばだよ」といっても納得してくれるはずです。
そんなのりで猫は「UMLは開発者の間で使われる共通のことば だから・・」なんて 言ったら、彼に「UMLは言葉だと思っていなかった」といわれてちょっとビックリ。 ・・え〜っ、え〜〜っ!
彼いわく「設計書を記述するドキュメントテンプレート」だと思っていたとのこと。 UMLは図ですから無理もないともおもうものの、 そういう認識でいいんかいっ!?とも思うのです。
その場で猫は 「UMLのLはランゲージのLだよ」とか、 「四角い箱かいてその中に名前書くよね、これが"単語"で、線とかで結ぶと"文"になるんだよ」 とか言ってみたものの、 「それはそうは言うけど・・」のように言われてしまいました。 ――うーん、これは「言葉のあや」だとおもっているのね。
まず、声を大にして言いたいのは、「言葉は文字だけで出来ているとおもうな!」です。
言葉の役割の一つは、コミュニケーションをとるための伝文プロトコルです。
言葉を使って喋れば、それを聞いた相手に意図を伝えることができるし、 紙に文字を書けば、それを見た相手に意図を伝えることが出来ます。
言葉は「喋る」ことから誕生したから、 文字のみによって表現できるように進歩しました。だって「図」は喋れませんからね。 でもでも、思い出してください。 学校の授業で先生が黒板に書いて、私たちがノートに取ったアレは、 教科書のように文字だけで表現されるものではなかったハズ。 図と文字が入り混じった、決してテキストでは表現できないもの。 あれだって「ことば」です。
視覚をつかってやり取りするのなら、 図形的要素を言語に取り入れた方がスムースに意思伝達が行えます。 つまり、自然言語は「喋れるし、書ける」という仕様を満たすため、 テキストのみでも構成できるようになっているものが多いですが、 それは言葉の本質ではありません。
というか、こういうテキストって、自分の考えることを記述するには窮屈ですよね。
これでも納得してくれなければ、ちょっとした証明を行ってみようかと思います。
まず。
猫日誌は物好きが見る。 作者は三猫。 物好きは感想を掲示板に書いたりする。
とか、
三猫は猫日誌を通して物好きに自己見解を垂れ流す。 さらに酔狂なものはそのフィードバックを掲示板に残す。
とか、
1.三猫が猫日誌を書く。 2.猫日誌を物好きな人が見る。 3.さらなる物好きはその感想を掲示板に書いたりする。
という情報があったとします。 上のようにテキストのみで表現する場合、 キーボードで打ったり、喋ったりするときは「じれったい」とは思わないと思いますが、 手帳にメモするときには、こんな風にかいてはとてもじれったい思いをします。
ですので、
なぁんて、メモを取るのは、よくあることじゃないでしょうか。
これらは図交じりで書いても、文章で書いても、箇条書きで書いても、
だいたい同じ内容を表現しますので等価です。
(でも書き方によって、メリット・デメリットがあって、
伝わりやすさとか与える印象とかが違うため、私たちはこれらの方法を使い分けているわけです。)
もっと突っ込んで言えば、文章、箇条書き、図形メモも 上例に限っては、 最小単位を「単語」とし、「単語」どうしを「述部」つなげて「文」を作り上げるという 構造レベルでも共通です。
述部を 「○○は××に△△する」と
「は」「に」などを駆使して書いても、
「 [○○] ―(△△)―> [××] 」のように
矢印なんかで図形的に書いても 本質的には同じなのです。
(ただ、矢印つなぎは喋れないのよね・・・。)
設計や仕様といったものを相手に伝えるのは、それらが複雑なため 自然言語ではとても難しいんです。
もちろん言葉は コミュニケーション プロトコルとしてだけでなく、
といった役目も持っています。UMLももちろん言語ですので、 コミュニケーション以外の役割でも良く使われます。
だから、1次受け会社のSEはプログラムに明るくなく(いやホント)、 技術的キーワードや概念をよく知っているもののその詳細はあまり理解していません。 一方、実際の開発担当者はこれらは良く理解するものの 顧客要求や 技術を使う「理由」、全体での仕様は知らないことがとても多いです。
2者の間の溝は、もはや「ごめん、アンタとはプロトコルが違うからアンタの言っていることは永久に理解不能。」 というほど深刻です。 しかし仕事を分業する上で言葉が通じない間柄では、その後のデスマーチは約束されたも同然です。
そんなわけで、いろんな「レベル」(抽象度といってもいいです)に合わせて多数の図を内包するUMLは、 決して「設計書の共通書式」などではなく、 システムを作り上げるものの間でコミュニケーションを取るための言語なのです。 前者は設計や開発の人間だけが知っていれば良いのに対し、 後者は実際にシステム実装に手を汚さない人間でも知っている必要があります。
とかくクラス図ばかりが脚光を浴びがちなUMLですが、 ユースケース図など顧客要求を表現するのに適したものや、 アクティビティ図のように顧客独特のビジネスルールを表現しやすいもの、 配置図のように環境を構築する側が主役の表現方法もあって、 プログラマのみが取り扱うべきものではないはずです。
とくにプログラマにUMLを書かせると、全てのメンバ・フィールドを網羅したクラス図を 他レベルの作業者に提示してしまったりするケースが多いので、 「設計書」または「設計書式」という印象はますます強まってしまうのですが、 クラス図は説明したい内容にあわせて、メンバを省略し見やすく書くことが出来るものです。 つまり、論文調の文章――正確に書くことを優先する代わりに冗長で理解しにくい。―のようなUMLを見せられているだけで、 決して「UMLが論文調」なわけではないのです。
ここら辺の自由度も、猫が言語と強く主張する論拠だったりします。
今現在UMLの普及度は最悪で、しかも「設計書」といいう認識がとてもとても強いため、 正直UMLを内輪でしか使えない機会が多いです。
プログラマを長くやっていると曖昧さをとても嫌うようになり、
それを排除するため直感的に理解しにくい言い回しが苦にならなくなってきます。
プログラマにとって些細な不正確さは「バグ」というトラウマゆえに
見過ごせないほど大問題なのですが、普通の人はそんな細かいところにつっこまれ続けると
不快になるわ、論旨の骨格を見失うわで良いことがありません。
UMLは自然言語にない厳密さをもちながら、プログラム言語ほど厳密でない、 この手のコミュニケーションにはとても適した言語です。 だからどうか、厳密さを旨とする設計書としては取られて欲しくない、と猫は思ってしまうのです。
「これは説明するより ソース見たほうが早いから・・・。」
プログラマさんなら、きっと聞いたことがあると思います。 複雑な処理仕様を聞くと帰ってくることの多い返事ですが、 これは単にそのプログラマさんは怠惰だ、ということではないと思うのです。
まず、そういう風に言うってことは、まず処理の仕様書はないんでしょうね、ということ。 そして、仕様書がない、ということはその複雑な処理を考えながら実装したんじゃないかなぁ、ということ。 つまり、当人の頭はきっと「プログラム言語」で思考していた公算が高いと思うのです。
こんなことをしているとだんだん複雑なことを考えるのはプログラム言語で考えるようになります。 「順接」「分岐(if)」「反復(while)」といったダイクストラの3大構造が脳裏を巡っているか、 脳内をオブジェクトが飛び交いメッセージを送信しあっているのでしょう。
ハッカーになろう (How TO Become A Hacker)の一節、
でも、言語を一つしか知らないなら、ハッカーではないし、プログラマですらないのです。あなたはプログラミングの問題について考えるのに、ひとつの言語に依存しない一般的な方法を身につけなくてはならないからです。
は猫は大好きなんですが、ちょっと意味の違う引用方になりますが、 「言語に依存した考え方」というのは知らず知らずのうちにわが身を蝕んでいくものです。
猫も子供のころは「日本語でないもっと直感的な何か」で思考が湧き上がってきたのを感じたのですが、 今は「我思うは日本語に拠りけり」になってしまいました。 言語は思考を助けますが、｢言語で」考えることは複雑な事象を取り扱うには不可欠で、 言語というのはそれだけ強力なんですが、トレードオフとして思考を縛ってしまうのです。
言語はみんなで共通でつかうため、決まった形式があるのが大切です。 これは言語ライクに言うと「文法」ですが、図形的なことばの場合「書式」なぁんて 概念も近いです。
言語に思考が縛られるのなら、 そして固められた「書式」が文法のように言語的性質を伴うのなら、 ある定型ドキュメントを作るようなツールを常用する人は、 徐々にそのツールに縛られた思考をするようにはならないでしょうか。
MS PowerPointは なんだか知らないうちに勢力を伸ばし、 プロジェクタでの投影用途以外のドキュメントにもガンガンつかわれるようになりました。 が、猫はこの「なんでもパワーポイント」な風潮が でぇきらい なのです。
パワーポイント語というのがあります。
UMLの言語的側面
→ UML は単なる設計図ではない!
箇条書きと図表で極度に構造化されたこのようなフォーマットを パワーポイント語と呼ぶらしいです。
猫がパワーポイントを敵視するのは、この言語的性質の強さ故です。 (既にツールの範疇を超えています。)
まず、確認したいことは、パワーポイントはプレゼン資料を作るためのツールだということです。
スクリーンに投影するのに最適な機能をもったパワーポイントは、 使用法の縛りによって十分な情報量を詰め込めないフォーマットです。 もともとプレゼンということもあって、 その箇条書きはどちらかと言うと、構造化ドキュメントの見出しのみを集めたものにとても近いです。 プレゼンの場であれば、足りない「本文」はスピーチで補えば良いのですから、自然とそうなってしまうのです。
見出しで全体を把握してから、スピーチやディスカッションで詳細を始めるという手順は とても有効です。 このときパワーポイントドキュメントを出席者に渡せば、 その「見出し」をみて「ああ、こういうことを話し合ったわね」と 記憶の再生をするのにも有効です。
ところが、これをプレゼン用の補助資料ではなく、ドキュメントそのものとして扱われるようになると さまざまな問題を産み落とします。
プレゼン用ツールとしての役割を忘れ、メインのドキュメント――スピーチやディスカッションもなく 運用されるパワーポイントドキュメントは 欠陥ドキュメントにすぎません。
しかし、なまじ「オーバースペック」なくらいパワフルなパワーポイントは、 それゆえ パワーポイントドキュメントが「見出し」や「参考図表」、「スピーチの材料」に過ぎないことを 忘れてしまいやすいのです。これはパワーポイントの欠陥です。
パワーポイントドキュメントは 「思考過程」を記述しませんし、情報のディテールも あまりもてません。 パワーポイントドキュメント中の記述が 十分に検討された末選択されたのか、 単に一番最初に思いついたものなのかは判りません。 あるのは思考の末 得られた「結果」のみで それすら「ステレオタイプ化」されたものしか取り扱えない ――そんな傾向になりやすいフォーマットです。
その代わり、必要最小限の情報を強調して 提示することができ、 「ぱっと見でわかる」力を得ているわけです。
会議の場であれば「正しい」という前提で話を進めますし、 疑問に思えばプレゼンテータに直接質問すればよいのですので 正しいかどうかを判断できるだけの情報が本文中に含まれて居なくてもまったく問題ではないのです。 しかし、ドキュメントは書いた人が目の前にいるとは限らないのです。
この「本文抜き」の情報を貰ったところで、 検討なんて使用がありません。せいぜい「こういう主張をドキュメント作成者はしている」ということの把握が出来る程度、 その情報量の少なさは仕様書として使われたときには、目も当てられません。
次に問題なのは、「理解した気になりやすい」フォーマットです。
パワーポイントのフォーマットは実に偉大で、
論旨の全体像がとても把握しやすく、短期間で理解した気になれる、
オーバービューの把握には持って付けなんです。
プレゼンや会議では、オーバービューを把握して初めて論議の場に入れるのですから、
こうした特性は嬉しくなっちゃいます。
しかし、こうした恩恵はドキュメントを作る人間も受けてしまう、ということに問題があります。 パワーポイントでドキュメントを作成していると、しばしば自分の頭がクリアになり、 次から次へ問題解決していけているような錯覚に見舞われてしまいます。
アイデアエディタとか、構造化エディタというツールがあって、 これは構造化した見出し付き文書を作るのに適したものなのですが、 パワーポイントはちょうどこれの「本文なし」を「本文なし」と認識させないで 作れてしまう・・そんな思考ツールとして十分に機能的なのです。
こんな思索ハイパーワープモードで 案件検討やら仕様検討やらをされた日には たまったものではない、と猫は思うのです。 詳細をスキップして見出しだけ纏めるアイデアエディタは、 検討項目の洗い出しには非常に有利ですが、検討自身は何も行っていません。
まっとうなアイデアエディタは、膨大な量の白紙本文を作るので、 「途中だ!」という意識を強くもてるのですが、 パワーポイントをアイデアエディタとして使ってしまうと、 そのような状態を「途中」と意識させない強い効果をもっていて、 これが危険だと、猫は思うのです。
そして、上記の「いけない運用」をしてしまうのは、 一重にパワーポイントの言語性の高さがあります。
ヒトは言語に思考が引きずられるのを普通は認識することが出来ません。 唯一の例外は、複数言語をつかい同じ思考をしてみて、それらの相対的な差異によって 初めて自己の思考が言語に引きずられていることに気付くのです。
メインドキュメントとして使ってしまうとき、「引きずられるものだ」という 覚悟なしに本来の用途以外に使っているので、 簡単にプレゼン風サブドキュメントな作り方に引きずり込まれてしまいます。
アイデアエディタとしてつかっているつもりがなくても、 パワーポイントドキュメント作成中になされた思考は、 パワーポイント語で思考されてしまいます。 すると、検討不十分な状態を「完了」という風に認識してしまいがちになります。
パワーポイントでドキュメントを作るのが上手になってくると、 普段の思考もパワーポイント語よりになってきます。
プログラマがプログラム言語に汚染されると、 複雑な問題をわかりやすく伝える能力を失ってしまうのと同じく、 SEがパワーポイント語に汚染されると、 複雑で大きな情報量を持った情報を、シンプルで簡単な情報に無意識に置き換えてしまい、 置き換えで生じた情報の欠落を意識することが出来なくなってしまうのです。 (つまり、深く考えられなくなる)
これらは、言語による思考の縛りですので自身で気付くことなく進行していくのが
性質が悪いのです。
「あ〜、プログラム言語はできるけど、日本語の不自由なプログラマって居る居る」という
SEも、自身が
「指示も仕様も深く考えられないSEっているのよね〜。」などと言われれば、
「やれば出来る」とか「こっちのほうが効率がよい」などといいわけを
言い出すのです。・・・やれて無いし問題が起きてるから言われるのにねぇ。
(逆も真です。プログラマも日本語が出来ないなどといわれれば、同じような いいわけを言い出します。)
自身の思考能力に対して、言語(ツール)がそれほど大きな影響力を持つわけがない、 と信じてしまうことに言語の怖さがあります。
言語は思考を縛ります。でも、縛られているとはなかなか気付けないし 信じられないのです。
パワーポイントドキュメント(またはパワーポイント常用者)の問題
問題の発生する原因
→問題のある使い方をしやすい、しても気付きにくい
問題意識の自覚判定例
これらを「変」と感じない場合は危険
→「パワーポイントドキュメント」を「OHPシート」に置き換えて読めば明らかに不自然
なんちて(:-P
風邪を引いてしまって、ようやく仕事復帰した三猫です。
土日と合体させて4連休となってしまったわけですが、 最後の一日は体の療養というよりどちらかというと心の療養が目的でした。
猫は心の貧しい人間です。 いつも実感するのですが愛と思いやりが足りないですし、 「傍に居るだけで安らぐ」じゃなくて「傍に居るだけで傷つける」ような人間です。 それでいて寂しがりやなのでタチが悪いです。(^^;
が、人は人の中で生きるもの、 ひきこもるなら別ですが、そんな自分でも「良い人」を演じることで よりよい関係を築けます。 「世の中みんな偽善者だったら、きっと良い世の中になるに違いない」を座右の銘に 日々頑張っているのですが、鍍金というのはだんだんだんだんと剥げてくるもの。 鍍金のかけ直しに迫られてのお休みでした。
なんだかまたまた偉そうですが、 要するにこういうこと。 猫は本当の良い人じゃないので、自分の心にゆとりのないときに人に優しくできないのです。 だから、自分の心にちょっとだけゆとりを作るために、一日お休みしたのでした。
猫の友人には愛すべきお節介さんがいて、私は彼のそんなところがとても好きです。
彼の困った(または魅力的な)ところは、 彼独自のアンテナで「心がSOSを叫んでいる人」を嗅ぎ付け、 本人の否定や回りの意見を聞かずに救済活動に身を粉にすること。
迷惑なんだか有難いのだかは微妙ですし、常識的に考えれば 「ほっとけば」なんてことも「ほっておかない」。 電波系日記を書いている人をWebで見つけても普通の人は「この人を救わなければ!」とは考えません。
でも猫は昔から彼のそんなところは「ひょっとしたら一理あるのでは??」と無碍に否定できないし、 表面での拒絶が本当の拒絶かつながりを求める心の裏返しなのかは、実際わからないから、 もし「つながり」を求めているのなら・・などとも考えてしまいます。 要するに認めるけど理解できてないといった感じ。
ところが、最近探偵ファイルで、 高校教師にレイプされた少女が自殺してしまった というニュース(?)を見て、猫はひょっとすると人の心のSOSなんかぜんぜんわからない人なのかも、と思っていしまいました。
この事件は当時高校一年生だった女の子が教師に学校でレイプされ、 そのことを訴えるも親も学校も「合意の上のセックスだった」と 「事を荒立てたくない」圧力に押しつぶされ、 心の病に罹るも狂言といわれ、ついに自殺してしまうという悲惨なもの。
事件のあらましを聞いて、猫は「子供を無条件に信じてあげるのが親なのに!」と むしろ犯人よりも彼女を自殺に追い込んだのは親であったと 怒りを覚えるのですが、 彼女の遺書を読んで「う〜ん・・・」と思ってしまったのでした。
もし、猫がこの遺書を事前に受け取っていても、緊急性を感じることはできない、つまりみすみす殺してしまうわけです。 いえ、まがいなりにも「遺書」と冠されていて文体も整っているこちらならば、 もしかしたら猫でも気づいたかもしれません。 でも探偵宛に送られたメールは、 猫には「私を見て」系のものにしか見えないし、 このようなことを書いて送れるというのは極度に深刻ではない、と判断してしまうに違いありません。 でも現実派そこまで深刻に追い詰められているわけで、自殺してしまうのです。
人の心のSOSというのがわかり難いのか、猫が朴念仁なのかはわかりませんが、 少なくとも、猫にはこういうのを「自殺した」という客観的な事実がないと、 重く受け止められないのは事実で、ああ、自分ってなんて冷たい人間なのだろうと 思うのです。
実はこの事件は知っていたものの、ここまで深く読んだり考えたりは、件の彼が 言わなければやらなかったというのも、なんともかな、です。
「電波」ちゃんや、「不思議」ちゃんとくくるのは楽なのだけれど・・・。 狂言と本音の境界はとても判断つきにくく、猫がそうくくって見過ごしてきた言動のなかに、 どれだけ助けを求める悲痛な叫びが含まれていたのだろう・・。 そう考えるとなんかか急に肩の辺りがとても寒くなってくるのです。
猫はプログラマですが、 プログラムを書くのが好きだからプログラマになったのではなく、 プログラマになったからプログラムを書くようになった、 ようするにお仕事プログラマなワケです。
そんな猫にプログラムのイロハを教え、並以上のプログラマに育ててくれた お師匠さんがいます。 猫はお師匠さんを今も尊敬していますし、 猫の中にあるお師匠さんのワザの数々は あたしが一目置かれるくらいにはハッタリを効かせてくれる、 素晴らしい武器です。
実は猫は体力的精神的限界からお師匠さんの元を出奔してしまった 元弟子に過ぎないのですが、 そんな猫でも「あたしの作るプログラムにバグはないよ」とうそぶいても 失笑を浴びないくらいのプログラマに育ててくれたのですから、 お師匠様はホントに偉大だわ、と思うのです。
「あたしの作るプログラムにバグはないよ」といっても 本当にバグが無いわけではないのですが、かなりバグのないプログラムが出来ています。
こんな話しをすると「自慢」だとか「誇大妄想」だとか言われてしまうのが プログラマという職業ですが、ちょっとまってください。 プログラマが仕上げた仕事に「バグ」すなわち「ミス」が 入っていて当たり前という今の風潮こそ変なのでは?と思うのです。
猫はファームのプログラマさんだったので、よっぽどそういう思いが強いのですが、 たとえば猫の仕上げたファームウェアにバグがあったとしましょう。 そして、それがパソコンと繋がない機器だった場合、 猫のミス一つが会社に「リコール」という大損害を与えてしまうのです。
だから、プログラマはバグの無いプログラムが作れて当たり前、 なのですが、PCで動くような業務アプリを作られるプログラマさんには なぜか「バグはあって当たり前」という風潮が強いですし、 自分が原因のバグが発覚しても、ちっとも悪びれた様子が無いのはどうかと思うのです。
と、偉そうなことを言っていますが、 猫が(または猫が指示を出したプログラムが)バグを殆ど出さないのは、 お師匠さんから叩き込まれた職業プログラミングのノウハウによるもので、 猫はその恩恵を有り難く受けている、ただそれだけなのです。
そんなお師匠さんと過ごした日々を思い出しながら、 ちょっとだけ初心に返って 「良いプログラムの作り方」をリストアップしてみると、こんな感じ。
いろいろ足りない気もするけれども、 とりあえず、振り返ってみましょ。
どんな状況だろうと、必ず設計を行います。 それが、システムの挙動を箇条書きで書いたモノでも、 何でも良いので「設計」という考える時間を設けて いきなりコードを書くようなことはしません。
もちろん設計ドキュメントを作らせてくれるような暇をくれるような ことは滅多にないのですが、猫のノートには設計書きでいっぱいです。
「頭の中にある設計」というのは実は、ただの「アイデア」に過ぎないのよね。
よく「設計は頭の中にあるから大丈夫」というプログラマは多いですが、 人間の頭って、そんなに良くないので、 頭の中で考えているだけだと、それが本当に動くものでないのに、 「よし、いける」と判断してしまうのです。
頭にある時点では検証のなされていない「ひらめき」に過ぎず、 それが本当に実現性があるのか、最善の方法なのか、 なぁんてことは保証外だから、 設計という検証フェーズを設けないと、 「仕様という名のバグ」を作る元凶となってしまうと思うのです。
ようは、自分の設計を第三者に聞いてもらい、 納得いってもらった時点でそれを採用する、というフェーズです。 大きめの設計をしたときには 周りの方を巻き込んで必ず行うようにしています。
自分で書いた文章の誤字ってなかなか気付かないように、 自分の設計で見落としていた部分って、自分では本当に気付かないもんです。
人間、自分で「当たり前」「大丈夫」と思いこんでしまうと、 次からそこの部分を必ずスキップするようになってしまいます。 これはなかなか自分ではどうにも出来ないので、他人を巻き込んでの確認作業になります。
つまり、このフェーズは設計のデバッグです。
猫のコメントはお師匠様譲りの「コメントによる構造化」です。
例えば、ファイルを開くような関数をコーディングする場合、猫はこんな感じで始めます。
//**********************************************
// [関数名] OpenIniFile
// [機能] ユーザが指定した設定ファイルをオープンする
//**********************************************
bool OpenIniFile()
{
// (1) 開くファイルのパスをユーザから取得する ----------------------------------
// コモンダイアログを開き、
// ファイルパスを取得
// (2) ファイルが開けるかチェックする ------------------------------------------
// ファイルがあるか?
// 既にひらかれていないか?
// 拡張子は対象の形式か?(.iniのみ)
// (3) ファイルを開く ----------------------------------------------------------
// (4) 関数の終了 --------------------------------------------------------------
// 正常終了なら true
}
なぜそんな面倒なことをするの?ですって?
猫がコーディングしたい内容は間違いなくこのコメントの内容なのです。 でも、「開くファイルのパスを取得する」って 具体的には、ダイアログを生成して、ちゃんとユーザがファイルを選択したかを 検証しなくてはならない。
処理を実現するコードから書くと、 書いている内に自分が本当は何が書きたかったかを忘れてしまいます。 実際にどんな順番で書いても良い処理でも、 「やりたいこと」の意味から考えると、一カ所に纏めるべきものだって あります。しかし、これらが纏めてかかれてていないプログラムって 結構多いです。
だって、コードから書くと「やりたいこと」を実現する手段に過ぎないはずの 詳細な手続きに、引きずられやすいから。
だから、処理に絶対引きずられない「コメント」から書くと、 そう言う失敗をしにくいですよ、という一つのテクニックです。
全段で殆ど説明が終わっています。 つまり「やりたいこと」を書いておく。 だって、「ファイルパスを取得したい」という処理、 コモンダイアログだろうが、オリジナルのダイアログからだろうが、 ホントは何でもよくて、 ユーザと対話してその結果取得できればいいんでしょう?
「ソースが全てを語ってくれる」というのは、
決して人に語ってくれるわけでは無いのです。
ソースの語る相手は常にコンピュータで、
コンピュータは「こうゆう作業をやれ」と言われたら
それを何のためにやるのか、なんて考えないので、
ソースには「何のために」という情報を保持する機能はありません。
(「ここで99回ループするように、って言うけど、
なんで99回なんだ??」なんて、考えながら実行するコンピュータがあったら
いいな、とは思います(笑))
だから、人間に対して全てを語ってくれるソースを書くには、
「コメント」で「何のために」をしっかり入れてあげる必要があるのです。
(逆に熟練したプログラマがコメントのないソースを読めるようになるかというと、
「ははん、コレを書いた人はこんなつもりだったのねっ」と
推測が出来るようになるからですが、推測という時点で「間違う」という可能性が
入るということを肝に銘じなければいけません。)
やりたいことを書いて、そこの範囲のなかに、 それを実現する手続きを書く。そんなコーディングをすると、 そのブロック毎に「ちゃんと動く」とこと順番に立証すればよいし、 逆に「やりたいこと」を実現する方法が変わっても、そのブロックの中で つじつまを合わせればいいから。
ようするに「段階的抽象化」という手法を上手に実装するための 一つの方法ですが、猫がお師匠さんから頂いた大事な宝物です。
これは、別にキチンとしたドキュメントを整えて、 そこに承認印をくっつけて、責任をハッキリさせましょう・・・なんて意味ではないのです。
人間、口頭で説明すると「相手がわかっている」と思いこんだり、 相手も「こういう意味に違いない」と思いこんだりするケースが多いです。 そして、こういう行き違いは「出来て上がったモノの動きが変」だとか、 「目論んでいた拡張性を得られなかった」とか、そういう不具合とか障害として発覚して、 工数的に結構な被害になることが多いです。
意図通りに出来てこなくて「戻り行程」が発生するくらいなら、 指示書という形で、一種の「要求仕様」として相手に渡す手間くらい 掛けた方がかえって良い、ということ。 また、文書に書き出すことで、指示を出す側も 「ホントはどんなモノを望んでいるか」の具体像をハッキリ認識できるので メリットがあります。
とても忙しい最中なので、猫の指示書は 不要コピーの裏紙にボールペンで書かれたものばかりですが、 これがあるのと無いのとでは大違いです。
ブラッシュアップ、つまり磨き上げる作業です。
一度組み上げてから、構造を見直した方がよいもの、 書式を整えた方が良いモノ、いろいろありますが、 そのソースの寿命を考えるなら、 再テストという工数をおそれずにリファクタリングを行うべきです。
実行ファイルだけが プログラマの成果物なら 行う必要はないのですが、ソースだって成果物、 ならば「きれいなソース」で納品するのは当たり前、と猫は思っています。
そうじゃないとね、メンテするたび、2次使用するたびに ソースがフランケンシュタインのようになってしまうじゃない。ね。
* * *
そんなこんなで、いろいろありますが 結局は全部「急がば回れ」。
それぞれの手間を惜しんで、最速プランを立てるプログラマが多いのですが、 猫的には奇跡的に仕様の読み違いも チーム間の認識のずれも、不具合も発生しないでできたのならば、 そりゃあ早く仕上がるけれども、 奇跡が起きないのなら、バグ地獄に填るだけだと思うのです。
もちろん「バグだらけでも良い、期日に納品さえ出来れば」という 言語道断な開発が世の中非常に多いのも確かです。 (で、当初の予定期間 + サポートという名のバグ取りで 実質的な開発期間を稼ぐケースというのが、とても多いです。)
でもでも、それでも。 急がば回れですよ。と、猫は思うのです。
だってね、お師匠さんは誰よりも仕事が早かったですし、 誰よりも不具合を出さない方だったんですもの。
と、ここまでだと、猫は余りに格好良くなってしまうのですが、 猫がプログラマに向いていないのよね、と思うのは、 こういったお師匠さんの教えを 知らず知らずのうちに破ってしまい、 それが元で失敗をするときなんです。
猫はどうも自分に対する厳しさというのが足りないらしくて、 同じことで失敗と反省を繰り返すダメな猫なので、 普段「猫のつくるプログラムにバグはないよ」とでも うそぶいて、崖っぷちに自分を置かないとだめなんだ、というのが ホントのところ。
あと、猫は人に説明しながら考えるクセがあるため、 とてもとても迷惑千万なプログラマだったりするのです。
それでも、「猫にはここら辺レベルがお似合いさ」などと思わず 上へ上へと目指すこと、 それと相手の意見は例え自分が相手より格上だと思っていても真摯に聞くこと を忘れないようにしたいです。
特に後者は良く忘れてしまいがちなのですが、 格上、格下という判断自体が誤ってるケースと、 例え自分が格上でも、その人の全てのスキルに対し全てが上回っているなんてことは ないので、どんな相手に対しても意見を聞く態度を変えないというのは とても重要だと思うのです。
逆もまたしかりで、自分が明らかに格下でも、 疑問に思ったら即質問、違うと思ったら即意見をいうべき。 それに納得するまで教えてもらうのは、自分にとっても相手にとっても プラスですしね。
結局人間っていうのは、自分の外側にも脳みそがあって、 話し合うという「通信」をすることで分散処理をできるのも強みなのよね、 と思うのです。
・・ああ、なんだか最近プログラムの話しをすると 私ってば偉そう。これはコミュニケーションスキル -1 かしら。
| SEO | [PR] おまとめローン 花 冷え性対策 坂本龍馬 | 動画掲示板 レンタルサーバー SEO | |
