「PHPからRubyへ」(楽天技研の講演会)

masuidriveさんのお話。
資料はちゃんと公開してくれるそうです。
以下、さっくりまとめと感想

Rubyでちょっと書けるようになるので2,3日、
Railsをガッツリ使いこなすとなると3ヶ月くらいかかる。

これを押さえてないとRailsを十分に生かすことは出来ない。
RailsではActiveSupportというモジュールで、
Rubyのコアライブラリのクラス自体をガンガン書き換えてて、
ActiveSupportの有無で同一言語の別バージョンというくらい違う。

ブロックとイテレータの話は以前golfの模範解答的なものを見たときに思った、

処理を手続きじゃなくて、ブロックを渡すことによるタプルからタプルへの変換みたいに捉えた方が良いのかな？

↑ちゅーことなんだと思う。
後ろ二つについては、どっちかというとフレームワーク側の話だと思うけど、
ユーザが自分の足を打ち抜くようなこともできるから、
ユニットテストは必ずやらなくてはならない(じゃないと危ない)みたいな話もあった。

「設定より規約」でクラスさえ作れば勝手にDBから絡む情報を取得してORマッピングしてくれる。
ただし、DB設計がその規約から外れていると飛躍的に書かなきゃいけないコード量が増える。

話聞いてると、とりあえず、既存アプリをDBをリプレースせずにアプリ部分だけ書き直す
とかいった用途には向いてないような気がする。

1行書けばCRUD自動生成。
これ以外にもさまざまな用途のスケルトンジェネレータがあって、
生成されたコードは勉強にも役立つ。
なぜか？→ジェネレータは敷居が高いから書ける人はレベルが高い＝コードのレベルも高い

ActiveRecordは必要のないものもガッツリ取ってきてしまうので、
DBアクセスがボトルネックになる。

フラグメントキャッシュ(Viewの部品をそれぞれキャッシュする)を使えば、
100〜150アクセス/secくらいまでは捌けるとか何とか。

社内βまではRailsで作って、アプリの構造が固まったらJavaで書き直すというのもあり。

ふと思ったんだけど、Railsの各モジュールに相当する
かっちりしてる(けど生産性はあんまり高くない)Rubyのフレームワークがあれば、
アクセスが増えてきたらボトルネックになるところだけそれで作るとか出来ていいんでないかな。
全体としては性能も良くて、保守性も高いと。