- HMDT archive-
October, 2004

ごぶさたっす。ずいぶんと久しぶりの更新になってしまいましたが。 一週間ほどネットワークから離れていました。というのも、また引っ越ししてたんで。三ヶ月前に引っ越したばっかりなのに、また引っ越しでした。今度のところでは、少し腰を落ち着けたいもんです。

前々から読まなきゃいけないなー、と思っていた、オライリーの『プログラミング Perl』の本を読んでみている。分厚いことで有名だけど、最初のページから丁寧に。 この本は、Perl の入門や解説だけではなくて、その背後にある思想も書かれている。相当な量の諧謔を交えながら。その Perl の考え方の一つに、「書き方は一通りではない」っていうものがある。つまり、ある一つの処理に対する記述の方法は、ただ一つに決まるのではなくて、たくさんの書き方を用意する。それが Perl のやり方だ、と。 あー。3 年前のおれだったら、この考え方に反発を覚えていたと思う。「ただ一つのベストのやり方があれば、それでよし。無意味な冗長性はパフォーマンスの低下と実装の困難さを増すだけで、一点の利点も無し」って。そういう潔癖さもありだと思うけど、最近はむしろルーズな考え方の方が好きになっているみたい。「あれもよし。これもよし。それぞれの考え方に基づいて、最終的に動けばいいんじゃない。」 この考え方が、プログラミング言語だけではなくて、アプリケーションのユーザインタフェース設計にも影響を及ぼしている。つまり、「ある一つの処理に対する操作は一通りではない」っていう考え方。たとえば昔は、「ツールバーなんていらないさ！なぜなら美しくないから」とか、「メニューのショートカットの変更なんて必要なし！」思ってたけど。今は、「あったら使う人もいるだろうし。つーか、使いたい人がいる機能は全部実装するべきなんじゃないの？」と思ってる。ユーザインタフェースにおいては、多様性は否定すべきではない、ということか。

Apple が Mac OS X v10.4 Tiger: Developer Overview のページを公開！その中で、Core Data について触れられている。掲示板で教えてくれた、poo さん thnaks。 Core Data っていうのは、新しく Cocoa で導入されるモデリングアーキテクチャだ。もともと、Cocoa アプリケーションは Model View Controller (MVC) アーキテクチャをとっていたよね。この 3 つのレイヤのうち、View のレイヤは Application Kit の豊富なクラスがサポートしている。Controller レイヤは、Panther で導入された Cocoa Bindings でサポートが強化された。そして Tiger では、Core Data によっていよいよ Model レイヤがサポートされる。 Core Data は、開発者に汎用的なデータオブジェクトのモデリング方法を与えるものだ。Core Data の方式でモデリングされたデータは、ほとんどコードを書くことなしに、保存、読み込み、アンドゥサポートなどが行える。つまり、ドキュメントベースアプリケーションが、ほとんどコードを書かずにできあがる、と想像してみてくれ。 このオブジェクトモデリングは、UML をベースとしている。そのために、Xcode 2.0 では UML モデラ機能を備えることになるんだ。データのモデリングもコード書くことなしに行えるぜ。 さらに、オブジェクトデータの保存方法は 3 種類ある。一つ目は、通常使われるバイナリフォーマット。二つ目は、XML 形式。XML テキストなので、汎用性に優れる。そして三つ目は SQL データベースへの保存。データベースの特性を活かした高パフォーマンスが期待できる。このために、Tiger はデフォルトで SQLite データベースを備えるんだ。ついに、デスクトップアプリケーションのための、標準データベースが搭載されるときが来た。 Core Data で、また Cocoa アプリケーションの作り方は大きく変わる。Panther の Cocoa Bindings からの流れも含めて、定型的なコーディングの量を少なくするために、データベースシステムに似たアプローチをとっているという印象。しかし、Tiger だけのサポートってのがほんと悩ましいよなぁ、、、

