Yamamoto Software / 開発メモ

このページでは開発にまつわるあれこれを取り留め無く記述して行きます。
ご意見・ご感想はメールかサポート掲示板にお寄せください。

■2004年 11月 25日

・OmniWebの逆襲その１

　少し滞っていた葉書ABのバージョンアップ作業を再開しました。今度のバージョンの目玉は画像の配置機能です。画像ファイルをどう扱うかで悩みましたが、外部ファイルではなくpreferenceファイルにエンコードして保存する事にしました。環境全てをpreferenceファイルに入れておけば扱いが楽になりますからね。しかし大きな画像が入ると問題では有ります。葉書や封筒に入れる画像ですから小さな物が多いとは思いますが。

　先頃のニュース(*1)によるとFirefoxの躍進によりIEのシェアが減少していると云う事です。葉書ABのダウンロードログを見てみますと確かにFirefoxでのアクセスは増えています。しかし圧倒的に大多数は何といってもSafari。然るにこのニュースではSafariのシェアは1%以下と云う事です。なにか侘しい物を感じますね。ま、これは仕方の無い事ですが、私としてはOmniWebへの言及が無いのが悲しい。何故ならばOmniWebこそが私のメインブラウザだからです。

　私がOmniWebを使い始めたのは古くMac OS X登場以前のRhapsody(Mac OS X Server 1.2)においてです。もはや忘れてしまいましたが、その時はこのブラウザしか利用出来なかったと記憶しています。その時の印象は特に良い物ではありませんでした。日本語サイトの表示にも問題が有ったと思います。そして時は流れMac OS Xが登場し、OmniWebもAquaに成って再登場しました。もちろんSafariの登場以前で、AppleとしてはIEを使えなどと云っていた時代です。IEのと云うよりCarbonの出来に満足しなかった私としては当然CocoaなOmniWebを選びました。ユーザー登録もしました。色々と問題―表示出来ないサイトが有る等―も有りましたがあまり気にならず、というか問題ありのサイトは見ません、何故ならそういうサイトは大抵HTMLコード自体が間違っていたからです。

　そして更に時は流れ、遂にSafariが発表されました。さすがにそのスピードにはビックリです。その時のOmniWebはどちらかと云うと重いソフトで、とても太刀打ちできる代物ではありません。それからが私の長いSafari生活の始まりです。Safariには概ね満足しますが改善して欲しい点が２つ。１つはテキストエンコードの問題。これは当時のOmniWebにも有りましたがテキストエンコードを正しく指定しないWebページの扱いが下手ですね。一応デフォルトのエンコードを変更出来る機能が有りますがこれでは解決出来ません。かと云ってIEの様に文字コードを自動判定せよとは申しません。サイト毎に指定し分けられれば良いのです。２つ目は広告の画像や動画をカット出来ない点。この機能はOmniWebには早い時期から提供されていました。これらが提供されればSafariでも良かったのですが、どうもやる気無いみたいですね。

　不便な思いをしながらもSafariを使っていた私に朗報が届けられました。なんと長らく新バージョンを出さずに沈黙していたOmniが、Safariを超えるブラウザとしてOmniWeb 5をリリースすると云うのです。早速使ってみて愕然としました。こりゃだめだ、重い、重すぎる。起動も遅けりゃページの切り替えも遅い。あんまりだ、と云う訳で哀れOmniWebはゴミ箱行きと成りました。しょうが無いな、これじゃあ。ホントに遅いもの。この時からOmniWebには期待しない様になったのです。（この稿続く)

----------------
*1: http://hotwired.goo.ne.jp/news/business/story/20041124106.html

■2004年 11月 17日

・正にこの世は謎だらけ

