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仕様変更に対する問題に光明が差した気がした。
RubyKaigi2014に参加してきた(2日目、3日目)
2日目
Coming soon…(Yukihiro "Matz” Matsumoto)
- 2001年にRuby2の話をしている
- VirtualMachineが入る
- 6年後
- 笹田さんがきちんと実装してくれた
- M17N
- Native thread
- Generational GC
- VirtualMachineが入る
- RubyConf 2005
- Stabby lambda ( -> )
- RubyConf 2006
- 22のアイデアのうち7つは入らなかった
- オープンソースコミュニティはサメのようなものなので泳ぎ続けないと死んでしまう
- 燃料を投下したい
- Ruby 3.0のアイデア
- 最近登場した言語はスクリプト言語でありながら静的な型を持っている
感想: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
- starling
- unicorn
- Log Server
- Fluentd
- サーバープログラミングで考慮すべきこと
- マルチプロセス、マルチスレッド
- エラーハンドリング
- ログ
- ServerEngineを作った
- 何ができるか
- Unicornみたいなサーバーを簡単に作れる
- Worker moduleとServer moduleをユーザーが作る
- 3層構造
- 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日間の熱を冷まさないように、岡山での活動につなげていかねばっ!と思いました。