ラスト2になりました。これからもみなさんはMacにかかわりをもたれると思いますが、いろいろな意味で厳しい時代であることは言うに及びません。もはやコンピュータは成熟した商品だということに世の中はなっているのですが、私はあちらこちらで書いていますけどこれは大きな間違いだと思います。コンピュータメーカでの技術に限界が見えたのかもしれませんが、だからといってこれ以上発展しないと決めつけるのはあまりに自己中心的なことです。だけど、考えてみれば、そのように大手のみなさんが閉そく感をもたれることは、大きなチャンスです。昔は大変なことでも、今となっては実に簡単にできるようなことになっているかもしれません。たとえば、マイクロソフトは大金をはたいてWindows NTというマイクロカーネルベースのOSを作り上げ、やっとのことでMS-DOSという自分で作り上げてきたプラットフォームからの移行ができました。だけど、Mac OS XやLinuxの事例を出せば、今時、OSを開発するなんてマイクロソフトがかけたお金よりもはるかにコストがかからないことは明白です。もちろん、単に安いだけじゃなくっていろいろあるとは言え、ほんの5,6年前に「OSを作る」と言ったら笑われていたでしょうけど、今だと「UNIXをベースにして」と言えば、けっこう現実的な話なわけです。こうした大きな転換はOSに限らずあると思います。
大きなビジネスはとても魅力的ですが、結果的にはバブルか大損かというところで落ち着くという気がします。エンロンは極端としても、ユニクロの拡大路線はいつまで続くかが見物でしょう。マクロソフトだけが例外的にうまくやっている気がしますが、シェアを上げ過ぎるとその後は単に市場が縮退するのに身をまかせるだけになってしまいます。1%のシェアを2%にするのはエキサイティングで楽しいものですが、95%のシェアを96%にするのは苦しくつらいものです。バブらない、かつゆとりを持つというビジネスモデルができれば、それは長年に渡って収益を出しながらも楽しんで仕事ができるということにつながります。もっともそういうことができれば苦労はしないで済むという話はあるのですけど、Windowsブームとインターネットブームでかき回されたコンピュータの市場も、やっとゆとりをもって取り組む世界になってきたかという気もします。前に説明した通り、大手が閉そく感を持ってくれると、小さな会社はやりやすくなりますから、ビジネスチャンスはどんどん広がると思います。ましてや低いシェアこそ、おもしろビジネスが展開するタネになると思います。そんな中、私もいろんなネタに食い付いていきたいですし、みなさんも積極的に展開されてはどうでしょうか。Windowsの人とMacの人という単純な切り分けはまありよろしくはないですけど、仕方なくWindowsを使っている人たちと、好きでMacを使っている人たちでは、結局のところ仕事のできが違ってくるんじゃないかと思います。それがプラットフォームが包含するマインドであり、だからこそMacにこだわる私たちに存在意義があるのでしょう。
（新居雅行 msyk@mdonline.jp）
SwingなどのJava標準のライブラリを使ったアプリケーションなどを作る場合、やはり基本的にはクロスプラットフォームという点を意識してのこととなるだろう。だが、Mac OS向けのアプリケーションで、OSに最適化させるためには、その部分の非互換は目をつむるとしても、OSの機能を利用したくなる。Mac OS Xでは従来のMRJで用意されたクラスもある程度は継続して利用できるようになっているため、その機能を使うのが1つの手段だ。たとえば、Finderで文書ファイルをダブルクリックしたり、あるいは終了のためのAppleEvent対応のハンドラメソッドを定義するということは、Mac向けのアプリケーションでしか機能しないが、やはり必要となる。
ただ、こうした標準のJavaになく、Mac OS X向けの機能を提供するクラスが充実していればいいのだが、MRJのクラスはどちらかといえば、最低限必要なものをなんとか揃えているという感じでもある。OpenDocumentのAppleEventやファイルタイプやクリエイタの処理はなんとかなっても、ある程度以上のこととなると、どうしてもシステムのAPIコールを利用することになる。JDirect 3やあるいはJNIという手段もあるが、少し面倒なプログラミングが必要になる。お手軽な方法はコマンドラインレベルで動くツールを作ってそれを呼び出すという方法もあるが、管理の手間は増える。
一方、Mac OS XのネイティブフレームワークであるCocoaもJavaで利用できる。Cocoaを主体にしたプログラミングでは、Javaの標準ライブラリを利用する場面も多いのであるが、その逆のこともしたいと考えるかもしれない。つまり、SwingなどのJavaの標準ライブラリを主体にしたアプリケーションで、Cocoaのクラスを使いたいという場合である。たとえば、特定のWebページをシステムで設定されている既定のブラウザで開いて表示させるといったような場合である。以前はMRJにopenURLというメソッドがあったのだが、なぜかMac OS Xではサポートされていない。ならば、CocoaのNSWorkspaceのopenURLメソッドを使うのが楽だろう。NSWorkspaceクラスはJavaでも定義されているからだ。だが、単にクラス名をソースに書く以上にいくつかの設定が必要になる。以下の方法は、Project BuilderでSwing Applicationのテンプレートで作成したアプリケーションで、Cocoaのクラスを利用できるようにするために必要な設定をまとめてみた。
まず、JavaのソースにCocoaのクラスを使ったコードを書き込むためには、コンパイル時にCocoaのクラスのインポートが必要なので、ソースの最初に以下のステートメントを記述しておく。
import com.apple.cocoa.foundation.*;
import com.apple.cocoa.application.*;
そして、ソースコードにたとえばボタンをクリックしたイベント処理メソッド内で次のようなコードを書く。これによってブラウザで指定したページを開くが、エラー処理などは割愛させてもらっている。NSWorkspaceについては、クラスの解説ページを参照してもらいたいが、openURLが既定のブラウザで指定したページを開くメソッドだ。
NSWorkspace ws = NSWorkspace.sharedWorkspace();
try {
ws.openURL(new java.net.URL("http://mac-ome.jp/"));
}
catch(Exception ex) { }
そして、アプリケーションのターゲットの設定を開く。「プロジェクト」メニューから「アクティブターゲットの編集」（Command+option+E）を選択する。そして「アプリケーション設定」のタブを選択し、「詳細設定」ボタンをクリックする。ここで、プロパティが一覧されているが、Java→ClassPathの項目を1つ増やして「/System/Library/Java」というパスを、クラスパスに増やしておく。これによって、com.apple.cocoa関連の実際のクラスが参照できるようになるようだ。
なお、Cocoaのフレームワークを利用するように設定しても、実行時にCocoaのクラスを使おうとした段階で、クラスの定義がないと言う実行時エラーになってしまう。/System/Library/Javaを見ればわかるように、ここからパスが切られていて、classファイルそのものが存在している。つまり、Cocoaのclassファイルへの参照については、このパスが組み入れられていないといけないのであるが、各種のJavaのシステムプロパティはどこも参照していない。おそらく、Cocoa-Javaのアプリケーションだと、Javaを呼び出すネイティブのバイナリあたりでこうしたお膳立てはしているのだと思われるが、Swingアプリケーションではそのあたりを自分で設定しないといけない模様だ。だが、コンパイル時には参照をしているのかもしれない。結果的に、Cocoaフレームワークをビルドフェーズに含めなくても、Cocoaの利用はできてしまっている。
なお、Cocoaのクラスは、実際にはその先のObjective-Cのコードを呼び出しているため、メモリ管理は純粋なJavaのクラスと違っている。基本的には、Javaからも同じように利用できるような配慮はされているため、気にしなくてもいいことは多いかもしれない。Javaでは自動的なガベージコレクションを行うなど、メモリ管理をプログラマがほとんど気にしなくてもいいような仕組みが大きな特徴である。一方、Objective-Cはメモリ管理をプログラマが行う必要があるが、Java的な動作もできるし、自分でメモリを確保して解放するということもできる。
いずれにしても、Cocoaのクラスを生成した場合、Javaのメモリ管理下でオブジェクトが生成されるわけではないことをよく理解しておこう。何かの問題が発生したときには糸口になるかもしれないからだ。また、動作がきちんと行われてもコンソールに何らかのメッセージが出てくることある。また、スレッド関連の処理をする場合には、NSAutoreleasePoolの解説も参照してもらいたい。このクラスは、Objective-Cではメモリ領域の管理クラスだが、Javaでは独特の使い方をする。Cocoa-Javaでプログラミングをする人は、JavaとObjective-Cのつながりをどうやっているかという文書はやはり目を通しておく必要があるだろう。CocoaのProgramming Topicの中に、「Java/Objective-C Language Integration」という項目があるので、それを参考にしてもらいたい。
∽∽∽∽∽∽∽この項、以上∽∽∽∽∽∽∽[新居雅行]∽∽∽∽∽∽∽
カテゴリ：Cocoa, Java, Java Watch on the X
オンラインでの出版は、コンテンツの自由度が高くなることがあることを以前に説明した。もちろん、カラーでも値段は変わらないとか、あるいは動画もOKといった、内容を伝達する手段の違いもあるのだけど、むしろ目を付けたのはビジネス的な側面である。いままで5000人に売らないと成り立たなかったコンテンツが、500人でも成り立つし、もしかすると、50人でも成り立つ場合があるかもしれない。もちろん、従来の出版形態でも、自費出版というものはあったが、これは多くは自伝を記念に…といったものであって、ビジネスである側面は薄い。そうでなくて、少数の出版でもビジネスになると言うことを狙ったのである。もっとも、日経BP社や矢野経済研究所が発行していた1冊数万円〜数十万円の書籍といったものも昔からある。それと同じようなスケールのビジネスでもあるわけだ。世の中には参考になるモデルはいっぱいあるものだ。
Macintosh Java Report（MJR）はその意味ではまさにセグメントが極めて明確なニッチ市場をターゲットにしたものである。製品ポジションも明確だと、市場性が測定できる。だけど、ビジネスにするには、それなりのスケールが必要だ。もちろん、MJRのようなタイトルをいくつか作る…とも考えたけど、MJRも後半にさしかかり次のステップに行きたくなった。そこで考えたのが、Macプラットフォームの開発者向けコンテンツである。Macintosh Developers Journal、MacTechの日本語版がなくなってしまい、専門媒体がなくなってしまった。Mac専門誌にプログラミングの話題が掲載されることもあるけど、入門向けか趣味的なところが一般的であり、開発者にとっての必要な情報は限られる。そうした状況で、Mac OS X Serverの初期版が発売されての困惑があり、さらにその先のMac OS Xがどうなるということも極めて不透明になった。そこで、いずれはMac OS Xにフォーカスした開発やシステム情報を提供することにした、開発者向けという点を中心にした媒体の市場が見えてきたのである。これまでの経緯だと、Appleから系統立って情報は出てこないだろう。それを整理して解説するだけでも十分に媒体になると思った。また、いろいろな雑誌の人たちと仕事をする関係上、雑誌の人たちのMac OS Xに対する冷めた見方もあったので、Mac専門誌でのフォローも時間がかかると考えた。Mac OSがいいとかMac OS Xがどうこうという以前に、MDOnline出版時期の段階で、私の中では数年後はXに移行するならもはや受け入れるしかないと言うことを基本スタンスとして取り組んだというわけである。
ただ、大きな問題は、マックの開発という世界が広すぎることだ。むしろ、オンライン出版としては、MJRのようにもっと絞りそして単価を上げる方がいいということも一理あり、その点はまだ会社に部署があった時代なので上司とも議論を尽くした。
だが、MDOnlineの概略をまとめていくに従って、MJRとの大きな違いが分かってきた。MJRはコンテンツであるが、MDOnlineはメディアなのである。つまり、書籍と雑誌の違いがあるようなものだ。ニュースを届けるメディアであり、ノウハウやレビューなどもある。どこまで行けるか分からないけど、媒体を運営するということで、より存在感を強めることもできる。Mac FanやMacWIREに対抗しようと思ったわけではないが、共同戦線を張って、Mac専門媒体の中にMDOnlineもあるというところを狙ったわけである。
つまりは「編集長」になるということでもある。「情報メディア出版局」というちょっと怪し気なセクション名はMJRの時に考えたものであるが、それまでは「コンサルティング事業部」を名乗っていたけど、自分の肩書きは「情報メディア出版局 編集長」ということにした。自分で名乗ったものではあるが（笑）、悪い気はしないとはしゃいでしまった。他の媒体の編集長と同じく、企画や運営はしているが、違いとしては原稿を書いて営業までするところかもしれない（笑）。編集長と言えど、スタッフは自分ひとりなのだから。
メディアとコンテンツは対立するものではない。ただ、メディアというのはコンテンツを含んで「メディア」でなければならない。どこが違うかという点は実はいろいろあるのだけど、MDOnlineをやりながら気付いたことは、メディアというのはグルーブ感が必要であるということだ。あるネタでも、あの手この手で紹介し、ほめてみたりけなしてみたり、詳しく紹介したと思ったらからめ手を使う…単に情報を伝える以上に、そうしたノリとグルーブ感が必要なのである。また、それは独自性も要求される。パクリはすぐにばれる。
だが、一方で、MDOnlineは楽しみで読む人だけでなく、実用性も重視した。忙しい開発者が、ざっと見て必要な情報がアクセスできるというような、実利も追い求めてみた。そのあたりは、テキストの書き方や見出しの入れ方などに工夫が必要なのだが、ある意味、面白くする演出は極力控えるというのも、媒体のノリの一つとして組み入れてみたのである。ネタ的なことやメールニュースという側面からも、ありうる1つの形態であったかと思う。そのため、場合によって意図的に短くも書いている。
また、細かく説明することは、枝葉にこだわり徹底的に掘り下げるということを心掛けた。オンラインは文字数の制限はない世界である。雑誌だとページ数が決まっているけど、そういう制約がないのなら、あえて短くまとめる必要がないときにはじっくり書くということをやったわけだ。
いずれにしても、記事作成のテクニックは、知りうること、できることをありとあらゆるものを投下した。幸い、10年以上も前になるが雑誌の編集をしていたし、当時は専門的な記事から経営者インタビュー、さらにはケーススタディから芸能人取材まで、なんでもやる必要があるセクションだった。けっこう大変だったけど、2年半の間にけっこういろいろなことを勉強できたことが、役に立ったのである。その後はライター業中心だったから、使わなかった技術も多かったのだが、MDOnlineが出版できたのは、まさに昔取った杵柄そのままなのである。
内容的には、最初の頃から最近までは、他のニュースメディアに配信をしていることを考慮して、配信可能な形で、配信先でもそれなりに違和感ないものという記事を入れる必要があった。ただ、ネタ的には正直いってひとりでまかなう範囲を軽く超えていたのも事実だ。がんばって勉強するにしても限度はある。そのため、外部執筆者をなるべく増やしたかったのだけど、予算がとれないなどもあって、いろいろご迷惑をおかけしたということもある。だが、あの手この手をつくしたのは確かだ。最近ではPDFと記事が同時に執筆できる仕組みを作ったりもしたが、やはり元はライターだけに内容についてはこだわりたかった。
コンテンツとして成功したかどうかは、自分では判断しづらいものだ。もちろん、ベストを尽くしたのはもちろんだけど、カバーしきれなかった範囲ももちろんある。だが、評価していただく声もよくいただくので、それなりのものではあったのではないかとも思っている。話にならないコンテンツで廃刊したのなら、全く話にならないのだけど、それなりに惜しまれる内容だったことは自分としてはある意味での満足感でもある。だが、それだけに惜しいのではあるが。
∽∽∽∽∽∽∽この項、以上∽∽∽∽∽∽∽[新居雅行]∽∽∽∽∽∽∽
カテゴリ：業界動向