　アップルのサイトにMac OS X用オンラインソフトを紹介するページがあります。皆さんもご存知の「Mac OS X ダウンロード」ですが、私にとっては「新しもの好きのダウンロ〜ド」と並んで大変重宝なソフトウェア告知サイトです。しかし、理由は謎ですが、７月を最後に更新を停止してしまったのです。なので、葉書ABもver1.1から更新されずに残っております。このアップルのサイトの威力は抜群で、ここに新規掲載された時はダウンロード回数が１桁増えてます。それだけに残念に思っていたのですが、どうも更新を再開する事にしたらしく掲載申し込みを受け付けていました。早速申し込みましたので、もう暫くすれば更新されるでしょう。
　それにしても、どうして更新を停止してしまったのかが謎です。米Appleのサイトの方は特に更新停止などしていない様子でした。オンラインソフトの扱いについてアップル社内部で問題が発生していたのでしょうか？一体どんな問題が有り得るのでしょう。全くもって謎です。

　最近CSSを勉強しています。実は私は今までCSSを知らずに居りました。プログラマとしては少し恥ずかしい限りですが特に必要を感じなかったのです。それにCSSはブラウザの対応が不完全であると云う先入観も有ったりします。もちろん最近のブラウザ、特にSafariやFirefoxなどは大変強力にCSSを解釈している様なので、使ってみようと思い始めました。そして解説本片手に色々試してみておりますが、これがまた思い通りには行かない物で困っています。もちろんCSSが悪いのではなく私の理解不足が原因なのですが、今の私にとっては謎だらけの代物です。こんな体たらくでは山本ソフトウェアのトップページがまともなレイアウトに成る日は遠いです。

　実はCSSを勉強し始めたのにはもう一つの理由があります。現在、葉書ABとは別に複数のエディタ系ソフトを作成中なのですが、その一つが何を隠そうHTMLエディタなのです。このエディタではHTML/XHTMLをサポートしているのですがそれにCSSサポートを追加しようと考えたのです。どうもHTMLとCSSは密接な関係にあるので無視出来ないと思い始めたのがきっかけです。最もまだHTMLの扱いも不完全でエディタとしての完成はまだまだと云った所ですが、HTML/CSSを快適に編集する日を夢見てCSSの謎と戦っておりますです。はい。

■2004年 11月 15日

・QRコードは面白い

　前回のこのメモでQRコード(*1)のサポートに言及しましたが、早速規格書を入手してみました。まだ全部は読んでませんが思っていたより高機能な規格の様です。小さな矩形領域にバーコードとは比較に成らない情報量を詰め込める点がすごい。次世代バーコードとして今後普及して行くと思われます。最も私は現在の応用例としては携帯電話くらいしか知りませんし、携帯電話も持っていないので実際に利用した事は有りませんが。

　そこで葉書ABにQRコードを取り込む方法を考えてみました。まずQRコードの生成は他のプログラムに任せる事にします。既にQRコードを生成する為のソフトが幾つか公開されていますのでそれらを使う事が出来ますし、それ専用のソフトを利用する方がユーザーにとっても利益が有ると思います。操作イメージとしては、QRコード作成ソフトで作ったQRコード画像を画像ファイルやクリップボード経由で葉書AB側に取り込み、雛形編集機能で雛形の任意の位置に配置する。その際QRコードの内容が判る様な情報を付加すると便利です。そして、ここに問題が有ります。

　複数のQRコードを色々な雛形に配置するには、個々のQRコードの内容が判らないと困った事に成るでしょう。ユーザーはQRコードのイメージを見ても中身が判りません。そこでQRコードを読み取って内容を表示出来れば大変便利です。この部分がQRコードをサポートする上での難しい所で、これからの課題と言えます。まずは画像の配置という形でサポートして、次に読み取り機能を追加すると云う２段階で考えていますが、さてどうなる事か。
----------------
*1: 「QRコード」は(株)デンソーウェーブの登録商標です。

■2004年 11月 09日

・封筒で四苦八苦

　葉書ABで封筒の印刷をサポートしました。やってみると封筒と云うのは結構厄介な物で、まず種類とサイズが色々と有ってどれをサポートするかで悩みます。全てをやるのも大変なので、結局近所の文房具屋の品揃えを参考に角形と長形を数点ずつとしました。最もサイズのバリエーションはプログラムとは関係なくリソースの追加だけなので今後も少しずつ増やして行こうと思います。

　プログラム的な問題としてはベロの存在です。葉書は形とサイズが１種類に固定されているので簡単なのですが、封筒にはベロ―封をするための折り返し部分ですね―があるのでその分だけ印刷がずれてしまいます。しかもベロを伸ばして印刷する場合と閉じて印刷する場合も考える必要が有り、更に悪い事にはベロの高さは規格に成っていない様子です。

