ぼくのさんかしたさいしょでさいごのYAPC::Asia Tokyo

YAPC::Asia Tokyo 2015 に参加した。

• Perlに近い環境にいながら最初で最後の参加になってしまったが、行ってよかった。
  • そもそも自分は今Perl使ってないけどよかった
  • ES6やHTTP2など、知りたいと思いながらどうアプローチしてよいかいまいちわかっていなかったフロントエンド界隈の話が聞けた
  • Perl6, Ruby, Scalaの言語設計や並列などちょっと踏み込んだところにも触れられて面白かった
  • mozaic.fmやrebuild.fmで親しんでいる話題が脳内で整理できた
  • はてなの人たちとランチできた
  • CONBUチームのNW設営のデモがすごかった
  • naoyaさんに結構久々にお会いできて仕事の話とかできた
  • 気がついたらいろんな人が便利なビューアーをさくっと作ってて感動した
    • Tatsuhiko Miyagawa on Twitter: "Better Schedule viewer for #yapcasia http://t.co/AVvPsMNOj3"
    • YAPCのハッシュタグを楽に追うページを作った話 #yapcasia - gennei's blog
• H2Oやio.js,Electronのトークも是非聞きたかった
• 941さんはエンジニアだと思っていた
• 懇親会チケットが必要なことには気づいた頃に完売してて悔やまれた
• antipopさんの動画のインパクト
• hitode909さんベストトークおめでとうございます！
• スタッフの皆様、10年間おつかれさまでした！

資料・動画も公開されると思うので、以降はメモ以上のものではありません（不正確な記述があればごめんなさい）

8/20(前夜祭)

『言語開発の現場』

• @hsbtさん
  • GMO
  • Rubyコミッター
  • 社内でRubyを使っているので、Rubyの問題があるとRubyを直してリリースされるのを待つ
  • ビルド、配布、RubyGems、Rakeのマージ
• Ruby
  • 1.8 : MRI
  • 1.9 : YARV,VM化
• いろいろな実装 どこまでがRubyなのか問題
  • MRI,Cruby
  • JRuby
  • mruby
• 開発に関わる人の種類
  • comitter(Ruby Core Team)
  • branch maintainer
  • platform maintainer : 好意でプラットフォームごとのサポートをする
• 権限
  • 権限をもらったらどこへもcommitできる
  • 一度直すことになったら最後まで自分で直す覚悟
• github : proprietaryなのでつかわない
• OSS開発も普通の開発とおなじ
  • write code
  • take care of development resources
  • focus use case
  • release management
• developer meeting : 英語圏developerとの距離の解消
• releaseが大変
  • 2hですむはずが4h(?)かかっている
  • 自動化できてない

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

• @5kozawaさん
  • はてな、はてなブックマーク
  • Elasticsearchを用いたはてなブックマークのトピック生成, 2015
• はてブにおける過去の試み
  • クラスタリング
  • トピック編集
• トピック生成
  • トピック=キーワードの集合
  • ElasticSearch の Significant Terms Aggregation 機能
  • Amazon ElastiCacheのノードが6台
  • JLH score
    • 出現割合を加味したスコアリング
    • 絶対割合変化 x 相対割合変化
  • トピック生成は時間がかかる。2hおきにつくっている
  • 新語が多いので辞書作成が追いつかない
• トピックタイトル生成
  • 要約技術の一種
  • キーワードを羅列すればよいわけではないので並び替える
  • 一つ一つの記事のタイトルはちゃんとしているので、どれかの記事のタイトルを使えばよい
  • 係り受け関係に基づく文圧縮
  • アプリだと短いタイトルのほうがよい。10文字以内が目標
• 毎年のYAPC::Asiaのトピックの抽出には成功している

『技術ブログを書くことについて語るときに僕の語ること』

• @y_uuk1 さん
  • はてな, Mackerel
  • ネットワークの研究室に入ったが、カーネルがやりたくなった
• ブクマを稼ぐ技術
  • タイトルが9割
  • （笑ってて詳細メモるの忘れた）
• 哲学
  • 知識と感動 : どちらを伝えたいのか？
  • ブログ=自己表現 : ポートフォリオとして、キャリアとして見直す
  • 寝かせる
    • 調べる、分からない、を3年くらい繰り返すことも(Webサーバーアーキテクチャなど)
    • なぜ我慢できるのか
      • 金曜の夜に投稿してもブクマされないことは経験でわかっている
      • ブクマ数で評価されて特上寿司が食べられる
  • 普段の仕事もアウトプットベースで考えるようになる : どうすれば技術的に面白く見せられるかを考える
  • 神は細部に宿る
  • 時間をかける : かけてはいけないと誰も言ってない
