Programmers Office

[T1-412] いつまで生き残るか分かりませんが、そうは言っても目をつぶるわけにはいかないスマートクライアントについて、まず設計編。 アプリケーションアーキテクチャガイドというものがあり http://msdn.microsoft.com/library/default.asp?url=https://jqinglong.github.io/programmers-office/library/en-us/dnpag/html/SCAG.asp これをベースとした話でした。 ガイドには ・データハンドリング ・接続方法の選択・断続的な接続のサポート ・配置とアップデート ・性能 ・セキュリティ上の考慮 といった点について解説されているようです。 特にデータキャッシングや断続的な接続のサポートについて解説が多めになっていたように思います。

SQL Server 2005 : SQLCLR – .NET Framework ベースのデータベースプログラミング [T2-367] 今回の一つの目玉と思われる、SQL Server 2005のSQLCLRです。 SQLCLRというのは、.NET言語で作ったアセンブリをT-SQLから呼び出せるという仕組みです。 ・一貫したプログラミングモデルを採用できる ・T-SQLでは不可能・難しい操作が可能になる ・パフォーマンス向上 等のメリットが発生します。 そして、VisualStudio2005でデータベースプロジェクトとして環境が統合されることにより、配置やデバッグが容易になり、開発がしやすくなります。 これも、大いに期待できそうです。 なお、ちょっと本題と外れますが、デモの中で紹介されていましたが、プロファイラにパフォーマンスデータを読み込ませ、どのステートメントで負荷がかかっているか、時間がかかっているかが分かるようになります。パフォーマンス調査もやりやすくなりそうです。

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で詳しく見る