デベロッパーズサミット2013（2/14）に行ってきました

約一年半ぶりのfujitaです。こんばんわ。

本日デベロッパーズサミット2013（Developers Summit 2013 Action！）に参加してきましたので、ご報告させていただきます。

参加させていただいたセッションは、

• Androidセキュアコーディング　久保正樹さん、松並勝さん
• 決済だけではないペイパル（ペイパルアクセス活用事例）　PayPal Pte. Ltd, 植野稔之さん
• エフェクティブiOSプログラミング　楽天株式会社　高橋憲一さん
• グリーにおけるスマホアプリ開発〜ネイティブ編　グリー株式会社 開発本部　堀田敏史さん、白倉悠祐さん

の4つです。

以下、私の解釈も交えてしまっていて、かなり乱暴な箇条書きではありますが、レポートとさせて頂きます。
Androidセキュアコーディング
JSSEC　松波さん
・ボランティアで、JSSECの『Androidアプリのセキュア設計・セキュアコーディングガイド』（http://www.jssec.org/dl/android_securecoding.pdf）の作成に携わられている。
・セキュアコーディングガイドでは、ソースコードに重要なコメントを記述するなどし、コピペされてもセキュアなコードを目指している。
・脆弱性の事例とガイドとして、IPAの報告によるAndroidアプリでの脆弱性の報告事例は、2012から急増している。
その背景としては、スマホの普及とアプリの増加、また調査を始めたのが2012年というのが大きな原因であろう。また潜在的な脆弱性はもっとあるだろう。
・脆弱性の報告を見ると、アクセスコントロールの不備などの初歩的なものが多く、知っていれば未然に防げるものが多い。
・JVN（http://jvn.jp/）のiPediaで、Androidの報告は156件。
・JVNからの事例紹介として、以下の事例を元に「脆弱性の原因」、「対策」、「セキュアコーディングガイドでの記述」についての説明。
※事例として取り上げられたアプリについては、現在対応がされているので問題が無いことを繰り返し伝えられていました。

• http://jvn.jp/jp/JVN31860555/index.html
• http://jvn.jp/jp/JVN92038939/index.html
• http://jvn.jp/jp/JVN23328321/index.html

・事例を通し、「知ってるだけで未然に防げる事が多い」、「メジャーアプリでも脆弱性があるケースがよくある」との事。
JPCERTコーディネーションセンター　久保さん
・脆弱性の報告は、発見者に依存するので、脆弱性の種類・アプリなどに偏りが出ている。
・1000アプリをサンプリングし、セキュアコーディングガイドに違反していると思われるものを抽出することで、潜在的な脆弱性の調査をしてみた。
・まとめとしては、「潜在的な脆弱性は結構ありそう」「セキュアに実装するにあたり、JSSECのセキュアコーディングガイドは大事」。

決済だけではないペイパル（ペイパルアクセス活用事例）
PayPal Pte. Ltd, インテグレーションマネージャー　植野稔之さん
・PayPalは、ebayの子会社です。ebayの決済をする為に作られた。
・2012年の決済総額『1450億ドル（13兆円）』
・アクティブアカウント数『1.23億』
・年間決済総額成長率『22%』
・クロスボーダーな取引の割合『25%』
・「PayPal Access」で取得できる「住所」、「TEL」、「メール」といった情報は決済で使われているものなので、信頼性が高い。
・「PayPal Access」を使用する購入者メリットは、「ECサイトへの登録が2秒」「クレジットカード情報をECサイトに渡さないでよい」「同意しなければ情報は渡さない」点。
・「PayPal Access」を使用するECのメリットは、ネットで購入するリアルユーザーの獲得
・仕様としては、OAuth2.0/OpenID Connect Standard 1.0
・「PayPal Access」+「Express Checkout」について。現状ログインと決済ログインの2段階だが、1回のログインですむシームレスチェックアウトを春頃にリリース予定。
・「PayPal Here」についての活用事例1（移動販売で、クレジットカードで購入）
・「PayPal Here」についての活用事例2（移動販売で、クレジットカードを使わずPayPal Hereアプリでの購入）
・「PayPal Here API」について。店舗でレジアプリを持っている場合などに、「PayPal Here API」と連携することで、カード決済を組み込む事ができるようになる。

