App Engine の NDB に StringListProperty がないっ

Google App Engine で新しくアプリをつくることになったので、調子にのって ndb を使おうとして、いきなり泣きを見ました。

class Foo(db.Model):
    def tags = db.StringListProperty()

というような、文字列配列を持つような StringListProperty が、ndb にはない！ 焦りつつぐぐったら、すぐに見つかりました。repeated というキーワード引数つきで定義すればよいみたいです。

class Foo(ndb.Model):
    def tags = db.StringProperty(repeated=True)

ある値を含むエンティティをクエリするには、以下のようにします。

Foo.query(Foo.tags == 'python')

複数の値のうち、いずれかを持つエンティティをクエリするには、以下のようにします。

Foo.query(Foo.tags.IN(['python','ruby']))
Foo.query(ndb.query.OR(Foo.tags == 'python', Foo.tags == 'ruby'))

参考:

• App Engine NDB alternative for db.StringListProperty 
• NDB Properties 
• Querying for Repeated Properties 

HTTP Access Control のヘッダ

Basic 認証のかかったウェブ API に対して、別のドメインから jQuery.ajax() でアクセスしようとして、えらく時間がかかりました。

サーバに

• Access-Control-Allow-Origin: http://example.com
• Access-Control-Allow-Methods: GET, POST, OPTIONS
• Access-Control-Allow-Headers: Origin, Authorization, Accept
• Access-Control-Allow-Credentials: true

をヘッダで返してもらうようにしたら、うまくいきました。が、これはただのコピペ。

それぞれ、何の意味を持つヘッダなのかが、 HTTP access control による、Cross-Origin Resource Sharing の解説に書かれています。

Access-Control-Allow-Origin

HTTP サーバに対して、 JavaScript からアクセスしてもよいドメインを指定する。Ajax で same origin 問題で検索すると、たいてい、このヘッダについて言及がある。ここまではよろしい。

ブラウザは、実際に GET や POST する前に、プリフライトリクエストというリクエストを発行します。通常これは OPTIONS メソッドです。で、このときのレスポンスヘッダをみて、ブラウザは呼び出す/呼び出さないを決定します。以下、同じく概要。

Access-Control-Allow-Methods

発行してもよいメソッドのリスト。OPTIONS と GET しか許さない場合には、OPTIONS, GET など。

Access-Control-Allow-Headers

サーバに送信してもいいヘッダのリスト。認証情報は Authorization ヘッダに書かれるので、このヘッダに Authorization が記載されている必要がある。

Access-Control-Allow-Credentials

名前だけみると上の Authorization と冗長な気がするんだけれど、こっちは cookie を送っていいかどうかのフラグ。

ブラウザによって、できたり/できなかったりして、いまだに確信が持てない。

要件定義の責任は発注側で持つ

開発するソフトウェアの発注内容に矛盾が含まれることがあります。びびる話ですが、残念ながらあります。モレがあるなんてことは、当然のように起こります。

ここで僅かなサンプルから、ものすごい一般化をしますが、日本では発注者がクソである、という仮説があります。ありますって、勝手にいまでっちあげたんですけど。大規模検査/管理システムを構築するメーカの人曰く「ドイツの会社は数百ページにわたる要件定義書を渡してくる。同じようなシステムに対して日本の会社は3ページくらいで済ませてくる」と。日本の発注者、というような集合に共通の特性があるわけあらへんやろう、という感じではありますが。けれど、私の観測範囲では SI の委託側と受託側の互いの期待がずれているために、不幸が起こっているように見えるのです。そして、発注側がけっこうクソなんじゃないのか、って感じがするのです。

SIer に仕事をたのむのは、何らかの事情で自分たちができないからです。時間とか、外注のほうが安いとか、技術がないから、とか。まあ、いろいろあるでしょう。そして、発注側に技術や能力や機能がないとき、発注側が要件定義できない場合、ということがあり得るのです。それはべつに構わない。

問題は、発注する側が (1) 要件定義できていないことを自覚していない、とか (2) 要件定義のコストを負担する気がない、ときです。 (1) が真のとき、当然 (2) も真になります。何が欲しいかを合意することなく、開発が進むと、当然、コレジャナイみたいな展開になるわけです。

もう、こんなことさんざん議論されていることなのですが、未だに、こんなことが起こっているような気がします（ソースは脳内）。SIer に指摘してもらうとか、コンサルしてもらうとか何でもいいけど、発注者はなんらかの形で、要件定義のコストを負担しなければいけないと思っています。伝わったことが伝えたことなのです。要件定義にOKを出すことができるのは、発注者しかいない。ここから次のことが分かります。

1. 発注担当者には要件定義の責任がある

2. 責任を果たさない奴はクソである

3. 私はクソである

たぶん一発で要件定義をすることは難しいでしょう。オンラインのサービスなら、なおさら。であれば、システムの稼働中や開発中に要件定義が変更になる、というのは、組み込んで置かないといけない。と、むりやりアジャイルな話に持って行ってみたり。

完璧なリリースに向けて

「完璧なリリースなどといったものは存在しない。完璧な絶望が存在しないようにね。」

関わっているプロジェクトが一旦落ち着いているように見えて、実はまったくもって佳境なのですが、その中で日々思いついたことをだらだら書き残していこうと思います。

一連のエントリには、便宜上、 Continuous Delivery （継続的デリバリ）のタグをつけます。ですが、 Farley と Humble の著書が扱う範囲とは必ずしも一致していません。アジャイル開発手法的なことも書くでしょうし、もっと細かいテスト手法のことも書くでしょうし、プロジェクトマネジメントとか成果物の納品形式や計画について書くかも知れません。クリックスルーレートが 0.0000% のAmazon へのアフィリエイト集になる可能性も大いにあります。なので、いずれはもっといいタグに変更するでしょう。

自分自信の考えはまったくまとまっていませんし、何が問題なのかさえ把握できていません。経験も交流も少ないので、単に答えを知らないこともあります。もしかしたら、最後には「頑張るしかない」みたいな泣きたくなる結論が出るかも知れません。それでも、まずは書き残す試みをしてみようと思います。