ブログを書くまでが、YAPCということでqiitaに書きます。

メインはPHPでperlは全く触ったことがないのですが、
YAPCはエンジニアなら楽しめるよと知り合いからの勧めもあり参加してみました。
前夜祭は残念ながら参加できず・・・
手元にメモったものを要約しつつなので、発表者の意図したものと若干ことなってるかもしれません。スライドも合わせてみることをお勧めします。

メリークリスマス! (Larry Wall)

Perl開発者 Larryのセッション
ホビット物語とロードオブザリングにたとえてPerl5とPerl6を説明していた。

残念ながら、ホビット物語もロードオブザリングも見た（読んだ）ことがなかったので例えがわからなかったのです・・・
が、今回のセッションで一番歓声が上がったのは以下でしょう。
Perl6はクリスマスまでには出す・・！出すが年までは指定していない。その気になればリリースは10年後でも20年後ということも可能だろう・・・ということ・・・!が
2015年のクリスマスころにはperl6出す。
まあ、明日バスに轢かれたりしたら遅れるかもしれないけど。
と名言されたことではないでしょうか。

Effective ES6(Teppei Sato)

スライド:http://www.slideshare.net/teppeis/effective-es6
WebDB+ Vol87にも特集が組まれている。
セッションは大きく分けて
・ES6の全体的な話
・各主要機能
・来年以降どうなるか

ES6の全体的な話

JavaScriptは柔軟にしすぎた(Brendan Eich)
JavaScriptは世界で一番誤解されている言語(Douglas Crockford)
というようにJSには落とし穴だったり謎仕様とかが多い。
特に他の言語を使ったことのある人が陥りやすい罠が多い。
例えばprototype継承でglobal汚染しちゃったり・・・。
そのためJSではBestPracticesが多く生まれてきた。
そのような状況を打開するのにES6が生まれた。

ES6

正式にはECMAScript2015 だけど、みんなES6と呼んでいる
落とし穴を防ぐようなmodernなsyntaxだったり大規模アプリのようなモジュールだったり後方互換性がある。
Classを正式に導入したり落とし穴を防いでいるのでBestPracticesで書いてきたものがいらなくなるかも。

ES6つかえるの？

ES6 compatibility table https://kangax.github.io/compat-table/es6/でどのブラウザがどれくらい対応しているか見れる。
今年の秋頃に出るSafari9ではES6のかなりの部分が実装されそう。
なお、IE11ではサポートされないし、ES6をサポートすることはない。
IE11は2013まで

対応していないブラウザに対してどうするか

・ES6 Transpilerを使う。
ES6→ES5/ES3に変換してくれる。

・ES6 Polyfillを使う。ソースコードを変換するのではなくES6で入ったbuilt-in classをJSで読ませてES5とかで使う。

・Babelを使う
開発が活発で71%の機能が使える

ES6の各機能

New syntax 新しい構文

・Arrow Funclition

var add = (a,b) => { return a+b;};

わざわざfunction各必要ない
closureのなかでthis.nameをとりたいけど、現在はとれず　スコープの外側で self = thisとして保存してthis.nameで取得している。
arrow functionの中では外側のthisがそのまま使える仕様
thisをbindするようなAPIとかcallbackするやつだとつかえないよう注意

・Classes
普通のClass
ES6では継承ができる

Class Programer extends person

のような感じで。
ES6ではbuilt-in Classも継承できる

・Module
モジュール化して粗結合できる。
ES6では

export var foo =“foo!;
やexport function bar(){}

のようにexportできる
importするときは

 (foo,bar) from “./module”;

のようにimportできる

・block scope
ES5ではblock scopeがなかった
ES6では使われる
ES6ではlet/constでblockscope作ってくれる
for loop中でletで宣言すれば多言語と同じ様に宣言できる
const 再代入とか再定義するとエラーになる
image的には Javaのfinal

