Date:  Wed, 29 Nov 2006 17:23:40 +0900
Subject:  【オブジェクト倶楽部: 2006-45号】
X-Mail-Count: 00172

       ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
       ┃                         ■┃
      ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部   ■ ┃
       ┃                       ■  ┃
       ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
                          No.166 2006/11/29

■ I N D E X
┃
┣【Topics】オブジェクト倶楽部クリスマスイベントの申し込み受付開始!
┣【Topics】オブジェクト倶楽部 秋イベントの資料を公開しました
┣【Topics】S-openホットセッションで、講演してきます(11/30)
┣【プログラミング】Cayenneで始めるO/Rプログラミング[6]
┣【PF】たまには仕事に役立つコミュニケーションのヒント[5]
┗【アンケート】気になるシステム業界 ホントのところ

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
 〇 オブジェクト倶楽部クリスマスイベントの申し込み受付開始!
  〇 〇━━━━━━━━━━━━━ ━━・ 
毎年恒例となりましたオブラブ名物「クリスマスイベント」の申し込みが、い
よいよスタートしました。
下記イベントページから、参加登録のページにお進みください。
http://www.ObjectClub.jp/event/2006christmas/

盛りだくさんの講演・セッション内容はこちらです!
http://www.ObjectClub.jp/event/2006christmas/session.html

【イベント概要】 
日  時:2006年12月20日(水) 10:00〜17:00 (懇親会17:30〜19:30)
場  所:国立\\オリンピック記念青少年総合センター http://nyc.niye.go.jp/
内  容:講演、ワークショップ
参加費:講演会3000円、懇親会4000円(いずれも事前振込み)

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
 〇 オブジェクト倶楽部 秋イベントの資料を公開しました
  〇 〇━━━━━━━━━━━━━ ━━・ 
オブジェクト倶楽部秋イベントが、11月17日(金)に開催され、大盛況のうちに
終了いたしました。トーカーの皆さま、ならびに参加者の皆さま。多数のご参
加、誠にありがとうございました。サイトにて、イベントの資料の公開を始め
ましたので、ご案内いたします。
◆秋イベント公開ページ
 http://www.ObjectClub.jp/event/event2006autumn/

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
 〇 S-openホットセッションで、講演してきます
  〇 〇━━━━━━━━━━━━━ ━━・ 
オブジェクト倶楽部事務局の上田雅美が、S-openホットセッションにて講演し
てきます。会場でお目にかかった方は、是非声をかけてください!
開催日:11月30日(木)
テーマ:リーダーは万能にあらず 
       〜コーチングコミュニケーションで作る自律型チーム〜
お申込み・お問合せ ⇒ http://www.s-open.net/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【プログラミング】Cayenneで始めるO/Rプログラミング[6]

ナンバーポータビリティが始まって、およそ一ヶ月。おもったよりもキャリア
変更している人は身近にはいません。みなさんの周りはどうですか?
もちろん料金も一つの判断材料になると思うのですが、やっぱり普段身に着け
ているものですから、デザインも重要ですよね。海外の噂サイトでは、アップ
ルの携帯電話iPhoneの話題がいつも話題になっています。最近ではiPhoneは
iChatを搭載するようだ、とか200万画素のカメラが搭載されるようだ、とか様々
です。もしアップルの携帯電話が出たら、キャリア変更する!という人は結構
いるのでは?と思っています。
ちなみにiPhoneが出てもiPodと差別化するために、ミュージックプレイヤー機
能は付かない、と噂サイトは見ているようです。。ちょっと長くなりましたが、
本題へ。

前回は、モデルの関連先がどのようにマッピングされるか、という関連技術の
一端を見てみました。今回、はオブジェクトモデルを永続化することを考えま
す。
具体的なシナリオがあった方が、わかりやすいと思いますので、「入会して借
りる」というケースを実現してみることにしましょう。
このケースは「入会する」と「借りる」を、同時に実現するモデルと思ってく
ださい。
この二つのユースケースは、これまでに登場しました[*1]。二つのユースケー
スを続けて実行すれば、それで終わり、という考え方もできます。もちろん入
会と借りるの間には、厳密な依存関係がある訳ではないので、借りるが失敗し
ても、入会だけは先に成功していても問題ないような気がします。でも、その
ままだと、今回の話は先に進めないので、この二つのケースが一つのトランザ
クションで実行される、つまり借りるが失敗した場合、入会も取り消す、とい
うシナリオであるという前提で考えます。
前述したとおり、すでに二つのシナリオの実装は存在していますので、
MemberRegisterクラスをリファクタリングして、VideoLenderクラスからmain処
理で記述されている内容を呼べるようにしましょう。

