2011年10月20日木曜日

PyramidフレームワークでPython+WSGIのWebアプリ(1)とっかかり

Webアプリケーションを作成するとき,そのための道具は枚挙に暇がありませんが,Python界隈がにぎわっているようです.


僕はこれまでJava系のフレームワークしか利用したことがなかったのですが,スクリプト言語でのWebアプリも興味深いですね.


というわけでPythonでのWebアプリ作成を検討します.


理由は上記のものもありますが,ちょっと遊んでみようと思って,日本語でのドキュメントやチュートリアルなんかが少ないな,と感じたので,皆さんと共有できれば幸い,というのが大きいです.


Google App Engineも,PythonのWebアプリケーションフレームワークで実装しているんだとか.


そうだ,Pyramidをつかおう

さて,早速PythonでのWebアプリ作成にとりかかりたいと思います.


ここで気になるのが道具ですね.どうも,Python単体では,いろいろやろうと思うと限界がありそうです.そこで,JavaでいうTomcatやglassfishにあたる,Webアプリケーションフレームワークが欲しくなります.


Python界では本当に多くのフレームワークがあり,選択肢が多いです:
  • Twisted
  • Zope
  • CherryPy
  • TurboGears
  • Django
  • Pylons
老舗にあたるのがどうやらTurboGearsのようです.が,ここではPylonsに注目してみようと思います.理由は,開発スピードが早く日本語のドキュメントが少ないこと,Ruby on Railsを彷彿させるMVCアーキテクチャを採用していること,包括的に多くのフレームワークを持ちつつ,シンプルな記述も可能であること,などです.
フレームワークのフレームワークとでも言えばいいでしょうか.Pylonsは他の多くの仕組みを自身に持っています.アプリケーションサーバでいうと富士通のInterstageがSpringやStrutsなどのオープンソースフレームワークを抱えていますが,ちょうどそのようなイメージです.


そして,Pylonsを含む上記リストアップしたフレームワークの特徴として,WSGIに準拠している,というものがあります.
WSGIとはフレームワークを用いてサーバとアプリがやりとりをするとき,その方法をPythonで定義したものです.ちょうど,JavaでいうServletやjspみたいなものです.
よって,Pylonsを使ってWebアプリを作り続けたが,他のフレームワークへ移行したいというシーンがあったとき,それまでのがんばりが無駄になることはありません.WSGIに準拠したフレームワークであれば,我々はその実装を意識することなく,Webアプリのコードが書けます.


が,このPylons,開発スピードが速いのもあってか,バージョン1.0を境にサポートは行うが新しく開発はしないというメンテナンスモード,レガシーステータスに設定されてしまいました.
事情としては,
The Pylons web framework 1.x line will continue to be maintained, though not enhanced. We will provide a package that allows Pylons 1.x applications and Pyramid applications to run in the same interpreter. The future of Pylon-style web application development is Pyramid
ということらしいです.
かわりに,このPylonsを統合するような形で新しくフレームワークがリリースされました.それがPyramidです.このフレームワークについては日本語のドキュメントが圧倒的に少なく,また利用事例も少ないようです.


公式のドキュメントはこれでもかというほど充実しているので,それらを紐解きつつ,実践的なWebアプリを実装していきたいと思います.


と,いうわけで次回から実際にインストールしてみて,使ってみた時の記録をまとめていきたいと思います.





PyramidフレームワークでPython+WSGIのWebアプリ(2)インストール 〜 Hello, world



PyramidフレームワークでPython+WSGIのWebアプリ(3)MVCに則ったサンプル(BankAccount)


2011年10月8日土曜日

開発環境と実行環境があるときのデバッグ

今研究室のプロジェクトで,電力や水量,二酸化炭素量といったエネルギーデータを測定する九州大学のメータから情報をひっぱってきて一元的に管理するシステムみたいなのを作っています.

開発では,各自のPCにEclipseを入れ,ソースをSVNで共有しています.
実行環境は別にあり,DBやアプリケーションサーバがインストールされています.

で,ここで疑問に思ったのが,アレ,デバッグどうやってやろうか,ってことです.
僕はこういう環境だとこれまではプロジェクトをjarなりwarなりで固めて開発環境の方へ投げ,チェックポイントのログや例外のスタックトレースなんかを適当なファイルに吐かせて確認していたのですが,統合開発環境のデバッグ機能って便利ですよね.それを使えないのはもったいないな・・・って思ったんです.

