プログラミング C# - 翔ソフトウェア (Sho's)

『ソフトウェア技術者サミット in 福井』
日時	2005/01/31(月) 13:00～
会場	福井県産業情報センタービル 8F (福井県坂井郡丸岡町)
主催	アジャイルプロセス協議会 見積り契約ガイドライン作成ワーキンググループ
共催	FITEA ― 福井情報技術者協会 準備委員会

1. 『アジャイルプロセス協議会の活動内容と今後の展望について』フリーITコンサルタント 北野 弘治 氏 特別出演 ギターSE 氏
2. アジャイルプロセス協議会 セミナー『アジャイルプロセスのもたらすインパクト ―ソフトウェアとビジネスの本質的困難をのりこえる知識主導型の経営、組織、プロセスについて考えよう―』 株式会社一 大槻 繁 氏
   
3. 福井情報技術者協会 発足セミナー『今こそ、立ち上がろっさ。ソフトウェア大国福井を目指して!』 福井情報技術者協会 準備委員会
4. アジャイルプロセス協議会 セミナー『リーンソフトウェア開発と「見える化」』 株式会社永和システムマネジメント 平鍋 健児 氏
   
5. 交流イベント『ソフトウェア開発の成功・失敗の意外な要因』
6. 懇親会
   
7. 二次会

北野さんの挨拶でスタート。北野さんのアイディアで、アイス ブレーキングとして、ギター SE 氏がギター持参で特別出演。ソフトウェア技術者を斬ってもらった。

私は、福井情報技術者協会 発足セミナーと交流イベントで司会をした。
話しながら、観客席側を見ていたら、なんか妙に大きいビデオ カメラで撮影している人がいる。
後で名刺を渡されて気付いたが、FBC (福井放送) の人だった。
夕方の FBC のニュースで流れたそうだ。
まさか TV 局が取材に来るとは思わなかった。誰も直接は声を掛けていないはず。

それにしても、大槻 さん と 平鍋 さん の話は良かった。実装者だけでなくソフトウェア開発全体を広い視野でみていて、しかも、具体的な解が用意されている。とても刺激的な話だ。
実は、今回のテーマのお話をお二人から伺うのは、とある東京のイベントに次いで二回目。
これから、福井でもこのような講演が聴けるようにしていけたら、と思う。

実は数年前から、こうしたソフトウェア技術者向けのイベントを福井で開催したいと思っていた。こうして、アジャイルプロセス協議会 さん のおかげで実現できたことは感無量だ。

福井・石川にもアツイ技術者がいることが判ったこと、そして、その人達と沢山の話ができたことは、とても良かったと思う。
イベント中、懇親会、二次会と話したが、まだまだ話し足りないくらいだ。

この体験を、是非次の行動につなげていきたい。

参加された方のエントリー:

• 福井プログラマー生活向上委員会 ― 福井の情報技術者のパワーが炸裂


• からくり屋Blog ― ソフトウェア技術者サミット in 福井


• keke log ― 050131 ソフトウェア技術者サミット


• 人生　伊達と酔狂 ― ソフトウェア技術者サミット in 福井

明日は、いよいよデブサミ。

二泊は無理があるので、明朝行く予定にしていた。
朝行こうと思ったら、小松空港から飛行機しかない。

ところが、雪のため今朝の羽田行きは第一便から今まで全部欠航している。

寒波が来ていて、二月の頭から結構な雪が三日降り続いたため、北陸では JR や道路も含め、あちこちの交通機関に悪影響が出ている。

昨晩も、道は混んでいるは、一本道でトラックが側溝にはまっているはで、通常なら 10 分で帰宅できるところを、一時間も掛かってしまった。

天気予報によると、「3日午前6時までの24時間に予想される降雪量は、山沿いの多い所で、北陸が70センチ」だそうで。

ということで、デブサミに行く方法をちょっと考え中。

・朝起きて、居間から外を見る

・家々の様子

・車の様子

・息子の通学風景

・私の通勤風景

