MOSA Multi-OS Software Artists

目次

• りんご味Ruby　　　　　　　　　第39回　　藤本 尚邦
• 藤本裕之のプログラミング夜話　　　#152
• 高橋真人の「プログラミング指南」　　第150回

りんご味Ruby　　　第39回　　藤本 尚邦

真偽値アクセッサを宣言するための疑似構文 attr_predicate のオープンクラスによる実装:

--------------------------------------- attr_predicate.rb ---
Module.class_eval do
 def attr_predicate(*names)
   names.each do |name|
     define_method("#{name}?") do
       instance_variable_get("@#{name}") ? true : false
     end
   end
 end
 private :attr_predicate
end
----

のうち、前回は、クラスやモジュールの定義を追加・変更するためのメソッドであるModule#class_eval (別名module_eval) と、メソッドをプライベート宣言するためのメソッド Module#private について説明しました。今回は、attr_predicate の定義の中身を見ていきます。

■ 可変長引数

Rubyでは、def構文によるメソッド定義の仮引数に、可変長引数を含めることができます。attr_predicate の定義:

 def attr_predicate(*names)
   names.each { |name| name のアクセッサを定義する }
 end

この仮引数 names のように、仮引数の名前の前に `*’ を付けると、その引数は可変長引数(呼び出された時に初めて引数の数が決まる引数)を意味するようになります。メソッドが呼び出され実行されるとき、可変長引数には、複数の実引数の値が入った配列オブジェクトが渡されます。

可変長引数は、メソッド定義の仮引数リストの中で、通常の仮引数の並びの最後に1つだけ含めることができます。例えば:

 def foo(a0, a1, *rest)
   p a0, a1, rest
 end

の場合、fooは2つ以上の引数をとり、3つめ以降の値は、rest に配列として入れられます:

　$ irb --simple-prompt
　>> def foo(a0, a1, *rest) p a0, a1, rest end
　=> nil
　>> foo(11, 22, 33, 44)
　11
　22
　[33, 44]
　=> nil

attr_predicate を使って:

 attr_predicate :done, :important

と真偽値アクセッサを宣言した場合には、attr_predicate が呼び出されたときに実引数の names には

 [ :done, :important ]

つまり宣言されたアクセッサ名2つを要素に持つ配列がセットされて、それぞれのアクセッサ名について、アクセッサメソッドを定義することになります。

■ define_method によるメソッドの動的な定義

 define_method("#{name}?") { `name?'アクセッサの実装 }

Module#define_method は、そのクラス(モジュール)のインスタンスメソッドを定義するためのメソッドです。通常、メソッドの定義に用いられる def 構文(疑似ではなく本物の構文です)との違いは、メソッドの名前や実装の手続きそのものを決めなければいけないのはいつか？というところにあります。

・def構文では       → プログラムコードを書いたときに決まる
・define_methodでは → 実行中、define_methodが呼ばれたときに決まる

もし、真偽値アクセッサの定義をすべてをプログラムコードに直接記述するのであれば、以下のようにどちらを使っても大差ありません。

# def構文を使って定義
 def done?
   @done ? true : false
 end

 # define_methodを使って定義
 define_method "done?" do
   @done ? true : false
 end

ですが、attr_predicate の実装では、define_method が呼び出されたときに、変数 name の値を文字列化してその末尾に `?’ を付けた文字列を生成して、それをアクセッサメソッド名として渡しているわけです。

def構文では、メソッド名を文字列で指定するようなことはできないので:

 names.each do |name|   # アクセッサ名が初めてわかる
   def "#{name}?"       # `?'付きアクセッサ名を生成 → 構文エラー
     ...
   end
 end

と書くことはできないのですが、define_methodを使うと:

 names.each do |name|                   # アクセッサ名が初めてわかる
   define_method "#{name}?" do          # `?'付きアクセッサ名を生成
     instance_variable_get("@#{name}") ? true : false
   end
 end

のように書くことが可能なわけです。

■ インスタンス変数の値の読み書き

インスタンス変数の値の読み書きをするためのメソッドとして以下の2つがあります:

 instance_variable_get(インスタンス変数名)           # => 現在の値
 instance_variable_set(インスタンス変数名、新しい値) #    値を変更する

アクセッサメソッドの実装手続き本体は:

@done ? true : false     # インスタンス変数の真偽により
                          # trueかfalseを返す

というようなコードになるでしょう。ところが、attr_predicate 自体の実装を書いているとき、肝心なインスタンス変数の名前はわかりません。メソッド名の場合と同様、それがわかるのは attr_predicate によってアクセッサが宣言されたとき、つまり attr_predicate が呼ばれたときです。なので:

 instance_variable_get("@#{name}") ? true : false

のように instance_variable_get を使い、変数nameの値を元にして、インスタンス変数の値を取得しているのです。

藤本裕之のプログラミング夜話　#152