public class MemberRegister {
      DataContext context;
      BufferedReader reader;  // readerの宣言をmain()から出します
      Member member;  // memberの宣言をmain()から出します

・・・・省略

      private void init() {
          context = DataContext.createDataContext();
          reader = new BufferedReader(new InputStreamReader(System.in));  // readerの初期化を移動します
      }

      private void main() throws IOException, ParseException {
          member = (Member)context.createAndRegisterNewObject(Member.class);
          System.out.print("会員ID:");
          member.setObjectId(new ObjectId("Member", Member.ID_PK_COLUMN, reader.readLine()));
          System.out.print("会員名:");
          member.setName(reader.readLine());
          System.out.print("誕生日(yyyy/MM/dd):");
          member.setBirthday(new SimpleDateFormat("yyyy/MM/dd").parse(reader.readLine()));
          return member;
      }

      private void end() throws IOException {
          context.commitChanges();
          reader.close();  // readerの後処理を移動します
      }
      // 外部から呼び出せるインターフェースを作成します
      public void main(BufferedReader reader, DataContext context) throws IOException, ParseException {
          this.reader = reader;
          this.context = context;
          main();
      }
      // 作成したMemberを戻せるようにします。
      public Member getMember() {
          return member;
      }
}

ここで注目すべきは新しく作成したmain(BufferedReader reader, DataContext context)
関数です。readerとcontextを受け取って、main()でmemberの登録を実行します。
続けて、VideoLenderクラスを修正します。このシナリオでは、入力された会員
IDがデータベースに存在しない場合、新規登録を動かすことにしてみましょう。

・・・省略
System.out.print("会員ID:");
Member member = Member.findByPrimaryKey(context, reader.readLine());
if(member == null) {
      MemberRegister register = new MemberRegister();
      register.main(reader, context);
      member = register.getMember();
      member = (Member)context.localObject(member.getObjectId(), member);
}
System.out.print("貸出日数:");
・・・省略

先程追加したMemberRegisterのmainを、呼び出します。登録した会員オブジェ
クトを取得して、後は貸出オブジェクトにセットすれば良いのですが、ここで
多少工夫が必要になります。
context.localObjectはデータコンテキスト内で、指定したオブジェクトIDとオ
ブジェクトの参照関係を一時的に登録とみなします。
何故このようにローカルオブジェクトを登録するか、というと、今回のビデオ
レンタルシステムでは、ビデオIDや会員IDを自動連番でなく、手動で与えてい
ます。もしシステムの主キーが自動連番となっていたなら、これらの工夫は必
要ありません。なぜなら実際にデータベースに登録するまで、主キーの項目は
設定されていないからです。Cayenneはデータベースへコミット時に、会員と貸
出の両方に会員IDをセットして関連を自動的に保持してくれます。
ただし、今回のように手動でキーをセットする場合は工夫が必要なのです。貸
出クラスへ会員の関連を追加する場合、lending.setToMember(member);を使い
ます。memberは新規オブジェクトです。つまり、まだ永続化されていないオブ
ジェクトです。
しかしCayenneは、コミット時に貸出の関連先である会員のオブジェクトの状態
を取得して、データベースへ更新の必要があるかを判断しようとします。この
とき自動連番なら、貸出→会員の関連で取得した主キーが設定されていないの
で、主キーの値を持つレコードを参照しません。しかし手動で設定した場合は、
コミット前の設定されているキー項目の値は、関連先のレコードを探してしま
います。すると、レコードが見つからないので、エラーになってしまいます[*2]。
そこで、データコンテキストに、コミット前のローカルオブジェクトへの参照
を登録します。このようにすることで、貸出から主キーで会員への参照が可能
となり、上記のエラーを回避することができます。
では実際にVideoLenderクラスを実行してみましょう。


・・・省略

ビデオID:100
・・・省略
会員ID:7777
・・・省略
会員ID:7777
会員名:てすと
誕生日(yyyy/MM/dd):1980/10/10
貸出日数:3
INFO  QueryLogger: --- will run 2 queries.
INFO  QueryLogger: --- transaction started.
INFO  QueryLogger: INSERT INTO member (birthday, id, name) VALUES (?, ?, ?)
INFO  QueryLogger: [bind: '1980-10-10 00:00:00.0', '7777', 'てすと']
INFO  QueryLogger: === updated 1 row.
INFO  QueryLogger: INSERT INTO lending (memberId, rentDay, returnDay, videoId) VALUES (?, ?, ?, ?)
INFO  QueryLogger: [bind: '7777', '2006-11-22 16:14:54.437', '2006-11-25 16:14:53.218', '100']
INFO  QueryLogger: === updated 1 row.
INFO  QueryLogger: +++ transaction committed.

