Pythonの軽量ウェブフレームワークBottleのデーモン化
Pythonの軽量ウェブフレームワークBottleは非常に便利である。10行にも満たないコードでウェブサーバーが構築できるけれども、せっかく立ち上げたプロセスはデーモン化してないとログアウトしたらkillされる。 今回はこれをデーモン化したい。今回はBottleのデーモン化に特化したBottleDaemonでやってみよう。
BottleDaemonは文字通りBottleのデーモン化に特化したパッケージ。構成ファイルも一つだけというモノシリックな構造だ。
BottleDaemon 0.1.1 : Python Package Index
必要パッケージの導入
次の二つを導入する。
$ pip install python-daemon $ pip install Bottledaemon
ソースコードの書き換え
BottleDaemonの公式ソースコードに少し手を加えたものが以下。通常のBottleアプリケーションと違って、先頭行にbottledaemonのimportを宣言しておく必要がある。
daemon_run()でデーモンとして立ち上げる。公式では何も引数がないが、この例のようにホストやポート番号の指定ができる。
from bottledaemon import daemon_run from bottle import route @route("/hello") def hello(): return "Hello World" if __name__ == "__main__": daemon_run(host='localhost', port=8080)
起動と停止
以下の様に簡単にできる。
$ python exapmle.py start $ python example.py stop
デーモン化にはそのためのコードを自前で用意したり、簡単にできる場合でも設定ファイルを編集したりと色々準備が必要だが、Bottleに関しては設定ファイルすらも不要でデーモン化ができる。
参考文献
Bottle: Python Web Framework — Bottle 0.13-dev documentation
意図せざるリダイレクトの原因
Apache 2.4でとつぼにはまったのでメモしておく。
状況としてはウェブアプリケーションのパス（例：/request/list）がどうしても別のパスにリダイレクトされて、困り果てたというもの。原因としては「301リダイレクトのキャッシュ」だったが、意図せざるリダイレクトの原因としては、以下が考えられる。
- mod_rewirte
- .htaccess
- DirectorySlash
- 301リダイレクトのキャッシュ
mod_rewirteと.htaccess
設定ファイルなどにリダイレクトの設定が残ってないか。
DirectorySlashの設定
「/list」などをディレクトリへのアクセスとApacheが認識して、末尾にスラッシュを補完することがある。
301リダイレクトのキャッシュ
クライアント側に原因があることもある。ステータスコード301のリダイレクトは「恒久的な移動」なので、ブラウザにキャッシュとして残る。以後ブラウザは、同一URLへのアクセスはサ勝手にリダイレクトする*1。302のリダイレクトであればキャッシュはない。ブラウザのキャッシュを削除すれば良い。
参考文献
ファイルのみ／ディレクトリのみパーミッションを変更
「ガルパンはいいぞ！」な物語論
劇場版ガールズ＆パンツァーのBlu-rayが発売されました。自分は立川の爆音上映を何度か観ましたが、あの重低音は素晴らしいものですね。さて、例によって、このガールズ＆パンツァー劇場版を物語論の観点から解釈しましょう。
続きを読む「常用漢字表、表外漢字はいわゆる康熙字典体」を実現するInDesign向けの字形変換スクリプトを公開しました
「常用漢字表、表外漢字はいわゆる康熙字典体」を実現するInDesign向けの字形変換スクリプトGlyphconv 2を公開しました*1。
目的
字体整理の標準とされる方針「常用漢字表、表外漢字はいわゆる康熙字典体」ですが、DTPでは拡張新字体というものが問題になります。
これを排除する必要がありますが、この作業を手動で行った日には、時間も掛かる上に作業漏れも多数出てくるでしょう。
このスクリプトは上記の作業を自動化したもので、作業時間の大幅な短縮と整理品質の安定を実現させます。
前バージョンからの変更点
以前にVectorで公開したものと比べて、以下の点を変更しました。
使用上の注意点
ダウンロード
下記のリンク先よりダウンロードできます。
https://github.com/igawa-seizo/glyphconv2/releases/download/2.0/glyphconv2.zip
日比谷カレッジ「情報化時代に考えたい漢字の話」聴講記録
日比谷図書文化館にて催された「情報化時代に考えたい漢字の話」を聴講したので、文字起こしをします。 内容としては大きく三つに分かれており、 - 常用漢字表とは - 平成22年の改訂はどのようにして決まったのか - 常用漢字表の字体・字形に関する指針 でありました。特に「常用漢字表の字体・字形に関する指針（報告）について｜文化庁」については2月29日に文化庁が公開したばかりの指針であり、非常にタイムリーなお話です。
講師は文化庁国語課の武田康宏さんです。常用漢字表や今回の指針の策定にも携っている方で、日本の国語政策に関る官僚のお話を聞けた貴重な機会でした。
この文字起こしは当日のレジュメと講師の発言を概ね時系列順に提示しつつ、私の補足や意見を追記する形で行きます。
講師の発言やレジュメの要約は、文章の前にバレットをつけてリスト形式にしています。
続きを読むVLAN備忘録：タグ付きフレーム／アクセスポート・VLAN非対応スイッチ
VLAN備忘録
VLAN関係で文献であまり取り上げられて居ない事例について調べないといけない機会があったので、記録しておく。
タグ付きフレームはVLAN非対応スイッチを通過できるか？
トランクポートから送出されたフレームは、VLAN IDが格納されたタグ付きフレームとなって、伝送路を流れる。さて、途中でタグ付きフレームがVLAN非対応スイッチを通る場合、どう処理されるのだろうか？
結論としては、大抵の場合は問題なく転送される。イーサネットフレーム長は規格では1518バイトであるが、VLANタグ付きフレームでは4バイトのヘッダが挿入されて1522バイトとなる。今日は大体がジャンボフレーム対応の機器であるから、問題なく通信できるだろう。ジャンボフレーム非対応の機器であると破棄される。
VLAN非対応の機器はフレーム内部に挿入されたVLAN情報を一切見ずに、宛先のMACアドレスに基づいて通常通りに処理をするだけだ。
アクセスポート（アンタグポート）がタグ付きフレームを受信したときどうなるか？
VLAN対応スイッチでは、アクセスポートとトランクポートとを設定できる。アクセスポートは端末をつなぐためのもので、トランクポートはスイッチ間をつなぐためのものだ。トランクポートから送信されるフレームはVLANタグが挿入される。それでは、アクセスポートがタグ付きフレームを受信したとき、そのフレームはどの様に処理されるのか？
調べた限り、タグ付きフレームのVLAN IDとポートのVLAN IDとが一致している場合に限って受信する様だ。
If an access port receives a packet with an 802.1Q tag in the header other than the access VLAN value, that port drops the packet without learning its MAC source address.
以下のアライドテレシス機器の説明書でも、似た様な説明があった。
AT-DC2552XS コマンドリファレンス 2.5.3.1: L2スイッチング / バーチャルLAN
また、以下のフォーラムでは、QoSフィールドも絡んだ状況下でアクセスポートがタグ付きフレームを受け入れることもあるという発言がある。
https://supportforums.cisco.com/discussion/11899466/vlandoes-access-port-drop-frame-when-it-received-frame-tag