上記に参加してきたので、レポートしてみたい。

■ 詳細

Developers Summit 2005
日時	2005/02/03(木)～04(金)
会場	青山ダイヤモンドホール
主催	株式会社 翔泳社
詳細	Developers Summit 2005

■ はじめに

デベロッパーズ サミットの開催期間には丁度、寒気団が日本上空に来ていた。
北陸地方は、今年一番の大雪で、出発前日の午前中には羽田行きが飛ばなかったこともあり、無事会場に行けるかどうかが先ず心配だった。

当日の朝は、五時半に自宅を出発した。道には新雪が積もり、ちょっと油断するとすぐスタックしてしまう。
高速道路もすっかり凍っている。凸凹の路をゆっくりと走った。

それでも小松空港には随分早くついた。INETAJ のイベントに一緒に出る杉下さんも、たまたま飛行機が同じで、同じ頃に空港にいらした。
心配した飛行機は定刻通りに出発し、定刻通りに羽田に到着。予定通りに会場につくことができた。ほっと一安心。

さて会場に入ると、すごい人の行列。
二日間会場の青山ダイヤモンドホールは大変な人で、歩くのに苦労した。

デベロッパーズ サミットには、最初の年から毎年参加しているが、参加するたびに良くなっている。
特に今回は、楽しみなセッションが盛り沢山で、選ぶのに迷うほどだった。

ただ、昨年も感じたことだが、あの Web からの申し込みのユーザー インタフェイスはちょっと「いけてない」気がする。
あれは本当にユーザーの方を向いた UI と言えるのだろうか。
ユーザー側の関心事に対してではなく、主催者側の関心事に対して UI が設計されているように感じた。

• 主催者側の関心事 : 各セッションに何人の人が参加しようとしているのか。どういう人が参加しようとしているのか。
• ユーザー側の関心事: 自分がどのセッションを何時受けるか。申し込み/変更/キャンセルの方法。

今回の参加者、即ちデベロッパーにとっては、ユーザーの視点・ユーザーの関心事に合わせるのがデフォルトだから、多分違和感有りまくり。

でもまあ、その他の面では大満足。とっても良いイベントだった。
デベロッパーが中心というのが実に良い感じ。

このイベントのサブタイトルに「デベロッパーの復権」というのがある。
この趣旨には大賛成。
日本のデベロッパーも、もっと楽しく自信に満ちて物作りをして良い。

■ 参加内容

○ XP事例カタログ
大熊 知栄 氏、猪狩 錦光 氏、関 将俊 氏、小倉 唯克 氏

四年の歴史を誇る XPJUG (日本 XP ユーザグループ) で紹介されてきた XP プロジェクトの中から三つの例が紹介された。

すごい人で立ち見がでている。

大熊 さんの司会に始まり、三人の発表者が順に XP 事例の紹介を行った。

関 さん の発表は、XP 祭り 2004 で 関 さん が発表された内容「三年目の報告」(サブタイトル「XPが良いか悪いかなんて話は もうしないよ。」) だが、マイナー バージョンアップしていて「その後」が少し語られた。題して「3.5年目の報告」。「忍者式テスト」など、独自に XP をカスタマイズされている。
二人目の方はゲーム業界での XP。単純作業などのときに使う「ペアプロ解除」というプラクティスが興味深かった。

お二人とも開発者として、XP をやっていく中で現実的な解をいくつも見つけている。
また、回顧をよくやっていて、次にフィードバックしている。

今回特に良かったのは、顧客側からの XP プロジェクトの発表があったことだ。
以前見たことのあるバーンダウン チャートが顧客側視点で語られた。
これは結構目から鱗で、視点が変わると随分違って見えるものだと思った。

○ 失敗から学ぶプロジェクトマネジメント
伊藤 健太郎 氏

XP だけでなく、プロジェクト マネジメントについても学ぶ必要があるだろう、ということでこのセッションを聴きにいった。

• プロジェクトの失敗原因は? → プロジェクト マネジメントの進化のさせ方