　この問題の解決策は、なんとユーザーにベロの高さを決めてもらうと云う物でした。ユーザーとすれば自分で測って、しかもミリ単位で、入力すると云う面倒な作業を強いられてしまいますが、どうも妙案が思いつきません。いっその事印刷する時に180度回転してお尻からプリンタに入れてもらうと云う手も有るかも知れませんが、プリンタのPPDはそういう印刷方法を考慮していないでしょうし、何かと混乱の元に成りそうです。何か良いアイデアが有る方は是非教えて下さい。

　もう１つの問題はイメージの拡大・縮小が必要に成る事でした。今までは葉書だけでしたので不要だったのですが、封筒はサイズも色々で固定サイズでは全てを表示出来ません。表示イメージの拡大・縮小はbounds(*1)のサイズを変更する事で簡単に実現できます。いやー、Cocoaはホントに楽ですね。お次はウインドウのリサイズとスクロールに対応しなくてはなりませんが、これはNSScrollView(*2)というクラスの担当です。そこでNSScrollViewを使ってみたのですが期待通りの動きをしてくれません。すなわち、ウインドウサイズを小さくする時の動作には問題は無いのですが、大きくして行ってイメージ全体が表示された時の動きが問題です。普通の画像表示系ソフトの場合、例えばPhotoShopなど、イメージ全体を表示する時はウインドウ中央に配置します。大抵の人はこの様な動作を期待すると思うのですが、NSScrollViewはdocumentView(*3)の座標系原点に配置します。葉書ABの場合は左下点が原点ですので何とも奇妙な表示になります。左上点ならまだマシなのですが、そうする為には葉書ABの座標系を変更する必要が有ります。それは出来ない相談ですし、NSScrollViewの動作を変えるメソッドは用意されていない様です。これは大変不便な状況と云えます。
　結局この問題はNSClipView(*4)をサブクラス化する事で解決出来ましたが、AppleにはNSScrollViewをもう少し使いやすくして欲しい所です。全般的にCocoaには満足しておりますがこの点は今イチですね。

　今回は少し技術的な話に成ってしまいプログラムに興味の無い方には申し訳無いです。最後に、１１月号のMacPeople誌に葉書ABの紹介記事が載っていました。このMacPeople誌の編集者は大変優しい人達の様でいつも見本誌を送ってくれます。この場を借りてお礼を申し上げます。さて、その紹介記事にQRコード(*5)を作成する「QRこ〜でんネン！」というソフトも合わせて紹介してありました。これを見てQRコードに興味が湧き、葉書ABでのサポートも検討中です。
----------------
*1: ビューの内部座標で矩形領域を表すインスタンス変数。
　他にframeという外部座標での領域を表す変数も有る。
*2: Cocoaの提供するクラスでビューにスクロールバーなどを追加したもの。
*3: NSScrollViewが内部に保持するビューで葉書ABの場合は葉書イメージを表示している部分。
　実はNSScrollViewが直接管理するのではなく間にNSClipViewが介在している。
*4: documentViewをどう見せるかを制御しているビュー。
　NSScrollViewとdocumentViewの間に立って結構頑張っている。
*5: 「QRコード」は(株)デンソーウェーブの登録商標です。

■2004年 07月 30日

・ことえりの切り替え

　葉書ABv1.2をリリースしたのもつかの間、早くもバグ対応バージョンをリリースしました。今回は私の単純なミスが原因でして、以後気を付けたいと思います。このバグを踏まれた方にはお詫び申し上げます。また、何か問題を感じた方は是非お知らせください。宜しくお願いします。

　実は今回のバグの原因は、元々葉書ABには英語リソースを付けていないのですが今回は中途半端な英語リソースが添付されていた、と云う事です。何故英語リソースを付けていないかと云いますと、日本語テキストを英訳するのが辛いからです。英語のテキストは良く読むのですが、それは電子辞書のおかげでして、私の場合英辞郎ビューア(*1)を片手に何とか読んでます。しかし英訳となるとこれはお手上げ状態ですので今後も英語リソースを付ける事は無いでしょう。最も葉書ABは日本語を扱うソフトなので英語リソースを付ける意味はあまり無いでしょうけど。

