YAPC::Asia 2014 2日目の感想とノート #yapcasia

YAPC::Asia 2014、大変な盛り上がりの中で終了しました。スタッフの皆さん、お会いできた皆さん、そして講演を聴きにきてくださった方、どうもありがとうございました！

とはいえ、まだ気持ちが落ち着いていないな、というのが正直な所です。ほとぼりを冷まして、改めて振り返る時間を作りたいなと思っています。

その前に、記憶が消えないうちにまとめたいノート、今回もアップしておきます。

突然ITインフラを任された人のための…監視設計入門

• 別途エントリ上げます！→あげました「YAPC::Asia 2014 に参加してトークして飲み切ったら夏が終わった #yapcasia」。

半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情（5.6対応）

• uzulla さん

• 感想
  • うずらさん全部持って行った！
  • 技術の内容で笑いを取るの、やっぱり高度な事だと思う。
  • ベストトーク賞 1位 おめでとう！！！

昼飯

• 相方とぷぷくさんとHUBでカレーを食べた
• うずらさんのセッションの説明をしていた
• エンジニアを夫に持つ非エンジニアの妻対談を聞いてた
• カメラのレンズの稟議がより厳しくなった

地域.pmミートアップ 2014

• 感想
  • 1人じゃない！ってのは大切だなと思った
  • 各地の地域.pmに遊びに行って地酒飲みたい

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

• あらたまさん
  • OpenAPI, Proxyなど
  • アプリも作ってるよ
• 感想
  • JSON RPCによるバッチ通信は積極的に使いたい
  • 早いのは感覚で凄く良くわかった
  • できれば数値で比較してもらえるとより良かったと思う
• あるある
  • 通信時のブロッキング: ウザイ
  • たどたどしいサーバプログラム: 遅くて辛い
• MBaaS
  • 知れ渡っているけどあまり使われていない感
  • 今回はParseを取り上げる
  • MBaaS + PaaS
    • Herokuっぽい
    • Heliosってどうなった？
  • アプリ開発に集中できる
  • データ同期が容易
  • DBはスキーマレス

• Dropbox Datastore API

• JSON-RPC 2.0
  • POSTのみ
  • URIは1つ(渡すデータで挙動を定義)
  • とりあえずたくさん送りつける際に、いい感じ。
  • 複数処理を組み立てやすい…バッチ処理しやすい
  • ひいては通信コスト(オーバーヘッド)を下げられる
    • ユーザを待たせない！
  • 言語の実装状況
    • Batchに対応しているものが思ったほどないらしい
• まとめ
  • システム都合でブロックしない バッチ処理で
  • ユーザのための理想に近づきつつある現実

Changing the tires on a moving car: a case study in upgrading legacy architecture

• Andyさん

• 感想
  • 規模に応じてどのように泥臭く取り組むのか一つの事例として参考になった。
  • スケーラビリティを出す仕組みの選定はどこも苦しんでいるのを知って、自分が苦しんでいるのも不思議な事ではないのを理解した。
  • かなり密にパフォーマンス測定をやっていて、エビデンスベースで進める大切さを再確認した。
• git
  • でかいオブジェクトのセットの中にある
• リポジトリサーバ
  • リポジトリ1個なら楽勝
  • GitHubの規模の数値やばい
    • ファイルサーバ 27台
    • シンプルにはできない状況
  • 答えはいつも変化している
• Grit
  • 2007年にできた。GitHubに近い。
• GFS
  • スケーラビリティが出なかった
  • Smoke
    • Gritをオンラインでできるようにした
    • ただあまりうまくいかんやった
• Gitの歴史
  • LinuxカーネルはBitkeeperで当初はバージョン管理されていた (OSSではない)
  • Shared Library ではない、エラーハンドリング、メモリ管理もやばかった。
  • JGit は…厳しい感じ
  • libgit2…Visual Studioなどで使える
  • Rugged
  • Git-Raw (Perl)

• Plaggable wire protocol

• Gitは何がstupidなの？
  • エンコーディングは気にしない(中身の種類に関知していない)
  • Smokeも同様
  • 日本語の自動認識はがんばって改善しています！日本企業スマン。
• 一気に更改はできないけどいじらないといけない
  • Graphite を使って全コール記録(回数・所要時間)
    • パフォーマンスを確認
  • Recap
    • 同時に新旧のシステムを動かす(一度に入れ替えなくても良くする)
    • 仮説を立てて取り組んだ

Mobile Application Development for Perl Mongers ninjinkun x gfx

• ninjinkun さん
  • Fablic (Fril) – 女性専用アプリ開発
• __gfx__ さん
  • Cookpad
  • モバイルアプリのためのライブラリ開発・環境構築
  • 大人数・多くの会社での開発の生産性向上をどうするか考えている
