2006年5月 のアーカイブ

Java

2006年5月31日 水曜日

研修で、Cの次はJavaについて学んでいる。
Javaは、Virtual Machineというメカニズムを用いて、コンパイル後の仮装機械語を一命令ずつ解釈して実行するというもの。
コンパイラと違って実行ファイルが環境依存にならず、インタプリタと違って文法エラーは事前にチェックできるという優れもの(とほめてみる)。

が、仕様がちょっと気にくわない。

1)forの拡張書式

List array = new ArrayList();
for(String s: args)
{
array.add(s);
}
for(String i: array)
{
System.out.println(i);
// 実行時にConcurrentModificationException例外を食らう。
// System.out.println(” Removed ” + array.remove(array.size() – 1));
}

for(int i = 0; i < array.size(); i++)
{
String s = new String(array.get(i));
System.out.println(s);

//こっちは正常
System.out.println(” Removed -> ” + array.remove(array.size() – 1));
}

ほぼ同じコードだが、配列の要素数が動的に変化すると例外を吐いて終わってしまうのが前者のコード。バグがあるけれど、そこはアルゴリズムでいくらでもフォローできるのが後者のコード。
BASICとかCOBOLとかで育ったプログラマは前者がいいのかもしれないけど、アセンブラとかCで育った私に前者は許せない。
インタプリタゆえ高速化が必要なのかもしれないが、それだったら素直にコンパイラで最適化しろと言いたい。

2)デストラクタ? ファイナライザ?
メモリ領域の問題。
メモリを正しく解放しないと、使用するメモリの量がどんどん増えていってしまう問題をメモリリークといい、サーバ関連のプログラムでは大問題になっている。クライアント関連では、ラグナロクオンラインクライアントの「BattleMode」バグは記憶に新しいところだ。
CやC++ではメモリ領域はプログラマが管理することになっており、あらゆる終了ルールに対してメモリ解放を行うべきという、高いプログラミングスキルを要求する。
それに引き替え、Javaは使わなくなったと判断したメモリ領域は勝手に開放する(ガーベジコレクション)ので、メモリ管理はかなり楽になる。
……と、これだけ聞くとJavaがすばらしいように感じるが。
C++には、あらゆる終了ルールに対して、たった一カ所メモリ解放を行えばいいという特別な場所がある。
クラスの「デストラクタ」メソッドである。
ここ一カ所だけで正しいメモリ管理関数を書いておけば、オブジェクト指向に従ったプログラミングに対してはメモリ管理が正しくできるという寸法だ。応用として、ファイル・ネットワークなどのリソースも同じ方法で管理できる。
C++にある、こんな便利な機能がJavaにないわけがなく。
Javaにも、やはり「ファイナライザ」というメソッドがある。

……が、「デストラクタ」「ファイナライザ」が正しいと仮定した場合、ここでJavaのメモリ管理機能が裏目に出る。
C++のデストラクタは、インスタンスが消えた瞬間に、確実に呼ばれる。ここで終了処理を行わないと、いつまでたってもメモリなどのリソースが解放されないからだ。
しかし、Javaのファイナライザの場合、インスタンスが消えても、実体が残っている限りはファイナライザが呼ばれるとは限らない。ガーベジコレクションがあるため、プログラム終了時あるいはガーベジコレクションが呼ばれるまでの「どこか任意のタイミングで」ファイナライザを呼べばいいだけの話になるからだ。

要するに、C++のデストラクタに比べ、Javaのファイナライザは動作が「読めない」という致命的弱点があるのだ。
これでは、せっかくの機能も宝の持ち腐れというものだろう。プログラマーレベルで最適なコードを用意するという、プログラミングの最高の喜びが手に入れられないのはあまり気にくわない。

ただし、あまり良くないコードに対しては確かに有効なわけで、どちらがよいのかは、プログラマーの「時間」と「自信」次第なんだろうなぁ、とか思ってみたりする。

3)JavaのフルコンパイラとかC++のVMとかないの?
C++のVMに関しては、ヨタ話程度には話があがっているようだが、Javaのフルコンパイラは検索にかからない(前処理コンパイラがばんばん検索にかかるので見つからないだけかもしれないが)。

C++のVMができたら、Javaが不要になるというわけでもないんだろうけど……どこかまじめに研究してくれないかなぁ。

予約

2006年5月30日 火曜日

乙女はお姉さまに恋してる キャラクターイメージソング(1)

とりあえず、実家周辺の兄メイトで予約してきました。

