よどんだ景色に答えを見つけ出すのはもうやめだ（3）

明日祖父母宅に行くのですが、今家でネットが使える状況なのでもう一つ記事を更新したいと思います。

この記事は前記事の続きです。

・MVC

――今回CJPolygonのデータベース部を開発するにあたって、MVCと言う考え方に配慮した。MVCとはプログラミングにあたって、コードを三種類のコンポーネントに分類してコーディングするものである。MはModel、VはView、CはControllerを表す。Viewは画面表示を司るもので、Modelは実際のプログラム内部での処理を担当する。そしてControllerがそれらを管理し、繋ぐのだ。MVCと言う考え方自体は結構古くからあるらしいのだが、Cocoaではそれを再定義してオブジェクト指向を徹底し、コードの再利用がより容易になるようにしている。また、プログラマに対してもMVCに準拠したコーディングを行うように推奨している。

・CDPolygon

こうして私はCJPolygonは挫折したが、たまたまインターネットでホームページを見ていて興味深い記事を見つけた。CoreDataである。

その記事はMac関係の本を多数出しているマイコミこと毎日コミュニケーションのマイコミジャーナルの特集記事だった。執筆したのはCocoaプログラミングのパイオニアである木下誠さん。そこにはXcodeの機能としてCoreDataという機能が紹介されていた。結局私はCoreDataがなんなのかは正確にはつかめてはいないが、それはデータベースを利用するソフトの開発を大幅に簡略化できるものらしい。そこで私は自分でも試してみることにした。

まずプロジェクト作成時にテンプレートとして［CoreData Application］を選びプロジェクトを作成する。このCoreDataを使う方法ではデータモデルを使う。プロジェクト内の拡張子が「.xcdatamodel」のファイルを開き、そこでデータモデルを定義する。Xcodeのクラスブラウザは、値を編集できるもののクラス自体を作成することは出来ないが、データモデルブラウザの場合はこれをつかってエンティティを新規に作成できる。つまりコードに一切触らずにプログラミングが出来るというわけだ。

マイコミジャーナルの記事に従って操作を進める。エンティティーを作成した後そのエンティティーが持つプロパティーを設定する。これを（大抵の場合）複数作り、関連性を設定してモデルを作り上げる。木下誠さんの著書「Happy Macintosh Developing Time」によれば、ここで設定を変にいじくると完成したソフトがクラッシュすることもあるらしい。

モデルを作成した後、もっともダイナミックなのがデータモデルブラウザからIBへモデルをドラッグ&ドロップするとき。Optionキーを押しながらすることを忘れないように。

Interface Builderにドロップすると、自動的に表が作成される。この表は入力用のフィールドや検索用のフィールド、そしていくつか表内に項目がありいくつ今選択されているかを表示するものや、レコードを表に挿入したり削除したりするためのボタンなどが用意されている。何より驚いたのは、アプリケーション終了時に入力した内容が自動的にハードディスクに保存されることだ。私がCJPolygonを挫折した理由のひとつにXMLでのデータの保存方法がわからないということがあったが、CoreDataはこれを自動的にやってくれるのである。

私はPolygonに使えるようにInterface Builder上でインタフェースを編集した。Fetchボタンや入力用のフィールドを削除、表のカラム名を日本語化したり（実際は日本語用のリソースを作って編集すべきだが面倒なのでEnglishでそのまま日本語化した。）ウィンドウを画面全体に拡大、カラムを並べ替えた。他にもバグIDのカラム名やそのカラムの内容の文字列の右寄せなどや、ボタンのルック&フィールの変更を行った。

先生のMac（OS X 10.3 Panther）ではこのCDPolygonは動かなかったが、これはこのCoreDataを使ったソフトが実行環境でもCoreDataのシステム（つまり10.4 Tiger以上）を要求するからだと思われる。――

この記事にはまだ続きがあります。続きは数日後に載せるつもりです。

お知らせ：数週間ほどブログ更新を停止します

長男が家に少し泊まるらしいことと、田舎の祖父母宅に行く予定があるので、数週間ほどブログの更新が出来ません。『よどんだ景色に答えを見つけ出すのはもうやめだ』の掲載中ですが、続きの掲載は数週間後に家に戻ってきてからになります。

