REALbasic 2008 Release 2

REALbasic 2008 Release 2が公開されたので、早速試してみました。

とりあえず、Mac版では、既存のプロジェクトを問題なくオープン＆ビルドできました。 相変わらず日本語化はされていませんが、以前紹介した方法で日本語化できました。 Windows版は、REALbasic 2008 Release 1で英語表記に逆戻りしてしまっていたのが、再び日本語表記になっていました。 ただ、喜びもつかの間、プロジェクトはオープンできるのに、なぜかビルドしたアプリケーションが起動できません。 う〜ん、これは困った！

調べてみると、今回のリリースから、win32のビルド方法が変更になったようです。 これまでは、「My Application.exe」という単一ファイルだけがビルドされ、アプリケーションを起動する度に、各種DLLファイルが裏で展開されていました。 それが、アプリケーションと同一のディレクトリに「My Application Libs」というフォルダが作られ、必要なDLLファイルが、ビルド時にその中に格納されるようになったんです。

この変更自体は、別に悪いことじゃないんですが、問題はビルドしても「My Application Libs」フォルダ内が空っぽなことです。 必要なDLLファイルが見つからないので、アプリケーションを起動しても、ランタイムエラーが続出してしまいます。 REALbasic本体のDLLファイルをコピーしてみても、やっぱり駄目です。 せっかく12ヶ月のライセンスを購入したのに、そりゃあないよ〜。

もしやと思って、ネットワーク上にあるプロジェクトファイルを、ローカルのデスクトップにコピーしてみたんですが、これも駄目。 まさか、ファイルのパスに日本語が含まれてると駄目とかじゃないだろうな、ということでルートディレクトリに移動させてみると、あっさりとビルドできました。 幸い、一度ビルドしてしまえば、日本語を含むパスに移動しても、ちゃんと起動してくれました。

REALbasic 2008 Release 2でビルドしたアプリケーションの動作環境は、Mac OS X 10.2以降（PowerPC, Intel）、Windows 2000以降となります。 Mac OS 9やWindows 98はサポート外となってしまいましたが、まあ仕方ありませんね。 ただ、iKeyboardで重宝してたSpriteSurfaceやNotePlayerなどの機能が、将来のリリースで使えなくなってしまうのは残念です。

拡張された部分も多いので、この機会に、REALbasicの全機能を復習してみるのも良さそうですね。

知識の功罪

iKeyboard 3の開発ですが、いきなり躓いています。

昨年末に学んだオブジェクト指向プログラミングやデザインパターンのおかげで、これまで苦労していた部分が簡潔にできそうな予感はあったんです。 実際、ここはVisitorパターンが使えそうだな、これならStateパターンが良さそうだ、などなど、早速勉強の成果が現れてはいるんですが、そこから先になかなか進まないんですよね。 理屈ではわかっていても、実際にそれを実装する方法がわからずに、手をこまねいてしまっているんですよ。

今は、基本となるキーボード関連のデータ変換部分を実装しようとしているんですが、これがまたややこしいんです。 要素としては、まず各キーに割り当てられたKeyCodeがあり、キー配列上の位置を表すKeyMapがあり、キー位置に対応した指使いのヒントとなるKeyHintがあり、キー配列に対応した文字配列となるKeyScriptがあります。 さらに、KeyMapにはJisとUsの2種類、KeyScriptにはQwertyとDvorakの2種類があり、おまけに直接入力とシフト入力、英字入力とかな入力の違いもあったりして、もう何をどうして良いやらわからなくなってしまいます。

これまでは、IfやSelectによる分岐を使って使い分けてきたわけですが、正しいオブジェクト指向プログラミングでは、クラスによって使い分けるらしいんですね。 とりあえず、それらしいクラスを作ってみたんですが、クラスの数が増えるばっかりで、それをどう扱って良いのかがさっぱりわからないんですよ。 どうやら、私の頭は非オブジェクト指向になっているようです。 でも、ちょっと待てよ。 今の自分は、オブジェクト指向やデザインパターンに振り回されてないか？