• QA
  • モチベーション
    • ブクマ数
    • 特定のエンジニアにブクマされるかどうか
    • 会社として書く vs 個人として書く : 自分のブログのほうがモチベーションはあがる
  • 古い記事の修正 : あまりやらない。むしろ新しく書き直すこともある。
  • タイトルしか読まれてなさそうなもの : 傾向まではつかめていないが、内容が丁寧だと読んでもらえる気がする

8/21

『メリークリスマス！』

• PerlのパパLarry Wall
• Perl5(Hobbit)とPerl6(Lord of the Ring)は実は同じ物語
• Perl5
  • Hobbitにおいてはすべてがgreedy
  • 正規表現
  • UNIX文化とうまく融合したことで成功した
  • 多すぎるglobal
• Perl6
  • 3つの大きな改善
    • NFG(Normal Form Grapheme)
    • NSA(Native Shaped Arrays)
    • GLR(Great List Refactor)
  • type system
  • 正規表現依存を弱める？ : ほかの言語は正規表現に移行してきている
  • don't overspecify
  • Supply
  • operators
• お知らせ : 2015年のクリスマスにはリリース予定（ただしバスにはねられたりしたらどうなるかわからない）

『Effective ES6』

• @teppeisさん
  • サイボウズ、Kintone
• Web+DBのES6はmust buy
• ES5
  • 落とし穴の例 : newをわすれるとグローバルがかきかえられる
  • ベストプラクティス、どちらかといえばワークアラウンド
• ES6
  • modern syntax
  • 大規模アプリケーション開発も容易に
  • 後方互換
  • ベストプラクティス・AltJSの一部機能が不要になる
• ES6はいま使えるのか
  • compat table : IE11は対応しない
  • ES6を始める方法
    • とりあえずBabel : Babel REPLで試せる
    • transpiler
      • ES5の機能だけを使うコードに書き換える
      • Babelならブラウザごとにtranspileをやめるタイミングなどもきめられる
    • polyfill : ES6ビルトインクラスを提供する
    • ESLint
• new syntax
  • arrow function:Array.filterにかますときべんり
  • (ES5)assign this to selfのreplace (ES6)スコープ外のthisがarrow func内から呼べる
  • (ES5)プロトタイプベース => (ES6)クラス、継承ベース
  • (ES5)グローバル依存のモジュール、commonjs依存(exports,browserify) => (ES6)export, 静的解析しやすくなる
  • use strictが不要になる
  • (ES5)function scopeしかなかった、巻き上げ(hoisting)が発生していた => (ES6)block scopeができた
  • (ES5)var => (ES6)let,construction
  • default parameters
  • rest parameters
  • destructuring(分割代入)
  • template literal
  • Generator
• new built-in classes
  • Promise : エラー制御改善、非同期の明示
  • (ES5)objectをdictionaryとして使う (ES6)Mapクラス
• 既存クラス拡張
  • Object.assign (shallow copy)
  • サロゲートペア対応
• AltJSは不要になるのか
  • CoffeeScriptは、インデントの書き味以外の優位性は残らない？
  • TypeScriptの型をとりいれるかどうかは議論中

『TBD』

• Matzさん
  • 言語デザイナー
• Rubyの反省点
  • Perlの影響 : 特殊変数
  • LISPの影響
    • intのサイズの問題
    • シンボルとストリングの区別
      • Rubyの思想
        • 使い分けを避けたかった
        • RubyにもProcとlambdaの区別
• アーキテクチャの変化
  • マルチコア
  • スレッドセーフ
    • 人類には早過ぎる
    • immutableをもつ関数型言語が評価されてきた
    • スレッドセーフでない外部のCライブラリから守るためにGILを導入した
• Rubyの今後
  • 新しいconcurrencyモデル(アクターモデル、Rust)
  • Ruby 3.0に入れたいもの : JIT, soft typing
• Rubyと違う判断
  • 高レベル抽象(DSL)
  • 技術トレンドのバランスは振り子
    • GC
    • サーバー vs クライアント
    • パフォーマンス vs 生産性 : シェルスクリプトの再評価
