Windows

そろそろ新しい開発環境を

Snow Leopard が8月末に発売され、そして新しいiMac先週発売、Windows7も発売されました。

私の今の開発環境は、iBook G4 1.33GHz メモリ:1.5GB HDD:40GB モニタ:12inch OS: Mac OS X Leopard。

そろそろスペック的に厳しくなってきましたし、Snow LeopardのGCDをはじめとする新しい技術や、もちろん、Windows7にも少なからず興味はあります。

そんなわけで、近いうちに iMac 21.5inch の上位モデルを買おうと思います。これで全て解決。Bootcampは12月頃対応するそうなので、その時期になったらWindows7も買おうと思います。ただ、ちょっと高いので、見送る可能性もなくはないですね…。Windows7の価格にはちょっとがっかりです。

Macを選ぶ理由

ここ最近、「どうしてMacを使ってるの?」といったような質問をよくされるので、ここにまとめておこうと思います。

1. 開発環境が付属している
Mac OS X のインストールディスクには、開発ツールが付属しており、gcc をはじめとする、さまざまな開発ツールをインストールすることができます。Windows では、gccをインストールするのですら面倒なので、これはありがたいです。

2. ターミナルがある
Mac OS X は、UNIXベースのOSであるので、ターミナル(端末)があります。UNIXサーバーにSSH接続するときには、これがないと話になりません。Windowsでもいくつかのクライアントがあるようですが、日本語文字コードまで満足に扱えるものを見たことがありません。ちなみに、OS Xのターミナルは、設定によって文字コードを簡単に切り替えることができます。

3. さまざまなファイルを開ける
Mac OS X や、そのアプリケーションは、多様なファイルフォーマットに対応していることが多いです。特に、文字コードに関しては、様々な文字コードを扱うことを前提に作られたアプリケーションが多いので、文字コードで困ることはあまりありません。psdがプレビューできるのは、ありがたかったです。

4. ネットワークの設定が楽
基本的に、ネットワークがあれば勝手につなごうとするので、自分から設定しなくても楽にネットワークに繋がることが多いです。それに加えて、例えば、無線LANに接続するネットワークによっては、特殊な設定が必要、といった場合に、あらかじめ設定を作成しておけば、メニューバーから簡単に設定を切り替えることが出きるので、楽にネットワークに接続できます。

5. Portsが使える
UNIX系でお馴染みのパッケージマネージャであるPortsが使えます。ということは、UNIX系のパッケージもインストールして使えるというわけです。

6. 変な日本語をあまり見かけない
Windowsでは、頻繁に変なエラーや、変な日本語を見かけますが、Macではそれほど見かけません。Microsoftの翻訳センスには、いつも驚かされます。

7. Exposé,Spacesが便利
ウインドウをサッと片付けたり、一面に並べたりするExposé、デスクトップを何枚も使用できるようにするSpaces。どちらも大変便利な機能です。これがないだけで、他のOSを使ったときのイライラの原因になったりします。Windows 7 では、Exposéより便利かもしれないというタスクバーがあるらしいので、それに期待をしてみましょう。

あと、「隠す」を使うとデスクトップがすっきりするので、これも好きです。

8. iPhone と連携できる
Mac上のアプリケーションとデータを同期できるので、いろいろと楽です。iPodの音楽データはもちろん、カレンダー,写真,ブックマーク、などなど

9. 画面が綺麗
フォントや画像がギザギザしないことが多いので、全体的に画面が綺麗に見えます。フォントは好みにもよるので、ぼやけて見えて嫌な人も結構いるようです。ウインドウが固まって真っ白になる、なんてこともありません。アニメーションが滑らかです。

10. トラックパッドが使いやすい
ノートブックの話になりますが、トラックパッドが非常に操作しやすいです。マウスなしでもいけます。

よくある誤解

1. Mac はクリエーター系に向いている
昔はクリエーター向けのアプリケーションが充実していたのかもしれませんが、今は Windows のほうがアプリケーションが豊富です。自分の分野のアプリケーションが、どれくらい揃っているか確認してみましょう。今は、ペンタブで描くならSAIがいいですし、DTMもWindowsの方が格段に安く済むらしいです。


