• Home
• About
• Contact
• Archive

今日はYAPC::Asia TOKYO 2015 Day 1 の日です

今日もビッグサイトの近くにおります。gihyo.jpさんのレポートも更新されていますので、ぜひご覧くださいませ。

オープニング

• @yapcasia 使ってね
• 5トラックあるよ
• タグは #yapcasia[A-E] でわけてね
• 同時通訳あるよ
• wifiのトラフィックレポートあるよ
• ベストトーク投票してね
• 6Fでランチあるよ（300食）。明日はランチセッションも別であるよ
• 懇親会18時からだよ
• スポンサーには感謝しましょう
• blogを書くまでがYAPC

Larry Wallさん 「メリークリスマス！」

• Larryは今年61才
• 「2」にまつわる悪いことがあった
• 「6」でも「.pl」でもない話をする？
• トールキン　ホビット物語、指輪物語
  • 6本の映画。3*2本
  • 3+2 = 5 (!) Perl 5は決戦の行方
• Perl5は成功し、今でも成功を収めている
• Perl5はホビット物語、Perl6は指輪物語
• どちらも「15」年の労力
• N年かかったかどうかは、過去のことであれば関係ない
• 「2つのパーティー」「山を登る旅路の物語」
• 指輪物語はホビット物語から盗んだ点が多い
• Perlも成長の物語
• 様々な敵 - 「Wood Wide Web」
• Second System Syndrome を克服した Perl6
• Perl6はPerl5から色々盗んでいる
  • シジル
  • 簡単なことは簡単に
  • 実践的
• Perlが好かれているのは表面上ではなく真相の部分
• Perl6は表面の部分は代わっている
• Perl5には欠点がある
• Unixの正規表現やawkの型、Cの演算子
• Perl6では正規表現を再設計。Perl6のパーサをパターンで書ける
  • 他の言語はPerl5の正規表現を真似ているのは皮肉
• Perl6のいいところは？ → 経験しないとわからない
• どうやるかより何をやるか
• 型 - Mooseのようなもの。Meta Object Protocol
  • 今までの言語でここまで柔軟なものはない
• multi path parsingを整理
  • 正規表現 「//x がデフォルト」「パターンはstringではなくlanguage」
  • 1 path parsing 言語ごとに切り替える「Mixins」
• 単位元の扱い、大きな整数
• 言語を設計することは世界を設計すること
• 仲間。IRCには200人がログインしている
  • トロールもいるが仲良くしようとしている
  • 意見が違ってもいいけど仲良くしたい
• Perl5 スレッドとグローバル変数
  • BEGIN, CHECK, INIT, END : フェーザー
  • CHECK コンパイルの終わり、INIT ランタイムの始まり
  • CATCH、CONTROL 例外処理
  • signal(SIGINT).act: { ... } プリミティブとして
  • マルチコアに対して対応
• 0, 1, *+* ... * フィボナッチ
• my ($a, $b, $c) = 42 xx * lazy list
• contextの決定は実行時
• 実行時例外 : pythonよりクリーンな言語にできる
• 実行時の字句解析
• ANNOUNCEMENT!
  • christmas??
  • 2015!! の予定のつもりで頑張ってる
  • ボランティアなので。人生の方が大事だよね
• 機能を固めてる段階。今後は安定版のメンテも行う
• まずはrakudo。MoarVMも
• -Ofun
• Perl6のリライトの3分野
  • NFG : ユニコードのNFD, NFC
  • NSA : 科学用行列計算
  • GLR : セマンティックの単純化。リストのリストをできるよう
• 「正しく失敗する」
  • Perl6は失敗すると想定していた
  • Perl5は欠点があるが使われている。Perl5のよくない部分を直す
  • boot strapのPerl6コンパイラはまだ
• ユーザの邪魔をしない言語。自然言語のような言語
• 指輪物語から得たことは多い
• Perl7の設計できるまで長生きするかもね。
• パーティーを楽しみましょう！

aerealさん、灘友さん「世界展開する大規模ウェブサービスのデプロイを支える技術」

• Miiverse
  • 世界展開。リージョン跨ぎ
  • Wii Uや3DSのアバターサービス
  • PC、スマホからも利用可能
  • 全てをWEBベースで実装
  • ゲームからAPIを叩くことも。専用ライブラリも
