10月 見えすぎる全体像

快調に進むPiyoCast、PiyoCast Makerの開発。しかし、広がり続ける世界観と増え続ける機能の影で、何かの問題が確実に起きつつあった

PiyoCast Makerのα版を公開

PiyoCastのデータ作成環境「PiyoCast Maker」をmixi PiyoCastコミュニティにて公開。 

http://mixi.jp/view_community.pl?id=358409

「control」による汎用オブジェクトアクセス

PiyoCastのデータを作るソフト、「PiyoCast Maker」の開発中、必要に迫られて編み出したテクニックが、「汎用オブジェクトアクセス」だ。 

これは、AppleScript Studioでプログラムを開発する際に、GUI部品がたくさん載っているような設定ウィンドウの設定内容を簡潔な記述でSave/Loadすべく作ったものだ。 


最初の段階(★ASS原始時代)では、Appleのサンプルプログラムに右に倣えで、解説書などでも、 

 set contents of text field "t1" of window "w1" to "ほげほげ" 

といった具合いにご丁寧に記述していた。GUI部品の数が増えるとひじょーーにメンテナンス性が悪くなり、こんな記述ばかりが延々と数十行も続いた日には、知性というものを微塵も感じさせない幼稚なプログラムリストになってしまう。 

そこで、TextField(テキスト入力用部品)、Popup Button(ポップアップメニューの出るボタン)、チェックボックスなどを種類別にそれぞれ内容をSaveするように処理するようにした(★ASS中世時代)。これはこれで、プログラムの記述量が大幅に減少するなど、「作成段階では」大きなメリットのあるものだ。 

「いくらGUI部品の数が増えてもプログラムの量は変わらない」というレベルに達したわけで、これだけでも十分に革命的な出来事だ(だいたい1か月前はこのレベルにあった)。 

しかし、この方式だと……記述効率の良さと引き換えに、実行スピードはいまいち……どころか、かなり問題があった。 

PiyoCast Makerは「とりあえず間に合わせで動けばいい」ぐらいのレベルを目標に開発を行っているものだが、そうはいいものの、自分で使ってみて問題を感じる程度の実行速度だった。 

そこで、少しぐらいはスピードアップさせてもバチは当たらないだろう、とさまざまなハイテクニックを投入してみたのだが、たしかに速くはなるものの、実用レベルにはまだまだ達しない感じだった。PiyoCast Makerについては、開発環境をREALbasicに移すべきかと考えかけたほどだ(RbはRbでいろいろ別の問題があるが……)。 

さらに、その当時どうしてもとれないバグに直面し、その解決策として抜本的な処理内容の見直しを行わなくてはならなくなった。 

この段階で、1つのウィンドウ上にあるGUI部品のデータと、GUI部品への参照情報をそのまま取り出し、まとめて変数に保持したりファイルに書き出していた。アプリケーションの実行中は何度Save/Loadを繰り返しても問題ないのだが、一度アプリケーションを終了すると、このGUI部品への参照を再現できなくなるらしく、問題が起こるのだった。 

この問題によりPiyoCast Makerの開発自体が袋小路に入りかけていた。かなりまずい状況だ。 

かくして、抜本的な解決策を見つけなくてはならなくなった。よりシンプルで、オブジェクトへの参照を保持しつつ、間接的な手法で参照を実現しなくてはならない……。 


ヒントは意外なところにあった。USのAS Studio MLで流れていた「NSIndicatorへのアクセス」に関する話だ。ASSにありがちなことなのだが、そのような新しいGUI部品への対応が間に合わず後手に回り、次回以降のOSのメジャーアップデートに持ち越されるケースがままあるのだ(書いていて腹が立つ。これでも純正の開発環境か?)。 

Mac OS X 10.3では「web view」がこれに該当した。「tell web view 1 of window 1」とかいったAS的なアクセス記述が行えないのだ(個人的には無理矢理テクニックで解決している。でないとWebブラウザなど作れたものではない)。 


話が脱線した。Indicatorに話を戻そう。 

正式には対応していないとはいえ、「Indicator」といったAS的な表現「以外では」Indicatorオブジェクトにアクセスする手段は用意されている。苦肉の策といえるが、ないよりはマシだ。オブジェクトに汎用的にアクセスできる「control」という用語があるのだ。 

そこでハタと思いついた。これを、未対応部品への無理矢理なアクセスではなく、雑多なGUI部品に対して同様にアクセスするための窓口として使えるのではないか、と。 

これはうまく行った。しかも記述量が以前の5分の1程度に激減したうえ、実行速度も格段に向上したのだった。まだ改良の余地が残されてはいるものの、汎用のオブジェクトアクセスのテクニックが確立したといってよい(★ASS現代)。 

ASSによる開発は、ASに比べてプログラムの使い回しがしにくいうえに、Xcode上に無理矢理実装されていることもあって、一定の規模を超えると開発効率が頭打ちになってしまう感じだが、こうしたユーザーの自助努力による地道な技術開発によって進歩し続けていくのだろう。メーカーをあてにせずに。

んーー、そうすると「control」のほかに「view」とかでも(text viewとかに)汎用アクセスできそう。よく考えると当たり前のことだが、そこらへんをきっちり解説している資料を……見たことが、、、、

暗号化テスト用ツール「Encrypter」

Mac OS X上で最低限の機能を備えた暗号化ツールを作ろうとして、1時間以上の時間がかかるとはとうてい思えない。 

事実、PiyoCastの開発支援およびシミュレーション用に作成した暗号化ツール「Encrypter」は電車の中で20分ほどで出来上がった。この程度のものなら、AppleScript Studioで一瞬である。 

暗号化キー、オリジナルのテキストデータ欄、暗号化したテキストのデータ欄、あとはいくつかのボタンだけを配置。ボタンが押されたら、それが何かを判別して、各種ルーチンを実行させればいい。 

実をいえば、暗号化プログラム自体はAppleScriptですでに作成してあったので、それにGUIをかぶせるだけでよかったのだ。 

このツールでは、暗号化した場合にデータサイズがどの程度になるかというシミュレーションと、実際にPiyoCastのコントロールデータを暗号化し、ファイルとして保存した場合の取り回しなどを検証した。 

そのため、当初は実装されていなかった暗号化データの「保存」「読み込み」といった機能を後になって実装し、さらにデータサイズがどの程度のものかを表示するインジケータも追加した。あまり厳密な数値を出すわけではないが、だいたいの「目安」が欲しかっただけなので、こんなものでよいのだ。 

PiyoCastのために作成したプログラムは膨大な数にのぼる。EncrypterのようなGUIつきのプログラムはまれで、ほとんどがGUIを持たないAppleScriptのプログラムだ。だが、このPiyoCastの開発で作成したプログラムは、その他のアプリケーション開発で流用できる汎用ルーチンばかりだ。汎用性の高い部品を作り続けることでライブラリが充実し、他のアプリケーション開発の助けにもなる。 

汎用性の高い部品をストックしていくことこそ、開発効率を高めるための最大の秘訣だろう。というか、そんなものは開発の「常識」であって秘訣と呼ぶことすらおこがましい。汎用部品を自分で作るなり拾ってくるなりして、それを収集し、評価し、分類して体系化することこそプログラミングの核となる作業である。 

以前に作成してあった「1年の祝日をすべて求める(振替休日処理つき)」AppleScriptがあったので、新たに「1年の土日をすべて求めるAppleScript」を作成し、これらを合わせて、「年間の休日をすべて求める」AppleScriptを作り、さらに「2005年から2022年までの休日数をすべてリストアップする」AppleScriptに進化させるのに、これまたトータルで30分もかからなかった。 

うむっ! 

休日を算出するAppleScriptは、別に無目的に作ったわけではなく……OmniOutliner上に指定月の業務日誌を作成するものを作ってみて、iCal上のカレンダーを反映させるところまではできたので、その次のステップとして一般的な休日については除外するように作ってみた次第。 