2. インターフェースが良い
たしかに、Macのインターフェースの方が、Windows よりも優れているかもしれませんが、些細な違いでしかないでしょう。


3. 操作が簡単
Windows よりもシンプルにまとまっているかもしれませんが、しょせんはパソコンのOSのひとつ。はじめてパソコン触る人にとっては、WindowsでもMacでもそう変わらないと思います。

4. 右クリックがない
普通にあります。

5. 高い
最近は、そこまで高くないと思います。

.NET Frameworkのセキュリティ

.NET Frameworkを動作させるときには、その実行場所がどこなのか注意する必要があります。なぜなら、ネットワーク上に実行ファイルが存在していると、実行できる動作が制限されるからです。

例えば、C++のCLRプロジェクトをネットワーク上に保存しようとすると、プロジェクト作成の際に警告のメッセージが表示されます。C++の場合はCLRプロジェクトを作成しても、ネットワーク上に存在していると実行できないからです。

しかしC#では、ネットワーク上にプロジェクトを作成しても、一部の制限をのぞき、問題なく動作してくれるようですが、プロジェクト作成の際に警告は出ないので、例外が発生しても何が原因かわかりにくいです。

そういうわけなので、.NETのプログラミングではプロジェクトの作成場所に注意を払う必要があるようですが、今のところこのことがMSDNのどこに書かれているのかがわかりません。従って、詳細も不明なので、.NETプログラミングする人は、とりあえずプロジェクトはローカルな場所に作成した方が良い、ということだけ覚えておいた方がいいでしょう。

Web インスペクタ for Windows

前回紹介したSafariのWeb Inspectorですが、Windows版のSafariにも付属していました。興味のある方はぜひ使ってみましょう。

WEB インスペクタ

Windows版のWeb インスペクタの表示方法は、メニューから「編集」>「設定…」を選び、「詳細」のパネルの一番下にある、「メニューバーに[開発]を表示」にチェックを入れ、メニューに表示された「開発」から、Web インスペクタを選択します。

ちなみに、Mac版のSafari 3.1から、Windowsと同じように環境設定からデバッグメニューをオンにすることができるようになったようです。環境設定のパネルの「詳細」から、パネルの一番下にある「メニューバーに”開発”を表示」にチェックを入れることで「開発」のメニューを出すことができ、Web インスペクタを使用することができます。


関係ない個人的な話ですが、一昨日カラオケではしゃぎすぎて、昨日朝から体調崩して病院で点滴打ってきました。体調が戻るまで、あと数日かかりそうです。私が体調悪くするときはいつもそんな感じで、何かに夢中になりすぎて体調に気を配っていない時、というよりは、夢中すぎて悪くなったことに気づいていないって感じな気がするので、今後はテンション上がり過ぎてるときには注意したいですね。

とりあえず、ライブラリ開発の方はSystem.Net.IPAddressクラスから手をつけ始めていて、Dnsクラスあたりまで作ったらコミットしようかなぁーとか考えていますが、なんかIPAddressクラスの出来がいまひとつなのと、やはり配列の仕様を早くどうにかした方がいいですね。やはり人任せにしていては早く進まないですね。私も何か打開策を考えた方がいい気がしてきました。

Mono

みなさんはMonoプロジェクトをご存知でしょうか?Monoは、オープンソースのマルチプラットフォーム.NET互換環境を開発しているプロジェクトです。現在はまだ、Windows.Formsが動くかどうかというあたりまで進行しているプロジェクトですが、今後の動向が気になるプロジェクトです。

さて、そのMonoですが、当然Mac OS XのMonoも存在し、今日はこれでちょっと遊んでみました。ダウンロードはここからできます。興味のあるWindowsのユーザーの方、Macのユーザーの方、その他のOSの方もダウンロードして試してみましょう。Monoにはいくつかのコンパイラが搭載されているらしく、Monoをダウンロードすれば.NETアプリケーションを作成することもできます。というよりは、まだMonoは.NETの一部分しかサポートしていないので、自作のアプリケーションでなければ動かないでしょう。

今回は、最近よく目にするSystem.IO関連のDirectory.GetFiles()を使ってみました。コードはMono付属の何かでコンパイルできるC#だったと思います。