• インフラはHatena、クライアントはNintendo
  • ローカライズや運営は海外ごと
  • JS/US/EUの3リージョン構成
• Proxy server, AppServer, DB
  • DBはマルチマスタで相互レプリケーション
  • PC版はUSリージョンのみ
• Timeline, Empathy, Notificationを処理を分離。RESTで
• Capistrano2 + Git : いわゆるpull型
  • 海を越えると git pull は辛い
  • Gitサーバが耐えられなくなる
• Git slaveを用意する
  • lsyncdでinode監視してrsync
  • ファイル数多すぎてlsyncdの上限を超えた事件
  • rsync中のgit fetchで配布物がサーバ毎に変わる事件
• ロールでデプロイを分ける。ランダムスリープ
• デプロイ対象サーバの管理は Mackerel APIを使って
  • net-sshが負荷でセグフォするなど
  • サーバ毎にroleを分けてる
  • サブシステムはMackerelでAutoScale
• 内容による手動対応も多い

ここからバトンタッチ。

• 昔はRedmineで開発していた
• GitHub Enterpriseを導入
• コードレビュー用の ghe というリモートを別に用意している
  • 2箇所に push が必要
  • Merge pull requestボタンは使わない (GHE上でマージすると HEAD の不一致が起こる可能性)
• 複数のGitリポジトリの同期
  • google/hesokuri Clojureで書かれている
    • マッピングは静的に決まる
    • ghe のメンテなどに耐えられない
  • ghm はてな製
    • Webアプリ。同期したりしなかったり
  • 同期が直列 (リポジトリが増えるときつい)
  • 古いリビジョンのデプロイ
