YAPC::Asia Tokyo 2015 メモ

yapc_asia_tokyo_2015_memo.md

YAPC::Asia Tokyo 2015

0日目

The PHP Empire Strikes Back!!

• @uzulla さん

安定の楽しさ！

はてなブックマークのトピックページの裏側

• @skozawa さん

• 祝 10周年

• ネットで盛り上がっている but ホッテントリが被らないようにしたい

• トピック生成: Elasticsearch

  • 記事を一気にやる所から、キーワードを取ってくるように段階を踏むようにした。
  • 要約技術を採用する。

• Significant Terms Aggregation

  • スコア計算方法がいくつかある。今回はJLHを使っている。
  • 指定範囲で頻出する単語がスコアがあがるアルゴリズム。

• トピックタイトル

  • キーワードをいい感じに並び替えるには？
  • 係り受け関係 (Cabochaを使っている)

• 6ノードでさばいている

• 質問しました。

  • Q: 辞書は鍛えているか？
  • A: 鍛えていない。鍛えるスピードより新しい単語が出て来る方が速い。また、鍛えなくても妥当な精度が出ている。

How to create/improve OSS products and its community

• @tagomoris さん

• コントリビュータの管理: コア・外部・メンテナンスの方針

• コミュニティとどのように接するか: 密室で決めない

• 会社による支援: 海外ではよく問われる

• どのような言語で書かれているのか？

• バージョニング: Unstable, Stable を把握できるようにする、0.99でホントにいいのか？

• 常に英語を使おう: ロシア語、わからん！ってのは日本語も一緒やろ。英語以外は却下でもいいくらい。どの国の人も排斥しないってことを表明する。

• プラガブルにするのはコミュニティを広げるにあたって重要

• 良いポイントがあるから広まっている。有名だから広まるなんて、そんなアホな話でもない。

• メンテナンスをしっかり続けよう。

• できる範囲でコントリビュートする。

  • 調整は入る。

• コンテキストを理解しているほうが…ってのがあると思うが。

  • 時間は無限に無い
  • 少ないコストでより良い形に
  • うーん自分で書くか…って判断をしてしまうこともある
  • 今度機会があればお願いしたい、って気持ちを伝える。

• 悲しかったこと・嬉しかったこと

  • moby/moby#12876
  • Fluentd→Docker API 変わった→依存ライブラリでか過ぎね？→ドキュメントが足りねー→hashicorpのライブラリに依存を変えてくんね？→あーかえた→よかった！

• 昔よかったツール→肥大化→切り出したコンパクトな新しいツール

  • 新陳代謝
  • コミュニティ全体に対してはプラス
  • ソフトウェアは入れ替わって行く
  • 全体最適

メリークリスマス！

• Larry Wall氏

• 今年で61歳

• Perl6は15年前(2000年)に発表、しかしがんに白内障…といろいろ大変だった。

• 2についてお話しします

• Second System Syndrome

  • 「クリスマスまで」と入ったけど、何年とはいってないよ！

• 5と6の深い違い

  • 5はPerlのHobbitバージョンだ
  • 6はLotR(ロードオブザリング)だ

• 革命的なことをやるには、いきなり革命的に見えてはいけない。透明である。

  • PerlはUNIXのツールの一つとして動いた。
  • Perl6では正規表現の書式を捨てて行こうと考えている

• 2015年に出すよ！今回こそは！

  • でもエクスキューズがすごかった。

• NFG: Unicode

• NSA

• GLR: セマンティックをシンプルにする

Managing Containers at Scale with CoreOS and Kubernetes

• Kelsey Hightower氏

• いかにコンテナをスケールさせるか？

• 2回、東京にきた。ロボットレストラン最高！

• 課題

  • 設定管理
  • IaS
  • スクリプティングフレームワーク

• シェルスクリプトを越える

• 将来的

  • アプリとマシンを切り分ける
  • そこでk8s

• コンテナを作る時

  • OSをフルに入れる所から始める
  • スケールアップするにはこれは無駄
  • アプリのみに切り分けて、イメージファイルを小さくする。展開も楽だよね。

• k8s

  • Demo: https://github.com/kelseyhightower/yapc-asia-2015

今フロントエンドで何が起こっているのか

• @koba04 Toru Kobayashi氏

