無確定のすすめ

小指というのは薬指の第一関節くらいまでの長さがあるのが通常らしいです。私の場合、第一関節までは数mm足りません。道理でリコーダの穴を塞ぐのが難しい訳です。もっとも数mm長くてもo1ao3dを押さえる難しいので全体的に手が小さいのではないかという気もします。

小寺さんは横に長いReturnキーだと小指が短くても楽に届くということを書いていらっしゃいますが、これは横に長いから押しやすいということではありません。US配列なのでキー一つ分Returnキーが近いのです。「横に長いから届きやすい」と誤解されやすい文章に思えました。具体的にはJISキーボードで言う「む」のキーが無いためにReturnがキー一つ分近くなります。

さて、Returnキーは変換結果の確定のために多用するという話なのですがそれほど多用するのでしょうか。むしろ無確定というのはどうでしょうか。

今時の連文節変換IMEであればcannaで(setq renbun-continue nil)とした時のような動作(ってどんな?)ができるはずなので、変換操作中や候補一覧が表示されている時にわざわざ確定しなくてもそのまま入力を続けることができます。たまに、かな漢字変換の癖などによる誤変換を避けるためにひらがなで確定しておきたい、というような場合には(そして割とこのケースが多い)確定操作が必要になりますが毎回確定する必要はありません。と、ここまで書いて思いましたが、このくらいは普通におこなっているでしょう。

こうして確定操作を減らしたとしても「ここで改行」と思ったときには残念ながらReturnで確定して、もう一度押して改行というのがちょっと煩わしいところ。つまり、Returnキーが確定操作と改行の2つの役割を持っているのが不便の原因です。

後は仮名入力の宿命か、日本語とASCIIの切替えをするときには一度確定してからIMEをOFFにというのが面倒。(確定 IME/OFF)という一連の流れができれば便利です。これも変換キーが変換/次候補とIMEのON/OFFという2つの役割を持っているためです。

しかし、ローマ字入力であればそのままアルファベットや数字も入力できますから。IMEのON/OFFを繰り返す必然性はありません。改行に伴う確定も、Returnキーの定義を「確定した上で改行」というように設定すると解決します。つまり、確定する必要は無いのです。

というわけで私が確定操作をする理由も判ってきたのでこれを排除することを考えます。要は

  • 改行する際にReturnキーの挙動が確定になっているため、確定してしまう。
  • IMEをOFFにしたくても変換キーの挙動が変換になっているためモードを切替えために確定する必要がある。
  • Returnキーは確定した上で改行
  • 親指確定を採り入れて、無変換を確定+IME OFFに。

しかしJapanist 2002ではIME OFFというコマンドが無く、常にON/OFFのトグルしかできません。しかも確定とON/FFを同時に割り当てると先にIMEのON/OFFが発動してしまい変換候補が消失してしまいます。変換キーはIMEのON/OFF専用にしてスペースで次候補、無変換は確定とするのが限界の模様。確定してIME OFFというのが欲しいところです。

とりあえずemacsでは希望の動作をさせられるように設定できました。Returnで確定しないというのはなかなか新鮮というか意外と確定だけを行いたいということもあるので難しい所。「Returnで確定しない」という入力だと

  • 「Return」と入力
  • 「でかくてい」と入力して変換
  • 「で確定」と変換される可能性が低い

というわけで「で」の直後で確定したくなることが。無変換キーはIMEのOFFだけにしたほうが無難かもしれません。こうなると快適な日本語入力のためにはますますキーが必要ということでHHKではキーが圧倒的に足りなくなります。つい先日には「必要なのは漢字キーであって変換キーや無変換キーは不要」と書いたばかりですが。

| | Comments (53) | TrackBack (0)

プログラマの生産性

ある問題があるとして、その問題解決の手順というのはいくつもあります。駅まで行く、という単純な問題でも徒歩で、自転車で、車で、泳いで、飛んで、といくつも選択肢があります。車を選択するにしても自分で運転するのか他人に頼むのか、自分の車を使うのか誰かの車を使うのか。このように選択肢は爆発する傾向にあります。

まっとうなプログラマであれば、駅までの距離に応じて適当な移動手段を選択するでしょう。しかし、「徒歩」しか移動手段を知らないプログラマであればフロリダまでも歩くことしか思い付かないのです。単純に知識の差だけで効率が変わってきます。

今時のプログラミングというのは、何かをいれたらそれに応じて何かを出すという入力と出力を決めていくということです。ボタンを押したら、それに応じて印刷する、とか。

自動販売機はお金をいれたら商品が出てきます。お金、硬貨だけでも1円硬貨,5円硬貨,10円硬貨,50円硬貨,100円硬貨,500円硬貨と6種類の種類があります。500円硬貨に至っては旧いのと新しいのと二種類ありますから7種類ともいえます。これらの複数の硬貨が投入されたときにどのように数えるか。まっとうなプログラマであれば、硬貨の価値を数値化、モデル化して100円硬貨であれば+100、500円硬貨であれば+500と点数を付けて行くでしょう。ある意味スゴイプログラマは100円硬貨が1つの時は100円、100円硬貨が2つの時は200円、というように組合せのパターンを考えようとするかも知れません。もちろん、こんなことをしていたのでは組合せを考えるだけで日が暮れてしまいます。同時に硬貨は10枚までしか受け付けない、といった制限でも付けば組合せは限定できます。しかし、今度はその組合せと金額が正しいかということを確認しなければなりません。組合せを作るのも大変なら確認するのも大変です。