　さて、本日はことえりの事で気になっている点を１つ。これはあまり知られていない事の様ですが、ことえりにはアプリケーション毎に入力モードを憶えておく機能が有ります。「システム環境設定」＞「言語環境」の入力メニューにオプションと云うボタンがありますが、その中に「キーボードとテキストを一致させる」と云うチェックがあってこれをOnにしておくとアプリケーション毎にモードを憶える様です。この「キーボードとテキストを一致」と云う説明は全く意味不明ですが結果的にはアプリケーション単位でことえりの入力モードを保存してくれる様なのです。これは大変に便利な機能で、例えばエディタで文章を書いている時にターミナルでUnixコマンドを実行したく成った時とか通常ですとモードの切り替えが必要に成りますがこれを自動でやってくれます。

　しかし、この機能をAppleは何故かアピールしません。もしかしてAppleとしては意図しない使い方なのかも知れません。実はこの便利な機能には１つバグが有ります。それはDock Menuをオープンすると何故か入力モードが勝手に切り替わってしまうのです。その状態で一旦他のアプリケーションをアクティブにして、再度元のアプリケーションをアクティブにすると元のモードに戻ります。この点が少し不便なので以前Tell USしたのですが未だに修正された様子は有りません。何か勿体無い感じです。

　来年はTigerの年となります。結構派手な機能満載で話題になるでしょう。それはそれで良いのですが、このことえりの件も何とかして欲しいものです。この様な地味な機能改善の積み重ねがヘビーユーザーにとっては一番利益になるのですが、Appleとしてはそうも云っていられないのでしょうか。ことえりの入力モード切り替えの煩雑さに嫌気が差したら是非この機能を使ってみて下さい。そして便利だと感じたら是非Tell USしましょう。そうする事がMac OS Xを少しずつ良くして行く事に成ると思います。
----------------
*1: http://numata.aquasky.jp/software/eview/
　大変便利なフリーウェアです。ただし利用するには英辞郎辞書ファイルを入手する必要が有ります。これは有料。

■2004年 07月 27日

・iPodでAppleは変わったか

　先日本屋で月刊ASCIIを立ち読みしていたら、なんと最後の方のソフトウェアレビューに葉書ABが取り上げられていました。結構好意的なレビューでしたので嬉しく成ってしまい普段は買わないこの雑誌を買ってしまいました。最もこの雑誌にはMacの記事はほとんど載らないので読む所が余り無いのですが。

　話は変わりますが、新聞、雑誌などではiPodが大変な人気だそうで品薄のため中々手に入らないとか。私の住んでる所は田舎(*1)の為か、あまりiPod人気を実感する様な光景を見た事は無いですが。Appleの製品が人気を得る事に関してはMac OS Xを愛用する身からすれば大変結構な事ですが、私自身はハードウェアとしてのiPodには特に興味は有りません。しかし、ソフトウェアとしてのiPod & iTunes & Music Storeは極めて興味深いし、パソコンの魅力を良く引き出していると思います。正にiPodの成功はソフトウェアの成功と云えるでしょう。Appleの面目躍如と云った所です。

　iPodの成功でAppleの方針は変わってしまった様です。新しい方針は、Macプラットホームにこだわる事よりもWindowsプラットホームを利用する事でユーザーを獲得して行くと云うものです。これからもソフトとハード両面でWindowsをサポートして行く事でしょう。iTunes, iPod, AirMac Expressと来て次はiPhotoあたりでは。iPodにカラー液晶を載せればiPhotoを外に持ち出せます。音楽にそれ程興味の無い層、私なんかそうです、にも受けそうですね。もしかしたらiLife全体をWindowsに移植してしまうかも。果たしてこの方針の転換はAppleの将来にとってどうなのでしょうか？短期的には業績を伸ばすでしょうが長期的にはMacプラットホームの衰退に向かうかも知れません。

