« June 2005 | Main | August 2005 »

Sunday, July 31, 2005

Roller Mouse Pro

RollerMouse Pro が届いて,数日使ってみた.

結局,最初に注文したところは問い合わせても返事が無く,
http://www.kinesis-ergo.com/roller_mouse.htm
で購入.
送料込みで $250 くらいでした.

ちなみに,ぷらっとほーむでも言えばあつかってくれるようです.
ただし,ロットで仕入れるわけでは無いため,かなり高めになってしまうようです.
(あまり変わらないならぷらっとで買おうと思ったけど,かなり差があったので個人輸入に)


クリックは,ボタン5つ+クリック可能なホイールになっていて,3パターンの設定から選べます.
ただし,自由なカスタマイズは出来ない模様.
わたしは,黒い横長のバーを戻る・進む,3つのボタンを左・真ん中・右クリック,ホイールクリックも真ん中クリックで使っています.
他のモードは...あまり使いやすそうには思えなかったり.(^^;
カスタマイズが出来ればもっと使いやすい設定ができそうなのが残念.

マウスの移動は,ローラーバーで行うわけですが,このバーは左右にスライドします.
それで左右の移動をするわけですが,長さの制限があるので,結構すぐ端までいってしまいます.
端までいった場合,さらに力を加えると,その方向に一定速度でマウスカーソルが移動するようになっていて,一応端まで言ってもさらに左右移動ができるようになっています.
端での移動は一定速度なので,なかなか思ったようには動かず,少し先まで行き過ぎてから戻ってくる感じになります.

慣れれば普通に移動できる感じです.


特に使いやすいーという気はしないですが,普通に使えています.
スペース的には奥行きがちょっとありますが,マウスの移動スペースは不要になったので,これはメリットです.
マウスを机から落とすことも無くなりますし(^^;

手の移動量は,KINESIS キーボードがかなり背が高く,マウスの時とあまりわからない状態に(^^;
普通のキーボードなら,スペースバー近くになるのでかなり楽になるとは思うのですが...
キーボード乗せてから,KINESISの高さに気づきました.

ローラー部分をもう少し高くできれば,良い感じなのですが...
KINESISキーボード自体に内蔵してくれれば・・・という感じです.

| | Comments (2) | TrackBack (0)

Windowsプログラミングの勉強

やはり基礎は押さえておくべき,ということで,

・猫でもわかるWindowsプログラミング第2版
・スタンダード Visual C++
・Visual C++ .NET ではじめる Win32 API システムプログラミング

を購入して読んでみた.
MFCとか,今回全然関係ないところは読み飛ばしてしまったけど.

Win32 API システムプログラミングは期待していたほど内容が濃くなくて残念.
もう少しスレッド周りとか詳しい情報を期待したのだけど...

pthreads からの移行方法のドキュメントとかあればいいのに...
MSDNのドキュメントにもマイグレーションの部分があったけど,cond_signal とかの代わりをどうするのが良いのかいまいちわからない内容.

例えば一定長のキューを実装する際に,キューがいっぱいで空きを待つ場合,
・空きを待つ方は WaitForSingleObject を使って待つ.シグナルが来たら mutex/criticalsection で保護してキューの空きがあるかチェックして,空きがあれば処理する.
・キューを消費する方は,キューに空きが出来たら空きを待つイベントをシグナル状態にする.
がベストの解なのかな?

空きを待っているスレッドのうち1つだけを起こすことは出来ないのだろうか...
(多数のスレッドを起こしても,処理できるのは1つだけなので,この方式は無駄があるはず)


システムトレイへの入れ方,画像の表示方法,WM_COPYDATA などのやり方の概要あたりが収穫かな.
次はオライリー系のような細かい説明までされている書籍が読みたいところ.
何かおすすめないですかね?

| | Comments (0) | TrackBack (0)

評価結果の見方

下駄配列を解析、その2へのコメントです.

でも、ローマ字打ちの人って、「ん」はこの定義ファイル通りに打ってますか?

わたしの場合は定義ファイル通りです.
一番短い打鍵になるようにしているので,「し」とかも shi ではなく si ですね.

人によってはこの辺が違うので,この定義ファイルでの結果は最小の場合と考えた方が良さそうです...


移動数について。移動数というのは、『姫踊子草』設定ファイル上でひとまとまりに定義されているものを1単位と数えて何単位になるかという数、だと思う。

はい,その通りです.

 QWERTYローマ字がやたらと少ないけど、これは、例えば「んは」が[NHA]でひとまとまりで定義されているため。よって、この数字にあまり意味はない(他のストローク系も同じ)。

単体ではあまり意味がないのですが,キータイプ数÷移動数,で,1回の動きのキー数が出せます.
この数が大きいほど,定義が複雑である可能性が高く,覚えにくい傾向にあると言えると思います.
(移動の種類数などを出せばもっと正確に覚えやすさが出せるとは思いますが...)

 同時押しを1打鍵と数えた時の打鍵数は、ストローク系はキータイプ数と同じ、同時打鍵系は移動数と同じになるはずです(同時押しを2打鍵と数えた時の打鍵数はすべてキータイプ数)。

これもその通りです.
同時打鍵系では,キータイプ数÷移動数で同時押しがどのくらいあるかの判断が出来ますね.
同時打鍵系ではあまり気にしないのかもしれないですが...
(同時押しがあってもなくてもあまり打ちやすさは変わらないという認識が多そうですので)

でもそれが悪いわけではないです。中指シフトの[K]→[D]→[I]は左右交互、下駄配列の[KD]→[I]は同手連打(しかも同指違鍵)、でもこの二つがそんなに違うの?と思うのです。

こういった場合,十分に配列をマスターしてれば,右手,左手それぞれの動きが速度の制限になると思います.
なので,上記の場合,同時打鍵系で同時押しと認識させるためのマージン時間を考慮しなければ同一と言えると思います.
(マージンというのは,同時に両方押して,それから離すために,同時に押しているという時間が多少必要と思いますので)

ローマ字で [N][N][I] と [N][A][N][I] のどちらが速く打てるか,ということを考えると,十分速い人ならほとんど変わらないのではと思います.
これも,同一連打や同手連打が素早い人なら事情が変わってくるとは思いますが...

わたしの場合はほぼ同じで,同一連打は特に速度が出ません.
そのため,JLOD配列は左右交互にかなりこだわったものになっています.
(省略入力は右手連打が多いですが,入力できる文字数が多いので問題ないという考え)


タイプ時間を想定でだしてみる機能を追加すると良いのかなあ.
人によるので難しいとは思いますが,左右それぞれで見て,
同手跳躍(2段)>同指異鍵>同一連打>同手連打
という傾向は見られそうです.

| | Comments (0) | TrackBack (0)

Thursday, July 28, 2005

音声入力

明日は~~どぉっちだぁ~~♪ (再び音声入力を考える)へのコメント

>途中から音声入力と音声会話がごっちゃになっていないだろうか?    いや、何十回も推敲しているのですから「わざとごっちゃにしている」んです!    つまり、発声という作業が気心の知れた相手とするか、仕事など必要上どうしても  会話しなくてはならない状況以外では、やる気にならないほど面倒だと言うことです。 

わたしはそうは感じていないので,人によって違うのでしょうね.
機械に対して発声するのが面倒というのが理解できません.

発声することのどこに面倒くささを感じるのかが違うのかもしれませんね.
わたしは対人が面倒と感じる方なので...

もしみんなが発声自体が面倒と思っているならば,カラオケなんて流行らないはずです.
音楽を聴いて,思わず歌詞を口ずさむ行為などもありますが,このような行為も説明がつかなくなります.

少なくとも,発声に対して,そこまで面倒と思う人はそう多くないのではと考えます.


だって、打鍵なんてチンパンジーでも言葉が分かれば、大きめのキーボードを 
与えればできそうなくらい粗雑な作業で、人間が数十万年とか前から持っていた 
能力できっと十分なんです。 

キーが10個程度なら出来るかもしれませんが,1つの指に4~10個のキーを割り当てて,タッチタイプするのは無理でしょう.

キーボードをタッチタイピングすることも,それなりに大変ですよね.
出来ない人が多くいることがそのことを証明しています.

難しいからこそ、赤ちゃんの最初の仕事は「音声母語の獲得」になっていて、  それで人類は繁栄できたのです。  つまり、音声言語の習得を本能にする必要があるほど発声は難しいものなんです。 
 

音声によるコミュニケーションが無ければ生きていけないからでしょう.
本能にしているのは,発声が難しいからではなく,生存に必要だからです.

キーボードが打てなくても生きていけますし,タイピングは生物的な生存とは関係がありません.

実際、留守番電話などは出力も音声ですが、それとは関係なく  不特定の他人に向けて機械相手にやるのですから、十秒の  メッセージでも入れるのは面倒でたまらなかった経験は誰にでも  あるでしょう。 

留守電を聞くのは人間です.
したがって,気を遣いますし,相手のリアクションがすぐ聞けず,時間制限もあるので面倒なのです.
間に機械が入るのは関係ありませんし,出力がテキストの音声入力の否定材料にはなりません.

では、その頃のIMEよりははるかに優れている今売っている音声入力が  普及しない理由は何でしょう? 
 

アプリケーションとして使いやすくないからでしょう.
使ってみればわかりますが,まだまだ完成度が低すぎます.

入力作業は長時間にわたってすることですから,この辺のできの悪さはストレスに直結します.
ドラゴンスピーチとViaVoiceの両方を試しましたが,一番ストレスがたまるのが修正のしにくさです.
ここがもっと使いやすくなれば,今の精度でももう少し普及すると思いますけどね.
(それなりに認知度を高める必要はありますが)

実用で使う気が起きない原因はまずそこにあると思っています.
ここが直って,認識精度も高いのに普及しなければ,発声が問題と言えるのでしょうが...

そのころのIME...というのがよくわかりませんが,ATOK6とか7の時代でも,修正などにストレスを感じることはありませんでした.
なので,今の音声入力はまだまだこれからでしょう....


今のユーザーが,なぜ音声入力を使いたくないと判断したか,その理由はどこでしょう?
一度使ってみればわかると思いますが,入力自体は非常に速くできますよ.
誤認識や,修正のやりにくさが利用されない原因でしょう.

これが快適になったら,いかに便利か...という夢はあると感じます.


同じことを大組織ができないはずがありません。それができないのは、 
五体満足な人で毎日数時間入力するほど言いたいことや書く必要がある 
人で、音声入力に乗り換えようとする人が見つからないからでしょう。 

ブログなんて最近出た媒体ですし,大企業がブログを書かせるというのも変な話です.
できないのではなく,やらないだけでしょう.


つまり、出力が音声であろうとテキストであろうと、「たかが機械」に向かって 
不特定多数に声で語りかけるという高級な「大作業」を孤独に長時間するのは 
人間に可能なのか、既に、キーボード入力という誰でも一応使える手段があるの 
を知っているのにも係わらず、という問いを私は前回投げかけていたのです。 
 

わたしは可能だという考えです.
音声入力なら10分で入力できる内容を,一応使えるキーボードで1時間かけと入力しようと思う人はすくないでしょう.
(十分タッチタイプが出来れば,そこまでの差は出ないとは思いますが)


人以外を相手に文脈の長い文章を何時間も「言う」のは無理なのではないのか? 
いや、人相手でも書いたら長文になるような複雑なことを言おうとする 
と支離滅裂になったりして、何度も言い返したり、面倒だから言うのを 
諦めた経験をした人が結構いるのではないか? 

1つ前の記事は音声入力で書いてます.
音声入力だから一発で入力しなければならないことはありません.
推敲もできますし,何度も入力し直せます.
そのあたりの条件はキーボード入力と変わりません.
(上の文章は,全然推敲しないで書いたものですが…)

推敲など細かいこともしなくてはならないテキスト作りで音声入力は原理的に  可能なのか、人間心理の面から検証する必要があると言っていたのです。 
 

自分では,心理的な負担など全く感じないので,正直なにを検証したいのか見えてこないのです.
これが一般的と主張するわけではないで,実際に使ってみた人の意見をもっと聞きたいですね.

「手を動かして言葉を固定する」ことなら、ギリシャ以来数千年の  「手書き」の歴史が実用性を証明しています。   別に99.9%(それ以上?)キーボード入力されている、ここ数年のネットの文章の  洪水を引き合いに出すまでもなく、「頭で考えて手で文字化して目で確認して推敲する」  という手書きやキーボード入力のプロセスの実用性は十分証明されていると言えます。 
 

昔は音声入力がなかったので,音声入力の歴史は始まったばかりです.
これから実用性が証明されていく分野なので,現時点で証明されてないのは当然です.

キーボード入力が実用的ではないと主張しているわけではないですよ?
キーボード入力も実用的ですが,それなりの練習が必要です.
手書きにしても,小学校あたりからかなりの時間をかけて読み書きを覚えます.

習得時間が短く,それなりに効率よい方法として,音声入力という選択肢が増えようとしているだけです.
音声入力も,声を出すという制約などがあるので,万能ではありません.
両方共存できるものだと思っています.
 

とにかく私は、音声入力は100%正確に入力できても、機械相手に人間は 
長時間喋れるものではないと確信したから飛鳥作りにはまったので、 
無気になって否定しているわけです。 
 

どうして確信したのでしょう?
実際に試して判断されたのでしょうか.
それとも,感覚的なものでしょうか.

わたしは,感覚的に,また実際に試してみて,音声入力は使えると感じて,反論しているわけです.

どちらも感覚的な意見であれば,これ以上議論しても答えは出なさそうですね.
人によっては音声入力は人気がないことはわかりましたが...
 

でも、みかさんも否定論に疑問を呈する以上試してみたらいいと思います。 
つまり、音声認識でなくてもマイクを前に自分のブログに書くことを 
「喋って」最低でも一時間くらいは録音が続けられるかどうか 
PCの録音ソフトでも使って実験されたらどうでしょうか。 

というわけで1時間はしてませんが,少し記事は書いてみました.
その後,ViaVoiceは強制終了して,おかしな状態になっていますが...
(ドラゴンスピーチの方が安定していますね.精度はいまいちですが...)

とくに打った方がいいとかは感じませんでしたが...
まあ,感嘆系の語句は減った感じがしますね.認識されにくいので...
話し言葉に近い入力にはまだ向かないかもしれません.


それで、「慣れたら簡単にできそうだ。100%近く正確に認識してくれるなら音声 
入力に乗り換えよう」と実感できるのなら、私の否定論は否定されるわけです。 
これまでの私を含めた新配列勢力の努力はパーになりますが、日本語 
入力の未来がそちらにあるなら、それもまた意味のあることと思います。 
 

安定入力できるなら,乗り換え...というか,音声入力しやすい環境なら使おうと思いますよ.
話し言葉の認識がもっと出来れば,チャットの入力も,お菓子食べながら出来るのでよさそうですし.

入力方法として制限があるので,音声入力が普及しても,キーボードは当面無くならないでしょうし,配列努力も無駄にはならないと思いますが...
わたしも,配列作って,キー配列変換ソフトまで作ろうとしていますし.


| | Comments (4) | TrackBack (1)

Wednesday, July 27, 2005

ViaVoice & VoiceATOK

毎日ジャストシステムに問い合わせをしたところ、IBMのViaVoiceであればATOKと組み合わせて使用できるという回答を得た。
というわけで、IBMのViaVoiceを買ってみた。

まず、ViaVoiceのみで使ってみたところ、認識精度はドラゴンスピーチと大きな違いはなかった。
若干ViaVoiceの方が、認識精度が高いように感じられる。
しかし、ユーザインターフェースと使い方がドラゴンスピーチとは大きく異なった。

1番よく使う誤認識された単語の修正方法がだいぶことなった。
ViaVoiceの修正インターフェースは使いやすいとは言い難く、専用の音声入力エディターを使っていてもかなり動作が遅く、時々固まったような状態になってしまう。(ただし、精度最優先の設定には変更している)

そのほか、改行するときの音声コマンドなどがかなり違うので、最初はけっこう戸惑ってしまった。

ATOKと連携機能は,漢字変換だけをATOK側で行うことが出来るようだ.
文字入力のタイピングだけを音声入力に置き換えてような感じだ.
句読点を自前で入力すれば,普段使っているカンマとピリオドの入力も行える.
効率がよいのか悪いのか,いまいちわからない.
文字のタイピングだけを考えれば,相当に早く感じるのだが,たまに誤認識してしまうと,大きな手戻りが発生してしまう.
また,このモードでは「てん」とか「まる」を文字として入力できないのが結構致命的.
期待していたほどのメリットがない感じ...


ViaVoiceの方では、ダイレクト入力機能があり、多くのアプリケーションで入力できるのはメリット。
ただ、やっぱり修正がやりづらい。

この辺のインターフェースが改善するだけでも、音声入力ソフトの使い勝手がかなり向上すると思われるだけに残念。
音声入力では、誤認識の修正が入力作業の半分以上になるため、この部分の使い勝手が非常に重要だと思うのだが………
動作が遅いのは、音声を扱ううえで仕方ないことなのかもしれないが、、、
今後に期待というところだろうか・・・

| | Comments (2) | TrackBack (0)

Tuesday, July 26, 2005

Windowsプログラム

ウィンドウの管理とかフックの仕方とかよくわからず,なかなか難航.

今日は会社休んだので,半日くらいフックと格闘してました.
で,キーボードフックして,1キーが押されたら,追加でもうひとつ1キーを入力するサンプルまで.
あとは,キーのスキャンコード調べて,IMEとかの状態取得をやって,SHIFTキーとかの状態見る部分とか作って...かなあ.先は長い.

最初は WH_KEYBOARD でやっていて,DLL 周りでなやんだり.
その後,WH_KEYBOARD_LL に直してみて,ドキュメントを再度見直すと,DLL 化する必要がなかったり.
この部分に早く気づいていたら無駄な時間書けなくて済んだかも(涙
(やり方は同じだと思っていたので,後から変えるつもりだったのに...)

この辺は資料があまりないので苦戦しそう.
菱がソース公開しているので,結構参考にさせてもらってます.

| | Comments (6) | TrackBack (0)

ロック続き

なるちゃんの日記より

あー、確かに。何気なく「ロック」という単語使っちゃいましたが意味が広すぎますか。一応SERIALIZABLEとかの意味は分かったつもりになってますが、その上で「SERIALIZABLE」→「とっても安全にBEGINからENDまで長い時間全体をロックするみたいなもん」、「READ COMMITTED→とりあえずダーティーリード出ないだけの間ロックするみたいなもん」という、凄まじく曖昧な説明(?)です。…あれ、この認識自体が間違ってます?

ロックが何を指し示すかで変わりますが,ファイルロックのようなものを考えているなら,DBの実装によってはあってないと言えるかと...
ロックという言葉が,DBの中で使われる用途と同じと考えるなら,例えば InnoDB ならあってないです.

簡単に言うと,マルチバージョニングを使ったDBでは,ロックなしに READ COMMITTED のトランザクションが実行できます.
DBの中に,更新履歴がすべてor一部残っていて,トランザクションのタイミングによって読み込むデータを切り替えることで,うまく隔離しています.

例えば,テーブルの全行を読み込んでいる間に,別のトランザクションがレコードを書き換えたとします.
その場合,読み込みトランザクションは,その後のトランザクションで書き換える前のバージョンのレコードを読み取ります.
こういうロジックなので,そもそもロックして相手の実行を妨げたりしないのです.

PostgreSQLは履歴全部を持っていて,VACUUMというメンテコマンド実行時に不要なデータを消します.
InnoDB/Oracleは,最新データと,それ以前のデータへ戻すためのデータを持っていて,必要に応じて古いデータを参照します.こっちの場合は不要なデータは自動的に消えます.

というわけで,ロックではちと説明しきれない範囲かと...


あと,ロックで問題が発生する部分で,表を使って説明するとわかりやすいかも.
ちょっとがたがただけど,以下のイメージ.


プロセスA             ファイル        プロセスB
ファイルを読み取りで開く     100
100を読み込む         
ファイルを新規で開く         空
                                ファイルを読み取りで開く
                                空を読み込む
101を書き込む           101
ファイルを閉じる
                                ファイルを新規で開く
                      1         1を書き込む
                                ファイルを閉じる


| | Comments (0) | TrackBack (0)

Sunday, July 24, 2005

配列の評価ツール改良その2

2006/03/04追記

配列の評価方法とツール改良その3に新しい記事があります.

----

配列の評価方法とツールに書いたツールを改良しました.

いくつか指摘していただいた点を修正して,見た目を変更しました.
%表示を加えたことでかなり横に長くなってしまったので,2段表示にしました.
(ちょっとみにくいかもしれません...)

http://www.mikage.to/keytool/perlscript.lzh

Chasen for Windows をインストール後,添付ドキュメントに従って操作すれば,簡単にn-gramの頻出単語の一覧と,各配列でのキー評価が行えます.
SKYとか月配列の姫踊子草定義ファイルとか,誰か集めて置いておいてくれると解析に便利?

■スクリプトの処理内容

入力:http://www.mikage.to/keytool/data.txt
出力1:http://www.mikage.to/keytool/step1.txt
出力2:http://www.mikage.to/keytool/step2.txt
出力3:http://www.mikage.to/keytool/step3.html

結果の値が正しくないとか,他にこんなのを測定したいとか要望があれば,対応しようと思いますのでコメントorTBにてどうぞ.

| | Comments (17) | TrackBack (1)

Thursday, July 21, 2005

英字配列と日本語配列

Kiiteの日記帳のキーボードより

しかし、みんなHHK pro使ってんだね-。英語配列だよね?

私仕事柄同じキーボード使っているので、英語配列でも問題ないんだけど、たまに外で仕事しないといけないときがあって、外のキーボードは大抵JIS。そんでもってたまに外で仕事をするって事は大抵緊急事態っぽいので、そこで配列違ってるとすごい困るので、家でもJISに固定してます。みんなはそういうこと無いのかな。>>HHKproな人

わたしはオフィスでは HHK Pro 無刻印,少し前までは自宅でも HHK Pro 無刻印でしたが,困ることはあまりないですね.
FF11するときはファンクションキーがある普通の日本語キーボードですし,日本語キーボードの端末を使うこともたまにありますが,両方の配列をだいたいおぼえてしまっています.
あまり使わない記号は少し迷うことがありますけど(^^;

わたしは日本語入力の配列も変えちゃってますが,こっちも人のマシンさわるときは使えないので,やはり2パターンをつかいわけています.

やはりメジャーな配列で打てないと不便ですし,両方慣れてしまうのがよいかと...


| | Comments (0) | TrackBack (0)

キー配列比較の改良その2

キー配列比較を改良.

JLOD,ACTはDvorak配列で結果を表示するようにしました.
また,英数字と句読点の入力に一応対応しました.
キーの切り替えなどが考慮されてないですが,比較の参考にはなると思います.

ローマ字入力でもなく、かな入力でもなくのkouyさんから,月配列2-263とU8版で同手シフトを削除した定義ファイルを提供していただいたので,その部分も差し替えました.
これで,交互率があがっているかと思います.

| | Comments (1) | TrackBack (0)

電子投票

選挙にわざわざ行くのはめんどくさいので,電子投票自体は賛成だけど,今あるシステムはどれも怪しいように思える.

http://www.itmedia.co.jp/enterprise/articles/0507/19/news059.html

少なくとも,選挙実施側がその気になれば,結果の改ざんはできるだろうし,後からそれを証明するのも難しそうだ.
アメリカの選挙でも電子投票が使われて,結構怪しかった,という話も聞いたことがあるし.

投票したことが結果に反映されている事を投票者自ら確認できる方法を用意してくれれば解決しそうなものだけど.

オンラインの場合の手順.

1.選挙のお知らせがくる.一人一人に投票コードが発行される.
2.Webから,投票コードを入れ,投票者を選んで,自分だけの確認コード(任意の英数字20文字くらい)を入れる.
3.選挙結果の発表と共に,各候補者に投票した人の確認コード一覧がWebで公表される.

オフラインの場合の手順.

1.選挙のお知らせがくる.一人一人に投票コードが発行される.
2.投票所にいって通知はがきと引き替えに投票カードをもらう.
3.専用端末に投票カードをいれ,候補者を選んで,確認コードを入れる.カードは回収される.
4.選挙結果の発表と共に,各候補者に投票した人の確認コード一覧がWebで公表される.

確認コードを十分注意して入れれば,他人に誰に投票したかわからないようにした上で,自分の表がちゃんと反映されていることを検証できる.
オンラインの場合は,誰が誰に投票したか選挙実施者は収集可能だけれど,これはどうしようもない.
オフラインでの場合なら,うまくやればそこは切り離し可能のはず.投票カードの中に密かに記録されないようにするなどの検証は必要にはなるけど,投票カードを渡すまでと,専用端末の会社を別々にするなどである程度は防げるかなと.

既に誰か考えてそうなものだけど,なんでないのかなあ.
電子投票で不正しやすくしたい人が多いのだろうか...
それともこの方法に致命的な欠点とかあるのかな.

| | Comments (4) | TrackBack (1)

Wednesday, July 20, 2005

お買い物

入門早稲田式-速記が書ける

JLOD配列の省略入力の候補探しのために購入.
速記の省略方法がそのまま参考になるかなあと.
読んでみると,結構省略ルールが多いかも.

1文字のものは除くとして,
助詞:80
ある・する:18
ない:14
です・ます:41
くらいはあるようだ.合計約160.

JLOD配列では,同じ指の連続を避けた場合で,18*6=108通り.
左手のYを1打目,2打目を左手人差し指以外,右手の省略を加えると 9+15=24通り.
あわせても足りないので,同じ指の連続は避けられないかな...
もしくは,3ストロークにしてしまうか.

覚えやすい配置にしたいので,配置を考えながら決めるかなあ...


■Visual C++ .NET

キー配列変換ソフトを作ってみたくて買ってみたけど,Professional以上じゃないと配布は無理らしい.
まあ,家で開発して会社でコンパイルするかなあ...
Windowsプログラミングはほとんどやったこと無いので挫折するかも...

とはいえ,配列変換ソフトがフリーで,気軽に試せる形であるかどうかは利用率に大きく影響するので作りたいところ.
自前でやればSendSとかキーボードガイド表示とかも出来るはずだし.
(そこまで気力が持つかはわからないけど(^^;)


| | Comments (0) | TrackBack (0)

キー配列比較の改良

キー配列比較を少し改良.
打鍵を詰めて表示して,カウントもだすように.

Dvorakベースの配列がわかりにくいので,これはDvorakベースのキーで表示すべきかなあ.
とりあえずの感覚はわかるとは思うけど.

| | Comments (2) | TrackBack (0)

Tuesday, July 19, 2005

配列の評価ツール改良

2005/07/24追記
配列の評価ツール改良その2
に改良版があります.

----

配列の評価方法とツールに書いたツールを改良しました.

同時打鍵系にも対応させました.
その他細かい部分をいくつか直しています.

http://www.mikage.to/keytool/perlscript.lzh

Chasen for Windows をインストール後,添付ドキュメントに従って操作すれば,簡単にn-gramの頻出単語の一覧と,各配列でのキー評価が行えます.
SKYとか月配列の姫踊子草定義ファイルとか,誰か集めて置いておいてくれると解析に便利?

■スクリプトの処理内容

入力:http://www.mikage.to/keytool/data.txt
出力1:http://www.mikage.to/keytool/step1.txt
出力2:http://www.mikage.to/keytool/step2.txt
出力3:http://www.mikage.to/keytool/step3.html

出力内容は相変わらずあまり検証してないので,一部間違っているかも.(^^;

他にこんなのを測定したいとか要望があれば,対応するかもしれないのでコメントorTBにてどうぞ.

| | Comments (4) | TrackBack (0)

Monday, July 18, 2005

JLOD配列練習

というわけでJLOD配列に変更して練習しているのだけど,ようやく「や行」「ぱ行」になれてきた.
でも,気を抜くとまだ古い位置で打ってしまう.

普段の入力で左右交互率がほぼ完全になったので,リズムよく打てるとだいぶ気持ちいい感じ.
省略入力では交互でなくなるけど,省略しているという気がするので問題なし.

M式とかは最初から左右交互が完璧なので快適度は高いのかな,とか思ってしまった.
(同時押しがあるのでわたしは使いたいとは思わないけど)


タイプウェルでの成績はこんな感じ.
赤線から上がJLOD配列です.
高速といいつつまだ全然速くないのが...
もっと練習すべきかなあ.

twk20050718

| | Comments (0) | TrackBack (0)

配列の評価ツール

下駄配列ver.1.03を解析へのコメント

■左右交互打鍵の多さ  ……は解析結果が実際の打鍵感覚と合わないよう思う。例えば「あお」([FK][DJ])は、このスクリプトでは左右交互2、左左1、右右0と弾き出される。実際の打鍵感覚は左右交互0、左左1、右右1だと思う。

このスクリプトでは同時打鍵をうまく考慮できていません.
時間取れたら同時打鍵にも対応させてみますね.

同時打鍵の場合は,どう判断するのがいいのか難しくて.(^^;

 同列同指ってなんでしょう?

同じ段の同じ指での打鍵です.
人差し指,小指以外では同じキーの連続押しになりますね.

あまり意味がないかも...
同一連打,とかの判定に変えた方がいいですかね.(^^;

あと、下駄配列とは関係ないけど、JISかなのキータイプ数の少なさは結構すごいと思った。作り込んだ4段配列こそ最強というのは、十分ありえるのではないでしょうか。

JISかなは打鍵数ではかなり少ないですが,4段使っているので...
4段使うか,シフトを導入すればかなり打鍵数は減らせるはずです.

3段同士の中で比較した方がよろしいかと...

下駄配列をキー配列比較に追加させていただきました.
ただ,定義ファイルに一部間違いがありました.

=s + ★
yuiop@ 未$ぷ$え$づ$゜$未
hjkl; ぐ$ろ$げ$未$ぎ$未 <1つ多いです
nm,./ び$ぶ$ぜ$ぞ$ぢ

| | Comments (3) | TrackBack (0)

JLOD配列ページ作成

まだ未完成ですが,とりあえず定義ファイルは作ったので公開します.

JLOD配列 (Japanese Layout on Dvorak)

未使用のYキーは,Yキー+任意の1文字で省略入力として使えるかもしれないですね...

ACT(M1)と比べると,ふぁ行,う゛ぁ行が2打から3打になっています.
その代わり,すべての子音が右手になったので,ぱ行,や行を打つときに,右左左右右左,のように左右交互が崩れることが無くなりますし,とりあえずは反転母音を覚えなくて済みます.
(省略入力では反転母音を使いますが,とりあえずの入力で必要ないことは新しく覚える人には大きいと思います.)

| | Comments (1) | TrackBack (0)

Sunday, July 17, 2005

JLOD配列

ACT配列がベースだったけど,ぱ行,や行まで変えてしまい,オリジナルとはだいぶかけ離れてしまったので,名前も変えることにする.
あまり良い名前も思い浮かばなかったので,Japanese Layout on Dvorak の頭文字を取って JLOD配列という名前にした.
わかりやすいし,グーグルで確認したところ他には使われていないようだったので・・・

二重母音を「あ行」でも使えるようになるかと思ったけど,句読点の他に「っ」もあった.
前と同じ割り当てなら「あい」の部分になるわけだが...
右手小指上段の LL (QwertyではPP) で「っ」にしようかとも思ったけど,「っ」の利用頻度はかなり多いので,逆に効率が下がってしまいそうなので却下.

句読点の位置も Dvorak と変えてしまうと違和感が増えるかも?
やはり「あ行」の二重母音はあきらめる方がすっきりするかなあ・・・

現在作成中↓





あい

おう

えい

うう

うい

ぱ行

が行

が行

ら行

拗音






だ行

は行

た行

な行

さ行

あん

おん

えん

うん

いん

ば行

ま行

わ行

や行

ざ行

| | Comments (3) | TrackBack (0)

Saturday, July 16, 2005

理想のマウス?

Uジローさんのマウスの記事より

写真で見ただけではさっばりピンと来ないのだけど、なんとコレ、マウスの一種なのだ!中央のローラー(黒くて細長い棒状の部分)を転がすとマウスカーソルが上下に移動する仕組みになっている。え?左右は動かないの?・・・ご安心を!もちろんそんなわけはない。

ちょっと説明が難しいのだけど、このローラー(っていうか棒)、軸受けにがっちりと固定されているわけではなく、棒全体が左右にスライドして移動できる構造なのだ。この棒を左右にスライドさせることで、マウスカーソルを左右に移動させることができるのだけど、これがまた実に滑らかにスライドするようにできている。ローラーを転がすことによる上下移動も当然、非常にスムーズなので、上下方向の移動と左右方向の移動は全く性質の異なる動きをさせるにもかかわらず、それをみじんも意識することなく、斜め方向も自由自在、ウルトラスムーズに移動させることができる、ってわけ。

以前Fentekのページで見たときはどんなのかわからず気にもとめなかったのだけど,そういう仕組みだったとは...

KINESISにしてからHHK比でキーボードがかなり場所をとるようになって,狭いパソコンラックではマウスの移動スペースが無くなっていたので,欲しくなった.
メーカーのページで見てみると,紹介されていたClassicの他に,Proというものもでている模様.
ローラーバーが少し長くなったりと改良が加えられているようです.

というわけで,早速購入してみる.
Fentekはこの前カードNGといわれたので,aritechに注文.
カードで買えるかは謎だけど...
(後から断りのメールが来なければいいけど(^^;)

届いたら使用感など書きますね.

| | Comments (2) | TrackBack (0)

Thursday, July 14, 2005

CGIのファイルロック問題

なるちゃんの日記より

実は密かに、CANO-LabでCGIやDBのロックと同時実行制御というタイトルの記事を作成し、つい最近公開しました。

読んで字のごとく、(数年前の僕も含め)あまりにみんなのファイルロックの使い方が下手だ、ということで、決定版の解説を作ろう、と思ったものです。

http://jn.swee.to/cano/lock/index.shtml

懐かしい...とまず思ってしまう.
昔CGIを書き始めた頃は,flockではうまくロックできない,と書かれたWebサイトをよくみかけたものです.

単に使い方が間違ってるだけだと思いますが,当時は人気サイトにそう書かれていたので信じている人が多かったように思います.


----

で,文章を読んだところいくつか微妙な記述があったので指摘してみる.

文章の中で,ロック・排他制御と,トランザクションを似たようなものとして扱ってますが,異なるものです.

トランザクションに関しては
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpguide/html/cpconacidproperties.asp
などが参考になると思いますが,ロックより抽象的な概念です.
また,ロックで実現できるのは,トランザクションの独立性だけです.

ロックにも複数あり,flockやMySQL(MyISAM)のテーブルロックのようなRead/Writeロックもあれば,MySQL(InnoDB),Oracle,Postgresであるようなもっと複雑なロックもあります.
mutex,クリティカルセクション,Javaのsyncronizedなどはもっと単純で,単に排他制御するだけです.

この辺は混ぜずに話した方が,わかりやすいかと思います.
(特に後々DBを扱う場合に,flockのつもりだと困ることも多いかと...)


プログラム2の例

if (-e "lockfile.lock") {sleep(1);} #ロックファイルが存在する間、1秒ずつ待つ

ロックファイルが存在したら1秒待つ処理と直すか,コードが間違ってますね.

while (-e "lockfile.lock") {sleep(1);}

でも,こんなコードにするとプロバイダから怒られるのでまずそうですね.
実装例として,上限回数5回くらいでリトライするものを見たことがあるので,例にはそういうものが良さそうです.


プログラム3

print OUT $count;
close OUT; # ロックは自動的に解除される

丁寧に自分でロックを解除しない方がよいことも触れた方がいいかもしれません.

print OUT $count;
flock OUT, 8;
close OUT; # ロックは自動的に解除される

と書くと,Perlのバージョンによってはうまく動きません.
printのバッファがフラッシュされる前にロックが解除されてしまうからです.

もうだいぶ前に対処されて,今はflock解除時にバッファが自動的にフラッシュされるようになっているはずですが,すごく古いPerlを未だ使っているかもしれないので,補足として.


flockの動作について.

flockはアドバイザリロックで強制ロックでは無いことを説明に加えた方がよさそうです.
flockはあくまで「宣言」であって,ファイルを操作するすべての場所でロックを使わないと意味がないことを理解していないと,書き込み処理の時は読み込み→書き込みの一連の処理を正しくロックして行うものの,読み込み処理のみの時はロック一切なしで処理してしまう,ということをやりかねません.

説明の文章の中では,ロックを取得することと,ファイルに読み書きできることが同列で扱われているので,その点誤解される可能性がありそうです.


負荷ツールに関して.

http://www.apache.org/

Apache付属のabというコマンドラインのツールや,Jakarta Projectの中にあるJMeterなんかを紹介すると良いかもしれません.


DBの話.つっこみ箇所が多いかも.(^^;

どこまで安全に、広い範囲をロックするか、を、リレーショナルデータベース(以下単にデータベース)の用語では「隔離レベル」と言います。

http://www.techscore.com/tech/sql/11_03.html

あたりを読んでみてください.
ちょっと正しい説明からかなりはずれてしまっていると思います.

でも、既に大抵の問題は説明しました。ここまでのCGI編で述べた「原則」を理解していれば、DBにおける排他処理を理解したも同然です。

MySQL(MyISAM)に関してはほぼ同じですが,MySQL(InnoDB),Postgres,Oracleなど,マルチバージョニングを採用しているシステムでは,その機構について理解が必要です.
正しく理解できていないと,デッドロックなどが発生して悩むことになると思います.

また,MySQLは,デフォルトエンジンはMyISAMですが,他にもInnoDB,BDB,NDB,MEMORYなどのデータベースエンジンがあって,それぞれで排他制御周りの実装まで異なっています
MyISAMでしか通用しない話は,そのように書いた方が誤解が少ないです.

InnoDBで TABLE LOCK しても思ったようには動作しない可能性があります.

7.5.15. InnoDB テーブルの制限事項

MySQL の LOCK TABLES 操作では、すでに完了した SQL ステートメントで設定された InnoDB の行レベルロックが考慮されない。つまり、あるテーブルで他のユーザのトランザクションが行レベルロックを設定していても、そのテーブルでテーブルロックを取得できる。したがって、テーブルで実行した操作が他のユーザのロックと衝突した場合は、操作が待機状態になる可能性がある。また、デッドロックが発生する可能性もある。ただし、InnoDB によって設定される行レベルロックでは常に完全性が配慮されているため、デッドロックによってトランザクションの完全性が損なわれることはない。 また、テーブルロックのために、他のトランザクションはテーブル上で(矛盾するロックモードで)行レベルロックを追加で取得できなくなる。

次の説明も条件によって間違いです.

これらの明示的なロックを行わない場合、MySQLはレコードを書き込んだり変更したり削除する際にその瞬間だけテーブル全体を自動的にライトロックし、

場合によっては,読み取りとINSERTが同時に行えます.
したがって,ライトロックが自動的に行われるわけではありません.

7.1. MyISAM テーブル

データファイル内に空きブロックがないテーブルに対し、他のスレッドがそのテーブルから読み取りを行うのと同時に新しいレコードを INSERT できる(同時挿入)。空きブロックは、大量のデータを含んだ可変長レコードに含まれるデータの長さが短くなるような更新をした場合、またはレコードを削除した場合に発生する。すべての空きブロックを使い切ると、それ以後の挿入は再び同時挿入になる。

※まあ,データが壊れることはないですが...

さて、MySQLはテーブル単位でしかロックできないので、300MBのテーブル全体を走査して検索するような事態が発生すると、数秒間~数十秒間、他の接続がそのテーブルの排他ロックを得られなくなって立ち往生してしまう、という問題が起きます。MySQLのデザイン上の制約なので、そういう検索が起こらないよう、全てが一瞬で終わるように工夫しましょう(方法はたくさんあるのでマニュアル参照)。どうしてもこれが避けられない場合にはPostgreSQLを検討します。

InnoDBを使いましょう.
MySQLと同じSQL文法ですし,MyISAMと混在させて使うことも出来るので,テーブル毎の用途に合わせてエンジンを変えることもできます.
(異なるエンジンのテーブルを一つのトランザクション内で使用するのはお勧めできませんけど)

明示的にユーザが何かをロックする、ということはありません。PostgreSQLは、中で複雑なことをして、自動的に必要なものをロックしてくれているみたいです。

明示的にロックしないとデッドロックすることが多くなります.
まあ,コミットで失敗したらやり直せば...というのも確かですが,最初から失敗しないようなSQLを書く方がよいですね.

また,トランザクションの中でも,同じSELECT文を2回実行したのに,結果が異なることがあったりします.
この辺をどこまで厳密に他のトランザクションの影響から隔離するか,というのがトランザクション隔離レベルです.
一番高い Serializable にすれば安全ですが,パフォーマンスは落ちるので,デフォルトは Serializable より低い隔離レベルの事が多いです.

Postgresに関してはここに説明があります.
MySQL(InnoDB)に関してはここに説明があります.


というわけで指摘はここまで.

DBに関しては仕事でやっている人でもちゃんと理解している人は少なかったりします.
デッドロックがまれに発生していて,しかもデッドロック時にトランザクションの再実行もしてない...なんてのは実際に経験したことがあります(^^;

この辺はDBのコンソールを2つ開いて,2つのトランザクションをいろいろな形で同時実行させてみると理解が深まるかと思います.

| | Comments (0) | TrackBack (0)

Tuesday, July 12, 2005

蒼星配列を取り込んだACT配列での句読点

V,F をや行,ぱ行に置き換えて,左側を母音専用にしようと思って気づいたのだけど,句読点の入力はどうしよう...と悩む.

ACT(M1)では,二重母音は子音の後のみ有効だったので問題なかったのだけど,あ行の二重母音を許容してしまうと句読点の入力が出来なくなってしまう.

うーん.句読点はかなり頻度が高いので,シフト兼用は嫌だし.
二重母音の一部をあきらめるべきかなあ.
「あい」「おう」「えい」「うう」「うい」だと,「うう」「うい」に関しては,あ行で使うことはあまりなさそうなので,ここを句読点に割り当てるかなあ.
思い当たる語句というと「ううむ(語句といえるか微妙だが)」「ういろう」「初陣」「初産」あたりで頻度は少なそう.

この辺の頻度集計をどこかで見た気がするけど,見つけられず.

----

あとは,ふぁ行,う゛ぁ行の代替入力を決める必要が.
え行+ゃぃゅぇょ,の省略打ちと同じストロークを使えるかな.

でゃ行:D(人差し指)+人差し指拗音化キー+母音
てゃ行:T(中指)+薬指拗音化キー+母音

ふぁ行:F(人差し指)+人差し指拗音化キー+母音
う゛ぁ行:V(薬指)+薬指拗音化キー+母音

となるのかな.
元々この運指は割り当てられてるものが少ないので問題なく埋められた感.

あとはこの配列を姫踊子草ファイルに直して練習かな.
慣れるまで大変そうなので週末に入れかえよう...

| | Comments (0) | TrackBack (0)

Monday, July 11, 2005

ワイヤレスヘッドフォン MDR-DS4000

今まで,家では SONY MDR-DS5100 を使っていたのだけど,ヘッドフォンのスポンジがボロボロになってしまい,耳が痛くなるようになってしまったので,新しいものを購入.

当時バーチャルサラウンドに興味をひかれたのだけど,結局普段音楽を聴くときに使うと,音質がかなりかわってしまいいまいち.
映画なら良いけど,映画そんなに見ないし...

ってことで,次は MDR-DS4000 に.
デジタル赤外線ので一番安いのに.
2万ちょいで買えてしまった.5年もたてばだいぶ安くなるのね(^^;

最上位機種は頭の向きを検知して音の方向を変えてくれるっぽいけど...
映画見ているときでさえ不要なような(^^;
(とっても大きなスクリーンなら意味あるのかも...)

MDR-DS4000はスタンドに置けば充電出来るところと,光パススルー出力がついたのが違いかな?
上位機種ではないので,スイッチとかはちょっと安物っぽいけど,2万と思えばこんなものかも(^^;
あと,ヘッドフォンから左右のバランス出力が無くなった.
よくボリュームと間違えてバランスを変えてしまい,ヘッドフォン外して中央に戻すことがあったので,これは嬉しい機能ダウン.

| | Comments (0) | TrackBack (0)

音声入力とTV電話

Rayさんの福祉大国ニッポン??へコメント.


しかし、五体満足で書きたいことも沢山ある一般人に音声入力が無用なのは 
開発に取りかかる前に、少し身の回りのことを考えたり観察したら分かるはずです。

(略)

2.相手が自分のメールをリアルタイムで読んでいるのが分かっているのに 
音声通話せずに、チャットのように携帯メールでやり取りしている女高生など。 
(JISカナどころではない、ケータイの文字入力の面倒さを考えると 
 「手を使う」ことが人間にとってどんなに気楽なことなのかが分かる。) 
 
3.PCのチャットで最近は文字だけではなく音声でも動画でもチャット 
できるし、携帯と違って常時接続だと何のコストも掛からないのに、圧倒的 
多数はキーボードによる文字チャットを選択している。

途中から音声入力と音声会話がごっちゃになってないだろうか?

音声入力と音声会話は全く異なるものです.

音声入力は音声で入力しましが,出力はテキストデータです.
対して,音声会話やTV電話(ビデオチャット)は出力データが異なります.

チャットで音声チャットやビデオチャットだあまり使われないのはなぜかというと,
話すのが面倒なのではなく,「声」や「表情」を相手に見せるのが面倒なのでしょう.

また,声や顔の情報は,個人を特定するための情報を豊富に含んでいます.
ネットでの知り合いと話すのには適切では無いと感じる人が多いのでしょう.


機械に認識のために話すのと,人と話すのではどちらが大変でしょうか?
話すのが苦になる,という人にとって,苦になるのは口を動かして発声することではなく,
人との会話で色々気を遣うところなのではないでしょうか.

相手を目の前に,もしくは電話で話す場合,チャットなどと違いかなりリアルタイムな
回答を求められますし,他のことをしながら話すのが難しかったりもします.
(人によっては失礼な態度と受け取られる可能性もあります.)

音声での会話はそういった面倒くささがあります.

だから,時間をかけても携帯やキーボードで文字を入力してメールやチャットで
やりとりをする人が多いのだと思います.


そうすると,音声入力の位置づけは,そういった面倒くさくないコミュニケーション手段を
より楽にするもの,と考えられます.

今の精度では微妙かもしれませんが,もっと進化すれば,上記の理由から
もっと流行るのではないかと思います.


----

ちなみに,わたしは普段文字でのチャットしかしませんが,
子供が実家に帰ったりしたときは,ビデオチャットで毎日話していました.

電話したり顔を見せ合うのが苦にならない相手であれば,
文字でのチャットよりビデオチャットの方が適しているのです.

ただ,ネット上でそういった相手と会話する機会は非常に少ないので,
ビデオチャットがマイナーに見えてしまうだけかと思います.

| | Comments (0) | TrackBack (1)

蒼星配列

ACTに近い配列.

蒼星配列

V,Fをや行,ぱ行に使うらしい.
コレはいいかもなあ.

わたしは同時押しは避けたい人なので,Shiftキーで拗音は魅力を感じないけど,
V,Fの置き換えは試してみたい.
なにより,あ行の二重母音などが入力できるようになるのが大きい.

ACT(M1)をもう少しいじりたくなってきたかも.
少し考えてみよう...

| | Comments (2) | TrackBack (1)

Saturday, July 09, 2005

日本語入力に関する10の質問テンプレート

だいぶ対応が遅くなってしまいましたが,「挫折」と「試用」を分けました.

日本語入力に関する10の質問

| | Comments (2) | TrackBack (0)

Friday, July 08, 2005

ちっちゃな MP3 Playre TJ500(TinyJack)

今まで,MP3 Player として iRiver H120 を使っていたのだけど,最近重いこともあって,ほとんど使ってなかった.
(ちなみに重さは約160gくらい)

最近マイメロとかお気に入りの曲もでてきたので,軽い MP3 Player が欲しくなり店頭で探してみた.
昔はメモリタイプのは512Mとかが最大だったけど,今は2Gタイプまであるようで...
さすがに2Gのは高かったですが(^^;(4万くらい)

MP3を転送するときケーブルでつなげるのが嫌(ケーブルが邪魔だし,探すのに苦労することが多い)なので,USBに直接つながって,かつ軽いものということでOTO 「TJ500(TinyJack)」 (ピンク) 1GBを購入.
ビッグカメラで18000円くらいだった.

小さくて軽いし,ケーブルもいらないのでかなり良い感じ.
ちと電池周りのふたとかの作りがちゃっちいきもするけど,とりあえず小ささと軽さでは一番で,ピンク色があるのが選定の際におおきかったです.
マニュアルを見ると歌詞表示なんかもできる模様.
フォーマットは
[分:秒] 歌詞
という一般的なものなので,iRiver の MP3ファイルへの埋め込み方式よりはかなり扱いやすそう.

% TORICAのホームページは製品案内が動的出力になっていて直接リンクを張れなかった.
% SEO対策は考えてないのだろうか...

| | Comments (0) | TrackBack (0)

Wednesday, July 06, 2005

ココロの運転技能チェック

やってみた.

http://www.drakahige.com/CHECK/

各技能レベル評価一覧

以下の表は、技能レベル毎の得点と評価です。
各種技能 得点 評価
自己肯定スキル総合 56
対人スキル総合 25 初心者マーク
ストレス対処スキル総合 35

あたってるようなきは.
ストレス対処スキルは低いけど,そもそもストレス自体あまり感じない気がする.

| | Comments (2) | TrackBack (2)

Monday, July 04, 2005

Dvorak配列用ACT配列(M1版) 2005/7/4版

今日タイプしていたところ「デュアルCPU」と打とうとして,「でゅ」がでないことに気づく.
調べてみると,拗音の打ち方(え行+ゃぃゅぇょ),の定義が間違ってました(灰

というわけで,その点だけ修正.

高速タイピング ACT配列(M1版)※作成中

特殊省略の整理をしたら正式版にしたいと思っているけど,とりあえずはそこだけ.

ちなみに,母音+「き」「く」「つ」「っ」の省略打ち,はそこそこ便利です.
ただ「っ」はあまり使えてないかも.
「き」「く」の省略打ちは漢字熟語が多いため,使いやすい.
「っ」はうまく思考の流れに組み込めていない感じ.
まぁ,そのうち慣れるかなぁ…

| | Comments (0) | TrackBack (0)

Sunday, July 03, 2005

同時打鍵無しの入力配列の比較

ユーザの入力内容を各配列で評価するCGIを作成してみた.
各配列でのタイプ内容を表示して,どの段を使うのか,右手左手の分配はどうか,アルペジオ打ちになっているかどうか,を見た目でわかりやすいように色分けする.

キー配列比較

Qwertyローマ字,AZIK配列,ACT配列(M1版),JISかな,和ならべ,で評価を行う.
このほかにも,同時無しの配列で,姫踊子草のフォーマットの定義ファイルがあれば対応可能だけど,月配列とかは菱用のものしか無いようだ…
(フォーマットは単純そうなので,菱の設定ファイルにも対応してもよさそうだけど,今日は時間切れ)

とりあえず,実験してみると,以下のことがいえそう.
・Qwertyローマ字は片手を連続して打つことが多く,上段の利用が多い
・AZIKは打鍵数は減るが,バランスはQwertyローマ字と同様.
・ACT配列(M1版)は,ホームポジション段の利用が多く,ほとんど左右交互打鍵.左右交互でない部分の多くはアルペジオ打ちになっている.
・JISかなは打鍵数は少ないが,最上段の利用もそれなりにある.左右への偏りも大きい.
・和ならべは打鍵数はQwertyローマ字とほとんど変わらないが,ホームポジション段の利用が多く,左右交互率も高い.
といった感じ?かな.

和ならべの配列が,打鍵数が多い以外は意外と打ちやすそうなことが判明.
いろんな拡張ルールを覚えたくない人にはよいかも.

| | Comments (2) | TrackBack (0)

Dvorak配列の視覚化

Dvorak配列で検索していたら,
文字,キーシーケンスなどの頻度調査
というページを発見.

ここにある,
QwertyとDvorakの比較
QwertyとDvorakの比較(2)
の表記がとてもわかりやすい.

以前作った配列の評価方法とツールの出力に加えてみるべきか...
JavaScript表示もあるし,明日時間がとれたら作ってみよう...

| | Comments (0) | TrackBack (0)

実名とハンドル

あまり本題と関係ないところへのコメントで申し訳ないけど.
かえでさんの記事から

実名を出すことなくハンドルネームで物事を記す以上は、記事の質に関しては日々必要以上十二分に見直さなければなりませんし(訂正すべきところはすぐさま直すことも含めて)、おかしな表現は可能な限り避けなければなりません。それがハンドルネームを使い続ける者にとっての「宿命」ですので。

2chのような匿名は別として,固定された名称を名乗っていれば,実名もハンドルネームも差は無いかと思います.
実名としても,ネット上の名称が本当の実名と一致しているかはわからないわけですし,実名は1人1つ(結婚とかによる改名は除くとして)という制約はあるものの,その名前が世界中でユニークかどうかは保障がありません.

ネット上での名前は,そのユニーク性(他に同じ名前がないこと)が重要かと思います.

実名では絶対無いような名前をハンドルとして使う方が,よくある実名を使うより良いと思ってます.
実際,わたしはハンドルネームで検索すれば,自分に関するページしかでてきませんが,実名で検索すると他人のページがいっぱい出てきます.
(1ページ目の結果では,わたしのはベクターのとCPANのだけ.2割しかヒットしません.)

昔,気に入った漫画2つから,それぞれ名字と名前をとったものですが,幸い同姓同名はいないようで,嬉しい限りです.

% ネット上での活動の全部がバレバレになるのがアレですが(^^;;

| | Comments (10) | TrackBack (2)

Blogはサーチエンジン的に有利?

blogの特徴の1つに,コメントとトラックバックがある.

トラックバックは普通にリンクが張られるし,コメントも自サイトのURLを書けば普通はリンクが張られる.

従来のWebサイトでは,サイトの管理者側が能動的に作業しない限りリンクは発生しかったけど,blogなら受動的にリンクできる.

このおかげで,リンクをサイトの評価基準とするサーチエンジンには,blogは上位にでやすいものと思う.

理論的には以前からわかっていたことだけど,最近配列関係の記事を多く書いたりしてることで,そのことを実感.

Google: 高速タイピング(3位)
Google: ACT配列(1位)

Yahoo: 高速タイピング(9位)
Yahoo: ACT配列(1位)

マイナーな検索語句ということも大いにあるだろうけど,結構簡単に上位にいけてしまうのだなぁと思ったり.


そのうち,トラックバックとか,深いURLへのリンクの価値を下げるとか,そういう変更がされたりするのかな?
とも思ってしまう.
本家サイトのほうが上に来るべきと思うし.
(判別が難しいところだとは思うけど)

| | Comments (0) | TrackBack (0)

FortiGate Farmware MR10

FortiGate Farmware MR10 でSIPをサポート!

時々MSN経由でWebCam使ってビデオチャットをするのだけど,今までは音声がだめで,WebCam映像のみしかやりとりできなかったのが,音声込みでちゃんとチャット出来るようになった.
普通のルータならUPnPで問題ないんだろうけど,業務用のはUPnPには対応して無く不便していたのでありがたい.

と思っていたら,NetScreenもサポートらしい.

IP電話とかが流行ったことで業務用でも需要がでてきたのかな?

| | Comments (0) | TrackBack (0)

eDimensional 3Dメガネ

3D表示に興味がわき,3Dメガネを購入してみた.

http://www.edimensional.com/

原理的には,左右の視界を交互にディスプレイに表示し,専用メガネでそれに併せて左右の視界を交互に見えなくするというもの.
ディズニーランドとかのアトラクションであるような偏光メガネタイプではないので,結構ちらついてしまうのが欠点か.

うちのグラフィックカードはGeForceなので,nVidiaからでている3Dドライバをインストール.
PCとディスプレイの間に付属の機械を挟み,それについてる同期用の赤外線発光部を適当なところに設置.
あとはメガネのボタンを押してスイッチをいれてから,メガネをかけるだけ.
(最初,メガネのボタンの存在に気づかず苦戦したりした(^^;)

まず,テストアプリを試すと問題なく3Dにみえた.
MSフライトシミュレーター,FF11ベンチもOK.
ただ,FF11はうまくいかなかった.
ゲーム開始までは3Dになるのだけど,肝心のゲーム中の画面がだめ.
なんか特殊なことしてるのかなあ.
(3Dバックグラウンドとフォアグラウンドの解像度が違うようなので,一度3Dで描いてから2Dで表示し直してるのかも?)

ちらつくし,立体的に見えることで結構目は疲れてしまうかも.
長時間のゲームには向かない感じです.
(ホットキーでON/OFF切り替えられるので,途中で2Dに戻すことも出来ます.)

それから,DVDを3D表示するソフトの方も購入したので試してみた.

まずは普通に表示は無理だろうと思いつつ,アニメ...
手元にあったシスプリリピュアを見てみる.

OPなどは,背景の平面画像の上に,キャラ画像の平面画像が少し手前に見える感じ.
これはこれで面白い.
ただ,全体的にアニメのせいか,画面が揺れたりするので,実用には耐えない模様.

次に,マトリックスを見てみた.
動きの激しいシーンを見てみると...確かに3Dに見える.楽しい...
ただ,動きが無いシーンでは,奥行きの検出が出来ないようで(当たり前だけど),2D表示とかわらない.

最初から3D表示前提で作られていれば面白そうだけど,2時間とかある映画を3Dで見続けるのはかなり疲れそうなので,やっぱり実用的では無いかも...

液晶側とかで3D表示するアプローチが正解かも?
(高いので気軽には試せないけど.1度は見てみたい...)

| | Comments (2) | TrackBack (1)

Saturday, July 02, 2005

Dvorak配列

水城珠洲の日記(2nd)のDvorakにて

最近、ローマ字入力の話が多かったのでキーボードの配列のひとつDvorakを調べてみました。 ここでも、ショック。 なんと、ローマ字入力に適した配列でしょう。

か行をcに割り当てるとうちやすくなりますよ.
更に,拗音や二重母音の拡張などをするとDvorakJP配列になりますね.
その拡張を更に進めるとACT配列ACT配列(M1版)になります.

Dvorak配列のついでに日本語入力もやりやすくなるのがメリットですかね.
最近他の配列と比較すると,打鍵数での効率はそんなでもないきはしますが,通常のローマ字入力よりはかなり改善されるはずです.

ううむ、本物で試してみたい・・・。 Standerdなキーボードって入手可能なんでしょうか。

エルゴノミックなものであれば結構ありますが,普通のは日本ではあまり見かけないですね.

海外ではそれなりにあるので,個人輸入なら入手しやすいかもしれません.
例えば以下のサイトとか.

http://www.fentek-ind.com/dvorak.htm

ソフトウェアで対応の方が手軽そうな気はします.
http://www7.plala.or.jp/dvorakjp/dvorak_a.htm
にいくつか紹介されてますし,姫踊子草でもできますね.

| | Comments (0) | TrackBack (1)

天空のシンフォニア

プレイ時間短いってことで薦められたので,久しぶりにこの手のゲームをやってみた.
最近更新してなかった原因はコレです.

天空のシンフォニア

最初の方はちょっと退屈な展開だったけど,後半は良い感じに.
ただ,キャラクターが...

この手のゲームって,いろいろな嗜好の人に幅広く対応できるようにいろいろなキャラを用意するものかと思うけど,なんか微妙な感じのキャラが多いような.
とりあえず消去法で(^^;ミルフィを選択.

戦闘はイージーパッチを当てていたので,すんなりすすめました.

最後の方はシナリオ的にびみょーな感じ.それ以外はまあいいかも.
ミルフィ,結構かわいかったし.

公式ページを見ていたらミルフィのショートストーリーなんてものが.
プレイ後に読むと微妙な感じですが.(^^;

| | Comments (0) | TrackBack (0)

« June 2005 | Main | August 2005 »