2015/3/21（土・祝）に開催された時雨祭（http://shigure.connpass.com/event/11780/）というイベントに参加してきました。

会場提供はドワンゴさん、会場は歌舞伎座タワーでした。

当日のTwitterの流れとスライドへのリンクは@blaue_fuchsさんがtogetterにまとめてくださっています。

時雨祭 2015.03 -まったり編- #時雨祭
時雨祭 2015.03 -プレゼン編(1)- #時雨祭
時雨祭 2015.03 -プレゼン編(2)- #時雨祭
時雨祭 2015.03 -プレゼン編(3)- #時雨祭
時雨祭 2015.03 -プレゼン編(4)- #時雨祭
時雨祭 2015.03 -プレゼン編(5) 終わり- #時雨祭

以下メモ。

@voluntasさんの事前案内

時雨祭 2015.03
事前の登壇予定内容。

10:00〜15:00

フリータイム（または投げっぱなしジャーマン）。

自分は、資格試験の勉強とAtom×Proxyが倒せなかった件のメモをしていました。

ここから先がプレゼンタイム。

droneの話

Abbyの松原さん（@mopemope）。

自分のPCだとスライドが文字化けしている…直ってました。（2015/03/24）

DockerベースのCIサービスdrone.io。
drone.ioについては、ペパボの@udzuraさんの資料（Drone.io のご紹介）が参考になる。

drone.ioのOSS版であるdrone。

drone（OSS版）でできないのは、Artifact（成果物）の管理、GUIでの操作。
GUIの代わりにyamlを書く必要がある。

インストールは、drone自体がDockerizeされているので、git cloneしてリポジトリ上でビルドを叩くとdroneのイメージができる。UbuntuでもCentOSでも。

設定はほぼ環境変数で指定可能。
Volumeだけ注意。/var/lib/drone。

author指定がないのがオフィシャル。
オフィシャルの実体は、bradrydzewski/xxxx。
オフィシャルのイメージは特殊なのでカスタマイズが難しい。

droneのカスタマイズはプラグインで。

成果物を配布する仕組みがpublish。
ドキュメントに記載されていないpublish先は、DropboxとAzureストレージ。
Dropboxのプラグインは松原さんが作った。Azureのは誰かが最近作った。

droneは0.3から0.4への変更でdrone.ymlの書き方が大きく変わる。
0.2→0.3の時もそうだったが、破壊的な変更が多くなるので書き直しが必要になる。
今運用している人は注意。

0.4で追加されるmatrix build。
matrixなので、指定したパターン分だけテストをやってくれる。「Ubuntu/CentOS」「Pythone2系/3系」とか。
テストがパラレルに実行されるかは、今のところ不明。

メルカリを支える技術

メルカリの久保さん（@cubicdaiya）。

メルカリ。スマホで使えるフリーマーケット。
日本版とアメリカ版がある。

さくらとAWSのハイブリッド。SMSやメールの送信はAWS。

メルカリのAPIサーバはPHP。
レスポンスタイムはピーク時でも平均30msぐらい。
購入トランザクション等はもう少し遅くて数100msかかる。

早い理由。
DietCake（http://dietcake.github.io/）。高速・軽量なPHPフレームワーク。
キャッシュ。memcachedやRedis。
非同期処理。重い処理はキューでバックエンドに回す。検索インデックスの更新やSMS/メール送信等が重い。

フロントにnginx。
Apache 2.4等ではデータプロバイダでTLS Session Cacheができるが、nginxでは使えないので代わりにTLS Session Ticketsを使う。
iOSはTLS Session Ticketsに未対応、Androidも4.どこか以降からの対応だが。
複数のnginxをフロントに立てる場合は、同じ暗号鍵を使う。

SPDYはiOS・Androidが対応しているので、nginxノ設定で使用するように指定すれば使える。
TLS Session CacheとSPDYで帯域が軽くなる。

Gaurun。goで書いた汎用Push通知サーバ。そのうちOSS化する予定。
スマホへ通知するのにGCMやAPNsを使うが、GCMやAPNsへの通知依頼は1件あたりGCMで数百ms、APNsでは1秒を越えることも。これを数百万ユーザ分回すと膨大。
この処理（APIサーバからGCMやAPNsへ通知を要求する時のProxy）がGaurun。
nginxをAPIサーバと複数のGaurunの間に立てている。
goの並列化で、Gaurunを載せたサーバのCPU使用率が1000%（100%の誤植でない）といい感じにリソースを使えている。