組合せというのは大きな問題です。ゲームのコマンド入力等で「たたかう」「どうぐ」「じゅもん」「にげる」といった4つの選択肢があるとします。一人パーティのゲームであれば組合せは4通りです。2人であれば「たたかう」+「たたかう」、「たたかう」+「じゅもん」といったように組合せが増えて4×4の16通り、4人なら4×4×4×4で256通りになります。こうした爆発する組合せについて、それぞれ正しく動作することを確認して行くことは大変手間がかかります。

まっとうなプログラマであれば、パーティ一人一人の行動を他のパーティとは影響が無いように注意して作ります。こうすることで、4×4×4×4×…といった組合せではなくて4+4+4+4+…といった項目に抑え込んで手間が増えないようにします。もっと良いプログラマであれば、人数に関係なく4通りのコマンドをテストするだけで問題ないように作るでしょう。

確認項目が4つで済むプログラマと16通りで済むプログラマ、256通り確認しなければいけないプログラマ、では作業効率に大きな差ができます。しかもこれはパーティが増えればもっと差が大きくなるのです。100人パーティとか考えたくなります。

できないプログラマというのは問題をどんどん大きく育ててしまうので、結果的に作業効率に差ができてしまいます。

もちろん、最初に選択されても2番目に選択されても最後に選択されても問題なく動作する「たたかう」コマンドや、いつ、誰が選択しても動作する「たたかう」コマンドというのは、256通り確認しなければ行けない「たたかう」コマンドに比べれば作るのが難しいはずです。でも、それができるかどうかが大きな分かれ目になります。

厄介なのは、できる人とできない人の判断です。例えば256通りの確認が必要なコマンドを作るのは、確認が4つで済むコマンドよりも簡単なので、この人はどんどんコマンドを作って行くことでしょう。端から見ているとどんどん仕事を進めているように見える。「できる人」に見えてしまうのです。さらに質が悪い口が達者な人ですと「コマンドが4つで4人パーティですから組合せは256通りなんですよ」とか言い出して自分の作業量を正当化します。このために「できない人」をできない人と評価することが難しくなります。

こうして「できない人」は「できる人」がコマンド1つを作り上げる間に10個も20個もコマンドを作り上げるのです。ここだけ見ると「できる人」が1つ作る間に20個作るわけですから「できない人」は20倍の作業速度に見えてしまいます。しかし、「できる人」がコマンドを4つ、つまり全部作ったときには「できない人」は100個くらい、まだ半分も出来上がっていないことになります。

「できるプログラマ」「できないプログラマ」だけではなくて「できるように見えて実はできないプログラマ」という人もいるので見極めは大変難しいです。しかし、こうした作業の組み立て方、進め方の違いで作業効率というのは大きく違ってきます。

どんなに作業スピードが速くても、作業スピードよりも速い速度で問題を大きく育ててしまう人は結果的に能率は劣ることになります。こうした積み重ねが10倍、100倍といった差になります。

| | Comments (55) | TrackBack (0)

RedHatコピーの価格とRedHatの価格

RedHatの複製品について記事になっているが、OSとしてRedHatなどのLinuxが選択されているのはここに尽きるのかもしれない。

ただし、Linuxベンダーが設定できる価格には上限があるとの見方もある。「われわれがLinuxを選んだ本当の理由は、価格面の優位さだ」というのは、Eastek International(ニューヨーク州バッファロー)のBrian Trudeauで、同氏はCentOSのユーザーだ。「Windowsと同じくらいコストがかかるのであれば、Red Hat(のLinux)を選ぶ理由もない」(Trudeau)

つまり、価格が同じならWindowsを選択する。セキュリティ上Linuxが有利かどうか、というのはそれほど大きな問題ではないということだ。

ところで、RedHat Enterprise LinuxのソースはRedHat Networkのライセンスが無いとダウンロードすらできなかったと思ったけど、それを再配布してしまって良いのだろうか。というか、GPL準拠のソースだと思うのだけど、なぜ公開されていないのかが判らない。

| | Comments (15) | TrackBack (2)

添付ファイル?

OSIのトップに就任したNelsonは、この(OSIが認可するオープンソースライセンスの必要条件の)定義に3つの要件を追加することを提案した。

  • ライセンスは既存のものと重複してはならない
  • 明確に書かれた簡素で理解できるものでなくてはならない
  • 特定の個人やプロジェクトあるいは組織を付随する添付ファイルに移動させることで再利用可能となるものでなくてはならない

という3項目を満たすことが新たに求められると述べた。

添付ファイルってなんだよ。

ということで原文をあたってみた。

Nelson said the new proposed provisions would require :

  • that a license not duplicate existing licenses;
  • that it be clearly written, simple and understandable;
  • and that it be reusable by moving the names of specific individuals, projects or organizations into an accompanying attachment.

どこから添付ファイルなんていう言葉が出てきたのか問いたい。問い詰めたい。

別の呼び名に変更したり、プロジェクトや組織に付属させても再利用可能でなければならない、ということらしい。ライセンスの名称を変えることでオープンソースライセンスとは認められなくなることや、ライセンスの権利者(著作者?)が別の組織に移動する、もしくはライセンスそのものが誰かに買い取られてもそのまま利用できること、という条件を設けたいのだろう。

| | Comments (42) | TrackBack (0)