効率化を図るのが目的のはずなのに、効率化のために効率が落ちていたんじゃ話になりません。 確かに、オブジェクト指向プログラミングは非常に強力な手法ではありますが、何が何でもオブジェクト指向にしなければならないわけではありません。 XPプログラミングでも、まずは最短の解決策を見つけて、最適化は後からリファクタリングすることになってるじゃありませんか。 どうやら、気負い過ぎて頭が固くなっていたようです。

人の意見に耳を傾けるのは大切なことですが、人の意見を鵜呑みにして自分を犠牲にしてしまっては意味がありません。 まずは、自分にとっての理想をイメージした上で、それを現実にするための努力をするべきです。 人の意見というのは、その段階になって初めて役に立つんですよね。 イメージを膨らませるには、自分のやり方を貫くのが一番です。 そう思うと、肩の荷が下りて、ずいぶん気が楽になりました。

とにかく、手探りでもいいから前に進まないと。

Javaのソースはどんな味？

Javaには、無償の総合開発環境があるらしい。

というわけで調べてみると、NetBeansというのが見つかりました。 Javaのお膝元であるSunがオープンソースで開発しているので、安心して使えそうです。 最初から日本語に対応しているのも嬉しいですね。 というわけで、早速ダウンロードしてインストール。 WindowsでもMac OS Xでも同様に使えてしまうのは、Javaの面目躍如といった感じです。 画面表示も綺麗で、動作もキビキビとしています。

他にもないかと探してみると、IBMが開発したEclipseや、ORACLEが元々商用として開発したJDeveloperがありました。 中でも、Eclipseは最も歴史が古く、Java以外の言語にも対応していて、一番人気が高いようです。 JDeveloperも、商用だっただけあって完成度が高く、他のORACLE製品との連携も高いんだとか。 とりあえず、一通りダウンロードしてインストールしてみましたが、どうやら入門用にはNetBeansが良さそうです。

まだ右も左もわからない状態なので、とりあえずNetBeansのソースを開いてみます。 オープンソースのソフトは使ったことがありますが、オープンソースのソースを見るのは初めてです。 いきなりずらりと並ぶプロジェクトに、ぎっしりと詰め込まれたクラスの数々。 プロジェクト全体だと、果たしてクラスは何個になるんだろう？ これはJavaだから？それともNetBeansが巨大なアプリケーションだから？

クラスの数はとりあえずおいといて、今一番興味があるのは、ひとつひとつのクラスの規模です。 メンバ変数の数は？メソッドの数は？getter/setterメソッドの占める割合は？ どうやら、ほとんどのクラスは、メンバ変数、メソッド共に10個以内に収まっているようです。 ただ、一部のクラスは非常に規模が大きくなっていて、50近くのメンバ変数やメソッドがあるものもありました。

サンプルじゃない本物のJavaのコードを見るのは初めてだったんですが、これはとても勉強になりそうです。 最近つくづく思うのは、多くのソースコードに触れる機会があれば、もっと上達が早かっただろうな、ということです。 REALbasicでは、付属のサンプルコード以外にソースを見ることはほとんどなかったので、成長する機会がずいぶん失われていたように思います。 その点、Javaはオープンソースが盛んなので、とても助かります。

文章も、定型的な例文をいくら覚えたところで、生きた文章を書くことはできません。 まず最初に伝えたいことがあって、それが自然と言葉を選んでいって、文章になっていきます。 最終的にできあがった文章だけを見ていては、決して良い文章は書けません。 プログラムも、説明のためのサンプルコードばかり見ていても、いざという時にはあまり役に立ちません。 生きたコードに直接触れて、初めてそのコードを活かせるんでしょうね。

これからは、Javaの香りも味わっていきたいと思います。

消化不良と一人旅

どうやら、一度に多くのことを学び過ぎたようです。

リファクタリングやデザインパターンについて一通り学び終えて、オブジェクト指向プログラミングの理解もずいぶん深まりました。 よし、これでプログラミングの技術力も上がったはずだ。 わくわくしながら、久々にHomeRecipeのプロジェクトファイルを開いてみると、そのコードの汚さに驚いてしまいました。 一年半前のiKeyboardならまだしも、ついこの間書いたばかりのHomeRecipeのコードまでもが、不吉なコードの臭いで充満していたのです。

