こんにちわ。Pythonアドベントカレンダー に参加して、 この記事を書くまでblogをやったことのない ransui です。Pythonはお仕事でバリバリ使ってますが、広告配信システムやら、ログ分析やらで、最近のWebフレームワークってのはあまり使ってないんです。というか、未だにZope2とかTurboGears 1.xが現役。
で、当初の目論見としては、Pythonの標準ライブラリだけでTiny Web Frameworkみたいな感じでいこうかな。なんて思ってましたが、思い切り清水川君にやられちゃったので、おじさんがもう10年以上使っている、Webアプリ開発時に使えるちょっとしたツールの話をしようかと思います。
ちょっとしたプログラムを書いて、その挙動がおかしいとか、なんかエラーが出るとか、テストを通過しないというときはデバッグ作業をするわけですが、そのときに「ここぞ」という場所でprint()で変数の内容を見てみるなんてことを良くやります。本格的にデバッガを使ったりするまでもない時にはお手軽に使える手法で「printデバッグ」なんて言う事もあります。というか、みんな良くやるよね?
たいていのWebフレームワークには【デバッグモード】とかがあって、プログラムの実行中になにかエラーとかが起こると、すごく美しいスタックトレース画面がブラウザに表示されたりして、嬉しいんですけど、そのエラーが起こった細かい経緯とか原因まで推測するのはなかなか難しいものです。
でprintデバックしてやろうとか思うのですが、Webフレームワークによってsys.stdoutの行き先がまちまちだったりして、いつでも出来るとはかぎらないし、だからといってログに出してtail -fってのもタイムラグあったり、loggingの設定がやたら複雑だったりするとゲンナリなわけです。
必要は発明の母。ここで一発、超簡単・単純なprintデバッグ用の道具を作ります。まずはソースコードを見てくださいな
- # -*- coding: utf-8 -*-
- import sys
- import socket
- import optparse
- class UDPMonitor(object):
- def __init__(self, host="localhost", port="8181", buffer_size=4096):
- self.host = host
- self.port = port
- self.buffer_size = buffer_size
- def monitor(self):
- print("This is UDPMonitor, waiting message on %s:%s" % (
- self.host, self.port))
- udp_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
- udp_sock.bind(("", self.port))
- while True:
- (data, (address, port)) = udp_sock.recvfrom(self.buffer_size)
- print(repr(data)[1:-1])
- def send_message(self, msg, target_host=None, target_port=None):
- udp_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
- udp_socket.bind(("", 0))
- udp_socket.sendto(msg, (
- target_host if target_host else self.target_host,
- target_port if target_port else self.target_port))
- def main():
- parser = optparse.OptionParser()
- parser.add_option("-a", "--address",
- action="store", dest="address", type="string",
- default="localhost", help="host name or address")
- parser.add_option("-p", "--port",
- action="store", dest="port", type="int",
- default=8181, help="port number")
- parser.add_option("-s", "--server", dest="server_mode",
- action="store_true", help="run as monitor")
- (options, args) = parser.parse_args()
- if options.server_mode:
- UDPMonitor(host=options.address, port=options.port).monitor()
- else:
- UDPMonitor().send_message(" ".join(args), options.address, options.port)
- if __name__ == "__main__":
- main()
はい。大体なにをやっているかはわかると思います。
ようするにprintでstdoutに出力する代わりにネット越しにメッセージ流すということです。このプログラムの味噌はUDPを使っていることで、デバッグするコード側では、いちいちコネクションを張らずにメッセージをお手軽に投げつけることができます。あ、簡単のためにバッファ長は固定にしちゃってますので、投げつけるメッセージのサイズには注意が必要です。
上のプログラムは基本部分だけで、ホントに指定された文字列を投げつけるだけしかできませんが、色々と応用もできます。たとえば
- 時刻情報を自動的に付加するようにしてみる
- カレントスレッドの情報を自動的に付加するようにしてみる
- メッセージ送信部分をデコレータ関数に仕込んで
- 呼び出されたメソッド名を送信する
- メソッドが呼び出されたときの引数の内容を送信する
- メソッドの戻り値の内容を送信する
- ORM使っているときに、最終的に実行されるSQL文を確認する
- ある場所から、他の場所までの処理時間をリアルタイムに観測する
などなど。
TCP前提のアプリケーションレベルプロトコル全盛の現在でもUDPにはコネクションレスという強力な武器があり、使い捨て的な道具を作るときには結構役にたつものです。
所詮デバッグ時に一時的に使う道具なので、あまり豪華にする必要もないですし、使い回しとかはあまり考えずに、上のような基本部分を手持ちのカードとしておいて、状況にあわせてちょっと拡張して使うってのが、お手軽で良いのではと思います。
スイスアーミーナイフの性能を余すところ無く使いこなすものスマートでカッコいいですが、そのへんの木片と金属片でささっと必要な機能をもったナイフを作って仕事を片付けるってのもイイとおもうんですが、どうでしょう?
さて、次の @zenich さんが見事にWebフレームワーク話に軌道修正してくれることを期待しつつ、バトンを渡すことにします。
loggingのDatagramHandlerで、と思いましたが、応用のカスタマイズはいいですね!
返信削除