他にも WWDC の基調講演ではみかけなかったものとして、サードパーティのアプリケーションからも iSync の機能が使える Sync Services や、Cocoa に PDF 表示機能を追加する PDFKit の情報などが追加されている。PDFKit は、Safari に対する Web Kit のように、Preview の機能を一般のアプリケーションでも使えるようにしたものだ。

シイラ nightly build 041020。 Growl に対応。 アプリケーションからの情報をポップアップ表示するユーティリティである、Growl に対応してみた。シイラからの、ダウンロードの終了を通知するようにしてみた。Growl のページからダウンロードしてインストールしてみてください。

シイラ nightly build 041015。 環境設定に「アイコンを削除」ボタンを追加。 鍵アイコンをタイトルバーに表示。 タブ表示を改良。 終了時にサイドバーの状態を記憶。 Favicon をシイラで保存。 まず、アイコン削除ボタンの追加は、環境設定のアイコンパネルに、アイコンを削除するためのボタンを追加。いままでは、アイコンを削除するには Finder からフォルダを削除する必要があったけど、これでアプリケーションからすべて行える。ただし、デフォルトのアイコンは削除できない。 続いて、セキュアモードで表示される鍵アイコンをタイトルバーに移動。これで、ステータスバーを隠しても鍵アイコンを見ることができる。この機能の実装が遅れたのは、タイトルバーにアイコンを表示する方法が分からなかったから。気づいてみれば簡単で、NSWindow の contentView の superview に、subview として追加すればよかったのだ。 タブ表示の改良は、複数タブを一気に開いたときの挙動を改善。少しきれいになった。 次の変更点は、サイドバーの状態の記憶。サイドバーを開いた状態でシイラを終了すると、次回起動したときに、自動的にサイドバーを開く。これも、サイドバーを開くタイミングが難しかった。 最後は、favicon の保存。いままでは、favicon はページ履歴と連動していたので、履歴が消去されると、ブックマークの favicon もいっしょにクリアされてしまっていた。これを、シイラ独自に favicon を保存するようにしたので、これからは大丈夫。

MOSA の湘南ミーティングに参加することになりました。 MOSA とは、このページ読んでいる方ならご存知の方も多いでしょうけど、Macintosh OS Software Association のことで、数少ない日本の Mac プログラマのための組織。その MOSA が毎年開催しているのが、オールナイトで Mac プログラミングを語り合う湘南ミーティング。そこで、今回講師として Web Kit とシイラプロジェクトの話をすることになりました。 他の講師の方は、昔から Mac プログラマとして有名な方々なので、おれがいっていいのかよ、とも思いましたけど、面白そうなんで引き受けてしまいました。なるべく、分かりやすく、面白く話すつもりです。参加される方は、湘南で会いましょう。

シイラ nightly build 041013。 暫定的に、画像のオートリサイズを復活。 前のビルドで実装した画像のオートリサイズ機能だけど、技術的な理由で無効化していた。だけどリクエストが多かったので、暫定的に復活させてみた。問題は、完全には解決されていないけど。 その問題というのは、ビルドするときに起こる問題。だから、実際に使用するときには、ほとんど問題にならないと思う。

で、その問題の内容は、export されていないシンボルを使っていることが原因になっている。画像のオートリサイズを実現するために、WebImageView っていう画像を表示するための Web Kit のクラスのサブクラスを作っている。ただ困ったことに、この WebImageView というクラスは、export されていない。クラスの存在は知ることができるけど、リンク時にシンボル解決できなくて失敗してしまう。 しょうがないから、アプリケーション側でダミーのクラス実装を作ってやって、どうにか通している。この方法はやりたくないんだけど、他に解決方法が見つからない。どうしよっかなー。Framework のシンボルテーブルを操作して、export にすることができればいいんだけど。再コンパイル無しでやるのは無理っぽいよな。