• Streem
  • パイプラインベースの言語
    1. パイプラインの組み立て
    2. パイプラインをデータが流れるイベントループ
  • ピタゴラスイッチプログラミング
  • イミュータブルデータ
  • エラー処理
    • 明示的チェックC,Go
    • 例外処理 Java,Ruby
    • Optional Swift,OCaml
    • デフォルト無視 Streem
  • より少ないデータ構造(<-> 大クラス主義) : 数値, 文字列,配列(ハッシュ、オブジェクトを含む)
  • OSSの新しい知見
    • 言語をつくる連載（日経）でコンセプトだけのプロトタイプを作ったらHacker Newsのトレンドに上がった
    • mattnさんによるGo実装も
  • 応用
    • 実用には遠い : Goのような複雑なチャンネルのネットワークなどは難しい
    • 教育的な効果
    • データ分析
    • シンプルなwebサービス
    • Reactive Programmingっぽいもの
• まとめ : 言語デザインは楽しい
• QA
  • 型
    • 短いスクリプトを書くという理想に反する
    • 「絶対に型を書きたくないでござる」
  • 言語デザインのインスピレーション
    • 既存言語の成功例をとりいれる
    • 既存言語の問題点を改善する
    • 日頃のアイデアを形にする
  • 楽しい瞬間 : 作っている言語でHello Worldが表示された瞬間
  • この業界、コンパイラに対する共感能力高い人が多すぎる

『Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜』

• @hitode909 さん
  • はてなブログ
• イケてるサービス
  • 役立つ、楽しい、早い、かっこいい、イメージが良い
  • 開発を継続する : 一貫した指針などが必要
• 社内フレームワーク
  • Ridge, MoCo : 継承前提, 使うために結構読まないといけない
  • 後方互換性のためのモンキーパッチ
• はてなブログのスクラッチ
  • cho45さん,2011
  • 薄いフレームワーク
  • 読むコードが最小
  • ORM使わない
  • 継承しない
  • 3回コピペするまでは共通化しない(DRY³)
• Service
  • MVCの間で3回コピペされたコードをServiceのname spaceに移す
  • テーブルと1v1にしない
  • 外からみるとオブジェクトどうしの呼び合いにみえる
  • クラスメソッドで済ませる
  • インスタンス化は最低限におさえる
  • 状態が必要ないものに状態を与えない
• オブジェクト指向設計入門
  • 契約による設計 : 事前条件、事後条件
  • 責任外のことをチェックしない
  • 設計としてはよいが、言語的な支援がない
• リファクタリングのためにPerl静的解析
  • YAPC::Asia 2014
  • 特定トークンの置換
• DDD
  • コアドメインに集中する : ソフトウェアにとってもっとも重要な部分
  • レイヤ化アーキテクチャ
    • エンティティは状態をもつので値オブジェクトに寄せたほうがよい
    • 状態をもたないサービスを独立させる
  • 実践DDD
  • 名前
    • 用語集をつくってgitに突っ込む
    • 企画にもコードを見せるが意外に読める
    • コードは変えられるが、ストレージに変更を行うのは難しい

『PietでLISP処理系を書くのは難しい』

• @hnagaminさん
  • KMC
• （Pietでビジュアル化されたソースコードがひたすらでてきて楽しかったがメモるの忘れた）

『esa.io - 趣味から育てたWebサービスで生きていく』

• @fukayatsuさん
  • esa.io
• 大事なこと : いろいろ試して失敗する, 公開する
• 事業化まで
  • esaの原型はQiita:Teamの試用期間が切れて、開発合宿でできた
  • 開発合宿後も毎日がハッカソン
  • ドッグフーディング
  • 知人の会社でつかってもらった
• 反省 : チーム申請を待たせすぎた
• 楽しく開発したい
  • 自分が楽しく開発することで最終的にユーザーに価値を届けられる
  • 楽しさ、モチベーションは複雑で直接コントロールできない
  • 制御可能なものを見極める
• 開発のリズムをつくる : botに毎日bundle updateをさせてpull reqをつくらせる
• bugfixを競技感覚でできるだけ速く本番反映する
• フィードバック駆動開発
  • 5分以内にメール返信
  • 直せるならすぐデプロイする
  • 自分がされて嬉しい事をする
• リリースノート駆動開発 : 自分自身がユーザー
• 週7日間プロダクトに触れる
• ユーザーサポートをやっている人が意思決定してデプロイする
• スケジュールを決めない。要望が多いものから対応する