ほとんど独学とはいえ、それなりに技術の蓄積もあったし、自分なりに満足していたつもりでした。 特にHomeRecipeは、紆余曲折はあったものの、これまでの集大成として自信を持っていただけに、かなりショックが大きかったです。 これまでずっと頼りにしてきたREALbasicも、Javaの言語仕様を知ることで、だんだん貧弱で頼りないものに思えてきました。 今までの自分は井の中の蛙で、ずっと無駄な努力をし続けてきただけなのか？

というわけで、すっかり自信をなくしてしまいました。 とりあえず、HomeRecipeの簡単なリファクタリングをしているところなんですが、新しくコードを書くのが怖いんですよ。 何かコードが思いついたとしても、もっと良いコードがあるんじゃないかと不安になって、先に進めないんです。 これまで学んできた「あれをするな」「こうすべきだ」「こうしなければならない」といった言葉が頭の中で渦巻いて、どんどん混乱していきます。

でも、これまでだって、曲がりなりにもソフト作りはできたわけだし、気に入ってシェアウェア登録してくれた人だってたくさんいます。 上を見たり人と比べるのも良い刺激にはなりますが、あまり気にし過ぎると、自分がどんどん駄目になってしまいます。 そう、遠くの景色を眺めたり、出会った人達との会話を楽しみながら、自分のペースで旅をしたほうがずっといい。 写真だって、自分の気に入ったものを撮るのが一番ですからね。

というわけで、マイペースで頑張ります！

下駄と雪駄の履き心地

オブジェクト指向には、getter/setterメソッドというのがあります。

クラス内のメンバ変数は全てPrivateにしておいて、外部からはgetter/setterメソッドを使ってアクセスしましょう。 ということなんですが、それには10の理由があるんだとか。 読んでみると、なるほどなぁと納得半分、何だかこじつけっぽいなぁと疑問半分といった感じです。 私も、最初はメンバ変数を全てpublicにしていたんですが、Nilチェックが面倒臭いという理由で、インスタンス変数の場合はいつの間にかgetter/setterメソッドを使うようになっていました。

せっかくオブジェクト指向の理解が深まったわけだし、試しにgetter/setterメソッドを徹底してみるか。 というわけで、早速HomeRecipeのRecipeClassを修正することにしました。 でも、RecipeClassには、メンバ変数が11個あるので、getter/setterメソッドの数は倍の22個になってしまいます。 これだけ数が多いと、それ以外のメソッドが埋もれてしまって、とてもわかりにくくなってしまいます。

そこで、メンバ変数とgetter/setterメソッドだけのクラスを作り、それ以外のメソッドは、そのサブクラスに実装することにしました。 これで、リストはずいぶんすっきりしましたが、サブクラスからはどんなメンバ変数があったのかが見えなくなってしまったので、いちいちスーパークラスを確認しなければならなくなってしまいました。 ひとつのクラスにするとメソッドが増え過ぎるし、クラスを分割してしまうと見通しが悪くなってしまうし、どうも中途半端なんですよね。

まあ、元々同じクラスだと思うからいけないのであって、最初から別のクラスなんだと思えば、すぐに慣れるのかもしれません。 getter/setterメソッドがずらりと並んでいても、すぐに気にならなくなるのかもしれません。 初めてのものを導入する時には、不安や抵抗はつきものですからね。 何といっても、今の私は、オブジェクト指向に関してはまだまだ素人ですから、ここは心を落ち着けて、謙虚に受け入れなければなりません。

新しい靴も、履き慣れるまでには時間がかかりますからね。

様々な臭い

リファクタリングの本には、大抵「コードの臭い」について書かれています。

コードの臭いとは、読みづらい、わかりにくいプログラムコードの気配のことです。 理屈じゃなくて、見ただけで感じることのできる、感覚的なものです。 そういう臭いを感じたら、早めにリファクタリングして、臭いの元になるコードを捨てて、清潔で読みやすいコードに取り替えましょう、というわけですね。 確かに、リファクタリングされたコードは読みやすく、気品のある香りすら漂ってきます。

