Posts tagged ‘Python’

GAE のアプリケーションを Marketplace に登録するときの注意点

Google Apps Marketplace にアプリケーションを登録しようとしてハマった。この Marketplace への登録についてはそれなりにドキュメントが揃っているのですぐに出来るだろうと思っていたが、かなり時間が掛かってしまったのでその経過をメモ。

まずは Marketplace のデベロッパ登録をするのだが、これについてはオリジナルの “Google Apps Developer Program Site” に加えて、”Google Apps Marketplaceにアプリケーションを登録する方法” や “Google Apps Marketplaceにアプリを公開するときに気をつけること” を参考にさせていただいた。これらのドキュメントにしたがって、Marketplace の Vendor 登録はあっさりと完了。

続いてサンプルアプリケーションを登録してみようということで、”Writing your First Marketplace App using Python” に掲載されているコードを使って、Google App Engine にアプリケーション環境を構築する。そしてこれを Marketplace に登録し、さらに Google Apps からアクセスできることを確認した。

本来はここで Google Apps のアカウントからアプリケーションを起動できるはずなのだが、どうしてもエラーとなってしまい期待した結果にならない。調べてみるとサンプルコードの federated_identity() が本来返すべき値を返さず None を返していることがわかった。OpenID まわりでうまく行ってないのだろうと推測するものの、どうすればいいのか分からないまま調べを進めていたら、”App Engine and Chrome Webstore Issues” に解決策があった。原因はアプリケーションではなく GAE の設定であった。GAE の Application Settings にある Authentication Options を (Experimental) Federated Login にすることで、Google Apps に組み込んだ自前のアプリケーションを動作させることができた。

結論:
Google Marketplace に登録するアプリケーションを Google App Engine 環境で提供するときは GAE の Authentication Options を変更する必要あり。

ERP5 への道 — 導入編4

はじめに

前回、「ERP5への道 — 導入編3」で ERP5 のインストールまでこぎ着けたものの、そのまま手付かずになっていた。久しぶりに ERP5 を触ってみようと思ったら、buildout を利用したインストールが出来ることが分かった。ちなみに buildout のことは知らなかったのだが、Zope 環境で動作するプロダクトなどを配布ならびにインストールするための make のようなものと理解した。

手順の概略

インストール手順は基本的に erp5.org の Web サイトに記載されている情報に従った。

以降で具体的な手順について順番に記載していくが、ここでの内容は次の環境で実施したものである。

  • OS : Mandriva 2010.0 on 32 bits x86 CPU
  • HOST : VMware Player 3.0.1 (メモリ割り当て 768MB、HDD 20GB、NAT 接続)

RPM パッケージのダウンロード

まずリポジトリを設定してから buildout に必要な RPM モジュール群をインストールする。実際の作業は root アカウントで実施した。

# urpmi.addmedia –update nexedi http://www.nexedi.org/static/mandrivalinux/2010.0/i586/
# urpmi.addmedia –distrib –mirrorlist ‘http://api.mandriva.com/mirrors/basic.2010.0.i586.list’
# urpmi task-erp5-buildout

この手順によって ERP5 に必要なバージョンの Python と Zope などに加えて MySQL もインストールされる。

各モジュールのインストール途中で「複数バージョンが存在するので、どれをインストールするのか?」といった趣旨の問い合わせがある。Python などが必ずしも最新バージョンをインストールするわけではないことと関連していると思うが、すでにインストール済みのバイナリパッケージなどのバージョンを調べながら、出来るだけ一致したバージョンのものを選択したほうが良いと思う。

MySQL の設定

前項の手順を踏むと MySQL がインストールされているはずなので、そこに ERP5 用のデータベースとユーザを登録する。

  • データベース名 : erp5
  • ユーザ名 : erp5user

この名前はこれから実行する buildout で作られるbuildout.cfg 内にデフォルトで設定されている値である。データベース名などを変更するときは、buildout.cfg も編集する必要がある。

buildout の準備

ここからの作業は一般ユーザアカウントで実行する。buildout を実行する前に buildout を実行するユーザのホームディレクトリに ~/.buildout/default.cfg というディレクトリとファイルを作っておく。default.cfg の中身は次のようになる。

