前回の続きです。
BitTorrentのソースツリーをみると、BitTorrent/HTTPHandler.pyと言うファイルがあります。どうやら、BitTorrentには、HTTPをハンドリングする仕組みが既にあります。2箇所ぐらいでHTTPHandlerが使われていますが、わかりやすいのがTrack.pyにあるトラッカーの部分のコードです（トラッカー自体の説明ややりとりはそのうち発売されるユニマガに書いてあるはず）。トラッカーの初期化の部分のコードはBitTorrent/track.pyの500行目前後の↓。

def track(args):

    (略)

    r = RawServer(Event(), config)

    t = Tracker(config, r)

    s = r.create_serversocket(config['port'], config['bind'], True)

    r.start_listening(s, HTTPHandler(t.get, config['min_time_between_log_flushes']))

    r.listen_forever()

    t.save_dfile()

    print '# Shutting down: ' + isotime()

コードをみて分かるのがローカルの変数名が短いです。スコープに応じて変数名の長さが変わっています。変数の定義から使用箇所までの距離が短いと、変数名が一文字です。長くなってくると、一文字じゃなくって、単語になります。僕も同じような感じで、定義して使うまでが短ければ変数名は短くしています。
さてさて、コードの説明ははしょるとして、RawServerの最初の引数のEventはthreading.Eventです。configは辞書でRawServerのコードをみると、close_with_rst、timeout_check_interval、socket_timeout、bindが定義されていればよいらしいです。timeout関係は、タイムアウトまでの秒数です。timeout_check_intervalは5秒、socket_timeoutは15秒をtrackerはデフォルト値として使用しています。bindはバインドしたいアドレスを指定します。から文字を指定すると0.0.0.0でlistenしてくれます。close_with_rstはよくわかりません(説明が面倒なので省略)が、trackerはデフォルトで0になっています。オブジェクトができあがれば、create_serversocketでlistenするアドレスとポート番号を指定して、ソケットのオブジェクトを作り、start_listeningでコールバック関数などを指定し、listen_foreverでio処理します。

start_listeningは、ソケットとハンドラーを登録します。RawServerはパケットのやりとりをするだけなので、HTTPHandlerがHTTPのプロトコルとして善きに計らってくれます。アプリケーションとしては、HTTPHandlerの最初の引数の関数(HTTPのGETメソッド）を定義すれば、HTTPサーバができあがります。getはconnection, path, headersを引数にとります。pathの情報を元に適当な文字列をやステータスこーどなどをタプルで返せば善いらしいです。

def get(connection, path, header):

    return (200, 'OK', {'Content-Type': 'text/plain; charset=iso-8859-1'}, "body is here")

最初がステータスコードとその文字列、その次がヘッダーの辞書、最後にコンテンツですね。まあ、HTTPHandlerがGETしかハンドルしなくってPOSTなどはハンドルできないのは、BitTorrentには必要ないからですね。でも、これだけで、単に静的なファイルや簡単なGETを使ったCGIは書けそうです。
気が向いたらサンプルコードを書くかもしれません。このまま、終わるかもしれません。

僕が転職するという話じゃないです。と言うか、今転職しても初めてじゃないですね。はじめての転職は大変なんですね。履歴書に書くべきでない資格とはは、僕は運転免許しかもっていないので、これしかかけないです。TOIECは6年以上前に受けただけで点数も覚えていないし、僕は不器用なので、そろばんは3日ぐらいならってすぐにあきらめたし。勉強中の資格は、落ちたら恥ずかしいので資格をとろうとしないし。がーん、やっぱりかけるものがないです。

と言うことで、初めての転職は大変らしいです。僕の初めての転職は、履歴書はテキストエディタで書いてメールに貼っ付けて送ったような気がします。会社をやめるときにも、上司にメールで「辞めます」とだけ書いて送ったような気がします。そしたら、上司に会議室に呼び出されて、いろいろ言われたような気がします。うーん、はじめての転職の時は上司もほぼ同時期に辞めたんですけど、なぜか、引き留められた。なぜだろう？うーん、社会人としてちょっと違いますね。
2回目の転職（今の会社へ)の時は、社長と考え方の違いでいろいろあった時なので、まあ、スムーズでした。でも、しばらくは社長は落ち込んでいたらしいです。でも、社長はイスラエル人で、その社長のせいでPHP（イスラエル人が作ったので）が嫌いになりました。まあ、単なる偏見ですが。イスラエル人にもいい人はいます。。。でも、やっぱりイスラエル人は頭がいいです。やつらはすごいです。頭の構造が違います。やつらに勝つためには、中学ぐらいで大学の数学を教えないといけないです。日本人の優秀な人がナイフだとしたら、やつらはよく切れる日本刀です。でもやつらはプライドも高いです。