でも、リファクタリングの本には、啓蒙書にありがちな「文章の臭い」のあるものが多いようです。 それは、自分達の主張だけが絶対唯一の答であり、これを信じている限りあなたは救われるだろう、という、自信過剰で妄信的な態度のことです。 これは、リファクタリングだけでなく、XPやオープンソースでも感じられる臭いです。 そして、これは新興宗教やカルト団体、スピリチュアルなどにも共通する臭いでもあります。

自分の信念を広めようとすること自体は、別に悪いことではありません。 しかし、どんなに素晴らしいと思えることも、時とともに変化していくものです。 その発案者やそれに近い人達は、そのことを十分に承知していて、その著書の中でも、それらが発展途上であることを警告しています。 ところが、それが広まれば広まるほど、内容は形式的になり、それを妄信する人達が出てきます。

もちろん、バランスが大事だとか、新しい可能性についても触れてはいるものの、その警告すらも形式的になってしまっていて、もはや警告としての機能を失っていたりします。 掲載されているサンプルコードも、確かに読みやすくなっているものの、ずいぶん回りくどいことをしているように思えて、全然魅力が感じられないんですよね。 何だか、リファクタリングのためのリファクタリングをしているようで、まるでナルシストのポエムを読まされているかのようです。

私の場合、悪臭を放つ過去のコードに辟易していたので、リファクタリングに興味を持ち、大きな期待もしました。 でも、実際にリファクタリングを学んでみると、実はオブジェクト指向言語の基本的な事柄を知らなかっただけで、その基本さえしっかり押さえていれば、あまりこだわるほどのものではないことがわかってきました。 大切なことではあるけれど、こだわり過ぎてもいけない、料理の塩加減みたいなものですね。

そう、結局のところ、プログラミングは料理みたいなものなんですよね。 料理では、なるべく新鮮な素材を使って、それぞれの素材を活かしながら、いろんな味付けをして、美味しい料理を作り上げます。 プログラミングも、なるべく新しい技術を使って、それらの特性を良く理解しながら、蓄積された経験と合わせて、扱いやすいソフトを作り上げていきます。 ただ、あまり料理の味だけにこだわり過ぎてしまうと、そういう態度は鼻につくので、注意した方が良さそうです。

理論ばかりじゃなくて、そういう感覚も大切にしたいですね。

クラスと抽象クラスとクラスインターフェイス

オブジェクト指向は、オブジェクト単位で世界を構築していきます。

オブジェクトは、クラスによって定義され、その定義を元に作られた実体がインスタンスです。 あるクラスを元に、さらに別の定義を追加したクラスを作ることもできます。 親のクラスがスーパークラス、子のクラスがサブクラスです。 サブクラスでは、スーパークラスで定義したことを再定義することができ、これをオーバーライドといいます。 また、同じクラス内でパラメータの異なる同じ名前のメソッドを追加することができ、これをオーバーロードといいます。

というのが、今まで私の理解していたオブジェクト指向です。 間違っていたわけではありませんが、十分というわけでもありません。 最近の勉強で、どうやら抽象クラスとクラスインターフェイスというのがあるらしい、ということがわかりました。 でも、これって何なんだろう？ 普通のクラスとはどう違うの？ 働きが似てるようだけど、違いは何なの？ というわけで、このところずっと悩んでいたんですよ。

で、あちこち調べているうちに、だんだんわかってきました。 どうやら、抽象クラスはサブクラスに継承することに特化したクラスで、抽象クラスのインスタンスを作れないように制限しているだけで、それ以外は普通のクラスと同じもののようです。 つまり、普通のクラスを抽象クラスのように使うことはできても、抽象クラスを普通のクラスのようには使えない、というわけです。 要するに、インスタンス化されると困る時には、抽象クラスにしておきましょう、ということですね。

抽象クラスは、そのサブクラスを作り、定義された内容を継承させることによって実装していきます。 つまり、その子孫しか継承できない、門外不出のクラス定義なわけです。 でも、門外漢のライバルクラスでも、似たような作業をしていることもあるわけで、あまり独自技術にこだわり過ぎてしまうと、業界全体の発展が遅れてしまう恐れがあります。 そこで、異なるクラスの間でも、同じ作業を同等に扱えるようにした業界標準、それがクラスインターフェイスなわけです。

