プログラミング
ぬるぽ→ガッするゲーム May 20, 2005 00:05
- Permalink
- Comments (2224)
- Trackbacks (1)
プログラミング
Javaとswingの勉強をかねて、ゲームを作ったよ。
Download → nullpo.jar
起動方法は……。
java -jar nullpo.jar
もちろんJava VMが入っていれば、winでもリンゴでもペンギンでも動くはず。
手抜きのクズゲームだけどね。内容はもぐら叩きです。 着想はMonaOSのBayGUIアプリ。 モロです。
ぬるぽされたら……
∧_∧
( ´∀`)< ぬるぽ
こいつをクリックしてガッします。
人 ガッ
< >__Λ∩ ※早めにガッしないと消えてしまいます。
. V`Д´)/
ガッするのに必死なあなたを見て、ときどき釣りをするやつが現れます。
∧_∧
( ´∀`)< つるぽ
こいつはガッしないでください。減点になります。
ごく稀に、喪男がぬるぽしに来ます。
('A`) ぬるぽ
こいつはガッしていいです。以上、取説でした。
作ってく中で、ブチあたった問題が2つ。
1つは日本語が化けて豆腐になっちゃうこと。 これは「Debian上でJ2SE5(J2SDK5)で日本語を表示」 に書いてあるように、fontconfig.propertiesをコピーしてきて、 フォントをインストールされているものに設定したら表示できた。
もう1つは、*.javaファイルと同じディレクトリに画像がおいてあるんだが、 例えばそこの1つ上のディレクトリから実行しようとすると、画像がロードされなかった。 実行したディレクトリから画像をロードしようとするからだと思うが。 これは前にJeselがGTKで3x3パズルを作った時も困ってたことだ。
これは次のようにしたら解決できた。まー、core Java vol.1(p.644)に書いてあるんだけどね。 基本的過ぎるのか、web探しても見つけることができんかった……。
MediaTracker tracker = new MediaTracker(this);
img = Toolkit.getDefaultToolkit().getImage("title.png");
↓
MediaTracker tracker = new MediaTracker(this);
img = Toolkit.getDefaultToolkit().getImage(StartPanel.class.getResource("title.png"));
初swingだったけど、まだよくわからんな。あとオブジェクト指向で作る脳ミソができてない。 Cだと「こういうときはこう実装する」っていうパターンが頭にあるんだけど、そういうのがない。 闇の中。
GTKは? May 13, 2005 03:15
- Permalink
- Comments (0)
- Trackbacks (0)
プログラミング
Novellのミゲル・デ・イカザ氏(訳注:GNOMEプロジェクトを立ち上げた人物)が言うように、 「Cでプログラミングするには人生は短すぎる」のである。
衝撃的な言葉だな。「人生は短すぎる」とは……。あー、GTKは何でCなんだろうな……。 gtkmmとか使ってるやつあるのかな……。gaim、おちゅーしゃ、 その他SourceForgeをぼーっと見てるとやたらCが目立つが、 これらの開発者たちの人生は浪費されていることになるんだろうか……。 QTはC++ってのはホントかね? つーかC++もJavaとかC#見たらもう勉強する気が失せた。めんどくせー、ダメだ、もう。
「驚き」は少ない方が良い April 16, 2005 00:57
- Permalink
- Comments (313)
- Trackbacks (0)
プログラミング
今日は研究室で勉強する言語について、PerlやめてRubyにしね?ってのを提案してみた。 まー俺にとってRubyを使う最大の利点はオブジェクト指向プログラミングにおける 文法の素直さと効率の良さなんだけど、オブジェクト指向をかじったことない人達には Perlが持つ例外的文法をつっつく方がわかりやすいかと思って、いろいろくどくどうざく講義じみたことをした。
例えばPerlの変数には、ある値を保持する$scalarという書式を持つ変数と、
変数の集合をあらわす@array, %hashという、2種類が少なくともあるはず。
でもCにしろJavaにしろRubyにしろ、さらーと勉強した感じ、
変数は値の集合をそのまま保持するようなものはなくて、
数値か文字かポインタ(参照)というある単一の値を保持するようになってる(Rubyは数値かポインタ、
Cは構造体もか)。
で、問題はこの2種類の変数がお互い代入しあったり、引数になったりして、 両方をごちゃ混ぜに扱う場面になったとき解釈はどうなるんだーってのが、まず立ちはだかる壁としてある。 これは、変数名と値が1対1に対応するCなどでは、決して問題にならない (もちろんポインタの理解は必要だが別問題)。
こんなのはまだ一例だけど、結局
一見真新しい文法が予測可能で「想定内」であったり、既存の知識から説明がつくほうが
やっぱり言語の理解というのは進みやすいわけで、
Cなどをある程度まで知っている人からすると習得しやすいと思う。
だから検索でひっかかったRubyのプレゼン資料?にある、
「驚き」は少ない方が良い
というのは大賛成。
まー、俺はさすがにこれではもう驚かないけどね。慣れてしまったから。 あくまでこれから勉強する人にとってどうだって話でした。 俺にとってPerlを非難する理由はオブジェクト指向がしにくいって点だけ。
Perl or Ruby? April 09, 2005 13:44
- Permalink
- Comments (2297)
- Trackbacks (1)
プログラミング
これからの俺のテーマは自然言語処理なので、 プログラミング言語は好き嫌いや流行り廃りではなくて、 いかにツールとして最適かで選ばなきゃなと思う。
研究のインフラとしての Ruby
_ 組織または個人名:(匿名,仮称も可)
九州工業大学 情報工学部 知能情報工学科 野村・中村研究室
_ 対象とする問題の概要:
自然言語処理の研究に際しては小道具としてのプログラムやデモプログラムで 様々なテキスト処理が必要となります. 当時,テキスト処理能力と開発効率とに優れていることから Perl を 使っていたのですが, 大きな問題がありました. 大学の研究室としての性格上, 学生の入れ替わりに伴って引き継ぎが必要となるわけですが, 他人の書いた Perl スクリプトは非常に読みづらく, 読み解くよりも自分で書き直した方が早いというケースが多発しました. そこで,Perl と同等以上のテキスト処理能力と開発効率を持ち, Perl よりも 読みづらいプログラムに *なりにくい* ような言語が求められました.
うわー、今から思い浮かぶぞー。引き継ぎの時だけじゃなくて、研究室内で
お互いのソースが理解できないって図が。
特にPerlってのは熟練するほど「省略の美学」に洗脳されてしまうので(だがそれがイイ)
俺の書いたソースでさえ初心者には意味も利点もサパーリのはずだし、
「書き方は一通りではない」というスタンスをPerlという言語はとっているので、
ある書き方で書かれたものは、それを知らなければ理解できないってことになる。
逆に初心者のプログラムを俺が見た場合でさえ
「なんでこんな回りくどい書き方をするんだ、ムキー ヽ(`Д´)ノ」って
なってイライラがたまる→こっそり俺が書き直すってことになりそうだ。
つまり、他人の書いた Perl スクリプトは非常に読みづら
い理由がそこにある。
例えばCでお互いのソースを読みにくくする要因はこんなところだと思う。
- アルゴリズムの洗練度の違い
- スペースや空行の取り方の違い
- 命名が不適切
- モジュール分割の仕方が不適切
これらは言語の使い方の問題だ。つまり言語の学習コスト自体は低い。 でもPerlは多少熟練するまで目の前にある構文がわからないってことがありうる。 もちろんPerlが学習困難で利用しにくい言語と言うわけではない。 他人のソースを読むにはそれなりのPerlのボキャブラリーが必要ってことだ。 つまり可読性が、アルゴリズムの構成力や作法だけではなく言語自体の熟練度にも左右されてしまうと思う。 と、偉そうに書いてみた。その点Rubyはどうなのか、勉強しながら考えてみたい。
SourceForge.jpの各プロジェクトの人数統計 March 16, 2005 03:41
- Permalink
- Comments (319)
- Trackbacks (0)
プログラミング
SourceForge.jpには現在1,429のプロジェクトが登録されているそうだが、 その中で最近1週間で活発なプロジェクト の上位130のプロジェクトについて、開発メンバーの人数を調べてみた。
| 1人 | 56 projects | 43.1% |
| 2人 | 25 projects | 19.2% |
| 3人 | 10 projects | 7.7% |
| 4人 | 9 projects | 6.9% |
| 5人 | 8 projects | 6.2% |
| 6人 | 6 projects | 4.6% |
| 7人 | 5 projects | 3.8% |
| 8人 | 2 projects | 1.5% |
| 9人 | 3 projects | 2.3% |
| 11人 | 1 projects | 0.8% |
| 12人 | 1 projects | 0.8% |
| 13人 | 2 projects | 1.5% |
| 15人 | 1 projects | 0.8% |
| 17人 | 1 projects | 0.8% |
合計が130になってるし、多分うまくデータがとれたと思うんだが。 ちなみに割合はあとで電卓で出した(;´Д`)
調査の対象として「最近1週間で活発なプロジェクト」を選んだのは、 この春休みで何かに参加するならレスポンスが早そうなプロジェクトを当たってみるべきだと 思ったからだ(あと、たくさんやると時間がかかるから)。 開発人数についてはすぐにいくらでもデータが取れるので、 このデータの他に要望があれば言って欲しい。
このデータからわかることは、SourceForge.jpの最近活発だったプロジェクトの半分近くは 1人で(´・ω・`)ショボーンと開発されているということだ。 残りの1,299のプロジェクトについても推して知るべしか。 まーピンキリだろうから、こんなもんなんだろうか。 とは言え、人数の多さがソフトウェアの善し悪しに影響するわけではないが、 オープンソースの活動の現実を少しかいま見ることができたような気がする。
つーかなぁ、アカウント作成してみたのはいいんだけど、プロジェクト協力者募集 のページが寂し過ぎ。
コードの保守ってこのことか March 02, 2005 12:30
- Permalink
- Comments (314)
- Trackbacks (0)
プログラミング
今ブログの見えないところをちょこちょこいじっているんだが、 1年以上前に書いたソースがうんちだったので、そこの修正に追われていた。
当時は適当に作って「いつか直すだろ」と思っていたんだが、 それを直さずそのまま使ってしまっていたわけだ。 1から作り直すよりは、多少ゴミでも動けばいいから……なんて。
あと使い方が書いてないと、時間が経ってからまたソースを読み返すことになるんだな……。 とりあえずあとでまた使うことも考えて、取説も結構しっかり作っておいた。英語で。 ここまでやることはなかったかな……。
speedbarでプログラミング環境が快適になりますた October 04, 2004 02:28
- Permalink
- Comments (2307)
- Trackbacks (0)
プログラミング
ちょっと前にJDEEを入れようとして結局失敗に終わったんだが、 そのときにapt-getでインストールしたspeedbarがプログラミングするのにかなり便利です。
emacsの右に出てる縦長いのがspeedbarで、emacsのメニューから、または M-x speedbarで立ち上げることができます。 まあそのへんはemacsのことなのでいくらでも起動の仕方はありそうですが。 だれかemacsの本買ってよ。
このspeedbarは普通に立ち上げるとただのディレクトリツリーを出すだけですが、 どうやらetagsコマンドで作ったタグテーブルに追加されているファイルを開いた状態で speedbarを表示すると、そのタグテーブルが表示されるみたいです (etagsについてはwiki参照)。
つまり定義した関数の一覧ですね。それがずらーっと並んでくれて、 もちろんダブルクリックとかEnterとか押せばその関数定義をしてるファイルを開いて ジャンプしてくれます。ミニバッファにM-.と書いて飛ぶときは関数名がわかっている 場合、speedbarは一覧から飛ぶときは覚えていない関数を探す場合、 と使い分けできそうです。
もう関数定義を探すのにマウスのホイールをぐりぐりするとか、 C-sとC-rを駆使するとか、そういう原始的な技はありえないすね。 もっと早くに知っていれば前期のソフトウェア実験はちょっと効率があがったんだろうに。 まーあのころはWindowsを使ってたから。 Windowsを使っていながらLinuxの便利な機能を偶然見付けるなんて普通ないすもんね。 つくづく思うのは、不便なんじゃなくて知らないだけだってことですわ。
クラス分け September 15, 2004 03:29
- Permalink
- Comments (0)
- Trackbacks (0)
プログラミング
blog作ってて思ったんだが、ちょっとでも性質が違ったらしっかり別のクラスに しておかないと、初め予定していたところまではうまく作れても、 その後の拡張ができなくなって結局書き直しってことになるんだなぁ。 つまり、初めは一緒に括れるくらい似ていても、 新しい機能を追加するうちに、それぞれ別の動きをするようになるってことがあるからだ。 まーつまるところ横着はいけないんですね……。
それにしても、どこまで細かくクラス分けするかってのは結構悩む。 is-a(継承)の関係なら、まだ分けるのもわかりやすい気がする。 でもhas-a(委譲)の関係を考える時ってちょっと大変ではないですか? クラスメソッドのソースコードが明らか複雑化しているのに、 その中の機能をオブジェクトとしてイメージできないとか。 こんなことするクラスってどんなだろう、みたいな。 勉強が足りんなぁ。
