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メソッドがずらりと並んでいても、すぐに気にならなくなるのかもしれません。 初めてのものを導入する時には、不安や抵抗はつきものですからね。 何といっても、今の私は、オブジェクト指向に関してはまだまだ素人ですから、ここは心を落ち着けて、謙虚に受け入れなければなりません。

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

温かな満足

鹿児島中央駅に、夜行列車の指定席を買いに行ってきました。

実は、今回の帰省の旅は、盛りだくさんの内容なんですよ。 親戚や甥っ子、学生時代の友人やブログで知り合った人達など、いつになく人に会う予定がぎっしり詰まってます。 こうした旅ができるのも、青春１８きっぷのおかげですね。 行きの宿は確保したし、帰りは夜行列車でさっと帰ろうかな。 指定席の販売は一ヶ月前からということなので、予約開始の日に買っとけば安心できるというものです。

遅い昼ご飯の鳥はむカレーを食べてから、自転車で鹿児島中央駅に向かいます。 そうだ、今日はこの間見つけた駐輪場を使ってみよう。 2時間は無料だから、切符を買うぐらいなら余裕だもんね。 駐輪場で、空いている場所を探します。お、あったあった。 自転車の車輪を押し込むと、ガチリとロックがかかりました。 よし、これで安心。 ちゃんと駐輪場を利用するのって、気持ちがいいなぁ。

足取り軽く、颯爽と駅へと向かおうとしたら、ちょうど向かいに自転車を停めていたおばちゃんに声をかけられました。 「あの、鍵かけなくてもいいんですか？」「へ、ちゃんとロックされたから大丈夫かなと思ったんですけど…」「あそこの精算機で番号押したら簡単に持ち出せますよね」「あ、そうか！どうもありがとうございます！」 慌てて自転車に鍵をすると、そのおばちゃんはなぜか何度も頭を下げながら、地下通路を下りて行きました。

よく見ると、入口には「鍵を忘れずに！」という看板もあります。 いやいや、機械が自動的にロックしてくれたので、すっかり油断してしまいました。 それにしても、さっきのおばちゃん、わざわざ教えてくれるなんて、いい人だなぁ。 銀行などで置き忘れしそうになった人に声をかけることは良くありますが、こういう教えなくても何とかなりそうなことでも声をかけられるって、そうできることじゃありません。

残念ながら夜行列車は満席でしたが、とても心の満たされる出来事でした。

わくわく、どきどき

ねえねえ、あの向こうには何があるの？

様々な臭い

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

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

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

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

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

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

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

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

ピザでお祝い

ドラゴン改めNORIさん、新パソ購入おめでとう！
そして、ごちそうさま！

久々に鳥はむ

鶏の胸肉が安かったので作ってみました。やっぱりうまい！

キーボード随想

キーボードには、並々ならぬ思い入れがあります。

小学生の頃、ベーマガに載っているゲームを遊ぶために、暗号のようなプログラムリストを、一本指打法で入力していたあの日々。 10行刻みで1000行前後のプログラムを入力するのに、何時間もかかっていました。 定規をあてながら、1行ずつ、黙々と入力していました。 やっと最後まで入力し終わって、ドキドキしながらF5を押すと、今度はシンタックスエラーとの戦いです。 一体どの文字を間違えたのか、じりじりとした焦りと苛立ちが全身を駆け巡ります。

早くゲームで遊びたいけど、なかなか速く正確に入力できない。 そこで、自分でキーボード練習ソフトを作ってタイピングをマスターしたのが中学生の頃です。 当時使っていたPC-6001のキーボードは、ぺこんぺこんの酷いキータッチでしたが、そんなことは全く気になりませんでした。 でも、最新パソコンの、キーのぎっしり詰まった薄型キーボードは、とても格好良くて、ずっと憧れていました。

なので、高校進学記念にX1turboZを手に入れた時は、本当に嬉しかったですね。 憧れのキーボードがついに自分のものになったんだ！ もう、ただそれだけで大満足でした。 そのせいか、私のキータッチの好みというのは、このX1turboZのキータッチそのものなんですよね。 メカニカルスイッチで、クリック感はなく、すっと押し下げる感じ。 そして、キーが底を打つ度に、固い感触と共にカタカタという音がするんです。

で、この固い感触と音が、たまらなく心地良いんですよ。 アスファルトの上を革靴で歩くような、ちょっと美味しそうな感じ。 大学生の頃に買ったX68000 PROのキーボードは、キータッチが若干ソフトになっていましたが、大型のパームレストがついていたので、とても快適に入力することができました。 X1turboZのキータッチとX68000 PROのパームレストがあれば、最高のキーボードになるのになぁ。

