メッセージ。 - diary
2010-03-08
# [日記] Amazon S3負荷テストの問題(Gaucheのread-block)
Wiresharkでパケットキャプチャを取ってみたら、負荷テストで問題が起こる原因が分かった。どうもプロキシサーバーが上位に送出しているHTTPヘッダのcontent-lengthと、実際に送出しているbodyの長さが一致していないときがあるようだ(content-lengthが65536なのに実際に送出しているデータの長さは8192バイトになるなど)。
なぜこうなっているかというと、要するにぼくのコードのバグなのだが、下位からデータを受け取るときに、単純に(read-block 65536 iport)などとしてネットワークから必要な長さのデータを読み込もうとしているところが間違っている。read-blockは指定された長さ分のデータをポートから読み込むが、実際にはポートに十分なデータがない場合などにいったん指定された長さに満たないデータを返す。つまり、「指定された長さが得られるまでブロック」という風になっていない。
なので、実際にこのへんをコーディングする際には、read-block!を使って得られた結果の長さをチェックし、欲しい長さに満たない場合は必要に応じて繰り返しread-block!を使って残りを得るという風にしなければならない。このへんは何度かプロキシサーバーを実装したときに知っていたのだが、今回コードを組んだときにはめんどくさいから端折ってしまったのだった。ということで、たぶんこれを直せばうまくいくはずだが、朝のコーディングタイムは時間切れ。続きは明朝かな…。
…あれ? と思ったけど、read-block!のマニュアルには「Function: read-block! vec &optional iport start end endian」とあって、取得するデータの長さを指定するというよりも、ベクターを埋めるという感じになっている。これだと、「read-block!したあと得られたデータの長さをチェックして…」ということができない気もする。実はふじさわは、ベクターやバイトデータが出てくるあたりが苦手で、Gaucheの仕様を正確に把握していないのだよね。(以前にプロキシサーバーを実装したときには、read-blockを複数回使って、imcomplete-stringをなんとか連結したりしたのだった。これで正しいのかもよく分かっていない…。そういえば、そもそもこのへんで返すデータの型がstringでいいのかという問題もあるな…)ということで、もうちょっと頑張ろう。
なぜこうなっているかというと、要するにぼくのコードのバグなのだが、下位からデータを受け取るときに、単純に(read-block 65536 iport)などとしてネットワークから必要な長さのデータを読み込もうとしているところが間違っている。read-blockは指定された長さ分のデータをポートから読み込むが、実際にはポートに十分なデータがない場合などにいったん指定された長さに満たないデータを返す。つまり、「指定された長さが得られるまでブロック」という風になっていない。
なので、実際にこのへんをコーディングする際には、read-block!を使って得られた結果の長さをチェックし、欲しい長さに満たない場合は必要に応じて繰り返しread-block!を使って残りを得るという風にしなければならない。このへんは何度かプロキシサーバーを実装したときに知っていたのだが、今回コードを組んだときにはめんどくさいから端折ってしまったのだった。ということで、たぶんこれを直せばうまくいくはずだが、朝のコーディングタイムは時間切れ。続きは明朝かな…。
…あれ? と思ったけど、read-block!のマニュアルには「Function: read-block! vec &optional iport start end endian」とあって、取得するデータの長さを指定するというよりも、ベクターを埋めるという感じになっている。これだと、「read-block!したあと得られたデータの長さをチェックして…」ということができない気もする。実はふじさわは、ベクターやバイトデータが出てくるあたりが苦手で、Gaucheの仕様を正確に把握していないのだよね。(以前にプロキシサーバーを実装したときには、read-blockを複数回使って、imcomplete-stringをなんとか連結したりしたのだった。これで正しいのかもよく分かっていない…。そういえば、そもそもこのへんで返すデータの型がstringでいいのかという問題もあるな…)ということで、もうちょっと頑張ろう。
2010-03-07
# [日記] 負荷テスト
今日は就職関連で人材会社の人と会ってきた。…が、人材会社の人って、なんでこうも感じ悪いんだろう。なんかこう、話していてもまったく共感とか感情移入がない。人間を完全に売り物としか見ていないのかね。不思議な感じだった。
--
Amazon S3の負荷テストについて。ちょっと負荷テストっぽいコードを書いてみたんだけど、プロキシを通すとうまく動かなくなる。デバッグプリントを入れると動いたりするようになって、なんか妙だ。こういうのにハマると、また時間取られちゃうんだよなぁ。いたずらに時間を浪費しないよう気を付けながらデバッグしたいが、とりあえず今日は時間切れ。おやすみなさい。
--
Amazon S3の負荷テストについて。ちょっと負荷テストっぽいコードを書いてみたんだけど、プロキシを通すとうまく動かなくなる。デバッグプリントを入れると動いたりするようになって、なんか妙だ。こういうのにハマると、また時間取られちゃうんだよなぁ。いたずらに時間を浪費しないよう気を付けながらデバッグしたいが、とりあえず今日は時間切れ。おやすみなさい。
2010-03-06
# [日記] 進捗あり!
ここんとこしばらく書いてるAmazon S3のテスト、うまく動いた! 例のプロキシサーバー形式がworkしたという感じで、問題なさそう。ということで残件は、もしやるとすればオプショナルな機能のテストと、あとは大量データの取り扱いのテストかな。後者はやるべきリストに入ってたし、Amazon S3を使いたいケースを考えれば必須だと思われる。ということで、明日以降はそれに取り掛かろう。まぁ、明日は明日でとある会社関連の就職活動で出掛けるので、使える時間がちょっと少ないけど。
2010-03-05
# [メモ] 行動原理
もちろんいまのは比喩的な表現だが、 基本的に、新山は「この世がどこまで続いているのか」ということについて 多大なる関心 (と恐怖) をもっているように見える。「この世」というのは、 物理的な世界にとどまらず、「自分の常識や論理が通用する領域」のことね。 しかし、ある意味では、自分は本当はそういう世界から足をふみ外すことを 望んでるんじゃないか、と思うときもある。新山はときどき 「どこまで進んだら自分の常識が通用しなくなるのか」を見きわめようとして、 突飛なふるまいに出るときがある。境界を越えることを恐れるくせに、 境界に近づくのはスキなのだ。世界の中心というのは 一カ所しかないが、「世界のはじっこ」は無数にあるよね…
このへんの話。自分に関しては、結局のところ死を怖れている。ぼくは昔から死について怖れ、考えている。怖くてこわくて仕方がなくて、どうしたらいいのだろうかと。それで1つ思い付いたのが、死に近付いてみること。人間は、理解できないからこそ何かを怖れるのだと考えた。死を理解できれば、怖れることはないのかもしれない、と。それでぼくは、死のそばまで近付くことにした。死のすぐそばでよく観察してみようと思った。
そうはいっても、別に死のうとしているわけではないし、自殺しようとかそういう話では全然ない。心と時間の使いかたの問題。ぼくは死ぬのが怖い。だから逆に死ぬことについて意識してみようと思ったのだ。昔ある漫画家さんが、自身の単行本のつぶやきみたいなスペースで、こんなことを書いていた:「朝起きたら、死ぬときのことを考える」。これと同じだと考えている。
毎朝起きたとき、自分が生きていることを確認する。死ぬときはこう死のうと考える。気が付いたら死の床にあって、「あのときああしていれば」と後悔するなんてまっぴら御免だ。だからぼくは、つねに今が「あのとき」でないか確認したい。今何をすべきかを確認していたい。だから人から言われたことをそのままやるのが苦手だ。なにごとも自分の目と手で確認してみたい。
まぁ、病気みたいなものだ。ある意味ぼくは壊れているし、客観的に見れば滅茶苦茶なことをやっている。もっとうまくいく滅茶苦茶ならいいんだけどね。
--
今日は早起きできたので、「よし! テストプログラムを検証しよう!」と思ったのだけど、うまくいかなかった…。ということで進捗なし。
# [メモ] 会話のクセ
昨日人と会って話していて、自分の会話のクセというか、「ああ、ここはああすればよかったなぁ」と思うことがあったのでメモ(というか言い訳というか)。
なんかこう、ぼくは、「○○について説明してください」と言われたとき、もっとインタラクティブに会話をすべきような気がする。たとえば昨日は、「どうしてSchemeとかHaskellをやってるの? きっかけは?」って聞かれた。それでぼくは、「自分の好きな言語を使える状況にあったので、面白そうな言語を選んだ。Eric Raymondがネットで『Lispはすごい』って言っていて…」みたいなことを説明した。
だけど後から考えてみれば、「あなたについてはどうなんですか? Eric Raymondのあの文章読みました?」って聞くべきだったんじゃないかという気がする。相手が何を知っているか、もちろん顔色を見ながら確認しているつもりで話しているけど、もしかしたらこちらの勢いにつられて頷いちゃってるだけかもしれないし。
とくに最近、SchemeとかHaskellについて話をするとき、やっぱり「触ったことがない」という人に会うことが多い。そうすると、触ったことがない人が、どれくらいの知識を持っているのか、たとえばEric Raymondのあの文章(How To Become A Hacker: Japanese)は読んだのか、Paul Grahamの文章(Beating the Averagesなど)はいくつか読んでいるか、逆にその人はどういう理由で今の言語を使っているのか、そういったあたりを丁寧に確認したほうが良かったなぁ、と思う。そうすると、説明ではなく会話になるのだけど、会話のほうが良いのかなぁ、と。
まぁ、あまり時間がないのでゆっくりやっていられないのだけどね。一応メモ。
なんかこう、ぼくは、「○○について説明してください」と言われたとき、もっとインタラクティブに会話をすべきような気がする。たとえば昨日は、「どうしてSchemeとかHaskellをやってるの? きっかけは?」って聞かれた。それでぼくは、「自分の好きな言語を使える状況にあったので、面白そうな言語を選んだ。Eric Raymondがネットで『Lispはすごい』って言っていて…」みたいなことを説明した。
だけど後から考えてみれば、「あなたについてはどうなんですか? Eric Raymondのあの文章読みました?」って聞くべきだったんじゃないかという気がする。相手が何を知っているか、もちろん顔色を見ながら確認しているつもりで話しているけど、もしかしたらこちらの勢いにつられて頷いちゃってるだけかもしれないし。
とくに最近、SchemeとかHaskellについて話をするとき、やっぱり「触ったことがない」という人に会うことが多い。そうすると、触ったことがない人が、どれくらいの知識を持っているのか、たとえばEric Raymondのあの文章(How To Become A Hacker: Japanese)は読んだのか、Paul Grahamの文章(Beating the Averagesなど)はいくつか読んでいるか、逆にその人はどういう理由で今の言語を使っているのか、そういったあたりを丁寧に確認したほうが良かったなぁ、と思う。そうすると、説明ではなく会話になるのだけど、会話のほうが良いのかなぁ、と。
まぁ、あまり時間がないのでゆっくりやっていられないのだけどね。一応メモ。
2010-03-04
# [技術] プログラミング言語にこだわるべきか
- Lispはなんとなくすごそうというイメージがあるけど、実際にはそれほどでもない
- where programming language matters @ val it: α → α = fun
- Island Life - 言語にこだわる場面
このへんの話。ぼくはヘッポコプログラマなので、上記の方々とは事情が違うが、いちヘッポコからすれば「プログラミング言語にこだわるべきか」という観点をどう感じるかというと:
どちらかというと、ぼくは向井さんの考えに共感する。言語よりも「なにを作るかが大事」という考えかた。howではなくwhat重視ね。むかし高林哲さんがC#かなにかでプログラムを組まれていることがあって、「すごいですね。いろんな言語でものづくりをされていて」と言ったことがあった。そのときも高林さんは「howではなくwhatじゃない?」とさらっと答えられていて感心した。なるほどこれも高林プロダクトが生まれる秘訣の1つだなぁ、と。
結局、「作りたいものがあるなら、その実現に一番近い(工数が少ない)言語を選ぶ」、というのが、たぶん優秀なプログラマにとっては一番合理的なんだろうなと思う。ただその「優秀な」とか「作りたいものがあるなら」ってところにパラメータがあって。多くのプログラマにとって言語の習熟はコストが大きく、一番近いはずの言語より自分の使える言語を使うほうが早い場合があるということだ(それでも出来上がるものは不完全だったり機能が足りなかったりするが)。また、そういうプログラマにとっては、「○○言語が使えないからそもそも作りたいものを諦める」というのが常のことだ。そんなに、なんでもかんでも言語を使える(切り替えられる)人というのは、たぶん全体の2~3割ぐらいなのではないか。つまり、世の中にはジュニアプログラマが多いってこと。
ただ、ジュニアプログラマもキャリアが10年とか15年とか経ってくると、一人前のプログラマにステップアップしなければならない(10年は長すぎて待てないと思われるかもしれないが、ぼくは普通の人がプログラミングできるようになるには10年かかると思っているので)。一人前になるとき、プロのプログラマとしてある1つの言語にこだわるべきかというと、たぶん*こだわらない*ほうが良いだろうと思っている。
なぜかというと、今回転職しようと試みた際にも痛感しているが、やはり1つの言語にばかりこだわっていると、時間を無駄にするからだ。たとえばぼくはSchemeやHaskellが好きでSchemeについては7年ぐらいやってるけど、その時間のなかで、RubyやJavaやC++でもちょっとぐらいプログラムを書いておけばよかったと後悔している。まぁ「ちょっとぐらい」と言ってもちょっとやっただけでは本当に身には付かないから、それなりに身を入れてやらなければいけないのだけど。でもこう、もしぼくもRubyのコミュニティに参加していれば、オブジェクト指向の話題とか、フレームワークとか、O/Rマッパとか、「共通の話題」(コモディティ)についてキャッチアップし、十分なスキルを身に付けることができていただろう。そして、それらの知識やスキルは、ぼくの好きなSchemeやHaskellにも導入できる。導入を試みることで開ける世界があったはずだ。
まぁ要するに、「ビジネスマンなら新聞を読め」みたいな話なんだけど。プログラマで一生やっていこうと考えているなら、自分の好む言語以外もチェックし、内容を理解できるようになったほうがいいよと。当然、上述の議論をされている方々は、複数の言語は「新聞を読む」的なレベルの上を行っていて、そのうえで議論をされているわけだけど。いちヘッポコプログラマとしては、同じヘッポコの人や、これから上を目指す人たちに言えることがあるかなぁ、と。
--
基本的にはそう思う。一方で、やっぱりぼくは、SchemeやHaskellが好きだ。なぜ好きかというと、ちょっと自分の生き方に合っている気がするからだ。ぼくはヘッポコだから普通の人と同じことをしていては普通以下の生産性しか出せない。だから普通の言語では足りない。そういったときに、SchemeやHaskellは「ふつうのやつらの上を行け」的な生産性の高さがある。そう。「ふつうのやつらの上を行け」という言葉にぼくはやられてしまっているんだ(これについては別稿を立てるべきだが、Paul GrahamやLisp界の人々を尊敬し共感しているという理由から、関数型言語を使いたいという面も大きい)。
ちょっとはみだし者で、普通の人との(悪く言うなら泥のような)チームワークが苦手な自分にとっては、SchemeやHaskellは魅力的に映る。それはやはり、少人数かつ短かいコード・少ないテストケースで高い機能を持つプログラムが組みやすいからだ。抽象ツリーの操作を行う分野ならLispを適用すると生産性が高いし、プロトコルが明確化されている分野ならHaskellで組むと生産性が高い。そういった性能上の優位点がはっきりとある一方で、LispやHaskellを使う人はそう多くない。だったらヘッポコの自分にもチャンスがあるかもしれないし、はみだし者の性でそこに惹かれてしまう。まぁそういう感じ。
ただし、今後はぼくも1つのプログラミング言語にこだわらないで、「なんでもできます、やります」と言えるのを理想としたいと思っている。そうせざるを得ないというか。
--
早起きしてテストプログラムを検証しようと思ってたのに、文章を書くだけで時間を費してしまった。orz