[buildout]
# Directory where built dependencies will be shared
eggs-directory = /home/<CHANGETHIS>/.buildout/eggs
# Directory to store downloads
download-cache = /home/<CHANGETHIS>/.buildout/download-cache

さらに default.cfg 内で指定した位置に eggs と download-cache ディレクトリを作っておく。この設定をしておくとキャッシュが有効となって buildout を繰り返した時の処理時間が短縮される。これらのディレクトリには buildout の実行ユーザが読み書き可能なパーミッションを設定する。

buildout の実行

まず ERP5 の buildout パッケージを取り出す。

$ cd <YOUR_WORKING_DIRECTORY>
$ svn co https://svn.erp5.org/repos/public/experimental/erp5.buildout/

ここで https を指定しているにも関わらず、証明書が自己生成のものなので確認を求められる。画面に表示される証明書情報を一応確認した上で、常に承認する旨の回答を選択しておく。

チェックアウトが完了すると、現在のディレクトリには erp5.buildout というディレクトリが作られる。そのディレクトリに入ってから、bootstrap/bootstrap.py と bin/buildout コマンドを実行すれば、erp5 のインストールが完了する。

$ cd erp5.buildout/
$ python2.4 -S bootstrap/bootstrap.py
$ python2.4 -S bin/buildout

実はここまでの記述は原本の HowToUseBuildout とは若干異なっている。原本では apt-get を使って gcc などの開発環境を整えているが、こちらではすでに urpmi コマンドを使って完了している。また、原本では データベース名が erp5db となっているが、buildout.cfg にデフォルト設定されている名前が erp5 となっているので、ここでもデータベース名は erp5 としている。さらに原本では buildout 実行時に python にはオプション指定が無いが、erp5.buildout/README.TXT をみると -S オプションを指定するようになっている。実は -S オプションの意味が十分に把握できていないのだが、ここでは -S を付けて実行している。

また buildout の途中で SOAP 関連のライブラリ欠如のためにエラーが出る。恐らく urpmi task-erp5-buildout では SOAP がインストール対象となっていないことが原因と思われる。このままでもインストールは完了して zope/erp5 は立ち上がるが、buildout 実行前に SOAP 関連のライブラリなどを手作業でインストールしておけばエラー発生は回避できると思う。

buildout コマンドを実行すれば、あとは erp5 のインストール完了を待つだけなのだが、実際には処理が途中でフリーズしたように見える現象に遭遇した。その時のプロセス状況を確認してみると、途中の svn co を実行したまま待ち状態になっているようなのだ。このままではどうしようもないので、一旦処理を中断してからもう一度 buildout コマンドを実行してみると、今度は最後まで実行が完了する、といったことを数回経験した。止まってしまうところは毎回異なるので、原因はつかめていないのだが、その後に ERP5 は問題なく実行できている。VMware Server 環境だとこのようなことは発生しないという報告もあるので、VMware あるいは マシン 固有の問題なのかもしれない。

buildout 終了後、次のコマンドで zope を立ち上げる。

$ bin/zopectl fg

なお fg の代わりに –help を指定すれば fg 以外のオプション機能を確認することができる。

続いてブラウザで次の URL にアクセスして ERP5 のログイン認証画面となれば、一応インストール作業が完了したものとする。

http://localhost:18080/erp5

ここでユーザ名 zope、パスワード zope を入力すれば ERP5 のトップ画面にアクセスすることができる。

日本語リソース導入のためのビジネステンプレート導入

ERP5 のメニュー表記などを日本語表示するためには、日本語化のためのビジネステンプレートを導入する。まず始めにHow To Install Business Templates における “Install Business Template from repositories” の項に記載されている手順に従って erp5_l10n_ja というローカライゼーション用のビジネステンプレートをインストールする。

  1. ERP5 トップ画面左上の “My favourites” メニューから “Manage Business Templates” を選択する。
  2. メニューバーにある “Import/Export” アイコン(青と赤の横矢印がすれ違うデザイン)をクリックする。
  3. “Update Repositories Informations” 画面になるので、そこにあるテキストエリアにリポジトリの URL http://www.erp5.org/dists/snapshot/bt5/ を入力してから、下部にある “Update Repositories Information” ボタンを押す。
  4. 同じ画面に成功メッセージが表示されたら、セレクトメニューから “Install Business Template” を選択する。画面にはインストール可能なビジネステンプレート一覧が表示される。
  5. 一覧から erp5_l10n_ja を探してチェックボックスで選択したら、画面最下部にある “Install Business Templates from Repositories” ボタンを押す。
  6. 確認画面になるので “Validate Installation” ボタンを押す。
  7. 画面右上にある言語選択メニューに “日本語” という選択肢が追加されていることを確認する。これを選べばメニューなどが日本語で表示されるようになる。

