発売延期

アプレットを手直ししようかと思っていたのだが、家に閉じこもりきりなのもどうかと思い、書店へ行く。そう言えば6月1日は涼宮ハルヒシリーズの最新刊「涼宮ハルヒの驚愕」が発売される予定だったよなぁと思っていたら、「涼宮ハルヒの驚愕」発売延期のお知らせの広告が目に入った。そうですか、延期ですか。書籍の発売予定日が遅れるのは毎度の事なので別にかまわないのだが……。

書籍を2冊ほど購入して、自宅に帰ってアプレットの見直し。

2007年05月31日(木) 21時02分  

アップロードの罠、再燃

とりあえず自分のPCからネットのアプレットが実行出来ることを確認してから、元のパズルゲームを作成した知人にメールで連絡してみる。

しかし、戻ってきたのは、ロード出来ずにそのままFireFoxがフリーズしてしまうとの返事。InternetExprolerでもロードに失敗してしまうらしい。ウチの自宅のPCはキャッシュでも表示していたのかもと思い、自宅に帰ってからFireFoxで確認。確かにアプレットを読みに行ったまま戻ってこない。終了させてもプロセスは生きているという状態。では、InternetExprolerだとどうなのだろうかと試してみると、こっちもロードエラー。

Firefoxがフリーズする問題自体は、去年あたりから現象が報告されているようだが、アプレットがロード出来ないのは全く別の問題。昨日、頭を悩ませていた問題が再燃した模様である。

とりあえずJavaコンソールに表示されるエラー等を元にネットで情報収集した結果、どうやらパッケージ名が原因になっているらしいことがわかった。

ネット上で紹介されている普通のアプレットは大抵1classファイルで構成されているのでパッケージ名も無く特に意識する必要は無いのだが、私が作成したアプレットはいくつかのclassファイルで構成されているのでパッケージ名というものが付けられている。

そしてそのパッケージ名は、ローカルではフォルダという形になっているのだが、eclipseはアプレットを実行するhtmlファイルをパッケージ名にあたるこのフォルダの中に生成してくれていたので、私は気づかずにそのフォルダの中身だけをアップロードしていたのである。

というわけで、アップロード先にパッケージ名と同じフォルダを作成して、その下へclassファイルをアップロードすることで解決。ローカルとは少々異なる階層構成になってしまった。

2007年05月30日(水) 23時39分  

アップロードの罠にはまる

粗方バグを潰すことが出来てまともに動作するようになったので、ネット上にアップロードしてみることにする。しかし、なぜかアプレットのロードに失敗してしまう。ローカルと同じファイル構成・階層構造でアップロードしているのだが。とりあえず空腹感を感じたので、夕食というか夜食を食べながらネットで情報収集。

ちなみに今日の夜食は、またもやプログラミングに没頭し過ぎて買い物に行きそびれてしまったので、おにぎりと冷凍食品。なので、写真は割愛。インスタント麺を食べなくなった代わりに冷凍食品を食べる頻度が増えたなぁ。

調べてみた結果、appletタグのcodebaseの設定が疑わしいように思えてきたのだが、いろいろと設定を変えてもローカルでは動作するのだが、相変わらずネット上にアップするとロードに失敗してしまう。ファイル転送モードも、ファイル構成も、階層構造も確認済み。

eclipseを使わずに、最新バージョンのJavaSDKのjavacを使ってコンパイル環境を変えてみても状況は変わらない。逆にキーボードイベントの取得に推奨されないAPIを使っているとの警告が表示されて、その部分を書き直すことになる。余計な作業が増えてしまったが、今後の為である。良しとする。

その後、気を取り直していろいろ適当にやっているうちになぜかロードに成功。原因は何だったのだろうかと考えながら、夜も遅いので本日の作業を終了。

2007年05月30日(水) 01時50分  

テストプログラムがひとまず完成

昨日調べた情報を参考に、テストプログラムを修正してみる。今度はちらつかないで画面が書き換えられていく。素晴らしい。表示している画像はしょぼいが。

続いてキーボードイベントを取得して、カーソルキーで画像を移動させるだけのテストプログラムを書いてみるが、あっけなく完了。MS-DOSのシステムコールとハードウェア関連書籍を地道に片手にプログラミングしていた頃に比べると、今の環境は格段に楽だなぁとつくづく思う。特に、わからない事があればすぐに調べられるインターネットという環境の存在はかなり大きい。

とりあえず一通りテストが終わったので、今度はゲーム本体のコーディングに取りかかる。一番肝心な部分なのだが、コーディング中にもeclipseが即座にエラー箇所を指摘してくれるので、どうにか完成にこぎつけることが出来た。