　それでも私はAppleのこの方針転換は正しい事だと考えます。今は昔程プラットホームの優位性をアピールする時代では無いですし、少々問題が有ってもほとんどのユーザーはWindowsを使い続けて行きます。いくらMac OS Xが進化してもユーザーが飛び抜けて増えると云う事は考えにくいですね。やはりWindowsは対抗すべき存在ではなく利用すべき物なのでしょう。その結果Macプラットホームが繁栄する事もあり得ると思いますし、そう成って欲しいですね。

　CNET Japanの梅田望夫氏のブログ(*2)にiPodが取り上げられていて、最後にiPodの活字版が欲しいと結んでいます。これには私も同感で、かさ張る本をハードディスクに圧縮して保存でき何時でも検索して取り出せたら。そんなiPodが出たら即買いたいです。別にAppleがやらなくてもソニーとかでも良いのですが、その時は是非ともMacプラットホームもサポートして下さい。ソニー殿、宜しくお願い致します。
----------------
*1: 実は福山市ですが、一応新幹線も止まるので田舎では無いという意見も有ります。
*2: http://blog.japan.cnet.com/umeda/archives/001421.html

■2004年 07月 25日

・PantherからTigerへ

　やっとこさ葉書ABもv1.2にアップデートしてMac OS X 10.2対応を果たしました。テストの為に久しぶりに10.2を使いましたが、さすがにPantherに慣れた身には辛い物があります。Pantherはやはり速いですね。今回のアップデートは今までの不備な点を修正すると云う意味合いが大きかったのですが、次のv1.3は結構意欲的なバージョンアップに成ると考えています。これから基本的な設計を行うのでまだまだどうなるかは判りませんが私も楽しみにしています。

　そして遂にTigerが発表されましたが私の気にしている部分はまだ明らかに成っていません。そんな中でも気になったのがDashboardです。別に気に入ったという訳では有りませんでどちらかというと困ったもんだ、という感想です。なぜならアプリケーションとしての見せ方がまた増えたと云う点で困り者なのです。AquaからSteel、そしてDashboardとどんどんアプリケーションの外観と使い勝手のバリエーションが増えてしまいます。私はこの点が嫌いなのですね。できればAquaだけを追求して行って欲しいのですが、それは叶わない願いなのでしょう。

　最もDashboardの全てが嫌いという訳では無いのです。非常に良い点があります。それはDockの不備を補完する可能性を秘めている点です。現在のDockは小さなアプリケーションをたくさん使うのには適していません。単機能の小さなアプリケーションは私のお気に入りなのですが、Dockはすぐに一杯に成るので実用的で無くなるのです。そんな小さなアプリケーションをDockとは別の枠組みで管理出来ればかなり助かります。が、それはDockの機能を何とかすべき問題なので方向性が違う気がしてます。どうもDashboardはExposeのデモの様な感じですね。

　この様にDashboardにはあまり期待していない私ですが、Dashboardの内部構造については非常に興味深い物があります。ご存知の様にDashboardはHTML+CSS+JavaScriptで作成されるとの事です。という事はWebアプリケーションと同じだと云う事ですね。そうなるとDashboard Widgetはローカルのマシンにインストールする必要はあまり無いのではないでしょうか？Webアプリケーションの様にサーバー経由で利用する事も技術的には簡単なのでは、と類推しております。Appleがこの線を狙っているとしたら面白いです。将来多くのデスクトップアプリケーションはサーバー側に移行すると云われて久しいですが我々は相変わらずアプリケーションをダウンロードしてはローカルディスクにインストールしています。アプリケーションをサーバーから直接利用する、しかもオンライン、オフラインどちらでも。そんなソリューションをAppleなら提示してくれそうな気もします。そしてそれはパソコン業界の新たなトレンドを作って行くのではないでしょうか？

　妙な妄想はこれ位にして、現実的に考えると果たしてTigerは速いのか遅いのか。Cube G4 450MHzの私としてはこの点が重要です。これに対する確たる回答は有りませんがPantherより遅くは無いのでは、と云うのが私の予想です。今まではバージョンアップの度に速く成りユーザーを喜ばせて来ましたが今度はどうでしょうか。来年の春には明らかになるでしょうけど、今から楽しみです。