===========================================
RubyKaigi2016とは？
日本で開催されているRubyコミュニティ主催のオブジェクト指向プログラミング言語Rubyに関する年次イベントである。
by wikipedia
Rubiestが世界中から集まってくるイベントです。
今日はその1日目です。
その中で、私が聞いた講演をまとめてみました。
[Ruby3 Typing] by Matz
Rubyの父
型がこうなるといいなぁという話
最近は静的な言語が流行っている。
Rubyは静的な言語ではなく、動的な言語。
世の中の流れは、
動的が当たり前 -> 静的が当たり前 -> では次は..？
(JavaScript・Ruby) -> (Swift・Go) -> ?
流行ってきているからといって、静的言語を取り入れるのも間違っているのではないか。
未来の型について考えてみよう
Duck Typing
「アヒルのように鳴き、アヒルのようにふるまえば、それはアヒルである。」 という考え方。
プログラムでいうと、
継承、内部構造は関係ない。どういうふうにそのオブジェクトがふるまうかが大事。
そのオブジェクトさえちゃんとふるまえば、それはDuckである。
Duck Typingは 柔軟性が高い 。
プログラミングするときは色々考えければならない。プログラマの負担を減らしたいという思いがある。
負担を減らすということは、 オブジェクトがプログラマの期待されるふるまいを行う こと。色々考えなくて済むこと。
プログラマの脳の負担を減らす点において、Duck Typingは非常によい。
重要なのは 柔軟性 である。
そして、 DRY(Don't Repeat Yourself) であるということ。
静的言語のように、classによる型指定はDuckではない。
ただ、動的な言語のデメリットとしては
- 実行してみないとエラーがわからない
- エラーメッセージが親切じゃない
点がある。
型絶対に書きたくない!!
でも型はいる
未来のRubyはそのへんのジレンマをなくしたい。
-> 型推論 はどうか？
=> Static typingのようにチェックできて、Duck typingのように柔軟性があるものが望ましい。
-> Goみたいなものか？
=> Goのインターフェースは素晴らしい。でも、インターフェース書かなきゃいけない。書きたくない。。
Soft typing
(Soft typingという命名については色々議論があがっていました)
構想段階だが、型推論の考え方を盛り込んだシステム。
Duck typingを維持したまま型推論ができるといいな！
=> まだ構想段階
=> より早くエラーを見つけられるように。
=> よりプログラムが楽しくなるように、支援したい。
Ruby3
-> OSSには締め切りない..ロードマップない
=> でもプログラマが、みんなが楽に、楽しく開発できるように考えている！
=> OSSは進み続けなければならない。進化し続けなければならない！
Ruby3の重要な3つの点
- Soft typing(名前は違うかも)
- Ruby3は3倍速い!
- Concurrency
-> 目標は次の東京オリンピック..？
[個人的な感想]
途中スライドが止まってウサギが爆走するというハプニング
型推論のお話、おもしろかったです。未来のRubyはどうなるのか。
[Who reordered my code?!] by Petr Chalupa in English
ORACLEの方。英語での講演でした。
以下は講演内容のまとめ(公式より)を、Google翻訳したものです。
JITコンパイラとCPUで並べ替え - Rubyが速く3倍になり、並列計算をサポートするために開始するよう待機している。
そこには隠れた問題があります。
本講演では、我々はいくつかの簡単なRubyのスニペットを最適化しようとすることから始めましょう。
システムのルールが許す限り我々は、 JITの役割とCPUと注文操作を再生します。
その後、我々は、スニペットに2つ目のスレッドを追加し、それが恐ろしく壊れるとしてそれを見ます。
第二部では、Rubyにメモリモデルを導入することにより、不要なreorderingsを修正します。
私たちは、並列実行のための高速なコードを書くために使用することができますどのようにスニペットを修正し、どのように詳細に説明します。
Rubyで並列処理をしたときに、メモリをあまり使わないように
効率的にcompileしよう
というお話でした。(たぶん)
[個人的な感想]
私には難しくて理解が追いつかなかったです..
誰か教えていただきたいです..m
[A proposal of new concurrency model for Ruby 3] by Koichi Sasada
笹田耕一さんです。Rubyコミッターとして、Rubyの並列処理のアイディアについてのお話でした。
以下は講演内容のまとめ(公式より)を、Google翻訳したものです。
このプレゼンテーションでは、 Rubyの3のための並列実行をサポートするために、新しい同時実行モデルのアイデアを提案しています。
今、 Rubyは同時実行をサポートするための「スレッド」を持っています。
しかし、スレッドセーフなプログラムを作ることは非常に難しい
私たちは並行オブジェクト突然変異のすべてを管理する必要があるためです。
このような困難を克服するために、我々は、新しい同時実行モデルは、並列実行を可能に提案します。
このプレゼンテーションでは、次のトピックを示しています。
（ 1 ）なぜスレッドプログラミングは難しいのですか？
（ 2 ）新しい同時モデルの提案とその理由、このmdoelは簡単ですか？
（ 3 ）現在の設計、実装、およびこのアイデアの実装。
concurrency って言葉みんな大好きだよね
concurrency = 並列処理
その並列処理のアイディアについての発表
Guild という名前の新しいモデル
- CとRubyを比較してみよう
Rubyは文字列を、文字列オブジェクトを用いて処理する。
CはGCがないので、メモリの開放を自分で適切に行う必要がある。
RubyはGCがあるので、その点で悩む必要はない。
Rubyはsafetyでeasilyなアプローチをしている。
根幹にあるのは Happy Programming! という考え方。
並列処理の問題
並列処理はは難しい。
- データレスの問題
- プログラム自体の同期による問題
- デバッグが難しい
違う言語はどうか？
- Racket
- Elixir
- Clojure
Elixirについてならこの本がありますよ。とのこと。
pipeで繋げば並列処理は実現できるが、コピーなので時間がかかるというデメリットがある。
データは読み込み専用で共有すれば、排他制御について考えなくても良い。
様々な考察の末、Ruby3のゴールは何か。
Ruby3 のGoal
- keep compatibility 互換性を保つ
- parallel program 並列プログラム
- shouldn't consider about locks any more 排他制御は考えなくても良い
Guild 新しいアイディア。
- マルチスレッド
- スレッドセーフ
- 簡単に！
=> Ruby3へ！
[個人的な感想]
並列処理をするため、Ruby3に向けてのアイディアの発表でした。
中の人がいろんなことを考えながら開発しているのがよくわかりました。
Isomorphic web programming in Ruby by Yoh Osaki
youchanさんです。
以下は講演内容のまとめ(公式より)を、Google翻訳したものです。
昨年RubyKaigiで、私はHyalite、Rubyで実装された仮想DOMを導入しました。
HyaliteはRubyistsフロント書くと、Rubyで多くの利点を提供することが証明されているアプローチをコードバックエンドすることができます。アプリケーション・スタック全体で単一の言語を使用することは、時にはとして同型のプログラミングと呼ばれています。
本講演ではOpalと同型プログラミングのための新しいフレームワークが導入されています。Menilite。
Objectをmarshallingし、自動的にデータベースに格納することにより、サーバー側とクライアント側の間Menilite株式モデルコード。
その結果、コードの重複を削減しないとAPIはもはや必需品です。
同形プログラミングが大幅にプロジェクトの進捗状況を加速させることができます。私は心からあなたがWebアプリケーションを開発する際に、それが参考に願っています。
Meniliteは、Ruby言語、開発者の幸せのために最適化された言語のために活躍の場を拡大することを目指しています。私はあなたが私たちが同様のフロントエンドにRubyをもたらすことによってさらに多くの幸せを見つけることに同意するものと確信しています。
RubyKaigi2015では..
Opal opal
frontendをrubyで！
(RubyをJavaScriptに変換する)
-> Hyaliteというgemの発表
RubyKaigi2016では..
- Isomorphic web programming
-> nodeが有名だけど..javascriptじゃない
Menilite
Menilite というgemの紹介
いま作り途中
ライブコーディングをしながらの紹介。
ログイン、認証、ユーザのアクセス権を作るところを見せていただいた。
できること..
- model on the client side and server side!
- オブジェクトのマーシャリング
- ActiveRecord
Validationは？
- サーバサイドからのvalidation
- クライアントサイド側のvalidation
-> どちらもできる！
Object Marshalling
- CRUDのAPIを自動生成
- Controllerもある。actionも定義できる
- Storeはmodelとfront側両方ある
silicaというgemも併用で使用
[ライブコーディングを見た個人的感想]
controller側はreactみたいなかんじのコードになってる
react + rails でやっていたことをrubyのgemでやっているかんじ。すごいおもしろい！
newからcreateに変えるだけでmodelへのINSERTがはしる
newだけだとmodelへINSERTしないからリロードしたらクリアされる
action て書くとclientサイドからの情報をmodel側に渡すことができる
Reactive Recordというものもあるけれど..
サーバサイドとクライアントサイドで求められるものは違う。
- GUID -> サーバサイド。model
- Access controllの仕組み -> これはクライアントサイドでやるべき。
silica はこれから育てていきたい(いまはnewしかない)
将来的には、migrationを自動生成できるようになりたい
[個人的な感想]
FlontendもRubyでかけたら素敵!!
reactっぽいコードでおもしろかったです。デモも歓声があがっていました。
[Unifying Fixnum and Bignum into Integer] by Tanaka Akira @tanaka_akr
@tanaka_akr さん。Rubyコミッターの方です。
以下は講演内容のまとめ(公式より)を、Google翻訳したものです。
Fixnumか、大数と整数：Rubyは整数を表現する3つのクラスがあります。
整数はFixnumかとBIGNUMの抽象スーパークラスです。
Fixnumかは言葉に収まる小さな整数を表します。
メモリがいっぱいになるまでBIGNUMは任意の整数を表すことができます。
Fixnumかの正確な範囲は、マシンのアーキテクチャとRubyの実装によって異なります。
FixnumかとBIGNUMは実装の詳細であるため、
Fixnumかの範囲に依存するアプリケーションは、少なくともポータブル、そしてほとんどの場合、単に間違っていません。
私たちはRubyの2.4用の整数にFixnumかとBIGNUMを統一します。
これは、Rubyのプログラムは少しよりポータブルになります。
また、実装の詳細を隠蔽することは初心者が学ぶことのためにRubyが容易になります。
Ruby2.4では Fixnum classやBignum classがなくなるよ という話。
では何になるのか？
-> Integer classになる
影響は？
-> name errorはおきないよ
-> global変数はなくなる。コンパイルエラーになる
- なぜそんなことをしたのか？
- どんな狙い？
Q. Fixnum and Bignumってなに？
A.
Ruby2.3では..
- Fixnum: class for small integers 例) 1.class
- Bignum: class for big integers 例) (2**100).class
Ruby2.4では..
- 1.class
- (2**100)
=> どちらもIntegerが返ってくるようになる
Rubyには仕様、規格がある。
-> あるけど..FixnumとBignumっていう名前はでてこない
-> 国際規格では定義されていない
-> でも定義してもいい
=> FixnumやBignumって定義しにくい..というか依存しちゃいけない
FixnumとBignumがなくなると
いいこと
* より簡単になる
* よりクリアになる
* ドキュメントの内容も減るよ
わるいこと
* 間違った使い方でも動く
* Fixnum、Bignumに依存することができなくなる
こうやっても動く！
Fixnum == Bignum => true
1.is_a?(Bignum) => true
(2**100).is_a?(Fixnum) => true
コミッターは色々なことを考えながら意見を言い、コードを書く。
それをMatzがまとめる -> GO!という流れでやっている。
[個人的感想]
ひとつ仕様を変えるのにも色々考えられている。Ruby側からみた問題点、なくなったらどうなるか..
C側からみた問題点など様々なことを考えてRubyは作られているんだと思いました
[Scalable job queue system built with Docker] by Takashi Kokubun
cookpadの方です。
以下は講演内容のまとめ(公式より)を、Google翻訳したものです。
job queue systemが長時間非同期タスクを実行することが不可欠であったが、我々はRubyで構築された典型的なジョブキューシステムにおけるいくつかの問題を抱えています。
あなたは今までにjob queue systemの可用性、スケーラビリティや運用コスト苦しんでいますか？あなたが仕事に適している別の言語でジョブを実行するためにしたくないですか？
今年はDockerを使用して新しいjob queue systemを構築しました。
本講演では、これらの問題はRubyで構成されたシステムで解決することができる方法を知っていますよ。
新しいjob queueシステムの話
job queueとはなにか？
-> 遅いタスクをあとで実行するためのシステム
-> queue -> workerを使う
Rubyでjob queueを実行するには？
- jobをsidekiqに登録
- workerがrequeue
- 実行
という流れ
Data store for a queue
- Redis
- RDBMS(PostgresSQL..)
- RabbitMQ
- Amazon SQS
Worker to perform a job
- Redis使う
- delayed_job
- Amazon SQSを使うには -> shoryuken
Barbeque っていうgemを作った！
job queueシステムのコアの部分
どんな機能か？
- worker
Dockerにのせる
slackの通知とかもできる
- Web API(Queueing API)
parameterでqueを指定。
enqueueはjsonでPOSTする。
resqueueもPOSTすればjsonで返ってくるよ。
responseもjsonでかえってくる
- Web Console
rails engineを使ってる
jobの内容とかもGUIで見れる！
ActiveJobも使える！
jobはコマンドで実行。rake task
-> pythonでも実行できる！
なぜ新しいjob queueシステムを作ったのか？
-> いままで全然使ったことなかった
-> sidekiqとか、redisとかunicornとか使ってた
- kuroko2 っていうシステムがあった
kuroko2っていうのは、スケジュールバッチ実行
すぐやりたい処理に10分に1回バッチまわしたり..
本来job queueを使うべきところにkuroko2を使っていた。
あと運用コストを減らしたかった
(kuroko2もオープンソース化するよ！今後)
workerを集中管理したい。管理しやすいようにしたい
=> resqueとかsidekiqをぼこぼこたてられると管理できなくなる
=> 既存の仕組みに乗っかりたいのでdockerを使っている
(dockerでほとんどのアプリケーションをデプロイしている)
(AWSのEC2 -> Docker。インフラは基本的にAWS)
分散。スケールする(AWS ECS)
- at most one
- at least one <- 選択！
- exactly one
Auto scaling
ECSはあらかじめjobの数、リソースを計算しておく必要がある。
-> jobの数が増えたら勝手にリソースが増えるっていうことを実装！
-> リソースがちゃんと計算できるから、少ない時はサーバの監視
[個人的感想]
人数があふれててすごい人気でした。
barbeque、使ってみたいです！
[1日目感想]
いろんなRubiestに会えてとっても楽しい！
Rubyコミッターの人、世界中からRubiestが集まっています。
色々吸収して帰りたい。