2013年12月31日

ツイッターのお気に入りリンク共有fav2markを公開

Twitterのお気に入り(ふぁぼったツイートのリスト)からリンクを抽出して、はてなブックマークで共有するOAuthアプリを作ってみた。

https://fav2mark.usb0.net/

conohaが開催しているこのこんというのに応募しようと思って約3日で作ったもの。基本機能はテストしているものの、実アカウントが少ないので絶賛人柱募集中。

とにかくPythonでアプリ、プロセス管理、サーバー管理まで揃えている。 応募用にSlideShareでまとめ(?)たもの↓

 

時間がかかったのはだいたいOAuthとMongoEngineのせい。 MongoEngineのシリアライズが変なのでモンキーパッチして性能を稼いでいたりと、内部的には余り美しくないけれど、そこそこのアカウントをopenvzなVPSでも裁けるようにgevent、celery、redis で頑張ってみた。

共有先サンプルは http://b.hatena.ne.jp/causeless/bookmark (リツイートしたリンクの共有とツイートのコメント化有効)

2013-03-01追記

  • 内部的に色々と変更、全ての短縮URLを展開するように
ラベル:VPS
posted by ko-zu at 21:22| Comment(0) | TrackBack(0) | Python | このブログの読者になる | 更新情報をチェックする

2013年12月05日

uWSGIで複数バージョンのPythonを動かす

今のところuWSGIはvirtualenvで作ったアプリ別のモジュールをロードすることは出来るものの、システムのlibpython.soを直接使っているため、そのままではビルド時のPythonしか動かない。

異なるバージョンのpythonを含むvirutalenvに入ろうとすると、PYTHONPATHが違うためimport siteの時点でモジュールのロードに失敗する。