　かなり遅くなってしまったが明けましておめでとうござる。年末から年明けにかけて、派遣切りだの年越し派遣村だの、明日は我が身というか一寸先は闇というか、身につまされる話題てんこ盛りでおめでとうもないもんだが。え、オレたちはホームレスでもなければそうなる可能性があるハケンですらない。2009年、行く手には明るい未来が待っているのだお前と一緒にするなって？

　いや一応オレとてホームレスでもなければただいま現在ハケン社員でもないんだが、昨今話題の派遣労働という問題、われわれプログラマという職業の者が来し方行く末を考える上で避けて通れぬハナシなのである。

　突然メタな話をはじめるが、昨年1年、この場で埒もないことを書かせていただくうち、タカハシ編集長が何をオレに書かせたいかとは別に、オレがここで何を書くべきかというのがだんだん明確になってきたのである。

　前にも一度書いたと思うが、当初タカハシ編集長がオレに提示したテーマは「アプリケーション・プログラマは絶滅危惧種なのか？」というもんだった。これに応えるつもりでオレは、オレの頭のなかにいる「アプリケーション・プログラマ」という存在が現在のコンピュータシーンで生きていけるのかという問いに対し、手がかりになりそうなコトガラを思いつくままに調べ、考え、こ
こに開陳してきた。

　そうして1年が経ち、ようやく気がついたのは、これが「アプリケーション・プログラマ」という、その他の「プログラマ」との境界線がとっても曖昧な存在に固有の問題ではなく、より一般的な「プログラマ」という存在全般に関わる問題であり、またその視点で考察しないと本質が見えてこないというコトであった。

　で、その「気づき」の契機がいわゆる「派遣切り」問題だったのね。

　一連の報道の中で耳にした（あるいは読んだ）方もおられると思うが、そもそも今回の問題は、1986年に施行された「労働者派遣法」という法律がそのハジメである。

　この法律成立以前は、江戸時代から続く「口入れ屋」（ジョージ秋山の「浮浪雲」である）的システムが産む劣悪な労働環境、暴力的な労務管理、過剰な中間搾取を防ぐため、職業安定法という法律によって派遣労働、雇用者側からいうと間接雇用になるんだが、というものは全面的に禁止されていた。

　ここで「え？」と思った人もいるのではないか？　オレがガッコを出て最初の会社に就職したのは1983年だが、その会社は明らかに今でいう「派遣」をやっていた。ただその呼び名が「出向」だっただけ、顧客企業に「出勤」し、そこでタイムカードを押してそこの上司（このヒトも別の会社からの「出向」だったりしたんだが）から指示を受けてた。

　早い話、禁止されている間接雇用を、名目だけ「業務処理請負」ということにして行っていたわけである。いや、オレもこれでした、1984年から85年までね。別に咎められないんだからそのままにしといてもよかったんぢゃないかと思うが、1986年にこの「黙認されている違法行為」を合法化するために作られたのが先の「労働者派遣法」だったのだ。

　日本が前年に「女性差別撤廃条約」てのを批准し、「男女雇用機会均等法」というのを施行したせいで、秘書とか受付嬢とかを「女性に限って」募集できなくなったためという話もあるが（ほら、ハケンなら派遣会社に「女性が欲しいんです」っていうのは違法ぢゃないわけ）、ホントかどうかはわからない。

　とにかくこの1986年の「労働者派遣法」により天下晴れて「派遣が可能」になった業種の一つが（当初は全部で13の職種しか認められていなかった）、われわれ「コンピュータ関係職」であり、それには「専門性が強くかつ一時的に人材が必要となる職種であるから」という理由付けがされていた。

　いっすか、もう一度書くよ。「専門性が強くかつ一時的に人材が必要となる職種であるから」われわれコンピュータ技術者は「派遣になれる」コトになったのである。この、まるで「派遣になれる」のが立派なコトみたいだったという事実をよーく噛みしめつつ次回を待て。
（以下次回　2009_01_16）　

高橋真人の「プログラミング指南」第150回

これから始めようとする人へ(1)

　皆さんこんにちは、高橋真人です。
　さて、昨年からこの連載では、「新年の最初は新年にふさわしく」ということで、この連載の初心に立ち戻ってプログラミングの初心者・入門者の方々に向けた“道案内”の記事をお送りすることにしています。
　今年は、新年に当たって新たにMacのプログラミングに挑戦してみようと考える皆さんにお送りする「Macプログラミングの道案内」です。

　昨年は、日本でのiPhoneの登場と、ネイティブアプリ開発のためのSDKが登場したという私たちにとって大きな出来事があったため、MOSAにおいてもたくさんの“初めて”のあった年でした。そんな中、私が以前から関心を向けてきたプログラミングの入門者／初心者の層においてもiPhoneの影響は表れていたようです。
　私の参加したMOSAのイベント等で、「これからiPhoneの開発をやってみようと思う」とか「最近Mac上での開発を始めた」とおっしゃる方に数多く出会い、お話しする機会を得ましたが、そんな方々は大体以下の二つに分類できたのです。

・他の環境で既にプロとしてやってきている方
・今まではプログラミングに興味を抱いたことがなかった方

