1月2007

ライブラリ開発行程

最近ライブラリの開発スタイルが定着してきたようなので、すこし紹介というか、メモというか、まとめてみようと思います。

  • 実装したいところを決める
  • MSDNで仕様を把握
  • APIを探す
  • コーディング開始

基本的に、.NET Framework2.0のSystem内の移植をしますので、既に仕様は決まっているも同然です。

1の実装したいところは、ある程度優先順位があり、勝手に決まってしまいますが、今はIO関連の実装をしています。Formsは大変そうなので、IO関連が落ち着いてから手をつけようと思います。

2のMSDNで仕様を確認する作業が、最も時間を使う作業です。そもそも私は、.NET Frameworkでプログラムを組んだことがないので、まずどんなクラスがあるかとか、どういう構造になっているか、もっと初歩的なことで、この用語の意味は何かとか、結構低次元なところから始まります。この時点で、あまりにもわからない用語が多過ぎたり、他の部分と連携が多くて実装できそうにないところは諦めて、1に戻り、また実装したいところを模索します。

MSDNである程度把握できたら、今度は3のコーディングでどのようなAPIを使うかを探します。実装の半分くらいはWin32API+αみたいな感じでできていることが多いので、使えそうなものを探します。見つからなかった場合、自分で実装できるものなら実装しますが、APIが必要そうな物で見つからないこともあるので、探すのもなかなか時間がかかることもあります。ちなみに、PathクラスのGetFullPathのように、GetFullPathNameというAPIが存在するのに気づかずに、自前で実装してしまったのもあります。これはどっちのがいいか、後で考えます。

ここまで来て、いよいよコーディングです。コーディングは、全体から見れば、メインというよりは最後の仕上げに近いかもしれません。APIをラップしたようなクラスの場合、簡単に実装していきますが、DateTimeクラスのように、アルゴリズムを考えながら実装していくものもあります。DateTimeの場合、なかなか計算方法が思いつかなかったので、コーディング作業よりも考えている時間のが長くなりました。

そして、このとき必ずやることがデバッグ作業。たいてい、ひとつのメソッドを作成したときに、そのメソッドのテストを行います。後からではなく、すぐにやったほうがいいです。後からやって、うまく動作しなかったときに、どのメソッドが正しく働いていないか、わかりづらくなってしまいますからね。それと、ActiveBasicの場合、途中に制御構文を間違って書いたりすると、コンパイルエラーのメッセージが出たとしても、どこが間違っているのか発見するのが難しくなったりします。さらに、コンパイラのバグで、意味不明なところでエラーが出たりすることもあります。放っておいてコーディングしていて、後からコンパイルすると、とんでもないことになったりするので、定期的にコンパイルにかけることも重要です。

こんな感じで、ライブラリのクラスを作っていきます。みなさんはどのようなやり方をしているんでしょうね?これがいい行程かどうかは、後になってからではないとわかりませんが、このようなことができそうな人は、ぜひライブラリ開発に加わってもらいたいですね。

ということで、今はFileSystemInfoをコーディング中です…。IOのStreamはスレッドが絡んできそうなので後回しにしていますが、DirectoryInfo,Fileクラスとかだけでも、今までよりも数倍は簡単にファイルが扱えそうです。

カラーパネル

OS X標準のカラーパネルは、非常に使い勝手が良くて、かなりいいです。例として、次のようなカラー指定をすることができます。あんまり専門的な知識はないので、適当な説明でやらせていただきます。
ColorPanel1
これは視覚的に選ぶことができますね。色相と明度を組み合わせて選べるようです。適当に色を指定したいとき、よく使います。


colorpanel2.png
このHSB指定は、一番良く使います。色相,彩度,明度で指定するのは、感覚的にとてもやりやすいです。
ちなみに、ここの項目には他にも、グレイスケールという無彩色の明度だけを調節するもの、RGB指定,CMYK指定が用意されています。


colorpanel3.png
これは、あらかじめ用意されている色のセットから選ぶやりかたです。Appleの項目には、基本的な色が指定できるようにされています。他の項目には、デベロッパ,クレヨン,WEBセーフカラーなどがあります。さらに、自分で色のセットを登録できるようです。
よく見ると、検索ボックスがありますね。何に使うんでしょうね。


colorpanel4.png
これはあまり使用したことがありません。どんな風に使えばいいんでしょうね?適当に色を選ぶときにしか使いません。


colorpanel5.png
これは、二つ前に紹介したクレヨンの項目を、より簡単に選べるようにしたものです。適当によい色が拾えるので、結構使っています。さっと選択できて便利です。

他にも全体として、下のところに、選択した色を一時的に置いておくところが用意されていますね。このように、色指定の仕方が充実してて、とてもよいです。

ついでに補助的なツールとして、ユーティリティのところに、DigitalColor Meterというアプリケーションがあります。これは、画面上の色を取得できるツールです。標準で装備されているので、知らなかった人は、Spotlightで検索してみましょう。

というわけで、Vistaにはこういうところの強化もしてほしかったです…

困ったことに…

今日からデスクトップPCのVAIOがなくなってしまいました。理由は、パソコンで勉強するらしいので、他の部屋へ移動するというのです。家族共用PCということで、2月くらいまでは借りるということですが、これでWindowsが自由に使えなくなってしまいました。本当は勉強する時だけ、このiBookを貸しても良かったのですが、残念ながら、その勉強するところのWEBアプリケーションがIE専用で使えず。

そういうわけで、今日リリース版の非公開βを早く試したいのですが、試せません。どうやら、参照型変数というものが実装されたので、どんな物なのか、そして、どういう使い方をすればいいのか、コーディングしながら確かめたかったのですけどね…

しかしながら、Windowsを使う時は、ActiveBasicでコーディングするときくらいです。ライブラリ開発の際、どちらかといえばコーディングよりも、MSDNを眺めている時間のが長い気がするので、それほどコーディングには影響しないと思いますけどね…

可変であるということ

オブジェクトの値が可変というのは、必ずしもいいこととは言えません。なぜかと言えば、複数の場所で参照された時、どちらかで変更できてしまうためです。注意を払っていれば問題ないかもしれませんが、あまりよいことではないように思えます。

例えば、今のStringクラス。当初の仕様では、可変な文字列クラスだったわけですが、関数で参照渡しをしていくうちに、内容が固定されたStringのがいい気がしてきました。

そういうわけで、Insert,Remove,Replaceなどのメソッドは、自身のインスタンスの内容を書き換えるように出来ていますが、こういうメソッドは、関数内で文字列を操作するときに使われるのは、容易に想像できます。例として、PathクラスのGetFileNameとHasExtensionです。
Static Function GetFileName(path As String) As String
path.Remove(0, getLastSeparatorPosision(path) + 1)
Return path
End Function
/*パスからファイル名を取得するメソッドです。最終的に、パスから不要な文字列をRemoveして戻り値を設定しています。*/

Static Function HasExtension(ByRef path As String) As BOOL
If GetExtension(path) <> "" Then
Return _System_TRUE
Else
Return _System_FALSE
End If
End Function
/*拡張子が存在するか判定するメソッドです。拡張子を取得するメソッドの戻り値を使用して、判定しています。*/

GetFileNameの方では、参照渡しをしていません。なぜかと言えば、Removeを使うことでpathの値を変更するためです。一方、HasExtensionの方では、参照渡しをしています。メソッド内でpathの値は変更されることはないので、参照渡しでも問題ないし、そちらのが速いでしょう。

このように、メソッドの中で何をするかによって、参照するかしないかをしていたのですが、これはあまりいい気分がしません。
Static Function GetFileName(ByRef path As String) As String
Return path.Remove(0, getLastSeparatorPosision(path) + 1)
End Function

Static Function HasExtension(ByRef path As String) As BOOL
If GetExtension(path) <> "" Then
Return _System_TRUE
Else
Return _System_FALSE
End If
End Function

こういう風に書けた方がいいですよね。引数もByRefで統一することができます。

そもそも、参照とは何のために使うのか。関数内で引数の値を操作する時でしょうか?それとも、値渡しによるコピー頻度を減らすためでしょうか?両方でしょうか?

どちらにせよ、注意深く引数を見ていないと、Removeで値を変更しても大丈夫か、そういう危険性があります。そういうわけで、よく使うStringとかのインスタンスは、不変のがいいのかなーと、最近よく考えます。変数の命名の規則でも使えばある程度回避できそうですけどね…

さらに、参照型変数の導入という話もあるので、オブジェクトが可変か、不変かということが、より重要になってくるかもしれません。

ちなみに、OS XのCocoaでは、可変なオブジェクトにはクラス名にはmutableが含まれています。NSStringtとNSMutalbeStringみたいな感じです。
.NET Frameworkは、ほとんど不変ですかね?

てきとーなスパゲッティーの作り方

普段料理なんてほとんどしませんが、家に自分しかいない時はします。私はスパゲッティーが好きなので、そういう時はよく自分で作ります。そして、今日もスパゲッティーを作りました。

今日の場合、冷蔵庫の中にブロッコリーくらいしかなく、仕方なくブロッコリーを使ったスパゲッティーを作ろうと思い、ブロッコリーを切っていました。しかし、よく見ると、冷蔵庫の外に、なぜかたくさんトマトがあり、やっぱりスパゲッティーはトマトだなーと思いながら手に取ります。

しかし、ブロッコリーとトマトというのも微妙な組み合わせです。ブロッコリーだけだったら、バターとか入れたりして味をつけようと思いましたが、トマトが入れるなら話は変わります。

先に麺をゆでていたので、その間考えた挙げ句、トマトがあまりにも大量にあったので、使うことにしました。こうして、ブロッコリーとトマトのスパゲッティーを作ることにしました。

特に料理が得意でもないし、料理の本なんて見ないので、いつも半分以上が勘で料理が作ります。

とりあえず、一番最初にやることは水を沸騰させることです。その中に塩を適当に入れて、麺をゆでます。そして、その間に野菜とか、スパゲッティーに入れる物を準備します。
ゆであがったら、フライパンというか、炒めるやつにオリーブオイルを入れて、野菜とかを炒めます。今回はブロッコリーとトマトです。ブロッコリーは固いので、割と細かく切っておくべきです。普通はゆでてから使うのかもしれませんが…
トマトが原型を留めなくなってきたら、いいころです。適当に塩とこしょうを入れて、味をつけ、最後に麺を入れて、混ぜれば完成です。味付けはいつも勘ですが、薄いかなーと思うくらいでも十分だったりします。味付けがなくても、意外とトマトと野菜はおいしいのです。

完成したスパゲッティーは、全体的にトマト色になって、麺の上にブロッコリーが乗ったものです。食べてみると、トマトとブロッコリーが意外に合います。トマトだけの味付けよりも、若干ブロッコリーの甘みがあります。そしてブロッコリーは、あの葉というか、わさわさしている部分にトマトの味が染みていて、なかなかの味になっています。

こういう感じで、適当に合わせて作った料理が、意外においしいということがあるので、料理はなかなか面白いです。だから、チャンスがあるときはなるべく自分で作るようにしています。

スパゲッティーは非常に安価で手に入りますし、バリエーションが豊富なので、てきとーな料理に最適です。

英語読めるといいですね

今日、AppleからADC onlineメンバー(デベロッパー)向けに、昨年に行われたWWDC(Apple Worldwide Developers Conference 2006)の、デベロッパ向けの講演の映像がiTunesで入手可能になりました。

ADCメンバーは、無料登録で、Xcodeをアップデートしたりするのに必要になるので、OS Xで開発をしている人は、ほとんど入ってると思います。

そんなことはいいとして、1時間30分くらいあるので、まだ15分くらいしか見てないのですが、ほとんど英語がわかりません。かなり致命的ですね。所々なんとなく聞き取れるところもありますが、かなーり厳しいです。だいたいの流れと、keynoteを見れるくらいです。なにやら、Xcode3.0とかCore Animationが見れるようなので、早送りしながら見ようと思います。

前々から英語を読めるかどうかでは、PCを使うときに、大きな差があることは知っていましたが、最近OS Xの資料を読むときに、日本語があるほうがめずらしいので、英語ができないことに痛感しています。

そういうわけで、プログラミングは、数学よりは英語のが必要ですね。とりあえず今年こそ、英語をそこそこ読めるようにがんばりましょうかー、どうしましょうか…

WX320K

あまり見かけない型番かと思われますが、今日発表された、Willcomの携帯端末です。私が今持っているのは、WX310Kです。実は、このケータイですが、元旦におそらくソフトウェアの不具合で壊れ、修理するか、新しく機種変更するか迷っているところです。2月になると、保証期間外になってしまうので、そろそろ選択を迫られています。

そして、自分のケータイWX310Kの上位モデル、いわゆる京ぽん3が発表されるのを待っていましたが、今回発表されたWX320Kというのは、WX310Kの上位モデルではなく、WX300Kの上位モデル、つまりWX310Kと同位モデルとなっています。

WX320Kを見てみると、それなりにポイントを押さえた機能を搭載してると言った感じです。Operaブラウザと、JAVAがあるのはいいですね。これで、Operaのレスポンスが速ければ、機種変更してもいいかもです。今のWX310Kは、すごーく遅いんです。

nineも候補にあります。ブラウザはNetFrontで少々残念ですが、そこそこレスポンスがいいらしいので、実機を一度触ってみたいですね。モデム機能がないのは非常に残念ですが、バージョンアップで付くかもしれないらしいです。

nineは、近くの店で異常なまでな安さで売っていたので、機種変更の候補にいれてもいいですが、WX320Kは、おそらくそれほど安価にはならないと思うので、見送ります。しかし、結局今壊れているWX310Kの、Bluetoothでのモデム機能は、すごーく役に立っているので、あまり手放したくありません。

というわけで、WX310Kを修理に出し、京ぽん3でも気長にまってます。

メモとペン

