RubyKaigi 2016 3日目

=========================================

### RubyKaigi2016とは？

```
日本で開催されているRubyコミュニティ主催のオブジェクト指向プログラミング言語Rubyに関する年次イベントである。 
```

by wikipedia

Rubiestが世界中から集まってくるイベントです。
今日はその3日目です。
その中で、私が聞いた講演をまとめてみました。
メモのままのところもあるので悪しからず。。

--------------------------------------------------------------------

### Web Clients for Ruby and What they should be in the future by Toru Kawamura @tkawa

[スライドへのリンク](http://www.slideshare.net/tkawa1/rubykaigi2016-web-clients-for-ruby)

sonic garden中の人
RESTfulの勉強会開催しています

以下は[講演内容のまとめ(公式より)](http://rubykaigi.org/2016/presentations/tkawa.html)を、Google翻訳したものです。

```
このようなAmazon WebサービスとしてRESTとハイパーメディアのWeb APIは、毎日、より一般的になっています。もちろん、RubyのアプリにこれらのAPIを統合することも一般的です。そこでは、Rubyで書かれた統合のために使用しますので、多くのHTTPクライアントがあるが、それらのすべては、Web APIの利用を取るための機能「状態管理」を欠いています。
私はFaraday、Rubyで一般的なHTTPクライアント上で機能を実装しました。私はあなたのキーポイントと実装の有用性を紹介します。
```

RESTful web clientsという本が出ます
読書会もやります

#### Rubyで書かれたWebAPIクライアントにアクセスする
サーバサイドアプリのWebAPIにアクセスする部分もクライアントといえる

*WebAPIは使うのが簡単*

	統一インターフェース
	Webブラウザ、curlでも使える

ほしくないクライアント

* 密結合のせいでガチガチ。変更できない
* 再利用ができない

	```
	パラメータ名をコードの中に埋め込んでいる場合。
	例) HTTP.get(/v1/xxxx) みたいな
	```

ほしいクライアント

* 変化に適合できる
* 汎用性が高い。最良できる

	```
	疎結合なクライアントがいい
	ハードコードされたURLなし。URLや条件を変えてもクライアントが潰れない
	```

APIの変更がクライアントに反映されるべき！
-> APIの説明を分割してレスポンスの中に説明を埋め込むのがいい

#### Webクライアントのgem

Webクライアントのgemがたくさんある
	やってることは似たようなこと
	例) GAC, AWS, Twitter..

```
いいとこ
	WebAPIであることをあまり意識せずにかける
わるいとこ
	使い方はgemによって違う
```

もしgemを提供する側になったら

	* 使うのが簡単であるべき
	* インターフェースの計算..今あるやつを使ったほうがいいのでは？ってなる

なんでたくさんある？

	* Web APIごとのJSON構造の違い
	* API1回呼び出すことと、機能を実行することにはギャップがある
	* 1回のAPI呼び出しで目的が完了することはほぼない

状態管理

	* HTTPクライアントは状態を持たない
	* アプリは状態をもつ

-> WebAPI上の状態遷移
=> HTTPクライアント自体に状態をもてばいいのでは？

`状態管理できるクライアントがほしい`

> Rackの紹介
	WebAPIサイド
> Faradayの紹介
	クライアントサイド
=> gemまるごとではなく、Faraday Middlewareとして作ったらいいのでは？

#### Faraday Middlewareのgem作った

* faraday-navigation
	
	```
	historyをもつ。Webブラウザみたいに戻る・進むができる
	Link / Link-Template Headerでlinkの実現
	```

* faraday-link-extractor

	```
	WebAPIの種類に応じてリンクを抽出、Link / Link-Template Headerに変換
	```

gemのデモ

#### まとめ

* 疎結合にすることが大事
	処理を動的にしよう
* 再利用できるようにする
	アプリケーション / ドメイン固有のものを切り出そう

[個人的感想]

```
APIを使いまわしできるようにするとか、疎結合に作るっていうのは
仕事でも繋がる、とても大事なことだと思います。おもしろかった。
```

--------------------------------------------------------------------

### Deletion Driven Development: Code to delete code! by Chris Arcand @chrisarcand

redhat、ManageIQの人

[スライドへのリンク](https://chrisarcand.com/talks/deletion-driven-development-code-to-delete-code/)

以下は[講演内容のまとめ(公式より)](http://rubykaigi.org/2016/presentations/chrisarcand.html)を、Google翻訳したものです。

```
Good News！
Rubyは何年もの間に貢献してきたライブラリやレガシーアプリケーションの富と成功と成熟したプログラミング言語です。
Bad News：
これらのプロジェクトは無用の複雑さを追加し、新しい開発者を混乱させ、無駄な、未使用のコードを大量に含まれている場合があります。
まったくコードよりも維持するために簡単です何のコードがないので - 本講演では、私は嫌なものアウトあなたが明確に支援するために静的解析ツールを構築する方法を説明します！
```

ミネソタに住んでる
雪がすごい。自然いっぱい

I love deleting code
コードを殺すことだいすき

Dead codeとは？

* Over engineering
* Poorly written code
* Refactoring, deprecations

-> 誰がcareする？

`What if we could programmatically find unused code to delete?`

やること

1. Parsing the code

例を使ってparseしてみる
-> できない場合がある。動詞が前に来る場合などシンタックス error
=> Rubyでparseする場合は？

* gem紹介
ruby_parser
racc

2. Processing the s-expression

S式
process_*を処理

minimal parser

3. Building the dead 

send
fed

Rails DSL..
例) after_action, before_create..
-> manageiq(gem)

#### debride(gem)

```
.rb
-> parse
-> Generic processing
-> Call proccessing and reporting
```

[個人的感想]

```
具体的にコードがどう動くかを詳細に見せてくれた。スライドがすごく凝っている。
S式のことを勉強しようと思った。debrideのgemを見てみよう
```

--------------------------------------------------------------------

### Recent Advances in HTTP and Controlling them using ruby by Kazuho Oku @kazuho

[スライドへのリンク](http://www.slideshare.net/kazuho/recent-advances-in-http-controlling-them-using-ruby)

以下は[講演内容のまとめ(公式より)](http://rubykaigi.org/2016/presentations/kazuho.html)を、Google翻訳したものです。

```
Webサーバの設定は、OAuthのような技術、クライアントヒント、標準化になるHTTP/2プッシュとして、ますます複雑になってきています。
本講演では、設定およびラックへのインターフェイスに基づいて、Rubyのコードを記述することによって維持することができる方法を説明するだけでなく、HTTPおよび関連技術の最近の進歩を紹介します。
```

#### HTTP1 -> HTTP2へ

HTTP1は6requestsしか同時ではむりだったが、HTTP2は100requestsOK
HTTP2は2015年の5月から標準化。Firefoxは全体の3割

#### HTTP2が実際にどう使われているのか

* Header compression
* Multiplexing & prioritization
* Push

#### HTTP transaction

以下の3点の問題点がある。

1. respond to high-prority requests(優先度の問題)
	TCPに未送信データがたまる
	-> 優先度が高いやつを先に送りたいけど前に溜まってるからむり..
	=> 最適化で解決

	優先順位付け
	-> 優先順位を指定する。ただブラウザによって何を優先するか違う..(頭悪い子がいる)
	=> サーバ側で対処するしかない

2. CSS/JS -> HTML -> imagesの順で送る
	Hidden resourceの問題
	-> そもそもhiddenを使わない
	-> `link:rel=preload` を使う

3. キャッシュされないリソースだけ送る
	リソースの優先順位をつける
	リクエストの途中に投げる
	CDNのユースケース
	-> `Link Header` をつける
	-> `link: rel=preload` で対応できない場合は中間レスポンス
	-> HTTP2のサーバに設定を書く(例:mruby)
		(速さはアルゴリズムでなんとかなる)

[個人的感想]

```
HTTP2の話がわかってよかったです
ブラウザ起因は辛いなぁと思いました
```

--------------------------------------------------------------------

### Optimizing Ruby by Urabe, Shyouhei @shyouhei

Rubyコミッター
Money Forwordの中の人

以下は[講演内容のまとめ(公式より)](http://rubykaigi.org/2016/presentations/shyouhei.html)を、Google翻訳したものです。

```
私はRuby10倍速を作りました。
```

#### Ruby is slow

Rubyは遅い

* GCがあるから
* GVLだから
* 動的だから

-> 違う
=> 最適化されていないから
jRubyやRubiniusみたいなものをCRubyで実現

#### 最適化について

* Cのみで書かれている。移植性が高い
* VMの状態を変えない -> 軽量に動かせる

Floding constants
pureなmethod
-> pureかどうかはcheckするけど最適化はできない
=> 400倍速くなった！

[個人的感想]

```
最適化すればRubyははやくなる！
難しかった..
```

--------------------------------------------------------------------

### Game Development + Ruby = Happiness by Amir Rajan @amirrajan

[スライドへのリンク](http://slides.com/amirrajan/deck#/)

以下は[講演内容のまとめ(公式より)](http://rubykaigi.org/2016/presentations/amirrajan.html)を、Google翻訳したものです。

```
アミールラジャン（＃1のiOSゲームの作成者：ダークルーム）は、Rubyを使用してゲーム開発者になるための彼の旅について講演します。彼は、コード内の優雅さが画面上に優雅になる方法を示す、彼のゲームのソースコードを見ていきます。
```

* A Noble Sircleっていうgame開発した
	gameのコードの説明
	htmlを返しているみたい
	rubyで作ってる(たぶん)

* Node Kickっていうgame開発した
	ブラウザゲー
	絵を自分で描いた(demo)
	音声は自分
	nodeで動いてる。JavaScriptのcodeがカオスに

* A Dark Roomっていうgame開発した
	iOSアプリ

[個人的な感想]

```
スライドが凝ってる！
いろんなゲームのデモがあった。音声が作者本人
( 」ﾟ◻︎︎ﾟ)」~┻┻
```

--------------------------------------------------------------------

### Dive into CRuby by NARUSE, Yui @nalsh

TREASURE DATEの中の人
Rubyコミッター
本日の基調講演

以下は[講演内容のまとめ(公式より)](http://rubykaigi.org/2016/presentations/nalsh.html)を、Google翻訳したものです。

```
人々は時々CRubyの開発に関与したいのですが、しません。
私は、彼らがモチベーションを具現化していない可能性があり、それについては動作するのか分からないからだと思います。

私は、エントリポイントを見つけるコードを書く、MatzはそれをMerge作成する方法について説明します。
```

#### CRubyに貢献しよう！

-> なにしたらいいかわからない
-> 新機能を作る(新しいmethod追加)
-> 高速化、新しいプラットフォームを作る

#### ユースケースの重要性

今あるものじゃダメなのか？
-> 本当にほしいものはなんだろう
	(今までの例紹介: Web Crawler)
=> 色々考える必要がある
	名前とかインターフェース、ルール、今までとどう変わるか..
=> String#scrub
	その中のCのコードがどうなっているか

*やりたいことはちゃんと決めなければダメ*
-> 過去にもIssueにはあがったけどRejectされた場合もある
=> ちゃんと考えるには普段から考える必要がある

* new platformのはなし
新しいやつを作るとあっさり動くものもある
あっさり動かないものもある
-> 機械語を自力でメモリ上から引きずり出す

* パフォーマンス改善
ベンチマークをとってボトルネック探し(New Relic)
-> 最適化
=> ベンチマークを何でとるかは重要

`pid2line.rb` を作った
`SEGV`: セグメンテーション違反

問題見つけたらMatzになげてね

#### まとめ
* 現実のユースケースを収集しよう
* 現実のアプリケーションのボトルネックを知ろう

[個人的な感想]

```
Rubyコミッターからの質問が多数。笑
問題点、やりたいことをちゃんと考えるには普段から考える必要がある
というのはどこにでも通用する話だと思いました。
うーん難しい
```

--------------------------------------------------------------------

### Closing

--------------------------------------------------------------------

[3日目の感想]

```
今日Ruby2.4.0 pre2が会場からリリース！
Rubyコミッター黄色くて目立つ
RubyKaigiシャツ着てる人たくさん
Aaronさんと写真撮れた
お菓子充実
```