具体的には、抽象クラスのうち、定数と抽象メソッドに特化したものが、クラスインターフェイスとなります。 そして、サブクラスへと継承する代わりに、任意のクラスに実装していきます。 抽象クラスは、ひとつの抽象クラスしか継承できませんが、クラスインターフェイスでは、複数のクラスインターフェイスを組み合わせて、ひとつのクラスに実装させることができます。 おかげで、異業種交流が活発に行えるというわけですね。

抽象クラスやクラスインターフェイスについて調べている時に、これまでオーバーライドについて誤解していることに気づきました。 スーパークラスと同じ名前の要素をサブクラスにも用意することで、親クラスとは異なる動作をさせることができる、というのがオーバーライドの利点です。 でも、サブクラス型の変数をスーパークラス型の変数に代入してオーバーライドされたメソッドを呼び出した時には、スーパークラスの方のメソッドが呼び出されると思っていたんですよ。

実際には、スーパークラス型の変数であっても、サブクラスのメソッドが呼び出されます。 これを仮想メソッドといい、REALbasicのマニュアルにも書いてあるんですが、そこまで詳しく解説されていなかったので、ずっとこのことに気づかないでいたんですよ。 もし、仮想メソッドや仮想クラス、クラスインターフェイスをちゃんと理解していたら、iKeyboardやPhotoMasterの開発に、あそこまで頭を悩ますことはなかったのになぁ。ああ悔しい。

また、いつの間にかREALbasicに備わっていた機能もたくさんあります。 共有プロパティや共有メソッドがサポートされ、計算型プロパティというgetter/setterメソッドを自動化する機能も加わりました。 また、名前空間もサポートされて、ますますオブジェクト指向言語らしくなってきています。 デザインパターンを学んだことで、初めてオブジェクト指向の全貌を知ることができたように思います。

というわけで、これからのソフト作りがとっても楽しみです。

XPのまとめ

XPエクストリーム・プログラミングについて学んだことを挙げてみます。

• ユーザーがストーリーを作る。
• 各ストーリーに必要なタスクを挙げる。
• プログラマーがタスクごとに作業見積もりをする。
• 必要に応じて、ストーリーを分割または延期する。
• ストーリーに沿ったスパイク（試作品）を作る。
• スパイクのコードは使い捨てにする。
• タスクに必要なクラスを全て定義する。
• コードの実装を始める前に、テスト用のコードを書く。
• テストを通るようにクラスにコードを実装する。
• その時点で最も最適化されるようにリファクタリングする。
• 再びテストを行って、正しく機能することを確認する。
• タスクの実装が終わるごとに、結合テストを行う。
• 1〜3週間のイテレーションごとにリリースを行う。
• 次のイテレーションに向けて、ストーリーを強化する。
• 週40時間労働

私は個人でソフトを作っているので、ペア・プログラミングによるコードの共有や学習といったことは抜かしてあります。 XPでは、何よりもスピードと効率を重視しています。 それまで、大きな荷物をひとつずつ背負って運んでいたのを、小さな手荷物に分けて、バケツリレーで運んでいくような感じでしょうか。 それも、長いひとつの列を作るんじゃなくて、小さな円形の列を作って、バケツを同じ方向に回していくわけです。

せっかくバケツを回しても、中に水が入っていなければ意味がありません。 XPでは、必ずふた付きのバケツを使うようにして、途中で水がこぼれないようにしています。 また、バケツを渡した後でも、途中で手間取ってしまった場合には、何度か練習を繰り返して、効率良くバケツを渡せるようにトレーニングします。 そして、必要なだけの水を運べたかどうか、定期的に確認します。

ユーザーは、一度に大量の水が必要になるわけではないので、必要なだけの分量が集まったら、その時点で水を使ってしまいます。 そして、残りの必要量を計算してから、バケツリレーを再開します。 バケツリレーは重労働なので、あまり欲張って一度にたくさん作業してしまうと、筋肉痛になったり疲労がたまったりして、途中でバケツをひっくり返してしまうかもしれません。 無理せず体を休めることも必要です。

