RubyKaigi2014に参加してきた(1日目)

f:id:tech-kazuhisa:20140920094741j:plain

▲3日目 おはよう Railsの様子

9月18-20日にタワーホール船堀にて開催されたRubyKaigi2014に参加してきました。 簡単ですが気になった発表について、感想を交えてレポートを書いておきます。

1日目

CRuby Commiters(Tomoyuki Chikanaga)

  • CRubyのコミッタは80アカウント、実質50人ぐらいのアクティブなコミッタがいる
  • RubyKaigiでスピーカーになっているのは15人
    • ko1
      • 笹田さん
      • Herokuでフルタイムコミッタ
      • 現行RubyVMの開発者
      • Ruby2.2からIncremental GCが使える
        • GCの停止時間を短くする
    • nari
      • Mr.GC
      • Lazy Sweep/Bitmap Marking
      • Symbol GCという新機能を開発
    • matz
      • Rubyの作者
      • mrubyの作者でもある
    • kazu
      • Kazuhiro NISHIYAMA
      • Mr. ‘fix typo
      • typoを修正する
    • hsbt
      • ruby-lang.orgの管理者
      • 最新のRubyでライブラリをチェックしてくれている
      • 最新のRubyRailsが動くのはこの人のおかげ
    • sorah
      • Shota Fukumori
      • Rubyのテストを並列実行するツールの開発で有名
    • kouji
    • ktsj
      • Kazuki Tsujimoto
      • RubyVMの不具合修正
    • tenderlove
      • Aaron Patterson
      • psych/dl/fiddleのメンテナ
      • AT&TからRedHatへ転職
      • Nokogiriの開発
    • keiju
      • Keiju Ishitsuka
      • Rubyの名付け親
      • irbの作者
      • 古くからある標準添付ライブラリの作者
    • seki
      • dRuby/rinda/erbの作者
    • zzak
      • Document maintainer
      • rubygems, rake, rdoc の開発者
      • カンファレンスフリーク
        • 全世界のカンファレンスに参加
    • kou
    • tmm1
      • Aman Gupta
      • Githubで働いている

感想: ネット上やRubyKaigi会場で時々お見かけする方々が、どんな分野を担当してるか分かってよかった。

Building the Ruby interpreter -- What is easy and what is difficult?(Koichi Sasada)

  • 10周年
  • Rubyの開発は何が簡単で何が難しいかという話
  • 何をやってきたか
    • アンダースタンディングコンピュテーション(本)
    • YARV (Ruby1.9)
    • Fiber
      • 同期的マルチスレッド
    • Ruby2.0ではメソッドキャッシュを高速化
    • Ruby2.1で世代別GCを導入
  • 本題
    • Rubyコミッタの責務は品質を高めること
    • 高速化
    • トレードオフとは
    • Ruby’s Performance
      • 簡単
        • VMJITをシンプルに作るのは難しくない
      • 難しい
        • 人間が管理可能な状態にする
        • VMのコードが爆発しないようにする
          • 同じようなコードに記述はコード生成を行った
        • 脱最適化
          • メソッドの再定義やevalによるローカル変数のアクセスが行われたら最適化を再定義する
    • 並列実行
      • 簡単
        • 並列実行を提供するだけなら簡単
      • 難しい
        • スレッドプログラミングは難しい
          • Programming model
          • Debugger
          • なんで難しいか?
            • 情報のシェア
          • 使いやすいデバッガを提供
          • forkしてプロセスを分ける

感想: 「なんとなく思いついたアイデアを実装するのは簡単。でも、まともに使えるようにするためには苦労が必要」という部分は、レイヤーは違えどどんなエンジニアにも共通なんだなと思った。私の仕事だとRubyで大量のデータを集計するバッチ処理を書くことが多くて、GCの遅さには悩まされてる。これが新バージョンのRubyで少しでも軽減されると助かる。

Controller Testing: You’re Doing It Wrong( Jonathan Mukai-Heidt)

  • controllers
    • bing action
    • small details
  • controllerはno logicであるべき
    • テストが必要なロジックはコントローラに書くな
  • before_filterを使う
  • Little to no logic in controllers.
  • shared examples cover the small details.
    • 認証テストをまとめる
    • 使いすぎるとどこでコケてるかわからなくなる
  • テストはチェックリストのように
  • 命令文ではなく平叙文的にテストをかけ

感想:「うーん。まぁそうだよね」と思う内容だった。shared examplesを使ってテストをまとめるとしても、やり過ぎるとテストが追いづらくなるし、可読性を求めて一箇所に書いてしまうとDRYじゃなくなりメンテしづらいしバランスが大切ということかな。「テストはバランスが大切」という話は3年ほど前からよく聞いてるし自分でも感じてるんだけど、これといって決定打が無いなとも思ってる。

