翔ソフトウェア (Sho's) Fujiwo の日記

INETA Japan リ ーダーズミーティング に出席。

小田急サザンタワーのマイクロソフト 本社 (新宿オフィス) へ。

内容は，

• 活動報告
• 『Tech・Ed 2004』のイベントについて
• .NET 本について

等。

初参加で初対面の人だらけ．取り敢えず名刺交換。

Tech・Ed 2004 Yokohama に参加予定 (9/7～10)．

目的は，

• .NET 2.0 の知識
• Visual Studio 2005 のアジャイル関連の新機能の知識
• エンタープライズ アプリケーション パターンの知識
• INETA Japan 主宰のコミュニティ イベントへの参加

• INETA Japan Events!「アジャイル開発ライブ」 打ち合わせ
• MVP/INETA Japan Party + Hard Rock Cafe で二次会

• セッション
• INETA Japan Events!「アジャイル開発ライブ」 打ち合わせ
• Tech・Ed & MSDN 10th Anniversary Party

• セッション
• INETA Japan Events!「アジャイル開発ライブ」
• INETA Japan リーダーズ ミーティング
• INETA Japan 打ち上げ+二次会

四日間に渡った "Tech Ed 2004 Yokohama" から、新幹線と北陸本線で夜中に帰って来た。ひんやりとした夜風に吹かれながら帰り道を歩いた。虫の声しか聞こえない。こっちはなんて静かなんだろうと思った。

今回は、なんと言っても「アジャイル開発ライブ!」に参加したのが、一番の体験だった。

INETA Japan の人達やその他多くの技術者の人と毎晩のように飲んだり、昔の同僚とばったり会って久々に昼食を共にしたり、NIFTY のフォーラムで以前よくお話をした ひどり さん と初対面したり、同じくNIFTY のフォーラムや XP祭り2002 でお話した επιστημη さんに STL.NET のお話を伺ったり、コミュニケーションが沢山とれた。

# いずれレポートを書きたい。

今更ながら、Tech・Ed 2004 Yokohama の参加レポートを書いてみた。

Tech・Ed 2004 Yokohama 参加レポート

参加直後は、なんだか慌ただしくてレポートを書く気にならなかったが、昨日漸く社内報告会をおこなったので、そのついでに書いた。

# ちなみに現在社内では C# + ASP.NET の研修を実施中である。
# 今日は、研修用に以下の本を買った。

「ASP.NET＋SQL Server ゼロからはじめるWebアプリケーション」

【.NET】こんな.NETはいやだ

「『こんな .NET はいやだ』と思うものを自由にあげていくテスト。」

VB.NET JAPAN TOUR と INETA Japan リーダーズ ミーティングに参加。
http://www.ineta.jp/activity/calender/

会場は、マイクロソフト株式会社 笹塚 NA オフィス。

VB.NET JAPAN TOUR では、実際に VB の開発をしているジョーさんとアマンダさんから最新の VB の情報を二時間半に渡ってお話頂いた。

○ 内容

・VB 2003
・Visual Basic Power Pack
・Visual Basic .NET Resource Kit
・Tablet PC
・Vusial Studio Tools for Office
・.NET Compact Framework
・VB 2005
ClickOnce、My クラス、Edit&Continue 等
・Q&A

○ お土産

・Net Compact Framework Guide (Pocket Reference (O'Reilly))
・Visual Basic .NET Resource Kit CD
・Microsoft Mobile DevCon 2004 Conference DVD
・VB.NET World Tour Tシャツ

ジョーさんもアマンダさんも笑顔が魅力的な方だった。
通常の講演と異なり、気軽に随時質問も O.K. とのこと。講演者との距離が近い感じで、リラックスして聴けた。

私は VB でなく C# を主に使っているが、今の仕事で役に立つ知識が結構得られた。来週にでも調査してみたいことが幾つか。

※ 通訳付き、軽食と飲み物付きだった。

その後、INETA Japan リーダーズ ミーティングは一時間程度。
主に、INETAJ の今後について話し合われた。

終了後は、新宿で飲み会 (一次会・二次会)。
INETA 参加者の方達と五名で。
楽しいお話が沢山聞けて、とてもおいしいお酒だった。
少し焼酎を飲みすぎ。

Microsoft Tech・Ed 2004 Yokohama の 「Post Conference DVD」が送られてきた。

内容は、

• 「Post Conference DVD」 4枚
  Learning Day や 基調講演、テクニカル セッション等の 映像 (Windows Media) や資料 (Power Point)
• 「Visual Studio 2005 Beta 1 Refresh with Visual Studio 2005 Team System (英語版)」
• 「SQL Server 2005 Beta 2」と「SQL Server 2005 Beta 2 ハンズ オン ラボ DVD」

Visual Studio 2005 Team System は楽しみにしていたもの。
早速個人的にも仕事上も評価して行きたい。

また、参加できなかったセッションについてもこれで内容を把握することができる。

今日から、.NET/C# の社内研修を始めた。

ASP.NET 研修は、ずっと前から続行中だが、今度のは、Windows フォーム中心。
C++/C# での Windows 上での CAD の作り方の研修も数回実施。

自分の学習の方が全然進まない。
読みたい本もあるが、それより、もっとプログラミングを試したい気分。

今度、.NET Windows フォーム用のフレームワークと、その上にのる CAD のフレームワークのモデリング&実装をしてみたい。これはいずれにしても一度試す必要がある。
他にも .NET 上で実装を試したいものが幾つかある。開発用のツールとある種の ASP.NET アプリケーション。

近年マイクロソフトが力を入れているらしいパターン関連の頁は、今後益々要チェックのようだ。

• Microsoft patterns & practices (英語)
• Microsoft patterns & practices (日本語)

日本語の書籍も今月頭に発売になっている。

• 「Microsoft .NETによるエンタープライズ ソリューション パターン」
• 「.NETのアプリケーションアーキテクチャ アプリケーションとサービスの設計」

最近 ASP.NET の社内研修をやっているのだが、見ていると、或る程度 ASP.NET が判ってきて実用的なプログラムを書こうとしたときに、よく戸惑うのが、次のような点らしい。度々質問を受けた。

• 「ページのクラスとデータに関連の強い部分のクラスが入り乱れてしまうのだけど、それぞれどのように作っていったらいいの?」
• 「ページが沢山になったときに共通の処理をどこかに纏めたいのだけど、どうするのが普通?」
• 「ページ遷移が複雑になったときに、ソースが汚くなるのだけれど、何か良い方法はないかしら?」

ASP.NET でアプリケーションを書き進めていくと、上のようなことが解決できず、直ぐにソースがぐちゃぐちゃになってしまう、と言うのだ。

そういう人には、先の Microsoft patterns & practices から、先ず以下を試してみるように言ってみる。

• ASP.NET でのモデル ビュー コントローラの実装
• ASP.NET でのページ コントローラの実装

かなり手取り足取り説明してあるので、パターンに不案内な人にも分かりやすい。
また、テストのしやすさについても言及されているのが良いと思う (*1)。

後は追加で「『3 層分散』周辺は読んどいてね」とか、Singleton パターンくらいなら知っているという人には「『C# でのシングルトンの実装』が面白いよ」とか。
とにかく、効果が実感しやすそうなところから紹介していく。

この辺に少しずつ慣れていって、それから少しずつ、ドメイン モデルを作るべきかどうかや、ユーザー インタフェイスのテスト方法などについても考えていったら良いと思う。
そして、色々とパターンを試していく中で、プログラムの複雑さをどこにどんな風に吸収させていけば良いのか、そのコツを帰納的に体得していくのが良い。
パターンは教育ツールとしても強力なのだ。

(*1) これからは、デザイン パターンやアーキテクチャ パターンの記述のテンプレートに「テストのしやすさ」という項も追加するのが良いのではないだろうか。
パターンを適用することでどう設計が良くなるのかを言うのに、「テストがやりやすくなる」というのは判りやすい指標になると思う。

2004 Japan Community Open Day に参加予定。

沢山のワークショップが行われる。
Visual Studio 2005 Team System 関連のワークショップへの参加を希望した。

# 翌日は、INETA Japan のリーダーズ ミーティングに出席予定。

INETA Japan の関連で上記二つのイベントに参加してきた。

・両方の会場となった小田急サザンタワー

■ 12/18(土)

この日は、『2004 Japan Community Open Day』に参加。

・Community Open Day の様子

1. Visual Studio 2005 Team System を用いたアジャイル開発と手法
2. Visual Studio 2005 Team System Genera

の二つのワークショップに参加した。
Team System について、無責任に言いたいことを沢山言ってしまった。やれ導入しづらいだの、やれ高すぎるだの。
MS の人は熱心に聴いてくださったが、果たしてフィードバックになっただろうか。

その後、中華レストランで懇親会。
INETA の皆さんや MVP の方々、MS の方々など、色々な人とお話をさせて頂いた。
# 途中「○×ゲーム」があったが、商品ゲットならず。

そして二次会。
小井土 さん、福井 さん、中西 さんとご一緒させていただいた。
レゴの話などで盛り上がった。

コミュニティ関連の飲み会でいつも感じることだが、こういう素敵な方達と自分が一緒にいる状況というのは、五年前の自分には想像することもできなかった。
コミュニティならではの体験だと思う。

その後、12時過ぎにホテルにチェックイン。
ジャグリングの練習をした (謎)。

■ 12/19(日)

翌日は、『INETA Japan リーダーズ ミーティング』に出席。

帰りはPAPA'n VB の杉下 さんとたまたま飛行機が同じだったため、新宿～福井県丸岡町まで、話をしながら帰ってきた。
バスで帰る予定のところ、車で送っていただいた。
杉下 さんに感謝。

今回やっと羽田空港第二ターミナルを初利用。

・羽田空港第二ターミナル

楽しみにしていた 中西 さん の記事が @IT に載った。

• 連載 .NETで始めるデザインパターン 第1回 .NET開発におけるデザインパターンの有用性

私の偏見かも知れないが、.NET 開発者は、Java の人たちと比較して、オブジェクト指向だのデザインパターンだのに慣れていないような気がする。

だから、今回のような .NET 開発者向けの記事は、これからとても重要だ。

これから .NET 開発者の前には、テスティング フレームワークだとかリファクタリングだとかエンタープライズ パターンだとか DI (DependencyInjection) コンテナだとかアスペクト指向だとか、Java の人たちが取り組んできた様々な技術の可能性が待っている。
そしてこれらは、オブジェクト指向やパターン技術に関する知識を前提としているのだ。

ところで、中西さんは、ドットネッターでアジャイラーで TDD Player (謎) だ。
なので、デザインパターンの有用性を .NET 開発者に教えるのにもなんだかとてもアジャイルな感じだ。

これまでのデザインパターンの解説に、次のような言葉が使ってあるものがあっただろうか。

• 「モチベーション指数」
• 「ホワイト・ボードにクラス図」
• 「NUnit用テスト・コードを記述してみよう」

例題も、HowMuchGreenbarLover メソッドだとか、HowHappy メソッドだとか。
福井 さん も書いてたが、とても中西さんらしい。

※ この記事は、Ichikawa さん のところでも紹介されている。

さて、今回の記事では、次のような問いに答えている。

問い: 「デザインパターン? 何それ? 何が良いの? .NET な我々にメリットあるの?」

でこれに関する有り勝ちな答え:

1. 「デザインパターンというのは、こうこうこういうものだ」
2. 「例えば、State パターンというのがあって、それはこういうもので･･･」
3. 「使い方は、こんな感じ」
4. 「VB.NET や C# でサンプル コードを書いてみると、こんな感じだよ」
5. 「ねぇ、わかった? 良さそうでしょ。使ってみてよ」

これは、演繹的な説明だが、なんだかウォーターフォールな感じだ。
「うーん、どういうものかはなんとなく判ったけど… まあいいや、また今度改めて勉強するよ」
とか言われてしまいそうだ。
# 私経験有りますから!! 残念!!! 切腹!

で、中西 さん の答えは一味違う。少し真似してみるとこんな感じだろうか。

中西さん風の答え:

1. 「例えば、VB.NET や C# でこんなコードがあるとするやん」
2. 「ありがちなコードやけど、これってどうなんかなー 自分どう思う?」
3. 「こんな風にしてみたらどうかなー」
4. 「な? 自分知ってるやろ? ポリモーフィズム。どう、これ」
5. 「これが State パターンや。で、今やったのがリファクタリング」
6. 「な? 今度から State パターンやらいうたら、こういうのを指すんやで」

「デザインパターン23個覚えたぞ。さあ何かに役立てよう」でなくて、リファクタリングの結果として、使うべきところに使う分だけのデザインパターン。
こういきたいものだ。

さあ、今後の連載にも期待だ。

デブサミで INETA Japan として以下をやります。
# 私は C# 側。
是非ふるってご参加ください。

関連リンク:

• INETA Japan : Event Calender


• AI-Light ― 掲示板 ― Developers Summit 2005（デブサミ2005）2005年2月3日(木)・4日(金)


• ぺがらぼ Blog ― [.NET] デブサミ2005


• @SAKURA Drops ― デブサミ2005はじめます★


• 翔ソフトウェア (Sho's) Fujiwo の日記 ― デブサミ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♯ の良い点・悪い点

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

例．

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();

    }

}

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

    class Sub : Super
    {
    }

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

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

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

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

    Super  s = new Super();

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

    s.Foo();

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

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

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

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

ごめんよ。

■ VC++ から来た人向けの資料

VC++ でウィンドウズ アプリケーションを書いていた人が、.NET 開発を始めるときに重宝するドキュメント。
※ 特に C + Win32API で書いてた人向け

• MSDN ― Microsoft Win32 と Microsoft .NET Framework API との対応
• MSDN ― ランタイム ルーチンおよび同等の .NET Framework 関数
• MSDN ― アンマネージ コードとの相互運用
• PINVOKE.NET

■ Visual Studio の HTML ヘルプ作成機能

C# では XML コメントを書くことで、HTML ヘルプをコードから自動生成することが出来る。
※ 尚、VB.NET では次期バージョン (2005) から、この機能に対応する。

• MSDN ― コード コメント Web レポート
• @IT ― Visual C# .NETでAPIリファレンスを作る
  • 前編
  • 後編

Visual Studio では、メニューから「Web ページのビルド コメント」を選ぶことで、コードの XML コメントからHTML ヘルプ作られる。

但し、この機能で作られた HTML ヘルプは、Windows XP SP2では見ることができない。

参考:

• 中の技術日誌 ― Visual Studio 2003+Windows XP SP2でWebページのビルドコメントが閲覧できない

■ NDoc の紹介

"NDoc" というツールを使うことで、MSDN のような HTMLヘルプ形式 (.chm ファイル) を含む様々なヘルプ形式を出力できる。
※ プロジェクトのプロパティで「XML ドキュメント ファイル」を指定しておく必要がある。

• SourceForge.net ― NDoc Online (英語)
• SourceForge.jp ― NDOC日本語版
• SourceForge.jp ― NDoc Online -日本語版-

NDoc の使い方はこちらを参考に。

• @IT ― C#でMSDNライブラリ風のAPIリファレンスを作成するには?

■ .NET 開発における名前付けのガイドライン

.NET 開発でクラス名や変数名などのシンボル名を付けるときのガイドライン。

• MSDN ― 名前付けのガイドライン
• MSDN ― コーディング技法

参考:

• C#コーディング標準 (by 河端 善博 氏)
• VB.NET コーディング標準 (by 中西 庸文 氏)

■ .NET 開発用ツール

.NET 開発用の様々なツールが存在している。
※ 森屋 英治 氏 により N* (エヌアスタ) と命名されている。

• NWiki
  中西 庸文 氏 により、.NET 開発のためのツールが紹介されている
• SharpToolbox (英語)
  .NET 開発のためのツールがとても沢山紹介されている
• Open Source Software in C# (英語)
  こちらは開発用ツールも含む、C# で書かれたオープン ソースのソフトウェアが沢山紹介されている

■ ASP.NET Web アプリケーションの設計パターン

ASP.NET でアプリケーションを作っていく場合、よく入門書などにあるように、Visual Studio 上、でコントロールやデータ クラスをドラッグ&ドロップで作っていくと、

• 「ページ = クラス」
• データに関する処理は、各クラスに分散
• 頁遷移に関する処理も各クラス (= 各ページ) に分散
• UI に関する処理とデータに関する処理とロジックが混在

となり、或る程度以上の規模のアプリケーションでは、複雑なコードとなることが多い。

そのような場合にどのように設計を行うのが良いか。その代表的な設計のパターンを幾つか紹介する。

• MSDN ― 多階層分散
• MSDN ― 3 層分散
• MSDN ― ASP.NET でのモデル ビュー コントローラの実装
• MSDN ― ASP.NET でのページ コントローラの実装

参考:

• patterns & practices 日本語サイト


• patterns & practices Enterprise Library

参考書籍:

• 『Microsoft.NETによるエンタープライズソリューションパターン』


• 『.NETのアプリケーションアーキテクチャ―アプリケーションとサービスの設計』


• 『.NETエンタープライズWebアプリケーション開発技術大全 (Vol.1～Vol.5)』
  
  
  
  
  • Vol.1
  
  
  • Vol.2
  
  
  • Vol.3
  
  
  • Vol.4
  
  
  • Vol.5
  
  
  
  
• 『エンタープライズ アプリケーションアーキテクチャパターン』

■ Web アプリケーションにおける 危険な HTML の入力

先ず Web アプリケーション一般における、危険な HTML の入力とはどのようなものか、以下を参照のこと。

• @IT ― Webアプリケーションにセキュリティホールを作らないための クロスサイトスクリプティング対策の基本
  • 前編: クロスサイトスクリプティング脆弱性とは?
  • 後編: XSSを防ぐために不可欠なサニタイジング (無害化)

■ ASP.NET での対策

今の (.NET Framework 1.1 以降の) ASP.NET では、デフォルトでは、タグ入りの入力などは、自動でチェックされ、危険なリクエストを受けると例外がスローされる。
これにより、アプリケーションがサニタイズを怠った場合でも、最低限のセキュリティ対策はとられることになる。

これをオフにするにし、アプリケーション側でサニタイズを行う場合には、

Web.config で、

のようにする。

※ 参照:

• MSDN ― @ Page ― ValidateRequest

アプリケーション側で HTML サニタイズを行うには、以下のメソッドが便利。

• MSDN ― HttpUtility.HtmlEncode メソッド (System.Web 名前空間)

データバインド時に使う場合はこんな感じ:

<%# HttpUtility.HtmlEncode(DataBinder.Eval(Container, "XXXXX").ToString()) %>

※ 関連サイト:

• @IT ― セキュアなWebサイトを運営するための Webアプリケーションに潜むセキュリティホール
• MSDN ― セキュリティ保護された ASP.NET ページとコントロールを構築する

■ Web アプリケーション一般における、 SQL インジェクションの脅威

先ず Web アプリケーション一般における、 SQL インジェクションの脅威とはどのようなものか、以下を参照のこと。

• @IT ― セキュアなWebサイトを運営するための Webアプリケーションに潜むセキュリティホール ― 第2回 顧客データがすべて盗まれる?! ～OSやデータベースへの攻撃～

■ .NET の Web アプリケーションにおける対策

対策としては以下を参照:

• MSDN ― Web アプリケーション セキュリティ強化: 脅威とその対策 ― セキュリティ保護されたデータ アクセスを構築する

• @IT ― セキュアなWebサイトを運営するための Webアプリケーションに潜むセキュリティホール
• MSDN ― セキュリティ保護された ASP.NET