　これらのパターンの方が以前はいらっしゃらなかったというわけでは決してないのですが、昨年は特にこれらの方々が多く目立ったのです。これは、今までは余り見られなかった傾向です。
　さて、この二つのパターンのうちの前者ですが、“他の環境でプロとして”という方々は、さらにゲーム系とWeb系とに分けることができました。
　ゲームプログラマーの方は、開発環境としては主にWindowsということでしたが、そもそもゲームの場合、対象となるマシンの能力を極限まで引き出すような開発を要求されることも少なくないので、たとえ「Macはよく分からない」と言われていたとしても、それはあくまで「使い方が分からない」という程度の話であり、おおよそ初心者／入門者の分類に入れられるものではありま
せん。
　それに対してもう一方のWeb系プログラマーの場合は、少し事情が異なります。数多く手がけている案件のうちの一つがWebの仕事であるとか、過去に様々な開発を経験してきて、今はたまたま流れでWebの仕事をしているという方を除くと、Web開発者と言われる方の多くが、スクリプト言語のみの経験しかないようなのです。

　スクリプト言語というと、MacではAppleScriptを最初に思い浮かべる方もいらっしゃるでしょうが、Web系において真っ先に出てくるのはPHPでしょう。後は、今やAJAXになくてはならないJavaScriptと、Ruby on RailsでおなじみのRubyといったところが、現在のWeb系開発に用いられるスクリプト言語だと思われます。
　インターネットが一般化する以前には、スクリプトというのはマクロの一種といった位置付けで、UNIX界隈でこそPerlの登場により、スクリプトの可能性が飛躍的に高まったとはいえ、基本的には補助的な役割を担っていたと思います。
　WebにおいてCGIという仕組みが登場してからは数多くのCGIがPerlで書かれましたが、「Perlはインターネットの世界でのグルー言語」と言われていたように、あくまでそれは“糊付け”をするための補助的な役割だったのです。
　しかし、Webにおける動的な処理への要求が高まってくるにつれ、CGIでは賄い切れない高度で複雑な処理に対するニーズから、Webアプリケーションと呼ばれるカテゴリーが現れました。これの元祖がWebObjectsであることは皆さんご存じの通りです。
　このWebアプリケーションという仕組みは、Javaという、登場時にマルチプラットフォームを標榜していたものの、当時は中途半端な立場に甘んじていた言語／技術にとって非常に適した分野だったようで、Webアプリケーションと呼ばれるもののほとんどがJavaで書かれるようになりました。WebObjectsもバージョン5.0からJavaで全面的に書き換えたほどです。（スタート時は
Objective-Cでした）

　しかし、Webがこの世に登場したころの設計意図を大きく踏み越えて巨大化、多様化、高機能化していくにつれ、Javaも巨大化、複雑化することを余儀なくされました。それは大掛かりなWebシステムを構築するためには避けられない進化の道だったのかもしれませんが、同時に、Javaという技術への新規参入者にとっての敷居を高くして行ったことも事実です。それは、登場時に「複
雑化したC++からの複雑な部分を取り除いてシンプルにした」と言っていたJavaにとっては皮肉なことのように感じます。
　そうした中、「すべてのWebシステムが巨大化・複雑化したわけでもないのだから、Javaを使わなくてもWebアプリケーションは作れるだろう」と登場したのがRuby on Rails（以下RoR）に代表されるスクリプト系のWebアプリケーションです。RoRの成功により、Javaとは別の路線でずっと使われ続けてきたPHPなども含めて、スクリプト系のWeb開発というのが、世の中の一画を築くようになってきたのだと思います。

　ところでスクリプト言語は、ネイティブ系の言語に比べると処理速度においてどうしてもハンディがあります。しかし、実行時に動的に命令を与えられるとか、豊富かつ使いやすい機能が最初から備わっているなどの利点もあって、習得も比較的容易なことから、一般にネイティブ系の言語に比べて敷居が低いと言われています。特に、メモリの管理に関しては実行環境が面倒を見てくれ
ることもあって、その意味でも“気軽に”取り組める開発環境と言えます。
　ですから、速度の面でハンディを背負っていたとしても、それに引き換えて余りあると判断した人たちからは選択肢として充分に意識される位置付けにあるというのが、今のスクリプト系の開発環境です。
　しかしながら、ことiPhoneを対象に考えた場合、マシンの能力が非力である以前に、現在のiPhoneでは一切の処理系が動作しませんから、JavaScriptで書いたコードをWeb経由で動かすというのでもない限り、今のiPhoneでスクリプト言語の出る余地はありません。
　さて、このような状況において、スクリプト系の開発者がiPhoneの開発に取り組むにはどのようなアプローチがよいのでしょうか？　また、今まで全くプログラミング的なものにかかわってこなかった人にとって、新たにMacやiPhoneの開発を学ぼうとする場合、どのような手順で進んで行くのがよいのでしょうか？

　次回は、その辺をさらに解説していきたいと思います。

◇MOSAからのお知らせと編集後記は割愛します◇