Ruby勉強会@札幌-19 に参加してきました!

メニューは先日行われた「RubyKaigiのトークを見て語る」でした!!
(同時に予定されていた「初めてのRuby」の読み合わせは時間がなくなったため、今回は中止でした。)

午前中は自由時間とランチ懇親会があったようですが、体調が悪くて参加できませんでした。。。
(できればランチ懇親会参加したかったなー)

RubyKaigiをUStreamで観ていて、実際に行って来た方々のおみやげ話を聞きたいと思っていたので、少しではありますが実際に参加してきた方々のそういった話や感銘を受けたポイントなんかを聞けたのは大変ありがたかったです。

ですが、せっかくの機会だったのでもっと積極的にポイント絞って話を聞いてみたり、こちらからのフィードバックができればよかったなー、というは反省ポイントです。事前の用意が大切!

Issues of Enterprise Rubyist ~SIerのなかのRubyistが考えるべきこと~

  • Rubyを楽しみたくて分科会を開催したり、仕事のツールとして取り入れたりしたけど、ビジネスという視点から見ると価値を創造できてないのが課題でした。
  • エンタープライズって適材適所での提案が大事なんじゃない?あくまでその選択肢の一つとしてRubyを視野に入れられるようにするのが大切だよね。
って話。
ビデオを見た後のトークの中で沼田さんが言っていた次の旨の発言が印象的でした。
"いつかその選択肢を選び取るために既存のテクノロジーと比較してのメリット、デメリットをリストアップして見える化し、準備しておくことが大事だと思うよ。"

O/R Mapperを支える技術

SQLの課題ってこういうの、でもモダンO/Rマッパーはその課題の解決に向かっているよ、っていう話。
  • 分割、組み合わせ、抽象化ができない。

実はO/Rマッパー辺りは現在の主流がどうとかわかってないので、見た後のトーク含めて結構興味深い話でした。O/Rマッパーも進歩しているんだなぁ、というのが素直な感想でした。

この辺りの話では、SQLのチューニングが・・・という話は切っても切れないところで、やはりその辺りの議論が盛り上がっていました。
個人的には「SQLはDBのアセンブラ」「本当はアセンブラじゃなくて、機械語へのマッピングが必要」といった話の辺りが目から鱗でした!
ふむふむ、そういう風に考えたことはなかったわー!

プログラミング言語とDBの間にはインピーダンスミスマッチがあるとはよく言われますが、O/Rマッパーも進化中と考えると、今後どこかでブレイクスルーがあったりするのかなー、というのを夢想してみたくなりますね。

Rubyマスターへの道

プログラミング言語を学び、より使いこなしていくには・・・って話。
個人レベルの取り組みは話しやすいし、聞く方も大変よくわかるのですよねー(提起された内容が、自分自身実施できているかどうかはともかく。。。)

eachよりmapを使うほうがよりRubyっぽいよ、っていうのは「ふんふん、そうなのかー!」でした。
・・・関数型にちょっと近い感じ・・・?(最近ちょっとかじっている。。。)


コメント

このブログの人気の投稿

PostgreSQLで多次元配列を1次元配列に展開したい

inotify でファイル監視しようず!

ジャックパーセルのかかとの内側を直した