プログラム内部に適当にテストデータを生成する処理を書いて、実行させてみる。一通り動かしてみて、……やっぱりというか、バグを発見(苦笑) しばらくバグを潰しては実行しての繰り返し。orz

2007年05月29日(火) 19時53分  

アプレットのコーディング

今日はアプレット本体のコーディングと、画像の作成。先に画像の作成作業を行う。画像はWindowsのペイントを使って作成。今回は画像を切り替えてアニメーションさせるわけではないので、楽な作業。なのだが、ペイントは相変わらず使いづらい。もう少し使い勝手の良い画像作成ソフトが欲しいところ。

ほどなくして画像の作成が済んだので、今度は作成した画像をアプレット上で表示させるテストプログラムを作成する。ネット上の情報を参考にしながらのプログラミングは疲れる。そしてテスト。一応、無事に表示出来たみたいなので、今度は動かしたい。ということで、今度は画面を書き換えて動いているように見えるテストプログラムを作成。……ダメじゃん。VSYNC割り込みのような処理をしないとやっぱり画面がちらついてしまう。というわけで、再びネットで情報収集。ついでに、キーボード等のイベント処理についても調べて今日の作業は終わり。

2007年05月28日(月) 23時11分  

パズルゲームの内容を思い出す

今日は昨日に引き続いて、友人が作成したパズルゲームの内容を思い出しながら、eclipse上でクラス図に書き起こす作業。と言っても、相変わらずUML自体の使い方を習得しているわけではないので、どのようなクラスが必要で、そのクラスにはどのようなフィールド(変数)やメソッド(操作)が必要になりそうかを書き出しているだけである。

クラス図に書き起こす作業が一段落したので、次はコーディングの作業。……なのだが、なかなか捗らない。JavaのAPIを把握出来ているわけではないので、ネット上の情報を参考にしながらの作業となる。

とりあえず基本的なクラスは完成。次はアプレット本体のコーディング作業。表示させる画像も作らないと。

2007年05月27日(日) 23時54分  

対戦プログラムは保留

Javaを再勉強する為に、先日から昔N88-BASICで作成した対戦ゲームを書き直してみようかとeclipse上のUMLエディタでクラス図を練りながらあれこれ考えていたのだが、予想以上に大きな構成になりそうな感じだったので、もう少し単純なものにすることに。それまでは対戦プログラムは保留。

代わりに題材として選んだのは、学生時代に友人が作成したパズルゲームである。私は学校の帰りにこのパズルゲームをプレイするために一時期、毎日のように友人宅へ寄っていた。SHARPのX1 Turboという機種でBASICで作成されており、私が初めてプログラミングに興味を示すきっかけになったゲームである。ただし、興味を示したものの「難しそう」という先入観があったのと、当時の私はTRPGのほうに夢中になっていたので、私が実際にプログラミングを覚えたのはずっと後になってからである。その後、そのパズルゲームがディスクドライブの破損で出来なくなったという話を聞いて、ならばいつか自分の手で再現してみたいと思っていたのが私がプログラミングを覚えるきっかけ、原動力になったのかもしれない。

代わりの題材を探そうとしにネット上で公開されているJavaアプレットのゲームもいくつか候補として検討してみたのだが、題材としてあまり魅力を感じなかった。何よりも友人が作成したパズルゲームを再現したいという欲求には勝てなかった。とは言え、Javaを再勉強する題材として適しているかどうか。

とりあえず学生時代にプレイしたパズルゲームの記憶を手繰り寄せて、ノートに書き留めてみる。次はクラス図を書き起こして検証である。

2007年05月26日(土) 23時26分  

UMLエディタでクラッシュ対策を練る

eclipseに導入したUMLエディタを利用して、アイデアを練ったり考えていることを整理したりすることが増えてきた。OpenOffice.orgのDrawも試してみたのだが、使い慣れていないこともあって現在はeclipse上のUMLエディタに落ち着いている。

今回整理したのは、先日のHDDのクラッシュで再検討する必要が出てきたPCのハードウェア構成とドライブ構成、バックアップ手段についてである。バックアップ手段についてはもともと選択肢が限られているので、あとはバックアップ作業を行うタイミングだけを考えれば良いのだが、クラッシュによる被害を最小限に抑えるハードウェア構成とドライブ構成については、手帳や付箋紙に書き出してみたりしたものの、考えがうまくまとまらない。

そこでUMLエディタのクラス図を使って全体の見通しを良くしてみようと試みる。クラス図を利用するあたり相変わらず本来の使い方ではないのだが、結果的にこの試みは成功で、付箋紙等に書き出して検討するよりも効率が良かった。同時に欲しいと思っていても実は必要なかったり、逆に不足しているハードウェアとかも見えてきたり……。

とりあえず見通しの良い形に整理出来たので、保存。何日か時間を置いてから、見直しである。

2007年05月25日(金) 21時01分  

機能的(?)な栞(ブックマーカー)の作成

デスクトップPCや携帯電話、手帳に書き溜めていたメモを記事にして、順次投稿。こういうものは溜めると面倒である。極力溜めないように心がけなければ。

昨日、電車の中で思いついた栞のアイデアを形にする為に、スーパーへ材料集め。

必要な材料は、

  • クリアファイル
  • 太さ2~3mm程度の、細くて軟らかいリボン(30cm程度)

だけである。クリアファイルは5枚入りのものを100円コーナーで調達、リボンは洋裁コーナーで。クリアファイルは1枚しか使わないので、実質、合計40円程度の費用。余ったクリアファイルは、別の機会に本来の用途に使用。

帰宅後、実際に作成にとりかかる前に、栞の大きさとリボンの長さを検討。栞はメモ帳やノートを1枚使って、いろいろな大きさを作って試してみる。結果的にA7サイズ(文庫本の半分の大きさ)からクレジットカードサイズぐらいの大きさが妥当のように感じられた。

クレジットカードサイズならば、気にならなければ使用済みのテレホンカード等でも代用出来る。また、おしゃれな名刺やカードを持っていれば、それらを使うのも良いかもしれない。

作り方は簡単。

  1. クリアファイルを好みのサイズに切り取って、2枚用意する。大きさや色の組み合わせはお好みで(今回は同色で作成)。
  2. 上辺に穴を開ける。
  3. リボンで輪を作り(私の場合は20cm使用)、ストラップの要領でそれぞれの栞の穴に取り付ける。

以上で完成。栞を2枚1組にするのは、1枚の栞(Aとする)を読み始めるページに挟む為で、もう1枚の栞(Bとする)は、読み終わった(=次に読み始める)ページへ挟む為のものである。次に本を開くときは、栞Aをぶら下げる形にして、栞Bから読み始めることになる。

写真は、A7サイズの栞を作成してフィルム付箋紙を貼り付けてみたもの。説明の為に適当に貼り付けたので、少々カラフル過ぎて見栄えはいまいちだが、なかなか良さげな感じ。

このように栞そのものに付箋紙を貼り付けておくことで、マークしておきたい箇所やメモしたい場合等にすぐに使用できるようになっている。今回作成した栞はクリアファイルを素材としているので、簡易的な下敷きをも兼ねている。

クレジットカードサイズの栞の作成は、購入したリボンの長さが予想よりも足りなかった為、次回に見送り。完成の暁には、手帳や財布に忍ばせて持ち歩きたいと考えている。

2007年05月21日(月) 23時53分  

機能的(?)な栞(ブックマーカー)を思いついたり

前日、Javaの勉強で夜更かししてしまったので、昼前になってから起床。夜更かししないで、早起きするようにしなければ。

昼過ぎあたりに知人とメッセンジャーで会話。成り行きというか、勢いでモーモーパラダイスで外食することに。ふと自分の食生活の栄養のバランスの悪さが頭をよぎるが、悲しくなるので深く考えないことにする。

合流した知人と食事の前に100円ショップへ行き、買い物。購入したものは、マグネット式のホワイトボードとダブルクリップと乾電池。ホワイトボードは、冷蔵庫のドアに貼り付けておいて、使い切ってしまったものやアイデアをメモしておく為に購入。自炊している最中は覚えているのだが、食事の後片付けをしている頃にはすっかり忘れていることが多い。ホワイトボードマーカーは、近所のスーパーの100円コーナーにもう少し良い物があった気がするので、ここでは見送り。値段が同じだから、大して差は無いはずなんだけどな~。気分の問題かも。

食事をしながら、知人とFXや株式、経済の話題などいろいろと会話。また知人はSEの仕事に就いているので、現場ではオブジェクト指向で開発を行うのが当たり前になっているのだろうかとか聞いてみたり。

店を出て知人と別れた後、帰りの電車の中で本を読みながら、ふと栞(ブックマーカー)のアイデアを思いつく。忘れてしまわないように、手帳にメモ、スケッチしておく。なかなか機能的なアイデアだと思うのだが、実際に作成・使用して検証してみなければ何とも言えない。自宅に材料が揃っていないので、後日。すでに他の人が実践していそうだけど。

2007年05月20日(日) 23時57分