今日のPython

VSCode で TypeScript のデバック設定

2018-09-15T20:05:00.000+09:00

VSCode (Visual Stadio Code)　で TypeScript デバックするための設定は、ネット上で情報がたくさんあるのですが、なぜか少しずつ違っています。そして、動作しなかったりします。

今回は、単純なコードをデバックできるだけの設定をメモ書きします。

事前準備

Visual Stadio Code、TypeScript、Node.js がインストールされていることを確認します。

VSCode バージョン確認

$ code -v
1.27.1
5944e81f3c46a3938a82c701f96d7a59b074cfdc
x64

syntax2html

TypeScript バージョン確認

$ tsc -v
Version 3.0.3

syntax2html

Node.js バージョン確認

$ node -v
v10.10.0

syntax2html

確認できない場合、インストール作業を行ってください。インストール方法はネット上でいろいろ説明がありますが、次のページなどを参考にしてください。
TypeScriptチュートリアル① -環境構築編-

もしインストール中にVSCodeを開いていたら、一旦終了し開き直したほうが良いでしょう。

今回のサンプル用として、次のコードを使用します。

class Startup {
    public static main(): number {
        console.log('Hello World');
        return 0;
    }
}
Startup.main();

syntax2html

ファイル名 sample.ts とします。

コンパイル設定

TypeScriptのコードをデバックするためにはコードをコンパイルし、JavaScriptファイル（xxx.js）とソースマップファイル（xxx.map）を生成する必要があります。もちろん手動でコンパイルしても大丈夫ですが、せっかくなので、VSCodeに自動でコンパイルさせるための設定をします。

コンパイルオプション指定
コンパイルオプションの設定ファイル（tsconfig.json）を作成します。tsconfig.json は TypeScript のファイルで、プロジェクトのルートディレクトリに置きます。
新規にファイルを作成し、次のように記述します。最後に、tsconfig.json という名前で保存します。
```
{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "sourceMap": true
    }
}
```
syntax2html
"sourceMap": true によってコンパイル時、ソースマップファイルが生成されます。
この設定でコンパイルが実行可能かと思います。
VSCode メニューの「ターミナル」→「ビルドタスクの実行」→「tsc:ビルド」を選択すると、 js及びmapファイルが生成されるのが確認できます（「tsc:ウォッチ」を選択するとタスクが常駐し、tsソースが保存される度にコンパイルが実行されます）。

VSCode タスク設定

VSCodeから条件に応じて、処理を実行する機能が「タスク」です。今回はデバック時に事前に、TypeScriptコードをコンパイルするためのタスクを設定します。
タスク設定には幾つも方法があるようですが、例えば次のようにします。

メニューの「ターミナル」→「タスクの構成」→「テンプレートからtasks.jsonを生成」を選択し、「tsc:ビルド」を選んで tasks.json を生成させます。

「コマンドパレット」に、 >tasks configure task と入力してもタスク構成にアクセス可能です。
要は、.vscode/tasks.json を生成することが必要な訳です。

生成したtasks.jsonファイルの内容は以下の通りですが、特にコードの変更は必要ありませんが、label で名前（８行目）だけ付けておきます。

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "type": "typescript",
            "label": "tsc",
            "tsconfig": "tsconfig.json",
            "problemMatcher": [
                "$tsc"
            ]
        }
    ]
}

syntax2html

以上で、デバック構成設定前の準備が完了です。

余談ですが、TypeScriptのコードはコンパイルしなくても実行可能です。その場合、右クリックメニューの「Run Code」で実行できますが、事前に ts-node モジュールをインストールしておく必要があります。
ターミナルから次のようにインストールします。

$ npm install -g ts-node

syntax2html

デバッグ設定

デバックでは構成ファイル（launch.json）を準備する必要があります。

VSCodeのメニューの「デバック」→「構成を開く」を選択し、「Node.js」を選ぶと launch.js が生成されます。

「コマンドパレット」に、 >debug open launch.json と入力しても同様な事が可能です。

生成された launch.json のコードです。

{
    // IntelliSense を使用して利用可能な属性を学べます。
    // 既存の属性の説明をホバーして表示します。
    // 詳細情報は次を確認してください: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "プログラムの起動",
            "program": "${workspaceFolder}/sample.ts",
            "outFiles": [
                "${workspaceFolder}/**/*.js"
            ]
        }
    ]
}

syntax2html

これを次のように変更します。

{
    // IntelliSense を使用して利用可能な属性を学べます。
    // 既存の属性の説明をホバーして表示します。
    // 詳細情報は次を確認してください: ....
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "プログラムの起動",
            "preLaunchTask": "tsc",
            "program": "${workspaceFolder}/${fileBasenameNoExtension}.ts",
            "smartStep": true,
            "outFiles": [
                "${workspaceFolder}/**/*.js"
            ]
        }
    ]
}

syntax2html

変更は三点です。

preLaunchTask （１１行目）: デバッグセッションの開始前に起動するタスクを指定します。
ここでは先程コンパイル設定で作成したタスクのラベル名("tsc")を指定します。
program （１２行目）: デバッガを起動するときに起動する実行可能ファイルを指定します。
自動生成されコードでは特定のファイル名を指定していましたが、${fileBasenameNoExtension} という記述に変更しました。${fileBasenameNoExtension} は現在開いているファイル名から拡張子を除いた文字列を返します。つまり、作業ディレクトリ上なら任意のソースファイルをデバックできることになります。
smartStep （１３行目）: true の場合、マップファイル対象外のコードのステップを省略します。デバック中変な js コードが表示されたりしますが、それを省きます。ただ完全ではないようです。状況に応じて、"skipFiles" パラメータでスキップするソースを指定することが必要かもしれません。

preLaunchTask の設定ではなく、コンパイル設定でも紹介した、VSCode メニューの「ターミナル」→「ビルドタスクの実行」→「tsc:ウォッチ」でも同じように変更時にコンパイルされます（VSCode起動時にウォッチを実行する必要はありますが・・・）。

デバック実行とその他

以上でVSCodeの設定が完了したので、デバックを実行してみます。
一応、動作するのが確認できました。

この他に、TypeScriptファイルとJavaScriptファイルが同じディレクトリにありますが、それぞれ別のディレクトリに配置する設定を考えてみます。

TypeScriptファイルは src に、JavaScript と map ファイルは build に配置します。
まず tsconfig.json ですが、次のように、outDir パラメータでコンパイル時の出力先を指定します（６行目）。

1 2 3 4 5 6 7 8	{ "compilerOptions": { "target": "es5", "module": "commonjs", "sourceMap": true, "outDir": "build" } }
	syntax2html

次に launch.json ですが、program パラメータに TypeScriptファイルのディレクトリを（１３行目）、outFilesにJavaScriptのディレクトリを指定します（１６行目）。

{
    // IntelliSense を使用して利用可能な属性を学べます。
    // 既存の属性の説明をホバーして表示します。
    // 詳細情報は次を確認してください: ....
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "プログラムの起動",
            "preLaunchTask": "tsc",
            "program": 
                "${workspaceFolder}/src/${fileBasenameNoExtension}.ts",
            "smartStep": true,
            "outFiles": [
                "${workspaceFolder}/build/**/*.js"
            ]
        }
    ]
}

syntax2html

以上で、ディレクトリを分けてもデバックが動作すると思います。

参考：
VSCode + Typescript でデバッグを有効にする
 VisualStudioCode + TypeScript でブレークポイントが効かなかった問題（解決）
Visual Studio Code (VS Code) の非公式日本語訳
 Visual Studio Code Docs
第2回　Visual Studio Codeのデバッグ構成ファイルの基本：Node.js編

Datastore と組み込みインデックス

2017-11-17T05:33:00.001+09:00

GoogleCloudFlatform（GoogleAppEngine）のNoSQLデータベースである、Datastoreを使用していると、奇妙なことに気づくと思います。それは、想定していた保存データ量に比べて、課金時に算出されたデータ量が大幅に多いという点です。ここで、Datastoreの料金を示してみます。

※ 米国／ヨーロッパ - Cloud Datastore 料金と割り当て

	1 日あたりの無料利用枠	無料利用枠を超えた場合の料金（単価）	料金
保存データ	1 GB ストレージ	$0.18	GB/月
エンティティの読み込み数	50,000	$0.06	/10 万エンティティ
エンティティの書き込み数	20,000	$0.18	/10 万エンティティ
エンティティの削除数	20,000	$0.02	/10 万エンティティ
小規模な操作	無制限	無料	-

料金的には読み込み数や書き込み数の方が通常は大きいと思いますが、いつの間にか保存データが何十GB・何百GBとなり、課金されている場合があります。

保存データが増大する要因

アプリケーションの設計時に、事前にデータ量を推定していると思います。しかし何十・何百GBと、想定外のデータが増えるのでしょうか？。一例を挙げてみましょう。

あるエンティティのデータ使用状況（データストア・ダッシュボード）です。全体で８０MBを使用していますが、エンティティ（実データ）は、１０MBしかありません。残り７０MBを使用しているのが、組み込みインデックスと呼ばれるデータです。

GoogleCloudPlatformのドキュメントには、次のように記述されています。

インデックスは次の 2 種類に分けられます。

組み込みインデックス

デフォルトでは、エンティティの種類ごとに各プロパティのインデックスが自動的に事前定義されます。このような単一プロパティのインデックスは単純な種類のクエリに適しています。

複合インデックス

複合インデックスでは、インデックス付けされたエンティティごとに複数のプロパティ値がインデックス付けされます。複雑なクエリをサポートする複合インデックスは、インデックス設定ファイル（index.yaml）で定義されます。

参考：インデックス

組み込みインデックスは複合インデックスとは違い、自動で生成されるインデックスです。しかし、実データの７倍ものデータ（このデータの場合）を生成するのも問題ですね。

組み込みインデックスを生成しない

組み込みインデックスを生成しないためには、エンティティ定義時にプロパティのパラメータとして、indexed=False を設定すればよいです。

You declare a property unindexed by setting indexed=False in the property constructor:
class Person(db.Model):
  name = db.StringProperty()
  age = db.IntegerProperty(indexed=False)
You can later change the property back to indexed by calling the constructor again with indexed=True:
class Person(db.Model):
  name = db.StringProperty()
  age = db.IntegerProperty(indexed=True)
参考： Cloud Datastore Indexes

NDBでモデル定義する場合は、次のようにプロパティのパラメータとして記述します。indexed=Falseを記述しない場合は、indexed=Trueの見做され、インデックスが生成されます。

class Person(db.Model):
  name = db.StringProperty()
  age = db.IntegerProperty(indexed=False)

syntax2html

pydal（web2pyフレームワーク)で記述する場合は、フィールドのcustom_qualifierパラメータに辞書形式で指定します。指定しない場合は、インデックスが生成されます。

db.define_table('person',
    Field('name'),
    Field('age', 'integer', custom_qualifier={'indexed':False}))

syntax2html

組み込みインデックス設定の注意点

組み込みインデックスを生成しないという indexed=False は、どのプロパティ（フィールド）に対して設定してよいという訳ではありません。
組み込みインデックスは、クエリのフィルタ（条件）や単純なソートで必要です。このためアプリケーションで、該当するプロパティがクエリのフィルタやソートに使用していないか確認する必要があります。もしインデックスが無いのにアプリケーションで使用すると、次のようなエラーがログに記録されます。

BadFilterError: invalid filter: Cannot query for unindexed property xxxxxxx.

複合インデックスの場合、index.yamlをデプロイすれば自動にインデックスを再構築します。しかし組み込みインデックスの場合、indexed=False と変更しデプロイしても、インデックスが削除される訳では無いようです。
組み込みインデックスを削除するには、モデルの既存のエンティティ全ての更新処理が必要です。
このため、インデックス削除による保存データ課金額のコスト削減効果と、全エンティティの更新処理でのコスト（インスタンス・エンティティ読み込み・エンティティ書き込みの各課金額）を比較し吟味する必要があります。

最初にサンプルとして示したエンティティですが、組み込みインデックスが不必要なプロパティに indexed=False と設定し、更に全エンティティの更新処理をした結果、次のように変化しました。

１・２・４番目のプロパティの組み込みインデックスがゼロになっています。３番めのプロパティは検索条件に使用しているため、indexed=True になりインデックスはそのままです。これでも保存データは６割削減されました。

複合インデックスも整理

複合インデックスでも、不要なインデックスをチェックしましょう。
index.yaml の記述を見て、使用していないインデックスを記述から除外します。その後、index.yaml をデプロイします。
appcfgコマンドの時代は、アプリをデプロイすると自動的に index.yaml も更新されましたが、gcloudでは自動更新されません。次のように index.yaml をデプロイするためのコマンドを発行する必要があります。

gcloud app deploy index.yaml

syntax2html

その後、index.yaml から除外されたインデックスをアプリからクリーンアップする必要があります。コマンドは次の通りです。

gcloud datastore cleanup-indexes index.yaml

syntax2html

以上です。今回は Datasoreのデータ使用量削減という観点から、記事を書いてみました。

Python3 と web2py 、SQLEDITABLE

2017-07-16T23:37:00.000+09:00

ちょっと前に、web2py 2.15.1 が公開されましたが、このバージョンからは試験的に Python3 に対応しています。

web2py Download

また、これに合わせて、SQLEDITABLE もPython3に対応しました。

SQLEDITABLE version 0.30

Python3移行の注意点　ZIP・MAP組み込み関数

2017-07-12T15:36:00.000+09:00

Python2のサポートは２０２０年までだそうです。Python3に関しては私は殆ど使用してこなかったのですが、最近環境も揃ってきたような気もします。このタイミングで、プラグイン・ライブラリのPython3への移行作業してみました。

作業自体は一日程度で終わりました。また移行したライブラリのPython2.7での動作は何も問題が無く、後方互換性もバッチリで感心しました。

