漢(オトコ)のコンピュータ道

2009-08-25

KSCSデモ版

先日紹介したKSCSがプライベートβからパブリックβへ変更され、Web上からダウンロードが可能になった。興味のある方は是非試して見て欲しい。

ダウンロードページ

KSCSについて記載してから、KSCSはXAMLやCurlとはどう違うの？ということをたまに聞かれるのだが、KSCSはXAMLなどとは根本的に異なる。XAMLがベースとしているのはあくまでもテキストのマークアップであり、KSCSはレイアウト（領域≒枠）が主体となっている点が大きく異なる。枠の比率を設定しておけば、フォントサイズなどは画面の大きさから自動的に調整してくれるのもKSCSの持つ大きな特徴である。

HTML+Javascriptというマークアップ言語とスクリプト言語を組み合わせたスタイルは多くの人に慣れ親しまれたものであるが、全てのGUIに関する問題をHTML+JavascriptもしくはXAMLのような発展系で解決できるわけではないだろう。特にデジタルサイネージのようなインタラクティブな操作が多く用いられるアプリケーションでは、KSCSの開発効率が圧倒的に有利である。ぜひ適材適所でKSCSも使ってみて頂きたい。

MySQLパフォチュー資料

ちょっと古い話になるが、先々月に松信氏と一緒にMySQLのパフォーマンスチューニングのセミナーを行ったときのホワイトペーパーがダウンロードできる（要登録）ので、もし興味のある方はこちらからどうぞ。インタビュー記事（宣伝だけどね！）もぜひご一読を。

http://www.itmedia.co.jp/enterprise/articles/0906/29/news003.html

なぜ直ぐにブログで宣伝しなかったのか？という理由は、マーケの人に止められていたから。

オトコの理想国家

もうすぐ第45回衆議院議員総選挙の投票日である。選挙が近づいてくるといつも考えるのだが、「自分が考える理想の国家と現在の国家があまりにもかけ離れている」と。特にITに関して各党が掲げる政策があまりにも残念で、「ここに投票したいんだ！」というような政党が見あたらないのでちょっとツマラナイのである。（だからといって選挙に行かないわけではないのだが。）というわけで、今日は「こんな公約してくれれば票をバッカンスッカン入れちゃうよ！（俺が持ってるのは1票だけだけどね！）」という政策案（≒妄想）について語ってみようと思う。

完全電子マネー化

世の中が全て電子マネーになればどれだけ便利になるだろうか。コンビニで釣り銭として小銭をたくさん貰って財布がふくらんでしまうこともなくなるし、自動販売機でジュースを買うのに小銭を用意する手間も省けるだろう。電子マネーになればどこで何を買ったかという履歴が残るだろうし、そうすれば領収書を発行してもらう必要もなければ家計簿をつける必要もない。履歴が残れば脱税も不可能であるし、確定申告も不要になるだろう。現金が手元になければ窃盗も出来ないので犯罪の減少にも繋がるだろう。

役所の窓口業務のオンライン化

引っ越しをしたときのように何か身の回りに変化があると必ず役所に行って届出をしなければならないが、結構面倒だったりする。何故ならば役所は平日しか空いてないし、早々に締まってしまうところも多い。特に多忙で残業が多いサラリーマンにとって、平日に時間を作って役所に出向くという行為自体が割と大変だったりする。役所に出向いて行わなければいけない一連の諸手続が全てオンラインで出来ればどれほど便利だろうか。システム化すれば24時間365日利用できるだろうし、もはや役所に出向くためにわざわざ仕事を休む必要もなくなる。（休む口実が無くなって困る！という人が居るかも知れないが。。。）そもそも論であるが、住民票は日本全国共通の仕組みなので、市町村の役所ではなく国が一括して管理すれば良いのではないだろうか。

選挙の電子化

考えて見れば選挙カーほど無駄で迷惑なものはない。選挙カーは基本的に候補者の名前を連呼するだけで発信する情報量は皆無に等しいし、選挙カーが走行するための燃費や運転手の人件費だってバカにならないだろう。そして何より選挙カーは五月蠅くて迷惑な存在であり、そのようなものは一刻も早く禁止するべきであると思う。その代わりにインターネットを利用した選挙活動を認めるのがいい。そうすれば、各候補者（ないしは政党）がどのような政策を謳っているかも分かり易いし、何より選挙期間中静かになる。投票もオンラインで出来るようにするべきである。

国会の電子化

国会が格式張っていて非効率だと感じるのは俺だけだろうか。誰が何を言ってるのか把握しづらいし、法案の審議にもやたらと時間がかかる。牛歩戦術などは非効率性の象徴であるが、とにかく国会の決議は進まない、決まらない、既定路線のものだけすんなり決まるといった印象がある。国会議員たるもの普段からよく各法案についてはよく理解して、どの法案に対して賛成または反対すべきかなどということは即答できてしかるべきなので、投票に要する時間などは5分もあれば十分なはずである。決議はすべて押しボタン式投票にするべきだし、誰がどの決議においてどのような判断をしたかということは全て履歴をとってウェブ上で公開するべきである。（そうすれば次の選挙の時に投票するための判断基準になろう。）さらに議事進行においても、プロジェクト管理ソフトウェアを駆使して優先順位の高いものから順に話合うようにするなどの工夫が欲しいところで、さらに欲を言えば議論する内容については事前に十分に内容を吟味し、国会では賛成か反対かという意思表示だけをするところまで煮詰めておいてくれれば国会で審議される法案の数が劇的に増えることだろう。その結果、国民の生活は豊かで便利になるだろう。

