Re: ココログ利用規約変更のお知らせ
ココログ利用規約変更のお知らせによると、いわゆるSPAMブログを禁止し、削除の場合もあるとのことです。
これで軽くなるのでしょうか。SPAM判定のためにますます重くなるとか。
ローマ字vsかな入力
乗り遅れ……というか忘れていましたが思い出したので今さら。
初心者のキーボード入力は、ひらがな入力からか？ローマ字入力か？より。
けんじろうさんはローマ字入力のほうがすぐれている、と考えていらっしゃるようです。逆に私はかな入力のほうが楽だと思っています。けんじろうさんが考えている「かな入力の劣るところ」について反論してみましょう。
- ローマ字用の１９字を覚えれば良い。かな入力は５０音を覚えなくてはならない。
- ローマ字入力でもそもそも50音とローマ字への対応覚えなければ成りません。さらに("でぃ" . "dhi")だとか("ゃ" . "xya") ("ゃ" . "lya")といった特殊な形を覚える必要があります。
- 実際には日本語と英語交じりの入力が必要だが、その場合でも、２６個のキーを覚えれば良い。かな入力は５０音＋英字の７６字とローマ字の３倍。
- ここはそのとおりです。しかし、小学生の間だけでも1,000文字以上の漢字を覚えるのです。キー50個程度追加しても5%でしかありません。最初にたった50個キーを覚えるだけでキー入力の数を2割減らせると思えば安すぎる投資です。50個覚えるのがイヤなら38個(英字、数字と,と.)も覚えないで手書きにするべきです。でも、さすがにそれは遅いでしょう?
- 指の移動量が少ないので打つのが楽。
- ローマ字入力だと数字は打たないのでしょうか?
- ブラインドタッチに不可欠な、ホームポジション（人差し指をＪとＦに置いて横一列に他の指を置く）から上下に一つ移動させる範囲内なのでホームポジションに戻りやすい。
- ローマ字入力だと数字は打たないのでしょうか?
- かな入力では最上段の文字が打ちにくい。
- ローマ字入力だと数字は打たないのでしょうか?
- かな入力では、右手小指が酷使される。
- そんなことはありません。統計まではとっていませんが、「ろ」「む」「ほ」は意外に登場頻度が低いです。HHK(USキーボード)ではキーが足りないので「ろ」「む」「ほ」は別のところに飛ばしているのですが、意外と何とかなります。出てきた途端にしばらく悩みますが、これは慣れの問題。さらに言うと、私は小指が若干短いせいか「ほ」「へ」「ー」あたりは右手薬指で押しています。
- 実際の入力数は「推進」＝すいしん：ＳＵＩＳＩＮ、「情報」＝じょうほう：ＪＯＵＨＯＵ。
- 母音はローマ字入力でも1キーで入力できるのでかな入力と変わりません。それでも推進で1.5倍ですね。「じょ」に限ればローマ字のほうが簡単でいいのですが、これだけでは日本語にならないので特例でしょう。どちらにせよキー入力が2倍というのは行きすぎにしても、キー入力が増えるということには変わりがありません。
- 入力文字数が多いという意見があるが、実際には”ま”ならＭとＡをほぼ同時に入力しているので、「かな」より遅くはならない。
- キー入力の話をしているのか、速度の話をしているのか解らなくなってきましたが、「き」だとKとIを同時に押すのは難しいです。ごく一部の楽なキー入力だけを取り上げて「たいしたデメリットでは無い」というのは公平な態度とは言えません。
- 英字、かな、数字の切り替えが楽なので、混合文書（これが多い）の入力が速い。 かなでは、英かなの切り替えや濁点や数字などでの「シフトキー」の利用が多く、結果として「かな」は遅くなる。
- 英字、かな、数字を入力するときにはIMEをOFFにしてしまうので問題ありません。切り替えはIME ON/OFFを適当なキーに割り当てておけば1キーで出来るので楽です。私は変換キーをON/OFFに割り当てています。また、濁点はシフトキーは使いません。シフトキーを使うのは「ゃ」「ゅ」「ょ」「っ」「、」「。」「・」くらいでしょうか。
最初に100万投資して100万/月のリターンがあるローマ字入力と、最初は300万必要だけど150万/月のリターンがあるかな入力。3倍の初期投資でリターンが1.5倍と考えるとあまりいい投資とは思えないのは確かですが、だからといってキー入力から撤退するというわけにもいきません。コストを下げるために必要な投資と考えてはいかがでしょうか。
もちろん、「今から3日だけ日本語を入力する」という短期間の人に対してはローマ字入力で問題ありません。
Re: 中国の不幸を喜ぶ人々へ
中国の不幸を喜ぶ人々へから。
中国は人権の無い国ではありません。冷たい国でもありません。チベット人を尊重しないと思う人たちは、自分の目で見たのでしょうか。そういうことは自分で確かめてから言ってください。
いや、だってチベット自治区は見せてくれませんし、入れてくれません。入れても決められたルート、エリアだけだそうです。
普段はなにかと人命尊重意識が低いとか批判されがちな中国。しかし、今回の素早い救援活動は人命尊重の表れではないでしょうか。今回中国の対応姿勢をご覧いただいて、中国も少しは進歩したと思いませんか。
毎日新聞の記事を見るかぎり、まだ助かる見込みがあるのにたった72時間で早々に諦めてしまっているようです。諦めることが素早くても困ります。
日本人は知っています。非常事態になれば国は平気でうそをつく、大事なことは隠す、ということを太平洋戦争の大本営発表を通して知っています。なので、このような非常事態で中国が発表することは直には信じられないのです。
ずるい? PSE法
地方税滞納による差し押え物品の購買はPSEマークを付けなくてもよいとする見解があるという話を小寺さんがネタにしています。
曰く、自治体が差し押えても所有権は移転されないとのことです。
つまり、差し押えた時点では所有権は自治体になく、売買取り引きは所有者(=滞納者)と落札者との個人売買であるということなのでしょう。一応筋は通りますし別にずるい話でもないように思えます。
後はこの個人売買が事業者として認定されないのかどうか。もし、事業者として認定されてしまう場合にはどうするのでしょうか。
- 脱税する
- 電気用品安全法に違反する
無確定のすすめ
小指というのは薬指の第一関節くらいまでの長さがあるのが通常らしいです。私の場合、第一関節までは数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ではキーが圧倒的に足りなくなります。つい先日には「必要なのは漢字キーであって変換キーや無変換キーは不要」と書いたばかりですが。
どの口がそれをいうか
テレビ、雑誌、新聞、Web、blog。情報が掲載されているメディアがなんであるか、ということは情報の信頼性の基準とするべきではありません。Webに書いてあるから信頼できない、という人は同じ内容を紙に印刷したら信用してしまうのでしょうか。雑誌記事、新聞記事になっていたら信用してしまうのでしょうか。
雑誌記事、新聞記事になっているということはそれだけコストを掛けているということですからその分信頼できる、と考えることは可能です。逆に、「それだけのコストを掛けないと信頼性が得られない」という見方もできます。掲載メディアがなんであるか、ということと信頼できる情報であるか、ということは別の問題なのです。新聞や雑誌などのメディアであれば掲載、公表に至るまでに編集者のチェックが入るため安心、という主張もあります。この「編集者のチェック」というのは一般には誤った情報を取り除くためのフィルタと考えられます。目的はともかく、装置としてはただのフィルタです。情報の伝達経路にフィルタがあるから安心、というわけです。これも逆に考えるとフィルタがあるから安心できない、と考えることができます。本来受け取りたい情報であるにもかかわらずのフィルタが取り除いてしまうかもしれません。また、発信したい情報がフィルタによって取り除かれるかもしれません。フィルタを通すということは、生の信号では無くて加工済み、検閲済みの信号を得るということです。フィルタを通すということはフィルタによって変質させるということです。フィルタが信頼できない場合にはフィルタがあるから安心とは考えられません。
では、どういうところから得られた情報なら信頼できるのか。信頼できる「人」からの情報が信頼できるのです。伝達に用いられたメディアは関係ありません。社長がメールで「緊急・シークレット扱いで口座に入金するように」と指示するのと、内容証明郵便で、口頭で、手書きメモで、狼煙で、モールス信号で指示をするのとで信じたり信じなかったりするというのはおかしいです。
では、どういう人からの情報なら信頼に足るのか。これはなかなか難しい判断が必要で、お湯を掛けて3分というような訳にはいきません。信頼する、というは簡単です。自分で何も考えず言われたものを受け入れればよいのです。しかし、このような情報を鵜呑みにするという行為はリスクがありますし、そのような頭を使わない人に信頼されてもうれしくは無いでしょう。そのような考えの無い信頼には価値がありません。検証可能な情報を提供している、というのが一つのポイントになります。ある人が「1+1は2だ」と主張していたとして、その主張を信じるかどうか。この場合「1+1」という所まで開示していますからこちらで検証することができます。理屈の上では検証可能である、ということが重要で実際に検証できる能力があるかどうかは別問題です。「1+1くらいならともかく、耐震強度の検証だと実際に地震を起こして建物を壊さないと検証できなくなります。さて、これが「この問題の答えは2だ」という主張だと問題自体が提示されていないので検証することができません。何か隠しているということになるのでうかつに信頼する訳にはいきません。「100人のっても大丈夫」という主張は、実際に試すことができます。検証可能ですから信憑性は高いと考えられます。さらに深く考えると、嘘をつくメリット、嘘がばれたときのコストなどを考えたうえで真実である可能性を考える訳です。
「新聞記事ならともかく、Webに書いてあるようなたわごとを真に受けるなよ」という考え方があることは理解できます。新聞記事であればフィルタによって誤りが除去されているだろう、と判断することはそれほど不自然ではありません。しかし、書かれている内容の信頼性は書かれているメディアではなくて書いた「人」に強く依存していると私は考えます。
たとえば私の場合、仕事を進めてきた中で他の方が書いたプログラムに対して「このプログラムは間違っている」「これでは意図したようには動かない」と誤りを指摘することがあります。最初のうちは「どこが間違っているのか」と言われました。私からの情報だけでは信頼性が欠如していたためです。その度にシーケンスチャートなどの資料を作成し納得していただけるような解説、レビューを行ってきました。こうした活動を2年近く続けてきたいか、今では「このプログラムは間違っている」と言うとすぐに「どこが間違っているのか」と訊かれるようになりました。……ってこれでは何も変わっていないように見えますが。最初の頃に言われていた「どこが間違っているのか」と今言われる「どこが間違っているのか」では大きく意味が異なっています。
2年ほど継続していることにより、ある種の信頼が生まれていると考えられ、当初は上司経由で連絡していたものでも直接通知しても問題なく期待したような対応が取られますし、もちろんメールでも電話でも口頭といった伝達手段、メディアの違いによって信頼されずに対応が変わるということありません。
小寺さんのツールとインフラという文章を読んで「メディア」とは単にインフラだけを指すという発想をする人間がすでに現れている
という記述にちょっと違和感を覚え、瀬在丸紅子のセリフを思い出したのでした。
どのようなフィルタを経由するか、どのような伝達経路で到達するか、ということは関係なく発信者が誰か。これが重要なのだと思います。
リッチなフォーム
WebフォームをFlashで作りリッチにしようと提案する記事がありました。
お試しくださいというので試してみました。
はっきり言って使えません。サンプルだから、というのもあるでしょうが、サンプルだからこそ作り込みが必要ではないでしょうか。
一見すると通常のフォームと同じですが
というのが混乱に拍車をかけます。
- Tabキーで名前の入力欄にフォーカスが移動しない
- Enterキーでsubmitできない
- 日付入力欄でAlt+カーソルキーでプルダウンできない
なまじ一見すると通常のフォームと同じ
なので挙動の違いが使いやすさに直結しています。Enterを押してもなにも反応が無かったので、このサンプルは動作しないのだと思いました。
また、Flashを使うのでしたらデータのチェックはActionScriptで行うこともできるでしょう。わざわざサーバに問い合わせると言うのではFlashを使うメリットが少ないです。滑らかにアニメーションする点滅ラベルも、背景画像にアニメーションGIFでも貼れば済む話です。
※流行のAjaxを用いても可能ですが、RIAでの構築は他にも恩恵があります。
と注釈していますが、この程度ならJavaScriptで入力チェックを行い、DOMを操作して背景画像を差し替えれば可能です。バックグラウンドでサーバと通信する必要もありませんから流行のAJAXとは言えません。
ページ遷移が問題なのであれば、クライアントサイドのJavaScriptで大部分のエラーをチェックしてやればページ遷移が起きる前に確認できます。それでもダメならサーバ側でチェックするしかありません。この時のエラーページを、単にクッキーを反映しただけのページではなくてサーバ側で動的に生成してやれば細かな画面も作れます。
ブラウザのコントロールと同じ動作をするものをわざわざFlashで再現し直すというのも無駄と言いますか不毛な作業です。ブラウザのコントロールと同じ使い勝手でしか無いのであればそのまま使った方がマシでしょう。よほど使い勝手の良いフォームを作るのでなければわざわざFlashで作り直す程のものではありません。Flashが動かないブラウザもあるかも知れませんし。
この記事からではリッチなフォームによる恩恵というのは解りませんでした。次に期待。
プログラマの生産性
ある問題があるとして、その問題解決の手順というのはいくつもあります。駅まで行く、という単純な問題でも徒歩で、自転車で、車で、泳いで、飛んで、といくつも選択肢があります。車を選択するにしても自分で運転するのか他人に頼むのか、自分の車を使うのか誰かの車を使うのか。このように選択肢は爆発する傾向にあります。
まっとうなプログラマであれば、駅までの距離に応じて適当な移動手段を選択するでしょう。しかし、「徒歩」しか移動手段を知らないプログラマであればフロリダまでも歩くことしか思い付かないのです。単純に知識の差だけで効率が変わってきます。
今時のプログラミングというのは、何かをいれたらそれに応じて何かを出すという入力と出力を決めていくということです。ボタンを押したら、それに応じて印刷する、とか。
自動販売機はお金をいれたら商品が出てきます。お金、硬貨だけでも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倍といった差になります。