今回はPython3向け修正作業で感じた、ZIP・MAP組み込み関数の注意点について記事にします。

ZIP関数、Python2での動作

まずPython2での動作を見てみます。

>>> zip([1,2,3],[4,5,6],[7,8,9])
[(1, 4, 7), (2, 5, 8), (3, 6, 9)]

３つのリストを一つのリストに変換しています。

また、For文やリスト内包表記を使ってみます。

>>> z = zip([1,2,3],[4,5,6],[7,8,9])
>>> for i, j, k in z:
...     print i, j, k
1 4 7
2 5 8
3 6 9
>>> [(i, j+k) for i, j, k in z]
[(1, 11), (2, 13), (3, 15)]

とくに問題なく、動作します。

ZIP関数、Python3での動作

同様にZIP関数をPython3で動作させてみます。

>>> zip([1,2,3],[4,5,6],[7,8,9])
<zip object at 0x10d6968c8>

なんと、zipオブジェクトが返ってきました。

For文やリスト内包表記を試してみます。

>>> z = zip([1,2,3], [4,5,6], [7,8,9])
>>> for i, j, k in z:
...     print(i, j, k)
1 4 7
2 5 8
3 6 9
>>> [(i, j+k) for i, j, k in z]
[]

For文は実行できましたが、リスト内包表記は空のリストが返ってきただけでした。

zipオブジェクトというのは、ジェネレータと同様の遅延評価の機能を持っているそうですが、複数回の利用はできないみたいです。

ZIP関数をPython2と同様の動作に記述するには

Python3で動作させるには、工夫が必要です。３つ案があります。

【案１】同じ記述を２つする

>>> for i, j, k in zip([1,2,3], [4,5,6], [7,8,9]):
...     print(i, j, k)
1 4 7
2 5 8
3 6 9
>>> [(i, j+k) for i, j, k in zip([1,2,3], [4,5,6], [7,8,9])]
[(1, 11), (2, 13), (3, 15)]

zipオブジェクトは遅延評価なので、２つ記述してもオーバヘッドは無いようです。

【案２】リストやタプルに変換する

>>> z = list(zip([1,2,3], [4,5,6], [7,8,9]))
>>> for i, j, k in z:
...     print(i, j, k)
1 4 7
2 5 8
3 6 9
>>> [(i, j+k) for i, j, k in z]
[(1, 11), (2, 13), (3, 15)]

【案３】itertools.teeを使用

>>> import itertools
>>> z = zip([1,2,3], [4,5,6], [7,8,9])
>>> z1, z2 = itertools.tee(z)
>>> for i, j, k in z1:
...     print(i, j, k)
1 4 7
2 5 8
3 6 9
>>> [(i, j+k) for i, j, k in z2]
[(1, 11), (2, 13), (3, 15)]
>>>

itertools.teeで、一つのイテレータからN個の独立したイテレータを返すことができます。
参考： itertools.tee(iterable, n=2)

他にもあるかもしれませんが、取り敢えず、これだけ挙げてみました。

MAP関数、Python3での動作

Python3では、MAP関数もZIPと同様の動作になります。

>>> map(lambda i,j,k: (i, j+k) , [1,2,3], [4,5,6], [7,8,9])
<map object at 0x10d69a2e8>

>>> z = map(lambda i,j,k: (i, j+k) , [1,2,3], [4,5,6], [7,8,9])
>>> for i in z:
...     print(i)
(1, 11)
(2, 13)
(3, 15)
>>> [i for i in z]
[]

また、Python2 では最初の引数に None を指定すると、最大の配列数に長さを合わせて結合してくれました。しかし、Python3では使用するとエラーになります。

Python2

>>> map(None, [1,2,3], [4,5], [7])
[(1, 4, 7), (2, 5, None), (3, None, None)]

Python3

>>> list(map(None, [1,2,3], [4,5], [7]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callable

MAP関数をPython2と同様の動作に記述するには

MAP関数も、ZIP同様の解決策を適用可能です。

【案１】同じ記述を２つする

>>> for i in map(lambda i,j,k: (i, j+k) , [1,2,3], [4,5,6], [7,8,9]):
...     print(i)
(1, 11)
(2, 13)
(3, 15)
>>> [i for i in map(lambda i,j,k: (i, j+k) , [1,2,3], [4,5,6], [7,8,9])]
[(1, 11), (2, 13), (3, 15)]

【案２】リストやタプルに変換する

>>> z = list(map(lambda i,j,k: (i, j+k) , [1,2,3], [4,5,6], [7,8,9]))
>>> for i in z:
...     print(i)
(1, 11)
(2, 13)
(3, 15)
>>> [i for i in z]
[(1, 11), (2, 13), (3, 15)]

【案３】itertools.teeを使用

>>> import itertools
>>> z = map(lambda i,j,k: (i, j+k) , [1,2,3], [4,5,6], [7,8,9])
>>> z1, z2 = itertools.tee(z)
>>> for i in z1:
...     print(i) 
(1, 11)
(2, 13)
(3, 15)
>>> [i for i in z2]
[(1, 11), (2, 13), (3, 15)]

参考： itertools.tee(iterable, n=2)

【案４】 itertools.zip_longestを使用
Python2の map(None, [1,2,3], [4,5], [7]) と同じ動作をさせる方法ですが、 itertools.zip_longest を使うと良いそうです。

>>> import itertools
>>> list(itertools.zip_longest([1,2,3], [4,5], [7]))
[(1, 4, 7), (2, 5, None), (3, None, None)]

itertools.zip_longest も、ZIP関数同様の遅延評価のイテレータです。
参考：itertools.zip_longest

最後に

ZIPやMAP関数の動作の違いは、Python2のコードをPython3で動かしたらエラーになる訳ではないので、発覚しにくいです。仕様の違いを知らないと悩むことになるので、気を付けたいですよね。

参考
Cannot unpack a zip object multiple times
Python 3 vs Python 2 map behavior

GAE環境下でのペンドリングとデプロイ

2017-07-09T18:54:00.003+09:00

前回記事（GAE環境下での Echoフレームワークのエラー）で、EchoフレームワークはGAE（GoogleAppEngine）環境下ではバージョン指定をするという話を書きました。今回は続編で、Go言語の機能であるベンドリング（vendoring）を利用し、もっと簡単にパッケージ管理を行います。さらにベンドリング使用時、GAEデプロイに関する注意点も書いていきます。

ベンドリングと Glide

ペンドリング（Vendoring）は、プロジェクト毎の外部ライブラリを管理する仕組みです。Go言語バージョン1.5から利用可能になりました。

簡単に解説すると、プロジェクトのディレクトリに vendorというディレクトリを作成し、vendor下にプロジェクトで使用する外部ライブラリーを配置します。これにより利用するライブラリを、プロジェクト毎に管理することができます。

このペンンドリングを簡単に管理できる、パッケージ管理ツールが幾つかあります。有名なツールを挙げます（☆はgithubの星の数）。

Godep ☆４７４０
GB ☆１９５７
Glide ☆４８８１
Govendor ☆２１３２

最も有名なのは Godep のようです、Go言語がベンドリングに対応する前からあるそうです。古いので環境を汚したりとか、最近あまり更新されない等あるそうです。そして最も人気なのは、Glide です。機能範囲も最も大きいいようです。今回は Glide を使用します。
参考：Go Package Manager Comparison

Glideの使用方法は、いろいろなところで解説されています。詳しい解説は、そちらを参考にしてください。

参考
Go言語 / golang 入門必見!! パッケージ管理ツール Glideの使用方法を詳しく解説
 【GO言語のパッケージ管理：決定版】「Glide」を使ってみよう

まず Glideをインストールします。マシンはMacですので、brew でインストールします。

$ brew install glide

次にGlideの設定ファイル（glide.yaml）を作成するため、プロジェクトのディレクトリで次のコマンドを実行します。

$ glide create

実行すると、いろいろ設定ウィザードが表示されます。取り敢えず最初のウィザードで No（N）を選ぶと、プロジェクトを検索し依存関係を記述した glide.yaml を生成します。生成した glide.yaml は、次のようになります。

package: sample
import:
- package: github.com/labstack/echo
  subpackages:
  - middleware

ここで、依存するパッケージは github.com/labstack/echo　なのを確認します。またバージョンを 3.0.2 に指定する必要があるので、次のようにversionを記述します。

package: sample
import:
- package: github.com/labstack/echo
  version: 3.0.2
  subpackages:
  - middleware

vendorディレクトリを作成し、依存するライブラリをインストールします。

$ glide install

ライブラリはインストールされましたが、指定したバージョンはまだインストールされていません。ここでライブラリのアップデートを行います。

$ glide up

これによって、バージョン3.0.2が設定されました。

ペンドリング使用時のプロジェクトの位置

GAEのベンドリング使用時、プロジェクトのディレクトリは GOPATH 配下に設置する必要があります。GOPATH下でない場合、vendorディレクトリが GAEのSDKで認識されないようです。

※ プロジェクト下のファイルは、EchoフレームワークのGAEレシピで紹介されたサンプルです（Google App Engine Recipe）。
プロジェクトのディレクトリでターミナルを開いて、ローカル開発用サーバを起動してみましょう。

$ dev_appserver.py app.yaml

エラー無く、稼働できることを確認できると思います（EchoフレームワークのGAEレシピのサンプルデータ一覧URLは、http://localhost:8080/users になります）。

GAEへのデプロイ

GCLOUDコマンド（参考：Google Cloud SDK への移行）で、ベンドリングしたアプリをGAEにデプロイしようとするとエラーで処理が止まります。具体的には次のようなエラーが表示されます。

$ gcloud app deploy app.yaml --version 1
Services to deploy:
:::: 省略 :::::
Updating service [default]...failed.                                                                                             
ERROR: (gcloud.app.deploy) Error Response: [9] Deployment contains files that cannot be compiled: Compile failed:
2017/07/08 18:00:00 go-app-builder: Failed parsing input: parser: bad import "syscall" in vendor/golang.org/x/sys/plan9/env_unset.go

このエラーに関しては、GAEの設定ファイル（app.yaml）に次のようにデプロイしないライブラリを指定すると良いそうです。

nobuild_files:
- vendor

参考：golang環境でFailed parsing input: parser: bad import "syscall" というエラーが出るときのメモ

しかし再度コマンドを発行すると、同様のエラーが出てデプロイが失敗します。

現状ではGCLOUDコマンドは、上手くベンドリングに対応していないようです。このため一つ前のツールである、GOAPPを使用します。GOAPPは brew でもインストール可能なようです。

$ brew install goapp

ダンロードで goappツールを導入する場合は、GAE SDK ダンロードページの Or, you can download the original App Engine SDK for Go. から行います。

そしてデプロイします。

$ goapp deploy -application sample -version 1 app.yaml

デプロイが成功しました。

※ GAEの設定ファイル（app.yaml）の nobuild_files が無い場合、goappでも同様のエラーが出ますので、記述する必要があります。

最後に

GOPATH下にプロジェクト・ディレクトを設置する場合、シンボリックリンクを検討することもあるかと思います。シンボリックリンクでの設置では、デプロイは可能ですが、なぜか開発用サーバはエラーが出て起動できません。この辺、注意してください。

GAE SDK for Go は、Goの機能に追いついていない所や動作がおかしな点があるのかもしれません。一応、現状でまとめてみました。

※追記（2017/07/28）
６月末にリリースされた SDK 1.9.55 以降、Go1.8をベータサポートしているそうです。このため、app.yaml の api_versionを次のように指定すると、ベンドリングを使用しなくても Echoフレームワークが動作します。

api_version: go1.8

ただし、ローカル開発用サーバでは現在動作しません。またデプロイには、GCLOUDコマンドではなく、GOAPPコマンドを利用する必要があります。

GAE環境下での Echoフレームワークのエラー

2017-07-01T01:36:00.001+09:00

Echoフレームワークは、最近注目されている Go言語の高パフォーマンス・フレームワークです。シンプルかつ、意外とドキュメントも整備されており、メンテナンスも頻繁に行われているようです。

参考: https://echo.labstack.com/

GAE（Google App Engine）環境下で動作させるマニュアル（gcloudコマンド用では無いですが・・・）も整備されています。しかしサンプルを実際に動かしてみると、エラーで動作しません。初めは何だか良くわからなかったのですが、時間が掛かりましたが原因がわかり動作可能になりました。この件を記事にしてみます。

　GAE環境下でのペンドリングとデプロイ ← こちらも参照ください（違う方法で解決）

Echoのエラー

ローカル環境で、GAEテストサーバを動作させると、エラー次のエラーが表示されます。

テストサーバ実行コマンド（gcloudコマンド）

$ dev_appserver.py app.yaml

表示されるエラー

INFO     2017-06-30 18:16:29,531 admin_server.py:116] Starting admin server at: http://localhost:8000
ERROR    2017-06-30 18:16:31,076 go_runtime.py:184] Failed to build Go application: 
(Executed command: /Users/xxx/google-cloud-sdk/platform/google_appengine/goroot-1.6/bin/go-app-builder -app_base ...省略... )
/Users/xxx/go/src/golang.org/x/crypto/acme/acme.go:18: can't find import: "context"

2017/06/30 18:16:31 Can't find package "context" in $GOPATH: cannot find package "context" in any of:
 /Users/xxx/google-cloud-sdk/platform/google_appengine/goroot-1.6/src/context (from $GOROOT)
 /Users/xxx/go/src/context (from $GOPATH)
2017/06/30 18:16:31 go-app-builder: build timing: 0×skip (2ms total), 5×compile (258ms total), 0×link (0 total)
2017/06/30 18:16:31 go-app-builder: failed running compile: exit status 2

エラー原因

エラーの原因はズバリ、Echo側にあります。GAEのSDKには、Go言語が内包されています。しかしこのGo言語は、バージョン1.6系なのです。しかし Echoの最新版では、バージョン1.6系のサポートが外れました。このため、エラーが出て動作しないようです。

