「Program」カテゴリーアーカイブ

ゲームプログラミング

投稿日時: 投稿者:

VBAのゲーム本や、JavaScriptのゲーム本を軽く読んでみたりするのですが、VBAはExcelがないと動かすことが出来ないので、EeePCでは試してみることができません。OOoへ読み込ませたら、プログラム全部の行頭に REM がついてコメントとされてしまいました。JavaScriptのゲームは1024×600で起動されるWebブラウザというものを想定していないらしく、画面が収まりきらないという問題が… どちらも些細な話なのですが、やっぱり腰をすえてゲームプログラミングにとりかかるためには、専用開発マシンを一台用意して、それしかやらない環境というのを用意してあげないとよくないなぁと思う次第。

VBAの本には下記のサポートページがあるようです。

サウンドについては知りませんでしたが、音の杜というのがあるんですね。VBAアクションゲーム？Excel（エクセル）で動かそう！とか、エクセルVBAアクションゲーム博物館といったサイトもあるそうで、Excelもなかなかあなどれません。Excelで出来るならOOo Calcでもいけそうですが、WindowｓAPIをたたく系は厳しそうです。

JavaScriptの本には下記のサポートページがあるようです。

打ち込む気力がなかなかでてこないので、実際に何かゲームをつくるところまでいくのかどうかはわかりませんが、こういうフリーのゲームを作っている人がiPhoneのゲームやAndroidのゲームを作って小遣いを稼ぐということもありそうだなぁ、と思うと、ますますゲーム業界は大変そうだと思いました。

Android SDK

投稿日時: 投稿者:

久しぶりにAndroid SDKをさわって、EeePCへインストールしてみた。Eclipse + Android エミューレタがものすごく遅くて、これでは開発は厳しいと感じた。Androidエミューレタだけで動作させたらどうなるかも見てみたが、それでも遅くて厳しいと思った。Android開発にあたって、マシンはきちんと選ばないといけないようです。

iCalendar

投稿日時: 投稿者:

予定表関係のツールがほしいのですが、どういったデータフォーマットがあるのかと考えたら、iCalendarがあったということを思い出しました。これを使ってあげるのが一番シンプルな気がします。問題は、このデータフォーマットを扱えるライブラリがどれくらいあるかですが、それなりにあるようです。

RFC2445

システムでiCalendarを扱うには上記ライブラリを使えばいいのですが、ユーザとしてデータ編集をする場合にはツールがほしいところです。そんなときはMozilla Sunbirdを使うとかすれば良さそうです。Calendar プロジェクト – Lightning と Sunbird®のホームによると、ThunderbirdのAddonもありますから、連携させるのもいいでしょう。Linuxなら、Kontact Homepage – KOrganizer: Kontact Calendaringもあります。

ところで、メール情報はIMAPを使っているので、カレンダー情報も同じような仕組みで複数マシンで共有したいところですが、どうすればいいでしょう。そんなときは、WebDAVを使うと良いようです。単純な参照用Webインタフェースがほしい場合はPHP iCalendarが便利なようです。個人の情報しか使わないなら、Sunbirdとかで十分なので、わざわざWebインタフェースを用意する必要があるのか、と思うかもしれませんが、最近仮想マシンが増えているので、実マシン以外を使っているときに仮想マシンからアクセスするとなると、Webインタフェースあり、の方が便利そうです。ちなみに、大がかりになってくるとグループウェアを採用するか、という話になりがちなのですが、個人の情報と会社の情報は管理単位が違うので、マージする際は結局別々のシステムで管理しているデータを手元でマージするということになる点を考えると、躊躇します。グループウェアは確かに各アプリ（メーラ、TODO、スケジュール）の連携はしやすくできていますが、各アプリで管理するデータへ他の同様のアプリからアクセスできるような形にはなっていないことが多いからです。メーラなどはIMAPがでてきたのでいいのですが、TODOやスケジュールについてはiCalendarがどれくらい使えるか不明です。もし使えるなら、グループウェアも候補にいれたいところ。Kontact Homepage – Supported Groupware Serversによると、いろいろありますね。以前エントリしたグループウェアとかもありますし。

PDAとかの対応も気になりますが、Windows Mobileなら、RemoteCalendars, the Outlook2003’s plug-in to subscribe, delete and reload your iCalendarというのがあるようです。

ちなみに、Movable Type の記事を iCal で管理する – かたつむりくんのWWWとかも面白い発想です。試験管のなかのコード :: iCal4j にチャレンジも参考になるかもしれません。

jrubystack

投稿日時: 投稿者:

いまさらですが、BitNami :: JRubyStackというのがあるそうです。

Windowsマシンの整理をしていて、セキュリティアップデートをしているのですが、結構な時間がかかるので、久しぶりにJRubyについて調べていたところ、いろいろと世の中は進んでいることを知りました。

JRuby Users JPができていたり、SunがSun Developer Connection – JRubyとJavaによるアプリケーション開発をだしていたり。Windowsで最新のRailsをJRubyで動かす。 | AIRS Labsという記事も見つけました。要点がまとまっている感じです。