シイラで苦しんだバグから得られた、Cocoa プログラミングの教訓： 登録系のメソッドを使った場合、dealloc で明示的に登録解除しないといけない Cocoa のメソッドには、オブジェクトの参照を set したり add したりする際に、オブジェクトを保持する（retain する）ものとしないものとがある。しないメソッドには、NSNotificationCenter の addObserver: や、いろいろなクラスでデリゲートを登録する setDelegate: のメソッドなどがある。 このようなメソッドを使って登録されたオブジェクトが解放されるとき、解放する側で明示的に登録を解除しないと、ゴミが残ってしまう。残ったゴミ、つまり解放されたオブジェクトの参照の残り値、に対してメッセージが送られると、一発でクラッシュする。 ということで、NSNotificationCenter の addObserver: や、setDelegate: のようなメソッドを使ったら、そのオブジェクトの dealloc で、必ず removeObserver: や、 setDelegate:nil を呼ぶべし。 NSTableView の内部で使われるオブジェクトは、頻繁にコピーされる テーブルを表示するための NSTableView は、内部で NSCell オブジェクトや、値を表すオブジェクトなどを多数使う。実は、これらのオブジェクトは頻繁にコピーされる。特に NSCell のコピーは激しくて、テーブルのある行をクリックして選択するだけで、多数のオブジェクトがコピーされる。 だから、テーブルをコントロールするクラスで、ある瞬間に NSCell の参照を取得しても、次の瞬間にはそのオブジェクトは破棄されている可能性が高い。NSTableView から取得したオブジェクトを保持することは、できればやらないほうがいい。どうしてもやらなくてはいけないときは、充分に気をつけること。 nib でインスタンス化されたオブジェクトは、owner が解放する NSBundle の loadNibNamed:owner: で nib ファイルを読み込むと、nib 上でインスタンス化されているオブジェクトは自動的にインスタンス化される。しかし、owner を解放するときに、すべてのインスタンスが自動的に解放される訳ではない。 特別な例として、NSWindowController が owner の場合は、それが保持しているウィンドウは解放される。でもその他のオブジェクトは解放されない。owner が責任持って解放するように。 nib で NSController の content を接続すると、retain される Interface Builder で、nib でインスタンス化されるオブジェクトの間でさまざまな関連を作つことができるけど、多くの接続は retain されない。たとえば、NSTableView には dataSource や delegate を関連づけることができるけど、これらは retain されない。 でも、NSController に content を接続すると、これは retain される。この場合、明示的に release を呼ばないと content が解放されないので注意。特に、content として owner を指定してしまうと、content を release しない限り、owner の dealloc が呼ばれないので、特に注意。この場合、dealloc で release を呼ぶのではなく、別のタイミングであらかじめ呼ぶようにしないといけない。 このことを考えると、Cocoa バインディングのサンプルでよく使われる、owner を content とするパターンは、あまりやらない方がいい、という結論になる。

シイラ nightly build 041011。 安定性の向上。 最近クラッシュばっかりしてると評判のシイラだけど、こつこつ安定性も改善してるので。ある程度プログラムの規模が大きくなってくると、バグ 0 のプログラムを作るというのは、実践的にはかなり難しいことになってくる。これには特効薬は存在しなくて、問題を発見して潰す、また発見して潰す、の繰り返しになる。 この作業には、みなさんから送っていただいたクラッシュレポートが非常に助けになるので、よろしければどんどん送ってください。

ひ日誌さん経由で、「ぼくがきみのプログラミング言語できらいなもの」 筆者がいろいろなプログラミン言語のきらいなところを並べている記事だ。ウソです。そう書くと身もふたもない。ある程度、いろいろな言語で経験を積めば、それぞれの言語の長所、短所や、向き、不向きが分かってくる、という記事だ。 プログラミング言語の好き嫌い、を語るのは簡単だし楽しいから、どんどんやればいい。だけど、優劣を語ることは難しい。なぜなら優劣を語るにしても、基準が人によって変わるから。ただ、ターゲットを規定すれば、どの言語が優れているか、ある程度の議論はできるかもしれない。 たとえば、Mac OS X のデスクトップアプリケーション作るなら、Cocoa なら Objective-C だし、Carbon なら C++。Web アプリケーションなら、Java や Perl や Ruby や PHP や Python だろう。システム構築なら、Java なり Visual Basic なり。データベースなら、最終的には SQL。組み込みならほぼ 100% C だ。 そう考えると、実際のところ、ターゲットが決まった時点で言語の選択はほぼ決まってしまうから、議論の余地はほとんどないかもしれない。現実に即するエンジニアを目指すなら、ターゲットに合わせて最適の言語を習得するのが先でしょう。言語の議論はその後でもいい。