• 昔: Good old web -> リクエスト・レスポンス ステートレス

  • JavaScript 無効にしろと言われた時代

• Ajaxの時代

  • JavaScriptが必要になった
  • ECMAScript5

• Coffee Script

  • Rails 3.1で搭載されたのが普及の後押し
  • ECMAScript 2015にも一部影響を与えた

• jQueryだけでアプリを書くのはしんどい

  • Backbone.js フレームワークの登場

• サーバサイド・CLI

  • node.js
  • イベント駆動型

• タスクランナー (not ビルドツール)

  • Grant

• Chrome

  • 28からwebkitをForkしている
  • JIT

• Single Page Application(SPA) の登場

  • TypeScript

• AST

• Webアプリケーション

  • SPAだとSEOに弱い
    • 今はGoogleクローラはJavaScriptを解析してくれるようにはなったからちょっとはまし
  • サーバサイドとのロジック重複問題が出る

• Isomorphic

  • node.jsを使うことでクラサバ両方のコードを共通化する

• Angular.js

  • フルスタックフレームワーク
  • httpやルーターまである
  • 簡単なものをものすごく簡単に書けるのが特徴

• gulp

  • ストリームベースのビルドシステム
  • パイプでどんどんつないで行く
  • プログラマブルである (設定を書くのとは違う)
  • node.js らしいビルドシステム

• browserfy

• Statelesse, Composable, Stream

• ECMAScript 2015 (ES6)

  • その時決まっている仕様を出すために年号を使うようになった
  • サポート状況: https://kangax.github.io/compat-table/es6/

• Babel: JavaScript Translator

  • ES 2015→ES5に変換したりとか
  • ブラウザサポートを増やす時に良い

• TC39: http://www.ecma-international.org/memento/TC39.htm

  • サービスワーカー: イベントベースでのドリブン
    • http://www.html5rocks.com/ja/tutorials/service-worker/introduction/
    • ネイティブでしかできなかったことがWebアプリベースでもできるように
    • httpsのみになる
  • Extensive Web

• React.js

  • ステートレスなコンポーネントに
    • 一番上のコンポーネントだけ状態を持っている
  • 変更耐性をあげる
  • 「このデータの時はこのような振る舞いになるべき」と書いて行く
  • Virtual DOM: DOMはタダの出力先

• Flux

  • MVCをもっと細かく分割してわかりやすいデータフローに乗せている

• Functional Reactive Programming

  • 非同期なデータストリームをプログラムで扱う
  • 宣言的に書く
  • Observer and Observable

• Redux

  • Immutable (どういうことかピンと来ていない)
  • 公式サンプル: https://github.com/rackt/redux/tree/master/examples/todomvc

• 「UNIXという考え方」

• 質問しました

  • Q: フロントエンドで言うImmutableってどういう感じですか？
  • A: 関数型のパラダイムが来ているのと、ステートレス。プロパティ変更検知から解放される、等。immutable-jsが例。

Conway's Law of Distributed Work

• @caseywest Casey West氏

• Pivotal にいます - 重要なメッセージ

• うまくやるには労力・時間がかかる

  • リモート作業時に懸念になる
  • そこをうまくやる
  • ツールとテクニックを紹介します

• なぜ気にするか？

  • 10年やってる

• 効果的なコミュニケーションを通じ時間を削減する

  • 意識的な選択
  • 文化を変革
  • 長期的にはエネルギーの短縮につながる

• 意思決定

  • 過去・当時の情報を見つける
  • あとでさぐらないと逝けない
  • 責任分担
  • コミュニケーションの内容を公開する

• 「いずれリモートワークにしたい」

  • 常にうまく行くとは限らない
  • 永続的なコミュニケーションを取り入れるとより良くなって行く
  • エネルギー、労力はかかるが、報われるものになる。