そうして出会ったのが、これまで愛用していたFILCOのアルミキーボードです。 冬は冷たいのが難点ですが、キータッチはX1turboZに近く、X68000PROのような広いパームレストもついています。 実は、かつてApple Adjustable Keyboardという高価なキーボードを使っていたこともあったんですが、キータッチはあまり好きになれなかったんですよね。 やっぱり、X1turboZのキータッチが忘れられない！

もしかしたら、キータッチの好みって、物理的な特性よりも、心理的な影響の方が大きいのかもしれません。 メカニカルスイッチのキーボードから入った人は、メンブレンスイッチのキーボードを敬遠することが多いようです。 逆に、最初に買ったパソコンがノート型だった人は、ゴツゴツしたメカニカルスイッチのキーボードよりも、ノートパソコンのようなメンブレンスイッチのキーボードの方を好むようです。

私も、デスクトップパソコンのおまけキーボードのようなフニャフニャのキータッチは苦手なんですが、ノートパソコンのコリコリとしたキータッチは結構好きだったりします。 こちらも、豚の軟骨煮込みのような感じで、なんとなく美味しそうな感触なんですよね。 もしかしたら、キータッチの味わいというのは、料理の味と何か関係があるのかもしれません。 そのうち、メロン味のキーボードとか出てきたりするのかな？

なんてことを、X1turboZIIのキーボードを引っ張り出しながら、ぼんやりと考えたのでした。

ニュータイプのキーボード

新しいキーボードを買っちゃいました。

macallyのiceKEYという超薄型のキーボードです。 これまでのキーボードはとっても気に入っていたわけですが、先日、留守中にミーちゃんがキーボードの上にゲロを吐いて、使用不能になってしまったんですよ。 分解・清掃することで何とか使えるようになりましたが、こうした不慮の事態に備えて、予備のキーボードが欲しくなったんです。一応、iMac標準のJISキーボードもあるんですが、私はDvorak配列を愛用しているので、USキーボードじゃないと都合が悪いんですよね。

そうして、Yahoo!オークションで見つけたのが、このキーボードです。 メカニカルスイッチ大好きの私ですが、最近はノートパソコンのコリコリした感触も好きになっていたので、場所も取らないしちょうどいいなと思ったわけです。 ところが、このキーボード、突然キーがダブって入力されるようになったということで、ジャンク扱いになっていました。 現在価格は500円。これなら直せなくても諦めがつくかな。 というわけで、入札。そのまま落札となりました。

で、そのキーボードが今日届いたわけなんですが、早速使ってみると、tabキーのある行のキーを打つと、隣のキーまで同時に入力されてしまいました。 とりあえず、分解して中身を調べます。 配線と接点の印刷されたフィルムを取り出して、直接接点を通電させてみても、キーはダブって入力されました。 基盤に半田が浮いている部分がないか、コンデンサが液漏れしていないかもチェックしてみましたが、どこも異常はなさそうです。

もしかしたら、フィルムが劣化してどこか断線してるのかも。これはもう、手に負えんな。 がっかりしながら組み立て直して、念のためにもう一度繋いで入力してみると、やっぱりダブって入力されます。 あれ、でも何か様子が変だぞ。 さっきはちゃんと入力できてたキーまでおかしくなってる？ ということは、これはまだ直る可能性があるってことだ！ というわけで、再びキーボードを分解していきます。

例のフィルムは三層構造になっていて、外側の二層に接点と配線が印刷されていて、真ん中の層が接点の間に隙間を作る役割をしています。 キーが押し込まれると、この隙間が押しつぶされて、スイッチが入るというわけですね。 もしかしたら、このフィルムの間に見えない汚れが溜まってるのかもしれないぞ。 早速、アルコールでフィルムを綺麗に拭き取っていきます。 乾拭きした後、試しに仮接続してみると、ちゃんとダブらずに入力できています。やった！直ったぞ！

組み立て直して接続してみても、ちゃんと入力できています。修理成功です。 定価8,000円の品を、たったの500円で手に入れたことになります。 実は、もう直らないかと思って、これの後継機種に当たるiKey SLIMをネット通販で注文しちゃったんですが、慌ててキャンセルしました。 こちらの方は、なぜか定価が3,280円と大変お買い得になっていたわけですが、500円にはかないませんよね。

気になる使い心地なんですが、キータッチが軽くストロークも短いので、指の力の持って行き場所に困ってしましまいます。 この記事はこのキーボードで入力してるんですが、ようやく指が慣れてきました。 これまでのアルミボディ＆メカニカルスイッチのキーボードとは正反対の感触ですが、これはこれでとても良い感じです。 もしかしたら、ブログの文章も軽くなったりして。

というわけで、ハラハラ・ドキドキで大満足のお買い物でした。

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

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

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

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

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

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

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

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

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

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

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

秋色の公園

わざわざ見てはいないけど、みんな感じてる。

世界チャンピオンの味

こやさんから、皇朝の肉まんあんまんをいただきました。
どうもありがとう！

XPのまとめ

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

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

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

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

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

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

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

靴も買ったよ

高級品じゃないけど、嬉しいな。

合格証書

嬉しいな。額を買いに行ってこよう！

代弁者としての存在

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

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

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

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

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

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

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

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

学習に休む暇なし？

あれこれ勉強しているうちに、気づいたことがあります。

「効率良くソフトを作りたい」→「頻繁にリファクタリングをする必要がある」→「GoFデザインパターンの理解が必要」→「UMLの理解が必要」というわけで、リファクタリングの本を軸にしつつ、デザインパターンやUMLの本を拾い読みしているところなんですが、本の書き方にもいろんな種類があるんですね。 内容がきちんと分類されている本、わかりやすく解説されている本、そして実例の豊富な本、などなど。

最初のうちは、上の流れに沿って「UML」→「デザインパターン」→「リファクタリング」の順に本を読もうとしたんですが、なかなか頭に入らないんですよ。 UMLは、単語や文法を覚えるようなものだし、デザインパターンも、その名の通りパターンの丸暗記でしかないので、どうも退屈で興味が続かないんですよね。 でも、リファクタリングの場合は、実例が豊富なおかげで、その効果がとてもわかりやすいんです。

いくら単語や文法、用例を豊富に知っていても、それらの具体的な使い方を知らなければ、良い文章は書けません。 日本人であれば、皆が良い文章を書けるかというと、決してそういうわけではありません。 また、良い文章を書く人が皆、話し上手というわけでもありません。 それぞれの様々な場面において、たくさんの経験を積み重ねることで、初めてそれらの知識が生きてくるんですね。

認知心理学では、物事を記憶するための方法を記銘方略と呼んでいて、体制化、精緻化、生成効果などがあります。 体制化は、文法のように、内容によって物事を分類していく方法です。 精緻化は、より詳しい情報を付け加えることで、物事の詳細を明らかにしていく方法です。 生成効果は、問いに答えていくことで、その答を自ら探し出す方法です。 そして、これら全てにおいて、リハーサル、すなわち反復が役に立つのです。

苦労して覚えたとしても、それを思い出せなければ意味がありません。 良く知ってる人の名前がなかなか出てこなかった、という経験は誰もがあるはずです。 記憶されていても、その時の検索条件に合わなかったために、検索結果に反映されなかったわけです。 つまり、ちゃんと検索されるためには、正しい条件付け、つまり有効な文脈で覚えなければ意味がないということです。

リファクタリングの勉強をしながら、iKeyboardの開発中に勉強した認知心理学のことを思い出しました。 あの時は、覚えた知識を生のまま使っていましたが、ようやくその知識を消化できたような、そんな気がします。 今、勉強中のリファクタリングも、ちゃんと消化されて血や肉となり、力となるためには、まだまだたくさんの経験が必要なんでしょうね。 そうなってくれる時が、とても待ち遠しいです。

生涯学習というよりは、自転車操業ならぬ自転車学習みたいな感じかな？

生きる道

この道は、ライブへと続く。

自由

冬の青空が、目に染みるぜ。

いろいろ勉強しよう

どうやら、オブジェクト指向について、思っていたよりも理解できていなかったようです。

というのも、私はREALbasicで初めてオブジェクト指向に出会って、REALbasicのマニュアルを読んでオブジェクト指向を覚えました。ところが、このマニュアルの説明が実にあっさりしていて、何度読んでもどうも良くわからなかったんですよね。すでにオブジェクト指向を十分に理解している人向けに書かれているようで、専門用語は覚えられても、その深い意味まではあまり理解できなかったんです。

もちろん、オブジェクト指向の基本的な概念は理解できたわけですが、オブジェクト指向ならではの、より便利な使い方というのは、ずっと気付かずにいたんです。それが、最近リファクタリングの勉強を通してJavaの様々な技術を知り、オブジェクト指向の理解も深まってきました。やっぱりJavaってオブジェクト指向言語として優れてるんだなぁ。いいなぁうらやましいなぁ。

ところが、そのJavaの技術が、ちゃんとREALbasicでも使えてしまったんですよ。最初に手にしたREALbasic 2ではなかった機能が、いつの間にか最新のREALbasic 2007r5では使えるようになっていたりして、ちょっと得した気分になってしまいました。ま

