今年は京都で開催、しかも国際会館なので地下鉄一本でいけるアクセスのしやすさということで、Super Early Birdで申し込んで会社も有給休暇とって万全の体勢で行ってきました。今日は未来と過去の話、コンテナに関連する話が多め? 個人的にはhaconiwaとジョブキューシステムが気になる。DockerだとToo Muchになることもあるんじゃないかなといろいろ試してみて思っていたので、haconiwaのわかりやすさというのがよさげ。" Isomorphic web programming in Ruby"の発表は内容の面白さもさることながら、お手本にしたいプレゼンの進め方をしていた。非常にわかりやすくデモもスムーズにいっていてすばらしかった。
Ruby3 Typing
- Yukihiro "Matz" Matsumoto
- 大事なことは日本語で
- Ruby3
- Performance
- Concurrency
- Typing => Matz
- 2010's
- Many Static Typed Lang
- "Ruby is dead" "Rails is dead"
- Don't have Static Type
- 技術は行ったり来たりする
- 振り子みたいなもの
- Smalltalk => Java => Ruby/Javascript => Swift/Go etc => ?
- Futre of (Dynamic) Typing
- What is Type?
- Class は型ではない
- 継承も内部構造も関係ない
- 振る舞いが大事
- 動けばいい
- ここでスライドにトラブル
- StringIOとIOの例
- Static Typeだと動かないlog
- Duck Typingは未来に開かれている
- Rubyの型とは? Duckという概念
- Duck is not a (nominal) Type
- Duckは期待する振る舞い
- ClassによるTypeは近似でしかない
- GoのInterfaceはいい
- Wirteメソッドをもっていることだけが期待されている
- Duck Typingは素敵
- DRY
- 冗長性は削りたい
- Dynamic Typingの欠点
- 実行してみないとわからない
- ドキュメンテーションの情報が欠落
- ナンの引数?
- 絶対に型を書きたくないMatz
- ドキュメンテーションがほしい
- 一部型指定とかいろいろ提案あるけど、どうもイマイチ
- いろいろ課題はある => 改善の余地がある
- まだ構想段階なので動いているものはない
- We Care about YOU
- 開発体験を改善したい
- Ruby3いつくる?
- わかりません
- ちょっと無理そうな期限を設定してはっぱかけるのがコミュニティリーダーの役割かな?
- 東京オリンピックのときにあるといいなぁ
- 前に進み続けないといけない
- Soft Typingの用語が元々アカデミックな用途と違うけど
- 新しい言葉が必要
dRuby in the last century.
- Masatoshi SEKI
- dRuby => from 1999
- 2000年にdRubyの話をここ(国際会館)でした
- dRuby is OOPARTS
- before dRuby
- dRuby
- 分散オブジェクトシステム
- プロセス超えてメソッド呼び出せる
- みんなでデモやる
- OOPっぽさ
- 相互に呼び出せる
- 仕組みは本買ってください
- Twitterの初期はdRubyとRindaだったらしい
- いまはつかってない
- dRubyではじめて最後は使わなくなることがある
- これから
- 直したいところ
- セキュリティっぽいのを消したい
- アブナイモノは危なく見えるべき
- UnitTest
- セキュリティっぽいのを消したい
- 啓蒙していきたい
- まずおもしろがってもらう
- 並行処理の勘所に気づいてもらう
- 直したいところ
- わかる人がわかればいいと思ってたけど、心境の変化とかあった?
- はい
- るびまで寄稿お願いします
Welcome to haconiwa - the (m)Ruby on Container
- Uchio KONDO
- Before Haconiwa
- Docker, LXCを経験
- Dorne.io
- Dockerを使ったin houce CI
- 変なバグふんだ
- operation大変
- LA, CPU usage, memoryつらい
- Sqale
- PaaS by GMO Pepabo
- LXC usa
- resource reallocation
- configから変更したり手で変更したり煩雑
- ぶつかった問題を解決するコンテナを作りたい => Haconiwa
- Small tour of Haconiwa
- Container technology overview
- mruby, mrib使用
- Linux namespace => partitions in OS resources
- cgroups => CPUの使用制限など、デモでcpu4個あるが2つまでしか使ってないところを見せる
- Container = Isolation + Limitation
- Haconiwa & mruby
- はじめはcruby使ってた
- うごいたけど……
- system callsで制限
- mrubyに置き換え
- c system callつかうので
- いろいろgemがあった
- 自分でも書いた
- mruby-cli
- Container as Codeに落とし込める(まだ開発中だけど)
- Containerの数が変わったりしても、同じ数に維持できる
- mrubyをつかうことで大変だったこと
- ドキュメントが足りない
- ドキュメント書く人がほしい
- 目的を達成はどのくらい?
- あと一歩
- Jailとかはどうか?
- 今は計画なし
- FreeBSDの経験ないのでやろうとすると時間かかる
- He said NO!
A proposal of new concurrency model for Ruby 3
- Koichi Sasada
- だいありー
- 平行並列の八票多いのでconcurrent ruby kaigiではないか?
- マルチスレッドプログラムの難しさ
- Rubyは安全性、簡単さを想定
- マルチスレッドプログラムを正しく実装するのは難しい
- 簡単なものだったわかるかもしれないけど、どでかいプログラムだと? ましてやgemの内部の問題なんかだと?
- Ruby3でのConcurrency
- Guildというものを導入する
- Guildの中にスレッドが存在する
- mutableなオブジェクトはGuildの中に存在する
- メンバーシップがある
- 他のGuildからはアクセスできない
- Guild::Channelでやりとりをする
- GoLangのChannelみたいな感じ
- Array#concatの例からすると、やってることが違うような?
- ああいうことをやれないようにするという提案
Isomorphic web programming in Ruby
- Yoh Osaki
- Opal
- Ruby => Javascript
- Hyalite
- React like viretual DOM library
- Isomorphic programming
- Node.js?
- Javascriptが好きじゃない
- Rubyで書きたい
- Menilite
- 作ってるところ
- サーバとクライアントでRuby Codeを共有
- ActiveRecordも対応
- デモ
- スムーズなデモ
- 簡単に見える
- Reactive RecordというActiveRecordを使ったものがある
- サーバサイドとクライアントサイドではモデル求めるモノが違う
- Meniliteを作った理由
Unifying Fixnum and Bignum into Integer
- Tanaka Akira
- Ruby2.4
- Ruby2.3までは数値をあらわすのに3つのクラスで表現
- 整数はFixnumとBignum => 2.4でIntegerになる
- Rubyの規格では
- FixnumとBignumという名前は出てこない
- ↑二つのクラスは実装
- 規格には出てこない内容と考えた
- 2.4からはFixnumの範囲に依存した挙動を当てにしてはいけない
- Rubyを学習するのが簡単になる
- FixnumとかBignumという言葉はCommon Lispから来てる
- 教えることが減る
- ドキュメントも簡便になる
- 非互換
- FixnumやBignumがIntegerを参照する
- コード中にFixnumなどにアクセスすると、挙動が異なる場合がある
- 2.3 EOLまでは消すことはない
- Fixnumのrangeが隠れる
- MetaprogrammingとDSLが壊れる
- Sequelとか <= 自業自得だけど……
- FixnumやBignumがIntegerを参照する
- Cレベル
- 利点が特にないかも
- 内部表現は変わらない
- ifdefで2.4以降とそれ以前でかき分けてください
- 対応して、ライブラリをバージョンアップする場合はマイナーバージョンアップをおすすめ
- gemの依存関係で悲観的なバージョン指定されている場合、使えなくなる可能性がある
Scalable job queue system built with Docker
- Takashi Kokubun @k0kubun
- ジョブキュー
- 遅いタスクを実行する
- ジョブを記述してデータストアにいれて、あとで実行
- resque, sidekiq
- キューに使うデータストア
- Worker
- resque
- delayed_job
- shoryuken
- Barbeque
- なんでつくるのか?
- いままでジョブキューをほとんど使ってこなかった
- resqueはマルチプロセス
- kuroko2というすばらしいバッチシステムがあった
- リッチなwebコンソール
- Dockerでjobを実行
- Too muchな感じなのに使ってしまう
- ジョブキューが必要な場面もあるので作ってしまった
- workerを集中管理したい
- アプリケーションがたくさんあるので管理が大変
- Jobが簡単にデプロイできる
- Dockerでほとんどのアプリケーションをデプロイ
- ECSを使用しているので、既存の環境にはいるとオートスケールしてくれる => うれしい
- いままでジョブキューをほとんど使ってこなかった
- 内部
- Dockerイメージを
- ECSのログとるのめんどくさいけどどうやってるの?
- ECS上で実行されたログはS3に
- ECSに実行するログはcloudwatchにあるので、それを見られるアプリをつくってる
- enqueueとdequeueの形がちがうのは?
- enqueueは実装を隠蔽したい
- dequeueはBarbeque workerからしかアクセスしないのでいらないかな?と判断
おまけ
おいしかったです。