RubyKaigi 2016 1日目メモ #rubykaigi

rubykaigi.org

初参加だ

今年は京都で開催、しかも国際会館なので地下鉄一本でいけるアクセスのしやすさということで、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
  • 技術は行ったり来たりする
  • 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
  • ドキュメンテーションがほしい
  • 一部型指定とかいろいろ提案あるけど、どうもイマイチ
  • いろいろ課題はある => 改善の余地がある
    • エンジニアは技術でなんとかしたい
    • Static Typing with Type Inference(型推論
      • 静的な型は柔軟性が……
    • Rubyとしては別の何かが必要
      • Call soft Typing
      • Soft Typing
        • 振る舞いで決まる
      • 型の名前を決めるのは難しい
      • すべての型チェックできないこともあるが、元々0%なのでまし
    • 実行時の型情報なんかも使えそう(Gemのテスト時に得られたものとか)
      • Type DatabaseをGemと一緒にだしてコード補完に活用したり
  • まだ構想段階なので動いているものはない
  • We Care about YOU
    • 開発体験を改善したい
  • Ruby3いつくる?
    • わかりません
    • ちょっと無理そうな期限を設定してはっぱかけるのがコミュニティリーダーの役割かな?
    • 東京オリンピックのときにあるといいなぁ
    • 前に進み続けないといけない
  • Soft Typingの用語が元々アカデミックな用途と違うけど
    • 新しい言葉が必要

dRuby in the last century.

  • Masatoshi SEKI
  • dRuby => from 1999
  • 2000年にdRubyの話をここ(国際会館)でした
  • dRuby is OOPARTS
  • before dRuby
    • 昔っぽいUNIXを使った組み込みシステム
      • 小さなデーモンの組み合わせ
      • fork, pipeなど
      • selectはなかった
    • CGIの単純な世界
      • 俺マイクロサービス世代
    • ruby & shttpsrvにであう
      • 小さいアプリにwebサーバを組み込む
    • なにか気に入らない
      • RubyとWeb世界を翻訳しないといけない
    • Rubyのように振る舞う分散オブジェクト
      • RPCじゃくてRMI
    • 分散オブジェクトがあるような演出
      • 簡単通信ライブラリではない
  • 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
  • Hyalite
    • React like viretual DOM library
  • Isomorphic programming
  • Menilite
    • 作ってるところ
    • サーバとクライアントでRuby Codeを共有
    • ActiveRecordも対応
  • デモ
    • スムーズなデモ
    • 簡単に見える
  • Reactive RecordというActiveRecordを使ったものがある
  • サーバサイドとクライアントサイドではモデル求めるモノが違う
    • Meniliteを作った理由

Unifying Fixnum and Bignum into Integer

  • Tanaka Akira
  • Ruby2.4
    • Unify Fixnum And Bignum into Integer
    • Ruby使う人はFixnumやBignumクラスはなくなる
    • C使う人はいくつかのグローバル変数がなくなるので、影響あるかも
  • 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とか <= 自業自得だけど……
  • Cレベル
    • 利点が特にないかも
    • 内部表現は変わらない
    • ifdefで2.4以降とそれ以前でかき分けてください
    • 対応して、ライブラリをバージョンアップする場合はマイナーバージョンアップをおすすめ
      • gemの依存関係で悲観的なバージョン指定されている場合、使えなくなる可能性がある

Scalable job queue system built with Docker

  • Takashi Kokubun @k0kubun
  • ジョブキュー
    • 遅いタスクを実行する
    • ジョブを記述してデータストアにいれて、あとで実行
      • resque, sidekiq
  • キューに使うデータストア
  • Worker
    • resque
    • delayed_job
    • shoryuken
  • Barbeque
    • 新しく作った
    • Ruby実装
    • なにがはいってる?
      • Worker
        • serverengine
        • Dockerつかってる
      • webconsole
        • Rails engine
        • RubykaigiではRailsの話はしてはいけない(どっと笑いがおこる)
      • Queueing API
      • コマンド実行
        • 他の言語でも使えるように
  • なんでつくるのか?
    • いままでジョブキューをほとんど使ってこなかった
      • resqueはマルチプロセス
      • kuroko2というすばらしいバッチシステムがあった
        • リッチなwebコンソール
        • Dockerでjobを実行
        • Too muchな感じなのに使ってしまう
      • ジョブキューが必要な場面もあるので作ってしまった
    • workerを集中管理したい
      • アプリケーションがたくさんあるので管理が大変
      • Jobが簡単にデプロイできる
        • Dockerでほとんどのアプリケーションをデプロイ
        • ECSを使用しているので、既存の環境にはいるとオートスケールしてくれる => うれしい
  • 内部
    • キューはAmazon SQS
      • スケールするし、信用できる
      • 制限もある
      • QoS
        • at-leaset onceを選択 => これで困るようなことがないため
    • WorkerはRubyで実装
      • jobを実行するのはコマンド
      • jobを実行するのはhakoを使用
        • Dockerを使用する環境がころころ変わるのでコアに含めると管理が大変
    • RDBへの書き込みはworkerのみ
      • メンテでとまることもあるので、簡単にする
    • AutoScaling GroupでECSクラスターを拡張
      • 足りないときはEC2追加で自動的にスケール
      • いらないときも同様に
  • Dockerイメージを
  • ECSのログとるのめんどくさいけどどうやってるの?
    • ECS上で実行されたログはS3に
    • ECSに実行するログはcloudwatchにあるので、それを見られるアプリをつくってる
  • enqueueとdequeueの形がちがうのは?
    • enqueueは実装を隠蔽したい
    • dequeueはBarbeque workerからしかアクセスしないのでいらないかな?と判断

おまけ

お弁当

開けた

おいしかったです。