という内容のセッション。
プロジェクトの失敗原因で、

• プロジェクトを KKD (勘と経験と度胸) で実施

というのが印象的だった。

ソフトウェア開発の場合、QCD (Quality: 品質・Cost: コスト・Delivery: 納期) のマネジメントだけでは、中々プロジェクトの成功に結び付かない、とよく言われているようだが、プロジェクト マネジメントも進化しているようだ。

講演中、プロジェクト マネジメントによるプロジェクト成功のための様々なキーワードが使われたが、「いけてる」と思ったものを私の独断であげてみる。

• いけてるキーワード:
  • コミュニケーション
  • モチベーション
  • キャリアパス
  • ナレッジ マネジメント
  • メンタリング

ところで、はじめの方で「是非このセッションが思い出に残るように」とのことで、「プロジェクトの失敗について隣の人と話してみよう」という時間があった。
アイス ブレーキングなんだろうが、これはちょっといけてない。余りにも唐突で中途半端な感じ。

○ .NETでアジャイル ペアプロ ライブ! ～VB.NETはテスト ファーストで行こう!
中西 庸文 氏、福井 厚 氏

「ドットネッターでアジャイラーで TDDer (謎)」になるための方法について。

最近は、Java の開発者に比べてアジャイルに馴染みが薄い .NET の開発者の人たちにもアジャイルな開発を知ってもらいたいという趣旨の講演や記事が漸(ようや)く増えてきたようだ。
嬉しい限りだ。

さてこのセッションだが、なんと終始関西弁。
ペア プレゼンになっていて、会話形式で説明が進められていく。

圧巻は途中二回の「ペアプロ笑劇場」と題したペアプロ ライブ。
若手アジャイラーとアジャイル未経験なベテラン先輩開発者という設定で、テスト ファーストなペアプロを行う。
で、このペアプロが TDD で且つ TDD (謎) なのだ。

前者の TDD は、勿論テスト駆動開発 (Test Driven Development) のこと。アジャイルではお馴染みの手法だ。
後者の TDD (謎) は、ツッコミ駆動開発 (Tsukkomi Driven Development)。
テンポの良いボケとツッコミによって、開発が進められていった。このテンポは関西弁ならではかも。

※ ちなみにツッコミ駆動開発にもペアプロは必須。
※ 一人でぶつぶつとボケとツッコミをしながらプログラミングされるのはかなり嫌だ。

面白いのは、ペアプロなので、ドライバー役 (キーボードでプログラムを書く方: リアルタイム コード レビューア) とパートナー役 (ドライバーのコーディングを見ていてリアルタイムにフィードバックを行う) があるのだが、パートナーがボケてドライバーがツッコんでいたりする。

二回目の「ペアプロ笑劇場」では、Mock (擬似オブジェクト) によるテストも紹介され、技術的にも興味深かった。

このセッションを聴き終わって考えたこと:
これは私の経験則だが、アジャイルな人というのはアジャイルな講演をする。
見ていて感動が有る。
プレゼンテーションが濃いのだ。

薄いセッション →	濃いセッション →	もっと濃いセッション
パワーポイントに文章を書いておいて、それを読みながら解説 →	実際にやってみせる →	参加者に体験してもらう
言葉で説明する →	図や写真で説明する →	寸劇で表現・動かして説明
抽象的な新しいアイディアを述べる →	具体的な例を交えて新しいアイディアを述べる →	新しいアイディアを試してもらう

コミュニケーションの帯域が違うのだ。時間当たりに伝わる情報量が違う。
これは、沢山話して言葉数を増やす、ということではない。沢山のパワーポイントを用意する、ということでもない。

発信側でなく受信側の情報量を増やすのだ。
新しいアイディアというものは、いくら言葉数を増やしたって伝わらないものは伝わらない。
見せる工夫、伝える工夫をしなければ。

私はこれを Broadband Communication と呼びたい。

仕事でも多分同じだ。

例えば、

• 「プロジェクトの失敗の主な要因はコミュニケーション エラー」

