┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.197 2007/08/08
■ I N D E X
┃
┣【Topics】PMシンポジウム2007開催のお知らせ（8/30〜8/31)
┣【コラム】思いやり駆動開発（ODD）後編
┣【プログラミング】Rubyで進むオブジェクトの道[23]
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 PMシンポジウム2007開催のお知らせ（8/30〜8/31)
〇 〇━━━━━━━━━━━━━ ━━・
国内最大のPM大会が今年も開催されます。
オブジェクト倶楽部事務局長の天野も、2日目にワークショップを行います。
お見逃し無く！
開催日時 ： 開催日時 ： 8月30日(木)、31日(金)
場 所 ： タワーホール船堀（東京/船堀）
【メインサイト】http://www.pmaj.or.jp/sympo/2007/main.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【コラム】思いやり駆動開発（ODD）後編
※先週発行した記事の後編です。
前回の記事は、こちらからどうぞ。
http://www.objectclub.jp/ml-arch/magazine/202.html
このように、相手への思いやりという「こころがけ」を基本に考えるだけで、
さまざまなソフトウェアの活動に応用がきく。
さて、ではどのようにこの「相手への思いやり」をはぐくむことができるだろ
う。「相手」を具体化することはとても重要に思える。たとえば、顧客、ユー
ザー、実際の開発メンバー、自分のコードを読むであろう人、使うであろう人
・・・そして、その相手とできるだけ会話をすることで相手を理解しよう。一
番いいのは、その相手と「食事をする」ことだ。これは、時代と分野を超えて
使える。人間の底辺の欲求を共に満たし、おいしい、という感情をともにする
ことだ。
思いやり駆動開発では、ソフトウェア開発を「ロジック中心」の思考から「感
情重視」の思考へと変革する。仕様書には書かれていない「行間感情」を伝え
るために、共感力と想像力を使って、相手を思いやろう。相手に興味を持とう、
相手を理解しようと努力しよう、相手に感謝しよう。ソフトウェア開発に、3K
(興味、共感、感謝)を導入したいのだ。
ソフトウェアは人が人のために作っている。この仕様書は誰に読んでもらう？
そのプログラムは誰を幸せにする？そこを忘れてしまった成果物は、悲しい。
詳しくは、igaiga さんのページを参照のこと！
http://igarashikuniaki.net/tdiary/20070620.html#p01
※余談だが、仕事を終えて帰ってきて、妻と遅い夕食を摂っているときの話。
疲れている私に、妻が長い話をはじめる。「今日、PTAでね、こんなことがあっ
てね・・・」、「それでね、○○さんがこういうのよ・・・」、「そしたら会
長さんがね・・・」、「それで私も困ってね・・・」という話が延々続く。仕
事脳のままの私は、「ご、ごめん、結論から言って。」とつい言ってしまう。
そして「そういう場合は、誰々と話をまずして、ああして、こうしたらどう？」
と解決策を提示してしまう。そして、結局妻の顔を逆に曇らせてしまうのだ。
そして、後で気づく。彼女が欲しかったのは解決ではなくて共感。「あぁ、そ
んなことがあったのか。本当に大変だったねぇ。」という共感の一言だったの
だ、とわかる。相手を思いやることは、ロジックよりも感情を大切にし、相手
の気持ちを分かろうと努力する「態度」なんだ。いい加減な態度で、ロジック
で解決しても、相手をしあわせにはしない。まず共感すること、思いやること。
そこからはじめ、次にロジックを使おう。（平鍋）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=H003-36&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=H003-36&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=H003-36&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】Rubyで進むオブジェクトの道[23]
■はじめに
前回はRSpec[*1]を軽く紹介しました。今回も引き続いてRSpecです。
before(:each)、 before(:all)を紹介します。
beforeメソッドは、Test::TestCaseである場合setupメソッド相当し、it実行
前の初期化処理を担当します。
引数:eachを渡した場合と:all渡した場合で、振る舞いが異なります。
サンプルのspecと実行結果から詳しく解説します。
■サンプルのspec
describe "node-aaaaからnode-zzzzの要素が追加されている配列" do
before(:all) do
puts "[DEBUG] called method 'before(:all)'"
end
before(:each) do
puts "[DEBUG] called method 'before(:each)'"
# 時間がかかる処理
@array = ('aaaa'..'zzzz').inject([]) { |nodes, str| nodes <<
"node-#{str}" }
end
it '検索結果件数 1×1×1×1 を返すこと、検索条件[e =~ /node-jjjj/] の時' do
@array.select{ |e| e =~ /node-jjjj/ }.size.should == 1 * 1 * 1 * 1
end
it '検索結果の件数 26×1×1×1 を返すこと、検索条件[e =~ /node-.jjj/]の時' do
@array.select{ |e| e =~ /node-.jjj/ }.size.should == 26 * 1 * 1 * 1
end
it '検索結果の件数 26×1×26×1 を返すこと、検索条件[e =~ /node-.j.j/]の時' do
@array.select{ |e| e =~ /node-.j.j/ }.size.should == 26 * 1 * 26 * 1
end
it '検索結果の件数 26×1×26×26 を返すこと、検索条件[e =~ /node-.j../]の時' do
@array.select{ |e| e =~ /node-.j../ }.size.should == 26 * 1 * 26 * 26
end
it '検索結果の件数 26×26×26×26 を返すこと、検索条件[e =~ /node-..../]の時' do
@array.select{ |e| e =~ /node-..../ }.size.should == 26 * 26 * 26 * 26
end
after(:each) do
puts "[DEBUG] called method 'after(:each)'"
end
after(:all) do
puts "[DEBUG] called method 'after(:all)'"
end
end
■ 実行結果
ienagaeiji$ spec rspec.rb
[DEBUG] called method 'before(:all)'
[DEBUG] called method 'before(:each)'
[DEBUG] called method 'after(:each)'
.[DEBUG] called method 'before(:each)'
[DEBUG] called method 'after(:each)'
.[DEBUG] called method 'before(:each)'
[DEBUG] called method 'after(:each)'
.[DEBUG] called method 'before(:each)'
[DEBUG] called method 'after(:each)'
.[DEBUG] called method 'before(:each)'
[DEBUG] called method 'after(:each)'
.[DEBUG] called method 'after(:all)'
Finished in 22.70541 seconds
■ 解説．
beforeに:eachを引数として渡すと、it毎にbeforeが呼ばれます。対して:all
を引数を渡すと、it毎ではなく、describe毎に呼ばれます。
JUnit4.0系であれば、@BeforeClassに相当する機能です。:allと:eachを二つを
混在させて呼ぶことも可能です。
xUnit Pattern[*2]のSuiteFixture Setup[*3]として紹介されているものをRSpec
のbeforeはサポートしています。
■ :allの使いどころは？
おもに、Slow Test[*4]の問題を回避する場合に利用することができます。
Fixture（specの事前準備）を共有し、１回のみにすれば、Specの実行時間の短
縮が期待できます。
before(:all) do
puts "[DEBUG] called method 'before(:all)'"
# 時間のかかる処理をbefore(:all)に移動
@array = ('aaaa'..'zzzz').inject([]) { |nodes, str| nodes <<
"node-#{str}" }
end
私のマシンの場合、before(:all)に初期化処理を移動することで、実行時間が
約16秒から約8秒と、半分にまで短縮することができました。
ただし、it毎に初期化しないため、it内でオブジェクトの状態を変更し、その
状態変化が他のit内のshouldの結果に影響がある場合は問題になってしまいま
す。
各々のitに依存が出来てしまうと、不安定なSpecのErratic Test[*4]の問題を
導いてしまいます。今回の例では、selectを使っていますので、オブジェクト
の状態は変わりません。この心配は不要です。
■ まとめ
RSpecのbefore(:all)、before(:each)を紹介しました。it実行後の処理は
after(:each)、after(:all)になります。
:allや:afterの引数が渡されなかった場合は、デフォルト:eachが実行されま
す。
次回は、Slow Testの回避策の代表格であるモックをRSpecでどのように書くか
を学習してみたいと思います。（IENAGA）
■ 参考
[1] : RSpec
http://rspec.rubyforge.org/
[2] : xUnit Pattern
http://xunitpatterns.com/index.html
[3] : SuiteFixture Setup
http://xunitpatterns.com/SuiteFixture%20Setup.html
[4] : Slow Test : Test Snells[6]の一種
http://xunitpatterns.com/Slow%20Tests.html
[5] : Erractic Test : Test Snellsの一種
Erraticの単語の意味は、「気まぐれな」「一貫性のない」「不安定な」
など
http://xunitpatterns.com/Erratic%20Test.html#Interacting%20Tests
[6] : Test Snells
http://xunitpatterns.com/test%20smell.html
http://xunitpatterns.com/Test%20Smells.html
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-22&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-22&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-22&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「好きなエディタは？」のホントのところ。いろいろ種類がある中で、
読者の皆さんはどの種類のエディタを愛用していますか？好きなものを1つだけ
教えてください。
Emacs系エディタ。
http://www.ObjectClub.jp/special/kininaru/vote?vol=163&choice=0
vi系エディタ。
http://www.ObjectClub.jp/special/kininaru/vote?vol=163&choice=1
秀丸。
http://www.ObjectClub.jp/special/kininaru/vote?vol=163&choice=2
さくらエディタ。
http://www.ObjectClub.jp/special/kininaru/vote?vol=163&choice=3
メモ帳。
http://www.ObjectClub.jp/special/kininaru/vote?vol=163&choice=4
自作エディタ。
http://www.ObjectClub.jp/special/kininaru/vote?vol=163&choice=5
その他(フリー、オープンソース)。
http://www.ObjectClub.jp/special/kininaru/vote?vol=163&choice=6
その他(有償、シェアウェア)。
http://www.ObjectClub.jp/special/kininaru/vote?vol=163&choice=7
それ以外。
http://www.ObjectClub.jp/special/kininaru/vote?vol=163&choice=8
それは秘密です。
http://www.ObjectClub.jp/special/kininaru/vote?vol=163&choice=9
ちょっと語らせて！
詳細をこのメールに返信ください！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「開発するとき、1つだけ自由になるとしたら？」の結果は公開中。
ぜひご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru/vol162/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。2年ほど前に買った携帯電話を使い続けているのです
が、先日「まだ、そんな弁当箱みたいな携帯使ってるの！？」とお客さんにいわれ
て初めて「そーなんだ。もう古いんだ。」と思いました。自分ではなんとも思って
いなかったのにね。ただ、まだ新しい携帯電話は機能などが多くなりすぎて選べ
ません。同じように、未だにデジカメも選べません。トホホ。
今週の強引な一言
*** 所変われば品変わる(ことわざ)***
土地が違うと、風俗習慣も違うこと。(出典:故事ことわざ辞典 東京堂出版)
クライアントやプロジェクトが変わっても、強引にやり方を通そうとせず、結
局今までどおりのやり方となっても、新しいルールを話し合うのが良いという
やりかたを知りました。軸を持ちつつ、柔軟でありたいものです。
(上田雅美)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2007 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.