Goは早い・速い・軽い。

フロントエンドを楽にするために

Increments（Qiitaを運営しているところ）@mopemopeさん。

@mizchiさんの資料（フロントエンドを楽にするために; https://gist.github.com/mizchi/757776f685805a1fddc5）。

JavaScriptなフロントエンドの話。

フロントエンジニアのイメージ。HTML、CSS、javaScriptを使ってフロントエンドを作る人。
イコール、サーバサイドの片手間、デザイナの片手間という印象。
フロントエンドの業務は、コンポーネントを提供するか、シングルページをゼロから作ってAPIとの境界面だけ綺麗にするとか。

最近のフロントエンドに求められるもの。アセットパイプライン、minify。

JavaScriptは学習コストが高い。
一定以上の規模がある場合は、専任まで行かなくてもある程度やらないといけない。

glup/gruntは秘伝のタレ化しやすい。

ECMAScript6。
classとかletによるレキシカルスコープとかyield parameterとか。
「普通」の言語になりつつある。

ES6は現在使えるか？
全然使えない。有効化されていない。chromeでオプションを有効化したら使えるとかそういうレベル。

最近人気があるのはBabel（https://babeljs.io/）。ES6準拠＋α。
勝手にES7の仕様を取り上げたりしている。authorの暴走気味。

TypeScript。モジュール部分が独自仕様で、ECMAScriptの仕様に沿っているかというと怪しい。
オプションをうまく絞れば互換のものとして使える。GoogleのAtScriptも合流。

@mizchiさんの好みはCoffeeScript。

一部のJS書きがASTレベルプログラミングに行くわけ。
（ブラウザベンダが？）昔のIE暴走のような感じで実装の足並みが乱れるのを恐れている。進歩も遅くなっている。
なのでASTをガンガン弄っていこう、未来の規格を勝手に実装しようという流れ。

SPA（Single Page Application）を片手間に作るのは無理。
クライアントがバリバリ動くためにはバリバリ動く設計をしないといけなくて、それはアプリケーションエンジニアの領域で、しかしアプリケーションエンジニアはJSが書けない。

jQueryはスクレイピング相当。
一度書かれたDOMのレタッチなので、レタッチにレタッチを繰り返すと今のステートが失われてデバッグが非常にし辛くなる。

JSでのMVC概念はBackbone.jsの導入以降。
まだぐちゃぐちゃしている。
クライアントサイドでMVCができるか。
そもそも完全にMVCをクライアントでやるのは無理。

最近のFluxの流れ。
クライアント開発アプローチの富豪化。
VirtualDOM。React（http://facebook.github.io/react/）とか。
Diffの部分でCPUを使うが、最近のjavaScriptは速いのでそこにコストをかけられる。

現実。
覚えることが多い。
ある程度は仕方がない、増えた分は覚えるしかない。
その分サーバはサボれる。

過去にいろいろなアプリケーションを作ってきたが、基本的には「このレイヤ以下は俺にくれ」という形で引き取る。
SPAだったら、REST APIだけくれという。
ある程度以上のJSエンジニアに取ってはSPAの方がコストが低いが、その母数が少ない。

Isomorphic。
Meteor（https://www.meteor.com/）はサーバとクライアントの共通化、うまいことやっているが癖がある。

特殊Isomorphic。
JSで動くようにすれば良い。
Scala.js等。
clojurescript（https://github.com/clojure/clojurescript）はかなり良い。

Reactエレメントをサーバサイドでレンダリングできるようにしているreact/react-rails（https://github.com/reactjs/react-rails）。
ReactElementをサーバサイドレンダリング。
テンプレートでできる範囲なので、サーバサイドでいろいろできるようにするにはテンプレートエンジンを整えないといけない。
まだ使えない。ライブラリが足りない。

Quipperを支える負荷テスト技術

Quipperの本田さん（@hakobera）。
Dockerを使ったWebサーバ／WebアプリケーションのHTTP通信の負荷テストの話。