using System;
using System.IO;
using System.Collections;

public class HelloWorld
{
	static public void Main ()
	{
		foreach ( String s in Directory.GetFiles(Environment.CurrentDirectory) )
		{
			Console.WriteLine(s);
		}
	}
}

OS Xでのコンパイルの仕方は、mcsコマンドにファイルパスを渡します。問題なくコンパイルできたら、.exeの実行ファイルが作成されるので、今度はmonoコマンドに実行ファイルのパスを渡せば実行できます。実行結果は次の通り、問題なく動作します。

/Users/********/Desktop/.DS_Store
/Users/********/Desktop/.localized
/Users/********/Desktop/Google、コラボレーションツール「Google Sites」立ち上げ - ITmedia News.webloc
/Users/********/Desktop/Start - Mono.webloc
/Users/********/Desktop/hello.exe
/Users/********/Desktop/novi's Blog iPod touch に W-SIM を接続してみた.webloc
/Users/********/Desktop/temp
/Users/********/Desktop/ 人間に興味があるんじゃなくて,どちらかというと知識に興.textClipping
/Users/********/Desktop/「2ちゃんねる」と「ニコニコ動画」のひろゆき氏が語...webloc

これだけじゃつまらないので、試しにこのMono for Mac OS Xでコンパイルした実行ファイルを、Windowsにそのまま持っていって実行してみました。驚くことに、というか当たり前ではありますが、そのままの実行ファイルでWindowsでも問題なく動作します。WindowsにはMonoが入っている必要はなく、.NET Frameworkが入っていさえすれば動作します。実行結果は次の通りです。

C:¥Documents and Settings¥aaa¥.unicode_cache_283a1d41.dat
C:¥Documents and Settings¥aaa¥.unicode_cache_7ffe4658.dat
C:¥Documents and Settings¥aaa¥hamcore.se2
C:¥Documents and Settings¥aaa¥ntuser.dat
C:¥Documents and Settings¥aaa¥ntuser.dat.LOG
C:¥Documents and Settings¥aaa¥ntuser.ini
C:¥Documents and Settings¥aaa¥PUTTY.RND
C:¥Documents and Settings¥aaa¥ReafMe.txt
C:¥Documents and Settings¥aaa¥reglog.txt
C:¥Documents and Settings¥aaa¥vpnserver.exe
C:¥Documents and Settings¥aaa¥vpnsmgr.exe
C:¥Documents and Settings¥aaa¥vpn_server.config

これができるのなら、今度はWindowsのVisual Studioを久しぶりに立ち上げて、どこでビルドすればいいのか操作にしばし迷いつつ、なんとか実行ファイルを生成したところで、WindowsからMac OS Xにそのまま実行ファイルを持っていき、monoコマンドで実行してみたくなるわけです。

結果は、これも問題なく動作しました。さすが.NETと言ったところでしょうか、Windowsプラットフォームが普及したように、.NET環境も同じように普及する可能性が見えますね。

というわけで、今後もMonoプロジェクトにはかなり期待をしています。今後は.NET Frameworkを使ったアプリケーションが多く作られることが予想されますし、そのアプリケーションがWindowsだけでなく、そのままMac OS Xでも動くとなれば、Windowsより圧倒的にソフトの少ないMac OS Xにとっても非常に有益なことです。Paint.NETとかMac OS Xで動かしたいです。

ちなみに、MonoのWindows.Formsはある程度実装されているようなので、インストールすれば実行できると思うのですが、インストールが難しかったので途中で挫折しました。

WPFとCore Animation

WPFとは、Windows Presentation Foundationの略であり、.NET Frameworkの一部であるが、文字通りインターフェースを担当するフレームワークとなっているようだ。この前からたびたび話に出てきている.NETのデータバインディングも、ここに含まれているようであるが、実はLeopardで大々的に披露されたCore Animationとほぼ同様のものも備えているらしい。

その前に、もう少しWPFについて触れておくと、WPFはMac OS XでいうCocoaのAppKitと同じようなもので、ユーザーインターフェースを担当しているものである。AppKitとの大きな違いは、WPFはXAML(ザムル)と呼ばれるXMLで記述する事ができる点だ。このことは、インターフェースを設計する開発ツールを容易に作成できる事を意味する。