• ツール

  • テキストチャット
  • chatops (hubot, lita)
  • ビデオコミュニケーション
    • 誰でも聞こえるような、良いマイクを用意する。
    • HipChat Plugin, Google Hangouts, appear.in, sqwiggle
  • 画面共有
    • Scheenhelo (slack), Hipchat, join.me, WebEx
    • 1分以内に始められる(起動できる)ことが大切 手間がかかるとコラボレーションに支障が出る
  • 開発
    • コミットメッセージで会話する これが非常に重要
    • 埋蔵した過去の情報を探るために大切 その時に何を考えていたのか あとの人にコンテキストを受け継ぐ
    • コードレビューにより 60% エラーを減らすことができる
      • Gerrit
    • Digital Progress Board(カンバンスタイル管理ツール)
      • Pivotal Tracker, Trello, GitHub, waffle.io
    • 文章作成・共有
      • Etherpad, Hackpad, Google Docs, GitHub wiki
    • ファイル共有
      • Dropbox, Box, Google Drive, NFS
    • スケジュール
      • スケジューリングが難しい、忙しさが一目で見えることが重要。
      • 時差があることを考えると自動的に決められるとよりよい
    • メール
      • ツールとしては良くない
      • 通知、非同期コミュニケーション、時間に拘束されづらいものならいい。
      • すぐに返事が来ることは期待しない。

• テクニック

  • 全員がリモートワークを体験する・強制する 1週間が目処
    • 実感する
    • 子供がいて家にいるのがしんどい人はコワーキングスペース、喫茶店へ。
    • 会議室で仮想的にやってもいい。ただ、ずるしたらダメ。
  • 時には膝を突き合わせてミーティング。
    • 一緒に飯を食う
  • 会社にいる人も、リモートの人を巻き込みながら仕事をする。
    • テキストチャット、ビデオチャット、等を使って意図して巻き込む。
    • 最初は気が進まないかもしれないけど。
  • Over communicate
    • 積極的に話して行く
  • Share your personality
    • 積極的に自分の個性を出して行く。
    • オフトピックもどしどし。
    • 毎日会えない人でも、より深くお互いを知ることができる。
    • もし問題が起きても、相手の人となりを知ることでより歩み寄ることができる。
  • Exhibit "visible pulse"
    • 自分の存在をはっきりさせる
    • 忘れ去られないように
  • SOT(Standar Operating Time)を決める
    • 基準となるタイムゾーンを決める
    • 本社があるならそこを中心に

• Sociotechnical Theory

  • 社会技術 って訳すらしい
  • 社会と技術は常に結びつけている
  • そこにしっかり投資し価値を高めて行く

• リモートワークとCAP定理

  • 実は適用できる
  • 分散しますしね…

• そしてコンウェイの法則

  • ソフトウェアの品質は組織の品質と相互に影響する
  • CAP定理→コンウェイの法則 逆に当てはめる

• JIRAなんで使わないの？

  • 前は使ってた。でも今使ってない。
  • 欠陥があるのではなくて、JIRAの管理を問題としたい。
  • インストール型はなんでもできすぎて、開発者のワークフローを阻害する可能性がある。
  • Hostedを使うか、あまり変更を加えない。

• 働き過ぎないか？

  • そう言うこと、あるよね。おっしゃる通り。
  • 家族に寂しがられる、とっても寂しがられる。そう信じてる。
  • 「自分を律する」自分のスケジュールを適切に管理する。
  • 責任分担を確認する。特に、自分の責任範囲をよく理解する。
  • 疲れたら休む。飯を食う。エクササイズする。それも自分の責任。
  • メンバーに「帰ったら？」などと声をかけるというのも重要。
  • 人に負担をかけ過ぎない。余裕を持たせる。そして、最後は家に帰るべき。

• SaaSは企業秘密を持ち出さないと信じられるのか？

  • ポリシーを作る
  • センシティブなデータは入れて良い場所を決めた 便利さとはトレードオフ

• ミートアップの間隔は？

  • 四半期に1回が最低限と思う
  • リモートは人間関係構築が大変。

• スマホを使ってリモートワークはしているか、そして推奨しているか。

  • 休み、睡眠時間のコントロールが難しい。横に置こう。
  • 友達や家族がフラストレーションをためてしまう。

Podcastを支える技術、エンジニアのためのWebメディア、そしてCPAN

• @yusukebe

• http://www.slideshare.net/yusukebe/podcastwebcpan

• Podcast中心にやります

• iTunes Store の登録は、簡単だしRejectされることはまず無い。

• 質問しました

  • Q: 録音環境どこがいい？家は電車が近くを走って手厳しい。
  • A: カラオケルームは厳しい。店員さんは来るし、人の歌声もはいる。 @chezou さんによると、反響しにくい小さな会議室が良いとのこと。数千円で場所を安心して確保できる。ただ、下見がちょっと大変かも。

