先日、web.pyで研究室ミーティング管理アプリを作って、 Flask を使えば良かったかなあ(練習的な意味で)、と軽く振り返りながらGoogle様と戯れていたら、FlaskみたいなコンパクトなWebアプリケーションフレームワークが他にも結構あることを知った。
web.pyを目指しているFlaskって感じ。URL定義はdecorator方式。
Bottleは(強い)依存関係無しと言って単体である程度出来るところまで頑張っているようだが、まだSessionがサポートされていないのは痛い(Beakerに頼ることになるか)。Junoは色々依存ライブラリがある(データベースを使うためにSQLAlchemyが必須とかは重いなあ)。
もろSinatra(Rubyの)っぽい見た目。URL定義はdecorator方式。ドキュメントはなく、examplesを読めということらしい。依存ライブラリ無しというのは良いが、まあ大したことは出来ない。
Flaskのバランスの良さがよく分かった。次はFlaskで何か作ろう。
Windows/Linux専用。つまり、Macでは今のところ使えない。qemuとかffmpegを作った人製。コンパイル速度がGCCより速いらしい。
C/C++ interpreter。built-inでdebaggerやクラスブラウザが入っている。
C/C++ interpreter。古くからあるらしく、結構有名。IDEがある(英語版、中国版、日本語版)。User's Guideが教科書っぽいので、教育用途だろう。
非常にシンプルなC interpreter。「It was originally written for scripting a UAV's on-board flight system and it's also very suitable for other robotic, embedded and non-embedded applications too.」とあり、なかなか使えそう。
openFrameworksでJSONを扱う際はJsonCppがよく使われているようだ。
Cならjson-cが広く使われていて、picojsonは後発でhファイルonlyの構成で扱い易そう。
Androidアプリを作るにあたって、ゲームエンジンというのは欲しい。iPhoneでは cocos2d の派生のcocos2d-iphoneが人気らしい。
cocos2dのAndroid版だが、 `JBox2D`_ のラッパの形で実装しているようだ。
結構注目されているようだが、開発が2.0に向けての開発が進んでいるようで止まっている。Twitterのアカウントも消えているし、公式WebサイトのWikiは壊れているし、これからの進展が心配になる。
JBox2Dを使うのが、サンプルも豊富だし簡単そうだが、AndroidのOpenGL ES用にチューニングされたライブラリの方がパフォーマンスに優れているだろう。
もう少し様子見かな。
特徴は、FastCGI/mod_wsgi/Tornado/Gevent/CGIと動かせる環境が選べるところ、デコレータを使って綺麗に書けるところ。
もうWebフレームワークはお腹いっぱいで、Google App Engineで使うなら kay-framework - Project Hosting on Google Code 、個人で使うものをちょっと作るなら web.py みたいな法則を作ってしまえばもうどんとこいなわけだが、新しいものが出ると覗いてしまう。
Processing用のGUIライブラリというものもあるらしい。
JythonからProcessingをライブラリとして使ったときは、JFrameにPAppletを貼り付けて、その下にSwing部品を幾つか、という感じで作ったが、Processing用のGUIライブラリがあればもっとProcessingらしく良い感じの画面が作れそうだ。
バーコードリーダを作りたくなって、ライブラリを探してみた。
C/C++で書かれていて、Python/Perl用ラッパが付属。Objective-Cでも使える。画像の読み込みはImageMagick/PIL辺りに任せる必要がある。
Macでコンパイルすると、不必要なものや、幾つかエラーを出すものがあったので適当にオプションを付けた。
$ ./configure --prefix=/opt/temp/zbar-0.10 --disable-video --without-xv --without-gtk --without-qt $ make $ make install
Javaライブラリ。Java SE, Android, Java ME, C#, C++, RIM(BrackBerry), Objective-C(iPhone)に対応したポートや、JRuby用ラッパがある。
ビルドはantでする。Android SDKを入れていないので、build.xmlを適当に編集。
<target name="build">
<ant dir="core" target="build"/>
<!-- <ant dir="javame" target="build"/> -->
<ant dir="javase" target="build"/>
<!-- <ant dir="android" target="compile"/>
<ant dir="androidtest" target="compile"/>
<ant dir="android-integration" target="build"/> -->
<!--<ant dir="zxingorg" target="build"/>-->
</target>
画像の読み込みはBufferedImageを使えるので、javax.imageio.ImageIO等でファイルを読み込む。
試しにプログラムを書いて、MacbookのiSightからのカメラ画像でやってみたが、バーコード読み込み失敗が頻発する。もう少し考えて、精度を上げたい。
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が既に入っている。
groovypptest - Project Hosting on Google Code 、 jetlang - Project Hosting on Google Code 速い!
ScalaがErlangに倣い過ぎてJVMの特性を見極めていないらしい。まあ、そもそもJVM上で実装されなければならない理由は無い言語だしなあ。出でよ、Native Scala。
Strongly Typed, Loosely Coupled: Groovy++ vs. Groovy vs. Java vs. Scala - Performance Update みたいな話もあるし、Scalaからjetlangを使うのが良いかな。
This work is licensed under a
Creative Commons Attribution 2.1 Japan License.