開発環境と実行環境がある場合のデバッグ方法はいくつかあると思います.その長短について自分なりの考えをまとめます.


  • 開発環境では開発のみ行い,デバッグはすべて実行環境で行う
僕が採っている方法です.実用への感覚をつかみやすく「修正→再ビルド→再実行」の流れをスムースに行えますが,統合開発環境のデバッグ機能が使えません.


  • テスト用コードと実行用コードを用意する
つまりDBなどが実行環境にある場合接続部分をローカル用とリモート用両方用意し,開発段階ではリモート用のコードを使うというやり方です.統合開発環境のデバッグ機能が使え障害箇所を特定しやすいですが,「バグ発生→デバッグ→修正→再ビルド→再実行」という流れの中でテスト用と実行用のコードを書き換えないといけないのが億劫です.


  • 開発環境に実行環境と同じサーバ機能を再現する
統合開発環境のデバッグを使え,コードもローカルやリモートといったことを考慮せずに済みます.しかし開発環境と実行環境とでOSが違う場合に発生する問題や,利用しているサーバソフトウェアのバージョンの違いなどを考慮する必要がでてきます.いざ問題が発生すると原因の特定に時間がかかること必至っぽいです.

と,いうわけで現在これといった決定打もなく勝手なやり方でデバッグしております.もしかしたらこのへんのわだかまりを解消してくれるフレームワークみたいなのはあるかもしれませんが,Springとかみてると大抵ああいうフレームワークは巨大です.今回のような小規模なシステムに対しては大げさに感じてしまいます(そのような発想でシステムが大きくなるといわゆるツギハギになってしまうのかもしれませんが).

みんなはどんなふうにデバッグやってるのかな〜統合開発環境使いこなせてなくてごめんなさい.

もう少し調べてみます!

2011年10月3日月曜日

EclipseからSubversionを使う

ひととおりの手順をメモ


◯前提
Eclipse(Indigo)がインストールされ,使用出来る状態にあること

◯手順
インストール編
  1. EcipseのHelp -> Install New Software
  2. リポジトリを追加する Name:適当(SubclipseとかでOK) URL:http://subclipse.tigris.org/update_1.6.x
  3. 取得したパッケージをすべて選択し,Next
  4. Temsに同意してインストール,Eclipse再起動

新規共有プロジェクト作成編
  1. 普通にJavaプロジェクトを作成し,ビルドし,実行したりする
  2. 満足したところでパッケージエクスプローラのプロジェクト名のとこを右クリ
  3. Team -> Share Project -> SVN ->Next ->ロケーションはakbのリポジトリを指定 ->Next
  4. プロジェクト名をフォルダ名として使用にチェックを入れFinish
  5. ユーザ名やパスを入れる
  6. これで自分のプロジェクトのフォルダがサーバー側に出来上がります
  7. パッケージツリーで右クリ -> Team ->コミット
  8. これで作成したJavaファイルなどがアップロードされます


他の人がSVNにあるプロジェクトを共有する編
  1. EclipseでFile->Importを選択
  2. SVN->SVNからプロジェクトをチェックアウト を選択し Next
  3. AKBのSVNがなければ新規リポジトリ作成,すでに作っていっれば既存のリストにあるはずなのでそれを選択
  4. リポジトリを選択するとフォルダリストがでてくるのでインポートしたいプロジェクトが入っているフォルダを選択
  5. 次の画面(チェックアウトオプション)で「新規プロジェクトウィザードを使ってプロジェエクトとしてチェックアウト」を選択->Finish
  6. プロジェクトの特性(Java?Tomcat?)に従い新規プロジェクトを作成
  7. ソースなどはSVNのものが,ライブラリなどはローカルのものが導入されたプロジェクトが完成

2回目以降編
  1. チェックアウトしたプロジェクトを編集する前は必ず更新する
  2. 編集したプロジェクトをアップロードする場合はコミットする


ここでSVNの設定をしたのがきっかけでちょっとばかしgitについて調べてみたのですが,いやはやバージョン管理ソフトウェアって相当奥が深いですね.

学生のうちでもなるべく現場に近い作業を積んでいって,こういったユーティリティソフトウェアをただ道具で終わらせるのではなく,
  • どう嬉しいのか
  • 誰が嬉しいのか
  • このソフトウェア固有のものは何か
といったことに思考をめぐらせると面白いですね.