SQL Server 2005 : Reporting Services によるレポーティング アプリケーションの構築
[T2-374]
一番見やすいデモでした。途中トラブルがあったにもかかわらず、落ち着いてやり直せばすぐに立て直せると言うところまで見せてもらいました。
それにしても、ちょっと安定していないなと言う印象は免れませんが。
Accessレポートのインポートができるということで、そこに大きな期待をしたのですが、今回の範囲ではデモはありませんでした。
ただ、Excel出力やPDF生成もあり、既存の帳票ツールを吹き飛ばすパワーを感じました。あとは、どこまで作りこみができるかと言うところだと思います。
最近は音楽青年なので、今日は半日息抜きで「スウィングガールズ」を見てきました。
で、中に出てきた言葉が「裏を打てばジャズになる」と。いいなあ、こういうシンプルな定義。
公式サイトを見ると色々なイベントもやられているようで、行きたくなってしまいます。
マイクロソフトのコンポーネント技術はどう変わってきたか？
[L4-S001]
IoCの話の中で、イベントドリブンという言葉が出てきました。
この言葉で、ちょっとIoCということの意味が分かったような気がしました。自分が書くアプリからライブラリを呼ぶのに対して、イベントの部分だけ自分で書く、確かに制御が反転している！！・・・単純すぎますか？
アスペクト指向についても説明がありましたが、まだ理解し切れません。修行します。
[T1-401]
まず、アジェンダが、単なるリストではなく、階段状の図になっていました。
アジェンダという、何よりも即時的な理解が求められる部分を図式化する、というのはとてもよい案なのではないかと思いました。
内容の中で、よいと思った言葉が、「意思決定ポイントの再利用」という言葉です。
「知識の再利用＞コードの再利用」であるが、「コードでは開発者の”意図”をほとんど伝えられない」ので、それを示すためにパターンを活用し、再利用性を向上させる、という話です。
確かに、コードさえ見れば（できたらテスト結果もあれば）「何をしているか」は分かるのですが、「何をしたかったか」を説明できれば修正しなくてもよい、場合によっては、やってはいけない修正を避けられる、ということがありますね。大切なことだと思います。
しばらく、Tech・Edの情報整理をしたいと思います。
まず最初は、一番最後のセッションからのネタになりますが、プログラミングレシピという言葉について。
Architect Salon
http://www.event-registration.jp/events/te04/sp_architectSalon.htm
このセッションは、上記ページのタイトルとは関係なく、SOA・IOC等の技術動向に対する3人のスタンスや、技術者としての心構え的なことについて語ってもらう、というものでした。
色々とおもしろい点はあったので、また別途整理しておくかもしれませんが、一つ引っかかりを持った言葉がレシピという言葉でした。
米持さんが、料理はプロジェクト管理だという話をしている中で、そう言えばプログラミングについてもレシピと言うのがあったらよいですね、料理のレシピでは材料から完成品イメージとカロリー表示までされているように、このようなコンポーネントを組み合わせるとこのような性能のアプリケーションができます、というものができているとよいですね、と言うような話が出て、3人とも合意、という流れでした。
ちょっと冗談を言っているような場面でしたので、もちろん本気にするところではないのですが、このような言葉は便利に使われやすいので、自分的に整理しておきたいと思います。
何が問題かというと、アプリケーションは料理と違ってコピーができます。あるレシピに従ってアプリケーションができた場合、次もそのレシピで同じアプリケーションを作ると言うことはあり得ないのではないでしょうか？逆に言うと、レシピができているアプリケーションは（工数的には）「タダ」ではないでしょうか？
・・・という話があり得ると思います。
これに対する一つの考え方として、レシピの視点という話があります。料理という完成品から見たレシピではなく、材料・素材から見たレシピだとすると、「このコンポーネントを使ってこのようなプログラミングをすると、このようなアプリを作ることができ、このような性能を期待できる」というものになり、これであればきっと皆さん意義に合意だろうと思います。
しかし、さらに考えたいのですが、レシピを作りたいようなアプリケーションって、何でしょう？例えばMSOfficeにレシピがあったとしてそれを使ってOfficeを作ろうとする人がいるでしょうか？そう言うものが欲しいのではないと思いますく。日々似て非なるアプリを作る中で、共通する部分については同じように作りたい、という気持ちがあるからレシピという考えが出るのだと思います。なぜ同じものではなく、似て非なるものを提供するかというと、ユーザの要求に応えることが「商売」だからです。もちろん、コストとの兼ね合いですから、なるべく同じものを提供するように話すことが多いですが、それでも同じものにはならないですし、同じものを提供できるようなパッケージ製品についてレシピはいらないのです。
では、同じものを作ることはないのだからレシピなんていらないのでは、と言うことにもなるのですが、あとはレシピと料理人のレベルと言うことになります。酢豚のレシピを見て、酢を黒酢に変えた場合の材料費・調理時間・カロリー等が見て取れれば、普通の酢豚のレシピもやはりあった方がうれしいということです。
まあ、マイクロソフトもレシピというのはおもしろいと思っているのでしょうかね。
http://www.microsoft.com/japan/users/recipe/
いきなり、とりとめもない話から始めてしまいましたが、もう少しとりとめもない話をこれからしばらく続けたいと思います。
SQL Server ユーザーグループ経由で、INETAJapanさんよりTech・Ed 2004 Yokohamaの招待状を頂きました。
初参加なので楽しみです。
最近、泣くほど忙しく、勉強の時間がとれていないので、いい時間ができたなと思います。とは言っても、夏休みを使っていくんですけどね。
SQL Server ユーザーグループ
一五一会音来、買ってしまいました。
http://www.yamano-music.com/docs/hard/ginza4/fg04.html
うれしいな、弾く時間ないけど。
ちょっとだけやってみましたが、ギターって思ったよりも難しいです。
でも、なんか楽しい！
買ってみようと思います。
らくらく合格 うかるぞ社労士〈2004年版〉
秋保 雅男 ， 松本 幹夫
おすすめ平均社労士受験のバイブル
Amazonで詳しく見る
広島出張のついでに、以前から行きたいと思っていた宮島に行ってきました。
まずは市内から広電で宮島口まで。1時間弱です。広島は生まれて3回目で、原爆ドームは2回目、最初のイメージは思ったより小さいな、という感想が先行してしまったのですが、今日電車から見たら素直に悲惨さを感じられました。
宮島口に着いて、電車をパチリ。このタイプのきれいな電車が結構走っていました。古くさいイメージだったので、ちょっとした驚きだったのです。駅を出たらもみじビルがお迎えでした。
宮島口からフェリーで宮島に渡ります。JRフェリーだと大鳥居の近くまで行ってくれるということでそちらへ。宮島ってこんなに大きかったんですね。
着いたら早速厳島神社へ向かいます。修学旅行生がいっぱい！
厳島神社は、満潮時の方が風情がありそうな気がしますが、今日はちょうど干潮だったようで、神社の方にはほとんど水がなく、潮干狩りをしている人もいました（禁止という立て札がありましたが）。
ただ、そうは言っても、世界遺産！だから、と言うことではなく、やはりおもしろいと思いました。こんな場所に神社を造り、海の中に大鳥居を作るというコンセプトがすごいと思います。昔は大鳥居をくぐって船が入ってきていたということですが（よそのツアーガイドさんの解説を盗み聞き）、想像するだけでおもしろそうだと思います。
帰り道の参道は、寄り道を楽しみながら。
まずは、焼きたてもみじまんじゅう。フルーツ味は温かいのはないということで、残念。温かいのは抹茶味を食べましたが、温かいのはおいしいですね。
次は、やはり焼きガキ。行きに値段チェックしながら歩いていたので、おそらく最安値の2個400円のお店で食べました。本当に大振りでプリプリでおいしかったです。ただ、ちょっとだけ磯の香りが強過ぎかも。そういうのが好きでないとダメな人もいるかもしれないですね。ビールを飲みながら食べたかったですが、この時点では若干二日酔い気味だったのでやめときました。
そんなこんなで、割とあっさり旅でしたが、気分的には満足です。
（締めの昼ご飯はたこ天むす）
お土産：
春もみじ（生チーズもみじまんじゅう）：5個入り550円×2個
川通り餅：1260円
旅先でのロマンス：プライスレス（いや、なかったんですけど）
参考：（Martin Fowler’s Bliki in Japaneseより）
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?HarvestedFramework
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FrameworkBuilding
Fowlerさん、さすがいい言葉持っていますね。
昨日も、朝まで飲みながら話していた内容なのですが・・・
いえ、以下はフィクションです・・・（涙）
ある会社では、フレームワークを作りました。
Fowlerさんの言葉で言うとFoundationFrameworkということになります。
まあ、そのこと自体はよいとします。これまで標準化をしてこようとして、なかなかうまくいかなかったのが、これを土台としてちょっとでも進んでくれればよいと思うわけです。
しかし、完璧なフレームワークなど、そう簡単には作れません。だから、日々改善が必要なわけです。そして、本当に改善ができるのは実際にそれを利用している人たちです。
ところが、このフレームワークは実際にフル活用される前に販売され始めました。当社から発注するアプリケーションはこのフレームワークを使用して作らなければなりませんから、協力会社には順調に売れているようです。そして、1年もないサイクルでバージョンアップをしていきました。
そうなるとこれを使って作る方は訳が分からなくなっていきます。フレームワークは売り物ですから、気軽に修正するわけにはいきません。改善要望を出しながらも、対応されるまでは変な工夫をしながら無理矢理にでもそれを使います。
ある程度再利用可能なシステムができても、新しいフレームワークができるとそれに対応させてテストをし直します。他人のフレームワークなら、「このシステムはバージョンxを前提としています」でよいと思いますが、自社のフレームワークですから、古いバージョンを使うわけにはいきません。
この話に対して、私は、フレームワークを売るという場合は、残りかすを売ればよいのではないかと思っていました。フレームワーク使う・作る目的は開発をうまく進めると言うことです。日々の開発の中で再利用できるところを抽出・整理していくことによりフレームワークと呼べるものができてくる。うまくいくものができたら、それを売って儲けてもよいかもしれない。ある時点のものを売りながら、自分たちは日々の開発の中で改善を重ね、よりよいものにしながら使っていけば、他社より有利に開発を進められます。
残りかすというのは言葉が悪いかなと思っていたら、FowlerさんはHarvestedFrameworkという言葉を使っていたというわけです。結実型というのが訳としては気に入りました。「残りかすを売ればよいのではないですか」と言っても聞き入れてもらえないような気がしますが、「フレームワークも充実してきたので、これからは結実型のフレームワークを目指していきませんか！」という話なら聞いてもらえるような気もします。がんばろ。