そして、WPFのアニメーションもまた、LeopardのCore Animationとほとんど同じなのである。次のリンク先を見てもらえばわかるだろうと思うが、基本的にプロパティをアニメーションさせているあたり、まるで同じである。

第 4 回 私のアプリが動き出す! ~インターフェイスにダイナミックな表現を~(WPF)
プロパティベースのアニメーション(Core Animation)

こうして見るとWPFのアニメーションとCore Animationには違いが無いように見える。少なくとも今日調べた段階では、WPFは動画とアニメーションを同期する事ができるが、Core Animationはできない。Core Animationは何百枚ものレイヤーを同時にアニメーションさせることができるが、WPFはどれほどのパフォーマンスなのかわからない。といったところだろうか。

今日はこの本を立ち読みしてXAMLについて勉強してみました。

XAMLプログラミング WPFアプリケーションの概要と開発 XAMLプログラミング WPFアプリケーションの概要と開発
高橋 忍 川西 裕幸

ソフトバンク クリエイティブ 2007-04-07

Amazonで詳しく見る by G-Tools

インターフェース体験

最近は「直感的なインターフェース」というのが流行りなのか、iPod touchを始めとするApple製品から始まり、インターフェースが語られる場所ではよく見かけるキーワードとなっているようです。しかし私は、インターフェースにとって直感的な操作方法を提示する事は必要な事ではありますが、それよりもインターフェースを操作したときの「体験」の方が重要だと最近考えています。

例えば、iPodのクイックホイールです。これはよく直感的な操作だという意見が見られますが、決してそんな事はないでしょう。少なくとも、私が最初にiPodと手にしたとき、操作方法が数分わかりませんでした。我々は、ボタンを押して操作するというのが当たり前になりすぎています。何も知らない人がiPodを手にしたとき、クイックホイールを指でなぞって操作できる人は、一体どれだけいるでしょう?私には到底直感的に操作方法がわかるとは思えません。

先ほどiPodの操作が数分わからなかった書きましたが、私が操作できるようになるまでに何があったのでしょうか。それは、インターフェースの体験と学習です。iPodを手にした私は、ボタンで操作する事に疑いの余地もなかったので、ボタンを押して項目を選択しようとしていました。しかし思った通りに操作する事はできません。どうすればいいのだろうかと、しばらくいじっていると、ある事に気がつきました。ボタン上で指がずれたときに、選択されている項目が連動して動くのです。もしかして、ボタンを押してまわすのかと思って最初はやったものの、すぐに指でなぞって操作する事に気がつきました。

ところで、iPod touchはインターフェース体験と、直感的な操作の両方を実現している、すばらしいインターフェースです。つい最近、ようやく私もiPod touchをお店の展示品で操作させていただきましたが、確かに直感的と言えるにはふさわしい操作をすることができます。しかし、それ以上に大切なのは、その直感的な操作を体験させるインターフェースにあると思うのです。例えば、スクロールのフリック操作ですが、いくら直感的な操作だとしても、もし画面が指に合わせて動かなかったらどうでしょうか?動作が正しく伝わっていないのかと思ったり、そもそも操作することが面白くなく、ただの指で操作する事できる珍しい製品として幕を閉じていた事でしょう。

MacがWindowsより優れている事について、よくインターフェースが挙げられます。しかしながら今日、両方のOSを見比べてわかる通り、ほとんど似通ったものです。メニューバーが固定、それともドキュメントウィンドウに付くか、そんなことは些細なことで、その人の嗜好によるのではないかと思ったりします。このように、インターフェースを見ているだけではMacの優位性を語ることなど難しく、むしろWindowsの方が優れている部分も十分にあるのではないかと思います。

しかし私は、先に述べたインターフェース体験の部分ではWindowsよりMacの方が優れていると考えています。例えば、どちらのOSもアプリケーションを起動する方法は一緒で、アプリケーションアイコンをダブルクリックします。このとき、Windowsの場合、画面に即座に変化がありません。対してMacは、即座にアプリケーションアイコンがDockで飛び跳ねて、起動しているという状況を表してくれます。アプリケーションを多重起動してしまった経験は、誰にでも一回はあるでしょう。

