2008-07-12
意味のわかるオブジェクト指向(1) プログラミング言語は、巨大なシステムを開発するために進化してきた
プログラムは書けるけどオブジェクト指向がどうもよくわからないという人に
オブジェクト指向の価値は多態性にある
ことを理解してもらうためにこの連載を書きます。このことが理解できたら、次はデザインパターンに触れて多態性がいかに役立つかわかるようになると、ものすごく理解が深まることでしょう（この連載の中でも、少しだけデザインパターンを紹介する予定です）。
連載では、ずっと昔のプログラミング言語の紹介から始めて、オブジェクト指向に向けて進化する中で何が変わったのかを解説していきます。この過程は（デザインパターンを学んでいくところまで含めて）まさに僕がプログラミングを学んできた過程そのものにほかなりません*1。自分では、自分はちょうどいい時代に生まれてちょうどいい段階からプログラミングを習得できたと感じているので、この過程を紹介する次第です。
プログラミングの初心者にとって、オブジェクト指向プログラミング（面倒くさいので、以下OOPと略そう）を取り入れた言語から学ぼうとすると、意味のわからない「おまじない」がとても多い。昔のマイコンのずっと原始的な言語でプログラミングを学んだ人の方が、自分が何を書いているのかよっぽどわかりやすかったはずだ。
※Java（OOP言語）で書いた、「こんにちは！」と表示するプログラム Class Hello{ public static void main(String[] args){ System.out.println("こんにちは！"); } }
※BASIC（原始的な手続き型言語）で書いた同内容のプログラム 10 PRINT "こんにちは！"
BASICのプログラムの意味は、「各命令行の頭には行番号を付けないといけない（上の例では「10」）」というルールさえ理解していればすぐに理解できる。それに対してJavaのプログラムは括弧がたくさんあり、行が字下げされていて、Class, Hello, public, static, void, main, String, args, System, out, とたくさん単語が並んでいる。こいつら、どういう意味？
やりたいことはprintln（これも、「ln」の意味がよくわからないけど……）だけなのに。println以外は全部おまじないだと思うしかない。これでは自分が何を打ち込んだのかもよく理解できない。
これらのおまじないの意味（と意義）を理解してもらうためのOOP講座なのだが、最も簡単なプログラムからこんなにおまじないだらけでは心がくじけてしまう。だからまず、心が折れないよう、次のことを頭に置いておいてもらいたい。
１．プログラミング言語は、巨大なシステム構築のために進化してきた
仕事としてプログラムを作る人たちも、昔はBASICのような原始的な言語で実務用のシステムを開発していた。しかし実務用の（複雑で巨大な）システムを開発していると、どうしても突き当たる問題というのがあった。それを解決するために言語の方が進化してきた結果が、おまじないだらけの現代の言語なのだ。簡単なプログラムは最初から念頭にないわけで、それが簡潔に書けないのはある意味当然のこと、と。
さて、そのプログラミング言語の進化のうち2大変革とも言える「構造化・モジュール化」と「オブジェクト指向」を順を追って見ていくことにする。それを理解することで、オブジェクト指向の意味が自然に理解できるはずだ*2。
次回：「スパゲティ・プログラム」
2008-05-04
パソコンのエラーは、本質的に難しい
PC初心者の人からよく聞かれる質問に「パソコンの出すエラーメッセージはなんであんなに理解不能なの？」というものがあります。
そういう質問に僕はこう答えることにしています。「それは、エラーメッセージを出しているソフト自身だって、うまくいかなかった原因がよくわからないからだよ」。
実はこの質問は、質問した本人は気付いていないかもしれませんが、PCがPCである――家電や携帯やワープロ専用機とは違う――ことの本質を突いている質問です。そのことについての説明を一切省いて結論だけ言うと、冒頭の回答になります。
その本質というのが何なのかを述べましょう。まず、PCが家電と違うところ、それは使用者がプログラムを自由にインストールできることです。家電も携帯も、使用者が機械に入れられるのはデータだけ。プログラムを入れられるかどうかが違いなのです。
どんなプログラムが入っているかが決まっていないということは、機械の動作をあらかじめ予測できないことを意味します。ソフトを作るとき、他にどんなソフトが入っているかによって機械の仕様が違うのに、それは未定のままプログラムを作らないといけないのです。
他にどんなソフトがどのように入っていてPCがどのように振る舞うか、そのことをソフトは「環境」と呼びます。一部のソフトは、環境がどうであるかに応じて自分の動作を変更するため、ユーザに「環境設定」をさせます。これはもちろん、ユーザがPCのソフト状況を把握していることを前提にした要求ですね。
ソフト自身が自力で環境を解析して、それにあわせた動作をするというのは、原理的に困難です。PC内のソフトインストール状態には事実上無限通りの場合の数があるからです。*1そもそも、環境設定メニューで選択肢を提示して動作を変更すること自体も、何通りかの状態のPCに対して正しく動作するようにするだけです。ほぼ無限通りあるPCの状態すべてに対応できることは期待できません。
振る舞いの場合の数が無限通りあるPCに対して、有限通りの状態しか考慮せずに（できずに）設計したプログラムを動かした場合、期待と異なる結果が出る場合が当然あります。このようなとき、プログラムにわかるのは「想定した以外の振る舞いをPCがした」ことだけです。
このときプログラムにできること、それは「PCが、想定と違うこんな反応をした」とエラーメッセージを出すことだけです。何が原因なのか、どうすればいいのかなど表示できるわけがありません。なにしろ、想定した有限通りの状態以外だったわけですから（想定内の振る舞いだったのなら、最初からエラーメッセージなど出さず、振る舞いにあわせた動作をすればいいだけのことです）。
プログラムをインストールすることができるおかげで、PCは使用者の望む機能を持つことができ、アップデートすることができ、複数のベンダのソフトを利用することができるという便利さを持っています。それと同時にこの特徴は、状態が（ほぼ）無限通りになることで振る舞いが予測できなくなるという最大の欠点の本質でもあるのです。
このことを一言でまとめると、まさに「ソフト自身だって、わかっていない」ですね。
*1：ある程度環境設定を自動化したソフトというのもありますが、それは選択肢を非常に限定することで実現しているに過ぎません。設計時に想定しなかった状態になっていれば、環境を正しくは判定できません。
2008-02-20
失敗公共事業e-Tax
オンライン確定申告「e-Tax」の利用を促すため国税庁が躍起になっています。アイドルを広報キャラクターに据えたり、利用者には控除を認めたり、関連証明書の提出まで免除したり、まさに「なりふり構わぬ」という言葉通りです。
e-Taxがどの程度不人気かを知るのは簡単です。役所で公的個人認証の鍵ペアを作ってもらうと通し番号がもらえるので、自分が（その都道府県内で）何番目の利用者だかわかるようになっているのです。僕が今日作ってもらった鍵ペアの通し番号は……東京都でe480番（＝58496番）。
これほどの広報にもかかわらず、まだ広い東京都内で6万人も利用者がいないのです。
e-Taxの利用は従来型の申告より面倒
従来型の申告でも、申告書類はオンラインで作成できます。それをプリントアウトして税務署に持っていく（もしくは郵送する）だけ。
源泉徴収票その他の証明書類をのり付けする手間＋税務署（郵便ポスト）へ足を運ぶ手間だけがかかるわけです。
e-Taxを使うとこれが楽になるか？
足を運ぶ手間は2倍になります。
役所へ行って住基カードを発行してもらい、これに鍵ペアを登録してもらうのがまず一手間。
次に、住基カードを自分のPCで使うためのICカードリーダを買いに行かないといけないのがもう一手間。
のり付けするための手間がかからない？ でも、カードリーダのドライバをインストールしたり、公的個人認証のクライアントソフトをインストールしたりの手間で、まあ、相殺でしょう。
2回目以降は面倒がない？
住基カードに登録された鍵ペアは、簡単に失効します。
まず、有効期間が3年間。しかも、期限切れの通知は来ないので、こっちで期間を把握して役所に更新に行かないといけません。
引っ越しでもアウト。市区外への引っ越しで住基カードそのものが無効になってももちろん、市区内の引っ越しで住基カードが有効なままでも、鍵ペアは無効になります。
結局、わりと頻繁に役所に行かざるをえないようです。
なぜ、ICカードリーダがFelicaじゃない！？
これが、多くのPCユーザが感じた疑問でしょう。
Suica、Edyなど数多くのサービスの基盤であり最も普及しているICカード規格であるFelicaを採用しておらず、よって最も普及したICカードリーダであるPasoriが使えません。Pasoriが使えるならわざわざICカードリーダを新たに購入する必要もないのに……という歯がゆさが残ります。
サービス主体が民間企業であれば、迷わずFelicaを採用していたはずです。
そもそも確定申告に必要な個人認証レベルは？
百歩譲って、ネットワーク越しの個人認証が面倒なのは仕方がないと認めることにしましょう。
しかし、確定申告にはもともとそこまで大がかりな個人認証をしていたかというと、そんなことはありません。なにしろ、三文判を押して郵送するだけでもできていたことなのです。税務署を訪れる場合も、身分証明を求められたりはしません。
三文判の代わりに身分を担保するものとして公開鍵認証までさせるのは、どう考えても過剰でしょう。
e-Taxを普及させたいなら簡単、氏名住所（または住基番号）の手入力のみでオンライン提出できるようにすることです。三文判を押せなくなることをどの程度重視するかですね。
2008-02-18
プリンスホテル日教組集会拒否問題の本質
日教組の大会を、他の利用客の迷惑になるなどとしてプリンスホテルがキャンセルし、裁判所の利用させよとの命令も無視した問題について。
この問題で、ホテル側の行動が正しかったかどうかという観点からの議論は、問題の本質を見失っています。もちろん司法判断の遵守という面においても、社会正義（著名企業には言論の自由を守る責任もあるのではないか）という面においても、責任を問うことは可能でしょう。しかし、結婚式場も持っているホテルにとって、裁判所の命令を無視することになったとしても街宣車が押しかける事態は絶対に避けなければならなかった。これは、仕方のないことです。
この問題の本質は、右翼団体の卑劣さにあります。
正面からは言論の自由に対して手出しできないので、ホテル利用客や周辺住民を間接的に人質にとったわけです。利用客を人質に取られてはホテルも抵抗できるわけありません。
問題の当日にある右翼団体が出した「日教組に会場を貸すことはけしからんということを知らしめることができた」というコメントは、まさに反社会勢力の勝利宣言でした。
この卑劣さはもっと言及されてしかるべきでしょう。
この問題を国会で取り上げるならば、ホテルの対応がどうこうではなく、反社会勢力の活動を規制する新たな枠組みについてであるべきでしょう。
2008-02-05
pipes!でRSSをもう一つ「専門家に聞く恋愛相談」
http://www.so-net.ne.jp/wedding/love/sunmarie/latest.html
「専門家に聞く恋愛相談」
このQ&Aサイトは，ライトな質問もあるけど，とんでもなくディープな相談がたくさん集まってておもしろいところです。
そして回答者もぶっちゃけていて，名問答がわんさかあります。特に，神田和花さんという回答者の切れ味が鋭い鋭い。ときにばっさり斬り捨て，ときにスマートな解決策を出す，もう自由自在。
ウォッチしてたいので，pipesでRSSにしました。全文配信付き。
RSS http://pipes.yahoo.com/pipes/pipe.run?_id=_FjD0czT3BGnc0iozKky6g&_render=rss
2008-02-04
「看護婦」という呼び方
「看護師」という新しい呼称が導入されてから，あっという間に「看護婦」という言葉は姿を消しました。看護婦という言い方は，すでに「古い」印象を与える言葉になっており，かといって「看護師」もまだ据わりがよくない，いまはそんな時期かと思います。
この時期なので，看護婦という呼称について少し議論をしておきましょう。
看護婦と呼ぶのはいけないのか？
法律上の呼称が看護婦・看護士から看護師に変更されました。もう，看護婦・看護士という呼び方をしてはいけないのか？
そんなことはありません。法律で定められているのは「看護師以外が看護師を名乗ってはいけない」ことであって，「看護師を看護師以外の名前で呼ぶ」ことは問題ではないのです。
たとえば，医師の呼称は法律で「医師」と決められているけど「医者」と呼んでも全然問題がないですよね。
看護婦・看護士という呼称には問題があったのか？
呼称が変更されたからには，元の呼称では困ることがあったのかという問題になります。
まず，男女差別なのかという点。男女で呼称が違うのは男女差別なのか？ 呼称が異なること＝男女差別という認識は，少なくとも日本ではあまり一般的ではないと思われます。最も一般社会になじみが深いと思われる職業であるホワイトカラー被雇用者のことを慣用的に，男性ならサラリーマン，女性ならOLと呼び分けているのが一般的ですね。このことに異議が唱えられることはほとんどありません。フランス語の職業も男女で呼称が異なります（ソムリエ／ソムリエールなど）が，これにも意義が出てはいません。
もっとも，看護婦・看護士の場合，看護婦がその両方を代表してしまっていたという現実は指摘できるでしょう。例えば，看護婦と看護士の職務長は「婦長」でした。ただし，これは男女同権を目指す上で，呼称変更までする動機としてかなり弱いのは確かです。
では，なぜ呼称が変更されたのか？
看護婦・看護士を看護婦が代表しており，看護職をほとんど女性が担っている不均等を反映してしまっていたこと。これは言えます。
もうひとつは，性的に中立な呼称がなく，「看護婦・看護士」という面倒くさい呼び方をしなければいけなかったこと。これもあるでしょう。
ただ，両方合わせても法改正までする動機としては弱すぎます。いじるべき法制度は他にもっとたくさんあったはず（らい予防法の撤廃に何十年かかったことか）。
個人的な意見ですが，「師」の一文字がほしくて運動した人々の成果ではないかと思っています。
2008-01-28
法、納得！どっとこむのレスポンスの早さ
法、納得！どっとこむ
に掲載されている法律相談は、質問が来てから答えが出るまでどのくらいの時間がかかるのか、興味がありました。
なぜなら、いつか自分がトラブルに巻き込まれたとき、このサイトが無料の質問先として役に立つかどうかに関わるからです。回答が来るのに時間がかかるのでは、緊急性を要する質問ができません。
それが、レスポンスタイムのわかる質問が来たんですよ。
http://www.hou-nattoku.com/consult/678.php
「病院内の電子機器の利用は法律で禁止されている？」
ブログのコメント欄での問答に関して、法的に正しいのかどうか疑問があるんだけどという質問です。その問答というのですが、なんか完全に日本語が壊れちゃってて特徴的な文章なので、ぐぐれば当該ブログがわかるかな、と思ったわけです。
そこで「あらゆる電子機器の関係で禁止しております。」という文字列で検索をかけてみました。お、一発ヒット。
http://plaza.rakuten.co.jp/misa4224/diary/200801160000/
これは、1/17に投稿されたコメントだということがわかりました。回答の掲載は1/28。
コメントが投稿されてから質問が出されるまでどの程度タイムラグがあったのかはわかりませんが、10日もあれば回答が得られるようです。
2008-01-27
理系のための恋愛論のRSSフィードを作った
Yahoo! Pipesはビジュアルプログラミングのいい練習になります。
今回、「理系のための恋愛論」 http://journal.mycom.co.jp/column/rikei/index.html のRSSフィードを、Pipesで勝手に作ってみました。
RSS http://pipes.yahoo.com/pipes/pipe.run?_id=MnzSkwnM3BGodbHNyp1_DQ&_render=rss
要約＆全文配信付き。
ポイント：
- 全文配信するには、item.content:encoded に記事本文のHTMLを配置します。
- 日付を付けるには、日付構造体（DateBuilderで簡単に作れる）を item.y.published に配置します。pubDateやdc:dateはみていません。
- 置換で $1 などの参照は（マニュアルにはあるのに）うまく動かないようです。置換を複数回かけるなどで、参照は使わずに必要な文字列を切り出しましょう。
2008-01-13
バーチャルアイドルは女性をターゲットにせよ
想像してみましょう。
もし合成歌唱ソフトの初音ミクが、歌手役のバーチャルアイドルとして新しいオリジナルキャラ初音ミクではなく、あの伊達杏子を起用していたら……！
萌える萌えない以前に「ふ、古……っ！」という印象が先立っちゃいますよ。男性の筆者として主観ですが、これは引きます。他の男性の反応もそう違うものではないでしょう。かの大ヒットソフトも今のような成功はなく、専門ソフト売り場の片隅で忘れられていたかもしれません。
伊達杏子があんまり可愛くないという問題はあまり関係ありません。顔も体型も細かく再調整できるのがバーチャルアイドルなんだから（ぷよぷよのアルルの変貌ぶりよ）*1。
歳をとって老けるわけではないバーチャルアイドルでも、「古い人」はアイドルとしての価値は落ちてしまうと言ってよいでしょう。これに関連して思い出したのがことわざの「女房と畳は新しい方がいい」。「若い」ではなく「新しい」方がいいと言っているんですね。
女性アイドルが長命にならないのは、トウが立つこととは無縁に新鮮さがなくなることに問題がありそうです。
バーチャルアイドルで商売するとき、この新鮮さの問題は重大です。せっかくの永遠の若さも、デビュー後「古く」なってしまうことに勝てないんだから。
ではどうすればいいか。
長命アイドルがいるのは女性よりは男性ですね。
女性をターゲットにして男性バーチャルアイドルを出すのはどうかな。
*1：初登場時にそれほどブレイクしたわけではないという問題は大きいかもしれませんが
2008-01-10
EclipseにほしいJavaリファクタリング機能
もう十分すぎるくらい高機能なEclipseのリファクタリング機能ですが。
- 親クラスをフィールドに変換
- フィールドを親クラスに変換（親子でのフィールド名衝突は自動解決）
- コードを「メソッドを抽出」するとき、メソッドの作成先は他クラスも指定できるように
- しかも、「メソッドを抽出」ではプロジェクト内すべてのクラスを検索して抽出可能なコードを変換
これがあったら今日の作業は10クリックぐらいで終わったのに。
ついでに、一太郎にほしいスタイル機能
今回の論文は数式が入らないので、アウトライン機能を見込んで一太郎で作成中。文書の見た目は完全にTEXのjArticleだけど。遊びすぎだっつの。
しかし、文書の論理構造とビジュアルの分離という点では、一太郎のスタイル機能ではまだまだ、できないことがいっぱいです。
- 段落スタイルで、行頭記号として任意の文字を任意のスタイルで設定させてください。現状、行頭記号の選択肢は貧弱すぎます（中黒がない）
- 行頭記号として、連番も使えるようにしてください。これができると、アウトライン機能と連携することで、見出し行設定と連番振りが一体化されます
- 同じく段落スタイル、「段落前で改行」というチェック項目がほしいです。大見出しはページの頭にあってほしいですよね
- ページ番号設定は目次機能と連動してください。標準機能で目次を自動作成してるんだから、目次が何枚あって表紙（目次より前のページ）が何枚あるかぐらい自明でしょう