『時をかける少女』についての新しい記事の編集が完了しています。現在の記事の掲載が完了し次第載せたいと思います。

アイシールド21の最終回どうやって視よう……。アンテナ入らないんですよね……。

よどんだ景色に答えを見つけ出すのはもうやめだ（2）

この記事は前記事の続きです。

本論

――では、実際のプログラミングの話に移ろう。

プログラミングには様々な形態があるが、今回はMac OS Xに付属してくるIDE（統合開発環境）であるXcodeを利用することにした。プログラミングではこのようなIDEを使ったGUI的な開発の他にも、コマンドラインにコマンドを打ち込み開発するCUIベースの開発方法もあるが、効率や難易度などの面から考えて、IDEを使うことにした。

XcodeはGUIで操作するソフトである。使うためにはXcodeを起動し、プロジェクトを作成し、ソースなどを編集して、プロジェクトウィンドウのツールバーに含まれるビルドボタン（実際には「ビルドして実行」ボタンを使うことの方が多い。）を押して、ビルドする。このようにしてXcodeではソフトが作られる。インタフェース部分は別にInterface Builder（以下IB）というソフトを用いて設計する。Xcodeを用いた開発ではこのようにXcodeとIBの連携で開発を進める。

Polygonは主に二つのビューから成り立つ。一つは表形式に表示してバグをデータベース的に管理する部分。そしてもう一つはそのデータからバグの依存関係を図に明示する部分である。今回はおまけ要素もかねてQuartz Composerで作ったコンポジションもソフトに組み込んでみる。

・CJPolygon

まず私は、昔Javaプログラミングを試みた経験があったのでCocoa-Javaを言語として選ぶことにした。Cocoa-JavaはJava言語を使いつつMac OS XのフレームワークであるCocoaを利用できる。Javaのソースコードの文法は私の感覚にしっくり来るが、pure javaの場合その代わりできあがるソフトのパフォーマンスや機能の面ではどうしても問題がある。そこでCocoa-Javaを使うことにしたわけなのである。プロジェクト名は「Cocoa-Java Polygon」を略して『CJPolygon』とした。

まずはPolygonのうちチャート（図）を表示するキャンバス部分を作ることにした。まずIBでNSViewを継承したクラス"MyView"を作り、"NSView"をパレットからメインウィンドウに配置する。そしてインスペクタでNSViewのクラスをMyViewに設定し直し、コードを書く。コードはdrawRectメソッドにいろいろと書くと、実際の動作に反映される。詳しくはご自分で調べて確認して欲しい。

このプロジェクトで特にこだわったのは、コードのメソッド化である。私はオブジェクト指向をあまり理解していなかったのだが、サブルーチンという考えは理解していたので、とにかくメソッドとして固定化できるコードはメソッド化して、再利用しやすいように作ろうと思って作った。たとえば、本来fillメソッドとstrokeメソッドで別々に指定する図形の塗りと線を、メソッド一つで一つの図形として塗りも線も同時に行えるようにメソッドを作った。

メソッドの作成という点においては、Cocoaの座標から標準座標（私はこう呼んでいる）を求めるメソッドが特に出来が良かったと思う。Cocoa座標でキャンバス内にオブジェクトを表示するときはウィンドウの左下を原点として表示するが、これだと使いづらいので、左上を原点とする標準座標をCocoa座標に変換するメソッドを作って、標準座標を指定するだけで自動的に正しい位置にオブジェクトを表示できるようにした。このメソッドでは、Cocoa座標ではウィンドウのサイズを変更すると（縦の長さが変わるので）自動的に表示更新されて動いてしまうオブジェクトを、動かないように表示することが出来るようになった。

ちなみに後日談だが、このメソッドと同じく標準座標で座標を指定して処理するメソッドがCocoaには既に用意されていることがわかった。

このように少しずつ発展していったCJPolygonのチャート部分だが、オブジェクト指向の理解、頭の中の仕様に対するコードの創出、複雑なインタフェース（たとえば文字列をある対象のオブジェクトに対して中央揃えで表示する）などの点において行き詰まりを迎え、プロジェクトを放棄せざるをえない状況になった。

