メッセージ。 - diary
2010-03-12
# [日記] 夜の進捗（なし）
なんか、帰ってくると非常に眠くて、あまり仕事ができない。本当のことをいえば、実は今年確定申告をしたほうがよいとかしないでもよいとかそういう話もあるのだが、疲れてできてない…。まぁ確定申告は来週の月曜が締め切りだから、それまでに頑張ろう…。あと、帰宅後に作業日報を書いて送っているのだが、それを帰宅後に書くのにも時間と労力がかかってて、その作業時間はどこに付けるの？みたいな話があって、いろいろややこしい。on top of that、今週末はTOEICを受けようと思ってて、その勉強もしなければいけないのだ。
2010-03-10
# [日記] 夜の進捗
「夜の進捗」といっても、まぁ進捗なしなんだけれども。今日は会社帰り、いまの仕事でお世話になっている派遣会社の営業さんと、打ち合わせをした。「現場はどんな感じ？」みたいなフォローをしに来てくれたんだと思うが、一通り報告が終わると、今の不況とか日本の企業に元気がないこととかで話が盛り上がった（ぼくのほうが喋りすぎた感じだったので、その点反省）。
人材会社の人にもいろいろあって、こういう小さい会社さんの人は、案外人間味があったり、こっちのことをきちんと考えていてくれたりして有り難い。苦労している人は、他人の苦労も理解してくれるというか。ぼくにとっても派遣のマージンは負担なのだが、こういう人のところに自分が稼いだお金が行っているのだと思えば、まぁそれも悪くはない。悪くはないというと言いすぎだけど。
ただ、なんだろなぁ。幻想かもしれないけど、こうやって話ができる人がいるというのは有り難い。まだ2～3度しか会ったことがない間柄だけど、自分が思っていることを聞いてもらいたくなったり、相手の話を聞いてみたくなるような人と出会えるというのは素敵なことだ。
人材会社の人にもいろいろあって、こういう小さい会社さんの人は、案外人間味があったり、こっちのことをきちんと考えていてくれたりして有り難い。苦労している人は、他人の苦労も理解してくれるというか。ぼくにとっても派遣のマージンは負担なのだが、こういう人のところに自分が稼いだお金が行っているのだと思えば、まぁそれも悪くはない。悪くはないというと言いすぎだけど。
ただ、なんだろなぁ。幻想かもしれないけど、こうやって話ができる人がいるというのは有り難い。まだ2～3度しか会ったことがない間柄だけど、自分が思っていることを聞いてもらいたくなったり、相手の話を聞いてみたくなるような人と出会えるというのは素敵なことだ。
# [日記] 朝の進捗
今朝はちょっと早起きできたのだけど、仕事関連のメールを書いていたら半分ぐらいロスした。案外メール書くのって、30分とかかかってしまうんだなぁ。で、その後プロキシサーバー部分のデバッグをした。コードを切り出して単機能が動くサーバー/クライアントを作って単体テスト。タイポレベルのバグは退治できたのだけど、結合させてテストするとまだうまく動かない。30分とかではなかなか進まないな…。以下は、read-block!を使ったネットワークパケットの送受信テスト用に書いたコード（これはうまく動いている）。
#!/usr/bin/env gosh (use rfc.822) (use rfc.http) (use gauche.net) (use gauche.uvector) (define (main args) (if (eq? (sys-fork) 0) (run-client) (run-server)) 0) (define (run-client) (sys-sleep 3) (let1 cnt 16 #?=(expt 2 cnt) (http-post "localhost:8080" "/" (make-string (expt 2 cnt) #\x)))) (debug-print-width 1024) (define (run-server) (define (read-block len iport) (let1 vec (make-u8vector len 0) (let loop ((start 0) (remain len)) (if (> len 0) (let1 len #?=(read-block! vec iport start) (if (eof-object? len) vec (loop (+ start len) (- remain len)))) vec)))) (let1 ssock (make-server-socket 'inet 8080) (let* ((csock (socket-accept ssock)) (cin (socket-input-port csock)) (cout (socket-output-port csock))) (let* ((stat-line (read-line cin)) (hdrs (rfc822-header->list cin))) #?=stat-line #?=hdrs (let1 clen (rfc822-header-ref hdrs "content-length") (read-block (x->number clen) cin)) (display "HTTP/1.0 200 OK\r\ncontent-type: text/plain\r\n\r\nOK" cout) ))))
Gaucheでread-block!を使ったネットワークパケットの送受信テスト用コード
2010-03-09
# [つぶやき] 「もし自分が○○だったら」
「どうして若者は結婚しないのか？」って歳いった人は言うけど。「もし自分がいま若者だったら、自分は結婚するだろうか？」って考えてみればいいんじゃないかなー。そうすれば、「やっぱり結婚しないかも」と思うかもしれない。「それでも結婚するかも」と思うかもしれない。さらに一歩踏み出して、「じゃあ自分たちがあれだけジャンジャカ結婚していたのは何故だったのか？」とも、考えられるんじゃないだろうか。
こういう風に、「もし自分が○○（同じ立場）だったら、自分はどうしただろうか？ 自分には同じことができただろうか？」と考えるのは、けっこう面白いと思っている。いろんなことが分かるから。見えていなかったものが見える。パッと道が開けるときもあるし、心が揺さぶられることもある。自分がいったい何を考えているかが分かったりする。だから、ぼくはこれは一つの良い方法だと思っている（少なくとも自分には合っているかな、と）。
でも一方で、こういう風に考えない人も多いみたい。というか、誰だって少なからず同様の思考はすると思うんだけど、あまり積極的にはこのメソッドを使っていないというか。ほとんどオフにしてしまっている人がたくさんいそう。冒頭の質問にしても、あまり意図が分からない。「どうして若者は結婚しないのか？」、質問した人は本当に知りたいのだろうか。それとも雑談したいだけなのか。「どうしてあなたは、そういう質問をするんですか？」と尋き返してみれば良いのかね。
こういう風に、「もし自分が○○（同じ立場）だったら、自分はどうしただろうか？ 自分には同じことができただろうか？」と考えるのは、けっこう面白いと思っている。いろんなことが分かるから。見えていなかったものが見える。パッと道が開けるときもあるし、心が揺さぶられることもある。自分がいったい何を考えているかが分かったりする。だから、ぼくはこれは一つの良い方法だと思っている（少なくとも自分には合っているかな、と）。
でも一方で、こういう風に考えない人も多いみたい。というか、誰だって少なからず同様の思考はすると思うんだけど、あまり積極的にはこのメソッドを使っていないというか。ほとんどオフにしてしまっている人がたくさんいそう。冒頭の質問にしても、あまり意図が分からない。「どうして若者は結婚しないのか？」、質問した人は本当に知りたいのだろうか。それとも雑談したいだけなのか。「どうしてあなたは、そういう質問をするんですか？」と尋き返してみれば良いのかね。
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でいいのかという問題もあるな…）ということで、もうちょっと頑張ろう。