裁判の電子化

国会の審議以上に時間がかかるのが裁判である。裁判もオンライン化すれば良い。そうすればわざわざ裁判所に出向く必要がなくなるし、裁判官が類似の事例を即座に検索できるような支援機能を利用すれば判決のスピードアップが図れるだろう。さらに裁判員が出廷しなくてよくなればパーフェクトである。

ETCの義務化

個人的に、民主党の「高速道路無料化」には反対である。むしろ堀江氏（ホリエモン）が言うように戦略的な価格付けをして渋滞を緩和するべきだと思う。冒頭で述べた電子マネー化にも繋がるが、料金を徴収するならクルマにはETCを義務化するべきである。料金所における渋滞は、ETCを完全義務化することである程度防げるからである。

著作権の再考

現在の著作権は保護され過ぎだと思う。とにかく著作物の扱いは不便で仕方がない。特にDRMというものは最悪で、「楽曲を購入しても自分のお気に入りのプレイヤーで聴くことが出来ない！」とか「携帯電話の着信音に設定できない！」という事態が生じてしまうので購買意欲も削がれてしまう始末である。地デジも不便だ。コピーが1回までだろうが9回までだろうが10回までだろうが同じことで、自由にコピーが出来ないデータというものは至極扱いづらい。我々国民はそのように不便を生じさせること≒DRMに対しては断固としてNo!というべきである。

著作権の全てを否定するわけではないが、現在はあまりにも保護され過ぎているのが問題である。著作者の死後70年も保護されるような権利とは一体何か？死後も保護されるのは何のためか？誰が幸せになるのか？今この瞬間に生きている国民はそれで幸せになれるのか？確かにミッキーマウスのようなキャラクターが真似されてしまっては、ディズニーのビジネスが成り立たないのは分かるし、夏目漱石の著作物は全て著作権が失効しているからと言って誰かが「我が輩は猫であるは自分が書きました」と偽ることは許されない。つまり何が言いたいかというと、著作物を保護するというコンセプトの全てを無効にするべきではないということである。

ただし著作物に纏わる権利には色々あって、それらを一緒くたにしてしまっているために種々の不便や問題が生じているのだと俺は思う。著作権という巨大な権利をもっと細分化して、例えば次のような権利ごとにそれぞれ期限を設けてはどうだろうか。

クレジット表示（誰が作成したかということを示す権利）・・・永遠に執行しない
キャラクターを利用する権利・・・商標法で長期間保護
映画や音楽を商業利用する権利・・・著作物が登録されてから5年〜10年
私的に利用する範囲でコピーする権利・・・自由！

商業的に投資を回収するのに十分な期間だけ著作権を認めるようにしておけば、著作者側も困らないし利用する消費者側も不便さを感じなくて済むだろう。

GPLないしはOSSの利用

政府の様々な仕組みを電子化するとなると、それはそれは大がかりなソフトウェアが必要になるだろう。しかし、現行の体制ではシステムを構築する時の一時的な価格優位性によってベンダーが決められてしまうが、それは時としてベンダーロックインという問題に直面してしまう危険性を孕んでいる。ベンダーにひとたびロックインされてしまうと、システムをメンテナンスしたり再構築する場合に他のベンダーへ切り換えるのに莫大な費用が必要になってしまう。プロプラエタリなソフトウェアは最悪で、ベンダー側がどのように危険なバックドアを仕掛けていてもユーザー側にはそれに気づくための手段がない。例えユーザーが国家であったとしても！だ。ベンダーロックインによって、国家のシステムを一ベンダーのコントロール下に置いてしまうという事態はあってはならないのである。このような危険なベンダーロックインを防ぐには、国家が調達するソフトウェアを全てGPLないしはOSSにするという決まりを作って、ソースコードごともらい受け、なおかつソースコードを一般公開してしまうのがベストである。特にGPLライセンスを利用すれば他の自治体でソフトウェアを再利用することも可能であるし、他のベンダーがそのソフトウェアを研究して改良や機能追加などを行い再利用することも可能である。国家が調達したものは国民の利益に還元されるべきなのでGPLでソフトウェアを公開するのはとても理に適っている。ソースコードが公開されていればバックドアを見付けることも出来るし、実装されたロジックを見ればどのような形式でデータが保存されているかも一目瞭然だからそのソフトウェアで作成したデータが将来に渡って安全に利用出来るということが保証される。国家がソフトウェア資産への投資を最小化し、なおかつセキュアなシステムを構築するにはベンダーロックインを避けることが出来るGPLないしはオープンソースソフトウェアでなければならないのである。

というような政策を打ち出してくれる政党があれば全力で応援するのだが、残念ながらそのような政党はまだ俺の脳内にしか存在しないのである。

2009-07-29

GUI開発におけるコロンブスの卵 - KSCS

