Date:  Wed, 08 Aug 2007 17:44:17 +0900
Subject:  【オブジェクト倶楽部: 2007-28号】
X-Mail-Count: 00203

       ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
       ┃                         ■┃
      ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部   ■ ┃
       ┃                       ■  ┃
       ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
                          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の事前準備)を共有し、1回のみにすれば、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.