デブサミ2013メモ 【14-A-4】グリーにおけるスマホアプリ開発～ネイティブ編

From Evernote:

【14-A-4】グリーにおけるスマホアプリ開発～ネイティブ編 Clipped from: http://event.shoeisha.jp/detail/1/session/4/

堀田敏史　グリー株式会社 開発本部 Japan Studio統括部 第1プロダクション部

白倉悠祐　グリー株式会社 開発本部 Japan Studio統括部 第1プロダクション部


＝＝＝メモ＝＝＝
サーバサイド
Webアプリとネイティブの違い

通信タイミング

     ウェブは画面ベース

     ネイティブはフローベース、必要なタイミングで行われる
表示データ(アセット)のありか

     ネイティブだとローカルにキャッシュできる

通信タイミングを考える
都度通信
非同期通信
更新タイミングで適宜通信

通信していない時のログ
クライアントで集めて、適宜サーバへ送信する必要あり

データ管理
更新頻度が低い

     キャッシュ
更新頻度が高い

     適宜通信

マスタデータの同期
最初に全部
更新分はテーブル単位でハッシュ値比較して、更新分だけ同期

アセットの同期
最初は全部（容量はコントロールすべき、全部やったら大きすぎるなど
更新分はアセットひとつ単位で同期
アセット管理のテーブルをマスタ上に持ってる雰囲気

APIの構成
JSONフォーマットでデータをやり取り
クライアントとの擦り合わせが重要
Webと同じ技術

     Php,MySQL,flare,memcached

通信タイミングの設計が重要



クライアントサイド

通信と表示で役割分担して開発

使ってる技術
Unity
Gree unity platform
Lightweight swf


ちょっとした工夫

遷移図からコードを自動生成

考えたこと
共通項は何か？
どこまで自動生成するか？
どれくらいなら使いやすいか？

Yamlで遷移を記述
Graphvizで図式化
rubyのコンバータ(独自)でC#のコード生成

良かったこと

遷移図が整備されているため、新しく入った人にも説明しやすい

　これ見といて、で済む

全体のコードに統一感ができて、読みやすい

デブサミ2013メモ 【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～

From Evernote:

【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～ Clipped from: http://event.shoeisha.jp/detail/1/session/9/

幡山五郎　オムロンソーシアルソリューションズ

社内で運賃計算ソフトウェアの開発部署でプログラムのデバッグを担当していました。現在は、社内開発現場への形式手法導入プロジェクトの主担当をしています。

＝＝＝メモ＝＝＝

運賃計算の膨大なテストケース

乗換

特別料金

割引

など、色々なルールがあって、テストケースがあまりにも複雑

西船橋とか鬼門

過去

積み上げ式で属人性が高い

今（運賃検証システムという名前）

まず全体を定義

電車の乗り降りをパターン化(8種類

すべての駅をあてはめると10^40

それから3段階の絞り込みを行って10^8ぐらいまで減らす

利点

積み上げでは見つからないパターンがみつかる

絞り込みに理由があるので、なぜそのテストを行っていないのかに答えやすい

テストの実施

一回流すのに3週間ぐらいかかる

検証用のソフトウェアを独立で開発して答えを突き合わせる

両方間違っているけど、たまたま一致するケースがある

      別のチーム、別の言語、別のプログラムでやって、同じバグが起きにくいようにする

実機と検証用で制約が違う

処理時間50ms

メモリ20MBなど

検証用は制約が緩いため、原則通りのアルゴリズムで計算できる

     駅の増加などでも変更不要

     実機用アルゴリズムでは対応してないパターンにも対応可

最終的に仕様書の問題が残った

VDM++で仕様を記述

        仕様書の暗黙知が列挙できた

デブサミ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ストレージ上に置かれたものを使うようにしました。