締切日が分からないまま、雑誌の原稿のドラフトを「とりあえず、ドラフト3」で出したら、それが最終的なものになってしまったようです。
それはいいのですが、メールの返信で「 :)」と言う記述があって、Thunderbirdでメールを見るとこんなの()になっています。HTMLメールで出してくる人なのか！思ったより若いんだ！と思って、メールのソースを見ると、普通のテキストです。ひょっとして、「 :)」をThunderbirdは勝手にSmily markに置き換えてくれているの？編集部の人にあらぬ誤解をかけたようです。
そう言えば、メーリングリストとかでも同じような顔マークがあったのは、ひょっとしてThunderbirdが親切にそうしてくれていたんでしょうか？
まあ、とりあえず、誤解はとけたのでよしとしましょう。

と言うことで、「まるちすけじゅーら」と「ぷろじぇくと あー」のP2Pの一部の社員しか知らない、あんなことやこんなことを書かないと・・・。でもって、できれば書いちゃいけないことを書いてみたい。

すぐ忘れるのでメモ。

WebサーバとのやりとりはPython君はurllib（または、urllib2）を使いますが、状態を維持しない場合の使いかたは、ライブラリリファレンスを見れば大体分かります。セッションなどの状態を維持するものは、cookieでセッションの情報が保持されます。urllibでセッションの状態を適当に扱ってくれれれば楽なのですが、自分でハンドリングしないといけません。
HTTPでは、サーバから

Set-Cookie: key1=val1; key2=val2

のようにHTTPヘッダーがセットされるので、

import urllib

opener = urllib.URLopener()

param = urllib.urlencode({"id":"myid", "passwd":"mypasswd"})

f = opener.open("http://myserver/login", param)

print f.read()

cookie = f.headers.getheader("Set-Cookie")

のようにクッキーをとってきて、

opener.addheader("Cookie", cookie[:cookie.find(":")])

f2 = opener.open("http://myserver/index")

とopnerにクッキーのヘッダーをセットすればOK。

けれども、某所にこれでアクセスしようとしたらSet-Cookieが二つあります。うーん、困った。と言うことで、

cookie = [itm[:item.find(":")) for itm in f.headers.getheaders("Set-Cookie")]

opener.addheader("Cookie", ";".join(cookie))

f2 = opener.open("http://mixi.jp/home.pl")

でOK。

ちなみに、クッキーは

Set-Cookie: key1=val1; path=/

のようにHTTPヘッダーにセットされるので、クライアントはこれを受け取ると次のリクエストで

Cookie: key1=val1

とHTTPヘッダーをセットしてリクエストを出さないといけません。クッキーが複数ある場合は、

Cookie: key1=val1; key2=val2; key3=val3....

となりますとさ。

mixiをPythonでごりごりするものです。ダウンロードして使ってみたい人は、これ。

まだ、友だちの日記しかとれません。mixi内の日記は本文もとってきてくれます。外部のblogなどは、リンクだけ表示されます。多分。会社のIさんがmixiに最近入ったのですが、ログインするのがめんどくさいとかいろいろおっしゃられるので、Iさんへのプレゼントです。自分自身のモチベーションは、現状はテキストに出力するツールしか作っていませんが、RSSに出力してRSS Readerでみることです。まだ、やっていません。
どうも、HTMLから情報を取り出す作業というのが建設的でないようで嫌いですが。。。
mixiの日記で写真がはって日記はうまくハンドリングできていません。本文のタグは全て消し去っています。というか、正確には消え去ってしまった。
そのうち、もう少しいろいろしたいですが、どうなることやら。

まだ、ドキュメントは全然書いていないし、今後も書かないかもしれません。

愛が足りなくて、バージョン0.0.1はIさんに受け止めてもらえませんでした。なので、バージョン0.0.2ではさらなる愛を込めて見ました。
今回、愛の表現として、mixiのidを指定するとそのひとの最大7個ぐらいの日記をとってきてくれます。こんな感じ