また、ウィンドウをドラックしてみましょう。ウィンドウをドラックしているのに、ウィンドウが動いてくれない、そんなことはないでしょうか?右クリックをしているのにメニューが出てこない。タスクバーでウィンドウを選択しているのに切り替わらない、さらに、いつの間にか二回以上押していて、ウィンドウがタスクから出たり入ったりする。そんなことはないでしょうか?対してMacは、いくらアプリケーションがおかしな状態でも、ウィンドウの動作はいつだって滑らかです。ウィンドウがドラッグの操作についていけない場合など、そうそうありません。また、タスクの切り替えもスムーズで、目的のウィンドウになかなか切り替わらないなんてことは、よっぽどの事でない限りありません。

Macは、ユーザーがインターフェースに対して行った操作を即座に画面上に反映し、インターフェースの体験をさせてくれます。この体験こそが、インターフェースの学習を容易にさせ、また、インターフェースに対するストレスの軽減、そして見た目だけでは語れないMacのインターフェースの使いやすさに繋がっているのだと思うのです。

Mac OS X Leopardは、Core Animationと呼ばれる重要な技術が追加されました。これはスムーズなアニメーションを簡単に利用できる技術で、iTunesのCover Flowから始まり、さまざまなところで活躍しています。この技術はもちろんデベロッパも自由に利用でき、インターフェースの体験を作る事に大いに貢献する事でしょう。

ブラウザ上での縮小画像

昨日ちょっと気になって、ブログがきちんとIEでも表示されているかWindowsで確認してみたのですが、WindowsとMacでブラウザ上の画像の表示のされ方にだいぶ違いがあることに驚きました。大きな画像を小さく表示する際、よくサムネイルとオリジナルの2つの画像が用意されているのはこのためだったんですね。


Windows XP IE7で1024*768の画像を縮小表示させた場合

windows ie6 thumbnail


Mac OS X Safari で1024*768の画像を縮小表示させた場合

Mac OS X thumbnail

いつも全く気にせず画像を縮小表示させてやっていましたが、これはちょっと不便ですね。リンク先は大きな画像、ページへ貼付ける画像は縮小用の画像を用意したほうがいいでしょうか。Windowsだと縮小画像だとよく画像がわかりませんからね。

ところで、VistaのIE7では綺麗に表示されるんでしょうか?どなたかVistaを持っている方がいれば、コメントくれたらうれしいです。あと、もしかしたらIE以外のブラウザを使うと綺麗に表示されるかもしれませんね。少なくとも、Windows版SafariではMacと同じように表示されました。

アプリケーションインストールで比較する Windows – Mac OS X

WindowsからMacへ移行したときに、アプリケーションのインストールに結構違いが見られたので、それを今日は紹介しようと思います。アプリケーションのインストールには主に、インストーラーを使ったインストールと、単純コピーのインストールがありますが、今回は単純コピーする方についてXPとMacで比較することにします。本当はVistaとMacを比較したかったのですが、Vistaは持っていないので後でにします。

今回インストールするアプリケーションは、2chブラウザにしました。WindowsはJane Style、OS XのほうはBathyScapheです。


1.各アプリケーションを公開しているサイトへ行く

Jane Style :: site

BathyScaphe :: site


2.ダウンロードする。

Jane Style :: download

BathyScaphe :: download
Safariはリンクをクリックすると即ダウンロードが始まります。Macのアプリケーションはディスクイメージ(.img)、またはディスクイメージをzip圧縮したもので配布されるのが一般的です。


3.保存先を指定する。(Windows only)

Jane Style :: saving
保存先を指定するのが少し面倒だったりするときもあります。しかも、保存した場所を見失ったりすることもよくあることです。Windowsは好きな場所に保存することができます。

Safariでダウンロードしたファイルはデスクトップに保存されます。他の場所に保存した人には不便かもしれませんが、ほとんどの場合はデスクトップで問題ありません。Macは保存先を指定する手間がありません。


5.ダウンロード中…。Windows,Macともに同じような画面です