Python version: 2.6.6 (r266:84292, Nov 22 2013, 12:16:22)  [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
...
Set PythonHome to /path/to/py27env
'import site' failed; use -v for traceback

他のバージョンのpythonを使うには、対応するpythonとpythonプラグイン対応のuWSGIをビルドし直す必要がある。

ビルド手順

デフォルトのままpipなどでインストールすると、python他プラグイン全部入りのuwsgiバイナリが出来ているはず。 (pipで入れていれば/tmp/pip-build-root/uwsgiに必要なファイルが展開されているので、これを元にビルド)

uwsgiソースのbuildconfディレクトリには、uwsgi本体ビルド用の設定ファイルが含まれている。 pythonを含まないバイナリを作るには、buildconf/nolang.iniを使ってビルドするか、main_plugin=からpythonとgeventを抜いておく必要がある。(geventもpythonに依存しているためビルド出来ない)

python uwsgiconfig.py --build nolang

次にプラグインをビルドするのだが、uwsgiconfig.pyはリンクするlibpython.soをビルド時のPython環境から探しているらしく、ほしいバージョンのsharedなpythonとlibpythonがセットで必要。 さらに面倒なことにpythonビルドツールのpythonzはデフォルトではsharedなビルドを作ってくれない。(OSXは別?)

一応configureオプションを渡すことでビルドは可能で、

pythonz install 2.7.6 --verbose --configure='--enable-shared LDFLAGS="-Wl,-rpath -Wl,\\$$ORIGIN/../lib"'

あるいは手動でインストール

./configure --prefix=/usr/local/python27 --enable-shared LDFLAGS="-Wl,-rpath /usr/local/python27/lib"
make
sudo make altinstall

必要なバージョンのsharedなpythonバイナリでプラグインをビルド。pluginsディレクトリにプラグインのテンプレートが入っている。

python2.7 uwsgiconfig.py --plugin plugins/python nolang python27
python2.7 uwsgiconfig.py --plugin plugins/gevent nolang gevent27

これでuwsgiバイナリと*_plugin.soが出来るのでバイナリを置き換え。

sudo cp uwsgi /usr/bin/uwsgi
sudo mkdir -p /usr/lib/uwsgi
sudo cp *.so /usr/lib/uwsgi

アプリの設定ファイルから

[uwsgi]
plugins-dir=/usr/lib/uwsgi
plugin=python27_plugin.so
virtualenv=/path/to/py27env
chdir=/path/to/py27app

とロードさせればpython2.7を利用できる。

同様にphp-embeddedの入った環境で

python uwsgiconfig.py --plugin plugins/php nolang php

でphpプラグインもビルドできた。

ものすごく面倒なのでuwsgi側でvirtualenvから自動ロードするか、libpython.soをplugins-dirに持ってくるようにパッチを当てたい……

参考:http://projects.unbit.it/uwsgi/wiki/MultiPython

posted by ko-zu at 21:58| Comment(0) | TrackBack(0) | Python | このブログの読者になる | 更新情報をチェックする

2013年11月11日

Robots.txtチェッカーを作ってみた

http://forbiddenrobots.usb0.net/

Googleのrobots.txtとmetaタグ仕様 https://developers.google.com/webmasters/control-crawl-index/docs/robots_txt に準じているつもり。

Flask+uwsgi-emperor+MongoEngineを試すのがメインだったので、 コアはFlask、サーバーはnginx+uwsgiでuwsgi-emperorでプロセス管理、バックエンドにMemcachedキャッシュとMongoEngine。 httpにpython-requests、htmlパーサはBeautifulSoup4という普通な構成。

ひとまず動くところまで出来たけれど、gevent化やmongodbの分散とか実装してみたい。 いまだにgeventをwindows環境で動かすことができていないのでしばらく掛かりそうだけど。

posted by ko-zu at 23:58| Comment(0) | TrackBack(0) | Python | このブログの読者になる | 更新情報をチェックする

2012年09月06日

民放テレビ局の音量均一化アルゴリズムを実装しての感想

http://www.nab.or.jp/loudness/
CMの音がうるさい、という事で均一化することを決めたらしい。
どの程度の効果があるのか知りたかったので、公開されているアルゴリズムを実装してみた。

実装したのは単一wavを適正音量に治すだけ。公開されている検査プログラムはパスする。
使い方は実行するとでるヘルプをみてください。python2.7系とnumpyとscipyが入ってればそれだけで動きます。

運用としては、ラウドネス計算の前に
・入稿する素材の中の各部分間の均一化は既に行われていると仮定
・CMとコンテンツは別素材として扱う
し、個々の素材毎に平均したラウドネス値を-24dB(フルスケール比)とする、と規定している。

このプログラムを使うには、
音量が大きな差がある部分を複数のwavに分けて、このプログラムを -n オプション付きで実行する。
拡張子の前に".norm"のついたファイルができるので、それを結合して結合部分付近を聴き比べる。

短い切った素材同士だと、だいぶ改善して聞こえる。(ラジオのエアチェックが元)
長い番組と長い番組をつなぐと、(当然だけれど)音量差はやはり感じられる。

この運用方針は、
・CMのような短い素材が極端に大きな音を利用しようとすること
・番組全体の平均音量を下げてCMを大きく見せること
を排除しようとしているのがわかる。

なぜかというと、アルゴリズムとして、

・まず無音部分を無視する。
・絶対的なラウドネスを計算する
・絶対的なラウドネスから-10dB以下の部分を全て無視する
・有効部分のみから最終的なラウドネスを算出する

というわけで、番組平均より-10dBいじょう小さな部分をつけて引き伸ばしても、平均ラウドネスを大きく見せかけることはできない。
逆に言えば、-5dBくらい音量を下げた部分で時間を稼げば、計算されるラウドネスと実際の音量に差をつけることは可能だ。
-10dBよりもっと差を小さくしたほうが良いと思うが、そうすると(放送全体にわたっての)平均ラウドネスが過大評価にすぎる、という問題も出るだろうから、どう決めたのか知りたいところだ。

posted by ko-zu at 01:12| Comment(0) | TrackBack(0) | Python | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。