というわけで、なかなか魅力的なXPですが、その名の通り、プログラミングの方法論でしかないんですよね。 何を運ぶのか、運んだものを何に使うのかは、完全にユーザー任せになっています。 XPでは、ユーザーをフルタイムでチームに取り入れることで、ユーザーの希望通りのものが作れるように工夫していますが、それもユーザーのストーリー作成能力にかかっています。 ストーリーの作成方法については、別の方法論で学んでいく必要があります。

とはいえ、プログラミングの効率アップが図れるというのは、とても魅力的です。 早くXPの方法論に慣れるように、頑張りますね。

代弁者としての存在

ソフトを作る上で、ずっと気をつけていることがあります。

それは、「自分は代弁者だ」ということです。 ただ自分の欲しいものを作るだけじゃくて、ただ言われた通りのものを作るだけじゃなくて、声なき声に耳を傾けて、その声に忠実でありたいと思っています。 これは、最初にiKeyboardを作り始めた時から、現在のHomeRecipeに至るまで、ずっと変わることはありませんでしたし、これからも変わることはないでしょう。 そして、それこそが「ソフトウェア作家」としての使命だと考えています。

個人が公開しているフリーウェアには、とりあえず自分の欲しいものを作ってみて、せっかくだから皆にも使ってもらおうと公開しているものが多いです。 そのため、便利な機能を提供してくれたとしても、単機能しかなかったり、必要以上に複雑で難解だったりします。 シェアウェアになると、利用者のことを意識したものが増えてきますが、「自分の欲しいものを作る」という姿勢に変わりはありません。

一方、市販のソフトは、綿密な調査を行った上で、多機能・高機能を売りにしてソフトを作ります。 商売として成り立つためには、より多くの人に買ってもらわなければならないので、できるだけ多くの声を反映させなければなりません。 また、競合製品との差別化のために、他にはない独自の機能も必要になりますが、すぐに他社にコピーされてしまいます。 その結果、一人の客には不必要な機能がぎゅうぎゅうに詰め込まれた、メタボリックなソフトになりがちです。

パソコン教室や数々のパソコン関連書籍では、これでもかと言わんばかりに、機能の説明が繰り広げられます。 機能を知ってしまうと使ってみたくなりますが、元々欲しい機能というわけではないので、何回か試せばすぐに飽きてしまいます。 仮にその機能に満足したとしても、それは機能を使えたことの満足であって、その結果はあまりパッとしないことが多いのが現実です。

結局は、誰かの大きな声に惑わされているだけで、自分の本当の声を見失ってしまっているんですよね。 言われたからやってみたけど、本当はわざわざこんなことなんてしたくなかったのに。 私はただ、これをこうしたかっただけなのに。 あれをああしてくれさえすれば満足なのに、何でそれだけのことができないの。 本当は声に出して言いたいけど、頑張って声に出してみても、周りの大きな声に掻き消されてしまいます。

本気でタイピングを習得したい。 写真の撮影技術を上達させたい。 過去の自分をじっくり振り返りたい。 毎日の食卓を楽しいものにしたい。 誰もが望んでいる、ありふれた願い。 それでいて、なかなか満たされることのない願い。 でも、その声はあまりに小さく、なかなか伝わりません。 たとえ伝わったとしても、その声に応えるためには、地道な努力が必要となるので、どうしても敬遠されがちです。

まだまだ未熟なところも多いですが、そういう声に応えられるようになりたいです。

クラスインターフェイスを使ってみた

恥ずかしながら、生まれて初めて、クラスインターフェイスを使いました。

表計算で作った表を、タブと改行で区切った定数として登録しておき、それを起動時に変数に格納したかったんです。 表によって、列数と行数は違ってきますし、変数の型も変わってきます。 変数に代入した後は、それをいろんな場所で使用します。 さて、これをどうやって実装すれば良いでしょうか？ iKeyboardで、キーボード関連の情報を初期化するための処理なんですが、たくさんの表があるので、なるべく効率良く処理したいと思います。

真っ先に思いついたのは、グローバルなモジュールの中に、表を定義した定数と、表を格納する変数、そして変数を初期化するためのメソッドを用意する方法です。 初期化用のメソッドは、どれも同じループ構造で、変数を格納する部分だけが異なっています。 コード自体は10行以内に収まる程度なので、さほど気にする必要はないのかもしれません。 でも、この方法だと、表が増えるにつれて、モジュールの変数と初期化メソッドが増えていってしまいます。