CVも発表されていないうちから、我ながら冒険だよなぁ……。

konozamaでアフィリエイトしてるんだから通販しるというツッコミはなしの方向で(笑)。

乙女はお姉さまに恋してる

2006年5月30日 火曜日

おとボクのアニメ化の情報ですね。そっち方面の私の知り合いはたいてい取り上げているようで。

スタチャ公式ページが更新され、悲喜こもごものようですが(原作絵に似てないゆえか、批判が強く聞こえてきます)、私は素直に「悪くない」と思った一人。
確かにマリみてのような神原画ではないにしろ、これくらいのクオリティあればお嬢様学園(本当は「学院」だけど)らしさはでるし、良すぎるまたは悪すぎるではないから、シナリオに集中できると思う。

……スタッフが最悪?
テレビを見ない私には、なんのことやら。

Firefoxあそび

2006年5月29日 月曜日

ときどき、掲示板なんかで、自分の書き込みに対して、

(Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

などという表示を目にしたことはないだろうか。
これは、ユーザーエージェントと呼ばれる、利用しているOSやブラウザの種類を表す文字列で、上の場合はWindowsXPにて、Internet Explorer6を利用していることを示している。
ここで、Mozilla Firefoxの場合、(私の設定だと、)

Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

がその文字列なのだが、しばらく前のおとボクチャットで、この値を任意に変更できるということがわかった。
やりかた。

1.URLを入れるところにabout:configっていれる
2.右クリック [新規作成]→[文字列]
3.general.useragent.overrideキーをつくって、偽装したい
useragentを入力

http://blog.livedoor.jp/maccy/archives/50012436.html
より。

で、チェック方法は、
http://fc.to/t2.cgi
の、「HTTP_USER_AGENT = 」パラメータをみる。
(アドレスはいつきさんに教わりました。感謝)

書き終えてすぐ反映されるっぽいのでFirefoxは優秀。ただし日本語の場合文字化けに注意。激しく注意。
これで手元のアクセス解析で、自分のブラウザが認識できずに困ることはないと思いたい。

……しかし、こうしてみると、中身Javaなんだなぁ、としみじみ。

アイディア、足りてる?

2006年5月28日 日曜日

コミケ当選しました。

受付番号70208-2020さんは
日曜日 東地区 “S”ブロック 03b  に配置されています。

……はぴねす!か……サークルカットのネタは4/30にやっちゃったんだよねぇ……。

ただ、こんなこともあろうかと、一応ネタだけは考えておきました。
新刊予定:
「ぱちねす! てんしょん(Ten:tion)」
ジャンル:はぴねす!りらっくす(Re:lucks)

あらすじ:
「私は普通の学生には興味がないわ、雄真のことが好きな人、
雄真のことを好きな人が好きな人、該当したら私の処へ来なさい、以上」
学級委員長・渡良瀬準の言葉に反応したのは、いつもの9名。
準が彼らに言い渡した『課題』とは……

玉石混淆の、10の話が織りなす小さな幸せ。
ぱちねす!てんしょん 絶賛執筆遅延中!

はぴねす!りらっくす

webとしての妥当性

2006年5月28日 日曜日

現在、コンテンツ移転作業の一環として、今まで作ってきたページがwebサイトとして正しいか(正しいタグを利用しているか)を検証しながらすすめている。正しくないタグを使ったページでは、将来ブラウザが保証しなくなる可能性があるからだ。

そこで私が使っているサイトが、以下の妥当性チェックサービス。

W3C Markup Validation Service

このサイトは、Webサイトの規格を作っている組織団体 w3c により公表されているページで、正しくないwebサイトに関しては、どこが間違っているのかを事細かにつっこんでくれる。

私はXHTML1.1に基づいてwebを構成しているが、引っかかったものとしては、「タグに大文字を使ってはならない」「aタグにtarget=”_blank”は利用できない」「&を使うときは、&amp;と書かなければならない」などなど。
新しく作ったページも、アフィリエイトのためにコピペしてきたURIなんかもつっこまれて、しどろもどろである。

webサイト移転を待っている各位には申し訳ないが、この作業は重要であると認識しているので、しばしお時間をいただければと思う次第である。

……そして、おそらくtarget=”_blank”は使い続けるでしょう、さすがにこれはないと不便なので……。

円周率

2006年5月28日 日曜日

<経緯>
会社の研修で、C言語を勉強しているのだが、内容が基礎的ゆえ全部『教えた』経験のある事柄ばかり、という暇っぷり。

んで、しゃーないので与えられた課題を、おかしな方法で解くことにする……ループ命令をいっさい使わず、再帰関数とif文でループをくむというやり方である。

これで、ほとんどの課題はうまくいったのだが、たったひとつうまくいかない課題があった。
「円の半径をコマンドライン引数からとって、円の面積を表示するプログラムを作れ」というものである。
一見簡単そうに見えるが、実は円周率πを正しく求めるのに、かなりの調査を要した。
まず最初に、小学生でもわかる求め方の一つとして、円とそれに外接する正方形の比をとる方法を2種類実装した。ひとつはランダムな点を打って、円の中か外かを判断することで、大数の法則に期待して円周率を求めるというやり方(モンテカルロ法という)。もうひとつは正方形の中にメッシュを張って、メッシュの各点が円の中にあるかどうかを判定するやり方。
要するに、どちらもCPUパワーに任せた、力づくのやりかたなわけだが、ループ命令を使わないデメリットがもろに出てしまう結果になった……すなわち、精度を上げようとループ回数を増やすと、スタック・オーバーフローによるエラーでプログラムが落ちてしまうのだ。

で、Wikipediaに頼って円周率を効率よく探すアルゴリズムを探してみると、「円周率の歴史」ページに、そのアルゴリズムがあった。

1995年9月19日午前0時29分

カナダのサイモン・フレイザー大学において、デビット・H・ベイリー、ピーター・ボールウェイン、サイモン・プラウフの研究チームが無限級数
¥pi = ¥sum_{k = 0}^{¥infty} ¥frac{1}{16^k} ¥left( ¥frac{4}{8k + 1} – ¥frac{2}{8k + 4} – ¥frac{1}{8k + 5} – ¥frac{1}{8k + 6}¥right)
を発見する。この式では2進表示または16進表示で n – 1 桁までを求めずに n 桁目以降の π の値を計算できる。ベイリーのウェブサイトで様々なプログラミング言語用の実装例を見ることができる。

これは、コンピュータ上において「桁数を区切って」円周率を求めることが可能という、画期的アルゴリズム。数式がTeXソース形式で読みづらいのはご愛敬。
このアルゴリズムの収束の早さに助けられ、私は無事円周率を再帰関数で求めることができた。私の「おかしな方法でプログラムを組む」というポリシーはこうして守られたのだ。

<主張>
で、ベイリー氏のサイトから。

あなたの名前が、円周率のどこの桁にあるか探してみませんか?

という、氏の円周率アルゴリズムの特長を生かした、すてきなお誘いが。

というわけで、実際に探してみた。

search string = “takumi”
30-bit binary equivalent = 101000000101011101010110101001

search string found at binary index = 3336826008
binary pi : 0110011010100000010101110101011010100101001100110011100111110010
binary string: 101000000101011101010110101001
character pi : up;ljm,rl;dwqnmsftakumiisggyhd;jlcx;wc
character string: takumi

というわけで、33億3682万6008桁めに私の名前があることが、このアルゴリズムにより明らかにされた。

あなたも、円周率の数字の奥深くに、自分の名前が隠されているかもしれません。ひとときの思い出のために、英語をおそれずに、少しの時間を使って、試してみるのはいかがでしょう?

移転のお知らせ

2006年5月27日 土曜日

「菅野たくみのチラシの裏」も3枚目になりました(移転多すぎ)。
自分のアドレスに落ち着いたので、lolipopがサービス終了するか、よほどサーバーが重くならない限り移転することはないでしょう。
(移転する場合、それは自前サーバーをたてるという意味なのでblogトップのアドレスは変更しません……今でもレンタルサーバーだからある意味自前サーバーではあるのですが)。

お金払ってるだけあって、gooよりも使い勝手は良さそうな感じ。けど、リアルタイムでプレビューが見られないのがちょっと難かとは思う……元々この手のコンパイラ系環境には慣れてるから全く問題はないけど。

ちなみに。
1枚目@ドリコムブログ http://blog.drecom.jp/aquahorizon/
こちらは機能・操作性は十分だったが、サーバーが重すぎて逃げた。

2枚目@goo blog http://blog.goo.ne.jp/eldersister/
NTTだけあってサーバーは安定していたが、アドバンスド機能があらかた有料オプション。安定性以外で評価するべきはお絵かきツールがblogツールとして標準添付されている点があるが、逆に画像upがやりづらくなっているなど、操作性に難がある。

一長一短のある二つのblogサイトから抜け出して、今度はレンタルサーバー上でのblog。果たしてうまくいくのか、やってみないとわからない。