そこで今度はCJPolygonの表部分を作ることにした。Cocoaでは、表を作ることはInterface Builderを使えば簡単にできるが、その表に表示するデータを管理するためにはDataSourceというものと作らなければいけない。これは元のDataSourceを継承して作るのだが、これがなぜかうまくいかなかった。「DataSourceはabstruct（注：「抽象」と言う意味）クラスなので、メソッドをオーバーライドできません」といった感じにエラーが表示されるのだ。「メソッドをオーバーライドするためにはabstructメソッドでないといけません」みたいなことを言っていたので、全てのメソッドにabstruct修飾詞を付けてコンパイルしてみもしたが、エラーがでた。クラスの継承（この場合正確にはimplementsでの実装）を削除してみるとなぜかとりあえず動いた。

その後表の中のデータをファイルに保存する方法を幾度となく挑戦してみるも、時には表に中身のデータが表示されなかったり、たとえ表示された場合でもそれを柔軟に利用することは出来なかった。Polygonの仕様としては表のデータの保存が必要なのだが、これもかなわず、やはりCJPolygonのデータベース部分も挫折することとなった。――

この記事にはまだ続きがあります。続きは数週間後に載せるつもりです。

よどんだ景色に答えを見つけ出すのはもうやめだ（1）

以下の文章は前私が学校の総合科目のレポート内容として提出したものです。Macでプログラミングをしようとしている人にとって参考になるかと思ったので載せてみます。学校に提出したものなので載せていいか微妙ですが、いいですよねT代先生？　この文章の内容はオリジナルであって、決して学校に提出したレポートの内容をインターネットのどこぞ（このブログのこと）からコピーしてきたわけではありません。

T代先生、詳細な添削ありがとうございました。「学問の目的は最終的には一つ」、うーん意味深な言葉だなあ。

序論

私が今回プログラミングをテーマにとろうと思ったのは、先生にそれを勧められたからである。本来は、自分は世の中に多々あるプログラミング言語の種類とその特徴についてレポートにまとめようと思っていたが、担任の先生に、「プログラミング言語の特徴を列挙するよりも、実際にプログラミングをしてソフトを作ってみた方がよい」といわれたので、それをテーマにしてみることとした。

しかし、それをテーマにしたのは先生の推薦だけが理由ではない。自分自身プログラミングをやってみたかったのと、強力なIDE（統合開発環境）が私が使っているコンピュータに入っていたこと、ちょうどプログラミングの本を書店で買ってきたこともあって、それをテーマに選ぶことにしたのだ。

ちなみに、プログラミングをやってみたかったのはプログラマーという職業にあこがれを抱いていたことや、実際自分が必要とするソフトで世の中で配布されているソフトに含まれていないソフトがあったことなどから、自分で作ってみようと思ったことも理由である。

今回、その作ってみたいソフトの中で、今すぐに必要としているバグデータベースソフトを実際に題材もかねて作ってみることにした。このソフトは、常日頃の日常でその人が抱えている「バグ」をデータベースとして管理するだけでなく、そのバグ同士の依存関係を図にして明示するということが目的である。私はこのような目的のソフトを「パーソナルバグトラッカー」と呼ぶことにした。ちなみにバグとはソフトウェア用語で（ソフトの）「不具合」と言う意味である。

人々は何不自由なく幸せに暮らしている人たちばかりではない。いや、というかそういう人はいないとさえ言えると思う。なぜ何不自由なく人生を送れないのかというと、それは日常の中で様々な「壁」が存在するからである。絵がうまく描けない。プログラミングが難しすぎる。人間関係がうまくいかない。レポートがなかなか終わらない。英語が読めない。仕事のノルマが厳しくて疲れる、ひいては、お金がない……など。その問題というものがこのソフトにおける「バグ」にあたるわけである。

私はこのソフトの名をPolygonと名付けた。（正式には「Polygon the BugTracker」。ディベート図式ソフトの構想である「Polygon the DebateTracker」と区別するためにこのような名前が付いている。）　この名は、このソフトの目的であるバグの依存関係の図が、ちょうど三角形などの多角形を描いているように見えることから来ている。