という問題提起があるとする。先のプロジェクト マネジメントのセッションでもこれはあげられていた。

でそれに対する解。プロジェクト マネジメントのセッションでは、

• 「コミュニケーションは『お仕事』なんだからしっかりやらなくちゃ」

ということだった。

でも「プロジェクトの失敗の主な要因はコミュニケーション エラー」という問題提起に対して、しっかりやるべきなのは自明であって、それだけでは不十分なのだ。
そこには「見える化」など実践するための工夫がなければならない。アジャイルな人たちはそこが上手だと思う。

○ INETA Japan Presents VB.NET vs C# 『.NET 言語合戦』
河端 善博 氏、東海林 秀晃 氏、小野 修司 氏、石野 光仁 氏、菊池 和彦 氏、小島 富治雄 氏、福王寺 聡明 氏、杉下 朋年 氏、中西 庸文 氏、片岡 真二 氏、樋口 忠洋 氏、Hollytown 氏

Visual Studio .NET 2003 になってからは、VB.NET と C# はそれほど使い勝手に違いがなくなりつつある。2005 では更に優劣がなくなる。
その中で、VB.NET と C# のそれぞれの長所をあげて、双方の使いどころについて考えてみよう、という趣旨のイベント。
別にどっちを使っている方が偉いかを競う訳ではない。

INETA Japanは、.NET のコミュニティのコミュニティだ。
私は、パネラーの一人として参加。C# 側。

ライブで VB.NET と C# のそれぞれで七並べの戦略部分をプログラミングし、その場で対決した。
お客さんは勝つと思う方に投票し、勝負の結果により、アマゾン ギフト券や PSP などが当たる。全員に参加賞もあたる。

パネル ディスカッションは、どうやら C# 側が劣勢な儘(まま)終わってしまった。折角 C# 側のパネル リーダーの小野 さん が頑張ってくれてたのに。残念。
C# を応援してくれてた参加者の方はさぞやきもきしたことだろう。
というか、VB.NET 側のパネル リーダーの杉下 さん のプレゼンが良過ぎた。

反対にプログラミング ライブの結果の七並べの対戦では、C# 側が終始優勢だった。

商品の効果かも知れないが、全体としては結構ほんわかと盛り上がっていたようで、コミュニティ色が出ていて良かったのではないだろうか。

○ My Framework作成の勧め：アプリケーションを30個作る時に何を用意するか
arton 氏

或る業務に関して、沢山アプリケーションを書くのであれば、その業務に特化した良いマイ フレームワークを自分で書いた方が良い、というお話とその作り方のお話。

arton さん のお話は、理論的で且つとても判り易い。

• フレームワークって何のことだったのか。
• 作ると何がうれしいのか。
• 良いフレームワークってどういうものか。
• そして .NET 上で作る方法は。

arton さん の独特の語り口は、とても説得力がある。

フレームワークの作り方の話は特に技術的に興味深かった。

パラメータ、プッシュ モデル (Tell) /プル モデル (Ask)、依存性注入 (Dependency Injection) などの実際の実装方法を、C# のソースをデバッグ実行しながらデモで見せてくれた。

リフレクションで仮引数名で検索してみせたり、実行時にコンパイラを呼び出してパラメータを評価させたり、自作の DI コンテナを使って依存性注入を実際にやってみせたり、ととても楽しめた。

※ ちなみに、このソース コードは公開されている。

○ フレームワークの効能と、.NET導入事例紹介
三部 雅法 氏

.NET Framework 上でのフレームワークの紹介とその導入事例の紹介。
自社製フレームワークの説明という感じ。

○ セッション参加者のパーティー (懇親会)

一日目の夜は会場でパーティーがあった。
デベロッパーズ サミットの場合は、他のイベントと比較して広い分野から参加者が集まっている。
で、層としては技術者が中心。
なんか縦割りでなく横割な感じで新鮮だった。

例えば、ドットネッターとアジャイラーは日頃それ程イベントでかぶらない。
今回はあちこちでドットネッターとアジャイラーが名刺交換する風景が見られた。