Fedora9 では、yum install jrubyでjrubyをインストールできるようですし、ちょっと驚きです。そう思ってインストールしてみたら、jruby 1.1.3が簡単にはいりました。ところがエラーがでるので、調べてみたところ、バグレポートではjruby 1.1.5 へバージョンアップするように、と書いてあって、yum版はとりあえずあきらめることにしました。ふつうにjrubyをダウンロードしてきた方が早そうです。

ところで、NetBeansもJRubyをサポートしているので、jrubystackと、どちらを選択するかは、ちょっと検討してみたいところ。

replaceAll.pl

投稿日時: 投稿者:

文字列置換をするPerlプログラムを作るには、まず最初に標準入力をそのまま出力するプログラムからはじめればいい。

#!/usr/bin/perl
while(<STDIN>) {
  print;
}

置換をするためには、次のように指定を print; の前に挿入すればいい。こうすると読み込んだ文字列に対して、置換処理をしてくれる。

s/$ARGV[0]/$ARGV[1]/go;

このあたり、スクリプト言語というかPerlに慣れていないと、違和感があります。置換対象の文字列を明示的に指定しなくてもいい、というのがなんとも不思議です。

できあがったプログラムは replaceAll.pl という名前で保存したとすると、下記のように使います。

$ replaceAll.pl 検索文字列 置換文字列 < 対象ファイル

ちょっとしたツールは、シェルスクリプトでけっこう頑張っているのですが、Perlでもいいかなぁ、と最近思いつつ、最終的にはJavaで実装しておいたほうが何かといいんだよなぁ、とも思っています。開発環境的にはJavaの方が充実していますし、オブジェクト指向プログラミングもしやすいので。ただ、問題なのは、ちょっとしたツールにオブジェクト指向が必要なのか、みたいなところでしょうか。再利用性はほとんど考慮する必要がないので、ベタに手続き型で書いてしまった方がよっぽど速くプログラムが完成してしまうという気がしています。まぁ、ぼちぼちやりますけど。

HTML and CSS

投稿日時: 投稿者:

情報技術もずいぶん進化して、簡単にできるようになったことも多いですが、あいかわらず難しいことも多いと感じています。HTMLのようなマークアップ言語によって、ドキュメント（文書）へデータ構造を持たせたり、ハイパーリンクのような機能をメタデータとして埋め込むことが可能となったのですが、そのせいでドキュメントのデータ表現が随分と複雑化してしまったのではないかという気がしています。

一昔前であれば、「HTMLでは主にドキュメントを表現しているわけだから、ドキュメント構造を意識したマークアップが良い」という主張が普通でしたから、「DOM（Document Object Model）によりブラウザ上に展開されるドキュメントをオブジェクトとしてモデル化し、プログラムから統一的に扱えるようにしよう」といった考えがでてくるのは自然な流れでした。

ところが、Webブラウザの世界では、ドキュメントを表現するためにHTMLを使うだけではなく、レイアウトデザインまで、HTMLで実装するのが普通となってしまいました。もちろん、ドキュメントとレイアウトを分離するために、CSSというものが考案されたわけですが、「論理構造を持ったドキュメントのレイアウトを見栄えよくする」ということには役に立つものの、「そもそも表示したい情報がたくさんあって、それらは論理構造的にはつながっていないようなものをレイアウトする」という目的には適していません。たとえば、body要素内において、ヘッダ部分にサイトメニューがあって、フッタには著作権表示があって、ヘッダとフッタとの間は、左右に分割されていて、左ペインにはサイドバー、右ペインにはコンテンツであるドキュメント、というようなWebページがあるわけですが、これを「１つのドキュメントだ」としてとらえるというのは無理があるわけです。こういったWebページは、divタグを使ってレイアウトの要素となる単位で分割して、そこへCSSを適用して全体のレイアウトを整えるのですが、これの意味するところは、「このWebページは複数のドキュメント（レイアウト要素）から構成されるもの」になります。ここで、レイアウト要素はFlashであったり、フォームであったりするので、それらはドキュメントとはいえないし、各レイアウト要素の間には強い結びつきがあったり文脈があったりするわけではないので、これを「１つのドキュメントだ」とモデル化するのは違うだろう、と考えています。

つまり、いまや、「Webページはドキュメントを主にコンテンツとして表現していれば良い」という時代は過ぎてしまったので、hタグやpタグを骨としてWebページを設計するということはなくなってきているのですが、これはHTMLの設計思想から乖離してしまっていて、どれが正しい、本来こうあるべき、といった議論がしにくい状況となってしまっています。このあたりを整理して、体系づけることが重要なのですが、誰かやっているのかなぁ、と思っています。

説明が不足しているので伝わらないかもしれませんが、結局、世界に普及した当時のWebブラウザは単なるハイパーリンクを含むドキュメントを表示するアプリケーションであったのが、現在はWebアプリケーションのユーザインタフェースを提供するプラットフォームという位置づけになっており、それにしては、これが解釈して表示できるのがHTMLで記述されたものだけだ、といったあたりが混乱を助長させている気がします。

Webアプリケーションのユーザインタフェースを提供するプラットフォームとしてWebブラウザをとらえたときには、DOMやCSSといった技術はドキュメントを対象としているわけではなく、主にクライアントサイドのWebアプリを実装するための技術要素の１つであることを認識して、これらを操作することができるJavaScriptや関連するライブラリもクライアントWebアプリケーション実装用言語だと考えると、結構すっきりと技術の整理ができるのではないかと思います。