これで日本語化された ERP5 を利用できるようになる。

最後に

buildout による ERP5 のインストールは、途中で想定外の動作に遭遇するなど、まだ完全に把握できていない状態である。そのため本稿の内容には間違った記述や誤解が含まれている可能性があり、それらをご指摘いただければ幸いである。

Google App Engine 超入門

知人の会社で実施している社内向けのミニセミナーに講師として呼ばれた。どんな話題でもよい、ということだったので、Google App Engine の概略を解説することにした。1時間という貴重な時間を割いて集まっていただいた皆さんに満足してもらえる内容だったかどうか不安が残る。とりあえずその時に使った資料を次の URL で公開しておく。

http://bit.ly/9b2bwx

終盤の Google Apps との連携部分についてはうまく説明出来なかったので、十分に理解してもらえなかったかもしれない。

ERP5 への道 — 導入編3

はじめに

実は前回の「導入編2」ですべての準備が整ったと思っていたが、実はまだもう少しやることがあった。そのあたりのメモ。

MySQL

ERP5 のプラットフォームになっている Zope は独自のオブジェクトデータベースを持っているはずなので、何で MySQL なのかと思ったのだが、インデクス利用の高速化を図るためのオプションらしい。このあたりは勉強会主催者ロングフィールドさんの説明による。

Mandriva のインストール工程で MySQL は入らなかったようなので、このタイミングで導入しておく。

urpmi mysql-max

ERP5 プロダクトの最適化

前回すでに ERP5 のパッケージを導入済みだが、subversion のリポジトリ経由でアップデートすることも可能のようだ。

http://www.erp5.org/DownloadSourceCode

ただし、この方法でのアップデートの可否は erp5-dev メーリングリストなどを参考にしながら判断するように、との注意書きも添えられている。今回は試しにチェックアウトを実行してみた。もちろん事前に subversion のパッケージも入れておく。ちなみにチェックアウト先である $INSTANCE_HOME/Products は、今回の環境では /usr/lib/erp5/lib/python/Products となっている。

ERP5 サイトの作成

ここで Zope の管理画面に入るため、Web ブラウザで次の URL にアクセスする。

localhost:9080/manage

続いて画面右端にある “Accelerated HTTP Cashe Manager” と書いてあるプルダウンメニューより “ERP5 Site” という選択項目を選んで “Add” ボタンを押す。そうすると ERP5 ポータルサイトのプロパティと、MySQL 接続用の情報を入力する画面になる。とりあえずすべてデフォルトのまま “Create a new ERP5 site instance” ボタンを押すと、ERP5 のサイトが作られて管理画面左側のフォルダ一覧表示欄に erp5 という新しいフォルダが出来上がる。ここの処理が完了するまではしばらく時間が掛かる。たぶん 5分から 10分程度は掛かったと思う。これでようやく本当に ERP5 にアクセスできる環境が出来たようだ。

しかしロングフィールドさんによると、さらに「ERP5 コアモジュールの最新化」「ERP5 ビジネステンプレートのインストール」といった作業が必要らしい。コアモジュールの最新化って前述の最適化と違うのか? まだまだ ERP5 への道は長そうだ。

今回はここまで。

ERP5 への道 — 導入編2

はじめに

本稿は Mandriva のインストールを解説した「導入編1」に続いて、ERP5 のインストール手順を記述する。ERP5 はアプリケーションフレームワークとして Zope を利用しており、またその Zope は Python で記述されている。現在、Python のバージョンは 2.6 が主流だが、すでに 3.0.1 もリリースされていて 2.x 系から 3.x 系への移行が始まっている状況にある。ところが Zope 2.x の動作には Python 2.3 や 2.4 が必要となっている。Zope の開発が止まっているわけではないのだが、極めて慎重にプロジェクトを進めていることによるものと思われる。