私も、多彩な人とお話ができて実に楽しかった。

○ 二次会

懇親会を途中で抜け出して、ドットネットな方々 (INETAJ・MVP) と原宿辺りで二次会。

○ その他

二日目の午前中は、INETAJ のリーダーズ ミーティングに参加した。
マイクロソフト 新宿オフィス。
その後 INETAJ の方々と食事会。

■ 人とのつながり

今回も多くの方々と話すことができた。
イベント参加の一番の収穫。

• 今回デブサミで初めて直接ご挨拶できた方々 (50音順):
  小野 さん、菊池 さん、国広 さん、関 さん、田中 さん、原 さん、樋口 さん…
• デブサミで再会できた方々 (50音順):
  arton さん、天野 さん、石野 さん、市川 さん、岩切さん、牛尾 さん、大熊 さん、太田 さん、小野 さん、沖田 さん、角谷 さん、懸田 さん、片岡 さん、河端 さん、倉貫 さん、小井土 さん、児玉 さん、佐藤 さん、渋木 さん、東海林 さん、杉下 さん、中西 さん、平澤 さん、平鍋 さん、福井 さん、福王寺 さん、松本 さん、水越 さん、堀田 さん、安井 さん、吉原 さん、和田 さん…
• 同じデブサミ会場にいらしたのに再会できなかった方々 (50音順):
  北野 さん、本間 さん、森屋 さん、和田 さん…

※ お会いしたのにお名前のもれてる方、すみません。ご指摘頂けると幸いです。

■ 関連リンク:

• @IT ― ユーザーに泣かされないITコンサルになるには
• @IT ― バズワードの連発は控えめに
• @IT ― マイクロソフトが提供する開発指針「MSF」とは何か? ―― 翔泳社デブサミ2005 セッション・レポート ――
• MyMy-MyCompany ― デブサミ2005 レポート
• Chronicler わらわらのつぶやき ― [IT]デブサミ2005
• Chronicler わらわらのつぶやき ― [IT]デブサミ2005（第２日）
• Matzにっき ― デブサミ2005 (1日目)
• Matzにっき ― デブサミ2005 (2日目)
• khiramatsuの日記 ― [セミナー]デブサミ2005 2日目
• +++ study room +++ ― [event]Developers Summit2005
• mattena31の日記（主にSeasar2） ― [お勉強]デブサミ
• seraphyの日記 ― デベロッパーサミット2005にゆく
• トアル電算室ノ業務日誌 ― デブサミ行ってきました。（下書き）
• sisonoの日記 ― [その他] デブサミ
• 日々の破片 ― デブサミ終了
• いつまでも構想中 blog ― デブサミINETAJセッション無事終了
• ぺがらぼ Blog ― INETAJ] デブサミ2005 VB.NET vs C# 『.NET 言語合戦』裏話その１
• ぺがらぼ Blog ― INETAJ] デブサミ2005 VB.NET vs C# 『.NET 言語合戦』裏話その２
• ぺがらぼ Blog ― INETAJ] デブサミ2005 VB.NET vs C# 『.NET 言語合戦』裏話その３
• ぺがらぼ Blog ― INETAJ] デブサミ2005 VB.NET vs C# 『.NET 言語合戦』裏話最終章
• jkondoの日記 ― デブサミ
• ぁまんによニッキ ― デブサミ
• ぁまんによニッキ ― デブサミ2日目
• J.Matsumotoの日記 ― デブサミ2005
• J.Matsumotoの日記 ― デブサミ懇親会と二次会
• PM見習いの読書日記 ― [dev]Developers Summit 2005 感想
• Ryo.Matsudaのほろ酔い徒然 ― [開発] デブサミ2005
• Studio Dragon Private Editon ― 馬場 経由 表参道行き
• hayashihがOSをインストールする日記 ― Developers Summit デブサミ2005 １日目
• hayashihがOSをインストールする日記 ― Developers Summit デブサミ2005 ２日目
• Miya's Weblog ― [セミナー]デブサミ2005
• ★ B. T. T. P ★ ― Developers Summit 2005
• 【よーたか】の日記 ― デブサミ
• UnsupportedOperation ― [Seasar]Developers Summit
• すがるの4004年の歴史 ― デブサミ
• あじの日々 ― [etc] Developers Summit 行ってきた
• atene1968の日記 ― [コンピュータ]Java Studio Enterprize
• 紺バージョン ― ■ めも
• nitsujiの日記 ― [仕事]デブサミ2005
• アピラクンの日記 ― デブサミ終了
• やしな日記/shayash ― デブサミ2005
• ふぇみにん日記 ― [Ruby][OSS] Developer Summit 2005 (1 日目)
• ふぇみにん日記 ― [Ruby][OSS] Developer Summit 2005 (2 日目)
• @江青日記 ― 2005-02-05 ― [デブサミ2005]みなさんの日記をたどって