Jane Style :: downloading

BathyScaphe :: downloading


6.解凍する

Jane Style :: unpacking
適当な解凍ソフトや、デフォルトで装備されているソフトを使って展開します。

BathyScaphe :: downloading
ダウンロード後、Macはzip,ディスクイメージともに自動的に展開,マウントされます。ダウンロードしたzipファイルは自動的にゴミ箱へ送られます。BathyScapheはzipではなく直接ディスクイメージで配布されているので、自動的にディスクイメージがマウントされます。


7.ユーザー許可(Mac Only)

BathyScaphe :: permit downloading
Macは、zip展開直前、またはディスクイメージマウント直前に、アプリケーションが含まれる場合は、続けるかどうかの許可を求めてきます。


8.適当なところへ移動する

Jane Style :: copy
ダウンロードした場所が必ずしもアプリケーションを置きたいところとは限らないので、自分の気に入る場所に移動したりします。Windowsは、このようなアプリケーションを置く場所はあらかじめ用意されていので、好きなところへ置きます。整理ができない人は散らかってしまったりします。Vistaでは検索があるので問題ないでしょう。

BathyScaphe :: copy
Macは、アプリケーションフォルダにアプリケーションをコピーします。また、ディスクイメージ上でアプリケーションを起動して確認することもできるので、コピーしてからゴミ箱に捨てるなんてことにはなりません。Macは、アプリケーションフォルダ以外のフォルダにアプリケーションを置くことももちろん可能ですが、ディスクイメージ上にアプリケーションフォルダへのエイリアスが用意されているように、アプリケーションフォルダにコピーすることが当たり前です。


インストール完了。

Jane Style

BathyScaphe


おまけ

Jane Style :: shortcut
Windowsの場合、フォルダへのアクセスがあまり簡単でないので、ショートカット(エイリアス)を作ってデスクトップに置くと、簡単にアプリケーションを立ち上げられるようになります。たくさんデスクトップアイコンがあるのはこのためです。

BathyScaphe :: spotlight
Macの場合、比較的アプリケーションフォルダへアクセスしやすく、アプリケーションがフォルダでなくてアイコンになっていて見つけやすいので、アプリケーションフォルダに置いても、Windowsよりは簡単にアプリケーションを立ち上げることが出来ます。ただ、やはりちょっと手間取るので、spotlight(デスクトップ検索)を使って立ち上げたりすることができます。Windowsも、Vistaならスタートメニューに検索が付いているので、MacとWindows、両方この方法が使えます。便利ですね。

もちろん、Macで最も簡単にアプリケーションを立ち上げる場所は、Dock(デスクトップ下に表示されているアイコン群)です。毎日使用するようなものは、Dockへ登録して使います。


アンインストール

このタイプのアプリケーションは、Windows,Macともにゴミ箱へ捨てればアンインストール完了です。Macの場合、アプリケーションの設定やデータは、/Users/username/Library/Application Support/以下に保存されていることがほとんどなので、アンインストール後、再度使うとき設定が消えてないことがほとんどです。もちろん、完全に消したい場合は、ここのアプリケーションデータも削除しましょう。Windowsの場合は、アプリケーションによってデータの保存の仕方が違うので、どのようにデータが保存されたり、保存しておくかは、アプリケーションにしだいです。


まとめ

WindowsはMacに比べてセキュリティがうるさいので、てっきり何回も警告されることを想像してたのですが、意外にMacの方が1回警告されただけで終わっています。Windowsはなんでも設定次第ということでしょうか。

WindowsとMacの大きな違いは、やはり配布のファイル形式とインストール先でしょう。Windowsは、zipでフォルダが一般的で、Macはディスクイメージでバンドル形式が一般的です。バンドル形式というのは、アプリケーションフォルダをひとつのファイルに見せかけているのもで、Macのアプリケーションが単一のファイルに見えるのはこのためです。パッケージの内容を表示すると、アプリケーションの構成が見えます。

Windowsの場合、アプリケーションを置くところは任意ですが、Macの場合はアプリケーションフォルダで決まっていると言って過言ではありません。そのためか、そでないか、Windowsはアプリケーションの整理が結構面倒になってきたり、ショートカットを無駄に作成、さらにリンク切れ、といった面倒な自体も起きたりします。

