ぬきポンのWeb技術関連のメモ

今週も、横浜のコワーキングスペース「タネマキ」で、 GAE/Pの勉強会を実施しました。

勉強会の中で、webapp2の公式ドキュメントを読み解く会を継続して実施しています。

本日は、こちらから。 

■Debug flag  

debugをFalseに設定すると、500の際にクライアントにstack traceが出なくなる。

Trueに設定すると、stack traceが出る。 

App Engineでは、以下の記載をすることで、開発環境とプロダクション環境を判断することができる。

実際にSDKので起動した場合には、Development/2.0が入っている。 

import os

import webapp2

debug = os.environ.get('SERVER_SOFTWARE', '').startswith('Dev')

app = webapp2.WSGIApplication(routes=[
    (r'/', 'handlers.HelloWorldHandler'),
], debug=debug)

もし、アプリの中でdebugフラグを取得したい場合には、 

app = webapp2.get_app()
debugFlg = app.debug

で取得出来そう。

続きを読む...

今週も横浜のコワーキングスペース「タネマキ」で、GAE/Pを中心とした勉強会を実施しました。今回も２名でした。

先週に引き続き、前半はwebapp2公式ドキュメントを読み解く会を実施しました。

今回は、Config,Registry,Error handlersの部分です。

いつも通り、英語は殆ど分からないので、読解力にはかなりの不安があります。。

1. Config
   Configは、ディクショナリ形式で、モジュール全体で共有できる。
   以下のソースは、公式サイトから転載
   ・configの設定
   

   import webapp2
   
   config = {'foo': 'bar'}
   
   app = webapp2.WSGIApplication(routes=[
       (r'/', 'handlers.MyHandler'),
   ], config=config)
   

   ・configの使用方法
   

   import webapp2
   
   class MyHandler(webapp2.RequestHandler):
       def get(self):
           foo = self.app.config.get('foo')
           self.response.write('foo value is %s' % foo)
   

   僕の場合は、config.pyやcommon.pyを作って共通設定を書いているので、あまり使いドコロが分からなかったのですが、この設定は、「モジュール単位」に設定が出来るようです。当サイトでも、公開画面と管理画面でモジュールを分けていて、管理画面はadmin権限でのアクセスを設定しています。このような場合に、webapp2のconfigを設定しておくと、classを共有していた場合に、configの値を参照することで振る舞いを切り分けることが出来そうです。

2. Registry
   

   インスタンス間を跨った、アプリケーション全体での共有ディクショナリのようです。
   以下のソースは、公式サイトから転載

   import webapp2
   
   def get_parser():
       app = webapp2.get_app()
       # Check if the instance is already registered.
       my_parser = app.registry.get('my_parser')
       if not my_parser:
           # Import the class lazily.
           cls = webapp2.import_string('my.module.MyParser')
           # Instantiate the imported class.
           my_parser = cls()
           # Register the instance in the registry.
           app.registry['my_parser'] = my_parser
   
       return my_parser
   

   シングルトン的な使い方が可能な感じですかね。使い方としては、GAEのmemcacheと同じ考え方のようです。先にRegistryから取得してみて、取得出来ない場合には生成する処理を実施し、Registryにセットする。

   ただ、GAEの場合は、スピンダウンが割りと頻繁に起こると思いますので、memcacheを利用するのが正解の様な気がします。

3. Error handlers

   WISGアプリケーションとしてのエラーハンドリングの方法ですね。httpのresponseを制御する為の方法で、ドキュメントでも、404,500はハンドリングした方が良いと書いてあるようです。

   以下のコードも、公式ドキュメントからの転載です。

   import logging
   
   import webapp2
   
   def handle_404(request, response, exception):
       logging.exception(exception)
       response.write('Oops! I could swear this page was here!')
       response.set_status(404)
   
   def handle_500(request, response, exception):
       logging.exception(exception)
       response.write('A server error occurred!')
       response.set_status(500)
   
   app = webapp2.WSGIApplication([
       webapp2.Route(r'/', handler='handlers.HomeHandler', name='home')
   ])
   app.error_handlers[404] = handle_404
   app.error_handlers[500] = handle_500
   

   使い方は、コードを見ればわかると思いますが、logging.exception(exception)は、loggingの特別な出力方法のようです。これで、stack traceが出力できます。response.set_status(404)は、固定でコードを入れるのがイマイチな場合は、response.set_status(exception.code)とすると、受け取ったレスポンスコードがセットできるようです。僕が使うときは、面倒なので404と403を同じ404の画面を返しているのですが、コードは、403のまま返したい時などに利用できそうです。

１人でやっている時は、なかなか読み切れず、とりあえず動けばよい程度で使っていますが、頑張って呼んでみると色々分かってきて面白いですね。

The WSGI application 

続きを読む...