エフェクティブiOSプログラミング
楽天株式会社　高橋憲一さん
・高橋さんはセカイカメラの開発に携わっていた方で、OpenGLを使う3Dプログラミングが得意。
・おすすめ図書1「エキスパートObjective-Cプログラミング」（http://www.amazon.co.jp/dp/4844331094/）。メモリ管理、GODについてここまで掘り下げて書かれている本はない。
・おすすめ図書2「プログラミング作法」（http://www.amazon.co.jp/dp/4756136494）。
・『エフェクティブiOSプログラミング』というタイトルは、スタートレックのセリフをサンプルにしている筆者と訳者の扇子に惚れた「Effective C++」（http://www.amazon.co.jp/dp/4756118089）のオマージュ。
・アルゴリズムを知ってる人の常識で、劇的な改善ができる。もし知らなくても恐れる事はなく、それをきっかけに学んで身につけ、実践すればOK。
・意識して、効率の良いコード、見やすいコードを見ることで、使っていて気持ち良い（ストレスの少ない、落ちない）アプリにする。
・メモリ管理に気を配る。最近のxcodeではデフォルトのARC。release、retainが必要なくなり、GCのようにパフォーマンスの問題がない。
・iOS4のみ対応しているので、旧来の方法から移行する場合は、iOS3以前のサポートとメモリリークの削減についてどっちを取るか検討する必要がある。
・brigdeキャストについて。
・並列処理について。GCDを活用し、UIを止めないように、動きのスムーズなUIを。dispatch_async、dispatch_once。
・オブジェクト指向を活用しよう。
・テストの話。自動化テストツール「UIAutomation」の紹介。instrumentsでアプリの動作を記録、再生。記録はJSとして残るので、関数・配列を使い複数条件での繰り返し実行も可能。
その他の機能として、ロギング・画面のキャプチャを取る事も可能。
・iOS関連のコミュニティMOSA（http://www.mosa.gr.jp/）。入会金必要だが、良質な勉強会を開催している。
・Appleの豊富な技術資料、WWDCのビデオなど暇つぶしや、参考になるので読みましょう。

グリーにおけるスマホアプリ開発〜ネイティブ編
グリー株式会社 開発本部　堀田敏史さん・白倉悠祐さん
・女性向け箱庭系アプリが事例
・サーバーサイドの開発担当の堀田さん。
・ウェブアプリとネイティブアプリの比較。フローは同じだが、通信のタイミング、表示データのありかが異なる。
・通信のタイミングについては、ウェブは画面ベースで1ページで1通信。ネイティブアプリは、フローベースでUI・画面遷移に応じて必要なタイミングで行う。
・表示データのありかについては、ウェブは通信の度サーバーからデータ配信で、表示はブラウザ。ネイティブアプリは、更新頻度が低いものはローカルに保存。
・通信のタイミングについて。
・タップ毎（都度）の通信。メリットとしては、常に同期できる。デメリットとしては、通信のタイミングでユーザーの動作をブロックしてしまう。
・非同期。メリットとしては、ブロックされない。デメリットとしては、同期されてるわけではないので、クライアント側で、アクションログを管理する必要がある。
・更新のタイミングで適宜同期（ガーデニングでいうと種をまく場所確定時）。メリットは、データ不整合の懸念が少ない。デメリットは、都度通信ほどではないが、ブロックされる点。
・UIフローや、画面の要件にあったタイミングで通信を。
・通信してない時のログとして、クライアントサイドの分析ログ、内部エラーログが大事。また、それをクライアントからサーバーへ送る仕組みの検討も必要。
・データ管理・アセット管理について。更新頻度、データ量に応じて通信回数を
・APIを考える。
・データフォーマットはJSONでやっている。
・クライアントサイドから見やすいように、APIデータのビューワーを開発した。
・APIのインターフェース、エラーコードについては、クライアントサイドとよく擦り合わせる事が大事。
・実装については、ウェブと変らない。
・PHP5.3でEthna2.6
・MySQL5.6で、マスタ・スレーブ・シャーディング。
・Flareで、永続データ・更新頻度の高いものを管理
・Memcachedで、一時的なデータの管理。
・まとめとして、「UIに応じた通信タイミングの設計が大事」「データ管理方針、API連携はフロントエンドとの認識合わせが肝」「webでのノウハウで実現可能」
・フロントエンドの開発担当の白倉さん。
・グリーにおけるウェブとネイティブアプリの違い。
・ウェブは画面ベースで、1ページ1通信。主に開発は1人。
・ネイティブアプリは、フローベースで、場面に応じ通信。通信と表示で分担。
・クライアント開発ではUnityを使っている。
・フロントエンド（ユーザーインターフェース、画面遷移の管理）では、プロタイプのレビューからの要望などにより、処理が複雑化しがち。
・ちょっとした工夫として、遷移図を自動生成するようにした。
・遷移図を自動生成した理由として、「ドキュメント管理が面倒」「コードを統一したい」「新人メンバーの教育が楽」。
・処理があっての条件なので、それを構造化。
・フォーマットはYAML。
・遷移図の表示はGraphvizを利用
・コンバータはRuby。
・結果、「遷移図の管理が楽になった」、「コードがある程度統一された」、「新メンバーの教育が楽に」。
・導入までの障壁は高かったが、収穫は大きかった。

その他
デベロッパーズサミットの入場にあたり、事前にメールでお知らせしてもらっていた参加証をプリントアウトし持参する必要があったのですが、
すっかり忘れていて、直前にiPhoneアプリでネットプリントを利用したのですが、非常に便利でした。
https://itunes.apple.com/jp/app/netprint/id372351201?mt=8