深夜番組のようなノリで、Twitter・KVSもろもろについて考える

ライフハック

» 2010/02/16

　前から、発展するかと書きためていたメモから、1本分には発展しそうもない探偵ナイトスクープ風小ネタ集（雑感）です（探偵ナイトスクープって関西の人しか分からんネタかな）。

◇　　　　◇　　　　◇　　　　◇

■Twitter

　何カ月かやってみて何となく分かりました。これって、英語圏より日本語（漢字）圏の方があってる気がします。昔からチャット特有の英語のスラングがあるけれど、それでも、英語では140文字では厳しそう。

　Twitterは本音が出てしまうというのはそのとおりだと思います。ブログは多少いい格好はしてしまいますからね。

　基本的にはチャットの拡張版と見てしまう。チャットといえば Niftyで卒業したわたしですが、当時は、Windows3.1の時代。上海からもやっていて、ホテルで電話線の接続ポイントを外し強引にモジューラジャックに改造して、インターネット → CompuServe → Nifty とつないでいた。ノートPCは14.4Kbps、デスクトップは28.8Kbpsのモデムだった。

　電話線を壊しているのを見て、中国の人に、「あなたはＺビザを持った外国人なのですから、そんなことしてバレたら大変なことになりますよ」って注意されたけど、まぁ、わたしみたいなガキンチョは誰も相手にしないだろうと思っていた。しかし、中国国営のプロバイダと契約していて身元がバレているし、今の中国のインターネットの規制を見るとホントはヤバかったのかな？

　従量課金でつなぎながら寝てしまう人とか、定額制のテレホーダイとかができたり、テレホタイムにはビジーでつながらなかったり、そんなチャット時代を思い出しつつ何となく参加しています。ちなみに、わたしは朝、家を出る前に見ることが多いのですが、Twitterはその頃ビジーになることが多い、アメリカが混む時間なのでしょうね。

　「かとぉぉぉぉぉきちぃぃぃぃ」か、オリンピックのフィギア辺りで二番煎じをやる人が出るのだろうけれど、二番煎じぐらいまでかな？そういうものはすぐ飽きるから、「何度も」は通用しないだろうし……。個人的には、ビジネス上の利用方法があんまり思いつかない。

　無料だから、テーブルマーク（加ト吉）のような利用方法はありだけれど、どう考えても、Twitter（利用者じゃない方）のビジネスって広告以外にやっぱりないと思う。どうやって儲けるのだろう。頭が固くなってるな～。

　それよりも、仮に Twitter と全く同じモノがもっと早く日本から発信していたとしても、金も人も集まってないだろうと、マーケティングやベンチャー市場についてなど、そんなところばかり気になります。

◇　　　　◇　　　　◇　　　　◇

■Key-Value Store（KVS）

　「これからはKey-Value Store（KVS）だ！」という意見が多いのでそれについて。

　先に断っておくと、わたしが関わっている分野でKVSを使わねばならない案件というのはほとんどなく、少し試しただけなので認識が間違っているのかも知れない。間違っていればご指摘いただければ幸いです。

　まずはそもそも論。

　KVSはRDBにあらず、RDBと取って変わるものでもありません。今、RDBを使っていてKVSの方が使いやすいと思うなら、そもそもRDBを使うべきでないところにRDBを適用しているだけの話です。KVSはその名の通り、データストア（保存）を目的にしたもので、RDBはリレーショナルデータベースですから、根本的に別物なので同列に並べることがまず間違っている。

　そもそも、KVSではデータの整合性が保証しにくいという点で、業務システムには不向きです。というか使えません。逆にTwitterのようなシステムや、オンラインゲームなど、最終的なデータ量、ユーザ数が読みにくく、整合性がなくても何とかなるシステムに向くでしょう。

　業務システムでも使う局面はあるかも知れませんが、基本的にRDBとの組み合わせで使うのじゃないかな？

　例えば、RDBを使ってファックスシステムを作ったとします。ファックスシステムでは受送信した画像をどこかに保存しないといけません。そのとき、RDB内に保存することもあるでしょうが、大抵はスケールアウトできるように画像をファイルサーバに保存し、RDBにはファイルサーバのパス・ファイル名のみを保存するという方法になるでしょう。

　つまり、一種のKVSですよね。

