PyramidフレームワークでPython+WSGIのWebアプリ（１）とっかかり

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アプリ（２）インストール 〜 Hello, world

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

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

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

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

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

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

• 開発環境では開発のみ行い，デバッグはすべて実行環境で行う

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

• テスト用コードと実行用コードを用意する

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

• 開発環境に実行環境と同じサーバ機能を再現する

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

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

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

もう少し調べてみます！

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のものが，ライブラリなどはローカルのものが導入されたプロジェクトが完成

２回目以降編

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

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

学生のうちでもなるべく現場に近い作業を積んでいって，こういったユーティリティソフトウェアをただ道具で終わらせるのではなく，

• どう嬉しいのか
• 誰が嬉しいのか
• このソフトウェア固有のものは何か

といったことに思考をめぐらせると面白いですね．

失敗例から学ぶStartupWeekend@Fukuoka

先日の話です．
8月25日（金）の夕方から8月27日（日）の夜まで，StartupWeekendが開催されました．
大雑把にいうと「約50時間強で起業のスタートアップをする」というものです．無茶苦茶な．
流れは，

• 自分のアイデアを発表したい参加者がみんなの前で1分間のピッチを行う
• アイデアを上位8つに絞る
• 参加者は8つのアイデアのうち自分が携わりたいものを選ぶ
• それで集まったメンバーがチームとなる
• チームは残り時間で開発，マネタイズの確立，プレゼンの準備を行う
• プレゼンで8つのうちから（いろいろな）トップを決める

という感じでした．

失敗の原因

最初に申し上げておきますが，以下の内容は誰々がどうだったとか，もしああしていれば・・・とかそういう辛気臭く仲間を批判するような内容とは程遠いものです．よしなに．

結論からいうと我々のチームは見事に失敗しました．

「ああ，こうやって間に合わなくなっちゃうんだな」って体感した気がします．

で，何がだめだったかを考えたのですが，以下の項目に集約されると思います．

1. 問題に対する解決策が明確でない
2. 動くものがない

問題に対する解決策が明確でない

私たちのチームは問題を解決する手法を決めるのに多くの時間を費やしてしまいました．

方向性が決まらないことには，各メンバーの得意分野の作業にとりかかることができません．

それで，結局完全なストーリーを一本つくることができず，成果物もプレゼン内容も確定していない状態で発表することとなってしまたのです．

この部分を反省するにあたり，まずStartupWeekendで発表するときの心構えみたいなものを説明しておきます．

StartupWeekendでは，ひとりひとりのピッチも，最後のプレゼンも，基本的には「世の中のこういう問題は，我々のつくったサービス（orアプリorデバイスetc）で解決できる！」とうロジックで話を進めます．

おそらく，わかりやすいからでしょう．学生の身分ではあまり多くを語れませんが，NEEDSベースな部分に人々はお金を落としていくのではないでしょうか．つまり，問題に対して共感できるというのが，プレゼンにおいて重要なんだと思います．

さて，この現象を回避するためにはどうすればよかったのか．

• チームのアイデア源である人が多少強引にでもひとつの解決案を押し通す
• 誰が見ても明らかでわかりやすい解決案である

こんなところを考えています．「問題は共感できるんだけど，なかなか解決策が思いつかない・・・」というシーン，あると思います．リーダーの人，ファイト！

動くものがない

上記にも関連するのですが，結局この手のイベントは動くものを見せないと始まらないのでしょう．

「おお，なんか面白そう．俺も使ってみたいわ．できるのかな？あ，できてるんだ，スゲー」

聴衆にここまで思わせれば優勝ですたぶん．

前半部分がおろそかなのは論外，後半部分が不十分なのは机上の空論で終わってしまいがちです．

今回福岡で優勝したOooiのプレゼンをみたとき僕が思ったのは，まさにこんな感じでした．たぶん他の人も同じでしょう．だからこそ圧倒的な支持をもらえたのだと思います．