どうですか?一つのトランザクション内で、二つのINSERT文が実行されると思
います。このようにO/Rマッピングを利用すると、オブジェクトの関連をセット
するだけで、自動的にオブジェクトの状態を検査し、適したSQL文を生成してく
れるのです。このシナリオでは、全て新規作成だけだったので、インパクトが
薄いかもしれません。これが伝票と明細のような関係で、追加・変更・削除が
複雑に入り乱れていたらどうでしょうか?もしO/Rマッピングの機能を利用せず
に、自らオブジェクトの状態を管理し、SQLを場合分けして実行しなければなら
ないとしたら、それだけで大変な労力とテストが必要になることは、想像でき
るでしょう。
このように、O/Rマッピングを使うことは、オブジェクトからデータベースとい
う「構造の違いよる永続化の実装の複雑さ」から、プログラマの労力を解放し
てくれる、一つの手段なのです。

今回もそろそろ時間となりました。次回はJDBCプログラミングで言うところの
テーブルジョインを使った、複雑な検索方法について解説したいと思います。
(きしだ)

[*1]:該当号の過去ログは、下記URLより確認ください。
      入会する: http://www.objectclub.jp/ml-arch/magazine/164.html
      借りる:   http://www.objectclub.jp/ml-arch/magazine/169.html
[*2]:今回使用しているVersion1.2は、NullPointerExceptionを引き起こします。
     要は変更チェックで関連先のオブジェクトのObjectIdをisTemporaryで判
     断してくれれば良いのですが、何か理由があってのことかもしれません。
      次のバージョンでは解消されている可能性もあります。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E010-5&choice=0
普通:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E010-5&choice=1
イマイチ:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E010-5&choice=2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【PF】たまには仕事に役立つコミュニケーションのヒント[5]
          -壁にぶち当たったら、質問だ!

クリスマスや年末年始の過ごし方の話題が飛び交うようになりました。そろそ
ろ今年もラストスパートなんですねぇ。12月はビールとスパークリングワイン
の泡で消えてしまわないように、落ち着いて過したいものです。

●壁にぶち当たる

前回に引き続き、実際にあった出来事を題材に「壁にぶち当たったとき」とい
うことを取り上げてみたいと思います。また今度も、前回とは違うお客様のエ
ピソードを取り上げてみましょう。皆さんにも、こんな体験はありませんか?

Aさん。男性。44歳。ソフトウェア開発会社の取締役をしているAさんは、こ
の数ヶ月、ご自身のマネージメントをテーマに、コーチングを受けています。
Aさんは、ご自分の部下であるBさんのことについて悩んでいます。
Bさんはとても仕事ができる現場マネージャーなのですが、残業や休日出勤が
多く、このままではいくら働き盛りとはいえ、体を壊さないかどうか心配して
います。
「この仕事はBさんがやるようなことじゃないだろう。」そう声をかけると、
「部長、みんな忙しいので、仕方ないです。このぐらい大丈夫ですよ。」「他
にできる人がいなくて・・・。」そんなやり取りばかりだそうです。
Aさんは、Bさんと同じ年齢だった頃にご自身も体を壊しました。そんな体験
も手伝って、Bさんの気持ちを上司としてありがたいと思いながらも、心穏や
かではありません。

「Bさんのおっしゃるとおり、仕方ないのでしょうか?」と聞いてみたところ、
「人が少ないことや、仕事の量が多いことは事実なんです。優先順位をつけて
みたり、なにか私で動けることがあったら言うようには伝えたんですが・・・。」
「上司のAさんにリクエストをすることを、躊躇っているのでしょうか?」
「いや、本当に困ったときにはきちんと相談してくれるんです。ただ・・・。」
Bさんばかりではなく、私にはAさんも考えが壁にぶち当たっているように見
えました。

そこで、「AさんがBさんの立場だったら、どうしますか?」そう質問してみ
ました。そうすると、仕事の振り分け方を検討しなおすことや、延ばせる納期
はお客さんに交渉したらいいのではないか?とか、他に出来る人を探すなどと
いった幾つかのアイディアが浮かんできました。
そのまま話を聞いていると、Aさんは「Bさんに私からそう言うか・・・。」
と言いました。

そのとき、「Bさんにも、Aさんと同じように自分で考えてもらってはいかが
ですか?」私はそう提案しました。ここで命令としてBさんにお伝えすること
もひとつの手段ですが、Bさんにも視点を変えて考えて、自分で納得して進め
たほうが良いと思ったのです。そして、そう思ったことも伝えました。「そう
だな!。」Aさんは考えを変えたようです。
その後私たちはちょっとした質問の練習をして、AさんがBさんと実際に話し
合うシミュレーションをしてみました。そして、次のコーチングの時間までに
Bさんと話してくることを約束して、電話を切りました。

