RubyKaigi 2008 LTメモ

「JavaからRubyへ」について、どうしても言いたいことがある

  1. JavaからRubyへコードを変えることではない。
  2. 考え方をJavaからRubyへ変えるのだ。
  3. コードだけでなくプロジェクトの考え方も変える必要がある。
  4. RubyはメタPなど上級者の力を引き出す力を持っている。
  5. 一方Javaは初級者用言語?
  6. 人数の多い初心者を重視するあまり、玄人の足かせになっている。

dRubyとセキュリティ

  1. dRubyをネットを通して複数ユーザーに公開するのは危険という話。
  2. dRubyよくわかんねorz
  3. デモなにやってるかわかんねwとりあえず早い。カッコイイ。

RubyとODEでピタゴラ装置

  1. ODE=Open Dynamic Engine 3Dを操作できるライブラリ
  2. Wiiリモコンで操作
  3. RubyCoCoa + OpenGL + ODEでピタゴラ装置
  4. すげーぐりぐり動く面白い。チャットがすごいことに。

初級者は Enumerator の夢を見るか?

  1. みねーよ ←結論
  2. ん、なんかすごい。なにやってるかわかんね。
  3. 初級者はeach大好き。なんでもeach。僕もでーす^^
  4. Enumraterの世界へいざないます。
  5. 3つづち処理をするとき、each_slice(3)を使う
  6. i, i + 1の配列を作るとき、each_cons(2)

Rubyで楽しむフォークプログラミング (Webアプリじゃないよ蝙)

  1. Folk Programmingとはフォークソングのように気軽に始めるプログラミング
  2. もっと気軽にプログラミングしようよ！
  3. それもWebアプリ以外でやろうよ！
  4. オススメはプラグイン作り。いきなり作るよりかなーり楽
    1. Safari + Hatena
    2. QuickSilver + Twitterやりてー
  5. なんでRubyなのか？
    1. ソフトとソフトをつなぐグリースになる。
    2. 自身をリロードすることでデバッグも楽

Ruby.pm - CライブラリとしてのRuby

  1. RubyはCでオブジェクト指向するための言語？
  2. PerlでRubyのCライブラリを使いたい人のためのモジュール
  3. なんだと思う…

Ruby 1.9 on Rails 2.1による新時代DBプログラミング

  1. DBの進化の歴史
    1. 古代言語 PHP、コードは省略w
    2. 中期、O/Rまっパー時代
    3. XMLカオスw
    4. そしてAR
  2. 実はDBアクセスはRailsの弱点
    1. RDBMS操作 != SQLの組み立て
    2. RDBMS操作とは集合演算
  3. そして今年Rails2.1でnamed_scope
    1. Book.written_by('Fawler').leastみたなこと書ける
  4. まとめ
    1. あー時間だ。

テストベースコードリーディングのすすめ

  1. どうやって飽きずにソースコードを読むかという話
    1. テストをかけてテストされていない行を読み、その行へのテストを書く
    2. テストが不足していないとこの方法はできないw
  2. PHPはテストがばれっじが低めなのでオススメ

A Jail Web Development with Rails 2008 でわっふるわっふる

  1. あじゃいる　じゃなくて、じゃいる。剛健なアプリの作り方
  2. エスケープしても防げないXSSがある。
    1. FireFoxでは大丈夫でもIEでマルチバイト文字による攻撃がある。
    2. 対策としては、入力されたマルチバイト文字列が正しいエンコーディングか確認する。
    3. 面倒くさいので、mod_waffulというApacheモジュールを作ってくれたらしい。

Industrial-Designed Language: Ruby

  1. 工業デザインについての話。
  2. 昨年グッドデザイン賞をFirefoxが取得
  3. Rubyも優れた工業製品
  4. アフォーダンス = 説明しなくても分かるインターフェースみたいなもの
  5. Rubyは名前をつけるのが重要。
  6. Rubyで正しい名前をつけることはアフォーダンスになる。
  7. 名前をつけるのはとっても重要。name is power → name is アフォーダンス
  8. UStream見てる人も使いましょうw
  9. Matzの屍を超えて自分の言語を作りましょう！でシメw

RubyKaigi 2008 教育セッションのメモ

Ruby<を>教えるんじゃない、Ruby<で>教えてるんだってば by 東大-増原さん

  1. 400人くらいにコンピュータサイエンスの基礎を教えている
  2. Rubyじゃなくてもいいけど、動くものを作ってアルゴリズムや計算量を教えている
  3. 400人全員がRubyistになるわけじゃないw