みなさんは家から出るとき、何を携帯するでしょうか?
私は、ケータイ,ハンカチとか,財布,電子辞書あたりでしょうか。しかし最近、もう一つ欲しい物が出てきました。

それは、メモ帳とペンです。外出中いいアイデアが浮かぶことは良くあることです。その時点で重要なアイデアと判断できれば覚えていられるのですが、ちょっとしたことは、忘れてしまいがちです。そこで、ちょっとしたアイデアなども忘れないようにメモを取るようにしたいというわけです。

ケータイは、打つの面倒だし、自由に書くことの出来るメモ帳が一番最適です。近いうちに、何か書くもの、スケージュール管理まで必要な身ではないので、手帳という物が必要という訳ではありませんが、何かそれに準ずる物を携帯したいですね。

ちなみに、デスクトップにはスティッキーズが常在しています。

warm mouse

基本的にこたつスタイルな私は、エアコンという物を使いません。というか、いつもいる部屋にはありません。そういうわけで、パソコンのキーボードやら、マウスを操作しているうちに、手が冷えてきてしまい、手が動きにくいのはいいとして、とにかく寒いのをどうにかしたい気分です。

まあ、指先だけ切ってある手袋とかでもいいかもしれませんが、いつも思うのが、マウスが暖かければいいなーということ。電気屋もわりあい頻繁に行きますので、そういうマウスが売っていないことは知っています。しかし、誰か思いついていてもおかしくないと思い、検索してみました。

結果。あるにはあるけど、見つかったのはひとつくらい。しかも、あまりよくなさそうです。この手の商品がほとんどないことからして、あまり熱効率というか、手が温まらないんでしょうね。

とゆーわけで、今思いつきでUSBキーボード接続し、こたつの中に入れてみました。

やー、暖かいです。これは意外にいけます。昔、ゲームのコントローラーを、こたつの中に入れてゲームやっていた時は問題なかったので、たぶん、キーボードは逝かないと、、、信じてます。

CocoaとCarbon

最近眠くて、一日の最後の方にやっている、ブログを書く時間が取れていなかったりしています。そして、最近Cocoaが板についてきた感じで、なかなか面白くなってきました。

ところで、OS Xのアプリケーション開発には、主に二つの方法があります。ひとつはCocoa。OS Xから搭載された開発環境で、Objective-C言語でプログラミングすることが前提になっています。もうひとつはCarbon。たしか、OS X以前からあるのですが、CocoaとOS X以前の開発環境の差を埋めるために用意された物で、CocoaからCarbon APIを使うこともできます。

Cocoaは、個人的にかなりすばらしいランタイムを提供してくれてると思っていますが、まだ不足がちなところがあります。今後搭載されるのかは知りませんが、Cocoaは自分のアプリケーションから飛び出したようなプログラムを組むことが出来ないのです。つまり、他のアプリケーションを操作したりすることです。例えば、特定のウィンドウを半透明化させたりなどなど..

そして今回、画面に表示されているウィンドウを取得したいと思い、Carbon APIから探していると、GetWindowList()という物が見つかりました。
WindowRef GetWindowList ();
WindowListの、最初のWindowを取得するらしいです。ということは、あれもあるはずと、探してみるとありました。
WindowRef GetNextWindow (
WindowRef window
);

これで、次々とWindowを取得することが出来そうです。

そして、これらで取得したWindowを、Cocoaに持ち込みます。
- (NSWindow *)initWithWindowRef:(void *)windowRef
initWithWindowRef:という大変便利なメソッドが用意されていて、Carbonで使われているWindowRefから、CocoaのNSWindowを作ってくれます。

これで、ようやく他のWindowも操作できると思いきや、そう甘くはありませんでした。どうも、GetNextWindow()で、次のWindowが取得できないのです。

とりあえず、最初のGetWindowList()で、WindowListの最初のWindowは得られてますから、それにSetAlphaValueメッセージを送ってみると、なんと、メニューバーが半透明化したのです。

どうやら、GetWindowList()で取得されたWindowは、メニューバーだったようです。ここでひとつ、OS Xではあらゆる物がWindowとして扱われているらしく、メニューバーのアイコンや、デスクトップのアイコン一つ一つもWindowとして扱われていると、どこかで聞きました。

結局、どうやってWindowを取得するかは、分かりません。しかしながら、次のような文章を見つけました。

http://www.cocoabuilder.com/archive/message/cocoa/2002/5/14/70411

なにやら、GetWindowList(),GetNextWindow()では、現在のアプリケーションのWindowしか取得できない様子。しかし、このあたりに解決方法が載ってそうなので、頑張って探索してみようと思います。

ちなみに、”GetWindowList Carbon”で検索すると失望しますね…