こういう、個人的に使って便利なツールも、一般配布するとなるといちいちドキュメントを書かなければならなかったりで、なんとも(−−;;;

PiyoCast Closed α

PiyoCastのClosed α1をリリース。 

http://mixi.jp/view_community.pl?id=358409 

の「PiyoCast」コミュニティに情報があります。 

当然Mac OS X用。Mac OS X 10.3.9以降対応。

クリックしなくてもPiyoCastの再生制御が可能に?

PiyoCastは、PodCastingの番組中で楽曲を再生するプログラムだが、再生のためにはリンクをクリックする必要がある。 

しばし考えてみたところ、このリンククリックを行わなくても再生する方法はありそうだ。ありそうだ、というよりもすでに「できそうだ」というレベルに迫っている。 

不可能ではない。ただ、ちょっと面倒である。組むのが(汗) 

しかも、ユーザビリティを若干犠牲にする必要も出てくるかもしれない。誰の環境でも同様に再生できるか、ちょっと不安でもある。 

まあ、通常版をリリースした後に研究開発を行うこととしよう。そう、もう「不可能」ではなくなったのだ。

あー、この仕組みを使ってBGMも流せます(クリックしなくても)。 

CPUパワーさえあれば、何トラックも同時に流して、、、なんてことも(^−^;

バーコード印刷がうまく行かない

バーコード印刷機能をPiyoCastのチケット/割引券発行機能に盛り込もうとして、オープンソース&再利用OKの「Barcode Generator」を見つけてきたのだが、これが……配布されているバイナリもソースも、Mac OS X 10.3.9およびMac OS X 10.4.2上で動作しない。 

http://www.lamarchefamily.net/nakedsoft/ 


PiyoCastのリリース予定は、 

(Publicβ)動作検証用の評価バージョン+ひととおりの機能を試せるテスト用コンテンツ。メディア関係者およびPodCast番組制作者向け評価バージョン 

(Release)フィードバック結果を反映させたバージョン。正式リリース 

(Developer)番組制作者側ツール「Link&Control Maker」リリース 

という順番になっている。いまはPublicβに向けて準備を行っている段階だ。クライアント版では、9割どころの話ではなく、9割五分程度の機能が出来ている。残り五分というのが今回のテーマになっているバーコード印刷機能だ。 


話をBarcode Generatorに戻す。 

Nibファイルが日本語化されているので、おそらく日本語ユーザーの誰かがローカライズ作業を行ったものと思われるが、つまり、その時点では動作していたはずだ。 

しかし、実際には動作しない。バーコード印刷といっておきながら、何らかのコードを使用してNSImageView上に画像を作成できればよいのだが……。いや、チケット画像上にバーコードを重ねて印刷といった場合には画像同士の合成を行わなくてはならなくなるのかもしれない。バーコード画像を取得できるようになっても、まだクリアすべきハードルがあるのだろう。 

いざとなれば、Webサービスでそのような機能を提供しているものがあれば、利用してもよいかもしれない。何にせよ、Publicβにバーコード印刷機能は間に合わない。 

逆に、バーコード読み取り&データベース照合のプログラムはすでにAppleScript Studioで作成してあったりするあたりがなんとも……。

GNUのbarcodeユーティリティを拾ってきてmakeしてみたものの、これって出力がPostScriptだったりでイマイチ(ーー;;

んーーー、Javaベースだったらオープンソースのライブラリが……本来JavaのプログラムもAppleScript Studioのプロジェクトに混ぜて、AppleScript側から呼べるはずなのだが……Javaのコンパイルはほとんど行っていないので、なぜか「よそでビルドできるソースがビルドできない」といった問題に直面することが多い、、、、、

うっ! Barcode Generator……別途英語環境のアカウントを作成して実行したらちゃんと動作してるし(ーー;;

Barcode Generatorの作者にバグレポート、、、、日本語にLocalizeしたnibが悪さをしているか、そのLocalizeしたNibのことをプログラム側が考慮しないで処理しているか、あるいはその他。

おお、すぐに作者からThank Youメールが……(^ー^;

PiyoCastアイコン出来

こんな感じか。奥方様が書いてくださった「ぴようるふ」に白いヘッドホンを付けてみた。 

自分:ぴようるふにヘッドホンをつけてみようと思うんだが、下の「ぴよ」の部分につけるべきか、それとも上の「うるふ」の部分につけるべきなのか? 

奥様:「うるふ」じゃない? 

自分:「ぴよ」じゃないの? 

奥様:「ぴよ」に耳ないでしょ! 

……ということで、うるふにヘッドホン装着。

環境設定の画期的な保存方法を考案

AppleScript Studioでアプリケーションを作っていて、確かに簡単なUIなら簡単にできるんだけれども、TabView込みの複雑なUIを作り出すと、とたんに開発効率が落ちて開発意欲が減退するのだった。 

お蔵入りしたり、お蔵入り寸前というアプリもいくつかあるが、たいていは環境設定のUIまわりでコケていたりする。環境設定までは快調にトップスピードで作り続けるのだが(それこそ1時間でソフトが1本開発できてしまうぐらいに)、環境設定UIおよびデータ保存のあたりで急速に開発スピードが落ちてしまうのだ。 


そこに、画期的な解決策を思いついた。 

たいてい、Text Fieldに入っている値を取り出す場合には、 

set a to content of text field "t1" of window "w1" 

などと指定するわけだが、これがTab Viewの中に入ってしまったりすると、その参照は奇々怪々でかつ複雑怪奇なものになる。それをいくつも取り出したりしなくてはならないとなると、もう大変である。頭痛がする、逃げ出したくなる、なんでこんな大変なものになるのかAppleの担当者を締め上げてブン殴りたい衝動に駆られる(もし自分がWWDCに参加しても、担当者を物理的にブン殴るぐらいしか楽しみがなさそうだ)。 

さらに、ものすんごく凝った環境設定画面を大量に作ってしまった場合にはどうなるか? 

発狂する。あんまり複雑なUIをデザインしてはいけないのである。 


だが、これを一気に解決する方法を考案した。まさに画期的な方法だ。 

これまでの方法論では、そのウィンドウ内にどのようなGUI部品があって、どのように値を取り出すかということを、きっちり指定するようになっていた。いわば「専用設定保存ルーチン」とでもいうものになる。 

これを、まったく反対に「とりあえずウィンドウ内にある設定変更が可能な部品の状態をかまわず全部とってこい」というように「汎用設定保存ルーチン」として書き換えてみたのだ。 

おっそろしく処理が簡単になった。いままでの苦労はなんだったのだろう。 

「専用設定読み出しルーチン」「汎用GUI初期化ルーチン」なども用意し、GUI系の処理は一気に簡単になった。しかも、このルーチンはどんなプログラムのどのようなGUI部品を含んだウィンドウに対しても使い回しが効くのである。 

この延長線上に、保存したデータから設定項目値を具体的に取り出すルーチンを作ってしまえばよいだろう。

Copyright by Piyomaru Software, all rights reserved.