8/22

『Mackerel開発におけるScalaとGo、そしてPerl』

• @songmuさん
  • はてな, Mackerel
• Mackerelの技術スタック・言語の多様性 : LVS,nginx,Scala,Go,PostgreSQL, Redis, AngularJS, TypeScript
• Scala
  • 静的型 : Mackerelのようなミッションクリティカルな領域では効果あり
  • 実績
  • 記述の柔軟性
  • クリティカルなバグは混入しにくい
  • コンパイル遅い
    • テストが遅いのでマインドチェンジが必要 : 型に守られているのでテスト減る
  • アンダースコア、省略可能などperlににてる
• Go
  • シングルバイナリ、マルチプラットフォーム
  • 用途 : mackerel-agent, コマンドラインツール, Web外形監視
  • manners : graceful restart
  • blogsync (motemenさん)
  • songmuさんリポジトリにOSS副産物
  • コンパイルはやい
  • 型あり
  • クロスコンパイルをちゃんとやるのは大変、というかパッケージングが大変
  • Perlとの共通点
    • 素朴さ、実用性
    • 値に対して型を作れる
    • 継承よりコンポジション、インターフェースのくみあわせ
• Perl : まだ使ってる。Web構築する力はある
• Ruby : fluentd, chef, capistrano
• 自動化
  • 自動化機構は負債になりやすい
  • ツールをテストする
  • ツールの責務をわける
  • デプロイを最悪手動実行できるようにする
  • TravisにpushさせるためにGithubのDeloy KeysとTravisのEncrypting Filesを活用する
• 属人化をふせぐ : 知見のないメンバーに敢えてレビューさせる

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

• @yumu19さん
  • NICT
  • キーボードプロジェクションマッピングなど
• 昨今のハッカソンのテーマはいろいろ : 「家」「オフィス」「100円ショップで買えるもの」
• International Space Apps Challenge : NASA, 世界142都市(日本5都市)同時開催
• 東京
  • 150名程度の参加
  • DMM.make
  • ワークショップも並列開催 : ハッカソン以外の方法でも宇宙・データ・科学などに親しんでほしい
  • Bostonとのコラボしてるチームも
  • H-IIA寿司
• これまでの成果
  • Personal Cosmos
  • Active Space Radar App
  • Dear My Space Debris
  • 衛星これくしょん
  • マー(Marface) : 月面サンダルなど
• 事務局 : 全員ボランティア
• 準備
  • 重要なのは場所決め : キャパ,WiFi,LAN,利用料,物販可否,夜間利用可否などを考慮
  • 収入はスポンサーと物販のみ
    • 物販売上は不確定 : 入金はイベント当日
    • スポンサー
      • 趣旨に賛同してもらう
      • リターンの提供　広告宣伝
      • 訪問、請求書、スポンサー間のロゴのバランス調整など
  • 無断キャンセル対策
    • DoorKeeper
    • 前払いにする(SpaceAppsはできない)
    • 「無断欠席の場合は今後の参加をお断りします」と明記
  • 本部・各拠点との情報共有
    • タイムゾーンバラバラなので、同じオンラインミーティングを月1で3回やる
    • 運営は各地域に移譲
• 重要なこと
  • コミュニケーションの量
  • ドキュメンテーション : 941さん・牧さんのYAPC運営引き継ぎ記事がとても参考になった
• QA
  • 運営で得られるもの : 仲間ができる、居場所ができる、段取り力を養える、達成感を味わえる
  • 苦労したところ : スタッフのうち自分だけ石川に移ったことで遠隔でやるのが意外に大変だった
  • アイデアソンをうまくやる方法 : ブレストやる前に1v1でアイデアをブラッシュアップする
  • NASAや宇宙開発への寄与 : テーマが具体化してきたので、NASAの本気度も上がってきたと感じる

『データ分析基盤を支える技術』

• @repeatedlyさん
  • TreasureData
• (追い切れなかった・・)
• Data Analytics Flow: collect, store, process, visualize, report, monitor
• RDBMS
  • single server
  • popular, huge ecosystem
  • ETL(extract,transform,load)
  • online transaction
• parallel RDBMS
  • optimized for OLAP workload
  • Netteza,Teradata,Vertica,Greenplum