バグデータベースの概念はインターネット関連製品を配布しているMozillaコミュニティーのバグトラッカーであるBugzillaと、SourceForge.netのトラッカーから来ている。これらのサイトのCGIは、それぞれのコミュニティーが開発しているソフトウェア製品のバグを効率的に追跡し、解決するために運営されている。Polygonはこの考えを、個人の生活に導入しようという目的のために私が構想した。――

この記事にはまだ続きがあります。続きは数日後に載せるつもりです。

未来は変えられない（後）

この記事は前記事の続きです。

――このことは歴史というものを考えることでも理解できます。私はNHKの歴史ドキュメンタリー番組である『その時歴史が動いた』を第１回から見ていたコアなファンでしたが、この番組ではときどき特別番組として、歴史の「ターニングポイント」を扱っていました。ターニングポイントとは、その後の歴史に大きな影響をもたらした歴史の分岐点です。その分岐点でその時代の人々がこういう決断をとったから今の日本がこうなっているという趣旨の企画だったのですが、その時司会者の人が言っていたこの言葉が耳に残っています。

「まあ、歴史に『もしも』は無いんですが――」

そう、もしもは無いんです。歴史というのはいわば過去から現在への一本の道です。もしかしたら過去のその時にはいろいろな未来の可能性を考えることが出来ていたかもしれませんが、実際のところ現在から過去を振り返ってみれば、歴史が一つしかないように道は一つなのです。選べる道が複数あったとしても、実際に選ぶことができるのは一つの道のみです。たとえば、ある学生に野球部に入る方法とサッカー部に入る方法があった場合を考えてください。その学生は必ずどちらかを選ばなければなりません。え？　どちらの部活にも入り兼部する道、どの部活にも入らず帰宅部になる道もあるって？　確かにそれはそうですが例えそうしたとしても複数の道を選んだり何の道も選ばなかったことにはなりません。なぜならば、野球部「だけ」にはいる道と、野球部とサッカー部両方に入る道はまた別個の独立した一つの道だからです。「だけ」が「両方」の中に含まれるわけではありません。

これで未来は一つの道しかないと言うことがおわかりいただけたと思います。もちろん実際には未来を完全に予測できるコンピュータなどこの世界にはないのですが、考え方としてこの理論は知っていた方がよいと思います。応用も利きますしね。

たとえば日常ではこんな使い方が出来ます。もし電車に乗り遅れそうになって駅に向かって急いで走っているとき、「遅れる可能性もあるし間に合う可能性もあるな」なんて思っていると間に合うかどうか不安でたまりません。そんなときはこう考えましょう。「私が電車に間に合うかどうかは、既にもう決まっている、無駄に心配をかき立てないようにしよう」。もちろんこのことを「急いでも無駄だ」と言う意味でとるのが正しいというわけではありません。あなたがあきらめるかどうかも含めた上で、未来は決まっているのです。あなたがあきらめるかどうかも物理法則次第、間に合うかどうかも物理法則次第、既に決まっているというわけです。

「チューブ理論」のチューブとは、その中に圧力を掛けて水を通しても、水の液面はチューブの中を通っていくだけで、チューブのくだの横の穴から水が飛び出したりしないというインスピレーションから来ています（穴がなければそうなるでしょう）。つまり時間は、現象は、決まった道から外れないというわけです。際限なく上に上がっていくエレベーターに例えて、エレベーター理論という呼び名も考えたりしました。（かなり特殊なエレベーターですね。）

よく「運命」という言葉が言われますが、日頃日常を漠然と過ごしていると、運命など無いという風に思えます。しかしこのようにチューブ理論のことを考えると、「未来は決まっている」つまり「運命はある」と言う風に考えることも出来るかもしれません。人間は運命の指し示す道を生きていくしか方法がないのだと。

■（2008.2.25）

後日注：「チューブ理論」と言う言葉は既に別の分野で別の意味で使われている言葉のようです。（2008.5.8）

未来は変えられない（前）

要約：「未来は変えられる」。当たり前にそう信じてはいませんか？

今日はわたくしことwhitecapsが持っている哲学の中の一つの理論を紹介したいと思います。その理論の名は「チューブ理論」です。