Echoのサポートが外れたのは、バージョン3.20 からです。しかしその前のバージョンも、GAEに関しては問題が発生して動作しません。結局、バージョン3.02まで遡らないと動作はしないようです。

参考
gaeをechoで動かそうとすると
 https://github.com/labstack/echo/releases

エラー対策

まずEchoのインストールを行います。

$ go get -u github.com/labstack/echo/...

Echo のインストール・ディレクトリ（例 /Users/xxx/go/src/github.com/labstack/echo 等）に移動し、タグ一覧を参照します。

$ git tag -l
2.0.0-alpha
v0.0.10
...省略...
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.0-rc.1
v3.2.0
v3.2.1

3.0.2にチェックアウトします。

$ git checkout -b 3.0.2 refs/tags/v3.0.2
Switched to a new branch '3.0.2'

ブランチ一覧を表示してみます。

$ git branch
* 3.0.2
  master

3.0.2 にブランチが移動したことが確認できます。

プロジェクトのディレクトリに戻り、GAEテストサーバが動作するか確認します。

$ dev_appserver.py app.yaml

参考： gitでタグをチェックアウトする。

ブランチした Echo を最新版に更新する

ブランチした Echo を元に戻し、最新版に更新するには次のようにします。

master にチェックアウトします。

$ git checkout master

作成した 3.0.2 ブランチを削除します。

$ git branch -d 3.0.2
Deleted branch 3.0.2 (was cd2530e).

オプション u を付けて再度、git getコマンドを実行します。

go get -u github.com/labstack/echo/...

参考： How to do “go get” on a specific tag of a github repository

最後に

以上で当面、EchoをGAEで使用できるようになりました。しかし依存ライブラリの管理を行う、Godep等のツールを導入し、プロジェクト毎にパッケージを管理した方が理に適っていると思います。この辺は色々難しそうなので、もう少し調べて記事にしたいと考えています。

参考： How to checkout a release with go get?

goenv導入

2017-06-30T19:30:00.000+09:00

GO言語のバージョンを気軽に変更できるツール goenv を導入のメモ

goenvについて

goenvは、pyenvやrbenvと同様のツールです。コマンドも大抵の場合、pyenvなどと合わせてあり理解しやすいです。しかし、goenvは同名のツールが乱立しており、調べたら沢山あって驚きました。

※GODOCに載っていた同名ツール

https://github.com/tmilewski/goenv
https://github.com/adjust/goenv
https://bitbucket.org/ymotongpoo/goenv → 日本人が開発者のようです（結構独特かも）

※その他

https://github.com/syndbg/goenv → brewで導入できる goenv
https://github.com/pwoolcoc/goenv → python製 goenv
https://github.com/crsmithdev/goenv

この他、rbvm と同様のツールである gvm もあります。

https://github.com/moovweb/gvm

こちらの方が、メジャーなようです。

私は滅多に使わないので、pyenvとコマンドが一緒で、brewで簡単に導入できる、https://github.com/syndbg/goenv を使用します。

goenvのインストール

macOSの場合は、brewでインストール可能です。

$ brew update
$ brew install goenv

syntax2html

次に、bashプロファイル（.bash_profile）に、次に一行を追加します。

eval "$(goenv init -)"

以上でインストールを完了です。変更したbashプロファイルをターミナルで再読込する場合は、次のコマンドを実行します。

$ source ~/.bash_profile

※ Windowsの場合は、こちらを参照してください。
https://github.com/syndbg/goenv

goenv使い方

pyenvと同じだと思いますが、使い方を書いてみます。

goenvでインストール可能なgoのバーション一覧は、次のコマンドで表示できます。

$ goenv install -l
Available versions:
  1.2.2
  1.3.0
  1.3.1
  ...省略...
  1.7.5
  1.8.0
  1.8.1
  1.8.3

試しに、1.6.3を導入してみます。

$ goenv install 1.6.3
Downloading go1.6.3.darwin-amd64.tar.gz...
-> https://storage.googleapis.com/golang/go1.6.3.darwin-amd64.tar.gz
Installing Go Darwin 64bit 1.6.3...
Installed Go Darwin 64bit 1.6.3 to /Users/xxx/.goenv/versions/1.6.3

1.6.3に切り替えるには、次のコマンドでグローバル設定を変えれます。

$ goenv global 1.6.3

しかしデフォルト設定してしまうと、goenvコマンドでは元に戻すことができません。

ローカルのディレクトリーのみ設定を変える場合は、

$ goenv local 1.6.3

とします。

ローカル設定では、--unset オプションで元に戻すことが可能です。

$ goenv local --unset

さてgoのバージョンを確認してみましょう。

$ go version
go version go1.6.3 darwin/amd64

1.6.3に切り替わったことが確認できると思います。

最新バージョンもインストールして切り替えれるようにした方が良いでしょう。

$ goenv install 1.8.3

goenvでインストール済みバージョンと、現在使用中のバージョンを表示するには次のコマンドです。

$ goenv versions
  system
* 1.6.3 (set by /Users/xxx/.goenv/version)
  1.8.3

system と表示されているのは、goenv外（brew）でインストールした go言語です。

グローバル設定の取り消しコマンドはありませんが、バージョン表示されている /Userx/xxx/.goenv/version ファイルを削除すれば、設定を取り消すことが可能です。

Go言語

2017-06-30T19:28:00.000+09:00

最近、Go言語（Golang）にも手を染めています。メモしておかないと忘れそうな事も多いので、このブログでもGoの記事を公開することにします。

Google Cloud SDK への移行

2016-12-09T00:05:00.000+09:00

Google App Engine（GAE）を利用していますが、いつの間にかSDKやツール・コマンドなどが変更になりました。従来の APPCFGとは全く違うので、最低限の使い方をメモ書きレベルで記事にします。

GCLOUD

結構前から、Google Cloud Platform の管理コマンドをまとめたツールが GCLOUD として配布されいます。最近まで、GUIツールも含んだ従来のGAEの管理ツール（APPCFG）も配布されていましたが、現在従来型ツールは非公開になっています。

参考: CLOUD SDK

GCLOUD は、GUIツールは無く、全てコマンドラインから操作します。その代わり従来ツールでは不可能だった、Google Cloud Platform に関する細かな管理が可能です。

Google Cloud SDK インストール

まず上記のリンクから、Google Cloud SDK をダウンロード・インストールします。ちなみに私の場合、Windwos10ではインストールが成功しましたが、MacOSでは何度試行してもインストールできませんでした。OSが二世代前の Yosemite、というのも理由かもしれません。

開発環境は MacOS の方が良いと最近言われていますが、今回、Windows10の良さを再認識できました。MacOSよりキビキビ動くし、遅ればせながら PowerShell を利用したところ、コマンドライン環境で特に不便なことは無かったです

※ 今回の記事中のコマンド例は、PowerShellの環境です。

※ MacOSでもインストールできました、手順としては以下の通りです。（追記 1/18）

コンソールから次のコマンドでインストール
```
curl https://sdk.cloud.google.com | bash
```
インストールが成功したら、次のコマンドで初期設定を行う。
```
gcloud init
```
gcloudコマンドでのデフォルト・ユーザとデフォルト・アプリの設定を行います。
この他に、
```
gcloud components list
```
コマンドでコンポーネントのリストを確認しようとすると、次のようなエラーが表示されることがあります。
```
ERROR: (gcloud.components.list) Failed to fetch component listing from server.
```
この場合は、次のコマンドで修復ができるようです。
```
brew update
brew uninstall python
brew upgrade openssl
brew install python --with-brewed-openssl
```

参考:
Google Compute Engine を使うための準備（Google Cloud SDK インストール - Linux & OS X 編）
Failed to fetch component listing from server

APPCFGからの移行

従来のAPPCFGからGCLOUDに移行する場合に、まずアプリの幾つかの yaml ファイルを書き換える必要があります。

アプリ定義（デフォルト・モジュール） - app.yaml
プロジェクト名（application）とバージョン（version）の指定は、コメントにします。この記述があるとエラーで、アプリのデプロイができません。
```
#application: myapp
#version: 1
```
モジュール定義 - （例）back_job.yaml
プロジェクト名・バージョンをコメントアウトにするのに加えて、モジュール名の項目名を、module から service に変更します。
```
#application: myapp
#module: back-job
service: back-job
#version: 1
```

プロジェクト名は、SDKインストール時に指定したデフォルトのプロジェクト名を使用します（変更方法は後述）。バージョンは、GCLOUD コマンドのデプロイ時に指定します。

デプロイ

GCLOUDでのアプリケーションのデプロイは、コマンド環境から次のように指定します。

gcloud app deploy app.yaml --version 1 --no-promote

アプリのフォルダ上で実行しています。ここでは、二つオープションを指定します。

--version（-v でも）: デプロイするバージョンを指定します。例では、１を指定しています。
--no-promote: このオプションを付けないと、デプロイ後直ぐにトラフィックが１００％移行してしまいます。テスト＆確認後バージョンを移行する場合は、Cloud Platformのバージョン管理画面から、トラフィックを移行させます。

実行例