なんでRubyを使ったか？
  1. アメリカで6年の間に大学でコンピュータサイエンスを学ぶ人が1/6に。日本でも同じ傾向が。
  2. ハッカーでない人にプログラムの面白さを伝えるように変えよう。
  3. 前はJavaで教えていたがpublic static void mainはねーよw
教育言語選択の基準
  1. 家でもできる。
  2. 日本語ドキュメントが豊富。
  3. オブジェクト指向言語
  4. JS, Python, なでしこ, Rubyなどが候補に。
教え方
  1. Rubyのライブラリにあるメソッドは使わない。自分で作る。元からあるメソッドの説明が大変
  2. とりあえずクラスを使わずに教えた。最初は制御構文から教えて最後の最後でクラス
Rubyのいいところ
  1. 階乗の計算をするときにCやJavaのようなオーバーフローがない
  2. プロット処理にライブラリを使うことで、手数以上の見た目
  3. Rubyの遅さは問題にならなかった。
つまったところ
  1. 学生がインデントをしてくれない。
  2. 先生エラーがあります。なんのエラー？　変なエラーです。…
  3. 学生がエラーメッセージ読んでくれない。
  4. 日本語が出ねー。
  5. "が全角w
  6. 全角空白が入ってるw
まとめ

なんの言語を使おうと最初は文法とかでつまずくんだよね。

成功するRuby教育のプラクティス by 吉田さん

いかに初心者にRubyを教えるのかという課題へ朝挑戦してのプラクティス。

社内にRuby開発者を増やすには？
  1. 社内でできる人が教える
  2. EY-Officeを呼ぶw
  3. 他社の教育サービス利用
  4. 勉強会とかに参加
1番がいいんじゃない？という話
  1. 会社や部署によってやりたいこと、教えるべきことが変わってくる。自分たちの特徴をいかせる
  2. 社内に教える文化ができる。
教える側のメリット
  1. 講師が一番勉強になる
  2. 将来、講師業という選択枝が増える
プラクティス
  1. 実習はペアプロでやる
    1. 二人で議論するから考え込まない
    2. スキルの差を吸収
  2. テスト駆動開発
    1. Hello Worldを書いても実業務では使えない。
    2. テストケースを経験者が書いて、中身を初心者が実装するといい
    3. ゲーム感覚で勉強できて楽しい。（オールグリーンにするゲーム）
  3. 他の言語の秀逸な本を教育に利用する
    1. 紹介していたのは、「なぜ、あなたはJavaでオブジェクト指向開発ができないのか―Javaの壁を克服する実践トレーニング」という本。吉田さんはこの本の問題をRubyに書き換えて使ってた。
まとめ

コミュニティーでも教育活動を行うことで、いろんな人に教える経験になる。
コミュニティーも全員が玄人ということは少ないので、教育者を求めている。実際喜ばれた。いい経験になる。

RSpecによるRailsアプリケーションBDD事例報告 by Yuguiさん

ASPの既存サービス改修からRailsに置き換えてSpecを使ってプロジェクトを立て直した記録。

まずやったこと
  1. バージョン管理する
  2. BTS導入
  3. Buildデプロイ自動化
  4. テスト自動化

バージョン管理してなかったのかw

結局上の方針は没に
  1. 事業方針的にスピードが足りない
  2. それでもまだ出るバグ
  3. 既存のバグで機能追加に手が回らない
ここで新たな要件が入る
  1. 既存システムを1ヶ月でリプレイス＋機能追加

→既存システムがバグバグで救いようがないからいっそ置き換えてしまえ！

FWの候補
  1. Seasar2
  2. Seasar2.net
  3. Rails
Railsへの決定要因
  1. オープンソースであること。いざとなればソース見れる
  2. Rspecがあったこと。
開発フェイズに様子
  1. 自動テスト(Selenium)の資産が生きた。おおまかな仕様を把握できる。
  2. 単体テストを確実に書く
  3. コードの７割がテストコードになってた。
やってみた結果
  1. 慣れてる人がSpecを書きながら作る
  2. 慣れてない人がSpecを真似ながらかける
  3. Specがあることで剛健なアプリを作れた。
まとめ

実際にやっていた人からSpecがあると安心できるねという感想。

質問が面白いw

Q.上から無駄なテスト書いてないで、機能追加してくれと言われませんか？
A.基本的に、お前は何も分かってないんだから黙ってろ。
会場からわぁーーーー拍手拍手


Q.RSpecはなにに対してどんなことを書いていたか？
A.Modelは全ての公開メソッドに対して。Controllerはパラメータの受け取りとMockの呼び出しなど。Viewのテストはやっぱり苦労するみたい。


※RSpecによるRailsアプリケーションBDD事例報告 by 松田さんになってました。正しくはYuguiさんです。お詫びして訂正します。