実は数年前に Zope/Plone を評価しようとしたのだが、その時も Zope が Python の最新バージョンに対応しておらず、それだけで面倒になって放り出してしまった経験がある。コンパイル時の config オプション指定によって複数バージョンの Python を共存させることが可能であることは、だいぶ後になってから知った。それが可能になったとはいえ、複数バージョンの言語処理系を同時に維持管理することに対しては消極的になってしまう。

今回は Zope に加えて ERP5 もインストールしなければならない。どうなることかと思ったが、幸いなことに ERP5 Community が Zope/Python/ERP5 を一括してパッケージしたものを配布してくれている。これを使えば何の苦労もせずに ERP5 の環境が出来上がる。このパッケージが Mandriva 用にメンテナンスと配布が行われているため、導入編1のような苦労をしても Mandriva をインストールする必要があった。

RPM パッケージを使ったインストール

Mandriva 環境で ERP5 インストールする手順はhttp://www.erp5.org/DownloadRpm に詳しく記述されており、それに従って作業を進めればまず問題はないはず。基本的に RPM を取ってくるリポジトリを指定し、続いてインストールということになるが、Mandriva ではこれらの作業に urpmi というコマンドを使う。自分にはあまり馴染みのないコマンドだったが、CentOS などで使う yum コマンドと同じようなものである。

まずはリポジトリの指定。ここで 2009.1 の部分は Mandriva のバージョンと合わせる必要があるはずなので、Mandriva の版が変わったときは、こちらの指定も変えることになると思う。

urpmi.addmedia –update nexedi http://www.nexedi.org/static/mandrivalinux/2009.1/i586/
urpmi.addmedia –distrib –mirrorlist ‘http://api.mandriva.com/mirrors/basic.2009.1.i586.list’

続いて RPM パッケージのインストール指定。このコマンドを実行すると依存関係によって、70 近い数のパッケージがインストールされる。

urpmi task-erp5
urpmi task-erp5-devel

これで必要なパッケージ群がようやく揃った。

Zope/ERP5 の起動

ERP5 を起動する前に ERP5 (or Zope)専用のアカウントを登録する。

/usr/bin/zopectl-erp5 adduser [user_name] [password]

今回のインストール作業では、ここで大量のワーニングが表示されてしまったが、とりあえず無視して進んでしまっても問題は無いように見えた。しかし、今後 Zope/ERP5 を触ってもう少し状況が分かってきたら、きちんと対処する必要が出てくるのかもしれない。
また、ここで登録したアカウントは ERP5 のものなのか Zope のものなのか、現時点では理解できていないのだが、コマンドから類推すると Zope を統合した ERP5 を稼働させるというイメージなのだろう。

最後に ERP5 の起動コマンドを実行する。今回のインストール作業でどうなっているか確認していないが、/etc/rc.d にスクリプトを追加すれば、OS 起動時に ERP5 が自動的に立ち上がるようにできるのは、他のサービスの取扱いとまったく同じ。

/etc/init.d/erp5 start

Zope/ERP5 アプリケーションサーバのデフォルト画面には、localhost のポート 9080 にアクセスすれば良い。また、/manage にアクセスしてから、前述で登録したアカウントで認証を受ければ、管理用の画面にたどり着ける。

localhost:9080
localhost:9080/manage

これでやっと ERP5 を触れる状態になった。ここまで到達するのに時間と労力が必要だったが、実は TioLive という SaaS 型の ERP5 サービスを無償で試せたり、即 ERP5 が立ち上がる LiveCD が配布されているので、これらを利用したほうが ERP5 への近道かもしれない。

Google Apps と独自のホームページ

Google 社が無償提供している Google Apps の Standard Edition は、一般企業だけでなく NPO や NGO のような組織体、同窓会や趣味のサークル団体などでも利用すれば、メンバー間のコミュニケーションを活性化するだけでなく、事務作業のコストと時間を大幅に節約できる可能性がある。