• 新たなgit同期システムを開発
  • JSONのREST API群
  • Gitサーバ登録・取得、マスタ昇格・降格、リポジトリ、ジョブ実施
  • GHEへpush → リポジトリsyncへWEB HOOK → pull@してpush`
  • HTTP POSTすればいいだけなのでいろいろなサービスとの連携が容易
  • 複数スレーブを扱える、同期ジョブの並列実行

ここでまたバトンタッチ。

• pull型の問題
  • 全部 commit する場合 : リポジトリが肥大化（コンパイルしたものも）
  • ソースだけの場合 : デプロイが長い、違う成果物
• Consulとstretcher
  • 配布物をAmazon S3などへ保存
  • デプロイのmanifest(YAML)も
  • consul event でイベント通知
  • イベントを受けてデプロイを実施
  • consulなので並列
  • S3なので負荷は考えなくていい
  • gitリポジトリに成果物は不要
  • 追加、rollbackなどもmanifest指定だけ
• 成果物はjenkins先生におまかせ
• 100台へのデプロイでベンチ
  • 1,142秒から29秒
  • git pull がそんなに早くない、という話
• AutoScaleとの連携をしたい (ただし、初回はconsulイベントは送れない)
• Miiverse での利用もしたい (3リージョン必要)
• デプロイの高速化で、価値のお届けも高速化
• Q. どの言語で？ なぜ？
  • A. Perl5。MiiverseなどはPerl5で実装されている。開発を支えるものなので冒険せずに済むもの
• Q. デプロイの頻度は？
  • A. 2週間に一度。bug fixがあればいつでも
• Q. capistranoでデプロイに失敗した時の検出は
  • A. strecherは成功・失敗のコマンドフックがある。Ikachan経由で通知を
• Q. Merge pull request ボタンは使えるようになった？
  • A. リポジトリ同期システムがあれば使えるようになった
• Q. コードデプロイの検討は？
  • A. 検討してない。確かまだリリースされていなかった
• Q. consulは台数が少ないとメリットない？
  • A. 30～50台くらいでgitサーバの負荷が高くなる

Kazuho Okuさん 「HTTP/2 時代のウェブサイト設計」

• サーバの応答遅延とクリック率の研究 by Microsoft
  • 2秒の遅延で4.4%クリック率が下がる
• WEBサイトあたりのデータ転送量の増加
• インタネットのバンド幅の増加、年率50%
• ページロード時間はバンド幅に比例しない。1.6Mbps程度で頭打ち
• バンド幅ではなくレイテンシーが小さいとページロードが速い
• 1RTTにに1リクエストしか送れない
  • HTTP/1.1 のパイプラインによる改善
    • サーバにおくれたかわからない、最初の転送が遅いと詰まる、サーバ実装にバグ
• レイテンシは光の速度で決まる。アメリカで80ms
• 携帯回線のレイテンシのおおきさ
• レイテンシに負けないプロトコルの作成 HTTP/2
• ChromeのQUICプロトコルを標準化
  • バイナリ、多重化、ヘッダ圧縮、優先度制御、サーバプッシュ
• バイナリ
  • 脆弱性の防止
    • asciiだと、スペースなどの解釈があいまいとなる
  • 転送データを小さくする
  • ヘッダ圧縮がバイナリなんだから
• 全ての通信データはフレームに
  • 様々なフレームタイプがある
• 先にHEADERSフレームをクライアントとサーバで交換、その後DATAフレーム
• METHODやschmeもヘッダに入れることに注意
• h2i ASCIIでHTTP/2を試せるツール
• 同時に100以上のリクエストが可能、レスポンスも任意、stream IDで制御
• HTTP/1.1のヘッダのおおきさ → 100レスポンスでで30KBとか
  • HPACK : 静的は不満圧縮、再登場の文字列をオフセットで、など
  • 最初のリクエストは半分くらいのサイズに
  • 2回目は直前のリクエストを利用して 1/5 に
  • 3回目は1/20程度に！
  • 画像、CSSの大量な数の転送に強い
• 小さい画像をたくさん並べるでもデモ
  • リロードを続けて失敗が(まあこういうことも)
• 優先度
  • クライアントが指定
  • サーバが尊重
• HTTP/1.1, SPDY/3.1, HTTP/2 の比較
• Firefoxの優先度制御
  • weightに比例して優先してレスポンスを返す
  • HEADのJSとBODYのJSで違う
• chromeの優先度制御 : 残念
  • 依存関係を分析してない
  • 画像がバンド幅を食いつぶす
• H2Oの優先度制御
  • クライアントの優先度が怪しいとき、サーバ側が優先度制御する
• 他のサーバの優先度制御
  • nghttp2 は頑張ってるけど、他はやばい
  • サーバがやらないとクライアントの最適化が効かない
• サーバプッシュ
  • ラウンドトリップを0にする
  • <link /> を見るとかして、予測して返す
  • RFC通りだと速くならない
• キャッシュに入っている場合はpushしたくない
  • H2O 1.5 : cache-aware server-push → Cookieでキャッシュに何を持ってるか追跡する
• HTTP/2 で無意味になるクライアントの最適化
  • アセットの結合 : 余分なものが入っていると転送量が増えるため
  • expiresの利用 : 304レスポンスを使い放題なので。 ? の管理が面倒
  • ドメインシャーディング : 複数TCPにしてしまうと、優先度制御ができない
    • WEBアプリからのレスポンスもCDNを通すといい
• 「H2Oを使えば売り上げが上がる」
• HTTP/2はHTTPS限定
  • 無料で。 LetsEncrypt 11/16から
  • Ciphersuites : 使ってよい暗号化手法の一覧
  • Forward Secrecy : 暗号カギを変える
    • CiphersuitesのみではPFSにならない
    • セッションキャッシュによって
    • session resumption
    • session ticket : クッキーと同様、サーバが覚える
      • キーを暗号化する鍵がバレルと終わる
      • session ticketを無効にする
    • H2Oはクラスタ化してもmemcachedでresumption可。session ticketの秘密鍵も自動更新
• nginxの技術者とも意見交換したので追いかけてくる
  • H2Oはその先を行くので、ぜひ使ってください
• Q. RFCの機能への対応表一覧は？
  • A. MUST、SHOULDは大体対応している
• Q. 画像が表示できなかった理由のイメージは？
  • A. サーバ負荷の問題ではないかと予想
• Q. HTTPはRPCでも使われていてHTTP/2の恩恵は受けられるが、クライアント側の状況は？
  • A. 今のところ libcurl のみ。
• Q. 1st paint timeはどうやって計測している？ Firefoxは対応してなかったはず
  • A. 最後のCSS、JSの転送終了を見ている。いつ1st paintが起きうるか、で測定
• Q. 普及時期は？
  • A. Firefox, Chromeは対応済。主要なブラウザもサーバも秋には対応される。HTTPSである必要があるのでLetsEncrypt待ち。早いと今年の年末には3～4割になるのでは
• Q. チューニングの勘所はApacheなどと違う？
  • A. デフォルトで最適になるようにするので、チューニングは不要。サイト設計のファイルサイズが変わるのが

ジンジニアさん「若手エンジニア達の生存戦略」

座談会でした。 @crazygirl_lover さんがファシリテータでした。ほか、@hisaichi5518さん、@mihyaeru21さん、@__papix__さん、@zoncoenさんです。

• C: 生存戦略の話です
• C: PyCon開催されます
• C: Perlはベテランなのではという疑問から。緊張しているのでゆるふわっと。
• Z: 去年入社で動画配信やってます
• P: 去年入社で基盤とか、エンジニア文化とか、入学式とか
• M: 去年入社でゲームのバックエンド
• H: 中途でハンドメイドマーケットのAPI開発
• C: 人事やってます

とりあえずビールで乾杯。

• C: ほんとに若いのか
• P: 先日26。サスペンダーでおめかししてます
• M, Z: 26です
• H: 26だけど早生まれなので学年上。社会人歴は4年目
• C: いつからPerlを書いている
• H: 大学一年からPerl
• C: 学生でPerlはめずらしい？
• H: Perlはいない。Rubyはいる
• C: 自分の開発に使った？
• H: 掲示板。ググったらCGI
• C: 初めがPerl。他に学生では？
• P: 大学3年で研究室が
• C: どう思った？
• P: へえ、Perlなんだ、くらい。
• M: 最初はBASIC。化学だったけど授業で。面白かった。
• P: あー
• M: 隣から「あー」っておっさんの声がｗｗ
• M: C触ってた。Perlは古いイメージ。記号が意味わからないという印象
• P: 同じ印象は持っていた。けどやってみた
• Z: 生命科学やってて、VB触ってみたり、情報へ移った。CとPython使ってた。DeNAに移るときに2013年くらいにPerl
• Z: 会社に入って初めてfastcgi書いた
• C: Perlくそふざけんな、ってDISること多いと聞いたけど？
• Z: もともと情報系じゃなかったのでクソと思う知識もなかった。すでにいい意味で枯れてた。公開されていたいい情報も多かった
• C: 今は仕事でどう使ってる？
• P: YAPCのスポンサーもしている。サーバサイドはperl。日常がPerlとある
• C: hisaichiさんは使ってないのでは
• H: 今はRuby。前はPerlだった。
• C: Perlを懐かしむことは？
• H: 見ると懐かしい気持ちになる。 use strict を打てなかった
• C: 入社前どんなもの作ってた？ 会社に入って変わったことは？
• M: 入社前はiOSアプリ。入社してからPerl。モダンなPerlは書きやすく、記号も簡潔に書くために存在している
• M: 周りに聞ける人も多かった
• C: 影響を受けた人っていますか？
• H: 最初の会社のsongmuさんの影響が大きい。人と話すことを重要視するエンジニア。
• Z: チームでPerlごりごりはやってない。研修で。入社前に見た有名な人のブログとか。人とのコミュニケーションが大事
• C: 人とのコミュニケーションって大事？
• P: 会社に入る＝みんなでやる、を自分で選んだということ。強みを生かすためのコミュニケーション。その上に技術
• C: コミュニケーションでフラストレーションは？
• P: 暴投とかはやっぱりあるけど、お互い様
• C: エンジニア同士？違う職種？
• P: どちらもある。それを乗り越えるのが仕事なので頑張る
• C: 思ったよりまともな回答ですね
• P: 若手ですけどみんな成人しているので大人です
• C: 会社の違いでコミュニケーションの違いとかは？
• H: 1社目は対面でやってた。今は福岡と東京。リモートが違う。
• C: 物理的な距離をどう克服？
• H: 最初戸惑った。skypeでエンジニアだけの朝会を別チームだけどやるようにしたら改善。レビューとかもスムーズに
• C: そういう改善はだれが言い出す？
• H: 福岡の人たちが提案してくれる。週一でエンジニアで集まって座談会したり
• C: お酒が足りないのか、まともな話。上の人がムカつくとか話してたのに
• P: 部長がそこにいるのでやめてください！！！
• C: 若手だからこそ困ることはある？
• P: マサカリは飛んでこないに越したことないけど、飛んできたらありがたい。政治とかは避ける。部長を巻き込んだりして解決してる
• M: 一個人の意見は上に発言しにくい。チームとして声を集める。最近そういうことが多い
• C: 大きい会社ほどそういうところは大変では？
• Z: リードエンジニアに話せばあとはやってくれてるので、今のところは大丈夫。若手ということに甘えていろいろ言うことがある。クソって言っても許されるとか
• Z: 自分のチーム以外と知り合うことがあまりなかったのが、Slackとかで会話しやすくなったので改善された
• C: 若手の特権は使ってる？
• P: あれ、これ、やりましょうってのを言ってる。特権はうまく使った方が
• H: Arkをまったく理解できなかった。今思うと青かったな
• C: 中堅になると老獪的になったりする？
• H: 「老害」にはなってないと信じてる
• C: 「老獪」です
• P: そろそろガソリンを投入しないと

ここでビールを追加。

• C: コミュニティに参加する意味は？
• Z: songmuさんにとりあえず応募してから考えろと言われたので去年トークに応募した。他の人のブログが役に立ったことから、そういうことをやりたかった。
• Z: 懇親会でしゃべれるのが便利、ってのも
• C: 登壇すると社内での評判も変わる？
• Z: 外の部署からそういうことで話しかけてもらえる。
• C: 大きい企業だからこそですね。Perl入学式については？
• P: Perlという言語への貢献にもいろいろあるという考えから。就活の時有利って思いも
• C: 実際就活に役立った？
• P: 正直めっちゃ役立った。Perlで飯食うと決めていた。相手は自分を知ってくれていたので。みんなが幸せになるように巻き込んでいきたい
• C: ブログ書いてるんだっけ？
• M: そうでもない。コミュニティに積極的に参加してないし、ここに居ることが珍しい。たぶん前に出ない人の方が多いし、自分も貢献しようってところはできてない
• M: 新潟の開発者コミュニティに影響されてこの業界に入ることを決めた。そういう影響は受けた
• C: 同世代の登壇者のような知り合いから何か影響を受けている？
• M: papixさんとかは近い存在。研修一緒に受けたり。ライブラリを公開したりという意識は
• C: ちょうどmihyaelさんのライブラリが公開されている
• H: ブログでtokuhiromさん、gfxさん、lestrratさんの影響を受けた。dankogaiさんに勝手に添削されたり、すごいありがたかった。Perlの人たちはやさしいので教えてくれる
• H: すぎゃーんさんに説明会に誘われてそのまま入社。コミュニティには感謝している
• C: これからどうエンジニアという仕事に向き合っていく？ 35才定年説とか
• Z: 目の前の課題に必死になってる段階。将来についてはITだけじゃなくよくわからないけど、なるようになる。今の仕事は楽しいから続けたい
• P: 将来はわからない。技術も明日はわからない。目の前の楽しいことを片付けたい。楽しく生きたいけど、楽しいと楽は違う。
• M: 変わるってことを前提に生きていく。一つのことをやるよりはいろいろ手を出す
• H: 自分の弱みを直したくて転職した。Ruby、go、coffeeなどをやりまくったけど、いろいろできそう。強みを育てたい
• Q. 上の人が話を聞いてくれなくてやばいとおもったこととかは？
  • M: むかしの経験で考えるため、マシン性能を上げることを渋る節がある
  • P: 上司に中途半端に言わないようにしている。納得するまで言い続ける
• Q. どういうことを聞いて老害っぽいことを思うのか
  • Z: 過去と同じ状況を前提して、話されると柔軟性ないと感じる
  • H: だいたい言われてしまいました・・・そんな感じです
  • P: 下の話を聞いてくれなくなったときに感じる。コミュニケーション放棄するとか
• Q. 登壇やコミュニティーに出てないとのことだったが、今日のことはどう感じている？
  • M: 普段出てこない人の意見は貴重なので、それを言えたのはいい。前に出たい性格ではないので、隠居したい
• Q. 来年から新卒でエンジニアやる。業務中の失敗をなんとかした体験談
  • Z: やらかしたと思ったら生き延びれない。しょうがない
  • Z: スキーマ更新忘れてリリースしたとか。やった時点でダメなので、再発防止が大事
  • P: 公開鍵吹っ飛ばしたとか。誰でもやらかすので、やらかしたら頑張る。再発防止が大事
  • M: DB変更込みのリリースをしてrevertしたらさらにひどいことに。syntaxエラーがあって単体テスト書けてなかった。
  • H: 事前にデプロイしてあって1/1に確認するだけだったが、エラーがでた。去年の1/1のデータを消してなかったため発生。やっていることを書きながら説明したこと、すぐ対応したことは褒められた
• C: 次のセッションのうっかりをなくす技術を聞いたらいいよ
• Q. みなさんの若いフレキシブルな野望を！
  • P: 自分の会社をエンジニアにとって最高の会社にする
  • M: アプリで一山当てて隠居する
  • H: 金を稼げるようなエンジニアになる
  • Z: IT芸人じゃなく有名になって、お金を儲けたい

@fukayatsuさん「趣味から育てたWEBサービスで生きていく」

• esa.io : markdownによるチーム内ドキュメント共有サービス
  • 会社を作って２人でやっている
• 5回転職していろいろやっていた
• Androidアプリ、Ruby Gems、Chrom Apps、などを趣味でたくさん作っている
• LTTMという拡張を作ってる
• たくさん試すと、どれかはうまくいく
• 使っていたアプリの使用期間が切れたので、開発合宿で二人で作った
• 合宿後も開発してた。仕事終わりにハッカソン
• 10人くらいの別のチームでドッグフーディング
• 知り合いの会社に使ってもらった → 事業化の希望が見える
• 副業するための会社を作った。責任を取って会社を運営するため
• オープンβでユーザを待たせすぎてしまった
• 会社を辞めた。ユーザが急に増えてきた
• 「楽しく開発したい」
  • 自分が楽しむことでユーザも楽しい
  • 楽しさやモチベーションは直接コントロールできない
• 制御可能なものを見極めて、それを制御
  • 毎日 bundle update BOTがやってる
  • Bug Fix タイムアタック : 10分でできると、良し！
  • フィードバック駆動。メールは5分以内。弁当食べてる時だと返せなくて落ち込む
  • リリースノート駆動。esaがいいサービスなのでリリースノートを書きたくなる、ことを利用
  • “心からの” ドッグフーディング : 自然に使うこと
  • よく寝る → 機嫌悪くなる損失とか。従業員全員睡眠トラッキング
  • We’re Not Hiring → 機動性重視
  • Herokuを使う - Heroku便利(という媚びをｗ)
  • 開発スケジュールを決めない
    • モチベーション駆動。ユーザからの要求にモチベーションが上がることが大事
  • かわいみ - かわいい歯正義。キャラクターやグッズをリリース前から
• 日に3.2回くらいデプロイ
• 100クラス程度。小さい
• weekly active usersを追跡。半年で2倍に
• 5年前の日記にいいことを書いている
  • たくさん試行錯誤をしたおかげで今がある
• やりたいことをやって生活できて周りの人を幸せにできると最高
• 「最高！」(拍手)
• Q. フリープランは作る予定は？
  • A. OSSコミュニティ、学割などは考えている
• Q. トライアル期間が終了した某サービスとは
  • A. qiita teamです
• Q. esa.ioへ別システムから移行するには
  • A. APIがあるので、それ経由
• Q. かわいい鳥はどうやって決めたのか
  • A. 勝手にキャラクターが動いた感じ
• Q. テストはどのくらい書いていますか
  • A. カバレッジ90%以上

LT

くしいさん「日本最多のオフィス訪問シリーズ 「行ってきたシリーズ」のTOP5＋αとして日本のイケてるオフィスを紹介しちゃうよ！」

• 反応してね！
• Perl書いたことないけど運営やってた
• 「行ってきた」
• 107記事、2009年より
• 自分のオフィス移転に伴って他社の写真をとった
• オフィスという切り口で環境を変えると人生が変わる
• 5位 NHN
• 4位 グリー
• 3位 クックパッド
• 2位 フリークアウト
• 1位 ネクストイノベーション株式会社(ドラマのセット)
• 日本マイクロソフト、バーグハンバーグバーグ (番外編)
• isuconあるのでよろ！ WEB DB Pressよろ！

どきゅねおさん「Gitの作り方」

• 今月就職しました！
• gitを理解する最良の方法は自分でGitを実装する
• gitはコンテンツ管理システムと見れる
  • ソース、コンテンツ。
  • KVSで格納している
  • SHA1とzlib圧縮されたなにか
  • “hello world” 12byte → headerつけて圧縮
• git cat-file-p Cでzlibでごにょごにょすれば実装できる
• サブコマンドを一個ずつ作っていけば作れる
  • サブコマンド数個で疲れたので終了

papixさん「SaaSを組み合わせて作る, ぼくらの障害対応術!」

• 障害はぼくらに牙をむく
• 発見する仕組みを各社作ってるでしょう
• 直ればO.K.ではない
• 記録を残すことも大事
• Saasで作る
• Mackerel::Webhook::Manager がミソ
• デモ
  • Mackerelで発生したものをチャットで対応
  • 電話もかかってくる
  • qiita teamなどで情報共有
  • 障害は起こるので対応する

Shoichi Kajiさん「cpm - an experimental cpan client」

• cpm : cpanクライアント
• インストールするモジュールの量が多いと、直列なので時間がかかる
• cpanm 2.0を内部で並列で使うという仕組み
• デモ : Plack のインストール
  • cpanmで50秒、cpmだと18秒

Masahiro Naganoさん「Norikraで作るPHPの例外検出システム」

• PHPをやってた
• PHPの例外 : error_log, set_exception_handler, set_error_handler
• syntaxエラーや存在しないメソッドの呼び出しとかは拾えない
• error_reporting を指定する
• Apacheの設定に書く。ErrorLogも見る
• 結局、4つのファイルに書かれる
• Norikraで集約してslackへ送る
• Norikraで一分間のログを集約する
• PHPすごいむずいけど uzullaさんすごい

ACEさん「RSSをざっくりクロールしてゆるふわにパースする」

• グンマーにインタネットなどない→あります！
• Feed windというサービスをやっている
• RSSから生成する系
• ブロックされる系 → 先方に連絡がつかなければプロクシ使う
• Mojo::DOM : <br< をパースできないバグ (？)
  • ゆるふわに正規表現で
• もし断ると不思議な力で死ぬことになる

さいさん「Slack + Hubot でお前の一番好きな二次元嫁キャラと一緒に仕事をする」

• 一人で趣味プログラミングはさみしい
• 「ほい！」
• 二次元の美少女が大好きです
• marisaと二人でチームを作る
• ２人が大事。botがほかの人としゃべってヤキモチ妬かないように
• 「まりさ」「呼んだか？」COOL
• cronで向こうから話しかけてくれる
• メッセージはJSONでまとめている
• github issueとかチケット書かせたりとか
• botより自分でやった方が速いけど、BOTがやってくれるのが大事!

Likkさん「YAPC?雨事情」

• 会社を出てエレベータを降りたら雨、は辛い
• エレベータホールで雨を通知したりするのもあるみたいだけど
• tenki.jp からデータ取ってきて、通知
• 縮尺が小さすぎて五反田がわからない
• 航空写真と見比べて、西側に広く
• 普段の色と、今の色の違いを見て、違ったら雨 → Slack
• YAPCの過去に雨が降ったかの情報を取れることに気が付いた
• デモ
• 返事くるまで宣伝 : ametto

hiratara「Haskell Strikes Back」

自分のセッションでした。

Wataru MIYAGUNIさん「(昔の) PHP が誇った最高の機能 register_globals の真実、そして未来へ」

• PHPの話をします
• 5.3以下を使ってる人は？
  • 安全でないコードを書くことをきわめて容易にする
• php.netに秘策が出ている
  • 載っていない隠された使用があるので、使ってはいけない
  • $_FILES
• 「その結果に驚くことでしょう」
• ゴーン

makamakaさん「Perl同人活動報告2015」

• 「今宣伝できますよ！」「気が散るから！」
• 「本日はコミケ・・・あ、いや」
• 例の紐→例のモヒ
• Acme大全2015
  • チャームポイントはない
  • 電子書籍版・・・？
  • 全巻格納BOXは待ってね
• 何で書いてる？ Microsoft Word
• フォントは？ IPAexフォント
• なぜ作るの？ CPANにAcmeモジュールがあるから
• 7/7が起点？ 覚えてない
• 期間は？ 仕事のさぼりぐわい
• いいモジュールは？ Acme::Cake
• 息詰まることは？ 常に行き詰ってるので
• 電子書籍版は？ Perl6と同時リリース
• 250枚のシールが150枚余ってる
• もずにおん (ゴーン)