　RDBとファイルサーバ（いにしえよりのFTPでしようが、Sambaにしようが、Windows共有サービスを使おうが）＋DNSサーバの組合せというのは、別に新しいシステムの構造とか、新しいテクノロジーでは全くない。KVSも同じように、「必要になったら使うよ」ってスタンスで十分だと思っています。イヤ、KVSを作る人は新しいテクノロジーにチェレンジしている部分はあるのですけれど、KVSを扱うことは新しくも何ともないわけです。

　大差ないというのはわたしの感覚で、Windows共有サービスをFTP、Sambaにするということが大変という人もいる（もちろん、サーバの物理的な引っ越しはデータ量によって大変ですけど）。という点で考えると、現状で、KVSも様々な種類が出ていますが、KVSに対してSQLのような汎用的なアクセス手段があるのでしょうか？

　SQLはちょっとした方言で、「こんなモノ使えね～」っていわれてしまうのですが、そういった人が、「これからはKVS」っていっているように思うのです。しかし、KVSに対するアクセスは、もはや方言というレベルでないほど大きな差があるように……（調査してない）。

　少なくともSQLなら単純な標準SQLのみで記述していたら、そのまま移植できるけれどKVSは無理よね。KVSは単純ですから、標準化はSQLに比べ容易ですが、Googleのように高機能を目指している向きもある。高機能になればアクセス手順も変わるから、ベンダー毎に振り回されるんじゃないですかね？

　KVSを作る方は「アクセス方法を標準化しよう！」とか、「最低限必要な機能を標準化しよう！」とか、そんな話も含めて楽しそうだし、機会があればやってみたいと思いますけれど、KVSを扱う方で「早くしないと遅れてしまう」とか、「そんな大層な話かな？」と思う。必要であれば使えばいいし、そもそもRDBと別物なのに同列にして、「SQLのような変なモノを使わなくてすむ」みたいな論調のブログなどを最近よく読むので、変な話だと思うのです。

　「新しいことは正しいことだ」みたいな風潮はよくない。例えば、Vistaを発売日の夜中に（1月30日で寒かったらしい）並んで買ってしまう人もいたらしいけれど、その行為を、今、冷静に考えてどう思いますか？わたしには、なんかの罰ゲームとしか思えない……。

　とにかく、何かを選ぶのに「新しいから」というファクタは、できるだけ小さなウェートで見た方がよいと思います。

　結局は、業務システムをメインでやっているわたしは、KVSを「RDBと併用しないで単体で使う」という局面はないと判断していますし、必要になっても大して困らない。

◇　　　　◇　　　　◇　　　　◇

■ユーザインターフェース

　イロイロ書きたいことはあるのですけれど少しだけ。

　わたしの俺様ルールの中に「キーイベントやチェンジイベントを極力使わない！」というのがあります。もちろん、矢印やタブキーの制御は必要なのですけれど、数値や日付のエリアの制御です。

　なんで、数値だけとかの制御をキーイベントでするのか？

　例えば、日付エリアで、2010/02/20 と入力するとする。

　このとき、スラッシュを入力しなくても4桁入力した時点で、スラッシュを足すとかそういう仕様が嫌いなのです。

　なぜかというと、わたしは古い世代の人間なので達人のオペレータさんをたくさん見てきたからでしょう。達人は自分がミスタッチしたとき、画面も見ずにミスタッチしたと判断しているし、画面を見ずにミスタッチした回数だけバックスペース叩けます。しかし、スラッシュ区切りで必ずゼロを入れないといけないとか、入力中にゼロやスラッシュを補完するような仕様だと、入力時に叩いたキーの数と、バックスペースを叩くキーの数が違うことになるので、逆に混乱するのです。

　で試しに、エクセルのセルで書式設定を日付タイプにして、システム日付が2010/02/15のときに、2010/02/20と入力するのを試してみてください。（日付は現在時間に合わせて適当に変えて読んでくださいね）

　　　　H22.2.20
　　　　H22.02.20
　　　　H22-2-20
　　　　H22/2/20
　　　　平成22年2月20日
　　　　feb 20
　　　　20feb
　　　　2/20
　　　　2-20
　　　　2010/2/20 ……