・テンプレートliteral
文字列連結 + を使ったり配列のjoinを使ったりする
テンプレートリテラルはバッククオートで囲んで ${name}とやることで nameがbindされる
PHPで変数展開しているのと同じ感じ

・Map/set
普通のmap objectでもkeyにとれる

注意点

新しい落とし穴もある。
if (a => 1) {

}
allow functionと >=(演算子)がわからない
ESLintという
Lint toolで解決する

来年以降どうなるか

Stage4に行ったものをES201Xとして出す。
草案はgithubにある。

まとめ

ES6はすばらしい。
BABEL使おう。

##　感想
なんとなく、JavaScriptは苦手に感じていて、その苦手な原因がJSと他言語の根本的な違いにあるのかなというのに気づけた。

HTTP/2時代のウェブサイト設計(Kazuho Oku)

前提

ウェブサイトと応答速度
ウェブサイトの応答速度が遅くなるほどクリック率は下がる。(500msec で1%,2秒で4.4%)
一方4年間でデータ量は倍近くに。また、エンドユーザの使えるバンド幅も増加。
ただし、ページロード時間はバンド幅に比例しない
(5MBぐらいまでは短くなるけど10MBぐらいだとかわらない)
レイテンシを減らすとページロードタイムも短くなる
今はレイテンシ

なぜか？

HTTP1.1は多重性がない
1RTTあたり1リクエスト/レスポンスしか送受信できない

レイテンシは今後も小さくならない

光の速度はかわらない
アメリカまで80msec往復で。
携帯回線はレイテンシが大きい LTE 50msec

レイテンシに負けないプロトコル HTTP2

5月に標準化
バイナリプロトコル
→脆弱性を防ぐ
HTTP1.1のパーサーによる解釈の差をつく攻撃がテキストだとあるので。

多重化

同時に100リクエストを発行可能
任意のタイミングでリクエスト送信可能
レスポンスの順序が問わない

ヘッダ圧縮

HTTP1.1のヘッダは大きい 300B GA+cookieで200B レスポンスも通常300倍と
→100個なら30kB
HPACKという仕様で圧縮
STATUS 200とかはindexから引っ張ってくる
よく使うやつは1Bですむ
1個前に送ったヘッダだから次に同じやつがでてきたら1Bになる

優先度制御

重み付けで通信順がかわる
FireFoxは依存関係もつかっているから早いけど
Chromeは依存関係つかってないからあんまり早さかわらない
EdgeとかSafariは優先度制御つかってない

サーバ側の優先度対応

サーバが正しく実装しないとクライアント側でチューニングできない

サーバプッシュ

HTTP/2はRTTを隠蔽する技術 1RTは絶対出る?
→それ0RTでできるよ。
サーバーがクライアントがリクエストしそうなものをプッシュする

HTTP2でオワコンになる最適化

・アセットの結合
・CSS splite (不要なデータまで転送するから)
一部変更したら全部再転送になるから
・expiresの利用
?date=2015...
HTTP/2なら304レスポンス使い放題
・ドメインシャーティング
アセットを別ホストにおくことでHTTP1の同時接続を6本以上にする(ホストごとに6本だから、別ホストに置くと6*ホスト数で接続できる)
TCP制御またぐと優先度制御できない
CDN使ってるはWebアプリからの応答もCDN経由で返す様にする
CDN内のサーバで優先度がかわる

まとめ

HTTP2はウェブを早くする技術
ページビューが増えれば売り上げが増える

質疑応答

Q.RestAPIとかでもHTTP2を使いたい
クライアントライブラリなにつかえばいい？
A.libcurl がどっちもはなせる。
Q.HTTP2いつ頃普及する?
A.Firefox Chrome Edgeは対応
Safariは秋
IEはしらん

感想

HTTP1.1で最適化している方法でも、2になれば逆にオワコンになるんだな。と
結構やってるので、この辺は要検討。

WebAudioで入門する信号処理 (cho45)

WebAudio

WebAudio != Webmusic
今までのWebは表示するだけ限られた範囲の光の制御
WebAudioは、空気を振動させられる/電気信号を直接遅れる

