デブサミ2013メモ 【14-C-2】決済だけではないペイパル（ペイパルアクセス活用事例）

From Evernote:

【14-C-2】決済だけではないペイパル（ペイパルアクセス活用事例） Clipped from: http://event.shoeisha.jp/detail/1/session/15/

植野稔之　PayPal Pte. Ltd, インテグレーションマネージャー

1985年に富士通に入社し、ワークステーション向けアプリケーション及びマルチメディアアプリケーションの開発に従事。

その後1997年よりシリコンバレーのベンチャー企業数社にてシステム運用やバックエンドシステム開発を経験後、2001年に独立。

独立後は決済システムやWebサーバシステムのコンサルティング、開発を行う。

2010年からはペイパルジャパンのインテグレーションマネージャとして、ペイパルの日本での導入・普及活動中です。

志水信也　PayPal Pte. Ltd, インテグレーションマネージャー

日系電機メーカ米国支社において、ウェブデータベース開発等に携わる。

その後、決済関連ベンチャーにてシステム運用、インフラ構築や新規サービスの企画・開発を行う。

外資系EC関連オンラインサービス会社を経て、2012年よりインテグレーションマネージャとしてペイパルの導入支援を担当。

＝＝＝メモ＝＝＝

決済総額1450億ドル/年

activeaccount1.23億

Ebayの決済は全体の32%

Paypal access

Openidの一種(Oauth 2.0 / opened connect standard 1.0準拠

登録されている住所、電話番号データの信頼性が高い

クレジットカード情報は提供されない

x.com デベロッパーポータル

github.com/paypal/paypal-access

PayPal accessと決済の連携

現状

     Paypalaccessとcheckoutの両方でログインが必要

近い将来(数ヶ月後？

     Checkoutでのログインをスキップ

PayPal here

ユースケースの動画(コーヒーの移動販売

1 クレジットカード払い

2 事前チェックイン&paypalアカウント決済

Api（2種類）で利用可能

Paypal Here mobile apps API

自前のレジアプリケーション内にPayPal hereのカード決済を組み込める

アプリ間連携を利用

Paypalのモバイルアプリに決済する商品情報を渡す(json形式

まだドキュメント等は公開されてない

Paypal Here API

商品情報の登録とかができるみたい

mobile apps APIよりももっと低レベルなAPIな雰囲気

ブランチの作成＆追跡ブランチ化の方法

久しぶりの更新です。今回のgitの使い方のお話です。

本来gitは分散型で、中央集権型のサーバを持たない使い方が想定されていると思いますが（実際オープンソースの開発だと特に）、仕事でgitを使うような場合はやはりSubversionに慣れているのもあり、共有サーバを一台用意し、それに対して開発メンバがPushしていくという使い方が多いかと思います。

そのような使い方の場合は、リモートにあるブランチを追跡する追跡ブランチをローカルに持っておくのが便利ですが、今までは「ローカルブランチ作成」→「追跡ブランチ化のコンフィグ設定」→「リモートへ作成したブランチをPush」という手順で追跡ブランチを作成していました。

ちょっとgitの使い方を調べていた所、もっと賢い方法があったので紹介します。（自分への備忘録としても。。。）

これで、追跡ブランチとして新しいブランチを作成できます。

Azure Tableによるデータ検索 - エンティティの結合（Join）

Windows Azure Tableに対するLINQクエリおよびREST APIでは、Joinによるエンティティの結合をサポートしていません。もちろんAzure Tableを使う時には、関連するエンティティのプロパティをコピーさせるなどしてJoinする必要がないようにデータモデルの設計を行います。

ただそれでも、仕様変更や機能追加によって当初想定していなかったデータの結合が必要になる場合もあります。そして、どうしてもデータモデルを変更したくないような場合には、Join処理が必要になってくると思います。

今までシステムを実装してきた中で行ったJoinの実装パターンを紹介します。

Azure Tableによるデータ検索処理

Windows AzureのTableストレージにおけるデータ検索では、基本的にはStorage Client LibraryのLinq to Azure Tableを使って開発するものの、AzureのLinqでは一部のLinq式しかサポートしておらず大部分のLinq式がサポート外になっています。http://msdn.microsoft.com/en-us/library/windowsazure/dd135725.aspx

そのため、Azure Tableにおいてデータ検索を行う際は、Linq to Objectを並行して利用する必要が出てきます。この使い分けについての基本的な考え方は表示対象エンティティをLinq to Azure Tableで取得し、その後のデータ加工処理をLinq to Objectで行うといった雰囲気です。ただしこの２つのLinqの使い分けでは、Linq to Azure Tableにおける取得可能なエンティティ数に制限がある（1000件未満、クエリ実行時間5秒以下 参考：http://msdn.microsoft.com/en-us/library/windowsazure/dd179421.aspx）ので、この制限にかからないよう十分にLinq to Azure Tableで絞込みを行う必要です。

Windows AzureでLog4Net RollingFileAppenderを使う

Windows Azure上で、Log4NetのRollingFileAppenderによりBlobストレージ上にログファイルを書きだすようにしてみたので、その方法についてまとめです。

やり方自体は単純で、RollingFileAppenderのログファイルの出力先を Windows Azureの Local Storageに設定し（これが意外と面倒）、出力先のLocal Storageの内容をDiagnostics Monitorで転送させてるだけです。またlog4netの設定ファイルlog4net.configはBlobストレージ上に置かれたものを使うようにしました。

CygwinでGit/GitHubを使うための環境構築

最近Gitを使い始めたんですが、コミットメッセージが文字化けるとか色々悩まされたんで、その結論的なものをまとめます。とりあえず、これでCygwinだけを使っている分には文字化けに悩まされずに済みそうです（やってることは文字コードをUTF-8で統一するように設定してるだけですが）

以下セットアップ手順です（既にGitHub上にアカウントを持ってる前提です）。

Azure Table Storageに非サポート型のプロパティを保存する

標準のAzure Table Storageにおいては以下の型のみが保存可能な型としてサポートされており、これ以外のプロパティとして持つエンティティを保存しようとするとエラーになってしまいます。

EDM型	CLR型	詳細
Edm.Binary	byte[]	バイトの配列 (サイズは最大 64 KB)
Edm.Boolean	bool	ブール値
Edm.DateTime	DateTime	UTC 時刻として表現された 64 ビット値 (サポートされている値の範囲は 1/1/1601 ～ 12/31/9999)
Edm.Double	double	64 ビットの浮動小数点値
Edm.Guid	Guid	128 ビットのグローバル一意識別子
Edm.Int32	Int32 or int	32 ビットの整数
Edm.Int64	Int64 or long	64 ビットの整数
Edm.String	String	UTF-16 でエンコードされた値 (サイズは最大 64 KB)

ただ、この制限に従って実際にシステムを作ろうとすると、ビジネスロジック層がドメインモデルとして設計されている場合に、ドメインオブジェクト群をストレージへ保存する際、そのオブジェクト構造をフラットに展開してからデータを保存しなければなりません。また、そのデータを読み込む時もフラットな構造から元のドメインオブジェクトに戻す処理が必要です。

データを読み書きするためにいちいちこんなことはやってられないので、今回はStorage Client APIをカスタマイズして、オブジェクト構造をそのままTable Storageへ保存できるようにします。