ISUCONの勝ち方

• @kazeburo さん

• 本物の、よくあるWebアプリケーションが課題として取り上げられる。

• 準備編

  • コミュニケーション
    • 会話を重視する。
    • 一箇所に集まってやる。
    • 決まったことはメモとして書き出す。手戻りはタイムロス。障害対応と同じ。
    • メモはスケッチブックとかいいらしい。
  • 時間配分
    • 7時間は短い
    • 1時間は方針・課題整理・プロファイリング
    • 最後の30分は再起動のテストに残す
  • 事前準備
    • Git Private Repo.
    • 公開鍵
    • Wikiにドキュメントをまとめる
      • 作業メモとか
      • アナウンスとか
      • 秘伝のタレとか
    • チャットルーム
    • 過去問を解く

• 当日

  • レギュレーションの読み込み
  • 課題の理解
  • プロファイリング
    • ログ
      • 解析ツールを活用する
      • アクセスログは消してしまえ！本番じゃないんだし
      • slowlog戻し忘れ中
    • アプリケーションのプロファイリング
      • strace
      • tcpdump
    • サーバ負荷
      • まあいつものツールやな
  • サーバ構成の把握
    • ミドルウェアの構成
    • データフロー
    • 罠があるのできちんと把握する
  • チューニングの方向性
    • CPUのパワーを使い切る
    • Cswitch
      • 通信しない、プロセスあげない、データ触らない。
      • いかに「何もしない」アプリケーションにして行くか

• ヒント

  • h2oの利用の検討
  • 重い処理
    • fork, テンプレート処理, 変換, 通信の接続, N+1
  • DB
    • 心にいつもB+Treeを
    • MOTTAINAIの心 (OFFSET)
    • ISUCONはメモリに乗っていても遅いとふむ
  • 初期状態にいつでも戻せるように
  • 変更を都度記録する
  • 前日はよく寝る
  • 諦めたらそこで終わり
    • 最後の5分で伸びることもあるんだ

• 質疑

  • チーム全員で1つのインスタンスをチューニングした方がいい(複数あげてもいいけど提出できるのは1つ)
  • sysctl.conf などの秘伝のタレは最初から適用していいと思う

NASA主催の世界最大級ハッカソンSpaceAppsを運営した話

• 湯村さん

• オープンデータの一貫でNASA主導で始まった 今年で4年目

• 142都市同時開催

Docker３兄弟について

• @toritori0318 鳥居 さん

• 3兄弟の紹介、ユースケースの紹介を中心に進める。

• 3兄弟

  • アルパカさん自身の定義
  • Machine
  • Compose
  • Swarm

• Docker toolboxはBoot2dockerのイメージをマイグレーションしてくれる。

• 3兄弟全てβバージョン！！！

データ分析を支える技術

• @repeatedly さん

• 勉強会で「ソース読むぞ！」って言うと一気に人が減るのでオススメ(？)

• 分析

  • 探索的手法
  • 仮説検証手法

• 基盤

  • RDBMS
    • スタートアップとかのデータが少ない時期。知見が多く、構造も単純。はまりにくい。
    • OLTPに強い仕組みがあだになり、データ量が増えると破綻する。
  • パラレルRDVMS

• 列指向DB

• スキーマオンライト

  • 書く時にスキーマを決めちゃう

• Data Lake

  • スキーマ管理は辛い
  • 一つのでかいストレージにとりあえず貯めて、Data Lakeが適切な型処理をする。
  • HDFSも適用できる

• Hadoop

  • Tez: 気をつけて、遅いときはMapReduceかもよ。
  • Spark: 比較の記事を見るときはTezかMapReduce化は確認。Tezじゃないと不利。
  • もう単一障害点は無い、そんなのは最近の記事はポジショントークだ。
  • 自社で持ちたい？やめろ、やめろ！どうしてもなら、ディストリビューションを採用する。通常は、PaaS等を使った方がいい。

• データの取り込み

  • Bulk
    • EmBulk
    • Sqoop
  • Streaming load
    • Fluentd
    • Flume

• MPP Query Engine

  • Presto, Apache drill

• よりリアルタイムに

  • Apache Storm, Norikra

YAPCあるある

• 人間模様を垣間みた笑いが続くトークだった