小さな世界

まだ若い彼の背中には、絵が描かれていた。

彼はそれを人に見せようとはしない。だが、それを見た人は皆、その絵に驚く。そして彼にこう尋ねる。「何これ、イレズミ？」。そう、それは刺青と言うには余りに拙く、中学生の落書きのような絵だったからだ。刺青の凄みは全くなく、その代わりに、若げの至りという一言で済ませてしまうのも憚られるようないたたまれなさが漲っている。

人は言う。「これを自分の子供が見たらどう思うと思う？」。彼は答えない。答えられない。誰よりも、自分がそのことをわかっているのだから。そして、その絵が背中だけでなく全身に及んでいることを知った人は、もはや言葉を失う。彼はただ「はい」と答えるだけで、会話が終わるのを静かに待つ。だが、その絵がある限り、その会話は永遠に続く。

私は、彼を笑えるだろうか。いや、笑えない。憐れみ？それとも同情？いや、それは同類だからだ。目には見えない子供の頃の落書きが、心の奥深くに刻まれていて、決して消えることはない。それがどんなに拙く幼稚なものでも、刺青のようにまとわりついてくる。彼は、その表現方法を間違えた。だが、その気持ちを笑うことはできない。

恐らく、彼の生きてきた世界では、それがとても魅力的なことだったんだろう。自分の世界を、自分に刻む。何て素晴らしいことなんだ！究極の自己満足。でも、自己は時と共に移り変わり、刻んだ絵だけが残されていく。とてつもなく大きな世界だったものが、人の目を避けるほどに小さなものになってしまった。こんなはずじゃなかったのに。俺は一生この落書きを背負って生きていくのか。

彼に与えられた道はみっつ。ひとつは、皮膚移植をして、過去の過ちを消し去る道。もうひとつは、これからも過去を背負ったまま、人目を避けて生きる道。最後のひとつは、落書きの絵を上書きして、立派な刺青に仕上げる道。そしてこれは、彼だけじゃなくて、過去を持つ人が皆、選ばなければならない道でもある。

もしかしたら、分岐のない真っ直ぐな道を歩んできた人もいるかもしれない。中には、与えられた道に文句を言うだけの人もいるかもしれない。でも彼は、少なくとも人生の分岐点に気付いたし、自分で道を選んだ。だから、何を言われても、「はい」と返事をするだけで、言い訳をしなかった。それは、より大きな世界を手にしたことになるのではないか。

何にせよ、人は小さな世界だけで満足することはできない。自分の世界を、広げていかなくては。

技術の前にあるもの

勉強して経験を積めば技術は身につきますが、それだけでは面白くありません。

パソコンを思い通りに扱えるようになったよ。洗練されたプログラミングコードを書けるようになったよ。惚れ惚れするほど美しい設計ができるようになったよ。確かに、技術力が上がれば、可能性も広がります。でも、どんなに優れた技術を持っていても、その技術が役に立たなければ意味がありません。たとえ、厳密に定義された要求を全て満たしたとしても、それで全てうまくいくとは限らないのです。

いろんなことを勉強して、いろんなことが見えてくると、完璧な理想郷を見たような気分になります。世の中の全てを把握したようなつもりになります。でも、実際には脳内のメンタルモデルが強固になっただけで、永久不変の真実を手に入れたわけではないのです。この新しい技術を使えば、過去の問題を解決できるかもしれませんが、それで問題が解決するわけではないのです。

現時点の最高の技術を使わなくても、ありふれた技術を適当に使っただけで、十分に問題を解決できることもあります。体調が思わしくなくて力が出ない時に、わざわざ病院で精密検査して点滴を打ったりしなくても、塩をかけただけの冷やご飯のおにぎりを作って食べた方が、より効果的なこともあるのです。

技術はあるに越したことはありませんが、技術があるがゆえに、技術に振り回されてしまうこともあるのです。完璧を求め過ぎてしまうと、時間も費用もがかかり過ぎてしまいます。かといって、速さや効率ばかりを追い求めていては、中身のないものになってしまいます。バランスを取るための技術もありますが、今度はありきたりでつまらないものになってしまします。

技術がないと何もできないし、技術だけでは何もできません。技術は、あくまでも論理の世界の道具でしかないんですよね。技術という水路に水を流すための豊かな感情の泉があって、初めて人の役に立つのです。その感情の泉を見ることができなければ、どんな理想郷も蜃気楼となって消えてしまうでしょう。世界を潤すためには、技術と感情の両方が必要なのです。

