基本的に何かの議論をする場合には、その当事者同士がたとえそのときだけにせよ同じ立ち位置にいることが理想です。それが無理だとしても、少なくとも同じ黒板に向かって議論をする必要があるわけですが、オンライン会議室やMLだとお互いに己の意見だけが書かれた黒板だけを並べて、全然議論になっていない事がよくあります。
まぁ、当事者たちは何か結論を得たいわけでもないようなので、それはそれでかまわないのかもしれないのですが、オンライン／オフライン問わず最近こういう光景をよく目にするなぁと思うしだいです。
気をつけなければいけないのは、開発の現場でも同様の空気が流れるときがあり、これは当事者間での技術力にギャップが大きい場合や、当事者の視野の大／小の違いにより起こりやすいような気がします。正直特効薬がない場合が多いのですが、「あんたそれは違う」という一言が状況を変えることがあります。ほかには「取りあえず黙ってくれ」とか。取りあえず憎まれ役になっても物事をまとめてプロジェクトを進めることが必要なときもありますよ。
と言うようなことを某ニュースサイトにある掲示板でのUMLへの議論を見ていて思ったしだいです。

Martin Fowler’s Bliki in Japanese – PatternShare
このBlikiのエントリでMicrosoftがパターンに関するコミュニティサイトを以下に立ち上げた事が紹介されています。
PatternShare Community
http://patternshare.org/default.aspx/Home.HomePage

The PatternShare community site brings together software patterns from different authors in one place to show relationships between existing patterns and to encourage you to contribute new ones. By combining our efforts, the patterns community can increase pattern usage and better meet the needs of developers and architects who use patterns.

様々な著者のソフトウェアパターンを集めて、閲覧可能にすることともともに、それらについての議論を行う場を提供するのが目的のようです。
まだ、dotNET開発ではパターンが浸透していないような気がしますし、日本語で、このような場が出来ると各開発者にとってのパターンの学習に弾みがつきそうなんですが。

『プログラマの数学』 – 結城浩著
目次抜粋

第1章 ゼロの物語 ―― 「ない」ものが「ある」ことの意味
第2章 論理 ―― trueとfalseの2分割
第3章 剰余 ―― 周期性とグループ分け
第4章 数学的帰納法 ―― 無数のドミノを倒すには
第5章 順列・組み合わせ ―― 数えないための法則
第6章 再帰 ―― 自分で自分を定義する
第7章 指数的な爆発 ―― 困難な問題との戦い
第8章 計算不可能な問題 ―― 数えられない数、プログラムできないプログラム
第9章 プログラマの数学とは ―― まとめにかえて

数学的な考え方は大事です。
効率的に克つ実行効率の高いコードを書くためには数学の知識が必要になります。また、このようなときに必要になる数学は、中学や高校で僕らが学ぶ19世紀以前の数学ではなく、20世紀以降に登場した比較的新しい数学です。
ですので、復習と言うよりも新しいことを学ぶつもりでこのような本を読んでみると良いかもしれません。
と言っても3月発売。

続きを読む 『プログラマの数学』 →

サン、大規模システム開発向けJava IDEの新版
年間55万で1000人使い放題はかなりお得ですね。まぁEclipseが「タダ」な状況においては、値段を下げないと太刀打ちできないのかもしれませんし、サンがアプリケーションサーバも含めてシェアを取っていくためにはこれくらいの戦略的な値付けも必要なんでしょうね。
永続ライセンスの方は1ライセンス28万なので、こちらの方は他社とあまり変わりません。ｍｓｄｎもサブスクリプション方式でお金を払いますが、サブスクリプションが切れたとしても、それまでに入手したソフトウェアのライセンスは同一権利で残るはずなので、ライセンスとしては永続ライセンスになるはずで、そう考えると、何から何までついてくるmsdnはやっぱりお買い得ですねー。(さすがにゲームはつきませんが)

オライリージャパンが今年で創立10周年という事で制作された今年のカレンダーが頼んだ本と一緒に送られてきた。
取りあえず先着順のプレゼントらしいので、ほしい方は早めにオライリージャパンのページから書籍を注文しましょう。
中身はスタッフの手作り感満載ですが、MSアーキテクトの萩原氏、ルビーのまつもとひろゆき氏等のコメントも寄せられています。

続きを読む オライリーのカレンダ →

＠ＩＴ：安藤幸央のランダウン 第26回
この記事のようにEclipseもアプリケーションプラットフォーム化されていますが、VS2005のIDEも今後登場するMSのサーバー製品の管理ツールのプラットフォームとなっていくようだ。現状でもSQL 2005のIDEとVS2005は同じプラットフォームを使用している。
今後はかつてX11でmotifがはたしたような形でこれらのアプリケーション構築用の環境が一般化してくるかもしれないと思う。

