・「はじめてのRuby」を読了。次はRails。
・昔見たテリー・ギリアムの「12 Monkeys」。ブルース・ウィリス主演のSF映画でした。その時は気がつかなかったのですが、音楽が、敬愛するPaul Buckmaster。最近、サントラを手に入れました。テーマはピアソラの曲なのですが、所々、Buckmasterのきらりと光るストリングスが。
・N君の推薦で、谷崎潤一郎の「細雪」を読んでいるところ。900ページの大作です。まだ200ページですが、何故かドストエフスキーを連想。本当に久しぶりの小説です。
・Radio Meowingsの曲数がもうすぐ1000曲。記念にナレーションの入ったプログラムを作ったのですが、ナレーションの難しいこと。Toshiboさんのうまさに脱帽です。公開は再来週の予定。ちょっと怖い。
・グーちゃんはあれきり来ない。家には入れるまいと思っていたのですが、気配がするとドアを開けて確かめる始末。なんだか寂しい。
今週のRadio Meowingsは、Rick Wakeman,Coldplay,Spandau Ballet,Peter Gabrielをお送りします。宜しかったらお聴きください。
Rubyの本を読んでいて、正規表現の項になった。
そこで見慣れない記法が・・・。
(.*?)”
暫く考えたあげくに、「Perl5 デスクトップリファレンス」の正規表現の項を再読。
分かりました。
「繰り返しサブパターンは可能な最長の文字列にマッチする。ただし、その後に？が続く場合は、最短のマッチングを行う。」
Rubyの例では、「”」が現れるまでの最短のマッチングになります。
分かっていると思っていた正規表現での新しい発見でした。
Yugui著
オライリー(2008)
いまさらですが、Rubyの勉強を。
6月に出たばかりの本ですが、Amazonでは在庫切れ。楽天で買いました。
まだ1/3しか読んでいないのですが、これだけ言語がある中、更に新しい言語が必要なのか？、と思って読み始めたのですが、「ええっ！こんな設計ありなの？」と驚くことしきり。
まつもとゆきひろ氏を見直した1冊でした。
頭を硬くしないためにも、新しい言語には挑戦するべきですね！
マッコーネルの本だったか、プロならば、年に一つは新しい言語に挑戦するべき、というのがありましたね。
最近はプロジェクト管理や、ピープルウェアの本が多くて、とても年に一つにはなっていませんが、その精神は大切にしたいと思います。
Railsの本も読もうと思います。
Rubyが好きになりそうです。
とても魅力的な言語です。
リクルートの「アントレ」のネット版。
この中の「プロワーカー」と呼ばれる人たちのインタビューと、お店を持った人たちのインタビューそれぞれ数十件を読みました。公開期限が過ぎて参照できないもの以外の全てです。
好感が持てるのは、紹介されているのは大成功している人ばかりではないこと。
等身大のチャレンジャーの姿が垣間見えます。
モチベーションをたっくさんもらいました。
こういう情報を無料で提供しているリクルートに感謝です。
もっとも雑誌もそうなんですが、フランチャイズの広告記事で成り立っているサイトなんですが、それだけではないところが、立派です。
くじけそうになったら、是非ブラウズしてみてください。
「ああ、こんなに頑張っている人たちがいるんだ」そう思うだけで感動します。
みなさん、とってもいい笑顔です。
願わくば、私もこんな笑顔で毎日仕事をしていますように。
近所の書店で買った、「アントレ」8月号。
「アントレ」を買ったのは独立前に数冊買ってから、数年ぶり。
有名人、無名な人のいろいろな人たちの体験談は、元気の源になります。
こういうものを読むと、「何でもありなんだなあ」「どんな逆境でもリトライできるんだなあ」と改めて思います。
たった500円の雑誌で、これだけ元気づけられるとは、非常にお勧めです。
映画でも小説でもないリアルライフ。
それぞれの人の短い記事が、それぞれが感動的なストーリー。
みんなお金儲けのことなど考えていない。
世の中の不便を解消したい、困っている人を助けたいという信念のもとで頑張っている。
初心に返るいい機会でした。
それにつけても、一番大事なのは「健康」。
今まで、一番大事なのは、「時間」だと思っていたのですが、2番手に下げました。
健康であることに感謝！
昨日、今日と、DVDで映画鑑賞。
「ALWAYS 続・三丁目の夕日」と「ロード・オブ・ザ・リング 王の帰還」。
どちらも話題作だし、名作だし、楽しめるはずだったのですが、見終わった後の、この空疎感はなんでしょうか？
所詮、偽りの人生、と言う気持ちが常にある。
時間が長いほど、現実からかけ離れているほど、その感が強い。
親に話すと、「年をとったんだよ、そうやって卒業していくんだよ」という答えが。
ちょっと寂しいが、確かにそうかも。
でも多分、話題作のDVDは買い続けると思う。
それは友達と話を合わせるためにだけかもしれないが・・・。
今週のRadio Meowingsは、Enya,Kenny G,Ian Anderson,Matt Monro,John Barryをお送りします。宜しかったらお聴きください。
フィーリングが事実であり、しかも重要な事実である、とあなたが考えないなら、次のような質問を自分に投げかけてみるとよい。なぜ顧客は、しばしば、訴えられたり、違約金を支払うリスクを冒してまで、不満足な製品に対する契約を破棄するのか？そして、なぜ将来の製品の供給業者を変更するのか？
ブラックボックス作業は延期してはならない。目標を達成するメカニズムを考え始めてしまうと、その効力はなくなってしまうからだ。このような場合、システム試験は、そのメカニズムが物事を正しく行っているかどうか（設計及び実装の試験）を試験するという罠に陥ってしまい、メカニズムが正しい物事を行っているかどうか（要件の試験）には目が向かなくなってしまう。
そうではなくて、解を与える段階でではなく、問題を定義する段階で、ブラックボックス試験をしなければならない。特に、クライアントが何をしたいのかということを、どのようにしてそれを行うかということにかかわりなく、理解しようとしなければならない。
”チームは日曜日も休まずに働くが、要件作業は決して終わらない。”ある種の仮定の定義は、設計者、構築者、及び顧客に残されるのがつねである。しかし、あなたは、ある仮定は他の人が定義するように残しておくという、メタ仮定を文書化しておくことができる。
全ての仮定を意識に上らせること。そうすれば、開発プロセスが進むにつれてそれらを制御できるようになる。
凍結というアイディアは、幕引きの恐れを手なづけるために考案された幻想にすぎない。しかし、私たちは、必要なら再交渉プロセスがあるということを知っていなければ、恐怖を覚えることなしに要件フェーズを閉めることはできない。
不完全であるというおそれによって、無限サイクルに陥ることがあるから、要件プロセスを終了させることに特に注意を払うこと。
作業に参画した人すべてから終了したことの合意を取り付けること。そうしなければ、彼らはいつまでも変更することを止めない。再交渉プロセスを約束すれば、彼らは合意するだろう。
要件作業を終わらせることは本を終わらせること、特に要件定義のような開かれた主題の本を終わらせることに似ている。あなたはもっと言うことを持っているが、朝にコンマをとり、夕べにそれを戻すようなことをしているのに、自分で気づくときがくる。その時点で、あるアイディアを不完全のまま残し、ある啓示は見えないまま残しておきリスクをただ受け入れるのだ。文書化された資料が失われていないことを確認し、勇気を集め、そして止めるのである。
～設計に先立つ品質の作り込み」
D.C.ゴーズ
G.M.ワインバーグ
黒田純一郎 監訳
栁川志津子 訳
共立出版株式会社(1993)
あいまいさは高くつくのだから、あいまいさにアタックすること。
できるだけ早い時点であいまいさを攻撃すること。いつかはあいまいさから抜け出すにしろ、製品開発の早い段階で誤りを修正すれば、遅い段階で修正するよりも、はるかに安く修正できるのだから。
最大の仮定が行われるのは、開始以前の思考によるものである。
●
誰がクライアントか？
クライアントにとって本当に価値のある高い成功を収める解とはいかなるものか？
この問題を解決したい真の理由は何か？
設計チームは一つだけにするか、複数必要か？
誰をチームに入れるか？
このプロジェクトにどれだけの時間をかけてよいか？
時間と価値のトレードオフはどうか？
この設計問題の解はどこか他で得られるか？
既存のものを模倣できるか？
●
この製品はどんな問題を解決するか？
この製品はどんな問題を作り出すか？
この製品はどんな環境で使用されることになるか？
この製品に要求される、あるいは望まれる精度はいかなるものか？
●メタ質問
私は質問しすぎるか？
私の質問は妥当か？
あなたはこの質問に答える適任者か？
あなたの回答は公式なものか？
お互いの理解を確かめるため、質問と回答を書いておき、空いた時間に検討したい。あなたの回答を書いて、コピーを渡すから、査見してもらえるか？
●
書類は役に立ったが、面談すれば、もっとよく問題が理解できると思う。いつかお目にかかれるか？そうすれば、私たちはもっとよく知り合え、問題点をはっきりさせることができる。
他に有益な回答をくれる人がいるか？
製品が使用されることになる環境を見に行けるところがあるか？
●面談を終える前のメタ質問
何か他に、私が聞いておくことがあるか？
あなたが私に聞きたいことがあるか？
今回カバーできなかったことがあれば、またここへ来るか、電話してよいか？
●
この質問に答える前にだいぶ長い間躊躇されたようだ。他に何か私たちが知っておかなければならないことがあるか？
その問題をXにたずねたところ、彼女はYと言った。あなたは彼女がなぜYと答えたのか心当たりがあるか？
あなた方は回答に合意しているようには見えない。そのことについて、何か聞いておくことがあるか？
これまでの進め方に満足しているか？
不満なことがあるなら、その理由は何か？
このプロジェクトに携わっている他の人々について何か話せるか？
このプロジェクトで私たちと仕事をしている他の人たちについてどのように感じるか？
このプロジェクトに入っていない人で、必要な人がいるか？
このプロジェクトには必要でない人が入っているか？
その人についてもっと話してもらえるか？
みんなのための会議（注意点）
１．出席者全員にとって安全な文化を創る。
２．会議はできるだけ小さく、ほどよい規模にする。
３．どの会議も一つのタイプに限定し、そのタイプを当面の仕事に合わせて設計する。
４．念入りに準備する。
５．熟練した司会者を使う。
要件定義の基本的な問題はあいまいさである。
観察：人々が重要な事象を見たり聞いたりするときの差異
記憶：人々が重要な事象を思い出すときの差異
解釈：人々が重要な事象に結び付いた重要な出来事をどのように解釈するかという差異
問題理解：人々がどのように心の中で問題を定義するかに関する差異
道具は次の三つの範疇に大別されることに注目して欲しい。すなわち、自分がどこにいるのか（アイディアが多すぎるのか、少なすぎるのか、ちょうどよいのか）を判断して記憶する道具、南に移動する（アイディアを減らす）道具、北へ移動する（アイディアの数を増やす）道具。
紛争の調停
司会者がしなければならない最初のことは、紛争が本質的なものかどうかを判断することだ。本質的な紛争とは、このプロジェクトに、この時点でかかわり、今出席している人々を巻き込むものである。
よい司会者であるためには、完全に参加する技術–自由に注意する、自由に質問する、自由にコメントする–を身につけなければならない。
●私は今回中立と思われているかもしれないが、提案Aを支持したい、提案Bは文書になっていないのだから。
●考えをまとめるために5分間の休憩をとりたい
●ぼくは今かなり腹を立てている、頭を冷やすため2時間ほど休憩したい。
●何人も一緒に話すから、ぼくは会議についていけない。
●フィービ、君の話を全部聞きたいのだが、マリリンが話し始める前に全部終わったのかどうかわからないんだ。どうなの？。
どんなプロジェクトも紛争を経験するし、ある種の調停なしでは、一貫して成功することはできない。幸運にも必要が生じたときに、活動できる”アマチュア”調停者でうまくいくプロジェクトもある。しかし、幸運に頼りたくないと思えば、訓練を受けた調停者集団を作り上げることだ。
生活 
コメントは受け付けていません。