動くものをつくるためには，「問題に対する解決策の意思統一がとれていること」がとても重要になってきます．作ったものが支離滅裂だったらどうしようもないですものね．

意思統一にかける時間を最低限にし，あとはその道のスペシャリストに作業を分担するという流れが理想的です．エンジニアがプレゼンを気にする必要はないでしょう．

起業に必要な要素

ってでかくいってますが，「こんなイベントに必要なこと」と読み替えてくださって問題ないです．

アイデアの普遍性

投票性である以上ニッチな話題は不向きです．誰もが潜在的に抱えている問題をそれっぽくばらまくのがよさげです．

問題とその解決案のわかりやすさ

共感を得やすいですし，さっさと開発作業にとりかかれます．

プロトタイプ

とにかく動くものを見せることが重要です．

プレゼンのわかりやすさ

最初，最終発表の5分という時間は短いと思っていましたが，わかりやすさを追求するならば納得です．

リーダー的存在

この場に必要なのはボスではなくリーダーです．ゴン蔵ではなくたけしなのです．

世の中に存在しない解決策を講じようとしているのだから，皆が不安を覚えるのは当然です．

リーダーの人は，多少のバッシングなどなんのその，責任をもってメンバーを引っ張っていくべきでしょう．皆，リーダーのアイデアに共感して集まってくれたのですから．

以上を一言にまとめると，

スタートアップイベントは，リーダーがアイデアのわかりやすさを維持し，エンジニアとデザイナーが開発し，それをドヤ顔で自慢するように発表する

ですよ．

また参加したいです！

Toodledoによる一週間のタスクサマリ(2011/6/30～2011/7/15)

Toodledoは一週間しか履歴を保存できませんが，一週間ごとにEvernoteにクリップすればほぼ半永久的に蓄積できることに気が付きました．さらに，このように表やグラフにまとめれば本家の有料版タスクサマリ出力機能にひけをとらない効果を得られるはずです．その分時間はかかりますが，自分に合った分析ができ，なおかつ文書化できますのでどっこい以上を期待していいでしょう．

一週間のサマリ

二週間の「タスクの絶対数」は以下のようになりました．

二週間の「タスクに費やした時間」は以下のようになりました．

最後にコンテキストごとの平均時間です．これはこれまでの累積で算出しています．

勉强していない．聞けば，学部4年の後輩の皆さんは大学院試験へ向けて毎日一時間その対策のための勉强に時間を費やしているそうです．

彼らのほうがよほど自己管理できている．見習いたいものです．

Toodledoによる一週間のタスクサマリ(2011/6/23～2011/6/30)

今日もやります．できるだけ続けたいです．

さて，前回からの変更点は

l  「資格」フォルダを削除

l  「Study」コンテキストを追加

です．資格はよく考えるとフォルダを作るレベルではないと思いました．というわけで資格の勉强時間などはStudyコンテキストへ割り当て，ライフに統合しています．Studyコンテキストですが，

l  知識を得ることによって完了できるタスク

と定義しています．Investigationタスクとの違いは，知識を得る手段がそのまま目的につながるかどうかということと，知識を得る元となる泉がはっきりしているかどうか，です．Studyは知識を得ることが手段であり目的ですがInvestigationは目的が別にあるでしょう．また，Studyは参考本や演習ページなど知識の泉があらかじめはっきりしていることが多いです．Investigationはどこから知識を得るかということも含めて考えなければならないでしょう．

たぶん来週はCodingタスクが追加されることになると思います．

一週間のサマリ

今週の「タスクの絶対数」は以下のようになりました．

圧倒的研究．少しずつ自分のやりたいことであるライフも増やしていきたいです．

今週の「タスクに費やした時間」は以下のようになりました．