Google Apps では独自のドメインを使って Gmail やカレンダー、Docs などの機能を利用できる。また、シンプルながらも良く出来た CMS である「サイト」機能を使えば、手軽にホームページを公開することができる。しかし、この「サイト」は誰にでも使いやすい反面、凝ったデザインのホームページや CGI のような Web アプリケーション的要素が少しでも入ったホームページの制作は困難である。そのためせっかく Google Apps を使いながらも、ホームページ公開だけのために別の Web サーバが必要になるかもしれない。

これではもったいないので、Google Apps の環境でも従来のように自由にホームページを公開するため、Google App Engine (GAE)を利用する方法を考えてみた。app.yaml ファイルを static_files や static_dir のような静的ハンドラだけで定義してしまうやり方である。

例えば top_dir ディレクトリを GAE 用アプリケーションのトップディレクトリとして、HTML ファイルやイメージファイルなどを次のように配置したとする。

top_dir/app.yaml
top_dir/static_dir/img/logo.png など
top_dir/static_dir/index.html など

この例の場合であれば app.yaml を次のよう定義する。

application: your-app-id
version: 1
runtime: python
api_version: 1

handlers:

– url: /img
  static_dir: static_dir/img

– url: /
  static_files: static_dir/index.html
  upload: static_dir/index.html

– url: /(.*)
  static_files: static_dir/\1
  upload: static_dir/(.*)

このようにしてから appcfg.py update top_dir コマンドを実行すれば、HTML ファイルなどがデプロイされる。あらかじめ Python と GAE SDK がインストールされていれば、GAE のことを意識せずに ftp のような感覚でファイルの更新ができると思う。この場合 Python は appcfg.py コマンドを実行するためだけに使われる。

デプロイしたものに your-app-id.appspot.com でアクセスできることを確認したら、Google Apps のダッシュボードで GAE アプリケーションを追加して適当な URL を割り振れば、Google Apps 環境だけで自由なデザインのホームページを公開することができる。

実際にこのやり方で作ってみたのが次のページ。ここでは teshigoto-lab.net というドメインで Google Apps を利用している。