そこで、表ごとに、専用のクラスを用意することにしました。 コンストラクタで表の初期化ができるので、モジュールが膨れ上がる心配はなくなりましたが、初期化メソッドのコードの重複が、どうも気になります。 そこで、表を定義した文字列を要素ごとに分解して、それを配列で返すクラスを新たに作りました。 次に、その配列を受け取るためのメソッドを定義したインターフェイスを作って、各表のクラスに割り当てます。

後は、表クラスのコンストラクタで、表の初期化クラスのインスタンスを作り、表を定義した文字列を渡してから、配列を受け取るメソッドで文字列を変換して、変数に格納していくだけです。 実は今まで、インターフェイスの意味が良くわかってなかったり、インターフェイスの継承を利用する場面が思い浮かばなかったりしてたんですが、初めてその威力を実感しました。 なんだ、こういうことだったのか！これは超便利じゃないか！

実は、iKeyboard 1では、グローバルモジュールを使いまくっていたんですよ。 iKeyboard 2では、グローバルにする必要がないことに気づいて、キー表示用のクラスに処理を移したんですが、今度はこのクラスが肥大化して、ややこしいことになっていました。 当時は、クラスは変数やメソッドを格納するための入れ物という感覚でしかなかったんですよね。 今になって、クラスはひとつの機能を実現するための単位だということに、ようやく気づいたわけです。

我ながら恥ずかしい話ですが、大昔のBASICのような手続き型言語に慣れ親しんできた人にとっては、オブジェクト指向ってなかなか受け入れられないものなんですよね。 頭では理解できても、体が覚えられないんですよ。 実は、さっきまで抽象クラスとインターフェイスを混同していて、書きながらやっと違いが理解できたくらいです。 REALbasicでは、抽象クラスはサポートされていないようですが。 とにかく、もっと勉強しないといけませんね。

とりあえず、クラスインターフェイスの使い方を、体に覚え込ませていきますね。

REALbasic 2007r5の日本語化

先日、REALbasic 2007 Release 5が公開されました。

早速ダウンロードして、まずはWindowsにインストール。 起動すると、日本語表示になっていてびっくり。 アスキーソリューションズが日本代理店だった頃は、なかなか日本語版が公開されずにイライラしたものでしたが、本家が直接日本語版を扱うようになったおかげで、新バージョンの公開と同時に、日本語表示で快適にREALbasicを扱えるようになりました。 中身は同じとはいえ、やっぱり母国語というのは嬉しいものです。

ところが、Mac OS X版をインストールしてみると、何と英語表示のままです。 Macで生まれ育った開発環境だというのに、今ではすっかりWindowsが主役になっているようです。 でもご安心を。Mac OS X版は、簡単に日本語表示させることができるんですよ。 私は、これまでのバージョンでも、同じ方法で日本語表示にしていたんですが、せっかくなので、これを機会に日本語化の方法を公開することにします。

1. REALbasic 2007 Release5と、REALbasic 2006 Release3をダウンロードする。
2. REALbasic 2006 Release3を右クリックして、パッケージの中身を表示する。
3. 「Contents」→「Resources」→「ja.lproj」と、順にフォルダを開いていく。
4. 「ja.lproj」フォルダを、REALbasic 2007 Release5の同じ場所にコピーする。

これで、日本語表示でREALbasicを使うことができます。 一部、英語表記のままの部分がありますが、「ja.lproj」フォルダ内の「Localizable.strings」ファイルを書き換えることで対応できます。 なお、このファイルのエンコーディングはUTF-16になってるので注意してください。 ちなみに、「"Strings.kProjectTemplatesFolder" = "プロジェクトテンプレート";」を「"Strings.kProjectTemplatesFolder" = "Project Templates";」に書き換えると、テンプレートが正しく表示されない問題を解決することができます。

元になる変数名を知るには、REALbasic 2007 Release 5 for Linuxをダウンロードして解凍した後、「Resources」→「ja-UTF-8」→「LC_MESSAGES」→「localizable.mo」ファイルをテキストエディタで開きます。 最初は文字化けが続きますが、真ん中に変数名の一覧、最後に日本語訳が格納されています。 まあ、そこまでしなくても十分に快適に使えますが、気になる部分があれば修正してみてください。

