日々の破片

_ ジェネリックパラメータがいるときといらないとき

今、オーバーロードされたジェネリックメソッドDeleteがあるとする。

public void Delete<T>(string key);


public void Delete<T>(T entity);

で、下のを使うときは、ジェネリックパラメータを指定する必要はない。つまり、Delete(myEntity);で想定通りの動作をする（未確認なので、正しくはするはずだ）。

と、いうのに慣れきってしまって、ついジェネリックパラメータを指定せずに、上のほうのをDelete("key-001");のように呼び出して例外を食らって20分くらい（1ポモドーロ）悩んだ。

考えてみたら、上の場合、ジェネリックパラメータ抜きにDeleteメソッド側ではどうがんばってもDelete対象となるTを知ることはできない。当然であった。

・アマゾンのDynamoDBを操作してはまったのでメモ。

_ API Gatewayでx-www-form-urlencoded

いろいろな情報が錯綜していてさっぱりわからなくてえらく困った（2日くらい）。

C#かJavaの場合は、実は何も考える必要はなかったのだった。

・メソッドにはANYを指定する（ここで個々のメソッドを指定すると100%はまる）

・Lambdaプロキシ統合を選択する

これだけで良い。

あとは、リクエストをStreamで受けて、自分でJSONデシリアライズするか、またはプロパティ狙い撃ちで正規表現で引っ掛ければ良い。

カスタム統合をしようとすると、$input.body.jsonを作ろうとして、必ずリクエストボディをJSONとしてパースしようとする（というか、これは愚かな仕様だと思う）。しかも出て来る例外メッセージがtrue、false、nullを期待する、というものになる。

この訳のわからない例外メッセージはなんだろうと考えて、しげしげとx-www-form-urlencodedなリクエストボディ（たとえば、a=1&b=2）を眺めて、ふと気づいた。{で始まらないということはスカラーだと判断し、しかも文字列を示すダブルクォーテーションでもなく英数字が出てきた時、JSONデシリアライザーとしては、英数字が出現しても良いのは、true、false、nullだけだ。そこで上記の例外メッセージとなるのだろう。

が、PythonやNodeでLambdaを組むときはどうするんだろう？ 現在のところ、どうやっても、bodyの中をJSONとしてパースしようとするのを止めることができないのだが。（これは間違っていたらツッコミが入ることを期待しているエントリー）