次のコーチングの時間は、Aさんの報告から始まりました。
Bさんと二人で色々アイディアを出し合い、最後は部下であるBさんが採用す
るアイディアを決めました。まだまだBさんの忙しい様子は変わらないように
見えるそうですが、休日出勤は殆どなくなったそうです。

●解説
コーチングの特徴のひとつは、コーチングする人が投げかける質問にあります。
知りたいことを質問で聞くのではなく、対象者(コーチを受ける人)が、より深
く考えるための質問をするのです。
今回のAさんのように、思考が壁にぶち当たったとき、思い込みや決め付けな
ども手伝って、なかなか解決の方法を見つけることが難しくなります。更に、
時間や期限が迫っていたりすると、【Aの手段でだめなら、Bの手段】といっ
た風に、熟考することが無くなり、これでは本当の意味での解決までに時間が
かかってしまいます。
そんな時、視点を変えるような質問が問題解決への鍵になるのではないでしょ
うか?

視点を変えるために作ることが出来る質問の例を、紹介します。
 ・仮説の視点に立つ。
    (もしも○○だったら?)
 ・時間軸を変えてみる。
   (4月の時点だったら?、10年後になるとどうなるかな?)
 ・立場を変えてみる。目標とする人物の視点に立ってみる。
    (○○さんだったら、どんな風に考えると思う?)
 ・制限をつける/はずす。
    (明日が納期だったとしたら?自由に考えられるとしたら?)
 ・原点に立ち戻る。
    (そもそもの目的は?)
 ・全体のバランスを考える。
    (全体の規模から見たら?)
 ・数値化する。
    (100点満点中、どのくらい?)
 ・感情に焦点を当てる。
    (やっていてどんな気持ちがしたのか?あのときの気持ちは?)

●まとめ
「どうせだめに決まっている。」と困ったときほど決め付けてしまうことは、
良くあることです。しかし、そう自分で決めてしまうことが、解決への道を
閉ざしてしまうのではないでしょうか?
壁にぶち当たったときこそ冷静になって、質問を試してみるのもお勧めです。
(上田雅美)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M003-4&choice=0
普通:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M003-4&choice=1
イマイチ:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M003-4&choice=2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ

今週は「あなたが身につけたいのはどんなこと?」のホントのところ。オブラ
ブクリスマスイベントの申し込みが始まり、皆さんの熱きコメントにスタッフ
一同、大変勇気付けられています。ありがとうございます。さて、参加の目的
は色々あるようですが、皆さんが仕事をやるうえで身につけたいのはどんなこ
と?

  高い技術スキル。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=132&choice=0
  チームやプロジェクトをまとめる、マネージメント力。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=132&choice=1
  場作りをするための、ファシリテーション力。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=132&choice=2
  まずは、体力。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=132&choice=3
  どんなことも乗り切ってゆくのさ!精神力!。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=132&choice=4
  色々な人と関わる上で、業界知識。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=132&choice=5
  どんなこともスルーできる、スルー力。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=132&choice=6
  それは秘密です。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=132&choice=7
  ちょっと語らせて!
     詳細をこのメールに返信ください!!

アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「オブラブメルマガをどこで読んでますか?」の結果は公開中。
ぜひご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru/vol131/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記

こんにちは、編集人です。秋イベントでも取り上げたLightning Talksですが、
その起源を調べてみました。YAPC(Yet Another Perl Conference)で、
Mark J. Dominusさんという方が考案した5分間限定スピーチだそうです。かた
苦しくなく気軽に、誰でも、失敗なんて気にしないで話し、聞く人たちも楽し
く、ストレス無く、気軽に、だけど発見がある!そんなことを引き起こす仕組
みなんですね。初めての人もベテランの人も、どんどん応募してください!
冬イベントのトークスが、ますます楽しみになりました。
参考:「What are Lightning Talks?」http://perl.plover.com/lt/

今週の強引な一言
*** 船頭多くして船山に登る(ことわざ)***
指図する人が多過ぎると、かえって統制が取れず、とんでもない方向にものご
とが進んでいくものだということ。ファシリテーターがいないからこんなこと
になるのでは?やっぱりファシリテーター役って必要ですね。しかし、どんな
人でも良いわけではないですよね。ちゃんと場を作ってくれないとね。
(上田雅美)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は         ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は   ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行:オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表:平鍋  健児
Copyright (c)2003-2006 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.