RubyKaigi2014に参加してきた(1日目)
▲3日目 おはよう Railsの様子
9月18-20日にタワーホール船堀にて開催されたRubyKaigi2014に参加してきました。 簡単ですが気になった発表について、感想を交えてレポートを書いておきます。
1日目
CRuby Commiters(Tomoyuki Chikanaga)
- CRubyのコミッタは80アカウント、実質50人ぐらいのアクティブなコミッタがいる
- RubyKaigiでスピーカーになっているのは15人
感想: ネット上やRubyKaigi会場で時々お見かけする方々が、どんな分野を担当してるか分かってよかった。
Building the Ruby interpreter -- What is easy and what is difficult?(Koichi Sasada)
- 10周年
- Rubyの開発は何が簡単で何が難しいかという話
- 何をやってきたか
- 本題
感想: 「なんとなく思いついたアイデアを実装するのは簡単。でも、まともに使えるようにするためには苦労が必要」という部分は、レイヤーは違えどどんなエンジニアにも共通なんだなと思った。私の仕事だと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
- 3rd party Activerecord adapter
- 標準にない機能
- Rubyの型とのマッチング
- 既存のテーブル設計をRailsに合わせるユースケースが多い
- 7つほど専用の命令が用意されている
- Oracleを使うことで何が良いか?
- オプティマイザが賢い
- プリペアードステートメントが賢い
- SQLインジェクションの対応に強い
- Oracle11g
- 1つのプリペアードステートメントで複数の実行計画を持つことができる
- User.where(:database => ‘oracle’).last.id
- ActiveRecord
- そのまま
- Oracle modified SQL
- 素のSQLではなく最適化されてる
- where文が書き換えられてる
- 実行計画を動的に変えてくれる
- where文で指定された列に該当する値が多ければフルスキャン
- そうでなければindexを使ってくれる
- 実行計画がメモリに蓄えられてシェアされる
- 素のSQLではなく最適化されてる
- ActiveRecord
- User.where(:database => ‘oracle’).last.id
- 問題点
- いくつかテストがコケる
- Empty string as NULL
- 長さ0の文字がNULLとして扱われる
- Identifier length <= 30 byte
- オブジェクト名は最大30文字
- “id” needs to set explicitly
- Oracleは明示的にidに入る値を書かなくてはならない
- No limit in sub queries
- limit句がサブクエリ内で書けない
- Empty string as NULL
- いくつかテストがコケる
- Rails4.2
- Adequate Record
- パフォーマンス改善
- Adequate Record
- Oracleとしての新しい機能
- 12cが最新機能
- 徐々に標準に近づけようとしている
- JSON Datatypeのサポート
- Better Top-N query support
- これのおかげでページネーションがまともに動くようになった。
- order_hacksというダーティーな処理を削除
- これのおかげでページネーションがまともに動くようになった。
- 12cが最新機能
- 環境作るのが大変だよね
- 1つのプリペアードステートメントで複数の実行計画を持つことができる
感想:発表前の会場挙手で意外とRailsでMySQLを使っている人が多かった。Oracleは普段使ってないけど、MySQLやPostgreSQLと比較して独特の仕様が多いように思う。その反面「Oracle modified SQL」で適切なSQLに書き換えれば高速に動作するところが素晴らしい。単に「ActiveRecordをOracleに対応させましたよ」というだけでなく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クローラー
- hypermicrodata gem
- HTMLをサーバーサイドでJSONに変換
- 状態遷移図を作って設定
- ブラウザと同じイメージで作ること
- HTMLじゃなくてJSONを書くときの注意
- まとめ
- Web APIはHTML Webアプリと同じように設計しよう
- RESTの制約・原則を意識するともっとうまくできる
感想:API設計で問題となる仕様変更についてのスマートな解決方法を学ぶことができた。クライアントが「次に読むべきURI」をアドレスではなくHTML内の文字で示すという考え方は面白い。「え?それってスクレイピングじゃ...?」という疑問に対しても「hypermicrodata.gem」という解決方法を準備してくれているのも素晴らしい。期限を設けてv1,v2...とバージョン番号で区切るしか無いと思っていたAPI仕様変更に対する問題に光明が差した気がした。