Announcing the 2005 Microsoft Professional Developers Conference
September 13 – 16, 2005
Pre-conferences September 11 and 12
Los Angeles Convention Center, Los Angeles, CA
なんと日本のTechEdの約1月後というタイミング。
いよいよLonghornベータか、Indigoのリリースって気もしますが、そこはPDCなので全く違う「何か」かもしれず。年を越して暖かくなった頃には何かしら聞こえてくることでしょう。
故に、本当にプログラマが活躍するのは、リファクタリングの終了後といえる。より正確にいえば、プログラマが活躍したいと思っているのに、それを阻むソース・コードの混迷を打ち払い、活躍の場を生み出すのがリファクタリングといえるだろう。もし、解決すべき問題を持ちながら手に負えないソース・コードに困っているのなら、リファクタリングを試してみてはいかがだろうか?
コピペ厨が書き散らかしたコードの重複部を関数化していく空しい作業をリファクタリングと呼ぶかどうか悩みます。たぶんよばないよな～。鬱。
Handbook of Software Architecture (Blog)
MicrosoftのDSLに対するBooch氏の反論。ちなみに今Booch氏はIBMのフェロー。
多くは中さんのBLOGに書いちゃったんでそちらを参照してください。私は意訳しすぎか。
まぁBooch氏にしてみれば、自分たちが努力してUMLという統一政権を作り連立政権を続けてきたのに、昔のこともよくわかっとらんどっかの野党の若造がDSLという内閣不信任案をたたきつけてきたようなもんで、面白くも無かろうというもの。
まぁマイクロソフトもよっぽどUMLが嫌いって言うか。何でも自分で作らないと気が済まないって言うか。
個人的には今までUMLに投資してきたものを失いたくないなぁという気持ちはあります。
【連載特集】Microsoftを追え！～第24回 “Form ”“COM ”“Strage ”――そして『Windows 2000』登場へ
新しいテクノロジーとしては、Windows DNAの3階層の拡張技術として、プレゼンテーション層の“Form+”、中間層の“COM+”、そして統合ストレージ層の“Strage+”といったアーキテクチャの概要が明らかにされた。
COM+以外は懐かしい名前が再び登場という感じですが、実際にはこれらの技術って復活してきてるんですよね。
たとえば”Forms+”ですが、これは実際にはAvaron, Xamlという形で再び登場してきますし、”Storage+”はLonghornではキャンセルとなったWinFSそのものでしょう。
という風にマイクロソフトの技術は突然一過性に登場してくるのではなくて、実際には長い時間かけて熟成されたり、少しずつ方向性を変えながら面々と続けられてきているものが多いです。
そういう点でリンクした連載のように過去を振り返ることが、未来を予測する有効な手段である場合もあります。
また、現状のWindowsはかつてマイクロソフトがCairoと呼ばれたOSで実現すると言っていたすべての内容が実現できているわけでもありません。やり残していることがあるのです。従ってこの先もWindowsはバージョンアップを繰り返していくことでしょう。
＃1999年頃のTechEDの資料をひっくり返してみるのもおもしろいかもしれませんね。
＃一度アップしましたが、一部修正しました。21:26
CodeToHTML作者のSantaMarutaさんよりソースコードを含むこれのダウンロードページを教えていただきました。以下のURLです。
CodeToHTML
http://santamartadotnet.hp.infoseek.co.jp/releases/freewares/codetohtml.html
ヤホーイ！ありがとうございます！
今VirtualPC上にVisual Basic 6.0の動作環境を構築中。来年でサポートは切れるとはいえ、仕事的には後数年は最前線で使いそうなのと、社内教育関係の資料の作成(社外での教育、資料の入手が困難になるので)が必要になりそうなのがその理由。
少々後ろ向きでやなんですけどね。
とりあえず、先ほど飛脚で到着したのでぱらぱらと読みました。
細かい比較はまだしていませんが、msdnでのコード標準とは大きく違っていないと思う。
この本自体は、表題通りコーディング標準と言うよりはルールブックといった内容。私が題名をつけるなら、「C# タコを普通にするための養成ギブス」といった感じでつけますね。ちゃんと言われた通り作られているかチェックできるようにFxCOPの使い方まで書かれてまつ。
巻末には「便利な」切り離せる一覧もあるよ！
一項目ごとに、なぜそうする必要があるかという点、制約、悪い例と良い例(リファクタリング前後)がつけられているので、とにかくこうしろという感じではないのでここは高ポイント。
中括弧の位置は完全なANSIスタイル(こだわるよ)。といっても特に言及はありません。これについてはマイナスポイントですかね。
結論としては総じて悪くなさそう。社内標準・プロジェクト標準で悩んでる方はとりあえず読んでみるとよし。
しかし、全ページオールカラーはすごい。(この出版社の場合デフォなのかもしれませんけど)
MSF Ver.4 Agileでは、ソフトウェアシステムの仕様決定にペルソナ・シナリオ法を使うようなので、アランクーパの著作、「コンピュータは難しすぎて使えない」を参考に、私が理解した範囲でごくごく簡単にまとめます。
要約: 辞書式インデックスから任意の数学的な組み合わせ要素を生成する簡潔なアルゴリズムを示し、このアルゴリズムがどのように開発スキルに有用であるかを説明します。サンプル プログラム ファイル内では実際のコメント行は英語で書かれていますが、この記事内では説明目的で日本語で書かれています。
この記事MSDNのRSSで突然入ってきました。表からどうたどり着けるのかは不明です。（W
記事は非常に珍しく数学（算法）の話ですね。
得てして数学嫌いな（いや、出来ない）私なんぞが小一日悩んじゃってることも、数学が得意の人にかかるとするすらっと数分でプログラム書いちゃったりして、数学って大事だなとそのときは思うのですが、かといって勉強するわけでもないんですけど。
でもこんな記事読むと、特に効率改善という点でやっぱり数学は大事なんだと思います。（でもきっと勉強はしない）
Team Developer デモ
このデモをごらんいただければ、VSTSの機能が、コードの品質管理をよりし易くしてくれることが確認できると思います。
しかしながら、リーダーやマネージャの人は気をつけないと、このようなツールがあるばかりにチームメンバが充分な設計をせず、コードをツールに流し、いわれるままに修正という作業ルーチンが出来てしまうといった、モラルハザードが起きてしまうことにもなりかねないので、ルール作りや、チームの雰囲気作りがより重要になります。
まぁこの手の機能、特にコードの静的分析ツールを、外注先のコードにかけると、会社ごとの実力の差が出るのでおもしろいですな。<悪魔。