WebAudioの考え方

AudioNodeが基本単位
マイク入力ノード・スピーカ出力ノード　各種フィルタノードなど
AudioNodeを複数接続していくことでストリーム処理
いろいろメソッドがある。

WebAUdioモデム

AudioBufferでつくれる。
昔のダイアルアップ通信みたいな感じでJPEG画像を転送していた。
響き渡るダイヤルアップのピーヒョロロ音。
詳しくは以下のデモで。
http://cho45.stfuawsc.com/WebAudio-Modem/FSK/modem.html

WebAudioのデバック

Canvasでトリガー付きのオシロスコープの実装する

今後の未来

超高音通信

16khz~で通信する
AndroidのGoogle playフレームワークにも入ったらしい
マイク　スピーカで送受信ができて非接触でデータやり取りできる
WebAudioでもいける
ただし、マイクとスピーカーの特性の保証がない
誤り訂正必要

IoTとの連携

Wifiに接続させたい Wifiにつなぐためには接続情報が必要
キーボートもないのにどうすんの？
直接ヘッドフォンポートに電気信号を出す
WebAudio 直結シリアル通信 (UART)

WebAudioで電源供給

WebAudioから音量MAXで出力して受信側で昇圧すればLEDぐらいなら光る

感想

ちょっと未来を感じた。
DIYとかとも相性よさそうだしちょっと触ってみたいなと思った。

Yet Another Perl Cooking(moznion)

今回のバカ枠（褒め言葉）だった。

概要

API basedでReproducibleでAutomaticをYet Another Cookingと定義。
要はAPIで操作できて(だからとろ火とか無理),調理の再現性があって、自動でできるもの。
そんな中でNomikuという調理器がすごい、水の温度を一定に保つことができる低温調理器。
しかもAPIが提供されている。
・・・が、アメリカからの発送で届かない。ので、YAPC駆動開発で自作してみた的な話でした。
Raspiで制御して、ヒータをリレーでONOFFさせて調理してみた。という。
なお、割と危ないし(使ってた水槽がヒーターで溶けてた）し、食べて食中毒とかなっても責任はとらない。
あと、Cooking for Geeksは聖典

大規模でも小中規模サービスでも捗る microservices な Web サービスのつくりかた (Kazuhiro Osawa)

Microserviceのメリット

・サービスのスケールがしやすい
・自然な感じで開発可能
・小さいAPIにフォーカス可能

デメリット

・サーバーがたくさんないときつい
・コンポーネントもないときつい

実は・・・

microserviceはbuzzwordで実は普通の開発手法。
twitterのAPIとか使ってマッシュアップとかしてると思うけど、要はAPIの提供が社内か社外かの違い

開発していく上でのコツ

・小さいサービスでは、モノシリックなコードにすべき
・初期段階の設計が一番大切

中規模サービスでとるべき戦略は

・いつ分離するかのタイミングが重要
・元のコードコピペして作るのはよくない。
・コピペして使いたいところを共通のサービスとして置き換える
・メンテナンスに手間がかかるモジュールを利用するコンポーネントなどは独立すると捗る

実質的に複数のサービスを抱えるので管理の手間をどうすればいいのか

deployの簡単さが鍵

リポジトリをわけるかどうか？

担当者が少ないときはいいけど、増えてくると分離したほうがいい。
後方互換性の問題はがんばる。
大規模サービスの場合はWikiに残したり UML化したりしたほうがいい

質疑応答

Q.ローカルにAPI用のサーバーも立てると重くならない？
A.開発用のAPIサーバを立ててそれを使う
Q.APIのドキュメントの共有
A.md使えるWikiなのでparamの詳細とかのせるとメンテナンス性が低くなるので、json schema書いておく。
日本語読めない人もでてくるので英語で書く

感想

割とAPI周りの実装をしているので、とくに元のコードコピペして作るのは良くない。って点は納得できた。