0030 号 巻頭言
コード生成を考える
Rubyist Magazine 第 30 号をお届けする。
今号は、全国的には「るりま」での活動、関西方面では Ruby 関西での活躍で知られる okkez さんを、yhara さんがインタビュアーとなってインタビューした「Rubyist Hotlinks 【第 24 回】 okkez さん」、全国各地で開催されている地域Ruby会議の模様をそれぞれお届けするRegionalRubyKaigi レポート (13) 札幌 Ruby 会議 02、RegionalRubyKaigi レポート (14) 東京 Ruby 会議 03、さらにRegionalRubyKaigi レポート (15) 仙台 Ruby 会議 02、出版社のご好意でお届けする0030 号 読者プレゼント、そしてRuby 関連ニュースにRuby 関連イベントとなっている。
Jack Herrington『Code Generation in Action』(Manning) という書籍がある。コード生成によるソフトウェア開発のための本だ。
出版されたのは 2003 年、いわゆる「before Rails」時代の Ruby 書籍である。日本ならともかく、海外であればまだまだ Ruby が「知る人ぞ知る」言語だった時代の本だ。貴重な海外 Ruby 書籍でもあり、比較的記憶に残っている。
特徴的だったことは、本の紹介の中でも明示的に Ruby のことがうたわれていないことだった。コード生成は生成される側の言語が重要であるため、生成用の言語は（本の営業上では）あまり重要ではない、と判断されたのかもしれない。とはいえ、実際には ERb や REXML が駆使される、こてこてに Ruby な本であった（らしい）。ある意味で Ruby の普及を印象づける本でもあったため、感慨深いものがあった。
初期の Ruby の使われ方としては、とりわけビジネス面において、コード生成は比較的多い用途だったと記憶している。もともと納品されるコードの開発言語は自由に選べない場合が多く、例えば Java なり C なりで開発を行っている場合、そのまま Ruby を活用することは難しいことが多いのは容易に推測できる。
一方で、開発の短縮化・効率化などのために何かしらのコード生成を行う需要はそれなりにあったようで、そのような場合であれば使用する言語も制約はゆるい。 コード生成目的であれば、テンプレートエンジン的なものを中心にしつつもはみ出すような気の利いた機能が簡潔に記述できるスクリプト言語は有利だった。 そこで Ruby ですよ、というわけである。さらにコード生成においては、ターゲット言語と生成用言語が文法的に異なっている方が、一読してどちらのコードなのか明快になりやすい、という利点もある。
もっとも、当時のコード生成は便利なツールの一つとして使われており、あくまでも補助的な位置づけだった。そんなコード生成は、2005 年以降、とりわけ Web 開発の現場では無視できないものとして改めて脚光を浴びる。その価値が「再発見」された、と言ってもよいかもしれない。言わずと知れた、Ruby on Rails における、scaffold を筆頭とする script/generate スクリプトの活用である。Rails 以後に生まれた Web アプリケーションフレームワークは、多かれ少なかれ Rails の影響を受けているものが少なくないが、とりわけコード生成は広く影響を与えた技術の一つと言っていいだろう。
もちろん、例えば関数型プログラミング方面からは、そのようなことは 50 年前の昔から延々行われており、今でもめずらしくない、と言われるかもしれない。都度都度スクリプトをファイルとして生成することもなく、高階関数を駆使して動的にコード生成を行う立場から見ると、むしろ退化したようにも感じられる。とはいえ、暗黙の内にコードが増えるよりもファイルとして陽に見やすい形で生成された方がふつうの人には読みやすいのは確かであり（同じく動的生成をも駆使する Rails のコードは一定限度を超えるとその挙動を追いかけるのが困難になることもある）、また生成されたコードを使う際、そのファイルに手で修正を加えることも、「足場」的なコードではさして問題になりづらい。お互い言語の特性を生かした利用方法ではあると思う。
前振りが長くなったが、iPhone OS SDK 4.0 のライセンスが改訂された。その中で、開発言語についての制限が新たに加えられたことが話題になった。
http://www.macotakara.jp/blog/index.php?ID=7488
これは、上記に書かれていたようなコード生成に制限を加える（あるいは禁止する）ことを示しているように読める。つまり、iPhone でのアプリケーション開発において、上記のような振る舞いは避けるべきことであることを示しているように読める。
私自身は日和見主義的なので、iPhone も Mac も仕事上必要であれば使うのは特にためらわないのだが、だからといってライセンスの文言に批判的な言動を差し控える必要性も特に感じない。むしろ、これまでフリーソフトウェアが歩んできた苦難の道程を考えると、発言をためらうことの方がよほどリスクの高い振る舞いであるように思う。
コード生成はプログラマであればいざというときのために身につけておくべき、重要なスキルの一つである。そのため、それを否定しようとするライセンスは、批判に値するものだと思っている。ソフトウェア開発者がよいスキルを身につける際に障害となるものだからである。もちろん Apple がそのような意図を持ってライセンスを変更したのではないのかもしれないが、コード生成を、例えばリバースエンジニアリングと同様、グレーな技術であることを一般的にも後押ししかねないことだと思っている。
iPhone OS SDK のライセンスについては、これ以外にも開発者にとっての自由な立場からの批判が多々あると思われるが、ここでは一点に絞って言及してみた。
iPhone は様々な意味で優れたプラットフォームであり、現在のソフトウェア開発者にとっては、iPhone または同様のスマートフォンに触れることは強く推奨されることだと思っている。そこから学ぶべきものは多く、その経験を元にして、よりよいソフトウェアを開発することはソフトウェア開発者として褒められこそすれ、非難される振る舞いではない。
しかしながら、このプラットフォームのための開発を行う際には、SDK のライセンスを読み、それによって得られるものと、失われるものに思いをめぐらせるべきだと思う。
そしてソフトウェア開発者として、私たちや私たちの周囲の人々、もっと言うとこの世界の現在と未来の為に、私たちはどのように振舞うべきなのか、少しの間でもよいので、時間を割いて考えてみてもらえるとうれしい。
(るびま編集長 高橋征義)