先日、web.pyで研究室ミーティング管理アプリを作って、 Flask を使えば良かったかなあ(練習的な意味で)、と軽く振り返りながらGoogle様と戯れていたら、FlaskみたいなコンパクトなWebアプリケーションフレームワークが他にも結構あることを知った。
web.pyを目指しているFlaskって感じ。URL定義はdecorator方式。
Bottleは(強い)依存関係無しと言って単体である程度出来るところまで頑張っているようだが、まだSessionがサポートされていないのは痛い(Beakerに頼ることになるか)。Junoは色々依存ライブラリがある(データベースを使うためにSQLAlchemyが必須とかは重いなあ)。
もろSinatra(Rubyの)っぽい見た目。URL定義はdecorator方式。ドキュメントはなく、examplesを読めということらしい。依存ライブラリ無しというのは良いが、まあ大したことは出来ない。
Flaskのバランスの良さがよく分かった。次はFlaskで何か作ろう。
特徴は、FastCGI/mod_wsgi/Tornado/Gevent/CGIと動かせる環境が選べるところ、デコレータを使って綺麗に書けるところ。
もうWebフレームワークはお腹いっぱいで、Google App Engineで使うなら kay-framework - Project Hosting on Google Code 、個人で使うものをちょっと作るなら web.py みたいな法則を作ってしまえばもうどんとこいなわけだが、新しいものが出ると覗いてしまう。
1日かけて、Xcode/Interface BuilderでObjective-CによるCocoaアプリの作り方を勉強した。思ったことは、PyObjCの立ち位置は微妙だということだ。
Xcodeのデフォルト新規プロジェクトでPythonプロジェクトを作れなくなったことに何の理由があるのか分からないが、Mac標準搭載のPythonにはPyObjCが入っているところ(使えるけど作れない状況)から見て、PyObjCはMacが提供する仕組みじゃないから、Macが作ることを促して、後であれこれ言われても仕方ないから外した、といった辺りの流れがあったんじゃなかろうかと推測する。
Objective-CならC/C++とそう変わらずプログラムが書けるわけで、じゃあわざわざPyObjCを採用するメリットって何だろうということになる。多分、チュートリアルを読むに、CocoaアプリのGUIをPythonで使うために、PyObjCは使われるのだと思う。そうすることでGUI周りだけObjective-Cの知識が必要で、他のモデルやコントロールの大部分はPythonの持つ豊富なデフォルトのライブラリを使えるというメリットがあるだろう。しかし、そこまでしてPythonでCocoaのGUIを使いたいかというと、どうも弱い。Javaに溶け込んでいるJythonの様な形であれば特に問題は無いのだが、PyObjCは中途半端にObjective-C記述能力を求めるものだから、メソッド名が汚くなっているようにも感じるし、ならもうObjective-C pureに書いてしまった方が、速いだろうし、プロジェクト全体がシンプルに収まる気がする。
まともなWindowsアプリもLinux/Xアプリも作ったことがないから、こういうアプリケーションの開発にどういうものが求められているのか、まだ見えていないのか。
Macをメインにして、そろそろPyObjCで遊んでみようかという気になって、Xcodeで新規プロジェクト作成画面を見たら、あると言われていたPythonプロジェクト項目が無い。どうやら3.2で、デフォルトからは綺麗さっぱり無くなったらしい。
PyObjCの pyobjc-xcode というディレクトリの中に、プロジェクトテンプレートがあるので、それを使えば良いようだ。
普段のPythonはmacportsから入れたものを使っているが、Mac標準搭載のPythonにはPyObjCが既に入っている。
diesel is a framework for writing network applications using asynchronous I/O in Python.
またhandles concurrency with easeなネットワークアプリケーションフレームワーク。
echoサーバの例でもそうだが、yieldがメッセージの送受信のための役割を担っているというのが、ぱっと見ての特徴か。
Windows 7のSensor APIドキュメントを読んでいて、OSがここまでサポートしてくれるようになったのだなあ、と感心する一方で、マルチタッチ界隈も動いており、各プログラミング言語の環境提供のためのライブラリが出揃ってきた。Javaには MT4j がある。
MTがキーワードか? 検索し難いけど。
しかし未だに、マルチタッチ対応デバイスの安価な手段が提供されていないようだ。やりたいことは色々あるのに。
JCC is a C++ code generator that produces a C++ object interface wrapping a Java library via Java's Native Interface (JNI). JCC also generates C++ wrappers that conform to Python's C type system making the instances of Java classes directly available to a Python interpreter.
PythonからJavaライブラリを叩くために、C++インタフェースをこしらえてくれるツール。Lucene関連で使われているらしい。
Webで見られるドキュメントがInstallationとFeaturesしか無くて、Featuresの方にHow to useが書いてある。つまりドキュメントはあまり良くない。オプションがずらっと書いてあって、えーという感じ。
Jythonを使うのも良いが、Twistedなどを使いたいなら純正Pythonだし、こういう道具は時々嬉しい。
研究室のWindowsデスクトップでやってみる。
hirax.net::無料配布のMathematicaカーネルをIronRubyから自由自在に使ってみよう を参考に Mathematica Playerと.NET/Linkを配置。`.NET/Link User Guide - Wolfram Mathematica`_ も軽く読んでおく。
例題?に倣い、2次方程式の解を求める。
IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.3603
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> clr.AddReference("Wolfram.NETLink") # clr.AddReferenceToFile("Wolfram.NETLink.dll")
>>> from Wolfram.NETLink import *
>>> kl = MathLinkFactory.CreateKernelLink()
# ファイル選択ダイアログが出るので C:\Program Files\Wolfram Research\Mathematica Player\7.0\MathKernel.exe を指定
# もしくは以下のようにパスを直接指定する http://www.hirax.net/diaryweb/2009/10/12.html#8415
# kl = MathLinkFactory.CreateKernelLink(r"-linkmode launch -linkname 'C:\Program Files\Wolfram Research\Mathematica Player\7.0\MathKernel.exe'")
>>> kl.WaitAndDiscardAnswer()
>>> print kl.EvaluateToOutputForm("Solve[a x^2+b x+c==d,x]", 0)
# 一般の数式を記述するような表示が返ってくるが、プログラムよりの表示にしたければ以下のようにする
# print kl.EvaluateToInputForm("Solve[a x^2+b x+c==d,x]", 0)
実に簡単。数式処理ソフトがこんなに簡単に(無料で)扱えることを、全く知らなかった。
hirax.net::IronRubyとMathematica Playerで経済データも自由自在 によれば、Rの様にデータを取って加工することも出来るらしい。
面白い道具を使えるようになった、という感動がある。
玄箱PROで動いているlighttpdでWevDAVを立ち上げるなら Webサーバ「lighttpd」でWebDAVを使うには − ＠IT や Hacking WD MyBook World Ed: Webdav 等を見てすれば良いのだが、どうもブログ検索してみるとmod_webdavはいまいち調子が良くないらしい(結局出来なかったとかマイナス記事がやたら目に付く)。
もう少し簡単に確実に、WebDAVサーバを立ち上げる方法が無いか考えてみて、Python実装があるに違いないと思い調査。
というわけで、pywebdavを使うのが簡単みたい。
Webサーバ入りWebアプリケーションフレームワークと見ても良いのだけれど、Webサーバが肝で、フロントエンドにnginxを置いて動かすと、Djangoやweb.pyに比べて爆速なパフォーマンスを得られるらしい。
epoll(7) を使って、ノンブロッキングハンドルで動作しているのだとか。
リアルタイムWebが叫ばれた昨今、もう少し熟して、安定性が保証されれば、この軽快さは十分売りになるのだろうな。
This work is licensed under a
Creative Commons Attribution 2.1 Japan License.