感情と要求というのは、似ているようで違います。好きな人とは一緒にいたいけど、一緒にいるように相手に要求してしまっては楽しくありません。相手の要求を察してそれに従ったとしても、やっぱり楽しくありません。一緒にいる時に楽しいと感じること。そこには何も要求はありませんが、最高に幸せになれます。

要求は、感情の後に生まれます。一緒にいるのが楽しいから、いろいろ予定を立てたりして、なるべく一緒になろうとします。一緒に楽しい時間を過ごしたいから、相手の好みを聞いたり、興味のありそうなことを提案したりします。そうした要求をすんなり受け入れられるのは、その背後にある感情に気付いているからなんですよね。

もし、感情を無視して要求だけを取り上げてしまうと、途端に窮屈な世界になってしまいます。要求を満たすために新たな要求が生まれて、どんどん条件が厳しくなっていきます。それによって悪い感情が沸き起こってもお構いなしです。そのうち皆が疲れてしまって、感情を失い、何も要求しなくなります。こんな世界は嫌ですよね。

感情が要求を生み、要求が技術を育てる。当たり前のことですが、忘れないようにしたいですね。

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

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

表計算で作った表を、タブと改行で区切った定数として登録しておき、それを起動時に変数に格納したかったんです。 表によって、列数と行数は違ってきますし、変数の型も変わってきます。 変数に代入した後は、それをいろんな場所で使用します。 さて、これをどうやって実装すれば良いでしょうか？ 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ですが、オブジェクト指向の総合開発環境で、手軽に扱えて、しかもネイティブにマルチプラットフォーム対応しているいうのは、とても魅力的です。 他にも魅力的な開発環境はたくさんあるわけですが、私のように個人で家庭向けの小中規模のアプリケーション開発をするような場合には、とてもバランスの良い開発環境だと思います。

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

いろいろあるさ

上を向いたり、うつむいたりしながら、前に進もう。

iKeyboardの再構築

iKeyboardを、一から作り直すことにしました。

あれ、リファクタリングするんじゃなかったの？ そのつもりだったんですが、あまりにも手に負えませんでした。 本来、リファクタリングというのは、オブジェクト指向の扱いに慣れた人が、構造が複雑化する前に、早めに最適化をすることなんですよね。 だから、途中でリファクタリングされないまま複雑化してしまった場合は、一から作り直した方がよっぽど早いというわけです。

ただ、これを機に全く新しいiKeyboardを作るぞ！となってしまうと、新しいアイデアを無理してひねり出したり、その度に試行錯誤を繰り返したりして、また開発に時間がかかってしまいます。 今のiKeyboardでも、動作自体は満足しているわけですから、わざわざ無理することはありません。 現状維持のまま、中身だけを入れ替える、つまり丸ごとリファクタリングしてしまおうというわけです。

まずは、空のWnidowに、キーボード表示用のSpriteSurfaceをドラッグして実行します。 次に、それをキーボード表示専用のサブクラスに替えて、また実行します。 今度は、キーの代わりに普通の四角形のSpriteを追加して実行しますが、四角形は表示されません。 表示の更新用のTimerを組み込んで実行すると、今度はちゃんと表示されました。 ループさせて複数のSpriteを追加するようにして実行してみましたが、全部同じ場所に表示されるので、見た目に変化はありません。

一体何をまどろっこしいことやってるんだ？と思うかもしれませんが、これがXP エクストリーム・プログラミングのリズムなんだそうです。 これまでも、似たような流れで開発してきたわけですが、やはりテンポの速さが違います。 最初は、ちょっと馬鹿馬鹿しいような気がしたんですが、実際にやってみると、このテンポの良さが次第に気持ち良くなってくるんですよ。 自然とやる気が湧いてきます。

このリズムのおかげで、一手一手が明確になるので、次の一手を導きやすくなります。 また、うっかりミスや勘違いもすぐに発見できるので、安心感があります。 前の手順を変更する時も、いきなり全てを変更せずに、最初の一手が正しく変更されたことを確認してから、他の類似した部分を変更します。 一度に多くを変更してしまうと、どこかにミスが紛れ込んだ時に、その発見や修正に手間取ってしまうので、これは便利ですね。

さて、キーのSpriteを正しく表示するためには、キーの各種情報を記述したデータベースを用意する必要があります。 各キーには、固有のコード番号が割り振られているんですが、日本語用と英語用のキーボードで、キーの配置が微妙に違います。 各キーコードには文字が割り当てられるわけですが、これもキーボードの種類やキーボード配列の種類によって変わってきます。 さらに、シフトキーの状態によっても変わってきまし、指使いの情報も付け加えないといけません。

