人気ブログ、Life is beautifulの著者である中島氏が、『プログラミングは「教わる」ものか、「学ぶ」ものか？』というお題に対して回答を述べている。回答の要旨はこうだ。

わたしの答えは、「“教わる”のではなく“学ぶ”もの」です。

わたし自身が、独学でやってきましたから。高校生のころ、『TK-80』を組み立てて初めてプログラムを書くようになってからずっとです。大学ではプログラミングを“教わる”授業も受けましたが、残念ながら仕事には何も役に立ちませんでした。

社会人になってMicrosoftでWindowsの開発にかかわった時も、まずやったのはひたすらソースコードを読む作業。誰かにプログラミングを教わったという記憶がありません。

正直なところ、この回答には異論があるし、これからコンピュータについて学ぼうとする人にとっても弊害があるように思うので、今日はそのことについて語ろうと思う。

続きを読む ≫

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

ダウンロードページ

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

HTML+Javascriptというマークアップ言語とスクリプト言語を組み合わせたスタイルは多くの人に慣れ親しまれたものであるが、全てのGUIに関する問題をHTML+JavascriptもしくはXAMLのような発展系で解決できるわけではないだろう。特にデジタルサイネージのようなインタラクティブな操作が多く用いられるアプリケーションでは、KSCSの開発効率が圧倒的に有利である。ぜひ適材適所で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("画像1"){
 Bs{
 #child?="_gazo"
 }
 }
 Rb("文章1"){
 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」という風に、要素名に対して数字がついている部分。これは現在の枠の分割比を設定するのである。これにより、縦横の分割であればかなり自由なレイアウト設計が可能になる。

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



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

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


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


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

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

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


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

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

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

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

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

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

dankogai氏のブログでバイナリデータとテキストデータの違いについて論じられているので、オトコ的にも少しコメントを加えてみたい。

バイナリーとテキストの本当の違い、それは「終わり」にある。
・「終わり」がはじめにわかるのが、バイナリー。
・「終わり」が来るまで「終わらない」のが、テキスト。
本質的な違いは、これだけである。

果たしてそうだろうか。

続きを読む ≫

DevMeetingで感じたことなのだが、MySQLの開発者にあまり若い人は居ない。日本では「プログラマ35歳定年説」などという俗説がまことしやかに囁かれているが、逆に35歳以下のプログラマを見つける方が難しいという様相である。かのJim Starkey氏などは60歳の手前であるが、今でも現役でプログラムをガンガン書いている。（正直言って驚異的ですらある。。。）

続きを読む ≫

Linuxシステムプログラミング



Robert Love (著)

Linuxにおけるシステムコールやglibc関数群の使い方について分かりやすく説明してくれる本。Linuxがユーザアプリケーションに提供するサービスがどのようなものかを理解するのに役立つ。初心者から熟練者まで幅広い読者層におすすめ。特にLinuxプログラマにとっては必読の本であると言える。

古典的なUNIXのインターフェイス、そしてLinuxによる独自拡張、POSIXで定義されている高度なインターフェイスの比較がおもしろく、すっきりとまとめてくれていて分かりやすい。復習にももってこいの一冊！！

DTraceで何かをトレースするときはProbe名を限定してヒットするProbeを減らすべし！述語(predicates)による条件判定のみで解決しようとしてはいけない。さもなくば、トレースする対象のプログラムがスローダウンしてしまうことだろう。

努々次のようなDプログラムを書いてはならない。

続きを読む ≫

予てから手を着けようと思っていたApacheのデータベースコネクション管理モジュールであるmod_dbdの中身を覗いてみた。これはApache 2.1から（2.1はスキップされたので実質は2.2から）導入されたモジュールで、データベースのコネクションを管理してくれる。誰のために管理してくれるのか？それは他のモジュールのためにである。実は自分で作成したCGI等のWebアプリケーションがmod_dbdを明示的に使用することは出来ない。mod_dbdの機能を使用するのはApacheにロードされた他のモジュールである。例えばmod_authn_dbdやPHPなどが使うことになる。なので、通常はApacheにロードされたモジュールが適宜使用してくれるので、あまり意識することなくその恩恵に与ることになる。そして殆どの人にとってはApacheモジュールを開発する機会がないだろうから、mod_dbdを使って開発をする機会もあまりないだろう。

続きを読む ≫