2/3 に行われた Developers Summit 2005 ― INETA Japan Presents VB.NET vs C# 『.NET 言語合戦』 のために集めたネタ (とイベント中で使われたネタ)。

• 【.NET】VB.NET 及び C♯ の良い点・悪い点

三連休で久々に天気が良いので、家族で福井県勝山の長尾山総合公園へ。

ここは家から車で30分くらい。恐竜博物館がある場所で、橇(そり) やスノーシュー、クロスカントリー スキー、スノー モービルなどで遊ぶことができる。

子供らと橇とクロスカントリー スキーをした。
娘は生まれて初めての雪遊びにはしゃいでいた。

# 久々に技術ネタを書いてみる。 # と言っても、某掲示板で使ったネタの使い回し。

C++ にはなかった新しいキーワードとして、C# では interface というものが出てくる。 interface は、Java ではおなじみのキーワードだ。

例．

interface ICloneable
{
    object Clone();
}

interface では公開されているメソッドとプロパティの外見 (名前、パラメータ、戻り値) だけが宣言されていて、実装部分が定義されていない。実装部分は、その interface を実装するクラスによって定義される。

例．

class Employee : ICloneable
{
    private string name;

    public string Name
    {

        get { return name; }
        set { name = value; }
    }

    public Employee(string name)
    { Name = name; }

    public object Clone()
    {
        return new Employee(Name);
    }
}

interface は 抽象クラス (abstract class) と機能的には似ている。 抽象クラスも、中身のないメソッド (abstract method) の宣言を持つことができ、そこから派生したクラスで、そのメソッドの実装を定義する。

例．

abstract class Person
{
    private string name;

    public string Name
    {
        get { return name; }
        set { name = value; }
    }

    public Person(string name)
    { Name = name; }

	public abstract void DoSomething();
}

class Employee : Person
{
    public Employee(string name) : base(name)
    {}

	public override void DoSomething()
    { /* Do good job. */ }
}

機能上の大きな違いとしては、

• • 抽象クラスは、実装を持つこともできる。上記の例でいうと、name や Name や Person(string name)。
  • interface は、実装が持てない。
• • 抽象クラスは、二つ以上継承できない。つまり、多重継承できない。
  • interface は、二つ以上でも継承できる。

というものがある。 しかし、機能上の違いでなく、使い分けるときの一般的な指針はないだろうか。 デザインパターンの一つである、State/Strategy パターンの場合で考えてみよう。 先ずは、抽象クラスを使った場合と、interface を使った場合の両方について書いてみる。

・抽象クラスを使った場合の例:

class Context
{
    State state = null;

    public State State
    {
        set { state = value; }
    }

    public void DoSomething()
    {
        if (state != null)
            state.DoSomething();
    }
}

abstract class State
{
    public abstract void DoSomething();
}

class ConcreteState1 : State
{
    public override void DoSomething()
    { /* 省略 */ }
}

class ConcreteState2 : State
{
    public override void DoSomething()
    { /* 省略 */ }
}

・interface を使った場合の例:

class Context
{
    State state = null;