Google Apps を使ってみよう!(http://www.teshigoto-lab.net/)

ちなみに同じようなページを Google Apps 標準の「サイト」機能でも作ってみた。こちらは favicon.ico が Google Apps オリジナルデザインのものになっている。

「サイト」版 Google Apps を使ってみよう!(http://google-apps.teshigoto-lab.net/)

「サイト」版は途中で面倒になってしまい、スタイル適用や画像ファイルへのリンク設定をしていない。したがって実際はもう少しまともなデザインにすることができるはずだ。

このサンプルページのようにシンプルなデザインであれば「サイト」機能だけでも何とか出来そうだが、もっと凝ったものになってくると GAE を使ったほうが楽だろうと思う。また、GAE には履歴管理機能があるので、これを使って複数リビジョンのホームページを簡単に切り替える、といったことも可能になる。

ところで最近、Google 社のサイトにおいて Standard Edition 用の申込み画面を見つけるのが極めて困難になっている。以前はそれほど深くない階層のところに他の Edition との機能比較表が掲載されていて、そこから簡単に申込み画面へ行き着けたのだが、その比較表は見つけられなくなってしまった。現状ではあたかも有料の Premium Edition しか存在しないように見える作りになっていて、一旦は Premium Edition の申込みボタンを押してからでないと Standard Edition の申込み画面に行き着けないようだ。

恐らく Premium Edition に比重を移して、Standard Edition は廃止の方向に持って行くつもりなのだろう。それは仕方がないことだと思う。しかし機能制限があっても構わないので、Standad Edition よりも安価(2,000円/1アカウント・1年くらいか?)な Edition も用意してもらえるとうれしい。

Amazon EC2/S3 の使用感

Amazon EC2/S3 を使ってみた雑感をまとめておく。今回は何らかのシステムを作るための開発環境として利用することを想定した。AMI には Amazon が提供している fedora8 を導入してから、必要なパッケージなどを追加した。Python と Django はソースコードからインストールしている。

AMI の導入はそれほど難しいわけではないが、慣れるまで手順が煩雑に感じた。導入の手順については多くの先駆者達が貴重な情報をブログなどで提供してくれている。これらにはずいぶんとお世話になった。感謝。一方、Amazon の公式ドキュメント“Getting Started Guide”, “Developer Guide”)もしっかりとしているので、導入作業を実施するときは、公式ドキュメントをメインのテキストにしながら、Web からの情報をサブテキストとして使うようにするのが早道だと思う。

AMI は Amazon が公式に提供しているものに加えて、コミュニティベースで配布されるものが多数ある。しかし、自分の目的に合ったものを探すのは困難である。仮に適当なものを見つけたとしても、出所が分からないとセキュリティなどの面からも不安が拭えない。結局、RedHat のような有償のものを利用するか、自分の手で AMI そのものも作ってしまうのが良いと感じた。AMI の作り方は前述の公式ドキュメントにも記載されている。今回は AMI の自作までは試みていないが、次の機会にはぜひとも挑戦したい。

サーバへの接続作業は ssh 端末を介して行ったが、キー入力に対するレスポンスがややもったりとした印象だった。もっともリモート環境へのアクセスとしてはこんなものだろう。今回はサービス提供用の公開サーバではなく、開発環境として使うことを想定して試用した。そのため毎日インスタンスの開始と終了を繰り返すことになる。当然、終了時には必ずイメージを S3 にバックアップすることになる。しかもバックアップ後には必ず AMI の再登録作業が必要になる。こういった一連の操作が意外と手間で時間も掛かった。これらの作業はスクリプトを書けばもう少し自動化できると思うが、それでも開発環境として常用するかどうかは判断に迷うところだ。また、終日運用を前提とする公開用のサーバ環境として使えるかどうかは、この試用の結果だけからは判断できない。ただ、サーバマシンとしては通常のものと同じように使えていたので、公開サービスに対する負荷にどこまで耐えられるのか、といったあたりが導入判断のポイントになるのだろう。

参考:
Python のアップグレードに伴う問題
Amazon EC2 の ec2-upload-bundle と ec2-register
Django の開発用 Web サーバを Amazon EC2 で動かす
Amazon EC2 で ec2-regist を忘れる

Google App Engine 用のログイン認証機能を作ってみた

Google App Engine では Google アカウントの認証機能がそのまま利用できるので、ログイン管理の手間が掛からない。しかし、当然のことながらアプリケーションの利用者は Google アカウント保持者に限定されてしまうし、逆に何も制限を加えないと Google アカウント保持者は誰でもアクセスできてしまうことになる。

そこで Google アカウントとは無関係にアカウントを管理する仕掛けのひな形を作ってみた。サンプルは http://teshigoto-showcase-02.appspot.com/ で実際に稼働している。ここで新規登録を行えばアカウントを取得することができるが、試用アカウントを使えば新規登録しなくてもログインすることができる。試用アカウントはサンプルサイトのトップページに記載してある。また、ソースコードは http://www.teshigoto.net/showcase.html の「Another Loin Utility – GAE case study 2」に置いた。

アカウントの新規登録を行うとき、同一ログイン名の同時登録を避けるため、ファイルを使ったロック処理を行おうとしたが、Google App Engine では肝心の fcntl を利用できない。そこで今回は登録依頼のあったアカウントを無条件に Datastore に格納してしまい、その後改めて同一のログイン名による検索を行って複数のエンティティが見つかったときは、自分自身を削除して「同じログイン名がすでに登録されてます」メッセージを出す、という手順にしてみた。具体的には次のような感じ。

new_user = users.Users(id = new_login_id, ...)
new_user.put()

query = users.Users.all()
query.filter('id =', new_login_id)

count = 0
for user in query:
    count += 1

if count == 1:
    #  regist copleted
    pass
else:
    # duplicated id
    new_user.delete()

このやり方だと同じログイン名を同時に登録しようとして、どちらも失敗する可能性が残るが、一般的なログイン名ではそれでも構わないだろうと判断した。

ログインすればセッション管理も必要になるので、これも作ってみた。前回公開したサンプルでもセッション管理を作ったものの中途半端だったので、もう少し手を入れてみた。セッション ID を Cookie として送信するために準備する機能(送信そのものは画面表示モジュールが行うことになる)や、セッション継続時に保存しておくデータを Datasore に格納する機能などがある。

import os
import re
import time
import random
import hashlib

from google.appengine.ext import db


class SessionDb(db.Expando):
    sid = db.StringProperty()


DEFAULT_SID_NAME = 'alu_001'

class Session():

    def __init__(self, req, res, sid_name=DEFAULT_SID_NAME):
        self.sid_name = sid_name
        self.req = req
        self.res = res
        if sid_name in req.cookies:
            self.sid_value = req.cookies[sid_name]
        else:
            self.sid_value = ''

    def new_ssn(self, ssl=False):
        random.seed()
        random_str = str(random.random()) + str(random.random())
        random_str = random_str + str(time.time())
        random_str = random_str + os.environ['REMOTE_ADDR']

        self.sid_value = hashlib.sha256(random_str).hexdigest()

        cookie_val = self.sid_name + '=' + self.sid_value
        if ssl:
            cookie_val += ';secure'

        self.res.headers.add_header('Set-Cookie', cookie_val)

        ssn_db = SessionDb(sid=self.sid_value)
        ssn_db.put()

    def destroy_ssn(self):
        ssn_db = SessionDb.all()
        ssn_db.filter('sid =', self.sid_value)
        ssn = ssn_db.fetch(1)
        db.delete(ssn)

        expires = time.strftime("%a, %d-%b-%Y %H:%M:%S GMT", time.gmtime(0))
        cookie_val = self.sid_name + '=null' + ';expires=' + expires
        self.res.headers.add_header('Set-Cookie', cookie_val)

    def get_ssn_data(self, k):
        ssn_db = SessionDb.all()
        ssn_db.filter('sid =', self.sid_value)
        ssn = ssn_db.fetch(1)

        return ssn[0]._dynamic_properties[k]

    def set_ssn_data(self, k, v):
        ssn_db = SessionDb.all()
        ssn_db.filter('sid =', self.sid_value)
        ssn = ssn_db.fetch(1)
        ssn[0]._dynamic_properties[k] = v

        ssn[0].put()

    def chk_ssn(self):
        ssn_db = SessionDb.all()
        ssn_db.filter('sid =', self.sid_value)
        count = 0
        for i in ssn_db:
            count += 1

        if count == 1:
            return True
        else:
            return False

さらに、今回のサンプルでも多言語対応を試みた。前回はオリジナルのちょっと安直な方法で実装したが、今回は gettext を利用してみた。これによって言語リソースを完全に Python のソースコードと分離することができた。また、表示言語を固定せずに、利用者からの指示で動的に言語を切り替えられるようにした。具体的には Python ライブラリリファレンス「6.28 gettext — 多言語対応に関する国際化サービス」を参考にしながら、おおよそ次のような流れで処理を行っている。

locale_path = os.path.dirname(__file__) + '/../locale'   # リソースファイルを置いた場所
supported_lang = ['ja', 'en']    # サポートする言語の一覧
for lang_name in self.supported_lang:
    lang[lang_name] = gettext.translation('resource', locale_path, languages=[lang_name])

accept_lang = 'ja'   # 実際の表示言語をここで指定
lang[accept_lang].install()
_ = lang[accept_lang].gettext

print _('message_sentence')    # 指定した言語で表示される

Google App Engine のサンプルプログラム

遅ればせながら Google App Engine のサンプルプログラムを作ってみた。簡単なアドレス帳のようなもので、Google App Engine のサイトにあるチュートリアルと同程度のものである。画面インタフェースはきわめて質素で CSS や JavaScript はほとんど使っていない。ただ、本格的なアプリケーションを作ろうとするときのテンプレートとしても利用できるようファイル分割に考慮した。また、簡単なセッション管理機能と多言語対応機能も試作してみた。

Google サーバのここ( http://teshigoto-showcase-01.appspot.com/ )で実際に試用することができる。ただしログイン認証のために Google アカウントが必要である。またソースコードはここ( http://www.teshigoto.net/showcase.html )に置いてある。

次はもう少し実践的で実運用にも耐えるようなものを作ってみたい。