PS C:\myapp\web2py> gcloud app deploy app.yaml --version 1 --no-promote
You are about to deploy the following services:
 - myapp/default/1 (from [C:\myapp\web2py\app.yaml])
     Deploying to URL: [https://1-dot-myapp.appspot.com]
     (add --promote if you also want to make this service available from
     [https://myapp.appspot.com])

Do you want to continue (Y/n)?  y

Beginning deployment of service [default]...
Some files were skipped. Pass `--verbosity=info` to see which ones.
You may also view the gcloud log file, found at
[C:\Users\xxx\AppData\Roaming\gcloud\logs\2016.12.08\12.03.23.383000.log].
File upload done.
Updating service [default]...done.
Deployed service [default] to [https://1-dot-myapp.appspot.com]

You can read logs from the command line by running:
  $ gcloud app logs read -s default

To view your application in the web browser run:
  $ gcloud app browse

モジュールをデプロイする場合は、下のようにモジュールの yaml ファイルを指定します。下のコマンドでは、デフォルトモジュールと back-job モジュールの、二つがデプロイされます。

gcloud app deploy app.yaml back_job.yaml --version 1 --no-promote

cron.yaml や queue.yaml 、index.yaml などを変更した場合は、次のようにデプロイを指定します。

gcloud app deploy cron.yaml queue.yaml

実行例

PS C:\myapp\web2py> gcloud app deploy cron.yaml queue.yaml
You are about to deploy the following configurations:
 - myapp/cron  (from [C:\myapp\web2py\cron.yaml])
 - myapp/queue  (from [C:\myapp\web2py\queue.yaml])
Do you want to continue (Y/n)?  y

Updating config [cron]...done.
Updating config [queue]...done.

Cron jobs have been updated.

Task queues have been updated.

The Cloud Platform Console Task Queues page has a tab that shows the tasks that are running cron jobs.

初めてデプロイするプロジェクトでは、ファイルロックのワーニングが表示される時があります。しかし何度がデプロイを実行すると、ワーニングが表示されなくなります。

ローカルのテスト環境

従来、GUIツールから起動できたローカルのテスト環境は、GCLOUDコマンドからは起動できないようです。代わりに、dev_appserver.py を利用します。

PS C:\myapp\web2py> dev_appserver.py .

パラメータとして、app.yaml があるフォルダーを指定します。現在そのフォルダーで作業している場合は、ピリオド（.）を指定します。

すると、Pythonコンソールが起動します。

INFO     2016-12-08 12:02:58,164 api_server.py:205] Starting API server at: http://localhost:53109
INFO     2016-12-08 12:02:58,187 dispatcher.py:197] Starting module "default" running at: http://localhost:8080
INFO     2016-12-08 12:02:58,204 admin_server.py:116] Starting admin server at: http://localhost:8000

アプリテストは、http://localhost:8080 で、Adminコンソールは、http://localhost:8000 でアクセスできます。

追記 2017/06/10
dev_appserver.py を終了させるには Ctrl+c を押しますが、再度起動しようとすると次のようなエラーが出る場合があります。

google.appengine.tools.devappserver2.wsgi_server.BindError: Unable to bind localhost:8080

この場合、次のコマンドを実行してみてください（macOSやLinuxなど）。

lsof -P | grep ':8080' | awk '{print $2}' | xargs kill -9

参考: Apps won't run on GAE - 'unable to bind to localhost:0'

プロジェクトの切り替え

デフォルト以外の複数のプロジェクトを利用している場合、プロジェクト毎に環境を作成し、切り替える必要があります。

新しいプロジェクトの環境は、gcloud config configurations create コマンドで作成します。

PS C:\myapp2\web2py> gcloud config configurations create myapp2
Created [myapp2].
Activated [myapp2].

「myapp2」という環境を作成すると共に、myapp2 に環境が切り替わりました。

プロジェクト名の登録は、gcloud config set project コマンドです。

PS C:\myapp2\web2py> gcloud config set project myapp2
Updated property [core/project].

アカウント情報の登録は、gcloud auth login コマンドです。

PS C:\myapp2\web2py> gcloud auth login

ブラウザ画面が開き、Googleアカントを認証します。

現在登録しているアカントと違なるアカウントを使用する場合は、次のコマンドを使用します。

gcloud config set account ACCOUNT

プロジェクトを切り替える時は、gcloud config configurations activate コマンドを使用します。

PS C:\myapp\web2py> gcloud config configurations activate default
Activated [default].

デフォルト・プロジェクトに切り替えます。

現在の環境情報を参照する場合は、gcloud config list を使用します。

PS C:\myapp\web2py> gcloud config list
Your active configuration is: [default]

[compute]
region = us-central1
zone = us-central1-f
[core]
account = xxxx@gmail.com
disable_usage_reporting = False
project = myapp

環境の一覧は、gcloud config configurations list を使用します。

PS C:\myapp\web2py> gcloud config configurations list
NAME         IS_ACTIVE  ACCOUNT              PROJECT      DEFAULT_ZONE   DEFAULT_REGION
default      True       xxxx@gmail.com       myapp        us-central1-f  us-central1
myapp2       False      xxxx@gmail.com       myapp2

その他

他にも様々なコマンドが用意されています。例えば、次のようなコマンドがあります。

インスタンスの一覧を表示
```
gcloud app instances list
```
モジュール一覧を表示
```
gcloud app services list
```
アプリをブラウザで表示
```
gcloud app browse
```
次のようにオプションも指定できます。

--service（-s）

サービス（モジュール）名を指定

--version（-v）

バージョンを指定
SDKコンポーネントのアップデート
```
gcloud components update
```
アップデートは指示が表示されますので、そのタイミングで実行すれば良いです。

などなどです。

参考:
Google Cloud SDK ドキュメント
 Google App Engine Python Standard Environment ドキュメント
 ハンズオン : Google Cloud SDK 基本と認証
 gcloud confing configurations コマンドでconfig設定を切り替える

GAEでSSLの設定（Let’s Encrypt の導入備忘録）

2016-06-01T04:22:00.001+09:00

---重要---
GAEのSSL設定は、マネージドセキュリティという仕組みが導入され、簡単になりました。
参考：Google App EngineでマネージドSSLが全ユーザーに無料提供

GAE設定の「カスタムドメイン」画面でカスタムドメインをチェックし、『マネージドセキュリティを有効にする』ボタンを押すだけで設定が完了します。また証明書の自動更新も行われます。
以下の記事のような作業は、行う必要はありません。（２０１７年９月１４日以降）

今回はGAEのSSL設定について、備忘録を残します。

サーバにSSL証明書を導入することは、セキュリティの観点から推奨されています。しかしGAE（Google App Engine）上で導入するには、独特の費用の問題があり、簡単ではありませんでした。しかし今では、導入のハードルはかなり下がってきています。

GAEでSSL証明書を導入する場合、以前は設定するだけ課金されました。しかし現在は、SNI 形式を利用する場合は無料で開放されています（以前は月額９ドル課金）。VIP 形式の場合は、現在でも月額３９ドル課金されます。しかしSNI形式でも最近では、多くのブラウザーが対応しています。

参考
SNI は、グローバルIPに依存せず、ホスト名毎にSSL証明書を使い分けることができます。
wikipedia - Server Name Indication
VIP（仮想IP）は、アプリケーションに専用のIPアドレスを割り当てます。SSL証明書も、与えられたグローバルIPに対して割り当てられます。
GAE日本語訳 - カスタムドメインのSSL

SSL証明書自体も、年額で数万するという認識でした（グローバルサインのクイック認証SSLで、定価34800円など）。しかしSSL/TSL普及を目指す非営利団体の登場などにより、現在では無料のSSL証明書を利用することも可能になっています。

今回無料のSSL証明書である、Let’s Encrypt をGAEに導入します。この手順は既にネット上で公開されています。私もそれらの情報を参考に設定しましたが、一つ問題があります。それは Let’s Encrypt が発行する証明書の有効期限は９０日と非常に短いのです。Let’s Encrypt では自動更新ツールを提供することにより、短い有効期限の問題の解決策を示していますが、現在のところGAE上ではこのツールを利用することが出来ないようです。

今回備忘録として設定方法を記事にするのは、サーバ側で何らかの解決策が示されるまで、当分定期的にSSL証明書を手動で登録更新を続ける必要があるためです。

今回参考にした記事・サイト
Let’s Encrypt
Let’s Encrypt on Google App Engine
Let's Encryptの証明書をGoogleAppEngineに設定して独自ドメインで運用する

Cloud Shell にてSSL証明書発行

Google Cloud Console　から、Cloud Shell を開きます。ちなみに Cloud Shell は 2016年中は無料だそうです。

ブラウザの下部にシェルが表示されます。

次のコマンドで Let’s Encrypt モジュールのクーロンを作成します。

git clone https://github.com/letsencrypt/letsencrypt

syntax2html

Let’s Encrypt のディレクトリに移動します。

cd letsencrypt

syntax2html

下のコマンドで、チャレンジ・レスポンス確認モードで動作させます（この時モジュールがインストールされるため、時間が掛かります）。

sudo ./letsencrypt-auto -a manual certonly

syntax2html

リカバリ用にメールアドレスを入力します。

利用規約に同意します。

独自ドメインを入力します。

マニュアルモードでの動作を確認します。

次のメッセージが表示されます。

独自ドメインの次のURLにアクセスすると、指示されたレスポンスコードを返すように設定します。

http://独自ドメイン/.well-known/acme-challenge/チャレンジコード

syntax2html

いろいろ方法がありますが、app.yaml に次の設定を追加するのが簡単です。

- url: /.well-known/acme-challenge/?(.{5}).*
  static_files: applications/myapp/static/letsencrypt/\1.txt
  upload: applications/myapp/static/letsencrypt/(.+)
  mime_type: text/plain

syntax2html

applications/myapp/static/letsencrypt/ ディレクトリに、チャレンジコードの頭５桁の名前を付けたテキストファイルの中身に、レスポンスコードを入れて、ファイルを生成します。例えば、

l1b83dAg6K-b10wHpoFguNo9b4iOIOAkiHtEkT3yhiE　というチャレンジコードだったら、 l1b83.txt というファイルを作成し、中身にレスポンスコードを入れます。

これらのアプリケーションファイルのGAEへのアップロードが完了したら、ENTERキーを押して処理を続行し、正常に完了したら証明書が生成されています。

SSL証明書のセット

SSL証明書は Cloud Shell 上で、

/etc/letsencrypt/live/独自ドメイン/fullchain.pem　　→ 公開鍵証明書
/etc/letsencrypt/live/独自ドメイン/privkey.pem　　　→　RSA秘密鍵

ファイルが生成されています。Cloud Consolel の「設定」→「SSL証明書」→「新しい証明書をアップロード」で次の画面を開きます。

Cloud Shell の次のコマンドで公開鍵証明書の中身を表示します。

sudo less /etc/letsencrypt/live/独自ドメイン/fullchain.pem

syntax2html

-----BEGIN CERTIFICATE-----
xxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END CERTIFICATE-----

BEGINの行からENDの行までコピーして、公開鍵証明書の画面に貼り付けます。

追記（注意）: fullchain.pem には、公開鍵証明書と共に中間CA証明書が追記されています。つまり、

-----BEGIN CERTIFICATE-----
公開鍵証明書
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
中間CA証明書
-----END CERTIFICATE-----

という構成になっていますので、公開鍵証明書のBEGINから中間CA証明書のENDまでコピーします。

同様にRSA秘密鍵も、

sudo openssl rsa -inform pem -in /etc/letsencrypt/live/独自ドメイン/privkey.pem -outform pem | less

syntax2html

で中身を表示します。

-----BEGIN RSA PRIVATE KEY-----
xxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END RSA PRIVATE KEY-----

同様にBEGINからENDの行までをコピーし、画面に貼り付けます。完了したらSSL証明書をアップロードします。

最後に、アップロードしたSSL証明書のリンクをクリックし、「次のカスタムドメインに対して SSL を有効にします」の項目でカスタムドメインにチェックを入れて、保存ボタンを押します。これによって、SSL証明書が有効に動作します。

以上で、SSL証明書の設定は完了します。難しくはないのですが、分かり難いです。この作業を９０日毎に行う必要があります（更新では証明書を生成して貼り付けるだけですが・・・）。GAEでも自動で更新するようになれば楽になります。今後に期待しています。

web2py GAEのカーソルとbelongs（IN演算子）

2015-07-01T00:28:00.001+09:00

GAE（Google App Engine）の Datastore環境でカーソルを使用した場合、belongs メソッドでエラーが出て動きません。これは記述を変更することで、動作することが解りました。この件について、メモ書き記事にします。

belongs は、SQLのIN演算子に変換されます。belongs の詳しい説明は、次のリンクを参照ください。

参考: web2py補足ドキュメント - Expression.belongs(value)

テスト用コード

次のようなコードを考えます。

モデル

db.define_table('person',
    Field('name'), format='%(name)s')

db.define_table('dog',
    Field('owner_id', db.person), 
    Field('birthday', 'date', requires=IS_DATE(format='%Y-%m-%d')),
    Field('name'))

コントローラ

def list():
    from datetime import date, timedelta
    today = date.today()
    date_last_year = today - timedelta(days=365)
    owner = [row.id for row in db(db.person).select()]

    dbset = db(db.dog.birthday >= date_last_year)\
        (db.dog.birthday <= today)\
        (db.dog.owner_id.belongs(owner))
    rows = dbset.select()
    return dict(rows=rows)

このコードは、GAE環境でも特に問題なく動作します。ちなみにコントローラのコードの９行目で belongs を使用しています。

エラーが発生するコード

それではGAE環境で、エラーの発生するコードを見てみましょう。

def list():
    from datetime import date, timedelta
    today = date.today()
    date_last_year = today - timedelta(days=365)
    owner = [row.id for row in db(db.person).select()]

    dbset = db(db.dog.birthday >= date_last_year)\
        (db.dog.birthday <= today)\
        (db.dog.owner_id.belongs(owner))
    rows = dbset.select(limitby=(0,10))
    return dict(rows=rows)

１０行目の select メッソッドに、limitby を設定しました。limitby は、セレクトするレコード数を指定するオプションです。

参考: web2py補足ドキュメント - Set.select([*fields, **attributes])

GAE以外の環境では問題なく動きます。GAE環境では、次のようなエラーメッセージがログに記録されます。

BadArgumentError: _MultiQuery with cursors requires __key__ order

解決策

このエラーが発生するのは、NDB API を使った場合のようです。NDB は Python の次世代 Datastore 用モジュールで、数年前に登場しました。web2py でもGAE環境の場合は、コードを NDB API 用に変換するようになっています。

参考:
BadArgumentError: _MultiQuery with cursors requires __key__ order in ndb
NDB Datastore API - Query Cursors

NDB ではクエリーとして、IN / OR / != の各演算子とカーソルを同時に使用した場合、上記のエラーが発生する仕様になっています。

「ん？、カーソルは使用していないぞ」と思われるかもしれませんが、web2py では limitby オプションを利用した場合、カーソルを使用するようになっています。

問題解決のためには、クエリーで使用するフィールドでソートしてあげればよいです。具体的には、次のようにコード変更します。

def list():
    from datetime import date, timedelta
    today = date.today()
    date_last_year = today - timedelta(days=365)
    owner = [row.id for row in db(db.person).select()]

    dbset = db(db.dog.birthday >= date_last_year)\
        (db.dog.birthday <= today)\
        (db.dog.owner_id.belongs(owner))
    rows = dbset.select(limitby=(0,10),
                        orderby=db.dog.birthday|db.dog.owner_id|db.dog.id)
    return dict(rows=rows)

１１行目の select メソッドで、 orderby オプションを指定します。

参考: web2py補足ドキュメント - Set.select([*fields, **attributes])

ここで気をつける事は、ソートフィールドにクエリーで使用するフィールドを含めると共に、主キーのフィールド（idフィールド）を最後に足します。idフィールドがソートに含まれないと、プログラムは動作しません。

ちょっとレアなケースの仕様のようですが、解り難かったので記事にしました。

GAE、Modulesの設定 ②

2015-06-24T03:12:00.001+09:00

前回の続きです。GAE(Google App Engine)の一機能である Modules APIの設定について、具体的に説明していきます。

GAEのデプロイツールは、従来の APPCFG が GCLOUD に変更になりました。移行方法などは次のリンクの記事を参考にしてください。
→　Google Cloud SDK への移行

yaml 定義ファイルの作成

Moduleを作成するには、そのための yaml ファイルを作成する必要があります。取り敢えず、バックエンド・ジョブ用の例を示します。

back_job.yaml

application: myapp
module: back-job
version: 1-00
api_version: 1

instance_class: B1
basic_scaling:
  max_instances: 2
  idle_timeout: 1m

runtime: python27
threadsafe: true

handlers:
- url: .*
  script: gaehandler.wsgiapp
  login: admin

syntax2html

back_job.yaml ファイルを作成します。GAEのアプリケーション情報を記述する app.yaml とほぼ同じ形式ですが、二行目の module: に Module名を記述します。ここでは、back-job という名前をつけます。

余談ですが、app.yaml にも module: を記述できます。しかし記述しないと、default という Module名が記述されたと見なされます。つまりすべてのアプリケーションのインスタンスは、Module下で動いていることになります（何も記述しないと default）。

もう一つ注目して欲しい項目として、instance_class: と basic_scaling: があります。それぞれ前回説明した、インスタンス・クラスとスケール・タイプを指定しています。ここではインスタンスクラスは B1 で、スケール・タイプは Basic Scaling を選択しました。これによって制限がないタスクを実行可能です。max_instances: は上限のインスタンス数を指定しますが、必ず記述する必要があります。

idle_timeout: はオプションの設定ですが、Basic Scaling の場合は指定しないと、インスタンスが停止するまでのアイドル時間がデフォルト値の１０分になってしまいます。毎時間実行するジョブの場合、一日あたり４時間分も余分なアイドル時間に取られてしまいます。費用削減のためにも、なるべく少ない時間を指定した方が良いでしょうね。

handlers: で、すべてのURLを処理するようにしていますが、login: admin オプションを付けています。Cronで実行するジョブは adminユーザ権限で実行されるため、ジョブの実行には問題ないと同時に不正なアクセスを防止します。

Moduleインスタンスのスタートアップ設定

ちょっとここから？？？、となる設定です。前回説明した３つのスケール・タイプの内 Manual Scaling と Basic Scaling では、インスタンスのスタートアップのために特殊な設定を行うことが必要です。それはスタートアップ時に、GAEからのGETリスエストが /_ah/start のURLに送信されます。これに応答する必要があります。具体的には、HTTPステータスコードの200〜299までか404を返すことが必要です。

私は最初次のように、静的HTMLファイルを返せば良いのかなと勘違いしていました。

# この設定は動きません。
# This setting does not work.
handlers:
- url: /_ah/start
  static_files: applications/myapp/static/200.html
  upload: applications/myapp/static/200.html
- url: .*
  script: gaehandler.wsgiapp
  login: admin

syntax2html

この設定では Module は動きません。なぜなら、 /_ah/start リスエスト共にインスタンスを起動してイニシャライズを行うことが必要だからです。静的HTMLファイルを返すだけでは、GAEのインスタンスは起動しません（逆に言えば、静的HTMLだけのアプリなら、GAEではインスタンス費用を払う必要がありません）。

インスタンスを起動するため、web2pyフレームワークの場合なら、_ah.py コントローラを作成し次のように記述します。

_ah.py

# -*- coding: utf-8 -*-
def start(): return "200"

syntax2html

これによって、インスタンスが起動する共にステータスコードの200を返すことができます。

この他に、インスタンス終了時に /_ah/stop というリクエストが送らてきますが、これに関してはアプリケーション側で対応する必要はないようです。

タスクやURLのディスパッチ

最も簡単にタスクを Module に割り当てるには、cron.yaml の target: パラメータに割り当てる Module名を記述します。

cron:
- description: my task
  url: /myapp/job/task
  schedule: every 1 hours
  target: back-job

syntax2html

もし、CronでないタスクやURLを使用する場合は、dispatch.yaml を作成します。

dispatch.yaml

application: myapp

dispatch:
- url: "*/job/*"
  module: back-job

- url: "*/nightjob/*"
  module: back-job

syntax2html

URL毎に Module を指定することができます。

これまた余談ですが、GAEにアップロードした dispatch.yaml の設定を削除する方法がないみたいです。設定を無効にする場合は、dispatch.yaml ファイルを削除するのではなく、設定にコメントを入れてください。これによって設定が無効になります。

Module のアップロード

設定した Module をGAEにアップロードは、GAEランチャーのアップロード機能では対応できないようです。コマンドラインやターミナルやから、次のコマンドを送ってください。

python appcfg.py update back_job.yaml

もしくは

appcfg.py update back_job.yaml

この他、app.yaml 側のアップロードも別途必要です。

もし dispatch.yaml だけを更新したい場合は、次のようなコマンドもあるようです。

appcfg.py update_dispatch ./

Modules API で一番嫌なのは、Module毎にアップロードする必要があることです。面倒な場合、必要なアップロードを全部繋げてバッチファイルを作成しても良いとは思います。

最後に

以上で Modules API の説明を終わりますが、バックエンドの無制限の環境でもジョブが停止することがあります。それはメモリの割当を超えたなどの原因が考えられます。このためジョブを適度な長さに切って、その都度タスクキューに送るなどの工夫が必要になってきます。タスクキューを使い始めると、いろいろプログラムの工夫ができるようになります。タスクキューを使ったことがない方は、Modules API と一緒に使ったら幸せになれると思います。

参考: Python Task Queue Configuration

ところで、暇つぶし用に作ったアプリケーションがあります。最近のメジャーなフレームワークなどをぶっ込んでみました（笑）。

GAE + web2py + Bootstrap + AngularJS + などなど
↓↓↓

↑↑↑
よかったら使ってみてください。

GAE、Modulesの設定 ①

2015-06-22T22:13:00.001+09:00

GAE（Google App Engine）の Modules API について、設定で試行錯誤したのでメモを兼ねた記事にします。

Modules API について

既に使っている方も多いと思いますが、Modules API について簡単に説明します。
GAEには以前から、Backends API という仕組みがありました。これは常時起動しているインスタンスで、主にCronなどのジョブを専門に実行する環境です。Backends API を利用した場合、次の利点があると思います。

フロントエンドの環境では１０分を超える処理はできませんでしたが、Backends API では制限はありません。
フロントエンドとバックエンドで環境を分けることができます。非常に重い処理に対して、強力なCPUタイプを割り当てるなどの設定が可能です。

しかし Backends API は、２０１４年に非推奨の機能になってしまいました。参考: Backends API

代わりに登場したのが、 Modules API です。フロントエンド・バックエンドに関係なく、アプリケーションの下に Modules という環境があり、その下にバージョン、更に下に実行環境であるインスタンスがある構成です。

参考: App Engine Modules in Python

Backends API との違いとして、次の点が挙げられると思います。

Module は幾つか作成できます（無償で５、有償では２０個まで）。処理タイプによって Module を切り替えることが可能です（Backends API でも処理毎にCPUタイプを切り替えることが可能でしたが・・・）。
Backends API ではバージョンはなかったですが、Modules API ではバージョンを分けることが可能になりました。
フロントエンドの処理でも、特定のURLだけ強力なCPU環境の Module を割り当てることが可能になりました。

スケール・タイプとインスタンス・クラス

Modules API との関連で、CPUに関するスケール・タイプとインスタンス・クラスを理解しておく必要があります。簡単にですが、解説してみたいと思います。
以前はなかったと思いますが、GAEに「スケール・タイプ」と「インスタンス・クラス」という概念が導入されました。スケール・タイプは処理に応じて、どのようにインスタンスが増えていくのかの設定です。またインスタンス・クラスは、CPUとメモリの割り当て種類です。

スケール・タイプ	Deadlines	CPU/Memory	Scaling	Free Daily Usage Quota
Automatic Scaling	HTTPリクエスト: 60秒までタスク: 10分まで	F1, F2, F4, F4_1G から選択	自動スケール	28時間インスタンス
Manual Scaling	リクエスト: 無制限タスク: 24時間まで	B1, B2, B4, B4_1G, B8 から選択	マニュアルによるスケール	8時間インスタンス
Basic Scaling	Manual Scalingと同じ	Manual Scalingと同じ	最大インスタンス数まで処理量に応じてスケール	Manual Scalingと同じ

インスタンス・クラス	メモリ	CPU	時間当たり費用
B1	128 MB	600 Mhz	$0.05
B2	256 MB	1.2 Ghz	$0.10
B4	512 MB	2.4 Ghz	$0.20
B4_1G	1024 MB	2.4 Ghz	$0.30
B8	1024 MB	4.8 Ghz	$0.40
F1	128 MB	600 Mhz	$0.05
F2	256 MB	1.2 Ghz	$0.10
F4	512 MB	2.4 Ghz	$0.20
F4_1G	1024 MB	2.4 Ghz	$0.30

参考: App Engine Modules in Python

リクエストの制限のない Module にするには、スケール・タイプを Manual Scaling か Basic Scaling にする必要があります。
因みにGAEでは、無償のインスタンス割り当てがあります。フロントエンドである Automatic Scaling Modules で一日あたり２８時間インスタンス、バックエンドの Basic and Manual Scaling Modules で一日あたり８時間インスタンスです。無償分を余すことなく使って費用を削減するためにも、Modules API を使用する必要があります。

前置きが長くなったので、次回に続きます。

web2py アップグレード豆知識

2015-04-12T11:16:00.001+09:00

web2pyアップグレード

作成したアプリケーションを、新しいバージョンの web2py に適用する場合は、幾つか方法があります。代表的な方法は、

web2py管理画面の「アップグレード」ボタンを押す
新しいバージョンのweb2pyをダウンロードし、applicationsフォルダに作成したアプリケーションのフォルダを丸ごとコピーする
（デベロッパー版web2pyを利用している場合） git pull コマンドで更新する

一番目の方法（a）は、web2pyの管理画面にあるアップグレードボタンを押すと、更新が完了します。
※追記
アップグレードボタンを押しても、エラーで更新されない時があります。この場合、web2pyフォルダーにある web2py_src_downloaded.zip ファイルを削除してみてください。前回アップグレード時に使用した更新用ファイルが、削除できないのが原因です。

しかし元のweb2pyのバージョンが古い場合など、更新が上手く行われない場合があります。その場合は、２番目の方法（b）でアップグレードすることが必要です。

アプリは別の場所で管理して、applicationsフォルダー下にシンボリック・リンクを貼るだけでも大丈夫です。

三番目の方法（c）は、GitHub のリポジトリにある web2py デベロッパー版を使用している場合に可能です。以前は GoogleCode で Mercurial で管理されていましたが、現在は Git で管理されています（昨年末位に変更になりました）。

アップグレード後の新規アプリケーションの注意点

新規アプリは、 welcome アプリをひな形に生成されます。しかしアップグレード後に新規アプリを生成しても、アップグレードが反映されていない時があります。その場合 web2py フォルダーの次のファイルを削除してください。

welcome.w2p

これは welcomeアプリのパッケージなのですが、アップグレード時に何らかの原因で削除されないまま残ると、アップグレードが反映されないということが起こります。新規アプリケーション作成時に wlecome.w2p ファイルがないと、welcomeアプリから自動生成されます。

アップグレード後の既存アプリケーションの注意点

アップグレードしても、アプリ・フォルダにある既存のファイルの変更は行われません。特に web2py 2.10.1 以降は Bootstrap3 に変更になりましたが、web2py をアップグレードしても既存アプリは Bootstrap2 のままという状態になります。

もし既存のアプリにもアップグレードを反映させたい場合は、アプリ・フォルダー内のファイルを手動で更新していく必要があります。このためアプリの作成時には、将来のアップグレードも考えて、記述方法を考えておく必要があります。例えば、次のようなことを考慮する必要があります。

新規アプリ作成時の既存のファイルには、なるべく変更を加えない。モデル・コントローラ・ビューなどは、アプリ用に新しいファイルを生成して記述する。
既存ファイルに記述する必要がある場合は、コメントを付けるなど変更点が後日わかるようにしておく。

以上簡単ですが、アップグレードの豆知識を書いておきます。

web2py 2.10.1 と SQLEDITABLE

2015-04-05T11:15:00.001+09:00

web2py 2.10.1

web2pyフレームワークの2.10.1が公開されました。このバージョンから、Bootstrapが２から３に変更になりました。これは、Bootstrap 2.3.2 の公式サポートの終了が予告されているからです。
他にデータベース関連の DAL モジュールが独立して、pyDAL となりました。この関連の変更も反映しています。リリースされたweb2pyフレームワークは問題があったようで、バージョンは 2.10.3 まで上がっています。

今後 pyDAL は、Python3 に対応していくようです。しかし Google App Engine などが Python2 のままなので、今後どうなるかわかりません。

web2py ダウンロードページ

SQLEDITABLE

SQLEDITABLEも Bootstrap3 への対応のため、バージョンアップしました。現在、 0.20 になっています。もし Bootstrap2 で使用したい場合は、0.18 を使用してください。

この他、SQLEDITABLEは仮想フィールドにも対応しました。特に自己参照フィールドを利用した場合、結構面白いユーザインターフェースを実現できます。SQLEDITABLEのデモ１４・１５を参考にしてください。

※ SQLEDITABLE 0.18 では、virtualfields.append メソッドで追加した仮想フィールドがある場合にエラーが出るバグがあります。これは 0.20 では修正されています。もし 0.18 を使用する場合は仮想フィールドとして、Field.Virtual メソッド（ニュースタイル仮想フィールド）の方を使用してください。

SQLEDITABLE プラグイン

2014-07-03T19:44:00.001+09:00

SQLEDITABLEプラグインを公開しました。次のデモページを参照してください。

SQLEDITABLE デモ

リンクをクリックしてください。

追記 2014/07/28
ドキュメントも作成しました。

SQLEDITABLE ドキュメント

web2py Book 第五版　日本語訳

2014-01-26T09:53:00.000+09:00

web2py Book の第五版の日本語訳は、本家サイトの方は公開されているのですが、表示がおかしいなどの問題があります。このため、次のURLで修正版を公開しています。宜しかったら参照してください。

http://web2py-book.appspot.com/chapter/33

web2py 静的アセット管理

2013-09-24T20:06:00.000+09:00

以前メーリングリストで、web2pyの「静的アセット管理」について書いたことがありますが、このブログでも少し内容を拡張して書いてみます。

静的アセット管理

静的アセット管理とは、静的ファイルをブラウザのキャッシュで利用する仕組みだ。Django でも同じような機能のコンポーネントがあるようだ。

具体的には次のように、モデル定義（db.pyなど）に記述する。

response.static_version = '1.1.1'

これによって次のように動作する。

静的ファイルのURL変更
静的ファイルのヘッダ情報の書き換え
対象の静的ファイルは、response.files に含まれているファイル

もう少し詳しく説明すると、

1. 静的ファイルのURL変更

例えば次のような静的ファイルのURLが、

http://127.0.0.1:8000/myapp/static/css/web2py.css

次のように変更される。

http://127.0.0.1:8000/myapp/static/_1.1.1/css/web2py.css

つまり、response.static_version で設定した値が、/_1.1.1のように静的ファイルのURLの一部に含まれるようになる。

2. 静的ファイルのヘッダ情報の書き換え

response.static_version の設定がある場合とない場合のヘッダ情報を比べると、次の項目が変更追加されていることがわかる。

Expires: Thu, 31 Dec 2037 23:59:59 GMT
Cache-Control: max-age=315360000

設定がない場合は、Expires の項目がなく、Cache-Control にも private が設定されている。これらの値が設定されることにより、静的ファイルがブラウザキャッシュから使用されるようになる。またキャッシュの有効期限が Expires の場合は２０３７年まで、Cache-Control は期間を１０年で指定している。

3. 対象の静的ファイルは、response.files に含まれているファイル

response.static_version が適用されるファイルは、response.filesに指定したファイルになる。デフォルトでは次の静的ファイルが含まれる。

js/jquery.js
css/calendar.css
js/calendar.js
js/web2py.js
css/web2py.css
css/bootstrap.min.css
css/bootstrap-responsive.min.css
css/web2py_bootstrap.css

効果と注意点

ここでブラウザのキャッシュの中身を見てみよう。

静的アセット管理の対象ファイルのキャッシュ期限が、１０年後の２０２３年に指定されていることが確認できる。

静的アセット管理を設定した場合、ブラウザキャッシュによる効果として、次の二点が考えられる。

ネットワーク負荷の削減
サーバ負荷の削減

もちろんブラウザキャッシュを使用するため、対象の静的ファイルが変更された場合など、本来サーバ上のファイルを使用すべきものが、ブラウザキャッシュのファイルを使用してしまう可能性がある。このため対象となる静的ファイルを変更した場合は、response.static_versio を変更する必要がある。例えば次のように変更する。

response.static_version = '1.1.2'

これによって静的ファイルのURLに含まれていた /_1.1.1 が、/_1.1.2 と変更されるため、新しいファイルとして認識される。

以後ファイルの変更の度に、response.static_version に指定する番号を、過去の番号と重複しないように変更する必要がある。

さらなる活用

静的アセット管理の仕組みは記述さえすれば、常にブラウザキャッシュを使用するため便利な設定であるが、デフォルトで対象となるファイルは限定されている。画像ファイルなどのキャッシュを利用すれば負荷を大きく削減できるファイルに適用するためには、次のように設定する。

URL('static', ('_'+response.static_version+'/' \
                     if response.static_version else '') +'images/test.jpg')

アプリケーションの static ディレクトリの image/test.jpg ファイルを、静的アセット管理で参照する。この記述を利用したコントローラ関数の例を次に示す。

def image():
   img = IMG(_src=URL('static', ('_'+response.static_version+'/' \
                        if response.static_version else '') +'images/test.jpg'))
   return dict(img=img)

このコントローラ関数を実行すると、image/test.jpg の画像を画面に表示する。

Google app engine での注意点

web2py 2.4.7 以前のバージョンでは、GAE上での静的アセット管理に対応していない。この場合、app.yaml の次の記述を、

- url: /(?P<a>.+?)/static/(?P<b>.+)
  static_files: applications/\1/static/\2
  upload: applications/(.+?)/static/(.+)
  secure: optional

次のように変更することが必要だ。

- url: /(.+?)/static/_\d.\d.\d\/(.+)
  static_files: applications/\1/static/\2
  upload: applications/(.+?)/static/(.+)
  secure: optional
  expiration: "365d"

- url: /(.+?)/static/(.+)
  static_files: applications/\1/static/\2
  upload: applications/(.+?)/static/(.+)
  secure: optional

expiration でキャッシュ期限を一年で設定している。必要であれば、この値も変更ください。

静的アセット管理の仕組みを使用すれば、気軽にアプリケーションのチューニングを行えます。結構大規模なサイトでないと効果がハッキリ出ないかもしれませんが、容易に実施できるというのが利点です。

web2py 補足ドキュメントについて ⑤

2013-09-09T23:36:00.001+09:00

近い内に web2py Book 日本語第５版が公開される予定です。

web2py Book 英語第５版
 web2py Book 日本語第４版

第５版に合わせて、web2py 捕捉ドキュメントも改定しました。DALの箇所しか変更していませんが、次のようにページを変更追加しました。

トピックス

クラス説明

Tableクラス _enable_record_versioning - 新規追加
Queryクラス case - 新規追加（CASE式が使えるようになりました）
Queryクラス as_dict/as_json/as_xml - 新規追加
Expressionクラス regexp - 新規追加（正規表現検索）
Expressionクラス avg - 新規追加（平均値取得）
Expressionクラス abs - 新規追加（絶対値取得）
Setクラス update_naive - 新規追加（コールバック関数を無視して更新）
Setクラス nested_select - 新規追加（ネストしたSELECT）
Rowsクラス xml - 新規追加
Rowsクラス json - 新規追加

他にも変更・追記した箇所があると思います。宜しかったら参考にしてください。

※ 以前のサンプルコードで owner フィールドを使っていたものがありましたが、ownerがDALの禁止ワードに指定されたので、owner_id に変更しました。

web2py でのテスト ③ モジュールでのdoctestの実行方法

2013-04-19T02:09:00.001+09:00

かなり久しぶりの投稿です。以前、次のような doctest に関する記事を投稿しました。

今回は モジュール での doctest の実行方法について書いてみます。

モジュールについて

最初に web2py のモジュールについて、簡単に説明します。モジュールは、共通関数などを抜き出し、独立性の高いコードとして設定するものです。 web2py管理画面の「モジュール」というセクションで、モジュールファイルの作成やアップロードが可能になっています。

モジュールを利用する場合の注意点を少し書いてみます。

モデル変数の扱い

モジュールはコントローラやモデルでのコード記述とは違い、モデルで定義した変数にはアクセスできません。このためモジュールで記述する関数やクラスで、モデル定義の変数（db や auth など）を使用したい場合は、~~パラメータでこれらの変数を渡してやる~~ current変数に渡してやる必要があります（注：記述が間違っていました web2py book モジュールからのAPIアクセスを参照）。

Pythonモジュールの利用

easy_install や pip などで導入する Python モジュールを、web2py 内に設定し利用することが可能です。この場合は管理画面のモジュールを利用するのでは無く、web2py ディレクトリの site-packages に設定します。具体的には次のページで設定方法を紹介していますので、参考にしてください。
Google AppEngine での Python-OpenID モジュールの設定

これは本番の Python 環境で、モジュールを追加できない場合などに利用可能です。

コード開発時に便利な設定

モジュールは一度インポートされると、モジュールのコード変更しても再度読み込まれることはありません。しかしこのような動作は、コード開発時には不都合です。もし次のコードをモデル定義に記述しておけば、モジュールのインポート命令がある度に、コードの変更チェックを行います。変更がある場合は、モジュールのリロードを行います。

from gluon.custom_import import track_changes; track_changes(True)

本番環境ではモジュールのリロードは不要ですので、コードをコメントにします。

モジュールテストの例

さて本題のモジュールのテストについて、入っていきます。まず date_calculator.py というモジュールファイルを生成し、次のコードを記述します。

#!/usr/bin/env python
# coding: utf8
from gluon import *

def last_friday(date=None):
    '''
    >>> last_friday()    #doctest: +ELLIPSIS
    datetime.date(...
    >>> last_friday('20130101')
    datetime.date(2012, 12, 28)
    >>> last_friday(20130101)
    Traceback (most recent call last):
    ...
    TypeError: must be string, not int
    >>> last_friday('2013/01/01')    #doctest: +ELLIPSIS
    Traceback (most recent call last):
    ...
    ValueError: ...
    '''
    return retrieve_date(init_date=date, weekday=4, weeks=-1)

def next_monday(date=None):
    '''
    >>> next_monday()    #doctest: +ELLIPSIS
    datetime.date(...
    >>> next_monday('20130101')
    datetime.date(2013, 1, 7)
    >>> next_monday(20130101)
    Traceback (most recent call last):
    ...
    TypeError: must be string, not int
    >>> next_monday('2013/01/01')    #doctest: +ELLIPSIS
    Traceback (most recent call last):
    ...
    ValueError: ...
    '''
    return retrieve_date(init_date=date, weekday=0)

def retrieve_date(init_date=None, weekday=None, **param):
    from datetime import date, datetime, timedelta
    if init_date is None:
        init_date = date.today()
    else:
        init_date = datetime.strptime(init_date, "%Y%m%d").date()
    date = init_date + timedelta(**param)
    if weekday is not None:
        d = weekday - date.weekday()
        date += timedelta(d if d > 0 else 7 + d)
    return  date

syntax2html

簡単に解説すると、 last_friday　と next_monday の２つの関数があり、それぞれ指定日の一番最後の金曜日と、次の月曜日の datetime.date オブジェクトを返します。既に doctest のコードは、この２つの関数には設定されています。

このコードの dcotest を実行するには、どうしたら良いでしょうか？。というのは web2pyの管理画面にはコントローラにあるようなテストボタンが、モジュールにはありません。また、コマンドラインからも実行できないようです。

モジュールテストの実行

doctest はモジュールのままでは実行出来ません。このため、テストが実行可能なコントローラにインポートします。

まず、ダミーのコントローラファイルを作成します。ここでは test.py とし、次のコードを記述します。

1 2 3 4	# coding: utf8 # try something like from date_calculator import last_friday from date_calculator import next_monday
	syntax2html

コードを記述し保存したら、管理画面からテストを実行してみます。

正常に、 doctest を実行したことが確認できました。

モジュールの doctest ではコントローラにダミーファイルを作成し、モジュールの関数をインポートすることにより実行できるということが、理解して頂けたと思います。

web2py を AWS Elastic Beanstalk で動かす設定

2012-12-03T22:08:00.002+09:00

web2py を Amazon web services (AWS) の Elastic Beanstalk で動作させるための手順を、ドキュメント化しました。宜しかったら、参考にしてください。

AWS Elastic Beanstalk デプロイ手順

↑　↑　↑　リンクをクリックしてください。

syntax2html のバージョンアップ

2012-11-12T08:06:00.001+09:00

ソースコード変換サービスの syntax2html を若干バージョンアップしました。改善点は次の通りです。

インラインCSS機能を強化しました。
pygments 1.4 から 1.5 に変更しました。これにより、対応するコードは２３５種類になりました。
ユーザ・インターフェースを改善する共に、多少のバグを修正しました。
syntax2html サイトへのリンク機能を付け加えました。

一番大きい改善は、インラインCSS機能の強化です。pygments の吐き出すインラインCSSのコードは、他のCSSコードの影響を全く考慮していませんでした。また行番号をインラインCSSで出力すると、レイアウトが崩れるという問題もありました。このためコードをチェックし、必要なCSSコードをインラインでセットするようにしました。

次のブログサービスの初期設定で syntax2html が出力したコードの動作を確認しました。

レイアウトのズレは対症療法的になってしまいますので、まだ不十分だとは思います。

インラインCSSは、普段はソースコードをブログには載せないが、ブログで公開する必要に迫られた場合に、使用すれば便利だと思います。ブログ側では何も設定は必要ありません（syntax2html が出力したHTMLコードを記事にコピするだけ）。

syntax2html へのリンク機能は、特に意味がありません。もし表示したくない場合は、「syntax2html へのリンクを表示」のチェックを外すだけです。

最後にインラインCSSのサンプルを紹介します。

注意
インラインCSSを使っていますが、このブログでは syntax2html 用に特別なCSSを設定しています。このため、サンプルで表示されている行番号とコードの間の線は、通常のインラインCSSでは表示されません。

■ AWK のコード（Pygments 1.5 で追加されました）

1	/^AWK/ { print "この行は AWK ではじまる行です。" }
	syntax2html

■ Dart のコード（Pygments 1.5 で追加されました）

1 2 3 4 5	#import('dart:html'); void main() { var elem = query('#text'); elem.text = 'Hello, Dart!'; }
	syntax2html

■ DTD のコード（Pygments 1.5 で追加されました）

<!ELEMENT firstName (#PCDATA)>
<!ELEMENT secondName (#PCDATA)>
<!ELEMENT info ANY>
<!ELEMENT data (firstName,secondName,info?)>
<!ELEMENT myDocument (data)*>
<!ATTLIST data age CDATA #IMPLIED>

syntax2html

■ F# のコード（Pygments 1.5 で追加されました）

1 2 3 4	let rec factorial n = match n with \| 0 -> 1 \| _ -> n * factorial (n - 1)
	syntax2html

■ Groovy のコード（Pygments 1.5 で追加されました）

class Greet {
  def name
  Greet(who) { name = who[0].toUpperCase() +
                      who[1..-1] }
  def salute() { println "Hello $name!" }
}

g = new Greet('world') // ???????????????????????????
g.salute()             // "Hello World!" ?????????

syntax2html

■ JSON のコード（Pygments 1.5 で追加されました）

1	{"name": "John Smith", "age": 33}
	syntax2html

■ MoonScript のコード（Pygments 1.5 で追加されました）

1 2 3 4 5 6 7 8 9 10	export my_func x = 2323 collection = height: 32434 hats: {"tophat", "bball", "bowler"} my_func = (a) -> x + a print my_func 100
	syntax2html

■ PostgreSQL のコード（Pygments 1.5 で追加されました）

1 2 3 4	CREATE FUNCTION square_root(double precision) RETURNS double precision AS 'dsqrt' LANGUAGE internal STRICT;
	syntax2html

■ PowerShell のコード（Pygments 1.5 で追加されました）

1 2 3	PS> $rssUrl = "http://blogs.msdn.com/powershell/rss.aspx" PS> $blog = [xml](New-Object System.Net.WebClient).DownloadString($rssUrl) PS> $blog.rss.channel.item \| Select title -first 8
	syntax2html

■ Scilab のコード（Pygments 1.5 で追加されました）

1 2 3 4 5 6	function [x]=fact(k) k=int(k) if k<1 then k=1,end x=1; for j=1:k,x=x*j;end endfunction
	syntax2html

■ SystemVerilog のコード（Pygments 1.5 で追加されました）

1 2 3 4 5	typedef enum reg [2:0] { RED, GREEN, BLUE, CYAN, MAGENTA, YELLOW } color_t; color_t my_color = GREEN;
	syntax2html

syntax2html へは、こちらのリンクをクリックしてください　→ syntax2html

web2py SQLFORM あれこれ ⑥ SQLTALBLEの利用

2012-11-02T03:02:00.001+09:00

SQLFORM.grid とカスタマイズ１と SQLFORM.grid とカスタマイズ２で、SQLFORM.grid を説明しました。SQLFORM.grid はそれだけで、テーブルの一覧表示やレコードの作成・表示・修正・削除が可能な、非常に便利な機能です。しかしカスタマイズという観点からは、できることは限定されます。このため今回は SQLTABLE を使用し、もう少し柔軟なカスタマイズを試してみます。

SQLTABLE で仮想フィールドを利用する場合の注意点

SQLTABLE と SQLFORMの連携について考えてみるが、SQLTABLE 自体に関しては、こちらを読んで欲しい。今回、SQLTABLE では仮想フィールドを利用するが、web2pyのバージョンに関する次の注意点がある。

SQLTABLE で仮想フィールドを利用する場合の注意点

仮想フィールドは、web2py ver. 2.0.0 ～ 2.2.1 では利用できません（バグのため）。
ニュースタイル仮想フィールドは、 ver.1.x.x を含む、web2py ver.2.2.1 以前では利用できません（未対応だったため）。

これはあくまでも、仮想フィールドを SQLTABLE で利用する 場合の注意点だ。現在の最新は 2.2.1 だが、 2.2.1 を含めて 2.x.x 系では仮想フィールドを利用できない。ニュースタイルは、2.x.x 及び 1.x.x でも利用できない。

記事執筆時点で利用可能なのは、1.99.7 などの 1.x.x 系の過去のバージョンと、ニュースタイルも含めたら、trunk バージョンのみとなる。もし今現在、trunk バージョンを利用している場合、最新に更新して欲しい。

参考：web2py download

SQLTABLE と SQLFORM の連携（仮想フィールド利用）

SQLFORM に関しては、SQLFORM基本及び SQLFORMカスタマイズで説明をした。記事のコードでは URLパラメータでレコードIDを渡し、該当するIDのレコードが存在する場合は編集・削除が、存在しない場合は新規作成を行う。今回は SQLFORMカスタマイズに紹介したコードと共に使用可能な、 SQLTABLE のコードを作成する。

まず、次の SQLTABLE を使ったコードを見て欲しい。

@auth.requires_login()
def table():
    class virtual_image(object):
        def edit_image(self):
            if self.image.url:
                url = self.image.url 
            else:
                url = URL(c='default', f='download', args=self.image.file)
            return A(IMG(_src=url, _width=50, _height=40),
                    _href=URL(f=image, args=self.image.id, 
                    user_signature=True))
            
        def edit_link(self):
            url = URL(f=image, args=self.image.id, user_signature=True)
            return A(I(_class='icon-pencil'),
                     T('Edit'),_class='btn', _href=url)

    rows = db(db.image).select()
    rows.setvirtualfields(image=virtual_image())
    
    columns = ['image.edit_image', 'image.name', 'image.category', 
               'image.edit_link']
    headers = {'image.edit_image':'', 'image.name':T('Name'), 
               'image.category':T('Category'),
               'image.edit_link':{'class':'row_buttons', 'label':'', 
                                'width':'60%', 'selected':False, 
                                'truncate':0}}

    add_link = A(I(_class='icon-plus'), T('Add'), _class='btn', 
                 _href=URL(f=image, user_signature=True))
    table = DIV(add_link, SQLTABLE(rows, columns=columns, 
                            headers=headers, _class='web2py_grid'))

    return dict(table=table)

syntax2html

このコードでは、Virutal_image クラス定義（２行目）で仮想フィールドの定義を行なっている。さらに、setvirtualfields メソッドで、Rowsオブジェクトに対しての仮想フィールドを設定する（１８行目）。最後に、これらの仮想フィールドを含めた、SQLTABLE オブジェクトを生成している（２９行目）。

また、SQLTABLE で仮想フィールドを表示する場合に、仮想フィールドを columns パラメータに指定することを忘れてはいけない（２０・２１・２９行目）。columnsパラメターには表示するフィールドを指定するのだが、このパラメータに指定した順にフィールドが表示される事にもなる。

コードを実行すると、次の画面が表示される。

画面イメージでは仮想フィールドで定義した、画像及び編集ボタンが追加されている。画像及び編集ボタンは、href属性に image 関数が、URL変数にはレコードのid値が設定されている。このため、クリックすると SQLFORMの編集画面に遷移する。

今回のコードでは、Twitter Bootstrapを利用している。Bootstrapの詳細は、Twitter Bootstrap の利用を参照して欲しい。また画面は、SQLFORM.grid のデザインに合わせるため、web2py_grid クラスを指定している。もし Bootstrap のテーブルデザインにしたい場合、例えば次のように、web2py_gridの代わりにクラスに指定する。

table table-striped table-bordered

すると画面は次のようなイメージになる。

SQLTABLE と SQLFORM の連携（ニュースタイル仮想フィールド利用）

同様に、ニュースタイル仮想フィールドでコードを書いてみる。

@auth.requires_login()
def table():
    def edit_image(row):
        if row.image.url:
            url = row.image.url 
        else:
            url = URL(c='default', f='download', args=row.image.file)
        return A(IMG(_src=url, _width=50, _height=40),
                _href=URL(f=image, args=row.image.id, user_signature=True))
        
    def edit_link(row):
        url = URL(f=image, args=row.image.id, user_signature=True)
        return A(I(_class='icon-pencil'),
                 T('Edit'),_class='btn', _href=url)

    db.image.edit_image = Field.Virtual(lambda row : edit_image(row)) 
    db.image.edit_link = Field.Virtual(lambda row : edit_link(row)) 
    rows = db(db.image).select()
    
    columns = ['image.edit_image', 'image.name', 'image.category', 
               'image.edit_link']
    headers = {'image.edit_image':'', 'image.name':T('Name'), 
               'image.category':T('Category'),
               'image.edit_link':{'class':'row_buttons', 'label':'', 
               'width':'60%', 'selected':False, 'truncate':0}}

    add_link = A(I(_class='icon-plus'), T('Add'), _class='btn', 
                 _href=URL(f=image, user_signature=True))
    table = DIV(add_link, SQLTABLE(rows, columns=columns, 
                                headers=headers, _class='web2py_grid'))

    return dict(table=table)

syntax2html

オールドスタイルの仮想フィールドとほぼ同じコードだが、１６・１７行目でニュースタイルで設定している。

SQLFORM のコード

新規作成・編集・削除を行う SQLFORM のコードは、SQLFORMカスタマイズ／ Twitter Bootstrap の利用で紹介したコードで良いのだが、登録に成功した場合と、キャンセルボタンを押した時のリダイレクト先が設定されていなかった。これらを設定すると、次のコードになる。

def image():
    def check_image(form):
        file_delete = '%s__delete' % 'file'
        if form.vars.url_file == 'url': 
            if not form.vars.url:
                form.errors.url = T('must enter a url')
            else:
                form.vars[file_delete] = 'on'
        else:
            if form.vars.file is None and \
                (form.vars.has_key(file_delete) is False or 
                 form.vars.get(file_delete, False)):
                form.errors.file = T('must select a file')
            else:
                form.vars.url = ''
            
    onchange_js = "jQuery.noConflict();\
                if(jQuery('#url').attr('checked')){\
                    jQuery('#image_url__row').show();\
                    jQuery('#image_file__row').fadeOut();}\
                else {\
                    jQuery('#image_file__row').show();\
                    jQuery('#image_url__row').fadeOut();}"    
    ready_js = "jQuery(document).ready(function(){" + onchange_js + ";});"

    record = db.image(request.args(0))
    if not record or record.url:
        checked = True 
    else:
        checked = False
    
    label = T('Image') + ':'
    radio = P(INPUT(_type='radio', _name='url_file', _value='url', 
            _checked=checked, _id='url', _onchange=onchange_js), 
            LABEL(T('url'), _for='url'), ' ', 
            INPUT(_type='radio', _name='url_file', _value='file', 
            _checked=not checked, _id='file', _onchange=onchange_js),
            LABEL(T('file'), _for='file'), _style="margin:0;padding:4px 0")
    position = -5 if record else -4
            
    extra_element = TR(TD(LABEL(label),_class="w2p_fl"), 
                    TD(radio, _class="w2p_fw"),
                    TD('', _class="w2p_fc"), _id='url_file__row')

    submit = BUTTON(I(_class='icon-ok icon-white', 
                      _style='margin-right: 5px;'),
                    T('OK'), _type='submit', _class='btn btn-primary')
    cancel = BUTTON(I(_class='icon-remove', _style='margin-right: 5px;'),
                    T('Cancel'), _type='reset', _class='btn',
                     _onclick = 'location.href="%s"' % URL(f='table'),
                     _style='margin-left:10px')

    form = SQLFORM(db.image, record, True, 
                   buttons=[submit,cancel],
                   upload=URL(c='default', f='download'))
    form[0].insert(position, extra_element)
    form = form.process(onvalidation=check_image, next=URL(f='table'))
    form = DIV(form, SCRIPT(ready_js, _type='text/javascript'))
    form.element(_id='image_url')['_placeholder'] = 
                                            'http://www.example.com'
   
    return dict(form=form)

syntax2html

登録が成功した場合のリダイレクト先は、processメソッドの next パラメータにセットする（５６行目）。キャンセルボタンを押した場合のリダイレクト先は、BUTTONタグの onclick 属性にセットする（４９行目）。

実行した場合の画面イメージは次のようになる。

新規登録	編集・削除

注意点など

SQLTABLE と SQLFORM の連携は、SQLFORM.grid を使用する場合に比べて自由度が高い。しかし SQLFORM.grid が持っていた次の機能は、別途コードを記述する必要がある。

検索
ソート
ページネーション（ページ割り）
CSVなどへのエクスポート

また SQLTABLE には、SQLFORM.grid とカスタマイズ２で説明した SQLFORM.grid の link パラメータによく似た、extracolumns パラメータが存在する。extracolumns は自分で定義したフィールドを SQLTABLE に追加できる機能だが、仮想フィールドを使う場合に比べて自由度が落ちる。このため SQLTABLE を使う場合は、今回の記事のように仮想フィールドを使用した方が何かと便利だと思う。

今回の記事はこれで終わりです。「SQLFORM あれこれ」のシリーズも、ほぼ終わりです。最後に次回付録的に、SQLTABLE に検索機能を付け加える例を紹介してみたいと思います。

web2py SQLFORM あれこれ ⑤　SQLFORM.grid とカスタマイズ２

2012-10-18T00:05:00.001+09:00

SQLFORM あれこれ ④ の続きです。今回も SQLFORM.grid を使ったカスタマイズを説明します。

SQLFORM.grid のカスタマイズ（一覧表示）

前回記事で、SQLFORM.grid の一覧表示画面を紹介した。

一覧画面のカスタマイズ用に使用可能なパラメータが、いくつか存在する。

表示項目を指定したり、項目の並び順を変えるカスタマイズでは、fields パラメータを使用する。項目のフィールド名を変更する場合は headers パラメータを指定する。サンプルコードは次のようになる。

@auth.requires_login()
def manage():
    fields = [db.image.name, db.image.category]
    headers = {'image.name':T('Name'), 'image.category':T('Category')}
    grid = SQLFORM.grid(db.image, upload=URL(c='default', f='download'),
                        fields=fields, headers=headers, csv=False)

    return dict(grid=grid)

コードを実行すると、次の画面イメージが表示される。

少し説明すると、fields には、表示する Fieldオブジェクトを指定する。これはリスト値で、指定順に表示される。
headers は、辞書値でフィールドと名前を指定する。ここでは翻訳オブジェクトである T を使って、名前を指定している。この他、csv パラメータも指定しているが、これは CSVエクスポートを無効にしている。

ここまでは普通の設定だ。もう少し難しいことを試してみよう。画像データがあるため、画像を表示するカスタマイズを試してみる。

テーブルに存在しないフィールドを表示するには、links パラメータを使用する。もともと links はレコードと関連するリンクを表示するためにあるようだが、無名関数（lambda）も使用可能なため、画像表示にも利用可能だ。links は、次のようにリスト値で指定する。

links =[lambda row: IMG(_src=row.url, _width=50, _height=40, _id='image')  
        if row.url else IMG(_src=URL(c='default', f='download', args=row.file), 
                            _width=50, _height=40, _id='image')]

links で無名関数を指定した場合、パラメータとしてレコード一覧の Row オブジェクトをが渡される。このためサンプルコードでは、url に値がある場合は src 属性に urlを指定したIMGタグを、urlに値がない場合は src 属性に file を指定する。links はリスト値のため、複数の定義フィールドを指定することも可能だ。

また links でフィールドを追加する時に、タイトルを付加することも可能だ。その場合、辞書値で header と body を指定し、header にはタイトル、body にはフィールド定義を指定する。

links=[{'header':T('Image'), 
        'body':lambda row: IMG(_src=row.url, _width=50, _height=40, _id='image') 
         if row.url else IMG(_src=URL(c='default', f='download', args=row.file), 
                             _width=50, _height=40, _id='image')}]

links パラメータを指定したコードを実行すると、次の画面イメージになる。

ここで注意して欲しいのは画面で、url と file フィールドも表示していることである。これは links に指定する無名関数のパラメータには、レコード一覧の Rowオブジェクトが使われるためである。つまり、無名関数で url と file フィールドを利用するために、レコード一覧に url と file が含まれている必要がある。

しかし無名関数に使用するといっても、一覧表示に url と file フィールドは不要だ。このため SQLFORM.grid の定義の前に、Fieldオブジェクトの readable 属性を False に指定する。

db.image.url.readable = db.image.file.readable = False

これによって一覧から、url と file フィールドを隠すことが可能になる。しかし、この設定で詳細表示（View）画面を表示させると、一覧と同様に url と file フィールドも表示されない。このため、ignore_rw パラメータを True に設定し、詳細画面では表示するように変更する。

以上まとめると、次のサンプルコードになる。

@auth.requires_login()
def manage():
    db.image.url.readable = db.image.file.readable = False

    fields = [db.image.name, db.image.category, db.image.url, db.image.file]
    headers = {'image.name':T('Name'), 'image.category':T('Category')}

    links=[{'header':T('Image'), 
            'body':lambda row: IMG(_src=row.url, _width=50, _height=40, 
                                   _id='image') 
             if row.url else IMG(_src=URL(c='default', f='download', 
                                          args=row.file), 
                                 _width=50, _height=40, _id='image')}]
    
    grid = SQLFORM.grid(db.image, upload=URL(c='default', f='download'),
                        fields=fields, headers=headers, csv=False,
                        links=links, ignore_rw=True)

    return dict(grid=grid)

コードを実行すると画面イメージは、次のようになる。

SQLFORM.grid のカスタマイズ（新規作成・編集・詳細表示画面）

新規作成や編集、詳細表示画面などもカスタマイズ可能だ。このために次のパラメータが用意されている。

パラメータ	制御する機能
formargs	新規作成・編集・詳細表示画面、共通パラメータ
createargs	新規作成画面のみ
editargs	編集画面のみ
viewargs	詳細表示画面のみ

これらのパラメータには、通常の SQLFORM に指定できるパラメータを辞書値で設定する。サンプルコードを示してみる。

@auth.requires_login()
def manage():
    db.image.url.readable = db.image.file.readable = False

    fields = [db.image.name, db.image.category, db.image.url, db.image.file]
    headers = {'image.name':T('Name'), 'image.category':T('Category')}

    links=[{'header':T('Image'), 
            'body':lambda row: IMG(_src=row.url, _width=50, _height=40, 
                                   _id='image') 
             if row.url else IMG(_src=URL(c='default', f='download', 
                                          args=row.file), 
                                 _width=50, _height=40, _id='image')}]

    submit = BUTTON(I(_class='icon-ok icon-white', _style='margin-right: 5px;'),
                    T('OK'), _class='btn btn-primary')
    cancel = BUTTON(I(_class='icon-remove', _style='margin-right: 5px;'),
                    T('Cancel'), _class='btn', _style='margin-left:10px', 
                    _type='reset', _onclick="history.back();")
    formargs = {'showid':False, 'buttons':[submit,cancel]}

    
    grid = SQLFORM.grid(db.image, upload=URL(c='default', f='download'),
                        fields=fields, headers=headers, csv=False,
                        links=links, ignore_rw=True,
                        formargs=formargs, onvalidation=check_image)
    
    return dict(grid=grid)

サンプルコードでは、id の画面表示を制御する showid の設定を行うと共に、SQLFORM あれこれ③ で紹介した Twitter Bootstrap を使ったフォームボタンのカスタマイズ（buttons）を行なっている。１５－２０行目でオプションの定義を行い、２６行目で formargs に定義したパラメータを渡している。

また、１９行目で Cancel ボタンを押した場合、前ページに戻る JavaScript を設定している。これは、一覧ではページネーション（ページ割り）があるためだ。

2012/10/23
Cancelボタンでは、location.href で page パラメータを指定していました。しかしキチンと動作しなかったため、JavaScript の history.back(); にコードを変更しました。

この他、入力値チェックのために、onvalidation パラメータも指定している。これは SQLFORM あれこれ② で最初に紹介した次の check_image 関数を指定している。

def check_image(form):
    file_delete = '%s__delete' % 'file'

    if form.vars.url is None and \
    form.vars.file is None and (form.vars.has_key(file_delete) is False or \
    form.vars.get(file_delete, False)):
        form.errors.url = T('must enter a url')
        form.errors.file = T('must select a file')

このコードを実行すると、画面のイメージは次のようになる。

新規登録	編集	詳細表示

編集と詳細表示の画面の左上には、links パラメータで設定した画像が表示されている。これは SQLFORM.grid の仕様により、この位置に表示されるようだ。表示・非表示を指定できるパラメータもない。もしこのイメージを非表示にしたい場合は、CSS ファイルに次の記述を追加する（links オプションで、IMGタグの id を image と指定しているため）。

.form_header>#image {
    display:None;
}

このCSSを設定すると、画面表示は次のようになる。

編集	詳細表示

以上で、SQLFORM.grid のカスタマイズの説明は終わりです。SQLFORM.grid はとても便利なのですが、カスタマイズには限界があります。例えば、SQLFORM あれこれ② で設定したような、DBテーブルにないフィールドを追加するとか、フィールドの属性追加や設定ができません。また一覧表示でも、編集・削除ボタンの位置変更や、links で設定したフィールドとDBフィールドの位置を入れ替えるなどの設定ができません。

このため次回はもう少し柔軟な設定が可能な、SQLTALBLE を使ったカスタマイズを紹介したいと思います。

SQLFORM.grid の他のパラメータについては、web2py Book に説明があります。

参考： web2py Book - SQLFORM.gridとSQLFORM.smartgrid

web2py SQLFORM あれこれ ④　SQLFORM.grid とカスタマイズ１

2012-10-13T09:38:00.001+09:00

SQLFORM あれこれ ③ の続きです。今回は SQLFORM.grid を使ったカスタマイズを説明します。

SQLFORM.grid と SQLFORM.smartgrid は、ほぼ同じ機能です。ただ SQLFORM.smartgrid の方が、関連するテーブルの参照やレコードメンテナンスが可能で、少し機能が高度になっています。しかし今回は、SQLFORM.grid を説明します。

SQLFORM.grid

SQLFORM あれこれ ②　の冒頭で紹介したモデル定義を利用して、試しに次のように SQLFORM.grid を使ったコードを書いてみる。

@auth.requires_login()
def manage():
    grid = SQLFORM.grid(db.image, upload=URL(c='default', f='download'))
    return dict(grid=grid)

少し説明を行うと、SQLFORM.grid は SQLFORM クラスの スタティックメソッド になる。

第一パラメータとして、Queryオブジェクトを指定する必要がある。ここでは、Tableオブジェクトを指定している。これはショートカット機能によって、db.image　は db.image.id > 0 に、Tableオブジェクトから Queryオブジェクトに変換される。

upload パラメータは、SQLFORM あれこれ ①　で説明した upload パラメータと同じ機能である。

このコードを実行してみる。

画面イメージのように一覧表示になる。SQLFORM.grid では、次の機能を提供する。

一覧表示
検索
ソート
ページネーション（ページ割り）
詳細表示
編集
削除
新規作成
CSVなどへのエクスポート

詳細表示とデータ編集画面イメージは次のようになる。

詳細表示画面	変更画面

SQLFORM.grid を利用すれば、それだけでデータ一覧表示やメンテナンス等に活用できる、便利な機能だ。ただ、いろいろ気に入らない部分もあるので、カスタマイズを試してみる。

SQLFORM.grid のカスタマイズ（アクセス制御）

前のセクションで紹介したコードの一行目で、 @auth.requires_login() と指定している。これはログイン認証を要求するデコレータだが、SQLFORM.grid はログインしていないと編集機能など一部機能を制限するため記述している。この制限は、user_signature パラメータを False で指定すれば解除可能だ。しかしセキュリティ上の問題になるため、通常は解除しない。

この他、アクセス制御に関しては細かな設定が可能だ。詳細参照・編集・削除・新規作成の各機能に対して、次のアクセス制御のパラメータが用意されている。

パラメータ	制御する機能
details	詳細参照
editable	編集
deletable	削除
create	新規作成

これらのパラメータに対しては、True/False といったブール値を直接指定しても良いが、特定のグループに属しているか判定するために Auth.has_membership や Auth.has_permission メソッドを指定しても良い。さらに無名関数（lambda）を指定することも可能だ。サンプルを示してみる。

@auth.requires_login()
def manage():
    def add_permission(form):
        auth.add_permission(0, 'update', 'image', form.vars.id)
        auth.add_permission(0, 'delete', 'image', form.vars.id)
        
    grid = SQLFORM.grid(db.image, upload=URL(c='default', f='download'),
                details=True,
                editable=lambda r : auth.has_permission('update','image', r)\
                                            or auth.has_membership('admin'), 
                deletable=lambda r : auth.has_permission('delete', 'image', r)\
                                            or auth.has_membership('admin'),
                create=True,
                oncreate=add_permission)
                
    return dict(grid=grid)

サンプルコードでは、次のように各パラメータを指定している。

パラメータ	設定値
details	True
editable	lambda r : auth.has_permission('update','image', r)\ or auth.has_membership('admin')
deletable	lambda r : auth.has_permission('delete', 'image', r)\ or auth.has_membership('admin')
create	True

この設定では、次のように権限を与えている。

詳細参照は、ログインユーザなら誰でも可能。
編集は、対象レコードへの update パーミッションを持っているか、admin グループに属するユーザ。
削除は、対象レコードへの delete パーミッションを持っているか、admin グループに属するユーザ。
新規作成は、ログインユーザなら誰でも可能。

ユーザに対するパーミッションの付与は、１４行目の onreate パラメータに add_permission 関数を割り当てることで実現している。oncreate は指定した関数を、レコード生成時に自動実行する。

このコードを実行してみる。

（admin グループに属していないユーザ で、アクセスした場合）

（admin グループに属しているユーザ で、アクセスした場合）

admin グループに属しているユーザは、全てのレコードの編集・削除が可能だ。admin グループの属していないユーザは、ユーザが作成したレコードしか編集・削除できないのがわかる。

このコードのままでも問題なく動作するのだが、レコード削除時に削除したレコードのパーミッションのデータが残ってしまうという問題がある。このため、次のようにコードを変更する。

@auth.requires_login()
def manage():
    def add_permission(form):
        auth.add_permission(0, 'update', 'image', form.vars.id)
        auth.add_permission(0, 'delete', 'image', form.vars.id)
        
    def del_permission(table, id):
        auth.del_permission(auth.user_group(), 'update', table, id)
        auth.del_permission(auth.user_group(), 'delete', table, id)
        
    def upd_permission(form):
        if form.vars.get(form.FIELDNAME_REQUEST_DELETE, False):
            del_permission('image', form.vars.id)

    grid = SQLFORM.grid(db.image, upload=URL(c='default', f='download'),
                details=True,
                editable=lambda r : auth.has_permission('update','image', r)\
                                            or auth.has_membership('admin'), 
                deletable=lambda r : auth.has_permission('delete', 'image', r)\
                                            or auth.has_membership('admin'),
                create=True,
                oncreate=add_permission, 
                ondelete=del_permission, onupdate=upd_permission)

return dict(grid=grid)

コードを解説すると、del_permission（７行目）と upd_permission（１１行目）という２つの関数を追加している。これを、ondelete 及び onupdate パラメータに割り当てている（２３行目）。ondelete はレコード削除時に実行する関数を、onupdate はレコード更新時に実行する関数を指定する。レコード編集画面で削除を許可している場合、ondelete ではなく onupdate で指定した関数が自動実行されるため、両方指定することが必要だ。

これによって削除レコードのパーミッションデータを削除することができる。

記事が長くなったので、次回に続きます。次回も、SQLFOM.grid カスタマイズを更に説明します。なお次のサイトも参考にしてください。

参考
web2py Book - SQLFORM.gridとSQLFORM.smartgrid
web2py 補足ドキュメント - アクセス制御 - Access control

今日のPython

VSCode で TypeScript のデバック設定

事前準備

コンパイル設定

デバッグ設定

デバック実行とその他

Datastore と組み込みインデックス

保存データが増大する要因

組み込みインデックスを生成しない

組み込みインデックス設定の注意点

複合インデックスも整理

Python3 と web2py 、SQLEDITABLE

Python3移行の注意点 ZIP・MAP組み込み関数

ZIP関数、Python2での動作

ZIP関数、Python3での動作

ZIP関数をPython2と同様の動作に記述するには

MAP関数、Python3での動作

MAP関数をPython2と同様の動作に記述するには

最後に

GAE環境下でのペンドリングとデプロイ

ベンドリングと Glide

ペンドリング使用時のプロジェクトの位置

GAEへのデプロイ

最後に

GAE環境下での Echoフレームワークのエラー

Echoのエラー

エラー原因

エラー対策

ブランチした Echo を最新版に更新する

最後に

goenv導入

goenvについて

goenvのインストール

goenv使い方

Go言語

Google Cloud SDK への移行

GCLOUD

Google Cloud SDK インストール

APPCFGからの移行

デプロイ

ローカルのテスト環境

プロジェクトの切り替え

その他

GAEでSSLの設定（Let’s Encrypt の導入備忘録）

Cloud Shell にてSSL証明書発行

SSL証明書のセット

web2py GAEのカーソルとbelongs（IN演算子）

テスト用コード

エラーが発生するコード

解決策

GAE、Modulesの設定 ②

yaml 定義ファイルの作成

Moduleインスタンスのスタートアップ設定

タスクやURLのディスパッチ

Module のアップロード

最後に

GAE、Modulesの設定 ①

Modules API について

スケール・タイプ と インスタンス・クラス

web2py アップグレード豆知識

web2pyアップグレード

アップグレード後の新規アプリケーションの注意点

アップグレード後の既存アプリケーションの注意点

web2py 2.10.1 と SQLEDITABLE

web2py 2.10.1

SQLEDITABLE

SQLEDITABLE プラグイン

web2py Book 第五版 日本語訳

web2py 静的アセット管理

静的アセット管理

効果と注意点

さらなる活用

Google app engine での注意点

web2py 補足ドキュメントについて ⑤

web2py でのテスト ③ モジュールでのdoctestの実行方法

モジュールについて

モジュールテストの例

モジュールテストの実行

web2py を AWS Elastic Beanstalk で動かす設定

syntax2html のバージョンアップ

Python3移行の注意点　ZIP・MAP組み込み関数

スケール・タイプとインスタンス・クラス

web2py Book 第五版　日本語訳

web2py SQLFORM あれこれ ⑤　SQLFORM.grid とカスタマイズ２

web2py SQLFORM あれこれ ④　SQLFORM.grid とカスタマイズ１