3日目
Rails Gems realize RESTful modeling patterns(Toru Kawamura氏)
一般的によく使われているgemに着目して良いリソースデザインを取り入れるというお話。
Gemを作ったりAPIをデザインするときに参考になるお話でした。
以下はメモ。
Railsのresourcesは設計しやすい、理解しやすい 。
/users/1
いろいろな書き方がある中でこれをRailsは選択している。
これを書いてれば同名のcontroler,model,viewが存在する(可能性が高い)ので共同の開発者に理解されやすい。
「制約が自由をもたらす」(DHH)
発表では以下のGemが作り出すresourcesを例にあげていました。
- devise(認証系、モデル無し)
- Authlogic(認証系、モデル有り)
- Ransack(検索)
- wicked(ウィザード)
Gemを作る人はResourcesのパターンも考えること。
Casual Log Collection and Querying with fluent-plugin-riak(Kota Uenishi氏)
fluentdのデータをRiakに入れてSQLで検索するというお話。
fluentd + mongodbという運用パターンが多い中で別の選択肢があるのはいい感じ。
以下メモ。
- RiakはBashoが作った
- サービスやりたい人たちが安眠できるDB
- DocumentDBっぽいかんじ
- なんでもかんでもriakにいれてOK.
- fluent-plugin-riakがある
- Mohairを使えばSQLライクに検索することができる
Complex Event Processing on Ruby and Fluentd(tagomoris氏)
アプリごとに異なるメトリクスをどうやってログから判断するかというお話。
norikraのデモはインストールから行われており、非常にイージーにスタートできそうな感じ。
以下はメモ。
- ストリーム構成とバッチ処理のハイブリッド処理
- norikraを使えば過去n分間のデータの集計がリアルタイムでできる
- 今のところデータの永続化はされない
Fight with Diversity(田中哲氏)
dbmというデータベースのライブラリをリンクするための設定ファイルextconf.rbのお話。
Matzの「多様性は善」という言葉に立ち向かうという内容。
「まぁ、あんまり使ってる人はいないんですけどね」とご自身も言われていたとおり、私は使われていないのならRubyから切り離せばいいのにと思ってしまいました。でも結局メンテし続けているということはご自身でdbmを使われたいのかなと。
最近のMatzの言葉に「最も大切なのはモチベーション」というのがあります。これだけの困難を乗り越えてまでdbmを使われたいというモチベーションがもたらすパワーは素晴らしいと思いました。
2日目
High Performance Rails(Issei Naruta氏)
クックパッドでRailsアプリケーションの高速化を担当されている@mirakui氏のお話。
以下はメモです。
- レスポンスタイム200msが速い、遅いの指標
- ログのレスポンスタイムを見るときにX-Runtimeを見るべき。この値はアプリケーションサーバーの最も外側に位置するRackが計測しているので実測値に近い
- チューニングの大前提は「Rubyに処理をさせない」。特にActiveRecordオブジェクトの生成が重い
- ルーティングはcontroller名、アクション名を指定せず名前付きルートを使ったほうが高速
- スロークエリはArproxyを使ってfluentdに記録している
Continuous gem dependency updating with Jenkins and Pull Request(NAGAE KENSUKE氏)
刺身ブーメランさんの依存したGemのアップデートをJenkinsで行おうというお話。
技術的な点だけでなく
- 人力で依存性を解決するという「やる気」に依存する作業は長続きしない
- メール通知だと「義務感に欠ける」
など心理的な面を強調していたのが印象的でした。
Jenkins氏のアイコンがついたユーザーからプルリクを送るというのはとてもいいアイデアだと思いました。
Concerning `Applications'(諸橋恭介氏)
moroさんのAcitveSupport::Concernのお話。
以下はメモ
- AcitveSupport::ConcernとはRubyのmoduleを拡張してるもの
- Rails4ではConcernの置き場所も決まっている
- 共通処理をまとめる。名前をつけてその性質を切り出す
- ただ分けるだけじゃなくて、リファクタリングすること
- refinementsを使えばベースクラスを汚染すること無く 機能を拡張できる
このお話を聞いた後、テンションが高くなった私はホテルでプロジェクトのコードをリファクタリングしてModelの共通処理をConcernに切り出しました。今までは独自の方法で動的に作成されてたメソッド群が本来のレールに乗った感じ。月曜日にテストしてマージするのが楽しみだ!
1日目
The History of Ruby;20th Anniversary Ed.(高橋征義氏)
2007年に第1回目のRuby会議がお台場で開かれた。
Rubyの20年の歴史を振り返る内容。
私はRailsを動かすためにRubyを覚えたAfterRails世代(せんそうを知らない子供)なので昔話は非常に興味深く聞くことができました。
以下は印象的だった事象だけメモ。
1995年
Ruby0.95
初めて普通の人が触れるRuby
1996年
Ruby 1.0リリース(知る人ぞ知る時期)
海外
2001-2004年
初の英文書籍 Programming Ruby
無料の電子版も公開された。RubyConfが開催された。この頃は「海外で知る人ぞ知る言語」となった。
2005年
2006年
CVSからSubversionへ
Rubinius、Mongrel、Capistrano、Engine Yard
2010年
CRuby1.9.2、Rubinius 1.0、Rails3.0、RVM、Bundler
2011年
RubyKaigi最終回
Ruby1.9.3
2012年
ISO認定、mruby、RubyMotion
Ruby2.0 リファレンスマニュアル刷新計画(okkez氏)
未だにArrayやStringなど基本的なクラスの情報はるりまを見ることが多いです。そのメンテナンス状況のお話を聞きました。
Two Legal Bodies about Ruby and its projects(杉原氏、福田氏)
一般財団法人Rubyアソシエーションの活動についてのお話。
ユーザーコミュニティ中心の「日本Rubyの会」と比較し「エンタープライズ領域へのRuby普及」を目指してる。
Rubyの開発、保守体制
- ビジネスの世界から見ると不安に感じる。
- ビジネスサイドの不安→今後も機能は発展していくか。継続性は?
- 安定版の保守事業。Ruby1.9.3
- ビジネスサイドの不安→情報が少ない。利用事例。
- 開発事例を集めている。
RubyWorld Conferenceの開催
- ビジネスの事例発表の会
エンジニアの確保
- 技術者認定試験
TWO CARTOON FOXES: the _why documentary (Japanese Subtitled)
私が楽しみにしていたセッションの一つ。2009年アーティスティックなRubyプログラマ_why氏は突如としてRubyコミュニティを去った。
「_whyの感動的Rubyガイド」を紹介しつつ、Ruby界の有名人から_why氏へのコメントをまとめたドキュメンタリー作品。
私は_why氏の事は全然知らなかったんだけど、昔使っていたhpricotというHTMLパーサーの作者ということでちょっと親近感が湧いた。
奇妙な歌と猫のキャラクターは印象に残った。hpricotの初期のソースを読んでみようと思う。
ドキュメンタリーを観てから_why氏について色々調べてるんだけど「_whyの感動的Rubyガイド」の日本語訳はここで紹介されてるみたいです。
Refining refinements(前田 修吾氏)
Ruby2.0の目玉機能としてアナウンスされてたけど、直前で実験的な扱いとなってしまったrefinementsのお話。
Ruby2.0のRC版の時に試してみてすごく気に入ってたんでゼヒ2.1では正式採用されてほしい機能です。
今回のお話でいいなと思ったのは後方互換性維持のために必要な箇所だけ使用するという方法。
一方、同じメソッドでも呼んだ箇所によって動きが変わるので可読性が下がるという問題もあるそうです。
PostgreSQLでユニークインデックスを指定するときwhereを指定したい話の続き
以前書いたacts_as_paranoid + ユニークインデックスの話の続きです。
実はこの方法は問題があって、schema.rbにwhere付きのユニークインデックスを張ってることが記録されないんですね。
Railsでスキーマ情報を確認したい時って、普通schema.rbを見ますよね。できればここにwhere付きのadd_indexを書き出すべきだと思います。
ちなみにschema.rbがどのタイミングで作成されるかは次の通り。
- rake db:migrateを実行
- Databaseのスキーマ情報が更新される
- rake db:schema:dump が実行されてDatabaseのスキーマ情報からdb/schema.rbが作られる
ちゃんと調べるまで2と3は逆だと思ってました。
と、いうわけでこれからちゃんとしたgemを作ってみようと思います。
ActiveSupport::Cacheを簡易KVSとして使う
KVS的なものを使いたいんだけどmemcachedを立てるほどではないって事ありますよね?
そんなときはRailsのフラグメントキャッシュで使われてるActiveSupport::Cacheでファイルストレージを使ってみてはどうでしょうか?
require 'rubygems' require 'active_support' include ActiveSupport::Cache fs = ActiveSupport::Cache.lookup_store(:file_store, "tmp") # tmpディレクトリを格納先に指定 fs.write("key123","value123") #Stringを保存 fs.write("key456",{:hoge => "fuga"}) #Hashを保存 p fs.read("key123") # "value123" p fs.read("key456") # {:hoge=>"fuga"}
ちなみにtmpディレクトリ以下はこんな感じにサブディレクトリが作成されています。
$ tree tmp tmp ├── 1E0 │ └── 8F0 │ └── key123 └── 1E9 └── A10 └── key456 4 directories, 2 files
同一ディレクトリに大量のファイルを置くとアクセス速度が低下してしまうのですが、それを防止するためにサブディレクトリを作ってるのかな?
keyを探したりワークディレクトリをクリアしたり、詳しい情報はこちらのドキュメントを御覧ください。
http://api.rubyonrails.org/classes/ActiveSupport/Cache/Store.html