シイラ nightly build 041010。 ダウンロードパネルを改良中。 いまのユーザインタフェースでは、ダウンロードの表示はダウンロードパネルとサイドバーで行っているんで、そのソースコードを共通化して同じ表示にするようにした。ついでに、コードの構造を設計し直して、バグ潰し。

これが片付いたら、タブ周りのソースコードを書き直してみるか。

シイラ nightly build 041008。 すべてのエラーコードを表示。 いままで「エラーが発生しました」としか表示していなかったエラーに対して、すべてメッセージをつけてみた。これで、どんなエラーが発生しているか分かるはず。ただ、実際にすべてのエラーを発生させて実験した訳ではないので、とんちんかんなメッセージを表示するかも。

ひ日誌さんより、 Objective-C は、インライン Smalltalk の書ける C というか、インライン C の書ける Smalltalk というか、そんな風味の本物のオブジェクト指向言語であろう。なんちゃってオブジェクト指向言語ではくせ球・変化球を屈指してプログラミングする必要があるが、本物の場合そんなトリックを使う必要はない。直球勝負のオブジェクト指向プログラミングが可能だ。 そう、その通り！Objective-C は直球です、ど直球。直球の気持ちよさを知ってしまうと、「Effective-C++」とか「Java によるデザインパターン」とかみたいな、「テクニックを駆使してオブジェクト指向で解決！」といった風味のものを読むと、「そんな無理してこねくり回さんでもいいのに。つーか、そこまでやるんだったら、別の言語使った方が手っ取り早いでしょう」と、思ってしまう。

シイラの新しいビルドっす。シイラ nightly build 041006。 URL 中の空白を正しく取り扱うように変更。(Thanks to Charles) URL コンボボックスでの、補完された URL のソートを改良。(Thanks to Charles) 検索エンジンのテンプレート URL にエスケープ文字が入っていたときの問題の修正。(Thanks to Charles) URL コンボボックスから、キーワードを使って検索エンジンによる検索が可能（例：'g シイラ'で、Google から検索可能）。(Thanks to Charles) 今日は Charles 特集。Charles が送ってくれたパッチを当てました。ありがとう！ 今回の目玉は、キーワードによる検索エンジンサーチだ。この機能は、URL を入力するところから、検索エンジンを使ったサーチを可能にするものだ。まず、検索エンジンにキーワードを関連づける。そのために、「検索エンジン」のウィンドウに、キーワード入力用の GUI が追加された。 そして、URL を入力する代わりに、「キーワード」＋「一文字空白」＋「検索用語」を、入れる。たとえば、Google にキーワード「g」を関連づけたならば、「g Shiira」と URL を入力すると、Google で検索できる。 この機能は Camino や FireFox や Mozilla にもついているらしいけど、これでシイラも実装したことになるよ。

ちなみに、たびたびパッチを送ってくれる Charles だけど、たぶん CharlesSoft の人だと思う。

Apple から WWDC の DVD ボックスが届く。全セッションの Quick Time ムービーと、スライドを収めたものらしい。DVD 20 枚組！わぉー。たぶん、見る暇は無いな。 プレゼンテーションのスライドをぱらぱらと眺めてみる。Apple のスライドは、シンプルだけど手間がかかってるなー。

前回の更新から時間が経って、もう 10 月になってしまったか。 久しぶりにビルド出します、シイラ nightly build 041003。 検索エンジンの追加、削除でクラッシュする問題の修正 コンテキストメニューに、その他のエンジンで検索、を追加 検索エンジン周りをあーでもない、こーでもない、といじっていたら、だいぶ時間がかかってしまった。外見はそんなに変わっていないけど、内部はだいぶ変わってます。