後藤弘茂のWeekly海外ニュース – アムダールの法則を巡るIntelとAMDの戦い
マイクロプロセッサに関するアムダールの法則については上のリンクを参照。
結局のところアムダールの法則を打破するのはプログラマである。
アムダールの法則を打破するとは、マルチプロセッサに対応した厄介で危なっかしい平行動作をするアプリケーションをいかにして生産性高く記述していくかということでしかない。
この厄介さを解消し、プログラムの生産性を向上させるには、Java VMや.NET CLIのような仮想実行環境が、今以上にこのプログラムの平行性を支援し、プログラマがマルチスレッドなプログラムを記述しやすくするという方法が一つ、もうひとつの方法としては、タスクの高度な平行実行を前提とするプログラミング言語を新たに構築する方法が考えられる。また、もちろんOSレベルでの積極的な支援も必要だ。（最近のLinuxやFreeBSDのタスクスケジューラーの変更はこのような情勢を踏まえてのことだ。）とは書いてみたものの、結局のところこれらの仮想実行環境やOSもプログラマが書くしかないのだ。
ということで、マイクロプロセッサがマルチコア化したとしてもその力を発揮させるにはプログラマが自身の技量を挙げていくしかないというわけで、プログラマにとってはマルチコア化は大きなデメリットなのかもしれないよ。
さてと、スレッドプログラミングの勉強でもしましょうか。（W

＠IT情報マネジメント：ペルソナとシナリオを用いたソフトウェア開発──実践編（後編） 1/2
後編登場。
複数のペルソナが必要なケースでは、思い切ってアプリケーションを分割するか、何らかの形でUIの分離が必要だと思ったり。実世界と同じく、システム化対象への関心がペルソナ毎に違うので、全く別の形のUI、機能が必要になるはず。それを無理に一つにまとめようとすると結局すべてのものにとって使いづらいものになってしまう。

sanonosa　システム管理コラム集: 伸びるエンジニアについて
大変興味深い記事だったので、煽り無しで考察してみます。
この記事の中で、著者は以下の三つの資質をあげています。
【条件１：自腹で技術書を買っていること】
【条件２：全体を理解しようとしていること】
【条件３：プロジェクトをたくさん経験していること】
先ず条件1ですが、これは自己への投資意欲がある、基本的に自分の仕事に対する興味、情熱があるということでしょう。わたしはこれらが自分の技術力を伸ばしていくためには必要最低限の資質であると考えています。後、学習という点では、出来れば自分の専門外の知識に対する欲求の持続やそれへの学習のサイクルが個々の中に出来ればよりよいと思います。悪い意味での専門バカにならないためにも、そうしておいた方が身のためです。
次に条件2ですが、全体を見渡すとしても全体の定義が難しいですね。Javaや.netではいったいどこまで確認していけばいいのか途方に暮れてしまいそうです。その時々で、全体を定義していく必要がありそうです。
ただ、何かのきっかけを元にその周辺についての理解を深めていくことは重要でしょう。
これ以上書くとトランスパーソナルの話を書き始めそうなので、ボロが出ないうちに止めておこう。
最後に条件3ですが、これはもうやっぱり学習を力に買えるには場数を踏むしかないわけで、致し方ないなぁ。とにかく書くしかない所はありますが、そのとき重要なことは間違った知識、方法で書かないようにすることだと思います。間違ったことを反芻しても仕方がないことなので。(あーいっぱい遠回りしたよ)そういう点では学習過程でよいメンター・本に出会うことは本当に重要だなぁ。
というわけで、以上を自分の戒めとして今年もがんばっていきたいと思います。

構造化設計技法でのローカル変数による外部へのデータ構造の隠蔽と言うことの延長に、オブジェクト指向のカプセル化があるわけですが、なんか頭の中でスコンとその関係が抜けてしまっている人がいるんですよね。要は何のためのカプセル化か理解が出来ていない人。
それをアホだ馬鹿だ言うのは簡単なんですが、何で抜けてしまうのかって言うのが見えてこないとその人に対してどう対処して良いか解らないんですよね。オブジェクト指向勉強すればそれ以前の知識はいらないとか、基礎知識という土台なんかいらないぐらいの勢いって言うのはどこから来てるんでしょう。日経ソフトウェアのせい？
自分自身が痛い目に何度もあっているのにねーとも、思うわけですよ。気付け、何度も言ってるだろと。
やはりアホだ、馬鹿だと矯正するしかないのかもなぁ。優しくメンタリングするほどおいらは人間が出来てないしなぁ。
というようなことをここ読んで思ってみたりして。