Introduce Oracle enhanced adapter for ActiveRecord, another choice for your Rails database.(Yasuo Honda)

  • Oracle enhanced adapter maintainer
  • Oracle enhanced adapter
  • 標準にない機能
    • Rubyの型とのマッチング
  • 既存のテーブル設計をRailsに合わせるユースケースが多い
    • 7つほど専用の命令が用意されている
  • Oracleを使うことで何が良いか?
  • Oracle11g
    • 1つのプリペアードステートメント複数の実行計画を持つことができる
      • User.where(:database => ‘oracle’).last.id
        • ActiveRecord
          • そのまま
        • Oracle modified SQL
          • 素のSQLではなく最適化されてる
            • where文が書き換えられてる
            • 実行計画を動的に変えてくれる
              • where文で指定された列に該当する値が多ければフルスキャン
              • そうでなければindexを使ってくれる
            • 実行計画がメモリに蓄えられてシェアされる
    • 問題点
      • いくつかテストがコケる
        • Empty string as NULL
          • 長さ0の文字がNULLとして扱われる
        • Identifier length <= 30 byte
          • オブジェクト名は最大30文字
        • “id” needs to set explicitly
          • Oracleは明示的にidに入る値を書かなくてはならない
        • No limit in sub queries
          • limit句がサブクエリ内で書けない
    • Rails4.2
      • Adequate Record
        • パフォーマンス改善
    • Oracleとしての新しい機能
      • 12cが最新機能
        • 徐々に標準に近づけようとしている
        • JSON Datatypeのサポート
        • Better Top-N query support
          • これのおかげでページネーションがまともに動くようになった。
            • order_hacksというダーティーな処理を削除
    • 環境作るのが大変だよね

感想:発表前の会場挙手で意外とRailsMySQLを使っている人が多かった。Oracleは普段使ってないけど、MySQLPostgreSQLと比較して独特の仕様が多いように思う。その反面「Oracle modified SQL」で適切なSQLに書き換えれば高速に動作するところが素晴らしい。単に「ActiveRecordOracleに対応させましたよ」というだけでなくOracleの旨味を引き出していた。メインで利用するDBとしての選択ではなく、外部システムとのやりとりで接続することを想定してActiveRecordに追加命令があるのもありがたい。複雑になりがちなRailsでの複数DB接続に希望が持てた。

Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails(Toru Kawamura)

  • Sendagaya.rb
  • Web APIの話
  • 蜘蛛の巣のようなAPI
    • public
    • どう使われるか分からない
  • 蜘蛛の糸のようなAPI
    • private
    • どう使われるか分かってる
  • APIをRestfulにするかどうかは要件次第
    • 要件にあったAPI
  • 今回は蜘蛛の巣のようなAPIをどう作るかという話
  • Breaking Changes are Harmful
    • 壊す変更は有害
    • クライアントがiOSアプリだと変更に時間が掛かる
  • 人間が読めるドキュメントから作られるサービスがたくさんある
  • 機械が読める説明書から作られるクライアントもある
    • JSONで仕様を提供してコードを自動生成する
  • APIの変更がクライアントに反映されるべき
  • APIの説明を分割して各レスポンスに埋め込むのが良い
  • 疎結合が良い
  • APIコールのメタファーが危険
    • クライアントが次に何をするかはAPIから返ってくるリンクをたどる。=HYPERMEDIA
    • 普通のWebと一緒
      • ワークフローがあるから破綻しない
      • 人間は画面に表示される内容を目で見て判断して処理を行っている
  • HTMLクローラー
    • リンクをたどって情報を取りに行く
      • SEO用のMicrodata(htmlのタグ)を使ってる
        • ドキュメントの中に構造化データを埋め込んでいる
    • HTMLはAPIのデータ提供形式として利用できる
      • クライアント的には大変。JSON使いたい。
  • hypermicrodata gem
    • HTMLをサーバーサイドでJSONに変換
    • 状態遷移図を作って設定
      • ブラウザと同じイメージで作ること
  • HTMLじゃなくてJSONを書くときの注意
    • 状態遷移図を使うこと
    • 疎結合のためmodel.to_jsonはやめること
    • リンクとフォームを持ったJSONテンプレートを使うこと
  • まとめ
    • Web APIはHTML Webアプリと同じように設計しよう
    • RESTの制約・原則を意識するともっとうまくできる

感想:API設計で問題となる仕様変更についてのスマートな解決方法を学ぶことができた。クライアントが「次に読むべきURI」をアドレスではなくHTML内の文字で示すという考え方は面白い。「え?それってスクレイピングじゃ...?」という疑問に対しても「hypermicrodata.gem」という解決方法を準備してくれているのも素晴らしい。期限を設けてv1,v2...とバージョン番号で区切るしか無いと思っていたAPI仕様変更に対する問題に光明が差した気がした。

2日目に続く...