Skip to content

Instantly share code, notes, and snippets.

@koemu
Last active August 29, 2015 14:27
Show Gist options
  • Save koemu/b7c9a418b4f48d7f7d5d to your computer and use it in GitHub Desktop.
Save koemu/b7c9a418b4f48d7f7d5d to your computer and use it in GitHub Desktop.
YAPC::Asia Tokyo 2015 メモ

YAPC::Asia Tokyo 2015

0日目

  • @uzulla さん

安定の楽しさ!

  • @skozawa さん

  • 祝 10周年

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

  • トピック生成: Elasticsearch

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

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

    • キーワードをいい感じに並び替えるには?
    • 係り受け関係 (Cabochaを使っている)
  • 6ノードでさばいている

  • 質問しました。

    • Q: 辞書は鍛えているか?
    • A: 鍛えていない。鍛えるスピードより新しい単語が出て来る方が速い。また、鍛えなくても妥当な精度が出ている。
  • @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: セマンティックをシンプルにする

  • Kelsey Hightower氏

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

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

  • 課題

    • 設定管理
    • IaS
    • スクリプティングフレームワーク
  • シェルスクリプトを越える

  • 将来的

    • アプリとマシンを切り分ける
    • そこでk8s
  • コンテナを作る時

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

  • @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)

  • Babel: JavaScript Translator

    • ES 2015→ES5に変換したりとか
    • ブラウザサポートを増やす時に良い
  • TC39: http://www.ecma-international.org/memento/TC39.htm

  • React.js

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

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

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

  • 「UNIXという考え方」

  • 質問しました

    • Q: フロントエンドで言うImmutableってどういう感じですか?
    • A: 関数型のパラダイムが来ているのと、ステートレス。プロパティ変更検知から解放される、等。immutable-jsが例。
  • @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回が最低限と思う
    • リモートは人間関係構築が大変。
  • スマホを使ってリモートワークはしているか、そして推奨しているか。

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

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

  • Podcast中心にやります

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

  • 質問しました

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

  • 142都市同時開催

  • @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
  • 人間模様を垣間みた笑いが続くトークだった
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment