騒がしい未来

無駄に元気な毎日を送っている、チームラボ所属 高須正和のブログです。最近はtwitterメインで更新中

第8回 Ruby勉強会
 1/24  20:00-

チームラボのRuby勉強会も、第8回となりました。

今回はテストのコードレビューです!

■テストはRuby on railsの特徴
 テストの便利さはRuby on railsの大きな特徴で、テストの準備が最初から用意されています。
アプリケーションの雛形と同時に、テストの雛形も自動生成されます。

今回は、先週のプログラムを元に、テストのコードをレビューします!

あるシステムにユーザーを登録する・削除するという部分のテストで、モデルのテストを行います。
DBの構造を変化させた時などに、正しくない変化が及ぼされる範囲を、簡単に判断することができます。

 Railのいいところは、最初から
・開発環境(ローカルPC)
・テスト環境(ローカルPC)
・本番環境(本番)
の3つを使うように想定されています。テストをするとDBが荒れるので、専用の
DBを用意させるのです。これで繰り返しのテストも気軽に行えます。

実際にコードを書いたエンジニアから、
 「本体のコードよりテストコードの方が2-3倍も多く必要になる。これはだいぶつらい。またどこまで細かくテストを書くべきか、判断が

付かない。このノウハウは、本体プログラミングとまったく別の習熟が必要になる。」

Rubyに慣れたエンジニアからは、
 「どんな開発環境でもテストは大事だが、Railsはテストとセットで提供されているフレームワーク。だからプログラムのコードを書く時

点で、テストがしやすいようにコードを書くことを心がけたほうがいい。
 バグが発生したときにも、すぐに直してしまわず、まずバグを再現できるようなテストコードを書くこと。
またテストのしやすさのためには、メソッドを細かくすること。
 理想は1メソッド1行(笑)」
(これはタダのジョーク。1メソッドが1行では、コードをまとめて関数化する意味がない。現実的には10行、上限は20行というところか。

「メソッドを細かくするメリットは?」

 →メソッドを細かくすることでテストが容易になり、それぞれのメソッドの影響範囲が明確になる。パフォーマンスはある程度犠牲にな

るが、Rubyではさほどパフォーマンスが要求されないことが多いし、テストドリブン開発の基本でもある。

などの解説が出ました。

■Modelテスト開始!
 テスト用のコードをすでに書いてあるプログラムを使って、Ecripse上でUnittestを実行します。

テストは、コードの上から順番ではなく、テスト用メソッド名のアルファベット順に実行されます。

 テストランナーが、テスト用にデータの初期化など、準備をやってくれます。
 Railsでは、rake というツールを使って、テストコード全体を実行することができます。

 テスト用のDBが、デモ用の環境ではできてないなど、いくつか問題がありましたが、修正して無事テスト終了。

■Contollerテスト開始!
 ある程度はControllerのテストコードが生成されています。
また、テストに便利なライブラリが豊富に用意されています。コントローラをgetで呼ぶ、postで呼ぶ、その結果のHTTPステータスの判定、

リダイレクト先の判定、コントローラのインスタンス変数の値の取得、etc…
 これがRuby on Railsの大きな特徴で、JavaとRuby両方書く開発者からは、
「ここはもうホントに便利!」「ヤバい!」という声が飛びます。

「便利かもしれないが、いくつか独自な部分があるので、ここから入門した人はちょっと影響はあるかも..」

get,postを使って、パラメータがどうなっているかチェックするテストをしてします。

「今回のテストコード生成にかかったのはだいたい1日ぐらい」

 という声に、速い!という声が飛びました。

 実行して初回のエラーは1件。

追加の紹介:
インテグレーションテスト
 「ひとつのControllerであれば今のテストでいいんだけど、Railsにはインテグレーションテストというものがあって、複数のController

を使うシナリオテストみたいなものも書くことができる」

mocks
 「たとえば本番環境でしか用意できないデータ(たとえば、本番環境でないとインターネットに接続できないとか)をこのディレクトリ

においておくと、テスト時に自動で読んでくれる」

■コードレビュー1段目!
次は、勉強会でコードを書いた新人のレビューです。

例題として、サイコロプログラムを構築されました。
 サイコロプログラムは、コードが実行されると

・1秒待って
・1-6の数字のどこかを選択し、
・数字に対応する文章を順番にif elsif elseで
 呼び出す(3=「サンざんなお話!」とか)

 というプログラムです。
これを先輩社員がリファクタリングしていきます。

 「この場合はcase文を使うと、numを繰り返さずにすむので簡潔になります。」

 「イチから書き直すなら、文章と数字をハッシュに入れて、ランダムの数字をdata.lengthで6以外も対応できるようにします。」

会場から「ここはハッシュよりリストの方が」というツッコミが入り、コードはさらに洗練されていきました。

■コードレビュー2段!
 実際に業務で使ったちょっとしたプログラムで、
 「任意でエラーコードを出してくれるhttpサーバー」
 を作りました。

 httpのURLが、/数字 だったら、数字をHTTPのステータスコードとして返します。
http://localhost/300だったら300番とか。

たった50行程度でテスト用ウェブサーバが作れること、それが単なるWindowsマシンで動くことに、会場からはどよめきの声が上がりました

■コードレビュー3段!
 wordのテキスト(docファイル)内をマルチファイル検索するスクリプト
 (日本語も正規表現も使える)

Windows の OLE経由で、MS-Wordを不可視で起動して呼び出すことで、Wordで書かれたファイルを検索する。

■コードレビュー4段!

BMI計算スクリプトのページ。
IEの中で、RubyがJavaScriptのように動く!

HTML(HTA)ページをGUIとして使えるので、バッチではない対話的プログラムを作るのに便利。

Windows環境で、ActiveScriptRubyをインストールした場合だけ動作する。

 デバッグについては今回できなかったので、勉強会はもう1回追加で行われることになりました!

正月休みに読了。

ウィキノミクス マスコラボレーションによる開発・生産の世紀へ
ドン・タプスコット/アンソニー・D・ウィリアムズ 井口 耕二
日経BP社 (2007/06/07)
売り上げランキング: 6399

ひさびさのヘビー級本。難しいわけでも読みにくいわけでもないが、なにしろ内容が多岐にわたる500ページ近くの本。どっちかというと一度読んで全体を把握し、その後レファレンス的に何回か読み直すような使い方の本ではないだろうか。

2007年のネット界を考える中で外せない本であることはすでにさまざまなブログで取り上げられているが、どこが本書を「外せない本」と評される要因となったのか。

この2つの要因だと思う。

  • すでにバズワードになりつつあるweb2.0のうち、「集合知」を実際にやった事例が集まっている。
    それも、”単にwebのコンテンツを増やす”,”サイトのトラフィックをあげる”なんていう事例でなく、飛行機の開発や鉱山の金鉱発見のようなリアルビジネスでの実例が掲載されている。
  • 広く深い取材/インタビュー

 

 本書は章ごとに、トピックとそれが実現された実例、という形で書かれている。

 第1章 ウィキノミクス 
   全章のまとめとして、集合知の利用としてのウィキノミクスという考え方の紹介、ウィキノミクスを構成する要素としての四本柱「オープン性」、「ピアリング」、「共有」、「グローバルな行動」の4つ
  実例
   ゴールドコープ社の金鉱発見

 第2章 嵐の中の嵐
   技術の進化、価値観の進化により、価値は共同で作られていくようになった。集合知としてのウェブサイトと、新世代の考え方
  実例
   さまざまなweb2.0系サイト

 第3章 ピア開拓者
   ピアプロダクション(個人の自発的な集まりによる共同開発)とはどういうもので、どういう考え方・人によって構成されていくか
  実例
  IBMのオープンソースへの取り組み

 第4章 アイデアゴラ
   従来社内で研究していた、研究開発のアイデアを、アイデアそのものに価格をつける形で、オープンに市場から調達する試み
  実例
    P&Gの新薬開発、イェットツー・コムといったアイデア市場

 第5章 プロシューマー
   自社製品の仕様をオープンして、顧客による改変を認めて確信していく試み。また、そのためのライセンス形態としてクリエイティブ・コモンズなど。
   実例
    リンデンラボ(セカンドライフ)、レゴ

 第6章 新アレクサンドリア人
   知識・研究成果の共有により研究の生産性を劇的にアップさせる動き。
   実例
   ゲノム解析プロジェクト、インテルのオープン・ユニバーシティ・ネットワーク

 第7章 参加のプラットフォーム
   マッシュアップなどにより、簡単にサービスのスタートアップができるようになり、多くの実用的なサービスが登場している動き
  実例
  ピープルファインダー(ハリケーン被害者のネットワーク)等のマッシュアップサイト、アマゾン等の仕様公開サービス

 第8章 世界工場
   仕様を詳細に決めて発注していたこれまでの開発に対し、開発元は大まかな目標策定とマネージに徹し、各社のコラボで製品開発を行う動き
  実例
  ボーイング社の787開発の試み、中国・力帆の自動車開発

 第9章 ウィキワークプレイス
   「ウィキノミクス」的な働き方を支えるための社内風土、ツール
  実例
   ギーク・スクワッド(PCサポートサービス)の運営方法

 第10章 コラボレーションの精神
   「ウィキノミクス」的なプロジェクトを行う際のまとめ、予想されるトラブルなど

 それぞれの事例の中で、いくつかすでに古くなってしまったもの、例としては怪しいものもある。読んだ人どおしで話し合っていても、「第8章 世界工場」で挙げられているボーイング・力帆とも、成功例としては微妙(出版後、どちらも商売が怪しい)という指摘が出た。

 それでも、個人が検索していては到底たどり着けない、「さまざまな国・商売での”web2.0っぽいもの”を収集し解説したもの」として、この本の価値は大きい。webサイトだけでは見れない、サイトの裏側のお金の回り方まで書いてあるし、そもそもwebとはほとんど関係のないものが多く含まれている。「オープン性」、「ピアリング」、「共有」、「グローバルな行動」という4つの概念についても、自分自身の実例で類推できる程度には、しっかり説明されている。

梅田本に近いような2.0マンセー臭はあり、できれば「ウィキノミクス失敗の事例」的なものが今後整理されてこないと、内容を丸呑みするのは危険ではあるが、それでも「どうやれば共有できる・できそうだ」「ピアリングできる・できそうだ」といったものはつかめる。

既存のサービス・ビジネスに対して、「ウィキノミクスの要素を取り入れて効果を上げることはできないか」を考えるケーススタディとして、何かビジネスのネタを考える際にはたびたび読み返すことになる本だと思う。

これ、面白いですね。

コード面接 – jkondoの日記

先週、今週と続けて技術者採用面接が続いている。最近はこうした面接の際に、「コード面接」とでも言うべきものを始めている。今までも、社員と一緒に人生ゲームとかをやってもらうゲーム面接をやっていたんだけど、今年からはこれの代わりにより実際の業務に近いことを社員の前で実演してもらうようになった。

エンジニアの場合にはやはりコードを書いてもらうのが一番、という事で、いくつか用意したお題の中から好きなものを選んでもらって、30分から1時間くらいでコードを書いて動かしてもらう。大型の液晶テレビパソコンディスプレイを映してもらって、それを他の社員が見守る中コードを書いてもらっている。

おんなじことをマーケ・企画でやったらどんな風になるだろう。提案書作成面接とプレゼン面接かな?

携帯アクセス解析