研究さんです．調査もさることながら，何をやるかわかっているExecutionタスクに関してもとにかく長い．しかし，Executionタスクは短縮させねばなりません．自動化の対象です．特に一度やったことに関しては現在自然言語のスクリプトに甘んじているので手順を再現しているに過ぎません．これを実際のプログラムで書ければ一歩進むように思います．雑務は少なければ少ないほどよいので一時間未満をキープしたいところですが今週は雑務タスクが溜まってしまっています．ライフタスクにかける時間はもっと必要です．

最後にコンテキストごとの平均時間です．これはこれまでの累積で算出しています．

先日の発表資料作成が効きPresentationが相変わらず飛び抜けています．研究以外の時間ではよく本を読んでいますね．また，研究関連の調査にも時間を費やしているようです．

ところで，このようにタスクのサマリを計算する前々から，一週間に一度研究報告をする機会があり，そこでは研究のWriteDocumentにあたる作業をおこなっていました．体感では3時間くらい毎週それに費やしていたように感じていたのですが，いざこのようにコンテキストを分け時間をしっかりはかると2週間での平均は49.5分となり実は一時間もかかっていないことがわかります．以前は調査しながら書いていたことが長く感じる原因でしょうか．しっかりと作業を切り分けることにより効率化が望めそうです．

Toodledoによる一週間の作業履歴サマリ

 折角Toodledoを使っているので，履歴データを活かそうと思いこれまでの作業記録をまとめることにしました．…が，しかし，Toodledo Free アカウントでは履歴データが一週間分しか保存されないことを完全に見落としており，それ以前のデータは消え去ってしまったという悲しい事実があります．一週間ごとにまとめる，あるいは時間がなければ履歴データのページをEvernoteにでもクリップしておくべきでしたね．とても残念なサンプル数となっていますが結果は以下です：

タスクの分類

Toodledoには「フォルダ」と「コンテキスト」という分類方法があり（タグもあるそうですが使っていません），これを用いてタスクを分類します．自分の場合，

【フォルダ】

タスクの所属．何のためのタスクか，何を達成するためのタスクか．フォルダは必要に応じて追加できるし，必要なくなれば削除してよい．

l  研究

l  雑務

l  資格

l  ライフ

【コンテキスト】

タスクを達成するための手段．基本的に永劫変わらない．

l  Mail

Ø  名の通りメールを送信することによって完了できるタスク．ほとんど時間はかからないだろう

l  Execution

Ø  タスクを完了するためのプロセス，タスクを行ったことによる結果がわかっているもの．あとはやるだけ！みたいなの．時間も見積もりやすいはず

l  Presentation

Ø  スライド作成，発表練習によって完了できるタスク．非常に時間がかかりそう

l  WriteDocument

Ø  キュメントを書くことによって完了できるタスク

l  ReadDocument

Ø  ドキュメントを読むことによって完了できるタスク

l  Investigation

Ø  調査タスク．方法もゴールもわからないことが多いため，時間の見積もりが一番きかなそう

一週間のサマリ

早速ここ一週間の作業結果をみてみます．今週は金土日と別件で取り込み中でしたので，作業時間は少ないです．本当はもっと履歴データがあったのに…とつくづく自分の適当さを悔やみます．

さて，まずは「タスクの絶対数」です．

やはり研究関連のタスクが多いですね．資格ゼロとは世の中舐めきってます．それから雑務はメールを送ることが多いようです．一週間でこれですから，累積していくと結構な数になりそうです．

次は「タスクに費やした時間」です．

圧倒的研究．バランスが非常に悪い．よろしくないですね．

最後に「１タスクあたりに費やした平均時間」です．これはコンテキストごとに合算しています．

PresentationとInvestigationの長時間っぷりが目立ちます．これらの作業時間を見積もるときは注意したほうがよさそうです．ReadDocumentは小説を一冊読みました．本当は論文やら技術書やら読むべきなのですが．

今週の分は以上です．サンプル数が少ないのでなんともいえないところも多いですが，続けていくことで有用な時間見積もりのための履歴データができあがることを信じています．もっともいつまで続くかはわかりませんが．物は試しです．