2014-08-31

YAPCに行ってきた

YAPCに行ってきました。Perlのセッションを避けたつもりは無かったのですが、モバイルアプリ開発やデータ分析のセッションに出ていたらほとんどPerlの話はありませんでした、適材適所というか、普段Perlを書かない人間には参加の敷居がどんどん下がっている印象。

Google BigQuery で DWH 構築

BigQueryといえばGoogle Analyticsのプレミアムプランの印象が強くて、100万JPY/month払って使う物と考えていたが。自前DWHのストレージとして使うととても安く、どんなクエリでも高速に帰してくれる奴だと知った。今丁度データ分析プラットフォーム構築業をしているので、休み明けにでも検証したい。
https://speakerdeck.com/naoya/google-bigquery-falsehua-number-yapcasia

JSON SQLインジェクション脆弱性と、そこから学ぶセキュアプログラミングの原則

構造化されたクエリパラメータをパースできるようなおしゃれなWebアプリケーションフレームワーク、使ってみたいと思った。

そんなにビッグでもないデータ処理手法の話

fluentdの圧倒的人気。この分野は自分が素人なので、どんなミドルウェアがあるのか知れたのはよかった。BigQuery等の登場によりデータ保持コストとコンピューティングリソースコストがこのまま下がり続けると、サンプリング調査や信頼区間といった統計的な手法を忘れて常に全数調査で良くなる、みたいな話をHUBでssig33とした。
http://www.slideshare.net/tagomoris/handling-not-so-big-data

モバイルアプリとAPIのありかたを考える2014

良く見る画面だなと思ったらParse.comのデモだったり。
JSON-RPCのバッチリクエストの話は、これはシンプルさを捨ててパフォーマンス(バッテリー効率、処理速度)を取るというアプローチなので、モバイルアプリなら全然ありかなと思った。

curlでターミナルから打つのが大変になる等のデメリットはあるが、クライアントが任意にリクエストを一つに纏められるというのが大きい。アプリ起動時だとユーザーのステータスやイベントの有無を取得したり複数のAPIを叩くというのはよくあるし、バッテリー効率を考えたらユーザーの操作ログみたいな物は纏めて送れた方がいい。サーバー側の設計の話はあまり無かったけど、APIコールのコストをけちって、貪欲なレスポンスを返さなくても良いので、サーバーAPIの粒度を小さくできるのもメリットかな。

あと、この話を聞いてる最中に自前ライブラリのバッチリクエスト対応をした。

Mobile Application Development for Perl Mongers [ninjinkun x gfx]

いい話だった。アプリ開発にgit-flowを使うの、仕様フリーズしてQA期間がありつつも次のバージョンの開発もする場合は確かにそうだなと。MVVM重要、Reactive Cocoaは後でチェックする。

その他

YAPCサイトのトークスケジュールの画面、iPhoneから見ると [ビギナー]とか[レギュラー]の難易度表示が無いの、罠だった。
大学内にHUBがあるのやばい。

まとめ

CONBUとスタッフの皆さんありがとうございました。



このエントリーをはてなブックマークに追加

2014-08-30

jquery-jsonrpc2.0のバッチリクエストとPromise対応

オレオレJSON-RPCライブラリがバッチリクエストに対応していなかったので対応した。こんな風に書けるようになった。
$.jsonrpc.defaultUrl = '/rpc';

// Send 3 requests at once.
$.jsonrpc([{
    method: 'getEventStatus'
}, {
    method: 'getUserStatus'
}, {
    method: 'sendLoginStatus',
    params: {status: 'login'}
}]).done(function(responses) {
    results.forEach(function(response) {
        if (response.result) {
            doSomething(response.result);
        } else {
            handleError(response.error);
        }
    });
}).fail(function(error) {
    // timeout or 503 or bad response
});
なぜ今になってメンテしたかというと、モバイルアプリはクライアントが任意に複数のAPIコールを一つのHTTPリクエストに纏められた方が良いよねと最近思う様になった*1 のと、今日のYAPCのセッションでJSON-RPCのバッチリクエストについて説明があったので。YAPCの感想はまた次のエントリで。

あとbowerのリポジトリを眺めていたら、WebSocketを使う物を見つけたのでこちらの方がおすすめです。

脚注:
*1: Orreily「ハイパフォーマンスブラウザネットワーキング」の影響

このエントリーをはてなブックマークに追加

2014-08-04

ハイパフォーマンスブラウザネットワーキング輪講を社内でやっている話

ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化
Ilya Grigorik,和田 祐一郎,株式会社プログラミングシステム社

オライリージャパン
売り上げランキング : 94924
Amazonで詳しく見る by AZlink
O'rreilyのハイパフォーマンスブラウザネットワーキングは日本語版が発売されたのを機に輪講形式で社内勉強会をやっている。先週の時点で8章の「モバイルネットワークの最適化」が終り、丁度折り返し地点である。

なぜ輪講形式にしたか

本の内容は、光ファイバーや無線の規格といった下のレイヤからHTTP2やWeb RTCの上のレイヤまでカバーしている。その範囲からして、アプリケーションエンジニアだけでやるよりも、インフラの人に解説してもらった方が面白いのでは、と思ったから。

例えばTLSの章に出てくる証明書チェーンの最適化のくだり、インフラとアプリで分業が進んでいるとアプリエンジニアは運営しているサービスの証明書チェーンがどうなっているかなんて意識していないだろう。TCP最適化の所には「サーバーは最新のカーネル使え」とあるがフロントのエンジニアにはどうしようも無い。本に載っているテクニックが採用可能かといった議論するには各分野に詳しい人がいた方が良い。

モバイルアプリ開発者が読んで得られる事

今の時点で書ける所を。特に5章から8章はモバイルアプリ開発者には面白いはず。TCPやUDPは他にいくらでも本はあるが、アプリ開発者向けに無線技術、モバイルネットワークの解説があるのは本書ならでは。

例えば自分の場合

  • 移動していれば接続基地局は切り変わるはずだが、TCPのレイヤで見るとサーバーと繋がったままに見えるのはなぜか
  • モバイルアプリでもGeoIPで良い感じに端末のいる都市が取れるのはなぜか
  • 位置情報を送り続けるアプリを適当に実装すると、あっという間にバッテリーを食いつくすのはなぜか

といった前からの疑問が解決した。バッテリーを無駄に消費しないためには、実際にどう実装すれば良いのかという知見と失敗例は参考になる。

あと、WebRTCに入門してみると必ず出てきて、ネットワーク初心者に混乱をもたらすSTUNやTURNなる謎のワードも前半のNATの章に解説がある。XMLHttpRequest等のブラウザに特化した話は後半になるまで出てこないが、いきなり後半をやるよりも最初から目を通していくのが良いと感じた。

普段なにげなく使ってはいるが中身の動作は知らなかった、という部分がどんどん埋められていく感覚が気持ちいい。

まとめ

カバーしている範囲が広いだけに、アプリ、セキュリティ、インフラ各々得意な分野が異なる人で集まって議論すると面白い。
後半もがんばるぞいという事で、参加者の皆様もいつもありがとうございます。

このエントリーをはてなブックマークに追加