3月29日にも配信を行っていますが、かなりの数のエラーが出ています。その後に配送を行っているような気もしますが、もし、29日のメールを受け取っていらっしゃらない方がいたら、御一報ください。こちらから再度送ります。Webサイトに、指定した日付の発行号を再送する機能をつけてほしいと御要望をいただいたりもしているのですが、すみません、まだ作っていません。だけど、やっぱり昨日はあちらこちらでサーバダウンとかしていないでしょうか。メールが遅れないというのは、DNS関係のトラブルであることがままあるわけですから、例によってクラックが集中したのかもしれません。EZWebのサービスが落ちていたことは記事で出ていますけど、それだけじゃないと思います。天気予報じゃないけど、ネットワーク混雑予報や、地震速報に対応するものがあればいいなとやっぱり思ってしまいますね。
それから、AppleのSample Codeのページで新しくたくさんの更新コードが掲載されています。以前のものをProject Builder対応やCarbon対応というものもありますが、まずは御自分で作っているものと関連がないかをチェックされてはどうでしょうか。MDOnlineではピックアップして順次紹介をしていくつもりです。
（新居雅行 msyk@mdonline.jp）
AirMacソフトウエアのVer.1.3の日本語版が公開された。Ver.1.3では、PPPoEによる接続やDHCPクライアントIDを設定した接続が可能になった。また、管理ソフトウエアの形態についても変更されている。PPPoEはフレッツ・ADSLで採用されている。ケーブルテレビのネットワークではDHCPのIDを要求する場合が増えている。これらのネットワークに、AirMac BaseStation経由で接続することができるようになるが、ネットワーク側の事情もあるので、接続に対してはプロバイダに確認はしておく必要がある。
関連リンク：AirMac 1.3
カテゴリ：ネットワーク
電子掲示板の続編、お待たせして申し訳ありません。サンプルはもう出来上がっているのですが、解説テキストの方で手間取っています。すみません、もう少々お時間をください。ううう(苦悶)。
今回、「WebObjectsで飯食ってます」のテーマからちょっと外れますが、Webで商売する人にとって避けて通ることのできない、インターネット接続についてお話します。
私のところは、現在、OCNエコノミーでインターネット接続しています。128kベストエフォート型、というやつですね。満足というわけではないけれど、とりあえず使えないわけではないし、ってんで毎月約３万円を支払ってきました。
で、今度引っ越すことになりました。引越が決まった時、そこにはケーブルテレビが入っているということで、これで一気にブロードバンドか？ と思ったら…「インターネット接続のための設備を設置するスペースが建物に用意されていないので、残念ながらテレビ放送だけです」という回答が。古い建物ならともかく、新築なのに…今どき、ケーブルなのにインターネットに配慮としていないというのは、理解に苦しみますよね。ただ放送を見るだけであればCS放送の方が料金が安いので、CATVは申し込みませんでした。でも、入居説明会の時、「インターネットができる！」って大書きされたチラシを配って加入を勧誘していましたが....いいのかしら？。
後は光ファイバーかADSLですが、これは新しい建物が光収容になっているということで、草々に諦めていました。
さて、ガス水道電気など、永遠に終わらないかのように思われる山のような手続きの中、引っ越し2週間前になってようやく思い出し、OCNサポート窓口に連絡を取ってみました。すると、移転工事に約１ヶ月かかるとのこと。それどころか、もし局内に空きがない場合には数カ月かかることもあるとか。
で、この記事を思い出しました。
◇ZDNet-わが家のブロードバンド化計画（1）──やってこないハズのADSLがやってきた
http://www.zdnet.co.jp/news/0103/09/adsl_honda.html
光収容でもADSL接続できるかもしれない！
ということで、さっそく、東京めたりっく通信に申し込みをしました。オンラインの申し込みフォームに、引越が近付いていることと、光収容でもこの記事のように接続された事例があるそうなので藁にもすがる気持ちで申し込んでいます、と、付記しました。
申し込み品目は、「AdvancedADSLシリーズSOHO1600」。下り1.6Mbps、上り500Kbps、グローバルIP 8個または16個、のサービスです。
◇東京めたりっく通信：Adbanced ADSLシリーズ
www.metallic.co.jp/service/adadsl.htmlhttp:/
申し込み翌日に返事があり、ともかく実現に向けて努力してくれるとのこと。まず最初に、NTTに調査を依頼する必要があるので、「証明書」をFAXで送るよう指示がありました。証明書は、たしかにその住所に居住しているということを証明するもので、最新の電話料金請求書か、登記簿謄本(法人での申し込みの場合)が必要、とのこと。運悪く、電話料金請求書はすでにシュレッダーにかけてしまった後なので、登記簿謄本を送ることにしました。ちなみに、会社の登記簿謄本はページ数が多くて、FAXするのも大変です。なので、住所も記載されていて公的書類としての捺印もされている印鑑証明書はどうかと提案したのですが、これは前例がなく、今回は時間的な余裕がないということで、登記簿をFAXしました。
さて、それが3月29日の午後3時。年度末かつ週末かつ引越シーズンというほぼ最悪の条件の中、どういうことになるのか、楽しみにしています。楽しみというか、緊張と不安ともに吾にありと言いますか。
なお、OCNからは、なんとか引越日に工事を間に合わせます、との連絡が入りました。ということで、セーフティ・ネットは確保できました。
＿＿＿＿＿＿＿＿＿＿＿＿
余談ですが、３月は大変忙しい一ヶ月でした。自社製品開発と受託開発がピークに差し掛かっているだけでなく、WebObjectsセミナーの講師として何度か呼んでいただきまして。3月23日のアップルコンピュータセミナールームでの事例紹介は申込開始当日に満席になるという盛況でしたし、その他、文字どおり北は北海道から南は沖縄まで、毎週飛行機でどこかにでかけているという状況でした。沖縄では、土砂降りの雨にも関わらず、大勢の方に参加していただきました。他にも「地方在住なので初台（アップルコンピュータ本社、WebObjectsセミナーが定期的に開催されています）へは行けないけど、どうしてもWebObjectsを勉強したい」ということで、お知り合いの方同士でお金を出し合って出張講習会を受講されたグループもありました。
WebObjectsへの関心の高まりを感じています。
WebObjects業界は慢性的な開発者不足で、関係者が顔を合わせるたびに「誰かいいヒト居ない？」っていうのがデフォルトの挨拶になっています。各地でWebObjectsが盛り上がって開発者が増え、少しでも今の状況が改善されることを業界一同、切に希望しております。
アナタも、WebObjectsで、飯、食ってみませんか？（笑)
[倉橋浩一/テクニカル・ピット]
関連リンク：WebObjectsのページ
カテゴリ：倉橋浩一、じつはWebObjectsで飯食っています
アスキーは、REALbasicのMac OS X対応版についての動作状況を掲載した。Mac OS X向けのREALbasic 3.0日本語版暫定版を公開しているが、Mac OS X 10.0で動作させると不具合が生じるとしている。まず、メニューなどの文字のメッセージが文字化けてする。また、ツールパレットからコントールをウインドウにドラッグ&ドロップすると、REALbasicが終了してしまう。いずれの不具合も、REALbasic 3.1で解消するとしている。3.0でこうした決定的な不具合があり3.1で修正されるのであれば、日本語版のVer.3.0の正式版は出ないで、Ver.3.1として正式版が出るということになるのが順当な線だろう。日本語版のREALbasic 3を快適に使うのはもう少し先になりそうだ。
関連リンク：REALbasic日本語版
カテゴリ：REALbasic
REALbasic 3.1のベータ版としてリリース5が登場した。今回のリリースアップでの新しい機能は、Windows向けのコンポーネントでいくつか挙げられている。他は、バグ修正やが中心のアップデートとなっている。なお、Real Softwareのサイトでは、REALbasic 3.0は、Mac OS X Public Beta向けに作られたものであり、Mac OS X 10.0で変更があったため、10.0ではREALbaisic 3.1を使うように記述がある。
関連リンク：REALbasic 3.1b5 Release Note
カテゴリ：REALbasic
HFS+ボリュームのいちばんの売りは、なんと言っても255バイトまでのファイル名を扱えることだった…が、初めて搭載されたMac OS 8.1ではそのメリットはまったく生かされていなかった。それは、「ファイル名は31バイトまで」というMac OSの従来の縛りがあり、仮にボリュームでそうした制約がなくなったとしても、アプリケーションなどが対応しないと意味がないからである。また、Mac OSの方も、なぜか64バイトまでの構造体を用意していたのだが（理由は後述）、いずれにしても、255バイトまでのファイル名に対応する道のりは遠かったと言えるだろう。
さらに、Mac OS 9では、255バイトのファイル名を扱えるAPIセットが用意され、アプリケーションとしては255文字までに対応するということが可能になった。Javaの実行環境であるMRJでは、ここで255バイトのファイル名に対応する。しかしながら、肝心なFinderがやっぱり31バイトまでだったため、255文字を使えるアプリケーションは皆無だったのではないだろうか。対応する気になれないというやつだ。
だが、Mac OS Xが発売された。Mac OS Xでは、Finderはもちろん、システムのすべての領域に渡って、ファイル名は255バイトまでの文字列が許される。しかしながら、古いFile Managerの機能を使っている場合には、そこで制限が出てくる。Carbonアプリケーションを移植している方などは、ファイル名の問題も要注意だと言えるようになってきた。
たとえば、StuffIt Deluxで、31バイトを超えるファイルを圧縮してみよう。すると、アーカイブファイルでは31バイトに切り詰めてしまう。また、31バイトを超える長さのファイルが、tar形式のファイルにあったとしても、やっぱり31バイトに切り詰めてしまう。システム標準のユーティリティでさえこうした状態なのであるが、やはり開発者としてはいつかはクリアしないといけない点だけに、ファイル名の問題解決の目処を立てたいところだろう。現状のバージョンのJeditのように、32バイトを超えるファイル名は扱えないとしっかり警告を出すという場合もある。
そこで、Carbon系プログラマに対しての255バイト対応についての説明を行いたい。なお、CocoaやJavaは最初から255バイトのファイル名の文字列に対応しているので、基本的にはこうした問題は発生しない。
□31バイトファイル名とFSSpec
File Managerの変遷はいろいろあるが、System 7あたりで、FSSpec構造体を使って、処理するファイルを特定する手法が定着したと言える。このFSSpecは、ボリューム、所属フォルダ、ファイル名（あるいはフォルダ名）という3つのパラメータ記録する構造体だ。ボリュームや所属フォルダはID番号なのであるが、ファイル名は64バイトの文字列である。なぜ31バイトなのに64バイトになるかと言うと、ここに部分パス名やフルパス名を指定して、構造体を構築するという機能を組み込んだからである。そのときに、なんで256バイトにしなかったのかと言ってももう遅い。FSSpecは255バイトのファイル名を特定するためには利用できなくなってしまったのである。このFSSpecを基調にしたFile ManagerのAPIを一般的に使うようになってしまった。
では、HFS+のボリュームに、31バイトを超える長さのファイルを作成したとしよう。Mac OS 9でもJavaを使えば作成できるし、Mac OS XだとFinderでファイル名を書き換えればよい。その場合、FSSpecの世界から見ると、ファイル名を切り詰めて、31バイトの長さのファイル名を持つファイルだとして参照できるようになっている。また、そのときに、末尾の拡張子は保存したまま、拡張子直前の文字を取り除く。単に取り除くだけでなく拡張子の直前に#2345のようなシリアル番号を振ることで、文字列を取り除いたことによるファイル名の重複をさけるようにもなっている。だから、HFS+で31バイトを超えるファイル名のものは、Mac OS 9のFinderでは切り詰めてシリアル番号が振られた31バイトのファイル名で見えるわけだ。このファイル名は、FSSpecベースのAPIでは有効なのである。
このFSSpecを使ったファイルアクセスの機能は、Mac OS XのCarbonでも利用できる。その意味では、従来のアプリケーションのファイル処理についてはほぼ手を加えなくても、Mac OS Xでは実行できるようになっている。しかしながら、それはそれで問題の元になる可能性がある。たとえば、StuffiItのように、ファイル名をアプリケーションの中で扱いしかもユーザに見せるような場合には、Mac OS Xでは切り詰めたファイル名を出してしまう。一般にはそれでは許されないことだ。また、文書ファイルを開くと文書ファイル名を、ウインドウのタイトルに表示する。そこでも、Finderで見えるファイル名と微妙に違うきりつめた名前ではどうだろうか。もっとも、ほんとうに255バイトのファイル名をつけてしまった場合にはウインドウのタイトルには入らないにしても、いずれにしても、ファイル名の255文字対応は、Mac OS Xでは必須となっている。
なお、従来はファイル名はシステムのエンコードだったために漢字などはShift-JISの2バイトで保存されていた。HFS+では、ファイル名はUNICODEとなり、しかもUTF-8でのエンコーディングとなっている。従って、アルファベットなら255文字と言えなくもないが、全部日本語のファイル名なら、85文字にしかならない。255だとほぼ無限大とも言えるけど、85文字と言うのは青天井とは言いがたいような気がする。
□255バイトのファイル名を扱えるAPIセット
Mac OSの時代にHFS Plus APIなどとして公開は始まっていたが、255バイトまでのファイル名を扱えるAPIはすでに使える状態になっている。そのキーになる、ファイルやフォルダを特定するための構造体は、FSRefというものになった。この構造体の中身は隠されており、単に80バイトのデータブロックであるということしか分からない。ただし、FSRefを使う限りは、HFS+であろうがUFSであろうが統一的に扱えるということになっている。つまり、ファイルシステムの違いを隠ぺいした構造体である。きっと将来に渡ってもOKというのを狙っているのだろう。たとえば、ファイル名が1024バイトまでに拡張されても、FSRefならシステム側が対応することで同じAPIで対応できるのではないかと思う。
それじゃあ、FSSpecをFSRefに置き換えればいいかと言うと、そんなことは絶対にない。FSSpecではファイル名などを構造体のメンバ変数にアクセスすることで得ていたが、FSRefではそれはできない。ファイル名を取り出すにしても、APIコールを呼び出すようになっている。従って、ファイル処理関連の部分は、ほとんど書き直すことになると言っても良いだろう。
APIについてはすでに公開されているのでそれを参考に作業にかかることも可能だ。また、File Managerを知っている方は、パラメータブロック系の複雑怪奇なAPIをまた1から覚えなおすのかとうんざしするかもしれないが、FSRefを使ったAPIはかなり整理されているので、その点は安心してよい。ただし、必ずパラメータブロックは使う必要があると言える。以前はパラメータブロックはローレベルのファイル処理という感じだったが、FSRef対応のAPIでは、たとえばファイルタイプやクリエイタを得るような作業でも、パラメータブロックは使う。ただ、たくさんのパラメータブロックはないので、明解さについては明らかにFSRefの方が上である。
（続く）
カテゴリ：Mac OS X, Browsing Mac OS X
□Resource ManagerはFSRef対応していない
ここで注意しないといけないのは、リソースというものの扱いだ。リソースはMac OSでの独特なシステム機能と連動したデータであったが、Mac OS Xではその位置付けは大きく変わったと言えるだろう。だが、従来のようなリソースの利用も可能で、Resource Managerは利用できる。HFS+のように複数のフォークに対応したボリュームだけでなく、UFSボリュームでもリソースは見えないところに別ファイルを作るなどして、アプリケーション側から見れば、リソースフォークとしてきちんと使えるようになっている。ただし、Resource ManagerはFSSpecでのファイル指定にしか対応していない。そして、どうもFSRefとしてリソースの処理を行う機能は付け加えられる気配もない。つまり、もはや過去との互換のためだけに用意されている機能なのである。Mac OS Xのパッケージ化するファイルではもはやリソースは定義しなくても、ファイルタイプとアイコンの対応付け、つまりBNDLリソースの設定内容などを記述できるようになっているのである。つまり、リソースフォークのないアプリケーションもありとなっている。
リソースは確かにユニークな機能ではあるが、メモリを節約したりやりくりするという点では昔のハードウエア環境ではそれなりに意味があった。しかしながら、仮想記憶がより充実したMac OS Xでは、リソースであろうが、それを一気に読み込んでメモリに展開しようが動作上はあまり違いはないと言える。むしろ、後者の方がパフォーマンスはかせげるのではないかと思われる。別々のファイルに保存するなんて…と思うのなら、それはパッケージという仕組みを利用することで、利用者からは1つのアイコンとして見えるようにできることで対応できるだろう。オブジェクト指向が当たり前になっているだけに、リソースとしてデータの固まりをシステム側で管理しなくても、それに匹敵する機能は言語やAPIで用意されている。だから、リソースとして保存していたものは、これからは別のファイルにふつうにデータフォークに保存して出し入れするという方が問題は少ない。特に、異なるプラットフォームを経由するようなインターネットの世界を考えた場合、リソースの存在によってMacintoshが特種扱いされてしまうということも避けることができる。やはり標準に従うという考え方からすると、リソースの存在は特異なものに見える。
リソースがなくなることを惜しむ声もあるが、これまでもユーザサイドには見えなかったものだ。使う側にとってリソースであろうが別の手法であろうが関係ないわけだし、開発する側も新たに作る部分からはリソースを別の手法に置き換えればいいだけである。ある程度の年月をかけて、リソースは使われなくなるだろう。それを見越してResEditのアップデートは止まったのかも知れない（とは言え、止まったのはえらく前なんだけど…）。
この項は続きがある。次回は実際にFSSpecとFSRefの違いをより詳しく見ていくことにしよう。
カテゴリ：
Tech Info LibraryおよびTech Info Library-Jに掲載されたMac OS X 10.0関連の文書のうち、ユーザアカウントやログインに関する文書を紹介しておこう。以下は文書のアドレスと要約だ。
◇Mac OS X 10.0: Do Not Use "root" as a User Name
http://til.info.apple.com/techinfo.nsf/artnum/n106240
ユーザー名として「root」を使ってはいけない。この名前はシステムで予約された名前であり、コンフリクトを起こす。
◇Mac OS X 10.0: ログインのヒントを作成する
http://til.info.apple.co.jp/cgi-bin/artnum?id=106231JC
◇Mac OS X 10.0: Creating a Login Hint
http://til.info.apple.com/techinfo.nsf/artnum/n106231
パスワードのヒントは、ログインをするときに、間違ったパスワード入力を3回行った場合に表示される。
◇Mac OS X 10.0: Startup Manager で起動ディスクを選択する
http://til.info.apple.co.jp/cgi-bin/artnum?id=106178JC
◇Mac OS X 10.0: Choosing Startup Disk with Startup Manager
http://til.info.apple.com/techinfo.nsf/artnUm/n106178
optionキーを押しながらMacintoshを起動すると、起動するボリュームを選択するStartup Managerが利用できるが、同じボリュームに、Mac OS 9.1とMac OS Xがインストールされている場合、それらを選択することができない。それぞれのOSにある起動システムの切り替えの方法を使って、起動するシステムを選択しておく必要がある。
◇Mac OS X 10.0: ユーザのパスワードを変える方法
http://til.info.apple.co.jp/cgi-bin/artnum?id=106156JC
◇Mac OS X 10.0: How to Change a User’s Password
http://til.info.apple.com/techinfo.nsf/artnum/n106156
管理ユーザでログインをしているときであれば、システム環境設定の「ユーザ」のパネルでパスワードを変更できる。パスワード欄はパスワードの文字列数に限らず、13個のドットが表示される。
◇Mac OS X 10.0: システム起動時に自動的にログインする方法
http://til.info.apple.co.jp/cgi-bin/artnum?id=106164JC
◇Mac OS X 10.0: How to Log In Automatically at System Startup Time
http://til.info.apple.com/techinfo.nsf/artnum/n106164
Mac OS Xではインストール時に指定したアカウントでの自動ログインが設定されているが、アカウントを追加すると、自動ログインの機能をオフにするかどうかをたずねるダイアログボックスが表示される。自動ログイン時に利用されるアカウントとパスワードは、システム環境設定の「ログイン」のパネルで設定できる。
カテゴリ：Tech Info Library-J, Knowledge Base（旧TIL）, Mac OS X
QuickTime for Java SDKの、QuickTime 5に対応したバージョンが公開された。QuickTime for Javaは、QuickTimeの機能を使ったアプリケーションなどをJavaで作成できるようにしたものだ。つまり、JavaからQuickTimeを直接利用できるライブラリである。Mac OS X 10.0には、QuickTime 5が搭載されているが、QuickTime for Javaも標準で搭載されている。従来のMac OSではQuickTimeのAPIはC言語が基本だったので、QuickTime for Javaはあまり注目されなかった。しかしながら、Mac OS XではCocoaのプログラミングをJavaできるが、CocoaからQuickTimeの機能を使うには、QuickTime for Javaを利用するのが1つの早道となり、従来のMac OSとは位置付けが異なると言えるだろう。Mac OS版のSDKは、JavaDoc形式のドキュメントと、サンプルコードが含まれている。サンプルコードは多方面な機能について大量に入っているが、Demosというアプリケーションを起動して、解凍して利用するようになっている。
◇QuickTime for Java SDK
ftp://ftp.apple.com/developer/Development_Kits/QTJava_5_SDK.sit.hqx
◇QuickTime for Java Windows SDK
ftp://ftp.apple.com/developer/Development_Kits/QTJava_5_SDK.zip
カテゴリ：アップルからの開発資料, Java, QuickTime
Tech Info Libraryに掲載された情報によると、iTunesを起動しているときに、CDを取り出すと、カーネルパニックが発生してしまうことがある。Appleはこの問題については認識しており、解決する方向で動いているとしている。解決するまでは、CDの取り出しはiTunesが起動していない時にしてほしいとのことだ。（ただし、筆者の側で試してみたけども、カーネルパニックは起らなかった。）
関連リンク：http://til.info.apple.com/techinfo.nsf/artnum/n60833
カテゴリ：アプリケーション, Knowledge Base（旧TIL）
Technical Q&Aに、GDBを使って、2台のマシンを使ったMac OS Xのデバッグ作業を行う方法についての文書が掲載された。attachコマンドで別のマシンに接続する時、IPアドレスでの接続はサポートされておらず、ホスト名を適切に与えないといけない。このとき、DNSの環境がしっかり設定されていない場合には、ホスト名の使用ができない。そのような場合には、NetInfoのディレクトリに、ホスト名をIPアドレスに変換する設定の登録を追加する方法が書かれている。つまり、hostsファイル的な設定をMac OS Xで行う方法の解説としても、参考になるだろう。
関連リンク：QA1019：Can’t attach during two-machine debugging with GDB
カテゴリ：Technical Q&A, 開発情報
Mac OSの仮想記憶で使われるVM Storageという名前の不可視ファイルを特定する方法がTechnical Q&Aの文書として掲載された。ドキュメント化されていないGestalt Managerのセレクタを使って、ファイルへの参照を得ることができる。ファイルへのFSSpecを得るサンプルプログラムも掲載されている。
関連リンク：ME07：Finding the VM Backing Store
カテゴリ：Technical Q&A, Mac OS 9