これまでは、変換テーブルをたくさん用意して、力技で処理していたんですが、複数のデータがあちこちに散らばってしまって、とても複雑な構成になっていたんですよ。 でも今は、データベースの正規化という強い味方がいます。 元々の構造が複雑なので、表の数も多くなりましたが、データの重複もなくなって、実にすっきりとした構造になりました。 こんなに簡単に整理できてしまうなんて、今までの苦労は一体なんだったんだ！

こんな感じで、勉強の成果に驚き、感謝しているところです。 リファクタリングのためにはデザインパターンの理解が必要で、そのためにはUMLを読めなければならない、というわけで、図書館で参考書をどっさりと借りて勉強中です。 今週から来週にかけて、iKeyboardを題材にしつつ、これらをマスターしていきたいと考えています。 iKeyboardの再構築と機能追加が終わったら、次はいよいよHomeRecipeのリファクタリングと機能強化です。

実力がどんどんアップしていくのが感じられて、毎日がとっても充実しています。

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

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

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

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

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

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

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

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

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

ごほうび

これ、ぜ〜んぶ、ひとりじめ。(^^)

成績の詳細と今後の展望

基本情報技術者試験の成績です。

午前が心配だったんですが、それなりに点数の余裕がありましたね。 その代わり、思ったより午前と午後の差がありませんでした。 本当は、700点くらいで余裕で合格したかったんですが、さすがに世の中そんなに甘くはないですね。 でもまあ、ちゃんと合格できたので良しとしましょう。 初めての資格取得、それも国家資格です。 これまで、資格にはまるで興味がありませんでしたが、持ってみるとやっぱり嬉しいものですね。

ただ、資格そのものよりも、資格試験の勉強自体に、大きな意味があるように思います。 私の場合は、実務経験がないので、自分の実力を証明するために受けたわけですが、結果的に、より広い視野を持てるようになりました。 試験内容は、広く浅くといった傾向でしたが、あやふやだった基礎がずいぶんしっかりしてきたように感じます。 おかげで、より広い分野に興味が出てきたので、資格試験を受けた価値は十分にありましたね。

ただ、基本情報技術者試験の合格者の平均年齢は24歳、ようやくスタートラインに立っただけなんですよね。 次の目標のソフトウェア開発技術者試験も27歳なので、これが受かってようやく半人前。 アプリケーションエンジニア試験の32歳になって、ようやく人並み、年齢相応になります。 それが受かる頃には、プロジェクトマネージャの37歳に手が届きそうです。 まだまだ、やるべきことはたくさんあります。

もちろん、資格を取得しただけでは、あまり意味はありません。 それを活かした仕事をしてこそ、意味があるというものです。 今のように、オリジナルソフトを開発・販売していけたらいいのですが、残念ながら、それだけではとてもやっていけないというのが現状です。 じゃあ、どこでどんな仕事をしたいのか、となるわけですが、これがまだどうもはっきりしないんですよね。 まだ未練が捨てきれないところもあります。

とりあえず、これから来年にかけて、自分の実力アップに励んでいきますね。

合格 (^^)v

基本情報技術者試験、合格しました。
応援してくださった皆さん、本当にありがとうございました。

椎茸猫

土鍋なんかより、干し椎茸の方がいいニャ〜。

交わり

お互い棘を持っていても、通じ合えるものがある。

勉強したいことリスト

忘れないうちに、勉強したい事柄をリストアップしておきます。

ソフト開発

• アジャイルソフトウェア開発
• XP エクストリーム・プログラミング
• テスト駆動開発 (TDD)
• ユーザ機能駆動開発 (FDD)
• モデル駆動開発 (MDD)
• UML
• デザインパターン
• リファクタリング

今、マイブームになっているのが、XP エクストリーム・プログラミングです。 「より早く、より良いものを」というのは、ここ最近の私のテーマと一致します。 私は個人でプログラミングしているのでペア・プログラミングはできませんが、テストファーストやリファクタリングなど、試してみる価値は大いにありそうです。 UMLやデザインパターンを学ぶことで、プログラミングの幅も広げていきたいですね。

プログラム言語

• Java
• Objective-C
• C++
• Xcode

これまで、ずっとREALbasicを使ってきましたが、残念ながらあまり一般的な開発環境ではありません。 そろそろ、他所でも通用するような、一般的なプログラミングのスキルも身につけなければなりません。 汎用性でいえばJavaなわけですが、XcodeとObjective-Cを使って、Mac OS Xのコアな機能を活用したCocoaアプリケーションも作れるようになりたいですね。 個性はマイノリティの中にあり。

Web

• XHTML
• CSS
• Ajax
• Perl