先日、とあるUI技術がひっそりとデビューした。このUI技術 - KSCS - を手がけたコンサルタントは友人なので、以前彼の取り計らいでKSCSについて話を聞く機会があった。KSCSは「なるほど！」と唸らされるアイデアを用いていながら、デビューしたにも関わらず巷であまり話題になっていないようなので、このブログで皆さんに紹介しようと思う。

KSCSの凄いところは、ズバリその言語構造そのものである。プログラム言語の紹介と言えばやはりまずはHello Worldからだろう。というわけで以下のソースコードを見て欲しい。


K(_hello){
  U{
    R(#m,"???")
    Rb("Push"){
      Bs{
        #m?="Hello, world!";
      }
    }
  }
}

恐らくこのソースコードを見て、プログラマ諸氏は「ナンジャコリャァァァーーーッ？！」と思うのが素直な感想ではないだろうか。私も初めて見た時はさっぱりワケが分からなかった。KSCSがGUI開発のためのものであることを思い出して欲しい。このソースコードをKSCSで実行すると、次のような画面が表れる。

この画面を見ただけで、勘の良い方なら気づいただろう。そう、つまりさきほどのソースコードは画面のレイアウトそのものを示すものだったのである。Basicもアセンブリ言語もC言語もC++もJavaもPerlもRubyも様々なプログラミング言語は、そのプログラムの先頭から順番に逐次命令を実行するというのが原則である。PHPのようにページに埋め込むことを主眼に置いて設計された言語も存在するが、それでもページ内に埋め込まれた各命令文は、基本的にページの先頭から実行されるわけであり、そういった意味では他のプログラミング言語と変わりはない。

しかしKSCSは違う。ソースコードそのものが画面の要素に対応しているのであり、プログラムは完全にイベント駆動型で実行される。まさにUIのために設計された言語というわけである。ちなみに、上記のHello Worldでは、「Push」を押すと下記のように「Hello, World!」の文字が表れる。

KSCSは、各要素をごく単純な記号をツリー構造に並べるという文法を持っている。レイアウトの表現に用られる記号には、次のようなものがある。

K ... 全ての要素のroot要素。
U ... レイアウトが規定されていない要素。レイアウトのroot要素として利用される。
R ... 行を表現する要素。
Rb ... Rのボタンバージョン。
C ... 列を表現する要素。
Cb ... Cのボタンバージョン。
I ... 代入のための要素。（後述）

これらをツリー構造（入れ子）にすることにより、様々なレイアウトを表現する。例えば「U{C{RRRR}C{RR{CC}}}」という文字列の並びも、れっきとしたKSCSのソースコードである。この文字列は次のようなツリーを表現している。

このソースコードを実行しても何も表示はされないが、次のような枠を内部的に構築することになるのである。上のツリー構造と下のレイアウトを対比してみてもらいたい。

このようにレイアウトを表現しただけでは、プログラム言語であるとは言い難い。（むしろレイアウトを定義するための言語であると言えるだろう。）ではどうやってプログラミングを行うのかというと、各レイアウトの子要素の中にプログラムを記述するわけである。KSCSの各要素のひとつは、次のように表現することができる。

要素名(属性){子要素}

要素名は既に説明したK、R、Cといったもので、予め意味が定められている。

子要素にはレイアウト要素を入れることも出来るが、イベントを記述する要素を入れても良い。ボタン操作に対するイベントを記述するには、例えば次のような要素がある。

Bs ... ボタンが選択された。
Bp ... ボタンが押された。
Br ... ボタンが放された。
Bt ... マウスオーバー。

これらのイベント要素の子要素として、何を実行するかを記述するわけである。ボタンを押した時に他の要素に何らかの変化をもたらしたい（表示されているテキストを変更したい）なら、他の要素のラベルを用いてその要素の属性などを変更するわけである。例えば「#label?="this is a test!"」とすると、#labelというラベルのついた要素のテキスト属性（表示されている文字列）が変更されるといった具合である。ラベルは各要素の属性として記述する。

ここまで解説したところで、ようやく上記のHello Worldのソースコードを理解することが出来るだろう。既存のプログラム言語とあまりにも発想が違うので、頭の切り替えが必要かも知れない。しかしこの発想は凄いのではないだろうか。逐次実行する文法からレイアウト主導型の文法への切り替えというのは、言葉にしてみれば簡単であるが、それを実行に移すのは難しい。まさにコロンブスの卵である。レイアウト主導型のプログラム言語を用いることにより、GUI開発に劇的な変化がもたらされるのは容易に想像がつくだろう。まるでプレゼンでも作るような感じで、スイスイとGUIプログラムが開発出来てしまうのである。

上記の例はごく簡単なものなので、KSCSによる開発がどういったものかというイメージがあまり実感できないかも知れないので、もう少しだけ複雑な例を紹介する。（複雑なアプリケーションを開発したければ、それだけプログラムを大規模化すれば良い。）

以下がそのテストアプリケーションの初期画面である。

で、これがソースコード。


K(_test2){
  U(#top,@s1){
    C{
      R
      Rb("画像１"){
        Bs{
          #child?="_gazo"
        }
      }
      Rb("文章１"){
        Bs{
          #child?="_bunsho"
        }
      }
      Rb("入れ子"){
        Bs{
          #child?="_test2"
        }
      }
      Rb("クリア"){
        Bs{
          #child?="";
        }
      }
      R5
      Rb("終了"){
        Bs{
          E(_quit);
        }
      }
    }
    C6{
      R("タイトル")
      R8{
        I(#child)
      }
    }
  }
}

K(_bunsho){
  U("Hello, World!")
}

K(_gazo){
  U{
    C(img="Winter.jpg")
  }
}

まず注目して頂きたいのが「C6」や「R8」という風に、要素名に対して数字がついている部分。これは現在の枠の分割比を設定するのである。これにより、縦横の分割であればかなり自由なレイアウト設計が可能になる。

このプログラムは、ボタンを押すと余白の部分にいろいろなオブジェクトが表示されるという、至極単純なものである。「文章１」を押すと、先ほどと同じように文章が表示される。

この例で先ほどと違うのは、I要素の子要素として他のツリーを代入していることである。KSCSのソースコードは生け垣構造になっていて、K要素をいくつも定義することが出来る。それをそのまま現在表示されているレイアウトの子要素として利用出来るのである。

次は画像の例。画像の表示も至って簡単だ。

これは自分自身を子要素にした例。

KSCSの最大の特徴として、解像度フリーな動的レイアウトというものがある。レイアウトの分割方法とか比率を前述の文法に従って決めておくと、文字のフォントやボタンのサイズなどを自動的に決めてくれるのである。従って、自分自身を子要素にしたときには、与えられた領域に対して自動的に大きさを調整して自分自身を再描画するわけである。無限ループか？！と思われるかも知れないが、描画が出来ないぐらい各要素が小さくなると、KSCSはループを停止するので心配は無用である。

一般的なGUI開発において、レイアウトの設計はかなり手間のかかる作業である。一カ所を変更すると、全体のバランスを取るためにあちこちを調整しなければならないという副作用が生じてしまったりして、変更要求があったときなどは涙目にならざるを得ない・・・。だが、KSCSは自動的にレイアウトを調整してくれるので、GUIアプリケーション開発の手間は格段に減ることになるのだ。

ちなみに、上記のように入れ子状になっている場合でも、ボタンはちゃんと動作する。以下は３階層目の「画像１」ボタンを押した時の様子。

このような開発環境がどんなものに応用できるの？というと、開発元の（株）カテナスは以下のようなものを想定しているらしい。

デジタルサイネージ
テーブルトップオーダーシステム
プレゼンテーションツール

KSCSはとにかくタッチパネルと相性が良いので、家電への組み込みなんかにも向いてるんじゃないだろうか。

KSCSは現在プライベートβの段階だそうで、開発＆実行環境は一般には公開されていない。使って見たい人は以下の問い合わせフォームから連絡してほしいとのことである。
http://www.kathenas.com/contact.html

KSCSのデモ動画（YouTube）もおいてあるので、興味のある人は是非見てみるといいだろう。

なお、上記の説明では出来るだけKSCSの専門用語を省いて解説したので、（株）カテナスのホームページを見るときには専門用語に注意して欲しい。ちなみに、KSCS上で実行出来るプログラム言語はKI言語、インタープリタはSaLaという。個人的には、これらをまとめてもっと分かり易くて親しみ易い名前にするべきじゃないかと思う。Sun Microsystemsが「Java」を名付けたときのように。

2009-07-15

Chrome OSアーキテクチャ大予想！

Chrome OSが出るぞ！というニュースを聞いたとき、ある種の衝撃が走った。というよりとても腑に落ちたと言った方がより正確に俺の心情を表しているかも知れない。そう、まるで心の鍵穴にChrome OS発表のニュースが鍵となって、今まで開くことが出来なかった心の奥底にある謎の扉を開いたような感覚だった。世間的には「ChromeブラウザがのっかったLinuxの1ディストリビューション」だという見方が趨勢であるように思うが、俺はChrome OSが断じてそのような安易で在り来たりなものとして登場するのではないと予感している。そしてまだ見ぬChrome OSにワクワクしながら、そのアーキテクチャを想像してニヤニヤしたりしているのである。まだChrome OSのアーキテクチャについては詳細が公表されていないが、以下のようなものになるんじゃーないだろうか。

この図はあくまでも個人的な予想というか妄想によるものなのでその点は了承して欲しい。公式にGoogleからChrome OSの詳細が発表されたとき「全然違うじゃないか！」となったら、笑いぐさにでもして頂ければ幸いである。

さて、この図（俺の心の中で想像しているChrome OSのアーキテクチャ）を解説しよう。

1. UIはChromeのみ。

一つ確信していることがある。それは、Chrome OSにおいてユーザーが触れることができるUIはChromeブラウザだけになるだろうということだ。Linuxだからといって、UNIXユーザーが慣れ親しんだシェルが搭載されることはないだろう。ギークなユーザーにとっては「なにー？！そんなものはLinuxではない！言語道断！！」と激高してしまう仕様かも知れないが、そもそもChrome OSはそのようなギークをターゲットにしていないだろうと思われる。全ての操作はChromeを通じて行われることになるだろう。

2. Webサーバを搭載

上記の仮説が正しければ、Chrome OSにはWebサーバが搭載されるはずである。lighttpdやApacheのような。何故かって？それは、そのコンピュータ自身を操作するためである。おそらくはコンピュータの電源を切る操作すら、ブラウザを通じて行うことになるだろうが、その場合ブラウザでクリックした操作を誰が実際に実行するのかと言えば、HTTPリクエストを処理するWebサーバーでなければいけない。コンピュータの管理や設定は、そのWebサーバー上で動くアプリケーションとして実装されることになるだろう。

3. ユーザーアプリケーションはサーバープログラム

Chrome OSはGoogleのサービスやその他Web上にあるリソースを活用するOSであるのは言うまでもない。しかし本当に全ての処理（電卓アプリのようなネットを一切必要としない）アプリケーションまで、Googleのクラウド上で実行するとしたらそれは愚かなことであり、Googleのデータセンターは大量のリクエストによって飽和してしまうことになるだろう。従って、いくらブラウザだけで操作するChrome OSとて、ローカルにアプリケーションが一切必要ないというわけではないだろう。そうすると、アプリケーションはJavascriptによって実装されるか、ローカルのWebサーバー上でWebアプリとして実装されることになるのではないだろうか。今、巷にはWebアプリを得意とするプログラマが溢れているので、彼らはきっとChrome OS用アプリの開発も活発に行ってくれるに違いない。

4. ファイル管理からの解放

おそらくここがChrome OSの最も革新的な側面になると思われるが、Chromeブラウザから自身のコンピュータ上の「ファイル」へアクセスする手段はないだろう。WindowsのExplorerのようなファイルマネージャーっぽいアプリケーションは、おそらく存在しない。そもそもであるが、静止画像や動画、音声、プレゼンテーション、文書、テキストなどの各種データを「ファイル名」で識別して、それをツリー状のファイルシステムで管理するというやり方は如何にも古典的であり、本来の人間の要求であるはずの「データを整理し、確実に保存し、必要なときに素早く検索する」ということからはかけ離れた方法であると言えよう。その代わり、Chrome OSではデータは全てデータベースへ格納され、Webサーバー上で動くアプリケーションがデータベースからの検索や保存を肩代わりしてくれることだろう。その結果、人間は「ファイル名と中身を紐付けて覚える」という無駄な行為から解放されることになる。

ここで一つ疑問が生じる。Chromeがデータベースを搭載するとしたら、どのデータベースソフトウェアを搭載するのだろうか？ということだ。これまでにGoogleがsqliteを（AndroidやGoogle Gearsなどで）採用してきたことを考えると、sqliteのような気がしなくもない。しかし、もし上記のような使い方を本気で考えるのであれば、sqliteではスケーラビリティの問題に直面することが容易に予測できる。そうするとやはり、MySQLやPostgreSQLのように大規模なデータを扱えるRDBMSを搭載して欲しいところであり、MySQLerとしてはぜひMySQLを薦めたい。もし、MySQLのライセンスがGPLv2であることがFOSS Exceptionを適用するといいだろう。そうすれば、GPLv2であるMySQLを搭載しつつ、Chrome OS全体のライセンスを例えばApache 2.0ライセンスにすることができる。

5. 強固なセキュリティ

Chrome OSでは恐らくユーザーが直接コマンドを実行することはないし、システム的にそれは出来なくなっているだろう。実際、ユーザーが起動することができるプログラムは何もなくても良い。もちろんブラウザプロセスでさえ。じゃあ誰がブラウザを起動するんだ？！と思うかも知れないが、起動するプログラムがブラウザだけで良いならば、Chrome OS自身が事前にブラウザのプロセスを起動しておけば良い。そうすれば、Chromeブラウザの実行ファイルの所有者をrootにすることによってrootだけがコマンドを実行可能に出来るように出来るし、rootが起動したChromeブラウザのプロセスは、自身が起動後にsetuid()をして実効ユーザーを切り替えれば良い。このようにすれば、ユーザー自身の手によってブラウザを起動せずともブラウザを利用することが可能になるわけである。

極端に言えば一般ユーザーは通常ファイルへのアクセス権限が一切なくても良い。（ただしブラウザはバックグランドで動くプロセスにはアクセスするかも知れない。）この場合、ブラウザがバッファオーバーフローなどによっていくらクラッキングの被害にあったとしても、クラッカーが実行出来るコマンドは存在しないので被害は最小限にとどめることが出来るだろう。クラッカーが何か悪事を働くには、さらにそこからroot権限を奪取するか、Chromeを操ってローカルのWebサーバーで動くアプリケーションにアクセスするように仕向けるかである。だが、そのような場合もローカルのWebサーバーで不正なアクセスをブロックする仕組みを実装しておけば、いくらChromeブラウザを乗っ取ったところでクラッカーは何もすることが出来ないだろう。（せいぜい他の悪事を働くための踏み台＝ボットとして利用する程度であろう。）

このように、実行可能なコマンドが存在しなければ「ウィルススキャン」という煩わしい行為から解放されることになる。なぜなら、スキャンする対象の「プログラムファイル」が一切存在しないから。

・・・

このような「Chrome OS」が本当に実装されれば、確かにGoogleが言うように「OSの再考」であると言えるだろう。こんな具合に俺の妄想は広がっているわけであるが、果たしてこの予想はどれほど当たっているのだろうか？一つだけ言える事は、もし俺の予想が当たっていたら、俺は確実にChrome OSのファンになるだろうということである。

2009-06-30

SPIDERストレージエンジンの近況など

SPIDERストレージエンジンの作者である斯波氏がブログを始められたそうだ。

Wild Growth 日本語版
http://wild-growth-ja.blogspot.com/

英語版もあるが、ここでは日本語版を紹介させて頂く。現時点で投稿されているトピックは２つ。

SPIDERストレージエンジン0.12リリース
新しいストレージエンジン「Vertical Partitioningストレージエンジン」のリリース

なんと！Vertical Partitioningとは興味深い。中身が気になる方は斯波氏のブログをチェックだ！！

というわけで更新頑張ってください。楽しみにしています！＞斯波氏

2009-06-28

オトコの近況 - ブログ停滞中のワケ

最近めっきりとブログの更新が遠のいている。

ついにネタ切れか？！

力尽きたか？！

中二病完治か？！

などという心配はしないで頂きたい。至って快調にマイペースで筆を進める毎日を送っている。ただしブログにではなくMySQL関連の書籍として。ブログは書籍の執筆が完了してから本格的に再開しようと思うので、その際にはまた是非お付き合い頂きたい。書籍も頑張って書いているので是非よろしくお願いしたい。

今書いてるのはこんな内容のものだ。原稿からプチ抜粋。

クエリキャッシュのヒット率はどのように計算すれば良いのでしょうか？ここで改めて説明するために、上の一覧ではクエリキャッシュについては敢えて省略しましたが、クエリキャッシュのヒット率は次の計算式で求めることが可能です。

Qcache_hits / (Qcache_hits + Com_select)

Qcache_hitsは文字通り、クエリキャッシュにヒットして、キャッシュからクライアントへ結果が送信された回数です。キャッシュミスが発生すると、MySQL ServerはSELECT文を実行してテーブルに対してクエリを行い、その際にCom_selectをカウントアップします。つまり、クエリキャッシュが有効になっている場合は、Com_selectがキャッシュミスをした回数を表すのです。SELECTを実行して結果を取得すると、クエリキャッシュへ結果がキャッシュされる場合と、結果セットが大きすぎる理由などによってキャッシュされない場合があります。キャッシュされた場合はQcache_insertsがカウントアップされ、されなかった場合にはQcache_not_cachedがカウントアップされます。従って、次のような関係式が成り立つでしょう。

Com_select ≒ Qcache_inserts + Qcache_not_cached

これを上記の式に代入すると、クエリキャッシュのヒット率は次のように変形することが可能です。

Qcache_hits / (Qcache_hits + Qcache_inserts + Qcache_not_cached)

Com_selectは離れた位置にあるので、Qcache_%だけを見てヒット率が判断できるこの式を用いると便利でしょう。この式ならば「SHOW GLOBAL STATUS LIKE 'Qcache%'」というコマンドでステータス変数を表示するだけで事足ります。

本のタイトルは「金利0無利息キャッシング - クエリキャッシュできます！！」ではなく（ってかそのタイトルはパクリだよ！＞俺）もっと広い範囲の内容をカバーした書籍になる予定なのでタイトルもそれに相応しいものになるだろう。タイトルは書き終えたら発表します。

書籍は書いていてもPlanet MySQLのチェックは欠かさないのが日本男児たるものの嗜みだが、ちょうど本日sh2氏による魂の籠もった検証結果報告のエントリが投稿されているので以下に紹介させて頂く。

MySQL InnoDB Pluginのデータ圧縮機能
http://d.hatena.ne.jp/sh2/20090628

InnoDB Pluginとは、MySQLに組み込まれているInnoDBを置き換えるストレージエンジンで、デフォルトのものにはない特徴を備えている。sh2氏によって検証が行われているデータ圧縮機能はInnoDB Pluginだけで使える拡張機能である。だからアナタが使ってるInnoDBでデータ圧縮が出来なくても不具合ではないので焦らないように！InnoDB Pluginを利用するには、以下のページからダウンロードしてインストールする必要があるのでチャレンジャーな人達は試して頂きたい。
http://www.innodb.com/products/innodb_plugin/download/

インストール方法はこちら。
http://www.innodb.com/doc/innodb_plugin-1.0/innodb-plugin-installation.html

sh2氏によると、Wikipediaのデータをおよそ半分に圧縮できたらしい。なんと、InnoDB Pluginを使えばデータ量が約半分になるということである。これはかなりの節約になるだろう。

ところで、とても偶然なタイミングなのだが、IBMの中の人もDB2の圧縮機能の検証をされていたようである。

ClubDB2 場外ブログ: 圧縮機能で遊んでみる
http://clubdb2.blogspot.com/2009/06/blog-post_27.html

こちらも圧縮した結果は半分程度だそうだ。

つまりInnoDB PluginとDB2 V9.xの圧縮機能は互角？！高価な商用データベースであるDB2と肩を並べるぐらいの圧縮率というのは、InnoDB Pluginの圧縮機能はかなり優秀だと言っていいのではないだろうか。

2009-06-13

MacOS XでTwitterをSkypeのムードメッセージに

最近Twitterを始めたのだが、Twitterに投稿した呟きをSkypeのムードメッセージに反映したいと思うのは、男と女が惹かれ合うがごとく自然なことだろう。ちなみに、Skypeのムードメッセージというのは、名前の横っちょに表示される短いメッセージのことだ。Skypeを利用している人ならご存じだろう。

Skypeのデフォルトの機能では、Twitterからメッセージを拾ってくることは出来ない。さてどうしたものか？とGoogle先生に聞いてみたら、既に連携している人が居るではないか。このサイトで掲載されているプログラムを動かすべく、DBusやらpkg-configやらをインストールしたり、CPANで各種Perlモジュールをインストールしまくったりして、無事にこのプログラムを動作させることが出来た。しかし動作エラーが出てSkypeのムードメッセージが変更されない。なんでかな？と思ってさらに色々調べた結果・・・気がついた。「あ、これLinux専用じゃん！」

そんなわけで一連のインストール作業は徒労に終わったわけだが、日本男児たるものその程度で諦めるようではいけない！

気を取り直してちゃんと調べたところ、Mac OS XではSkype.frameworkを使ってSkypeをコントロールすることができるということが分かった。（最初から気づけよ＞俺）このフレームワークを使って書かれたTwitter/Skype連携プログラムは存在しないようだし、ならばしょうがないからこのフレームワークを使ってプログラムを書くか！ということになるわけですな。

で、出来たプログラムがこれ↓


#!/usr/bin/ruby

require 'rubygems'
gem 'twitter'
require 'twitter'
require 'osx/cocoa'
OSX.require_framework 'Skype'

class SkypeMood < OSX::NSObject
  def clientApplicationName
    return 'Skype Mood From Twitter'
  end

  addRubyMethod_withType 'skypeAttachResponse:', 'v@:i'
  def skypeAttachResponse(status)
    return if status != 1
    puts 'Successfully connected to Skype!'
  end

  def isRunning
    return OSX::SkypeAPI.isSkypeRunning
  end

  def setDelegate appname
    OSX::SkypeAPI.setSkypeDelegate self
  end

  def setMood text
    OSX::SkypeAPI.sendSkypeCommand "SET PROFILE MOOD_TEXT #{text}"
  end
end

class AppController < OSX::NSObject
  @DEFAULT_INTERVAL = 60
  attr_accessor :sm

  def setAuth email, pass
    @httpauth = Twitter::HTTPAuth.new(email, pass)
  end

  def initTimer interval
    OSX::NSTimer::scheduledTimerWithTimeInterval_target_selector_userInfo_repeats(checkInterval(interval),self,:timerJob,nil,true)
  end

  def checkInterval interval
    return interval == 0 ? @DEFAULT_INTERVAL : interval
  end

  def timerJob
    return unless @sm.isRunning
    timeline = Twitter::Base.new(@httpauth).user_timeline
    @sm.setMood timeline[0].text
  end
end

def usage
  puts "Usage: #{$0} your.name@domain.com password [check interval]"
  exit 1
end

usage if ARGV.length < 2

sm = SkypeMood.alloc.init
OSX::SkypeAPI.setSkypeDelegate(sm)
OSX::SkypeAPI.connect

c = AppController.new
c.setAuth ARGV[0].to_s, ARGV[1].to_s
c.initTimer ARGV[2].to_s
c.sm = sm

OSX::NSRunLoop.currentRunLoop.run

即興で作ったプログラムなので、なんでRubyなの？とかエラー処理が甘いんじゃね？などという点には目をつむって頂きたい。

使い方は簡単。

1. まずはこのプログラムを/usr/local/bin/twittermood.rbなどに保存しよう。

2. コマンドを実行する。

shell> twittermood.rb メールアドレスパスワードインターバル

これらはTwitterに登録したメールアドレスとパスワードを使う。インターバルは秒単位だ。

3. Twitterに投稿する。

4. しばし待つ。

5. Skypeのムードメッセージに反映される。

6. プログラムを終了させるときはCtrl-CまたはkillコマンドでOK。

ただし、このプログラムはそのままでは利用出来ない。このプログラムで利用しているtwitter gemとSkype.frameworkをインストールする必要があるからだ。

Skype.frameworkのインストールは簡単だ。次のコマンドを使おう。

shell> sudo cp -r /Applications/Skype.app/Contents/Frameworks/* /Library/Frameworks

twitter gemは、gemコマンドでインストールすることが出来るのだが、gem自信のバージョンが1.3.1以上でないとインストール出来ないので、まずは先にgemをアップグレードしなければならない。俺のマシンでは、元々インストールされているgemは1.0.1だった。gemのアップグレードとインストールを行う一連のコマンドは次の通り。

shell> wget http://rubyforge.org/frs/download.php/57643/rubygems-1.3.4.tgz
shell> tar zxf rubygems-1.3.4.tgz
shell> cd rubygems-1.3.4
shell> sudo ruby setup.rb
shell> sudo gem install twitter

そんなわけでTwitterの投稿をSkypeムードメッセージに登録したい人はお試しあれ！

追記: 上記のプログラムのライセンスはもちろんGPLv2 or later!!

2009-06-03

そもそも日本のIT業界が残念だ。

梅田望夫氏のインタビューに対して様々な反応が上がっている。

俺に言わせてみれば、Webだけでなく日本のIT業界そのものが残念だ。

俺は、2000年に大学院を卒業してからSun Microsystemsの門を叩いた。なぜSun？という疑問は色々とあるだろうが、いずれにしても外資系が良かった。日本企業に勤める気にはならなかった。なぜか？

日本のIT業界が残念なことになっていたからだ。

周りを見渡してみよう。一体どれだけの（人気のある）コンピュータ製品が日本製だろうか。俺は今、MacBookでこのブログを書いている。組み立てはどこの国で行われたかは知らないが（たぶん台湾あたりか？）設計したのはアメリカの企業であるAppleだ。

サブマシンで使ってるLinuxは北欧の人が設計した。

最もシェアの高いOSはWindowsであり、これまたアメリカ製である。

スマートフォンのOSは、Android、iPhone OS、WM、Symbian OS、WebOSなど様々だが、いずれも海外のものだ。

今俺の本職であるデータベースだって、オープン系システムで利用されるものはほとんどが海外製のものばかりである。MySQLはスウェーデン生まれだ。

ハードウェアはどうだろう？メモリやHDDは日本製のものもあるが、花形であるCPUはIntel/AMD/VIAなど海外勢ばかりであり、GPUもnVidia/AMDとこれまた海外である。おっと・・・最近富士通が世界最速のCPUを発表したところだった。10年ぶりに。

そんなわけで、日本のIT製品・・・特に基盤となるソフトウェアは、海外発のものを輸入して利用しているのがほとんどである。俺はそれが残念でならない。

だから外資系企業に入って、日本ではなく海外の技術を学ぼうと考えたわけだ。ただし配属された部署の関係で、あまり希望するような仕事は出来ず、お世話になったSunを去ってMySQLへ転職したわけだが、どういう因果なのかまたもやSunに買い戻されてしまい、今度はそのSunが買われることになってしまった。これまた残念なストーリーである。

Webが残念なことになっているというのは、IT業界そのものの体質だと思えばそれほど不思議ではない。元々日本のIT業界は世界をリードする立場に無かったのだから、それがWebで立場が変わる方が不思議なのである。

なぜ日本のIT業界は残念なことになっているのか？社会に出て、俺なりに経験を積んできた中で思うことには、例えば次のようなことが挙げられる。

技術者の待遇がよくない。出世するには管理職にならなければならない。技術を学んでも待遇がよくならないので、技術を学ぶことに対するインセンティブが業界全体で低い。
ソフトウェアのライセンスはプロプラエタリなものばかりで、開発者がその方が良いと信じている傾向がある。実質的には経営者や営業職など、開発職以外の人達だけが得をしている。
国内市場向けの商品が大半である。特にソフトウェアでは顕著であり、日本から海外へ販売している例は少ない。Web系のサービスではもっと顕著で、殆どが国内消費向けである。
言語の壁が高い。

このように分析してみると、日本で開発されたものが世界標準になる可能性は極めて低いと考えざるを得ない。とても残念なことである。

じゃあどうすればいいか？結論だけ書くと、

ソフトウェアのライセンスはGPLにする。（1、2の問題への対策）
英語を学ぶ。（3、4の問題への対策）

というわけだ。こんな風に考えているので、俺は今のところ身を置いているわけである。今が残念ならば、少しでも良い方向へ進むよう努力すべきなのである。

日本発のもので勢いがあるものもある。例えばRubyだ。俺はRubyを猛烈に応援・支持している。松本さん、頑張ってください :)

正直言って、Webには国境はないのに、日本むけのサービスばかり展開していては勿体ないという気持ちもある。海外でもサービスを展開できればビジネスの規模も大きくなるし、Web系の企業は是非とも日本市場だけにとらわれない経営をして頂きたいものだ。

2009-06-01

あの漢（オトコ）が・・・ブログを始めた!!

現在、MySQL Performance Blogおよびその運営会社であるPerconaで活躍中の木下氏が、なんと日本語でブログを始めた。

ＤＢ改造屋雑記

木下氏はInnoDBのスペシャリストであり、おそらく実力はアジア一だろう。しかもレプリケーションなど、MySQLの他の機能に関しては、興味もないし知らないという尖った知識の持ち主である。尖ったオトコが綴るブログに期待したい。

初稿はInnoDBにおけるテーブルスペースのインポートのHackに関する内容だ。これまで、innodb_files_per_tableオプションを利用している際にできるInnoDBのテーブルスペースのインポートは、テーブルスペースIDがマッチしていないといけないなどの制約があって面倒だったが、その辺の不都合な箇所を改良して任意のテーブルスペースをインポートする機能を、彼がInnoDBからforkしたXtraDBに実装していますという内容だ。

これからもどんどんマニアックでディープな記事が投稿されることだろう。彼のブログ発進を喜びたい!!

登録: 投稿 (Atom)

ちょっと硬派なコンピュータフリークのBlogです。