• 感想
  • デバイス毎、特にAndroidの移動機のテストはどうやっているのか気になった。(HUBで聞くんだった)
  • ユーザビリティテスト、感覚の言葉を論理的に整理する流れをより詳しく知りたくなった。
  • 自分がゲーム開発をやっている時はデバッガさんがテスト項目で表現しきれないパターンのテストもしていたけど、他の会社ではどうしているのかもう少し知りたい。
• Client-Frontend Engineering (ninjinkun)
  • UIデザイン
    • UIはエンジニアが実装する
    • エンジニアがデザインに関わる
    • ペーパープロトタイピング
      • 合宿やりました！
    • モックを作ったらテスト
      • 開発は男が多いが使うのは女性
      • 女性スタッフから使ってもらって意見を聞く
      • 組織として重要視している
    • 難しい
      • 状態の同期 (例:ページの間)
  • フロントエンド技術
    • リアクティブプログラミング
  • オープンソース
    • COCOAPODS
    • Magical Record
    • Active Android
    • Android Query
    • Android Bootstrap
    • Androidなら、Google Playにデモをあげてしまおう！
• Client-Backend Engineering (gfx)
  • コミュニケーションコスト
    • 機能別で部署ができている
      • それをマージしないと行けない
      • 仕事が殺到 精神衛生上も良くない
    • 各チーム内である程度開発してもらう
      • アプリファースとチームは中枢の開発やリリースマネジメントに集中できる
    • 我々の冒険は始まったばかりだ！
  • リリースサイクル
    • Androidアプリはリニューアルした
      • やばいバグがあった
      • ロールバックできないので死ぬ
    • アプリの頻繁なリリースはユーザをいらだたせる
      • Webアプリのように随時とは行かない
      • 頒布方法が違う
    • 開発方法を変える
    • Branching Model
      • マスタブランチにマージ＝いつでもリリースされる訳ではない
      • git-flowベースで、フリーズをするというプロセスを取る
    • PR Based 開発
    • KISS
  • サーバサイド開発との差異(CI)
    • UIのテストをどうするの？
      • 若干ツールを使っているけどTDDにはならない
    • リリース作業
      • 複雑怪奇: プラットフォームへのアップデートが手動
      • リードタイム 1〜2週間
    • クラッシュモニタリング
    • ビルドスクリプト

• エンジニアは問題がないと生きて行けない Good Problem がある会社に

• Talk Show
  • CI基盤はTravis(Fablic)
  • カバレッジ取ってる？とってないねー
    • OSのバージョン
    • カバレッジ有効にすると落ちる(Googleの人は使ってるの？)
  • Perlから移ったけどどうよ
    • フレームワーク
    • 成熟してないのかな？
    • AndroidはActivityがステートレスだけれどトランジッションがリッチ。これ合ってない気がする。
    • Androidの次のバージョンから改善される模様
    • アプリはステートフル
  • Perlコミュニティについて
    • モバイルアプリにもこの文化を持って行きたい！

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

• tagomoris さん

• 感想
  • データマイニングミドルウェアのサーベイ資料として凄く参考になった。
  • もりすさんの物事のモデリングスキル、いい意味で盗みたい。
  • 20分では惜しい。
  • 自分はJVMから10年前に逃げたけど、ここでまた対面する覚悟をそろそろ決める時期が来た。
  • ベストトーク賞 第2位おめでとうございます！
• ログなどを何らかの処理にかけて分析しフィードバックする時の流れ
  • ストレージサイズ
  • スループット
  • 構造
  • 圧縮
• データ量
  • 必ず上下する 正確には求めるな
  • 1回にどのくらい読んで吐き出すか
    • GB未満級: RDBでよくね？
    • GB〜TB級: これが問題
    • TB級: Hadoopで！専門家に任せよう (これがビッグデータ！)
• GB〜TB級 (ビッグでもない)
  • うっかり取ってGB級
  • メモリに乗せるなら考えとこう
• どうやって処理するの
  • 特性を見抜く
  • Hadoop
    • 全体のスループットを稼いでいる
  • Apache Spark
    • オンメモリ
    • 機械学習・グラフ処理
  • Apache Tez
    • Map Reduceを置き換える勢い
  • Stream Processing
    • Norikra !!!

• JVMに支配されている！

• ノウハウをどんどん共有して行こうぜ！注目している視点を明確にしてみよう。

• DAG, RDD, MPP

LT

• Perlハッカーズハブ、一緒に書きませんか？とのこと。
• LTをどう進めると楽しめるか、参考にしながら聞いてた。

キーノート: エンジニアとして生きる

• @typester さん
  • kamakura.pm
• 感想
  • 話を聞きながら、僕の今置かれている状況は、実は自分自身で納得しているんじゃないかと考えたりした。
  • 仕事を請ける方式は、様々な技術に触れるチャンスと考えられる点、今の仕事を通じて痛感している。
  • 後半から前を向いて話してもらえるようになってよかった。