RubyKaigi2014に参加してきた(2日目、3日目)

1日目はこちら

2日目

Coming soon…(Yukihiro "Matz” Matsumoto)

  • 2001年にRuby2の話をしている
    • VirtualMachineが入る
      • 6年後
      • 笹田さんがきちんと実装してくれた
    • M17N
    • Native thread
    • Generational GC
  • RubyConf 2005
    • Stabby lambda ( -> )
  • RubyConf 2006
    • Bikeshed argument encouraged
      • 自転車小屋の色を何色にするかは盛り上がってすぐに決まるが、原子力発電所をどこに作るかは有識者の間で勝手に決まってしまう
  • 22のアイデアのうち7つは入らなかった
  • オープンソースコミュニティはサメのようなものなので泳ぎ続けないと死んでしまう
    • 燃料を投下したい
  • Ruby 3.0のアイデア
    • Concurrency
    • JIT(LLVM?)
    • Static typing
  • 最近登場した言語はスクリプト言語でありながら静的な型を持っている
    • TypeAnnotation
      • def connect(r -> arg) -> Fiber みたいな
    • パフォーマンスのためのStatic言語が必要なわけではない
      • 思い込み
    • コンパイルタイムの短縮
    • 型を導入すると柔軟性が減る
      • ダックタイピングと相性が悪い
    • Documentation
      • 今はnumと書いてたら数字というルール
      • メソッドに何を渡せばいいか型宣言をみればわかる
    • RubyがStatic Typingを持っていない理由
      • なくてもなんとかなる
      • ダックタイピング
    • 静的な型を導入するとしてもOptionalな仕様になる
      • 型ありの世界から型なしの世界に渡すと情報が失われる
        • ごく一部だけの型チェックしか行われない
      • TypeScriptは頑張ってすべての型を指定している
      • すべてを型指定したRubyはRubyじゃない
      • 型が推測できるようなコードを書いている
        • いちいち型宣言したくない
        • ベストエフォートな型チェックをする技術
          • Duck Typing的に型を推測する
      • コンパイラに型を教えるのではなくて、コンパイラが「こう思って書いてるんですよね？」という推測を行ってほしい。IDEやエディタから補完できるようになる。
      • Two language is one.

感想:Ruby3.0に導入されるかもしれない機能のお話。私はPythonのように、制約はないけどDocumentとして引数の型を書いておくという手法はアリかなと思う。けど、まつもとさんはとにかくコード量を減らしたい仕様にしたいみたい。コードの文脈からしてこのメソッドの引数にはintが入るであろうことは、言語が判断すべき。わざわざ型を指定しなくても、文脈で判断できるのが良いコードという認識なんだと思った。現在RubyMineとかのコード補完やチェックはかなりのレベル（ホント、どうやってるのか不思議なくらい）まで来ているので、言語側がサポートしてくれればより精度の高いコーディング補助が可能になると思う。今後Rubyがどのような進化をとげるのか楽しみ！

<%= link_to "bundle", "update" %> - Make "bundle update" more fun to review(Kensuke Nagae)

  • bundle update
    • Gemfile.lockが更新されるが、各Gemがどんな変更が行われているかを見たい。
  • Compare Linker
  • GithubからCompare Linkerがwebhookを受け取る

感想: bundle updateする→Gemfile.lockがなんか更新されてる→いつ更新してるんだろうとRubyGemsを見に行く→何が変わってるんだろうとGithubを見に行く... という流れは私もよく体験する。これを自動化してGithubに変更点のDiffを見ることができるリンクをpushする仕組みを作ったお話。3回同じことをやったら自動化しろとはよく聞くが、この複雑な処理を自動化したのは素晴らしい。

ServerEngine: a framework for multiprocess servers in Ruby(Masahiro Nakagawa)

  • fruentd
    • ログ収集ソフトウェアのメイン開発
  • System programs
    • Chef
    • Serverspec
    • Apache Deltacloud
  • Network server
  • Log Server
    • Fluentd
  • サーバープログラミングで考慮すべきこと
    • マルチプロセス、マルチスレッド
    • エラーハンドリング
    • ログ
  • ServerEngineを作った
  • 何ができるか
    • Unicornみたいなサーバーを簡単に作れる
    • Worker moduleとServer moduleをユーザーが作る
  • 3層構造
    • Supervisor
      • ユーザーがあまりいじる箇所はない
    • Server
    • Worker
  • USR2 signalでリロードできる

感想: 操作感はまさに慣れ親しんだunicornそのもの！webrickも非常に便利なWebサーバーだが、ServerEngineを使えば大規模アクセスにも対応したunicornライクなサーバーを作ることができそうだ。

3日目

おはようRails

  • (あまりの面白さにメモ取ってなかった)

    感想: tubolinksはみんな消してるんだなー、とか今の若い子は「Railsは業務で使うもの」だと思ってるとかなかなか刺激的な内容だった。正直、私はあまりサービス志向のプログラマじゃないので（社会人としてそれはどうなんだというのはさておき...）Rails使ってサービスを素早く立ち上げるって点はあまり興味ないかも。自分が楽しめる仕事をやっていきたいなーと思っております。

Speeding up Rails 4.2(Aaron Patterson)

  • ManageIQ
  • Rails no one commiter
  • Rackはもう終わり。楽じゃない
  • Rack 2.0
    • the_metalはrack2.0のプロジェクト
  • Rack 1.xの問題
    • hashのkey
    • ストリーミングの制御がめんどくさい
  • Adequate Record
  • URL PATHは短いほうが速い
    • 配列的な構造を定数に変換することでスピードアップ

感想: たこ焼き仮面ことAaronの日本語での発表はとても楽しく聞くことができた。特にスライド内のジョークを日本人のセンスに合わせているところがGood! 発表内容としてはAaronさんの地道なRails高速化についてのお話がメイン。長く運用するシステムでは長期的に見ると細かい点が積み重なり問題を引き起こすことがあるので、このような改善はとてもありがたい。「存在しないコードが一番速い」というのは名言だと思った。

Everything is Broken: A Story of Hope(Jonan Scheffler)

感想: あまりRubyに関係がある内容では無かったが、公開鍵暗号の仕組みを色の混ぜあわせで解説する方法はとてもわかりやすかった。私も他人に説明するときは使わせてもらおう。

以上が3日間でビビッときた発表でした。 RubyKaigiはいつもネット上でしか交わらない方とリアルでお話することができる素晴らしいイベントです。この3日間の熱を冷まさないように、岡山での活動につなげていかねばっ！と思いました。