　などなど、上どの入力を行ってもエクセルが日付と判断し、『年』は省略してもシステム日付の年を自動で補完し、セルに設定した書式で表示されます。（漢字は他システムからの値コピーのときに便利）

　ただし、エクセルは基本的にセルに何でも入力（制限はできるけれど）できる仕様上、

　　　　2.20 → これは数値と見なされてNG
　　　　2010.2.20 → これは文字列と見なされてNG
　　　　0220 → これは数値と見なされてNG
　　　　20100220 → これは数値と見なされてNG

　などの入力はできません。

　これらは、少なくとも、エクセル95（2000年問題はあったけど）からあった機能ですが、わたしは業界に入った頃から、「カスタムのシステムを作ってパッケージのエクセル以下じゃあマズイ」と思っていました。ですから、わたしが細かい仕様を決めるときは、年月まで補完し、補完のモードを3つ（直近の未来日付か、直近の過去日付か、当年当月か）を作ります。

　エクセルでは『日』だけで『年月』を補完しては、数字が入力できなくなりますから、『月』までは補完しませんが、業務システムでは日付エリアは日付しか入らない（ことの方が圧倒的に多い）ために、普通は『年月』を補完しても何の問題もないわけです。もちろん、漢字まで入力するパターンは現実的に不要なので作りませんが、エクセルよりは使いやすくなりますね。

　もっとも、達人は数十分もあればどんな入力方式でも慣れるのですけどね。

　実際のコーディングや仕様書はモードの指定だけしかしませんから、大した作業でも難しい話でもない。

　今はオペレータという仕事が少なくなっているのかも知りませんけど、昔は本当に達人のオペレータさんが派遣であちこちの会社を渡り歩いていた。会社毎に入力方法が違うので、見た目が洗練された入力方法を考えるより、あらゆる入力をサポートする方がメリットがある。つまり、エクセルと同じように、入力中は入力されたままを表示しておき、入力が確定するときに、補完、エラーチェック、表示の整形を行えばいい。つまり、キーイベントなど使う必要はないのです。

　年月まで補完したり、違う入力方法をサポートしたりしたら混乱する。って批判されることはあります。

　がしかし、デファクトスタンダードのエクセルで「混乱して日付入力ができない」っていう人をわたしは見たことがないですし、会話で日付を話すとき、いちいち年月をつけて話すような人とも会ったことがない。もちろん、わたしのお客様ではそのような機能を入れたことはありますけれど、混乱して入力できないというのは聞いたことがない。

　例えば、今が2010年2月25日として、「3日に飲みに行きましょう」って言われれば、2010年3月3日しかないですし、「これいつの売上伝票？」「3日のです」って言われれば、常識的には2010年2月3日のことです。（先付けで売上を立てることはなくはないけれど、そういうイレギュラーなときには、会話でも月を付けて話さないと話は通りませんね）普通の人は、会話では判断できるでしょう。あくまでも、「省略しなければならない」ではなく、「省略できる」ですから、省略したくない人はフル桁入力すればよい。会話でできるレベルは自動で判断すりゃいいのです。

　共通部品にするのでコーディング量は変わらない。それでも、文句をいうのは、技術者か、情報システム部の人です。情報システム部は、問い合わせがあったときにいろんな方法があるのは生理的にイヤらしいのですが、「そんなところ誰も質問してけーへん！」って。

　ですから、何もいわれなくても、「それぐらい共通仕様に盛り込めよ」って思うのです。

　逆に、アニメーションなどの懲り方には納得できないのね。エクセル97（95だったかな？）をインストールしてイルカが出たときには激しい怒りを覚えたモンだ。「こんな下らんリソース食うだけの糞機能削って安くしろ！」って冗談抜きでディスプレイ割りかけたモンね、CRTで良かったよ（鳴き声が入っていることを後から知って、もう一回……）。

　多分、わたしの考え方が古いんだろう。つまり、達人のオペレータさんというのは、昔は手書きの伝票が回ってきてそれを入力していたような人達で、入力機能はそういうオペレータさんに最適化した考え方が染みついているわけです。最近は専属のオペレータさんがいないことの方が多いので、「まぁ、見た目でもイイか」と極力いわなくしている（ウソ、多分、ぶつくさ言ってる）。

◇　　　　◇　　　　◇　　　　◇

　雑感でした。