- ねこのこべや -
- ねこのこべや -
インタプリタってなんだか可愛そうと思う今日この頃。
人間様は偉いから、わざわざ機械語を覚えてまでコンピュータと会話したいとは なかなか思わないので、 誰かが書いた「お使いメモ」をぽ〜んと渡して仕事をさせるのが主流になりました。 お使いメモ = プログラム ばかりを書くのに使われるため、 コンピュータと人間対話に使う言語を「プログラム言語」と呼ぶのに 誰も疑問を持たなくなりました。
インタプリタは「通訳さん」、コンパイラは「翻訳家さん」 今は「プログラム」ばかりだから、「翻訳」の方が有利だから、 インタプリタの肩身はとっても狭いです。
でもね、猫はコンピュータと会話が出来た方が絶対良いとおもうのです。
Realforce 89を使い始めてもうすぐ1ヶ月です。 お仕事キーボードに抜擢しているのですが、なかなか素敵なキーボードで、 コーディングなどにはまさに打ってつけといった感じです。
このキーボードの良いところはとにかく軽い力で入力できるところ。 他のラバードームキーボードだとどんなに軽いものでも、キーを底まで押し込む作業が必要になりますが、 本機の場合、最初のクリックの山を越えてしまうと残りは勝手に押し込まれていくような 感触を受ける独特なキータッチをしています。 いわば「フックを外すためにキーに触れる」といった操作感です。
このキータッチのお陰で非常に楽に入力できるのですが、 なんといったらいいか、そう、味がしないのです。 薄味ではなくて無味。 確かに「不快」なところはどこにもないのですが、 「不快でない」というだけで打つのがちっとも楽しくないのです。
ホントの入力作業(思考と入力があまりリンクしないような作業、作り出すものが無機的なもの) をするときにはこれ以上ないくらいに頼りになるのですが、 文章を捏ね繰り回すような場合、なんだかこのキーボードをつかうと 猫の場合、出来上がる文章がパサパサした感じになってしまうというか、 色気のない文章になってしまうような気がするのです。
う〜、仕事用としてはよいのだけれど、 こっそり内職してコラムを書くときには困ってしまいます。 ああ、どうしましょう・・。
・・・えっ、仕事しろって? えぅえぅ。(^^;
今週の日曜、伯母が亡くなりました。
あまりに前触れも無く、あまりに突然だったために実感も無く、 通夜、葬儀とバタバタとこなすうちに僅か3日で真っ白なお骨になってしまいました。
訳の解らないうちに、復活を希望出来ない姿にしてしまう「火葬」というシステムは、 良いものなのかもしれません。
前回、前々回と、単なる思索メモを日誌としてしまった三猫です。
考えたことをメモって置かないと直ぐ忘れてしまうのですが、 メモというのは忘れた頃には解読不能になってしまうのが世の常。 忘れないうちに要約しておくのが賢い生活術です。
前回のことばは、考えがあっちこっちに忙しく連鎖していて、 飛びすぎて解らない典型です。
出だしは「自然言語は人間の思考に影響(=縛り)を与えている」というところから始まって、 「プログラム言語もプログラマの思考に影響(=縛り)を与えている」と結ぶのが当初の予定でした。
が、なんだかどんどん飛躍を始め、 本来プログラム言語に「文」が必要なのかしら、という視点に飛び火してしまったわけです。
プログラマさん以外がもっている「プログラム言語」のイメージは 多分数学の時間に散々学生を苦しめた「関数」だと思うのです。(y=f(x)というやつですね。)
で、数学の「関数」というのは、 人間が問題を解くのに「分解」をするのですが、 それは人間が「解く」過程で式を次第に変形させていくだけで、 式自体に「時間」や「流れ」の概念はありません。 ただひたすらに「アレとコレは等しい」といった関係を記すだけのものです。
で、プログラム言語の「関数」というのはそういったものと大きく異なり、 関数の中で「流れ」、つまり時間が流れます。
これは人間が因果律を「時間の流れ」のなかでしか理解できないことと、 そもそも「コンピュータ」というプログラムの実行環境が「手続き実行」している ということに起因しています。
で、この時間の流れってモノを否応なしに生み出すのが、 言語(自然言語・プログラム言語)になるわけで、その結果 関数の中に「文」があるという、数学的関数の考え方では おおよそチンプンカンプンな状況が生まれたのです。
で、前回述べたように「文」はそのものでは内部完結してしまっていて
そのままでは肝心の「処理」に関われないため、変数をいう接着剤を使います。
これで文と文をくっつけると式になります。
それと前回は漏れていたのですが「集合」の概念に
タイムアローというフレーバを降りかけて「場合分け」にしてしまっている、
なんてのもあるような。
要はプログラム言語の「文」は、「式」の分解・変形なのよね。
もちろん分解・変形する一番の理由は、その方が理解しやすいからです。
で、こっちの方が人間には理解しやすいものの、 おそらく文に分解して考えるやり方は、「プログラムの本質」ではないハズです。 本質ではないだけに、「冗長」になるのは仕方ないところ。
しかし、「翻訳」には「誤訳」がつきもので、 「間接的」にプログラムを作っているような現在の言語というのは、 間違っているのかもしれない・・なぁんて 思考がどんどん飛躍してしまいました。(^^;
しかも更に(おまけ)がついて、
「もしかして、ヒトが"時間の流れ"に支配されてしまうのは、
"ことば"を覚えてしまうからかもしれない」と発想を飛躍させてしまうのが、
SF大好きな猫らしいところ。
だって、どうせ言葉を覚える前の記憶なんてないんだもん。
「とんでも仮説」だって否定されないわ♪
と、言うわけで、当初用意していた結論、 「プログラマはプログラム言語でモノを考えるから、どうしても言語に思考が縛られてしまう。 だからプログラマは複数言語を覚えた方が良いのよね。」は ちょっと電波なトンデモ発想の前にすっかりわきに置かれてしまった、というのが前回の日誌の真相です。(^^;
わき道ついでに・・。
で、猫は一つ疑問に思っているのですが、 プログラム言語の「関数」はどうせ内部に「タイムアロー」を持ち込んでしまった時点で、 数学的な「関数」ではありえなくなっているんです。
「関数」の考えとして戻り値は関数自身の「評価」、 ファイルを保存したりなどの処理は評価過程の「副作用」と取り扱いますが、 人間にとって重要なのはその「副作用」のほうで、 そうなると「戻り」以外にも値が取り出したくなってきます。 で、引数で値そのものではなくアドレスを渡したりして、引数から値in/outするのが 今日の「関数」の子供達です。
だったらなんで戻り値は一つにこだわるのかしら。 引数と同じように好きなだけ定義できればいいのに・・・。 (「例外のスロー」なんて「巻き戻し戻り値」を定義するより、 複数戻り値の方がよっぽど素直だと思うのだけれど･･･)
例えば
//**************************************
//
// 関数の定義
//
//**************************************
function GetHoge( param1 ,param2 ,param3 )
{
// なんかの処理。
}( ret1 ,ret2 ,ret3 ) // ←(戻り値の定義)
みたいなシンタックスの文法の言語のほうが、 引数に ref(=参照)だの out(=出力)だの修飾する文法よりは 良いと思うのですが・・。
(ひょっとして猫が勉強不足なだけで、もうそういう言語があったり、 それをやらない理由があったりするのかしら?)
前回の雑文を書いて心を躍らせる考えがあって、 それは、「神様が手をパンッと叩くとその間に時空が生まれる」という アイデアに基づいたプログラム言語ってのはどうよ?ってものです。
ブロックを示す「{ }」の中でのみ、「時間(フロー概念)」、「空間(=変数)」が 存在できるけど、その外からは一つの「式」としか見えない。 この発想をベースに文法を組み上げていった時、 その先にはどんな言語ができるのかしらん。
解りやすく言うと「{ .. }」は必ず戻りを持つ(評価されると結果を出力する)という
文法です。
これの行き着く先はLispの方言でしか無い気もしないではないですが(笑)、
ちょっと考えてみたいところです。
キモは最もルート側をどう表現するか、と 制御構造を上手く翻訳できるか、というところだと思うのですが・・。
と、素人があれこれプログラム言語を考えるだけというのは 楽しいのは本人だけなんですよね(^^;
猫はどうもオブジェクト指向には「道を誤った」という感じを受けるんです。 そう、地球から空を見上げると見かけ上天が回転しているように見えるので、 天動説を組み上げてしまったような・・、なにか根本的に間違ってしまったまま、 パラダイムを組み上げてしまった感じを受けるのです。
で、何が間違いなのかと考えていった時、 どうも継承という機能が怪しい・・。
最初、猫が「継承」という概念を勉強したときは、 「既存の処理を改良するとき、既存のソースと新しいソースを分離できる」 という、ソフトウェアの再利用性を高めるメリットが強調されていたような気がします。
しかし実際は早々都合よく前に作ったものを「継承」しただけで 再利用できるわけもなく、最初から「継承」することを想定して作ってないとダメ という現実をまざまざと見せ付けられました。 でも修正内容が製作時の予想を超えてしまうのはよくあることです。(TT)
また、無理に継承すると、「継承」自体がプログラムの「縛り」となり、 どんどん柔軟性を奪っていきます。 結果、「継承」によるソフトウェアの再利用という幻想は、 「継承」はオブジェクト・スパゲティを作るのが簡単だ・・という現実を 猫に身を持って教えてくれることになりました。(TT)
次に「継承」が大手を振って帰ってきたのは 「インターフェイス」の統一という考えかたを引っさげてです。
これは「同じモノのように扱って問題のないもの」を定義できる なかなかGoodな利用法ですが、それを前面にだすのなら「継承」っていいかたは 変よね、とも思うのです。
（まったくの余談ですが、 「インターフェイス」というのは、オブジェクト自身が持つのではなく、 そのオブジェクトの周りが与えるという方が考え方としては自然だと思うのです。 (どのように実装すればよいか、てんで検討もつきませんが・・・) )
継承は「使えます」。
既存のクラスライブラリをチョット拡張する、とか 大きな箱組みをオブジェクトに与え、画一的に扱える、とか または、テンプレート・メソッドパターンのように「土台」を用意するような使い方など、 「継承」の恩恵は凄まじく、「継承機能」はOO言語の必須用件というのは肯けます。 (もしかしたら「定義」を「継承」するというのが変なだけかもしれません。)
でも、継承関係にあるオブジェクトは否応なしに「強い依存」を生み、 下手に使うとオブジェクトのカプセル化を阻害してしまいます。
なんだか継承への不満をくだくだと書いてきましたが 要するに使うのが難しいということです。 なまじ機能が強力なだけに上手くつかわないといけないところなのだけれど、 だからこそ「継承」はgoto文のように「危険な」機能だと思うのです。 (でもgoto文のように「原則使わない」のようには扱えないのが歯痒いところです。)
「継承」の上手な使い方をマスターするのは世のOOPプログラマの必須要綱です。 現実的には継承の恩恵だけを授かる方法はいまのところありません。
でも、構造化プログラミングでgoto文を使わなくても分岐が書けるようになったように、 C言語のポインタからポインタ演算が省かれたように 将来OO言語の「継承」は残っても「今の継承機能」は消えてゆくものかもしれません。
というか、消してください。(TT)
暇なのです。暇な時は空想がはかどります。
以上、思ったままを無検証につらつらの書きづつりました。きっと内容はデタラメです。
なぁんか、サブウインドウ特許で 盛り上がっているようですが、 要点わかっている人と居ない人がいるような。
そういう猫も「三猫ヘッドライン」での解説文にも 間違いもあるので大きなことは言えないのですが。(^^;
結局特許の内容は、
というものの様子。
<HTML>
<HEAD>
<TITLE>特3393199号 請求項1+2です。</TITLE>
<SCRIPT language="javascript">
<!--
// 子ウインドウハンドルを保持するグローバル変数を定義する。
var m_subWindow;
//-->
</SCRIPT>
</HEAD>
<BODY onLoad="m_subWindow.close();">
<SCRIPT language="javascript">
<!--
// (1) ランダムなURLを生成(subXX.html) ---------
var subWindowUrl = "sub" + Math.random().toString().substring(2,4) + ".html";
// (2) サブウインドウをオープン ----------------
m_subWindow = window.open( subWindowUrl , "サブウインドウ");
//-->
</SCRIPT>
<H1>メイン画面</H1>
<P>
と〜っても重い画面です。
</P>
・
・
</BODY>
</HTML>
なんだかランダムURL作る部分がヘッポコですが、良しとしましょう。
キモはBODY要素のなるたけ先頭で「ランダムURLの作成」「子ウインドウを開き、そこに生成したURLのページを読み込む」 という風にウインドウを開くこと（「請求項1」です)、 BODY要素のonLoadイベントでページを閉じること(「請求項2」)でしょうか。 (BODYのonLoadイベントはページの読み込みが完了したときに呼ばれます。)
こんな感じのソースをページに仕込むと 特許侵害といわれてしまうわけです。う〜ん、こんなんで特許とれるのね。
・・・と、いうのは今日の日誌にはなぁんにも、関係ないことなのだけれども。
言葉というのはいったい何?とプログラマの視点で考えることがあります。
言葉というのは、
というところまでは異論の無いところです。
脳で紡がれた思考は「言葉」の形を取ることで外部へ、他者へ伝えることが出来ます。
ところが「言葉」を使って「思考」しているかというと微妙です。
大人になってしまうと、言葉でしか思考が出来なくなりますが、 子供の時ってそうでなかったような気がします。 というか、今でも「言葉にできない・・・」というデータが 脳の中から湧き出てくるのですが、それを「思考の例外」として よけるのが大人になると上手くなる、ってだけの話かもしれません。
猫は子供の時、「思考」に「言語化」が追いつかなくって、
オーバーフローした端から「思考」が揮発していく、ような感じの
もどかしい想いをした記憶があります。
今となっては「ホントにそうだったのか」は自信の持てないところなのですが、
思考を「言語化」しておかないと、自分の脳内でさえ保存はむずかしい、とのことかしらん。
でも、思考というか「感じたこと、思ったこと、考えたこと」は、 言葉だけじゃ言い表せないのが現実です。 言語はどちらかというと「考えたこと」を捏ね繰り回すのが得意で、 「感じたこと」はあんまり上手に扱えません。
ところが「歌」や「音楽」は「気分」・・「感じる、思う」という 心の色を再現させることが出来るようで、 特に「歌」はその情報量は言葉を完全に超えることができます。
さて、日本語の凄いところは「表意文字」を含むところだとおもいます。 「表意文字」は「意味がつかみやすい」だとか、 「文書面が簡潔になる」とか色んなメリットがありますが、 猫はじつは「絵である」というメリットに勝るものは無いと思うんです。
例えば「虫」と「蟲」。 何かの文章で呼んだのですが「蟲」は「虫」に置き換え可能とされているけど、
虫がっ!
と
蟲がっ!
では、与える印象が違います。 ・・・という解説を読んで、至極納得するのです。
こと文学では、こういった字の形が与える「印象」を上手く操っていることがおおく、 「カナモジカイ」のような、文字をコードとしてしか捉えない考え方は、 全てにおいて正解ではないのは明らかです。
発音するときも、「音」がとても大事で、 どうも「ことば」というのは「コード体系」「フォーマット」といった 至ってデジタルな要素だけでなく、 それを表すために使う「図形」や「音」にも アナログちっくな情報を持っている、と考えてよさそうです。
プログラミング言語に話題を持っていきましょう。
プログラミング言語において、「begin ... end」の問題があります。 BASICやPASCAL、RUBYでは「end」などの文字列で、 ブロックを示します。 C言語とその子供達は「{ ... }」でブロックを、Pythonではインデント(段落ち)の深さが一緒なら同じブロックとして、 Lispでは「(progn .. .. ..)」のような表記の仕方をします。
Lispはちょっと例外として、 他の言語では表記法が違うだけで、内容は一緒。 しかし、それぞれの表記法はソースを図形的に見たとき、大きな違いを生みます。
プログラミング言語が 「自然言語風」に見えるか、「数式風」に見えるか「図形風」に見えるかは、 趣味の問題でしかありません。
例えば、関数を定義して、if文、else if、elseとするロジックを
(引数)[→]：Hoge
(条件式)[○→]
処理内容
[×] & (条件式)[○→]
処理内容
[×→]
処理内容
[←]
[←](戻り値)
のようなに記す文法や、
function Hoge(引数)------------- | | if(条件式)------------------ | | | | 処理内容 | | | |(別の条件式)---------------- | | | | 処理内容 | | | |---------------------------- | | | | 処理内容 | | | |---------------------------- | |<<(戻り値) |--------------------------------
に記す文法があったって良いわけです。 (記述が面倒なので、誰も使わないとは思いますが)
このような言語があったとき、上の文法は、
行ったり出たりを意識させますし、
下の文法では、処理のブロックというのがとてもハッキリ認識できます。
これは極端な例ですが、C言語の複文化構文「{ ... }」は
処理を構造化する風に思考を誘導しやすいものだと猫は思います。
そして、プログラム言語の「字面」の与える「印象」は 次第にプログラマの思考を縛りはじめます。 プログラミング言語の文法も、然りです。
例えば、C言語での関数呼び出し
value = FunctionName( pram );
は、たとえ 引数と戻り値の無い関数でも「省略されている」という考え方を生みます。
また、End構文を持つ言語は、 コードの行が時間的な積み重ねを持つような印象を与えます。
多分言語は思考の自由度を蝕むのでしょう。
猫は正直、今のオブジェクト指向の持つ根本的な「複雑さ」に 今のクラス型オブジェクト指向という考え方の持つ歪みを感じます。
美しいものは再帰的になっていて、シンプルな法則に支配されています。 構造化プログラミングを猫が美しいと思うのは、 構造が再帰的だからです。 しかし、クラス型オブジェクト指向はオブジェクトを再帰的に記述できません。
オブジェクトはオブジェクトから出来て無くてはならないのに、 オブジェクトを定義するのに「クラス」が必要で、クラスはフィールドとメソッドから成っていて、 メソッドを「オブジェクト」として扱えないからです。
(だから猫はC#の「プロパティ」と「デリゲート」が好きです。ちょっとだけ前進しているからです。)
なによりメソッドもフィールドも「戻り」があるのに、クラスは「構造」だからクラス自信に「戻り」がありません。
「式」と「文」の違いは、 「式」には戻りがあるのに、「文」には戻りが無いことです。 C言語風文法で「文」と「式」を見分けるには、「( ... )」で囲んでみると簡単です。
(1+1) // 式
(value = 1+1) // 文
なんだか「式」の方は「( ... )」で囲むの 外から一つの値として扱えそうでしょう? でも「文」のほうは「( ... )」で囲んでも、かっこ内部の世界で完結して、外に影響を及ぼさない風に見えます。
内部で完結するならば、そんな処理をする必要はないので、 プログラムの本質は「式」のみで構築されなければなりません。 しかし、ここに「変数」という「箱」を積み重ねることで、 結果的に式にすることが出来るようにしたのが「ヒトの使う」プログラム言語です。
例えば、式
((((1 + 1) * 2) - 1) / 3)
は、次のような文の塊で表現できます。
{
var value; // 文に分解するための「箱」を定義
value = 1+1; // value = 2になる
value = value * 2; // value = 4になる
value = value -1; // value = 3になる
value = value / 3; // value = 1になる
return(value); // ※文の集まりを式にする処理
}
「処理」がプログラムの本質である以上、 必ず「文」はいつかは束ねられて「式」と成ります。 (だから、C言語は、束ねた文の集まりを「関数」と名づけたのでしょう。) でも、一度「文」という「シンタックス・シュガー」を用意してしまった為に、 プログラマは「文」という幻想を本当にあるものだと思ってしまいました。 (正確には、「文」と「式」が別なものである、と感じてしまう幻想です。) (そしてもう一つ、「文」というシンタックス・シュガーは「時間」というアローを作り出します。 タイムアローを作り出すからこそ「シュガー」になるとも言えます。)
クラスはそのスタート地点が「箱」である変数(の拡張定義であったCの構造体)であるため、
今尚単体で「式」に変形することが出来ません。
しかし、「箱」は変形過程で省かれるものです。
だからクラスとクラスの関連しあい、互いに打ち消しあうことで「式」を作ることができます。
この「変形」の過程は複雑で、直感的に理解でないため、
「デザインパターン」という武器を振りかざすしかないのは、
数学の問題を解くときに「公式」を振りかざさざるを得ないのと似ています。
現在のオブジェクト指向、「箱」に「処理」を入れられるようにしようという方向性になってしまったのは、 きっと プログラム「言語」に縛られた思考の成せる技でしょう。 (よって「クラス」はタイムアローに強く縛られたものとなっています。)
プログラマが複数のプログラム言語を覚えなくてはいけないのは、 きっとプログラマにとって福音です。
(もしかしたらヒトは「言葉」を覚えた瞬間、 タイムアローに縛られるようになるのかもしれない、なぁんて・・。)
いろいろ考えること。 それはとても無責任だけど楽しいことです。
今日は思考の赴くままブラブラと散策し、 その結果をだらしなくロギングしてみようと思います。
えっ?、いつもとかわらない!?
日本語のキーボード配列を考える時、 良く玄人の意見として言われるのは「入力効率が良い」こと。 親指シフトなんかはその典型で、 確かに日本語の入力手段としては究極に効率が良いです。
しかしもう一つ重要なのとは、その配列を覚えやすいこと。 でもこれは、蔑ろにされています。
しかし、打ちやすくも無く覚えやすくも無い旧JIS配列は、 実は覚えやすいを目指して作られたものでした。
旧JIS配列(JIS X 6002-1980、つまり、今現在普通に売っている日本語キーボードの配列ですね)をよぉくみると、
五十音の各行が比較的まとまっています。
あ行、た行、や行は完全にまとまっていますし、
か行、さ行、な行、ら行も「一文字だけ」全然別のところに降られている
以外はシッカリまとまっています。
ま行に関しては、5文字中3文字が固まっているのみ、
は行に関しては完全にバラバラですが、
結構まとまっているのに気付くハズです。
で、この「一文字だけ・・」の仲間はずれ文字 「け」、「せ」、「ろ」と、ま行の仲間はずれ文字 「む」、「め」は、何故かキーボード右端に固まっています。 唯一の例外が「ぬ」なのですが、これもまた一番左上のキーになっています。
| ぬ |
ふ |
ぁ あ |
ぅ う |
ぇ え |
ぉ お |
ゃ や |
ゅ ゆ |
ょ よ |
を わ |
ほ |
へ |
ー |
||||||||||||||
| た |
て |
ぃ い |
す |
か |
ん |
な |
に |
ら |
せ |
゛ |
「 ゜ |
|||||||||||||||
| ち |
と |
し |
は |
き |
く |
ま |
の |
り |
れ |
け |
」 む |
|||||||||||||||
| っ つ |
さ |
そ |
ひ |
こ |
み |
も |
、 ね |
。 る |
め |
ろ |
||||||||||||||||
実は旧JIS配列って、ある配列に無計画にキーを増設した結果出来上がったものなんです。
上の図で黄色く縁を囲った7個のキー、「ぬ」「へ」「せ」「け」「む」「め」「ろ」は、
旧JISの元となった配列では他の50音キーのシフト配置になっていました。
ところがタイプライターが42キーから48キーになったとき、
シフト配置されていたキーを何の考えも無く増えたキーに
割り振ってしまいました。
そのため、元となった配列の持っていた「50音で並べる」という思想を破壊し、
覚えやすさも打ち易さもないダメダメ配列を作り上げてしまった、というわけだそうです。
とまぁ、ここまでは比較的有名なお話です。
(参考：ＪＩＳキー配列の不規則配列の謎を解く)
旧JIS配列は本来50音の行ごとにキーを纏めて覚えやすいことを目指していた のは解りました。 でも旧JISの元となった配列(山下配列)って、なんで50音を素直に並べなかったのでしょうか?
もちろん当時のタイプライターの42キーに50音は素直に並びません。 でも、山下配列が素直になれべていないこと。 考え出すとこれは結構奥が深いんです。
まず、このキーは位置を素直に打つことを考えた場合、 ホームポディションは「F」「J」の行ではなく一行上、「R」「U」に持ってくるべきかしら。 そうなると旧JISの弱点「を」は、逆に非常に打ちやすいポディションとなります。
また、「ん」と「や」行が左手ホームポディションから+1の移動範囲にすべて収まっています。 これは日本ので多い「拗音」(「しゃん」とか「きょう」とか)の打ち易さに配慮した結果と見えます。
「ホームポディション」を移動させるという考え方が出来た時、 山下配列は
という、かなり優れた配列であることがわかります。
そして4段全てを均等に活用するのならホームポディションは一段上の方が 理に適っている点も見逃してはいけません。
つまり、現在の旧JIS(改悪山下配列)は 覚えやすさこそ失われたものの、ホームポディションさえ一段上に持ってくれば 日本語が打ちやすい配列ということになります。
これは「旧JIS」= つかえない と思っていた頭には結構新鮮なことです。
(でも山下配列のほうが旧JISより絶対いいのよね〜。)
猫は今回山下配列に思いをはせるのはとても楽しかったのですが、 満足度の大変低い現在の日本語入力環境、 みんながみんな黙っているとは思えません。
というわけで 世の中には他にも数多くの入力方式があります。
それぞれの入力方式を検証していくのはやっぱりとても楽しいのですが、 猫が注目したいのは日本語入力方式が思考に与える影響です。
猫はもう申し開きが出来ないくらいのキーボード収集家ですが、 猫がキーボードを集めてみて初めて気付いた事実、それはキーボードを変えると 思考が変わることです。
全然根拠のない話なのですが、猫は思考には文字で表せる「意味」の他に、
「感情」とか「気分」が絡んできます。
キーボードは文字を綴る道具ですが、同時に感情を奏でる楽器でもあると思うんです。
人は言葉を喋るときに抑揚をつけます。言い換えれば人はいつも小さな歌を歌っているんです。
楽しい歌を歌えば沈んだ気分も楽しくなっていくように
言語のもつ抑揚はきっとそのユーザの思考に影響を与えつづけていることでしょう。
同時にキーボードの打鍵感や入力方式も 文字を入力する人たちに感情的影響を与えます。 これは「打鍵音」として耳に入る情報だけでなく、「打鍵感」として指に伝わる情報も然りです。
で、最近猫が興味を持っている入力方式にAZIKがあります。
これは拡張ローマ字入力とでも言うべき方式で、 ローマ字でありえない綴りに、現在のQwertyローマ字入力で 打ちにくい配置を割り当てて行こうという方法です。
猫がコレに魅かれるのは、猫の愛すべきキーボードがそのまま使えることと、 うったら気持ちよさそうな改良点の二点です。
なにが気持ちよさうって、 「あん」「いん」「うん」「えん」「おん」といった撥音と、 「あい」「うう」「えい」「おう」などの二重母音を1字で入力できること。
たとえば、
ちのり の ついた ほうたい の まま しんぐんしろ と いう TINORI NO TUITA HOUTAI NO MAMA SINGUNSIRO TO IU TINORI NO TUITA HPTZ NO MAMA SKGJSIRO TO IU ふぁんねる が なんで あんなに もつんだ!? FANNNERU GA NANDE ANNNANI MOTUNDA!? FZNERU GA NZDE AQNANANI MOTJDA!?
のようになります。 「あんっ」という音を一キーで打てるのは気持ちよさそう。
こうしてローマ字で並べるとなんだかトンデも配列に見えますが、 撥音はもとの母音の下、二重母音は基本的に元の母音の隣のキーが割り当てられているため 覚えやすそうです。
猫がキーボードのためし打ちをする時、どんな方法を使っているかといいますと、 歌を聴きながらその歌詞をテキストエディタで入力する方法を取っています。 この方法を猫が愛用するのは、 打鍵感による入力スピードの変化が客観的にわかるという とっても論理的な理由と、 楽しいという極めてわがままな理由があります。 で、多分後者の方がおっきな理由です。
タッチタイプを習得している人には是非やってみてほしいのですが、 これがすごぉく、気持ちいいんですっ!
スローテンポの曲で、変換無しでないととても「歌うように」は打てないのだけど、 メロディーに合わせて文字を入れてった時の「歌ってる感」といったら!! なんか「新しいゲームにならないかしら?」と思うくらい気持ち良いです。
ちなみに猫がいま歌打ちで 一番いいわぁと思ってるのがCherryのMXリニア。 文字の度に打鍵がポコポコ区切れる他のキーボードと違って ほんとに歌ってる感 演奏してる感 が気持ち良い。 この子との打鍵作業は合唱できれいに声がハモったときのよう。もう、うっとりです。
逆に一番面白くないのがRealforce。
なんでかなぁ、ってくらい面白くありません。
面白くないんですが、憎たらしいくらい打てるんです。
まるで「こんなことやってバカみたい」とつっこまれているみたい。
このキーボードは、なんか棒読みで、全然歌ってくれないのだけど
棒読みだけど速い速い。さすがです。
ん〜、猫はこの子「お気に」じゃないけど、
富士通高見沢の打鍵感より好きじゃないけど、
修羅場とかで凄い頼りにするんでしょうね。ええぃ、小生意気な秀才くんめ〜っ!素敵だわっ!!
・・・と、言う風に、 「歌打ち」をするとその子との付き合い方が見えてくるというか。
・・・・・・病気?
話は少し変わって。
旧JISの歴史的不幸を除けば、日本のキーボード配列に足りなかったもの、 それは「スタンダード」という考え方です。
「日本語は特殊」だから「特殊な配列」でもよい。 この考え方のせいで、スペースバーは「変換」「無変換」「カタカナひらがな」の3キーもの サイズを削り取られ、BackSpaceと右Shiftは一つづつキーを削られました。
そして何より移動される必要性のない「記号」キーを独自にリマップされたため、 私達は「日本語をローマ字で入力する」という妥協をしているにも関わらず、 英語キーボードを素直に使うことを許されていないのです。 も〜っこれってどういうことかしらっ!
特に、日本語という文化の柔軟性は、 日本語英数記号混じり文をなんなく受け入れてしまいました。 (これは一重に日本語横書きを左から右に変えてくれた誰かさんのお陰でしょう。)
・・・という風に、 柄にも無く日本語キー配列の歴史に迫ったりしたのは、 素敵な英字キーボードをストレスなく打てないこの環境にぐだぐだ愚痴を言いたいだけでした。
えぅ〜・・。
日本の文字政治に強い影響力を持つ黒幕「カナモジカイ」。 猫はこの「カナモジカイ」ってヤツが嫌いです。
もちろんタイプライターの時代にはカナモジカイの主張は「一理ある」ものでした。 でも、FEPが有る現在の日本語入力環境では「カタカナタイプライター」なるものの恩恵は薄れ、 漢字の習得も事実上「読み・書き」から「読み・選択」(語呂がわるいわ)にシフトしまった今、 カナモジカイは負の遺産しか残してくれていません。
カナモジカイの残した最大の負の遺産、それは「漢字を減らそう」運動です。
文盲率を減らすには漢字をなくしたほうが良い。たしかにそれはそうですが、 ですが彼らは「書き」にこだわりすぎ、漢字かな混じり文の格別の読みやすさを 蔑ろにしてしまいました。 結果「似た漢字は定義しない」などという方策をとりそれが政治的な力を持っていたことから 新聞にも「タンパク質」などと言う表記が踊るしまつ。 ハッキリ言って、猫は読みにくい漢字にはルビを触ればすむ話だと思うのです。
なんだか論議の的が無産してきた気がしますが、 つまり、カナモジカイって途中から「漢字をなくすこと」が手段じゃなくって目的になってしまって、 もうカナモジカイのカナ文化を目指そうとした目的はうしなわれているのに、 なりふり構わず漢字をなくそうとしている。
その結果、文字コードに必要な文字を徹底的に減らしてしまったこと。これはもう犯罪です。
文字コードに関して言えば「大は小を兼ねる」が正義です。
いろんな思想的違いがあるのなら、両方選べるようにするのが、正しいスタンスだと思います。
もし「下の長い"吉"」が紛らわしいというなら、
名前にはその字は使えないとすればいいのです。法律でそういう名前を禁止すればいいのです。
そういう「社会的反発」を避け、裏でこっそり使えなくするその姿勢、
卑怯千番以外の何者でもありません。
猫はカナモジカイが嫌いです。 だって、私の仕事を増やしてくれるんだもん。 日本語業務システムを作る身にもなれってんだっ!!、です。
オブジェクト指向はC言語から見た場合、 構造体のメンバとして関数を含めることが出来るようになったというものですが、 これが意味するところは、プログラムの「部品」に時間の概念を持てるようになった、 ということに他ならないと思うのです。
モノは時間をとともに「経験」を得、その結果がモノの「状態」に影響を与える。
だから私達はそこらに落ちている石にも、その石の形、その石の傷一つにその石が生まれたどってきた歴史に
夢をはせることが出来る。
こんな当たり前なことを当たり前な様にプログラムできるようになったのがOOPだと思います。
状態を記録するための変数と、 経験を制御する関数を一つにパッケージングすると、 それは「オブジェクト」というものを記述することが出来るようになる。
この発想こそオブジェクト指向の原点で、 この発想の飛躍に猫は「すごいなぁ」と思うのです。 で、この論理でいくと、ノイマンさんの先見性もとても凄い。 だって、データとロジックを同じように扱うって発想がなければ、 オブジェクト指向なんてのも「机上の空論」になってしまったかも知れないもの・・。
えっと・・・・。仕事干されました。えぅ。
お財布がピンチです!
最近めっきりCherryのトリコになっている三猫です。
Cherryのいいところはひとえにスイッチに尽きます。 そのスイッチを使ったFILCOのFKB91JUなのですが、 そのスイッチの良さと、テンキーが無い、日本語である、 という3点はとても評価するのですが、 その配列・キーボードデザインは紛れもなくFILCOのそれで、 そこらへんはCherryの精神とは相容れないモノがあるのは事実。 猫にとっても大きな減点対象です。
そこで登場なのがこのCharry ErgoPlus。 なかなか売っていないのですがShopUで入荷して頂けたのと、 掲示板で入荷情報を教えてくれた方のおかげでGetすることが出来ました。 本当に感謝です。
 |
| Cherry ErgoPlus |
打鍵感ももちろん素晴らしいのですが、 このキーボード、配列も究極なんです。
FILCOのFKB91JUに無くてこのErgoPlusにあるもの、それは「無い」ことです。
物事なんでもそうですが、 意外に忘れがちになるのは「無い」ということが有ること。
商売がカタログに列挙出来るスペックを求めるのは性がないところなのですが、 「無い」という機能、それは結構重要なんです。
このキーボードは確かに変則配置ですし、 キーの位置関係だけみればFKB91JUと似たりな所もあります。 でも、本機にはちゃんと「キーのないところ」が有るんです。
 |
| 「無い」が有る配列 |
見ての通り、CtrlとAltの間にも、メインキーと機能キーの間にも、「無い」があります。
ファンクションキーもちゃんと4キーづつ「無い」を設けてあります。
省スペースなキー配置を求めて勘違いしてしまうのは、
この「無い」を削ることがスペックダウンだということが気づかないことです。
そういう配列を見るたび、「ああ、解ってないわ」と猫はがっかりするのです。
良く論議の的になるWinキー問題も、この「無い」ものが有るという性能を、 理解している人としていない人がいる、という背景にあります。
Winキーがいらないといと主張する人は、
「Winキーがあると他のキーが狭くなる」とか「使わないから付いているだけ無駄」とか
言うので、Winキーが欲しい人は、
「右Winキーをオミットすれば他のキーのサイズに影響はでないハズ」とか、
「別に使う人は使わなければいいだけじゃん」とか反論するのです。
でも、本当のところはCtrlとAltの間の「無い」が無くなってしまう(スペックダウンしてしまう)ことが
問題なのです。
こう見ればこの二つは完全に2者択一となり、だから欲しい派といらない派を相容れないのです。
この問題の完全解も本機は提供していて、 CtrlとAltの間にちゃんと「無い」がありますし、 キーボード左にWinキーもAppキーもちゃんとあります。 この配列を見るたび、「Cherryって解ってるわぁ」としみじみ思います。素敵です。
世の中、キーボードでエルゴといえばナチュラルキーボードです。
ですが、世の中には「アジャスタブル」という発想もあるわけで、 手首の負担を減らすだけなら「ハの字」に開けばOKです。
MSのNatural Keyboardが余りにも印象的だったせいか、開き加減を調節出来るキーボードって
余り見ません。
でもキーボードを打つときは手首は開きつつも肘は体にぴったりつけるのが
「つかれにくい」打鍵スタイルなので、
あまり「ハの字」に大きく開きすぎると肘が体から離れてしまって
かえって疲れにくくなってしまいます。
そういうわけで理想は「開き加減が調節できる」方が良いということになります。
 |
| キーが開く! |
というわけで開きます!。自由自在に開き加減が調節出来ます。
意外かもしれませんが、これがとても打ちやすい。
もうアジャスタブル最高です。
そしてナチュキー的エルゴの条件のもう一つ、それはキーが傾くことです。
人間工学的には手というのは水平じゃなくって人差し指側を高く、 小指側を低くしたほうが手首への負担が小さいといいます。 (これには猫は異論があるのですが・・・)
Appleのアジャスタブルキーボードは、この「傾き機能」をサポートしていなかったが為に、 「エルゴではない」などと言われてしまうくらい、 「開き」と「傾き」はエルゴキーボードの2大用件担っています。
もちろんErgoPlusも製品名に「エルゴ」を冠する以上傾きます!
 |
| Cherry ErogPlus 'NatuKey' Mode |
これじゃわかりにくいので、もう一枚!
 |
| キーが傾く! |
見ての通り傾きが付いています。
このキーボードは左右のキーボードのジョイント機構が軸ではなくスプリングなので、
傾き方向にも楽々動かせます。
あとはチルト(?)スタンドを調節するだけで
ナチュキーモードに変形完了です!
この「傾き」に関しては猫はちょっと異論が有りまして、 実は水平配置でもキーボードというのは常にキーを押しっぱなしの器機ではないので、 余り問題が無いハズなんです。
というのも、キーボードに手を乗っけて文字を打たない状態(待機状態とでも言いましょうか)では、 小指はキーに触れているけど人差し指は完全に中に浮いている様な状態にすることが出来ます。 これは水平配置でも打っていないときは手首に負担を掛けにくいということ。
もう一つは人差し指の方が力が強いということ。
その傾きから打ちにくいハズの人差し指は一番力が強く、 一番打ちやすいハズの小指が一番力が弱いというのは有る意味理に適っています。
そんな理由から「開き」より「傾き」の方が エルゴ的視点では神通力が弱いと猫は思います。
・・とまぁ、個人の考えはいろいろあるということなんですが、 このキーボードの良いところはその主義主張やその日の気分で、 ただ開いてるだけとか、傾きをつけてとかを選べるところ。
またパームリストを省けばその大きさはSpace Saver II Keyborad程度なので、 一般にある「ナチュキー = 巨大」というイメージにも当てはまらない、 コンパクトなのも魅力の一つ。
本機の配列に対する唯一の文句は、日本語配列じゃないこと。 でもそもそもCherryには日本語キーボードなんてものはないですし、 日本のキーボードメーカを見回すと、このような大人なメーカは皆無に等しい状況です。 うん、なんだか猫が生きている打ちにはこの配列を越えるキーボードは出なさそうです。
う〜ん、そろそろ潮時、猫も英語配列のタッチタイプも覚えなくっちゃならない時期に来たようです。
コンジョだ! 根性〜っ!!
Slashdot JAPANニュースを読むついでで、 ハッカーになろうという文章を読みました。 (なんだかずっと前に読んだことがある記憶はあるのですが、いったいいつだったかしら?)
猫はハッカーじゃありませんしハッカーになる素質も無いので、 ハッカーについて語る資格は無いのですが、文中でとてもとても引かれる文言を見つけました。
でも、言語を一つしか知らないなら、ハッカーではないし、プログラマですらないのです。あなたはプログラミングの問題について考えるのに、ひとつの言語に依存しない一般的な方法を身につけなくてはならないからです。真のハッカーになるには、マニュアルの記述を自分のこれまでの知識と関連づけることで、新しい言語をものの数日で習得できるようにならなくてはなりません。ということはつまり、ぜんぜん違った言語をいくつか学ぶべきだということです。
う〜ん、けだし名言。
「言語を一つしか知らないならプログラマではない。」
これは結構 目からウロコです。
プログラム言語って、作った人と育てた人たちの想定する「精神」みたいなものがあって、
それが文化になっているんです。
ところが、多くのプログラマさんは自分が一番最初に覚え育った言語(母国語みたいなものですね)の「文化」を
「常識」と思ってしまって他の言語を使うときもそれを持ち込んじゃうことが多いんです。
そうなると例え元の言語では「有能」なプログラマでも「無能」や「問題児」になります。
で、問題なのは言語の(市場的)寿命よりも人間の寿命の方が長いということ。
プログラマは母国語を幾ら極めようともいずれ亡国の民になる宿命なんです。 このとき、プログラマさんは「年齢的に固くなった頭」とかを理由に 新たなる母国語を得ることを諦め、国と運命を共にしちゃわざる得なくなる場合が多い。 これが「プログラマ35才定年説」の理由の一端です。
でもでも、そんなことは無いと思うのよね。
猫は二個目以降のプログラム言語の習得って、 難しくないと思うんです。 正直、よっぽどパラダイムの違う言語でないかぎり、 そこそこ使えるようになるまでは4,5日もあれば十分です。
もちろんバリバリのエキスパートにイキナリ慣れる訳でもないのですが、
とりあえず「いちおうちゃんとつかえる」ように成るのは、
そんなに難しくないというのが猫の実感です。
でも、そうは思っていないプログラマさんって結構多い。
この境界ってなんなのかな?って考えたとき、 漠然としたものはあるのですが、上手く説明できない。
多分コツみたいなのがあるのですが、 「差分で覚えればいいから楽だよ」とか、「う〜ん、実はライブラリや環境まわりは 覚えなくてもいいから、実は覚えるところはあんまり多くないのですよ」とか、 はたまた話を教育問題にまで格上して 「詰め込み型じゃ良いプログラマになれない。「覚える」ことより「考えて」「理解する」ことほうが重要なんだ!」 なあんて如何にも「らしく」説明しようとするのですが、どうもイマイチしっくりこない。
で、冒頭の引用句になるんです。
プログラマが新しい言語を覚えるのが楽なのは 「自分のこれまでの知識」をマニュアルの記述に「関連づけ」するだけでいいからです。 自分のなかの知識データベースが「関連づけ」できるような構造で構築されているか否かが 「プログラマ」とただの「言語ユーザ」の分かれ目なのかも。
小説家が「読み書きできる人」じゃないのと一緒で、 「プログラマ」は「プログラム言語を読み書きできる人」じゃない、というわけです。
盲点だけど考えてみれば当たり前のはなしよね・・。
さて、この本質的な「プログラミングの知識」を構築するには
「ぜんぜん違った言語をいくつか学ぶべきだということです。」とあります。
そして全然違った言語を学ぶのは、それはそれは楽しいことです。
(納期が絶望的な仕事でそれを押し付けられない限りですが(笑) )
「ハッカーになろう」の中でお勧めしている言語は、Python, Java, C/C++, Perl, LISPの五つです。 (但し、これら全部、ということですが。)
たしかに納得のラインナップなのですが、 それとは別に猫がお勧めする言語。それは JavaScriptです。
猫がJavaScriptを進めるのは特にJavaだとかC#、C++といった、 C++から派生したクラス型オブジェクト指向言語を愛用している人たちです。
動的Webページ生成用言語として、「素人向け」と思われることが多いJavaScriptですが、 実は「プロトタイプ型オブジェクト指向言語」という、 クラス型OO言語とちょっと毛並みのちがったオブジェクト指向言語で、 しかもちょっとだけLISPの香りもしてくる、かなり面白い「玄人向け」言語なんです。
その面白さをすこしだけ掻い摘んで説明すると、まずは JavaScriptが持つオブジェクト、その実体は連想配列であるということ。
これは
Cat.name; // Catオブジェクトのメンバ「name」
の実体は、実は
Cat["name"]; // Catオブジェクトは連想配列なので、これもアリ
なんです。
オブジェクトの実体が連想配列なので、
もちろん好きな時、好きな場所でメンバを追加することもできます。
これは型定義でメンバが固定されるクラス型OO言語とは大きく異なるところです。
そしてJavaScriptはメソッドを変数に代入できるという面白い特徴をもっています。 だからフィールドもメソッドも、動的にくみ上げることが出来るんです。
これはとても面白いことです。 クラス型オブジェクト指向言語では、オブジェクトは「定義」しました。 生まれた時から「そういうものだ」と決められているんです。
ところがJavaScriptでは、 オブジェクトは「組み上げる」んです。 生まれる前はお母さんのお腹のなかで人の形を組み上げられるように、 「時間的概念」のある中でオブジェクトが組み上げられていくものなんです。
そしてJavaScriptは、生まれた後のオブジェクトも 新たなフィールド・メンバを取得することが出来ます。 「生まれれる前」はヒトとして、「生まれた後」は人間として組み上げられていくような、 そんなオブジェクトライフが書けるってだけで、なんだかワクワクしてきませんか?
というわけで、とっても面白いJavaScriptについては、
お勉強リンクをご参照くださいませ。
(こういうときにリンク集を作ってあると便利ね。)
本としては、O'REILLYの「JavaScript -第3版-」をお勧めします。(というか、他のJavaScriptの本はJavaScriptって言語そのものに踏み込んでくれないのよね(TT) )
ちなみに今回のJavaScriptのお話が、これらサイトさんの受け売りだということはヒミツです。
最近、キーボードネタが増えてきた猫日誌です。 ほんとなら、キーボードルームのコラムにすればいいのにと思うのですが、 猫日誌は思ったことをその日のうちに書きとめるのスタイルなので、 ついついこちらに書いてしまいます。
というわけで、今回もキーボードの話です。
いきなりですが、皆さん、テンキーっていります?
ううん、「いる」とか「無いよりは有った方がいい」って言う人が多いきもするのですが、 じゃあ、ノートパソコンユーザのどれくらいが外付けテンキーを買うのかというと、 きっと外付けマウスよりは売れてないんでしょうね、と猫は思うのです。
テンキーの利点って、
位しか思いつかないのですが、(う〜ん、三つ目の利点は猫も欲しいところなのよね) 現実問題として、
など（3番目のは「そもそもプログラム自体が特殊用途」・・でいいかもしれない)、 テンキーってPCのデフォルト装備でなくってもいいくらいには、 重要度が落ちてきてると思うのです。(タブレットと同じくらいの位置付けで十分)
猫はテンキーが要らない生活を送っている人ですので、テンキーが着いてるのは無駄です。 も〜、切り離せるくらいなら、ばっさり切ってしまいたい。
だいたいテンキーなんて簡単に外付けできるのだから、
デフォルトで無くっていいじゃない。
フルキーからテンキーを外すのは普通じゃ無理なんだからっ!
そんなこんなで、 これだけPCの使い方の代わったご時世、「テンキー付き = 普通のキーボード」なんてナンセンス。 マウスが「特殊」だった時代ならともかく、 今は机の一等地をテンキーからマウスに受け渡したい、と思うのが自然じゃないかしら。
なら「省スペースキーボードにすれば」という声も聞こえてきそうですが、そうじゃない。
テンキーを外したいのは「省スペース化の手段」だからじゃなくって、
「使わないものをどかしたい」からなんです。
なにも使うものを窮屈にしてまで、欲しいもんじゃないでしょうし、
たかだか19mmだか38mmだかを幅詰めしたいと思うほど、
机が狭いわけでもない、ってのはあるでしょう?
なにより猫が問題とおもっているのはコンピュータの歴史の過程で 「テンキー = キーボードの拡張部分」という意識がすっかり取り除かれちゃったことです。
テンキーにある文字は全てメインキーで入力可能です。
そもそもデータエントリ用に数字のみを打ちやすく入力する為に、
増設した領域に過ぎないのですから、歴史が古いだけで拡張キー領域であることに変わりはないわけです。
そうした意味では「マルチメディアキーボードのホットキー」や、
「オフィスキーオボードのスクロールホイール&戻る・進むボタン」となんら重みは代わりません。
ところが、現在のPCはユーザの意識面でも、アーキテクチャ的にも 「テンキー」はキーボードの拡張部分じゃありません。 ん〜、、歴史的にしょうがないとは思うのですが、 やっぱりちょっとナンセンス。
例えば普通のテンキーユーザの不満としては、テンキー部に「=」キーが無い、ってことが あると思います。 結構メジャーな弱点なので、もちろん市場には「=」付きテンキーってのが出回っているのですが、 現在のキーボード事情だと109キーボードをエミュレートする必要があるので、 キーボードは「=」というキーではなくって、「Shift + [-]」というキーコードを返します。
ローマ字入力の人や、英数モードだとこれでもOKなのですが、 かな入力の人の場合、 テンキーのメリットとして「英数モード切替しなくても数字と記号を入力できる」というのがあるのに、 「=」付きテンキーでは「=」キーだけその恩恵を受けられないのです。
キーボードは標準入力だったので、 どうしても「文字入力」+ 「オペレーション」という役割を担います。 この二つの役割が曖昧で、カプセル化されていないのには メリット・デメリットがあるのですが、 せめて「拡張キーボード」という周辺機器をサポートする仕組みがあってもいいんじゃないかしら。
・・・と、話が大きくズレました。 要するにテンキーが特別扱いされているのは不当である、と猫は訴えたいわけです。
キーボードの配列を見ていると、 無計画に拡張してニッチもサッチもいかなくなった スパゲティ プログラムのようで、どうも歯がゆいです。
と、いうわけで、テンキーレスが「普通のキーボード」と呼ばれる日が こないものかしら、と思ったりする猫でした。
なぁんか、最近かったるくってやる気が出ないのよね、 と思っていたら、風邪でした。 お仕事で「一年分のお仕事が水泡に帰す」っていうかなりへこむコトがあったから 心の問題かなぁ、とおもっていたのですが、 うんうん、体でしたか。緊張の糸がぷっつんと切れてしまっていたので 病気にも掛かりやすいというモノ。
キーボードサイトとしてそこそこの認知度が出てきた三猫OnLineですが、 あんまり意識しすぎると良くないというか。 こうなると目標がたかくなりすぎて「やりたいこと」のスタックばっかりたまって、 掃けなくなってきます。
つまり出遅れてしまうことが多いわけでして。 なにがいいたいかというと、最近キーボードがらみで「先を越された〜っくやしい！」 ってことが連発しています。
きーっ！
これはくやしかったです。ええ、とっても！
猫もRealforce89の初回生産分を入手していたのですが、
そのレビューを作っていた11月1日(というかもう11月2日になっていたような・・)、何気なくQwerters Clinicさんを見ると、
鍵盤バカ一台さんちでRealforce 89のレビューが
リリースアップされているとのこと。
ふみふみ、とちょっと見てみると・・・、ガ〜ン。
あ、あたしの書こうと思っていたことが全部書いてあるっ!!
その日、三猫はブラウザの前で思わずキーボードを落としたという・・・、 などとデギン・ザビ級の脱力感におそわれてしまったのでした。
「簡単分解筐体なんだよ〜」とか、「おおっラベルが新しいです」とか 「けっこうギリギリまで作ってたのね」とか、うう、全部書いてある〜(TT)
そして何より猫を打ち拉がせたのは、「押下特注」です。
Realforce 89パッケージのスペック表には「押下特性」を「押下特注」としてしまった 誤字があります。かなりおっきい時で堂々と書いてあるのが笑いを誘うのですが、 猫はこの実に猫好みのネタに全然気づかなかったのです。
・・・・ま、負けたわ、完膚無きまでに・・・。
なんかもう、「猫は、あの人に勝ちたい・・・。」なんて気力も起きてきません。へみぃ・・、くやしい(TT)
Realforce 89 では、誰かがレビューするよね、と思っていただけにある意味暗黙の覚悟がありました。 でも、でもっ。こっちは違います。
ぷらっとホームと富士通高見沢コンポーネントの共同開発、 合体分離型ナチュラルキーボード FKB8530-T701。 なんだか全然売れていないのですが、そのパームリフトを外せば コンパクトなアジャスタブルキーボードに早変わりというギミックと、 富士通高見沢の実用打鍵の合わせ技は結構注目だわ、と猫はつねづね思っていました。
でも、こんな超マイナー機を取り上げるキーボードサイトさんは居ないわよね。とたかをくくっていたわけでして、 というわけで、いずれはキーボード個別面談で取り上げるつもりだったのですが、 来年の正月休みか、春休みくらいかなぁ・・と夏休みの宿題のような予定を立てていたわけです。
が、やられてしまいました。
みみラボ!さんの魅惑の鍵盤で きっちりレビューされてしまいました。
この機種の場合、紹介することそのものに意義があるのですので、
すでに出鼻を挫かれたわけです。
しかも、みみラボ!さんのハイセンスな文章とくれば、
勝ち目どころか挑戦権もなさそうです。(TT)
うう、思っているだけじゃNGなのよね・・。
猫は「知られざる名器!?」「こいつは結構掘り出し物よっ!」と思っていただけにショックも大きかったです。
く、くやしい。
というわけで、なんだか知らないけどいろいろ負け組になっている猫は 財布の中身まで負け組で、 10月はFILCO のFKB91JUやRealforce 89など大物キーボードを購入した為、 ほとんど借金財政に近い状態。ああ、赤字国債発行しなくっちゃっ。
そんなこんなで、 Shop Uで、 掘り出し物のCherry ErgoPlus MX 5000が出てきたときも 給料日までは購入しないで見送らざる得ない状況でした。
もちろん、長いこと在庫が持たないのもわかっていたんです。 でも1万5800円ですよ!? 一晩で在庫がなくなっちゃうなんて・・・。
「なんで1万オーバーのキーボードをみんなそんなにサクサク購入できるのよ!?」 と自分のことは棚に上げて小一時間くらい問いつめたい衝動にかられる猫ですが、 冷静に考えれば借金してでも買うべきだったかもしれません。(冷静なの!?というつっこみは却下です。)
現在再入荷は絶望的とのこと。し、しまったっ!
うう、Cherry MXスイッチでテンキーレスでアジャスタブルなんて、 そんな猫のツボをねらい打ちしなくても・・・。
きーっ、く、くやしいです!
ね、ねむぅ・・・・。おっと、失礼しました。
ごきげんよう、お姉さま。
と、いうわけで先日発売になった マリア様がみてる 最新刊 レディ、GO!を
堪能するついでに、週末シリーズを3周ほど読みまくってしまった三猫です。
やっぱマリみてはいいわぁ。
こうしてシリーズを読んでみると、 レイニーブルー以降、祐美ちゃん、格段にタフになったわとしみじみ思います。
祥子様との絆が深まった祐美ちゃんは、 祥子様に振り回されていた頃がウソのよう（というか、最近逆に振り回してるよね）で、 うん、なんだか2年生って感じ。 それでいてしっかり「祐美ちゃん」なのだから、とても上手く成長を描いていると思うのです。 さすがです。
その祐美ちゃんは、独特の魅力から可南子ちゃん、瞳子ちゃんを撃墜しまくっているわけですが、
（本人が気付いていない辺りがまた・・・）
さて、今後の展開はどうなることやら。
うう、あんまり眠いのでなんだか文章がまとまりません。 やっぱり変わりつづけるのが人間なのですが、きちんと成長するように物語を書くのは 難しいとおもうのです。 レイニーブルーの事件、そしてその後の祐美ちゃんの姿は、きっと作者の予定通りなのだけれど、 猫はあのとき、祥子様と祐美ちゃんが「ゴール」してしまったので、 「ああ、もうこんなに面白い騒動はないわね」と思ってしまいました。
だって、もう二人の絆を揺るがすことは何人たりとも出来ないから。 「子羊たちの休暇」「真夏の一ページ」で、そこらをマジマジと見せ付けられると、 今後は祐美ちゃんと祥子様の余生が綴られるだけなのかしら、と思っていたのですが、 ドッコイ、「涼風さつさつ」と今回の「レディ、GO!」は また新しい波乱、物語のプロローグを感じさせる素晴らしい仕上がり。いやが追うにも期待が高まります。
猫は祥子様が卒業するまでがマリみての寿命だと思っていたのですが、 「涼風さつさつ」「レディ、GO!」を読んで 今は祐美ちゃんが卒業するまでは絶対読みたいと思うようになりました。 (これは凄いことですっ!)
世界は二人だけで出来ているわけじゃい、とのセリフは作者さんの信念かしら。 上手く言葉に出来ないのだけど、猫はマリみての面白さの源泉をようやく見れたような、そんな感じがします。
| SEO | [PR] おまとめローン 花 冷え性対策 坂本龍馬 | 動画掲示板 レンタルサーバー SEO | |