    public State State
    {
        set { state = value; }
    }

    public void DoSomething()
    {
        if (state != null)
            state.DoSomething();
    }
}

interface State
{
    void DoSomething();
}

class ConcreteState1 : State
{
    public void DoSomething()
    { /* 省略 */ }
}

class ConcreteState2 : State
{
    public void DoSomething()
    { /* 省略 */ }
}

さて、State/Strategy パターンを使う場合、はたしてどちらが標準的なのだろうか。 「State/Strategy パターンを構成している部分だけ」を見ると、或る振る舞いに関する制約が付けられれば十分なので、interface が適しているような気がする。 但し、実際の設計では、

「State/Strategy パターン」を使おう → じゃ interface を使おう

とはならない。 それは、通常 State/Strategy パターンが適用される場合というのは、先ず (リファクタリングなりの結果としての) クラス設計があって、そこにおける抽象化すべきものがクラスなのか、振る舞いに関する制約なのかの判断があり、結果として「State/Strategy パターン」の形になるだけであるからだ。 つまり、抽象化したいのがクラスであれば抽象クラス、単なる振る舞いに関する制約であれば interface、という感じで使い分けることになる。 それから、もう一つ。 実装上の問題として、State/Strategy パターンなどが対象としている関心事が、既存のクラス階層と直交する関心事であった場合は、抽象クラスでなく interface を使う。多重継承ができないからだ。 例えば、始めの方の例でいうと、

等の継承によって形成される継承ツリー或るいはその他の継承ツリーが対象としている関心事と、ICloneable が対象としている関心事は直交している。 従って、ICloneable の方の関心事の実装には interface を使う。 これは、「アスペクトの実装を便宜上 (言語の都合上) interface で行う」というイディオムといえるかと思う。 尚、余談になるが、Strategy パターンの場合は、抽象クラスも interface も使わずに delegate を使う、というイディオムも有ると思う。

例．

class Context
{
    public delegate void DoSomethingMethod();

    DoSomethingMethod doSomething = null;

    public DoSomethingMethod OnDoSomething
    {
        set { doSomething = value; }
    }

    public void DoSomething()
    {
        if (doSomething != null)
            doSomething();
    }
}

