Programming log - Shindo200

イベント参加記録とプログラミング系の雑記

RubyKaigi2013に参加してきました

国内最大級の Ruby カンファレンス『RubyKaigi』をご存知でしょうか。RubyKaigi は2006年から年1回のペースで開催されていましたが、諸処の事情により2011年7月に開催された『RubyKaigi2011』を最後にして、RubyKaigi を終わらせることになりました。私が Ruby を使い始めたのが2011年9月頃からでしたので、RubyKaigi2011 には参加していなかったのですが、会議の規模の大きさや楽しさについては参加された方から話を聞いていました。「終わってしまったのが残念」「参加してみたかった」と思っていたのですが、2013年5月に RubyKaigi が復活すると突然の告知がありました。チケットの価格に戸惑いましたが、参加したいという思いが強かったので、『RubyKaigi2013』に参加してきました。RubyKaigi2013 は5月30日から6月1日までの3日間の開催でしたが、私は2日目(5月31日)から参加しましたので、2日目以降の講演からいくつかピックアップしてレポートを書きます。

f:id:Shindo_Masaya:20130531181449j:plain:w400
※上の写真は2日目の講演「RubyCommitters vs. TheWorld」からです。

講演のレポート

Continuous gem dependency updating with Jenkins and Pull Request

運用中のアプリケーションで使用している gem をアップデートするときは、どのようなツールを使い、どのような方法で行うのが良いのか、@kyannyさんが発表しました。
gem をアップデートせずに溜めていってしまうと、後でアップデートするときのコストが高くなってしまうので、日々少しずつ改善することが大事だと話しました。しかし、gem がアップデートされているのかを自分で確認して、手作業でアップデートしていくと起こることとして、以下のような問題を指摘しました。

  • やる気がある最初のうちしかアップデートをしない
  • 無意識にアップデートを行うようになれるまでに定着しない
  • アップデートがあったことをメールで通知する方法を取っても、プレッシャーを感じないので無視してしまう

そこで、gem のアップデートの「自動化」と「可視化」を行うことで、これらの問題を解決されたそうで、アップデートを自動化を行うために Jenkins を使用し、可視化を行うために Github の pull request を使用した話しました。ここで、Jenkinsに登録したコマンドを紹介しました。

$ git checkout -b YYYY-MM-DD
$ bundle update
$ bundle exec rake spec
$ hub pull-request

Github ならば毎日絶対に見ることと、pull request 数が0になっていないと気になるという心理を利用したそうです。「周りの環境を少しずつ改善すること」「続けること」が大事だと締めくくりました。

Ruby on Your Rails

DHH 氏に対して、ActiveRecord の仕様に様々な提案を出したときの問答の様子を、Rails のコミッターである@amatsudaさんが発表しました。ActiveRecord3 には、SQL の NOT 演算子や LIKE 演算子に相当するメソッドが存在しませんでしたので、それらを使った条件を書くときは以下のような書き方をしていました。

User.where(:name != 'Matz')
User.where(name: {not: 'Matz'})
User.where(not: {name: 'Matz'})

そこで User.where.not や User.where.not_like と書けるように、not や not_like メソッドを加えることをDHH氏に提案しました。ActiveRecord4 では not メソッドだけ取り込まれました。ActiveRecord 以外にも、Controller から params を隠蔽するために、パラメータをメソッドの引数で受け取れるようにする asakusarb / action_args を提案しましたが、引数の名前とクラスに関連性がないという理由で取り込まれなかったそうです。

Rails Gems realize RESTful modeling patterns

Rails の有名な gem は、どの情報をリソースとしているのか調べたことを@tkawaさんが発表しました。REST は「Web上に存在する名前を持った情報をリソースとして、リソースに対して4つの簡単なHTTPメソッド(GET, POST, PUT, DELETE)を発行して、処理を行うべき」という思想があります。Rails では、route.rb に resources と書くことで、RESTの思想に沿ったルーティングがされますが、この resources を利用することで以下のようなメリットがあることを話しました。

  • URI が決まるので、開発者はリソースの名前だけを考えればよくなり、設計しやすくなる
  • 外部の開発者でもURIを見ただけでアプリの動きがわかるようになる

REST が提案され始めた頃は「そんな単純な考えで上手くいくのか?」と言われていたそうですが、多くのアプリケーションが REST で組まれていますし、Rails は今も REST を推奨していますので、上手くいってきていると話しました。どの情報をリソースとするのかは開発者が考えなければいけないことですが、すでに REST の思想に沿った Rails の gem がたくさんありますので、その中からいくつかの gem を紹介して、リソースのパターンを見ていきました。ログイン認証の gem として Devise と Authlogic を紹介し、これらは Session という単数のモデルをリソースとしていると話しました。他に検索の gem として Ransack を紹介し、検索対象のリソース(User など)とフィルタリングのリソース(Filtering)を組み合わせていることを話しました。リソースモデルに迷ったら他の gem を見てみることを勧め、リソースパターンについてまとめたブログを紹介しました。

感想

7月の岡山Ruby会議で実行委員長をされる@gutch_jpさんに挨拶できたり、Matz さんと写真を撮らせていただいたり、『スタートアップRuby』の著者の方々にサインをいただいたり、海外からの参加者に日本語で話しかけられ、相手は頑張って日本語で話しているのに、私は全く英語で話せなくて辛い気持ちになったりと、刺激を受けた出来事が多くて楽しかったです。そのせいか、帰宅してから一気に疲労感が襲ってきて、今はぐったりしています。ブログに書かなかった講演でも興味深い内容がありました。(一つだけメモしておくと、Netzke が気になっています。)RubyKaigi2013の開催に関わった方々は大変だったと思いますが、ありがとうございました。お疲れ様でした。

f:id:Shindo_Masaya:20130601181130j:plain:w400