• columnar storage
• compute nodeにstorageがくっついているのでwriteが待たされる
• distkey, sortkey : 設計ミスるとノード間通信が発生してしまう
• schema management
  • Schema on Write(RDBMS)
  • Schema on Read(Hadoop)
  • Data Lake Patterns : HDFS
  • Apache Hadoop
    • MapReduce
    • Apache Tez : DAG based
  • ELT extract, load, transform
• superstition
  • "SPOF"
  • "cannot build from a scratch"
• tools
  • ingestion tools : bulk load / streaming load
  • bulk load tools : Embulk, Sqoop
  • streaming load tools : Fluentd, Flume
• MPP query engines
  • Schema on Read
  • "SQL on Hadoop"
  • Impala
  • Presto
    • backends:Cassandra,MySQL,..
• Apache Storm : low latency, micro batch
• Norikra
• Apache Kafka : distibuted messaging, pull(stream control)
• Amazon Redshift, Kinesis
• Google BigQuery, Dataflow
• Treasure Data (Data Lake)
• Resouce Model trade-off
  • Fully guaranteed: non boost mechanism
  • Guranteed with multi-tenanted
  • Fully multi-tenanted
• use service/build a platform
• Tableau (visualization)

『Parallelism, Concurrency, and Asynchrony in Perl 6』

• Jonathan Worthington
• Supply is the dual of seq
• react : scalaのreactと同じ？違う？

『HTTP2 時代の Web』

• @Jxck_ さん
  • HTTP2のgolang implementation
  • mozaic.fm
  • http2study : issue-thonなど
• 国内のHTTP2界隈のプレゼンス
  • nghttp2
  • H2O
  • ほんとうにRFCになった : 日本のコミュニティへの言及もされるほどの成果が出た
• HTTP2は策定フェーズから使うフェーズへ
• webのパフォーマンス
  • 現状
    • コンテンツサイズ 100 reqs, 2MB/page
    • 帯域増加よりレイテンシの削減の効果が大きい
  • アプローチ
    • Round Trip Timeを減らす : 物理的に近づける
    • Round Trip を減らす : アクセスを減らす、キャッシュする
• HTTP1
  • header : テキストベース、重複が多い(UA)、圧縮不可
  • TCPを毎回確立
    • head of line blocking: 1つ詰まると後続が詰まる
    • ブラウザはドメインごとに6本同時に接続
  • 高速化のためのノウハウがあったがbad hackだった
  • TCPのhackになるとkernel levelで、手を入れられない
• HTTP2
  • バイナリフレーム : パースしやすい、分割可能
  • GETなどのsemanticsは後方互換
  • HPACK
    • Huffman圧縮
    • 頻出ヘッダを共有
    • 送信済みデータを再利用
    • 圧縮率は実装次第　http2studyでは8割圧縮
  • コンテンツ優先度制御 : 画像よりCSSが先に届く、など
  • head of line blockingの解決 : コネクションを使い切る
  • Server Push
    • JSなどの依存コンテンツをブラウザにキャッシュさせる
    • cache control :実際にはbrowserのcache領域の奪い合い(48hで78%の人が使い切る)
    • Service Worker
      • 実装はまだないが議論中
      • HTTP2 Pushを受け取れる予定
      • フロントエンドのプロキシとしてjsを動かす
    • HTTPがPushのセマンティクスをカバーする
• 検討事項
  • HTTPS
  • performance
    • そのサービスのボトルネックは本当にHTTPなのか?
    • response timeだけでperformanceを測れる時代は終わった
    • バックエンドの最適化をフロントエンドが台無しにすることがある
    • 数値化しにくい
  • 実装・インフラはどうなのか?
    • ブラウザによる
    • HTTPS終端問題
  • HTTPS対応はどうなのか?
    • 暗号化の機運が高まる
      • NSAのPervasive Surveillance(広域盗聴)問題の告発（スノーデン）
      • 証明書取得の敷居を下げる動き
    • HTTPS化前提とするブラウザ仕様も : HTTPであっても暗号化する、など
  • HTTP1と戦っているのはhyper giantだけなのでは? : hyper giantでなくても複雑なアプリはある
  • 導入の敷居は高いのか? : セマンティックス互換なので入れて抜くことも可能
• 今後のHTTP2の動き
  • TCPの置換
    • TCPの限界：パケットロスで再送
    • QUIC(over UDP) : 既に使っている可能性もある
  • Nginx 2015末にHTTP2対応予定
  • IETF in Yokohama