Webデザイナーになりたいわけではありませんが、それなりに見栄えのする、今時のWebページくらいは作れるようになりたいですね。 私の中では、HTML 3.2で時間が止まってしまっているので、何とか時代に追いつきたいところです。 ブログを分割する時に、テンプレートをカスタマイズしながら覚えていけたらと思っています。

データベース

• SQL
• データベース設計
• データベースの正規化
• E-R図

資格試験の勉強では、目から鱗だったデータベースの正規化も、だいぶ馴染んできました。 面白いのは、ただ正規化を進めていけば良いわけじゃなくて、実装内容に合わせて、再び非正規化を行う必要があるというところです。 この辺りの勘も、養っていけたらと思います。 また、REALbasicでもSQLは扱えるので、実際にSQLを使ったアプリケーションも作ってみたいですね。

こうしてリストアップしてみると、いかに自分が何も知らなかったか、唖然とします。頑張らなくっちゃ！

うふ

ちょっと、休んでいきなさいよ。

あは

なんか、ほっとするなぁ。

図鑑の絵に想う

今日は寒かったので、博物館の代わりに図書館に行ってきました。

お目当てはもちろん、学研の図鑑「大むかしの動物」です。 小さい頃、学研の図鑑にはとてもお世話になりましたが、中でも「大むかしの動物」は、お気に入りの一冊でした。 何しろ大昔の動物なので、載っているのは絵と化石の写真ばかり。 でも、その絵が実に迫力があって、とても魅力的だったんですよ。 あの絵を、もう一度じっくりと観てみたいなぁ。 というわけで、わくわくしながら市立図書館へと向かったのでした。

早速、蔵書検索してみると、「大むかしの動物」には、1978年版、1986年版、1994年版の3つがあり、さらに「大昔の動物」というニューワイドの2000年版がありました。 私は1974年生まれなので、1978年版を選んで、係の人にお願いします。 閉架から出てくるのを待っている間、開架にある2000年版を探して観てみたんですが、予想通り、新しい絵に替わっていました。 マンガチックで、ちょっと可愛らしくて、まるでポケモン図鑑みたいです。

時代の変化に寂しさを感じてしまいましたが、1978年版を手にした瞬間、懐かしさで胸が一杯になりました。 ああ、この表紙！そう、これだよ、これ！ 恐竜の強さ、恐ろしさ、断然こっちの方がカッコイイ！ ページをめくっていくと、大昔の動物達が、まるで射すくめるかのような鋭さで迫ってきます。 弱肉強食の食物連鎖の厳しさが、無言の圧力となって突きつけられます。 その激しい競争の中で、生き残ったものだけが進化していく。 その進化の過程を、絵が雄弁に語っていました。

私の中では、大昔の動物達は、奇妙で恐ろしい、魅惑的な存在でした。 でも、今の子供達にとっては、ゲームのキャラクターのような、親しみやすい、友達のような存在なのかもしれません。 そういえば、ドラえもんの映画でも、のび太が恐竜と友達になってたよなぁ。 ただ、実際のところは、動物園や水族館の動物達のような、あるいは、公園の野良猫や田んぼのザリガニのような存在だったんでしょうね。

昨日の博物館でも感じたんですが、人は想像以上に直接的なのかもしれません。 博物館の展示はとても楽しかったんですが、正直なところ、展示の内容よりも、ジオラマの賑やかさや、模型の精密さに感動した部分が大きかったように思います。 図鑑にしても、ずっと印象に残っていたのは、内容そのものよりも、絵や図などの表現部分でした。 結局、物事の理解よりも、体験による印象の方が、より影響が大きいということなんでしょうね。

博物館や図鑑をきっかけにして、日々の生活でいろんな興味を追求していくのが良さそうです。

さあ、博物館に行こう！

今日は、県立博物館にも行ってきたんですよ。

鹿児島中央駅周辺を散策した後、市役所横の幸楽ラーメンで腹ごしらえしてから、市立美術館に行きました。 子供の絵を複雑な心境で鑑賞しつつ、やや食傷気味の本展示を観終えたものの、どうもちょっと物足りないな。 そうだ、向かいの建物にも、確か何か展示をしてたような。 西郷さんの横の歩道橋を渡って、立派な公民館の前を横切ると、四角い大きな建物が見えてきます。

実は、これが何の建物かずっと知らなかったんですが、県文化センターだったんですね。 この建物、入口がふたつあって、左側は普通のホールの入り口。 そして右側が、県立博物館のプラネタリウムと恐竜化石展示室への入口なんですよ。 う〜ん、これは知らなかったなぁ。 ちなみに、県立博物館の本館は、照国神社の角のところにあります。 本館の方は行ったことがあったけど、こっちの方はまだ未体験です。これは楽しみ！

エレベーターで4階に上がって、一般の札を県内の穴に入れます。 ん、何のこと？実は、県立博物館は入場無料で、入場料の代わりに入場者の調査をするんですよ。 で、ここはワンフロアの小さな展示場なんですが、雰囲気が実にいいんです。 美術館のような堅苦しさは微塵もなくて、とっても開放的です。 お母さんとやってきた子供達も、感嘆の声を上げながら、興味津々で展示を眺めています。

そして、この展示がまたいいんですよ。 目玉の大きな恐竜の化石は二体だけで、後は三葉虫やアンモナイトなどの地味な化石ばかりなんですが、その半数が本物で、これは全国的にも珍しいんだとか。 説明書きもていねいでわかりやすく、何より手描きのレタリングが味わい深い！ 学研の図鑑「大むかしの動物」からのコピーも、懐かしさで泣きそうになっちゃいました。 ここには、子供の頃のワクワクがぎっしり詰まってる！

プラネタリウムはすでに上映時間が終わっていましたが、手作り感たっぷりの展示に、なんだか人の温もりを感じました。 展示の仕組み自体が古くて、展示そのものに博物館的な価値がありそうな。 今の先端技術と比べたら、学校の理科の実験にも負けそうなものばかりです。 でも、当時の人達は、自分達の持てる技術を集めて、子供達が楽しめるように、精一杯の努力をしたんだろうなぁ。

とても楽しめたので、県立博物館の本館にも行ってみました。 もちろん、こちらも無料。 こちらは前に来たことがあったはずなんですが、想像以上に展示がしっかりしていて驚きました。 恐竜化石展示室が手作りの味わいなら、こちらは職人さんの技が光る展示ですね。 時間がなくてゆっくり観れなかったので、明日またじっくりと本腰を入れて観ることにします。 これだけ楽しめて無料なんて、鹿児島って素晴らしい！

皆さんも、ぜひ博物館に足を運んでみてくださいね！

行け！駅裏探検隊！（後編）

というわけで、後編ですよ。

駅前の商店街に限らず、駅周辺というのは新陳代謝が活発なので、いつもどこかで工事が行われています。 前に何があったのか、今となっては思い出せませんが、今日も結構な広さの土地が更地になっていました。 どうやら、ここにも高層マンションが建つようです。 交通の便は最高の場所なので、きっとリッチな人たちが入居するんだろうな。 その一方で、古い鉄筋コンクリートのワンルームマンションでは、何度目かの入居者募集が行われていました。

私は別に、鉄道ファン、いわゆる鉄ちゃんではありませんが、鉄道のある風景には、心惹かれるものがあります。 無理矢理隙間を空けたようなガード下を、頭をぶつけないようにドキドキしながらくぐったり、今となっては貴重な雑草の生育場所として、その長閑な景色を楽しんだり。 そして、線路の周りで毎日繰り返される、たくさんの人達の、様々な生活。 ああ、みんな生きてるなぁ。私も頑張って生きようっと。

鉄道の色はどんな色？と聞かれたら、私は迷わず赤茶けた鉄錆の色を答えるでしょう。 踏切の黒と黄のしましま模様も捨て難いし、カンカンと鳴り響く信号の赤い色も印象的ですが、私にとっては、吹き出る錆に、流れ落ちる錆、とにかくもう錆色が一番ですね。 不思議なことに、出来立てでペンキ塗り立ての鉄道には、あまり魅力を感じないんですよ。 徐々にくたびれてきて、錆が浮いてくると、ちょうど周りの風景にも馴染んでくるんですよね。

鉄道といえば電車、電車といえば電線。 というわけで、線路上にはたくさんの電線が入り乱れています。 この踏切では、電車とは無関係そうな電線まで入り乱れてますが、こういうゴチャゴチャしたところも、電車の魅力ですよね。 線路の近辺には、関連会社のちょっと変わった建物なんかがあったりして、独特の情緒を醸し出しています。 この建物も、元々は別の役割だったものを、再利用したんでしょうね。きっと。 窓の配置がロボっぽくてイイ！

そして、駅といえば、駐輪場です。 西鹿児島駅から鹿児島中央駅に変わってから、駅周辺の取り締まりが厳しくなりました。 それで、駅から少し離れた場所に自転車を置いてきたわけですが、何とこの駐輪場、最初の二時間は無料なんですね。 さらに、次の22時間までは、たったの100円。 なんだぁ、それなら堂々とここに停めれば良かった！ 駐輪場の脇では、人知れずひっそりと白い花が咲いていました。

久し振りに、のんびりと散歩を楽しみました。