人間は様々な問題を解決するために、未来を予測しようとします。たとえば「地球シミュレーター」というものをご存じでしょうか？　これは地球の未来の環境の変化を予測するためにつくられたスーパーコンピュータ（スパコン）のことです。このスパコンは日本のもので、一時は世界一の計算能力を持つスーパーコンピューターでしたが、時代が進歩するにつれて他のスパコンに性能的に追い越され、現在では高額なランニングコストのために廃棄される予定であるとテレビで報道がありました。

まあ、地球シミュレーターの行く末は今回の理論とは関係ないのですが、大事なのはここから発想をふくらますことです。それはもし、もっと正確に未来を予測できるコンピュータのようなものがあったとしたら、と言うことです。この世界は物理の法則で成り立っています。物理の考え方によれば、現在の対象の状態とそれを変化させる法則さえわかれば正確に未来を予測できると言われています。もしこの世界に関わりのある全ての事象や法則に関して詳細で完全で正確な情報が「超々々」高性能なコンピュータの中に入手できるとしたら、どうでしょう。この世界の未来を完全に予測することが出来ます。

人間の脳も電気信号で思考している物理法則に則った器官であるわけですから、その全ての情報と法則の情報が計算できれば、その人がどういった判断をとりどう行動するのかと言うことも完全に正確に予測可能と言うことになります。

世間ではよく「可能性」という言葉が言われます。「可能性は無限大だ」とか。「確率」と言う言葉もよく使われます。これこれが起こる可能性は三分の二だ、とか。しかし、全てを正確に予測できるコンピュータのことを考えると、これらの言葉が無意味であることがわかります。未来が一つに予測されると言うことは、すなわちそれは未来は一つしかない、一つの道しかないと言うことを表すからです。つまり、「未来は変えられる」と言う言葉は間違いで、本当は「未来は変えられない。未来は決まっている」と言うのが正しいのです。え、未来は決まっているなんてつまらない考え方だって？　そうかもしれませんね。しかしそれは事実です。――

この記事にはまだ続きがあります。続きは数日後に載せるつもりです。

詩『時代』by whitecaps

ちょっと思い立って　近所にある丘に来てみた
川が見れる、近所で一番高いところ
雨の中　濡れるのなんか気にしないで自転車で行く
疲れも知らずぐんぐん走る
気がついて　解けた靴紐を結ぶために止まっているうち　子供たちに追い越され
五月の雨に濡れて　近くの家の軒先から雫が落ちるのが見える
ピアノの音

自転車をわきにとめ遙か遠くの空を見つめる
雨が上がって雲がわかれ
光が差し込み、草木に付いた露が輝いていた
そして、空に大きな虹

僕はその大きな虹を見上げながら、過ぎ去った数々の季節を思い浮かべた。
夏の花火、秋のイチョウ、冬の星空、そして桜散る春
志を立てたあの日　涙に暮れたあのときも
きっと、どんなときも君がそばにいた

果てしない夢を抱えて 危なっかしくて、でも
ただひたすら、その時目指すべきものを目指して
行く先なんてわからないまま

根拠のない自信と　押さえ込んだ熱意
自分の考えだけを信じて　背伸ばして生きていこうと決めたあの頃
君が僕のそばを離れていったときから
今の情熱は過去のものとなり　新しい今の情熱が渦巻く
もう無くなった情熱も　それを生み出すものは今も変わらない

過去は、思い出は決してノスタルジックな色なんかじゃなくて
氷に固められた絵のよう　何度でも溶かして触れられる

若かった、ほんと泣けてくるほど若かった　僕は
あの懐かしい感覚　懐かしい人々
懐かしい匂い　懐かしい音楽　人のぬくもり、人の絆

きっと未来の自分も　今という時代を振り返って言うだろう　あのときは若かったと
なぜなら、人間は成長するものだから　変わっていくものだから

隠された哀愁も　時の忘れ形見

どんどん空が夕闇に包まれていく
川面がきらめく　美しいまま
黒い水がオレンジに染まる
さて、家に帰ろうか　僕は自転車にまたがる
家では　暖かい夕食が待っていることだろう

道は、もう乾いていた。

■（2008.1.29）