本田さんの資料（Quipper を支える負荷テスト技術; https://gist.github.com/hakobera/e47dd940b92f56d8bf1a）。

シナリオ作成。
ある程度は仕方がないが、XMLと格闘するのは本質ではない。
何らかのプログラミング言語でかけるとよい。
ここではLocust（http://locust.io/）を使った。
pipで簡単にインストールできる、分散環境が簡単に構築できる、Pythonで書ける。

負荷をかける側のインフラ構築。
負荷をかける側がサチって負荷がかけきれないとか。
インフラは最近はDockerやVagrantが基本。今回はDocker。

プライベートイメージの管理はGoogle Container Registryを、コンテナはGoogle Container Engineを使う。

Google Container Engineの中にkubernetes。

Google Container EngineにLocustのDockerを2個（slave）デプロイして、Webアプリケーションへ負荷をかけるデモ。
LocustのGUIで負荷状況を確認できる。
試験が終わったら簡単にコンテナを破棄できる。

クラウドで負荷試験をやる場合は（ローカルに比べて）ネットワーク距離があるが、QuipperはHerokuのサービスでバックエンドはWebサービスをいろいろ使っているのでそこは割り切った。

freeeを支える技術

freeeの松崎さん（@xga）。

クラウド会計ソフトのfreeeと企業会計ソフトのfreee、2つの製品を展開している。

フロント側はBackbone.jsとVue.jsとCSS。
サーバ側はRuby on Rails。

サムネイル変換とOCRはgo。goからCのOCRライブラリを呼んでいる。
インフラはAWS。

ブランチは、developとstagingとmasterの3つ。
developにpull reqするとJenkinsがビルドしてテスト。

Reviewerがmergeして、Reviewee（＝pull reqした人）がデプロイする体制。

監視はzabbix（http://www.zabbix.com/jp/）。
例えばWebサーバのCPU使用率が80%を越えるといった条件でZabbixが検知して、HipChatとMLへ通知を流している。

ロギングは、各サーバにtd-agentを入れてfluentdへ。
S3からPsotgreSQLへ。
fulentdからKibanaへ。

PostgreSQL9.4からJSONB型が追加された。
インデックスを張ったら早い。

OpenVBX（http://www.openvbx.org/）。powered by twilio。
OpenVBXを利用して着信後のフローを制御。転送などもできる。

機能的にはTwilioだけでできるはずなのになぜZendeskを併用しているかというと、Twilioでは03番号が取れないから。

freeeではバグを「ハッピー」と呼んでいる。

タスク管理はasana（https://asana.com/）。

サーバプロビジョニング。
入社時はchefだったが、今はAnsibleへ移行。

Web魚拓の闇

Web魚拓の新沼さん（@hiroki_niinuma）。

普通に開発の話をするつもりだったが、@voluntasさんの強い意向で闇について話すことになった。

箝口令。Tweetとか禁止。

HLSについて

もりよしさん（@moriyoshit）。

HLS。HTTP Live Streaming。

AppleがiOS3に初めて搭載した。
同時にIETFへ提案。
今はAndroidでも再生できる（らしい）。

インターネットラジオを実現するあれ。
プレイリストを生成／再生成。
Segment1〜3が最初にあるとして、再生が進んでいくとSegment4が追加されたり、Segment1がGCされたりする。

.m3u8ファイル。
セグメントの持続時間とかファイルパス。

HLSはプロトコルがシンプルで、キャッシュフレンドリー。
長い動画だと場所をシークするのが大変だったりキャッシュが大きくなったりするが、HLSなら細切れのセグメントをキャッシュすれば済む。

家庭でHLSを始めるには。
Webサーバでセグメントファイルを送る。

ffmpegでセグメントを作る。ffmpegにパラメータを指定すると作れる。
（スライドの14ページあたり）

サーバ。
AdobeのAdobe Media Server。商用のサービスをやるならこれ。
Red5 HLSプラグイン。
nginx-rtmp-module。

nginx-rtmp-moduleは実績がわからないが、これがお手軽？
OpenRestyを使ってビルドする。

HLSではクライアントがセグメントファイルを取ってから動画を取りに行くので、セグメントファイル分の遅延はある。

MPEG-DASH。
HTTPを使って動画を配信する技術。詳細はまだ追えていないとのこと。