また、日本語化と同様の手順で、「Language Reference」フォルダを入れ換えてやれば、言語リファレンスも日本語化されます。 もちろん、内容はREALbasic 2006 Release3のものなので、それ以降に変更・追加された部分は反映されませんが、わからない部分を日本語で理解できるというのは、とても便利ですよ。 フォルダの中身は普通のHTMLなので、ブラウザにブックマークしておくのも良いでしょう。

いまいち利用者が少なく、評判も良くないREALbasicですが、オブジェクト指向の総合開発環境で、手軽に扱えて、しかもネイティブにマルチプラットフォーム対応しているいうのは、とても魅力的です。 他にも魅力的な開発環境はたくさんあるわけですが、私のように個人で家庭向けの小中規模のアプリケーション開発をするような場合には、とてもバランスの良い開発環境だと思います。

というわけで、興味を持たれた方は、ぜひ試してみてくださいね。

リファクタリングの人生さ

今、一番興味のあるのが、リファクタリングです。

XP エクストリーム・プログラミングを通して知ったわけですが、これぞ私が望んでいたものだったんですよ。 これまで、「後から修正するよりも、一から作り直した方が早い」という言葉を信じて、iKeyboardからiKeyboard 2、PhotoMasterからPhotoMaster 2を、一から作り直してきました。 確かに、新しい枠組みを作り直す作業は新鮮味があって楽しいんですが、その枠の中を埋めていく作業になると、途端に面倒になってくるんですよ。

メジャーバージョンアップとはいえ、基本的には同じソフトなので、当然ながら重複する機能も多いわけです。 全体の構造を見直すためだけに、あるいは、新しいわずかな機能を追加するために、その重複する部分まで書き直さなければならないというのは、ちょっと無駄が多過ぎます。 家を引っ越す度に、家財道具を全部入れ替えなければならないとしたら、やってられませんよね。 やっぱり、今ある資源は有効に使わないと。

リファクタリングというのは、既存のコードを元に、より最適な構造に再設計していくものです。 つまり、資源のリサイクル、有効利用ができるわけですね。 ぐちゃぐちゃに絡み合ったスパゲティコードを解きほぐしていくのは大変な作業ですが、今ではオブジェクト指向という強い味方がいます。 そして、オブジェクト指向の頼りになる相棒であるUMLやデザインパターンもいるので、以前よりもずっとリファクタリングがしやすくなっています。

今、iKeyboard 2の成績表示を強化しようとしているところなんですが、あまりの複雑さに我ながら驚いてしまいました。 当時は、REALbasicのマニュアルと自分の経験だけを頼りに作っていたので、あまりオブジェクト指向のパワーを活かせていなかったんですね。 それでも、iKeyboard 1の頃と比べると、何とかシンプルな構造にしようという苦労の後があちこちに見られました。 そういえば、あの時は頭がパンク寸前で、本当に苦しかったなぁ。

おかげで、iKeyboard 2が転機となって、より負担の少ない設計を意識するようになりました。 オブジェクト指向に慣れてきたこともあって、思いついたまま実装するんじゃなくて、その前にひと工夫する余裕が出てきました。 頓挫していたPhotoMaster 2が動き出したのも、こうした意識改革のおかげです。 MT Log Readerの開発が猛烈な勢いで進んだのも、HomeRecipeが度重なる仕様変更に耐えてこれたのも、こうした苦労があったからです。

資格試験をきっかけにして、これまで自分の知らなかった、より便利な技術がたくさんあることを知りました。 私が最初にプログラムと出会った1980年代からは、ソフトウェア工学もずいぶん進歩したようです。 こうしたことをもっと早くに勉強しておけば良かったな、と思う反面、それらの有り難みがわかるまで、苦労と経験を重ねてこれたことを嬉しくも思います。 いくら知識が豊富にあっても、それを駆使できるのは経験だけですからね。

自分の人生は一度きり。生まれ変わってやり直すよりも、リファクタリングした方がずっといい！