続きは「[C#] Tips: interface と partial class で横断的関心事を分離」。

今まで新人向けのオブジェクト指向の研修で、「継承」というのは、

    class Sub : Super
    {
    }

こういうのだ、とか説明してきたんだけど…

ごめん。この説明はちょっとごまかしなんだ。
説明が面倒だったから…

本当は、これは C# 言語の「派生」なんだ。オブジェクト指向でいう継承と同義じゃない。
これは、「『派生』という機能を使って継承を実装する」っていう C# のイディオムに過ぎないんだ。

他にも、オブジェクト指向の用語を C# にマッピングして説明するときに結構ごまかしてるんだ。

    Super  s = new Super();

オブジェクト指向っぽくこれを表現してみると、
「Super というクラスに new というメッセージを送ると s というインスタンスが作られた」
という感じかな。

    s.Foo();

これも、「s という名前のインスタンスに Foo というメッセージを送ると s はそれに応じた振る舞いを行う」という感じに表現できる。

でも、実は C# 的には、s はインスタンスじゃない。参照変数に過ぎない。インスタンスを参照してるだけ。インスタンスは別に在る。

これも、「クラスのインスタンスを参照変数で表現」っていう C# でオブジェクト指向をやる場合のイディオムを前提に説明しちゃってる。

用語の曖昧さを使って誤魔化していたんだ。説明すると長くなっちゃうからね。
本当は、どのレイヤの話をしているのか、明示すべきなんだ。

ごめんよ。

コミュニティ活動を色々やる中で思い付いたので、ちょっとメモ。

■ コミュニティのマニフェスト

「私たちは、

『明文化された厳密で詳細な決まりごと』より『柔軟な臨機応変』、
『全ての問題が解決するまで始めない』より『先ずはやってみて結果をフィードバック』、
『入念な準備』より『変化への対応』、
『トップダウンなコミュニティ』より『ボトムアップなコミュニティ』、
『縦社会のコミュニティ』より『横社会のコミュニティ』、
『報告』より『双方向のコミュニケーション』、
『責任者の追及』より『言い出しっぺの法則』、
『どうあるべきか』より『どうしたいか・どうなりたいか』、
『責任感』より『ボランティア精神』
『義務感』より『自由な参加』

をより尊重します。
(前者も尊重するが、後者をより尊重する)

これは、理想を言っているのではありません。極めて現実的な解です。
全てを前以て厳密に決め厳密なトップダウンで実行、という方がはるかに理想を追っていて非現実的です。コミュニティなのですから」

私の大好物にハントンライスというのとタンバルライスというのがある。
子供の頃はよく食べた。
しかし、ここ二十年では一回しか食べていない。

洋食の一種で、強いて言えば、それぞれオムライスとドリアに似ている。
でも、強いて言わなければ、何にも似ていない。ハントンライスはハントンライスだし、タンバルライスはタンバルライスだ。
ハントンライスのハンはハンガリーのハン、トンはフランス語でマグロを意味するそうだが、そんなこともどうでも良い。

はっきり言ってうまい。
十年に一度くらい、猛烈に食べたくなる。
丁度今がその十年に一度の状態だ。

何処にでもある料理ではない。
東京にも無いだろう。

しかしすぐにでも食いたい。

これはもう自分で作るしかないか。

ハントンライスのレシピ: COOKPAD ＊ハントンライス＊

ナジャイラ (NAgiler: ドットネッターでアジャイラーの意味) の中西 さん の言葉。

いい。
実に良い。

強い言葉だ。

言い訳じみていないし、説得しようとしていない。

「こうあるべき」、「だからこんな風にしていくべき」なんていう「べき論」なんか寄せ付けない潔さがある。

凛とした感じ。自然体。

毛筆で書いて飾りたいという意見があったので、作ってみた。

一昨日、『第4回ITベンチャー交流会』に参加してきた。

第4回ITベンチャー交流会
2005/02/24(木) 17:00～20:30
福井県産業情報センタービル

前回に続いて二度目の参加。

このイベントは第一部と第二部に分かれていて、第一部は、DREAMGATE『起業・独立の強化書』の著者の増田 紀彦 氏の講演。

福井の西武デパート近くの店や呉服町商店街の話からスタートし、以下のような独立・起業に関わるノウハウと事例が紹介された。

• 「事業の基本プラン『誰に、何を、どう売るか』」と「事業の実施プラン『いつ、誰と、いくら使って売るか』」は違う。
• いけてる『誰に、何を、どう売るか』といけてない『誰に、何を、どう売るか』がある。
• 「起業したい」と「独立したい」と「今の職場がいや」は違う。
• 「ブログがはやっている→ブログで設けよう」ではなく「ブログがはやっている→ではどんなビジネス チャンスがあるのか」と発想せよ。
• 「事業家」と「経営者」は違う。自然の摂理が伴ってない基本プランの事業を、「経営」したって駄目。
• 『誰に、何を、どう売るか』がうまく行かなくなったら、『誰に』や『何を』や『どう売るか』のどれかを変えることで、いけてる事業になる例がある。
• 事業にお金を安易に投入するな。知恵を投入せよ。

第二部は、立食形式の交流会。

前回のときにお会いした方や、『ソフトウェア技術者サミット in 福井』に参加して頂いた方と再会。
新たな知人もできた。

今回は、全部で 60名くらいの人が参加されていた。
結構様々な業種の人、年齢層の人が参加している。

第一部の講演でも、第二部の交流会でも、日頃参加するソフトウェア開発技術系のセミナーとは全然違う刺激を受けた。

今後も、時々こうして様々な人の話を聴いて、脳の色んな部分をつなげ、視点を広げるようにしたい。
良いアイディアは、狭い範囲のものの組み合わせからは出にくいからだ。