python mixidiary2txt.py -u ログインID -p パスワード -t  506290

-tの後の数字はmixiの内部的なIDです。URLを参考に見付けてください。ついでにいろいろオプションを追加してみたりもします。-t 1 -t 2という感じで複数書くと、複数の人のものを一度にとってきてくれるはず。でも、-tを指定した時は名前はまだとっていないので、dummyという人になってしまいます。

そんな感じです。これで、愛は伝わるのでしょうか？
ブツはこれ。0.1になればドキュメントもちゃんと書かれているはず。
それから、多分、japanesecodecsかcjkcodecsのどちらかが入ったPython2.xなら動くはず。でも2.3でしか動かしていないけど。

最近、「ウィルスソフト」と言う言葉をノンテクニカルな同僚から時々聞きます。この言葉は同僚だけでなく、顧客の中にも使う人がいるようです。僕はウィルスソフトというのはウィルスのことだろうと思っていましたが、実は違いました。ウィルスソフトとは「アンチウィルスソフト」のことでした。この言葉を聞くとアンチウィルスのソフトを作っている会社の人はどう思うのでしょう？まあ、日本人にはアンチウィルスというのは少し発音しづらいかもしれませんが、せめて、「ワクチンソフト」とか読んだ方がいいかもしれません。
「ウィルス」も「ビールス」と言う人もいます。こういう人はドイツが好きなんでしょうか？お年寄(K村さん)とかは、常にビールスと読んでいました。僕は、英語のように「バイラス」と呼ぶ方が好きです。

それから、その同僚は「Web サービス」という言葉をよく使っていました。根っからの技術屋にとってみれば、その言葉はSOAPやら、なんとかディレクトリやら、そう言うものを連想します。でも、その言葉は、MIXIなどのWeb上で提供しているサービスのことらしいです。この言葉もビジネス界隈では、そういう定義になりつつあるんでしょうか？

そういえば、昔、客先のネットワーク環境を聞いたら、「VLANを使っている」と言われました。VLANと言えば、LANを仮想的にわけているやつだと信じていたら、VLANというネットワーク関係の製品名でした。なんの製品だったかは忘れてしまいましたが。思い込みは禁物です。

ついでに、昔、どこかの会社とミーティングした時に「もばいる あいぴー」という言葉を聞きました。この人もノンテクな人です。難しい言葉を知っているものです。でも、その人のもばいる　アイピーとは、単にノートPCで無線LANから割り振られるIPで使うネットワーク環境のことでした。

ということで、いろんな言葉が氾濫していて、結局は文脈でしか分からないんですね。

mixiのコンテンツはeuc-jpなので、PythonのHTMLParserがeuc-jpだとちゃんとハンドリングしてくれないみたいなので、ユニコードに変換しています。ちなみに、たとえハンドリングしてくれたとしてもunicodeで扱うと思いますが・・・。
さて、そのeuc-jpからunicodeへの変換ですが、時々

UnicodeError: EUC-JP decoding error: invalid character 0xadb6 in JIS X 0208

と例外がでて、unicodeにできません。0xadb6はmixiのページをhexでみると「Ⅱ」でした。一応、13区 NEC拡張外字らしいです。うーん、なるほど・・・。Firefox君はちゃんと表示してくれる偉い人でした。Pythonが悪いというわけじゃなさそうですが、でも。。。
つまり、13区の文字は?とかに置き換えてから変換すればよいということ?うーん、なるほど。。。

会社のFさんがデータベースのテーブルのフィールドでビットフィールドを使おうとしていました(booleanのフィールドを沢山作ろうとしていたので、bitフィールドにしてもらいました）。フィールド長を彼は、30とか、50にしようとしていました。他の開発者は32とか、64がきりがよいという意見ですが、彼だけは30とか50のほうがきりがよいという意見です。まあ、普通のユーザが見える所であればそうかもしれませんが、データベースのフィールド長はそれとは関係ないです。
僕達は、byteに害された結果なんでしょうか？まあ、普通のプログラマなら32や64がきりがいいと言うに違いない。多分、30に制限しても内部的には32bit分確保されているんだろうと思ってしまうせいかもしれません。

それはいいのですが、殴り書きのPerlのコードが氾濫するのは許せない。ロジックとプレゼンテーションが混然一体になって書かれていると、今後メンテナンスする気があるのか気になります。