今回はこれで終了です。今度は、インストーラー型のアプリケーションで比較しようと思います。

フレームワーク

フレームワークと聞くと、MacではCocoa、Windowsでは.NET Frameworkをフレームワークと呼ぶのは微妙なところですが、少なくともMFCなど、そういうものを想像されるかと思います。そして、オブジェクト指向プログミラングでアプリケーションを開発しようとすると、たいていなんらかのフレームワークを用いることが多いと思われます。

またもCocoa基礎ガイドからの引用ですが、フレームワークを用いたプログラミング方法について端的に表した一文がありました。

ライブラリコードを自分のプログラムに組み込むのではなく、自分のプログラムコードをフレームワークに組み込むのです。

Cocoa基礎ガイド > Cocoaプログラムへの動作の追加から引用。(PDFはP93)

実際にオブジェクト指向で作られているフレームワークを使ったことの無い人には想像しにくいと思うのですが、要するに、アプリケーションのテンプレートが用意されていて、それを改変するようにプログラミングしていって、アプリケーションを開発していきます。

少し話はそれますが、この状況はAppleのiLifeのアプリケーション郡と似ています。iLifeのアプリケーションは、たいていAppleが用意したすばらしいテンプレートや素材を元に、DVDディスク,音楽,映像,WEBサイトなどを作っていくようになっています。もちろん、そういうテンプレートの融通の利かなさに絶望感を抱くものもありますが、少なくともiLifeにはそれに関してのハズレは無いと思います。特にテンプレートが強制されるiDVDは最初は使えないと思ったものの、意外なところまでテンプレートを改変できたりして、驚いたというより、簡単にいい感じのエフェクトになったりして、使ってて面白いといった経験もあります。ヘルプファイルに、テンプレートを使用したくないときのこともきちんと書かれているのは気が利くところです。もちろん、一番シンプルなテンプレートを選んで…という解答でしたが。

結局何かと言えば、フレームワークを使ってプログラミングをする人は、上の引用部分で挙げたような、「フレームワークを使ってプログラミングをするのではなく、フレームワークに組み込んでプログラミングするということ」を念頭に置いてプログラミングすることです。これを実践するには、どうしてもフレームワークについての深い理解が必要になってきます。オブジェクト指向プログラミングの行き着く先は、フレームワークでプログラミングをするということが多くなると思うので、まずはフレームワークへの理解が、アプリケーション作成への一歩となるのではないかと思います。もちろん、基本的なプログラミングができることが前提の話ですが。そういうわけで、私もCocoa基礎ガイドをじっくり読んでいます。

そしてもひとつ、ライブラリ開発者の視点から見てみると、アプリケーションのテンプレートを提供すると言ってもいい、ライブラリの設計が非常に重要になってくるということです。ActiveBasicのライブラリは.NET Frameworkと同じようになるように開発を進めているのですが、正直な話、.NET Frameworkがいいと思ったことはありません。これは.NETでプログラミングしたことがないことに加え、まだ.NETの全容をつかめていないからというのが原因なのかもしれませんが、そもそも複雑過ぎて把握するのが難しいです。というか、MSDN探してもCocoa基礎ガイドに相当するものが見つからないので、そういうものがあるのならば、どなたか報告してくれたらありがたいです。

そういえわけで、.NETいい噂はあまり聞かないので、それに沿ってActiveBasicのライブラリを作成していることについては、少々不安になってきます。さらに、おそらく今後.NETと同じにできないところも出てくる可能性は高いです。そう考えると、いっそのこと完全に独自のライブラリを作ってしまおうという考えもなくはないのですが、なぜかここで思考停止します。おそらく、.NETより優れるライブラリを作れるわけがないとか、そんなことを無意識に考えているのかもしれません。とまあ、常々.NETに対するこんな疑念が尽きません。本格的に再参戦する来年までには、暇な時間を割いて結論を出したいところです。

自分のブログを見てると毎回ついつい長文になっているので、これはこれでどうなのかと思いつつ、今日は特に長文になってしまったしだいです。