ウィキペディアによると、解散したのではなく活動停止中だそうですが、・・・のWinkではなく、Tutorial and Presentation creation softwareの方のWink。
http://www.debugmode.com/wink/
ちょっとやった結果をビデオに残そうと思って、Winkを使ってみています。
が、意外と重いんですね。Winkを動かしながら、SQL Server Management StudioとMicrosoft Visual Studioの両方を使うのはなかなか厳しい。
できるビデオもうまく調整しないとポインタの動きがまだるっこしかったり、肝心なところが早すぎたり・・・慣れが必要ですな。
Microsoft Expression Web Designer CTPをインストールしてみました。
http://www.microsoft.com/products/expression/ja/default.mspx
できのよいHTMLエディタ、・・・以上のものを期待していたのですが、今のところはそんな感じでしょうか。
もちろん、aspxをVisualStudioに負けない機能で編集できるのはグッドです。
VisualStudioで作ったWebサイトをフォルダで指定して、一括で読み込むこともできます。
MSお得意のかっこいいテンプレートがあるのでは、というのが一番の期待だったのですが、それがないのがさびしいです。
まあ、しばらくできのよいHTMLエディタとして使いながら、何か面白いことがあるか見ていこうと思います。
やはり、一番の注目はInteractive Designer でしょうか。
なかなか触れるには勇気のいるエントリーですが（笑）、あえて行ってみる！
やっぱり変だよ日本のモティベーション
—
何をやるのか・何故やるのか、という動機付け（モティベーション）が明確だから、それを実行に移すためのやる気が湧いてくるわけです。逆に言えば、きちんと動機付けされていれば、やる気がなかろうが何だろうが「仕方ないなー」と思いながらでも、「やる」ことは出来るんですよ。そもそも、やる気があるからやるんじゃないんだよ。やるからやる気が出てくるの。
—
最近考えていたのが手戻りについて。
みんな手戻りを発生させたくない。なぜか。
後工程で手戻りが発生するほど対処コストが増加するから（そんなグラフ見たことありますよね）。
確かに電化製品や車などの「物」はそうなのでしょう。また、ソフトウェアも、コーディングのためにマシンを占有したり、コンパイルに何時間もかかったり（ってそういう時代を経験していませんが）、あるいは配布のためにあちこちをインストールして回らないといけなかったり（これは経験しました）という場合は、やはり成り立つでしょう。
しかし、現在はソフトウェアのその問題に対しては色々な対策が採られてきており、最初にグラフが作られた時とは状況が違うと思います。仮に似たような形になるとしても、値が違う。例えば、以前は納品後の手戻りコストが100だとしたら現在は30くらいになっているのではないか。とすると、以前は100のコスト発生を回避するために、前工程で50くらいのコストを費やしてよかったかもしれませんが、現在は前工程で50のコストをかけるよりも、手戻りしたほうがコストが低いかもしれない。
いや、30だろうが100だろうが、予定していないコストの発生は困る、と言われるでしょうが、以前も100全部ではないにしてもリスクと称してコストを計算していたのではないか、それが100のときは50だったので、30の現在は15にしてしまっているのがおかしいのであって、昔は50だったのが現在は30です、としておけばよいのではないか。
こういう抽象的な話はあまり意味がないですが、そういう観点で検証してもよいのではないかと思います。
ところが、手戻りにより発生するのは、コストの問題だけではない、すなわち「モチベーション」の問題です。
手戻りによって発生する作業を行うのは「モチベーション」が下がる。
なぜか。
・自分の最初の作業が無駄だったように感じる
・コスト増加の責任が自分にあるように思われる
・後になってさらに手戻りが発生するように思われる
・・・
で、「いやだな」「モチベーション下がるな」という感覚を持つことになります。
しかし、仕事とは約束です。ある意味義務です。最終的にそれを行うことが「正しい」のであれば、手戻りであろうがなかろうがやらなければならない。コストの分配（交渉とか）もそれはそれでしなければならない。
すなわち、「正しい」かどうかの判断と、「いやだな」の気分は別物として考えなければいけないと思うのです。
「きちんと動機付けされていれば、やる気がなかろうが何だろうが『仕方ないなー』と思いながらでも、『やる』ことは出来るんですよ」というはぶさんの言葉の通りです。いやな気持ちは酒でも趣味でもうっぷん晴らしをしながら、それでも仕事はやらなければいけないのです。
ということで、「正しいこと」の判断基準を持ちましょう。「きちんと動機付け」しましょう。自分でモチベーションを生み出しましょう。
手戻りの話に戻ると、上流工程をしっかりやって、前工程の成果をもらさないように設計を詳細化していって、と言う認識は入社以来の教育の賜物です（賜物というのはいい言葉ですが、要は植えつけられてしまったものです）。しかし本質がそうであっても、やり方は自分の経験を踏まえながら勉強すべき。勉強して基準を持つべき。
結城さんのエントリ「ソフトウェアは、私たちの想像よりもずっと複雑」
—
実際にコーディングしなければわからないことがたくさんある。それと同じように実際に本文を執筆しなければわからないことがたくさんある。コーディングしてみて得られた知見をフィードバックしなければ、ちゃんと設計できないのではないか。本文を執筆してみて得られた知見をフィードバックしなければ、構成は定まらないのではないか。
思うに、ソフトウェアも、本も、想像以上に複雑で大きなものであり、人間が誤りなく全体の設計を前もって行うというのは不可能なのではないか。設計が不要だとか、コードがすべてだという気持ちはさらさらないけれど、「コードを書かずに行う設計には何かしら本質的な限界がある」とは言えそうだ。
—
本執筆のプロ中のプロ（私の中での結城さん像）が、本文を書いてみてから構成に戻ると言う。それを受けて平鍋さんが「逆問題」「悪構造問題」と言う言葉を紹介して思考のヒントをくれている。
本を書くときにさえ、よいものを作るために「手戻り」を起こす。それに比べたらソフトウェアは、いくらでも再利用して「手戻り」を無駄にしないことができる。しかも、詳細を先に作ることも、もっともっと短時間にできるはず。そう考えると、自分の中では手戻りは不正ではなくなるので、「いやな気持ち」とも無関係（仕事上、そういうことを言わざるを得ないことはありますが）。ただ、この正しさは相対的です。今時間がかかっている部分が瞬殺できるようになれば、やり方はどんどん変わるわけです。ボトルネックをつぶしたら、別のところがボトルネックになるわけです。ということで、日々精進するわけですね。
ちなみに、イベントに行ってモチベーションが上がるのはありかなと思います。人間みんなすべてに基準を持っているわけではないので、ほかの人の活動を見て自分の基準に取り入れると言うことはあると思いますので。基準ができることで、それに向かうという動機が発生するわけですね。
寝ないで最後まで見てしまいました。
C.ロナウド、役者だね～
イングランドは、ベッカムを下げてからクラウチを入れても遅かったのでは？
これで、次はデコが見られる。
ブラジル戦まで起きてるか・・・
by オシム次期（笑）監督
休んでいる暇はないと。頑張ります。
各ウィンドウの右上の3つのボタン、ウィンドウを最大化すると、ボタンが上にくっついた状態になるのですね。×ボタンは右端にくっついているので、目をつぶってもウィンドウを閉じることができます。
Vistaのウィンドウは、上にくっついていることが一目瞭然ですが、実はXPもそうだったのだという今更ながらの発見でした。
しかし、スクロールバーは右端にくっついていないので、目をつぶってスクロールはできません。もちろん、目をつぶってはやらないのですが、操作性が全然違うだろうなと。
何でこんなことに気づいたかと言うと、ある事情で入れたOPERAの左端がくっついていて扱いやすかったからでした。
デザインを美しくしながら機能性も向上すると言う姿勢、重要。
厳しいな～
アレックスに変えて稲本でどうでしょうか。
最後に大黒で1点で。
本日は会社休んで参加。休まずにちゃんと業務として行けと言われているのですが・・・やはり色々面倒なので・・・。
＜新しいユーザーインターフェイスの可能性＞
近藤さんのしゃべりスタイルが美しい。WinFX→.NET Framework3.0のプレゼンテーション層について。今一番興味のあるところなので面白かったです。ExpressionもWPFでできているとはびっくり。WPF/eでどこまでできるかが興味深いですね。
＜.NET開発者におくるORACLE最新事情＞
ORACLEは全部自分でやる気だろうか。ある意味すごい。
データの暗号化をテーブル定義でできると言うのはちょっとよいかも。
JavaOneでもそうだったようですが、もう少しさりげない製品PRになるとよいのではと思いました。
製品機能の紹介ではなく、こういうすごいことをやりたい場合にこんな機能が使えますよ、と言う感じ？
＜WF(Windows Workflow Foundation)って何だろう？＞
WFは、確かにDTSと比較するのが一番身近で分かりやすいかもしれないですね（私自身はそんなに使っていなかったですが）。
ヒューマンワークフローについて時間切れ気味だったのが残念。ヒューマンワークフローのフローの動的変更と言うか、データに基づくフロー生成と言うか、その辺はやはり無理なのでしょうか？？
ステートマシンはうまく処理できると色々使えると思うので、要調査。
とりあえず現時点でも2.0で日本語対応された開発ができそうと言うのは個人的にはグッドニュース。
＜Visual Studio 2005で週休二日で週末秋葉原（アキバ）なパラダイス人生＞
Generics・delegete、要勉強！
DataAdapterの使い方も再度見直し！
面白く、かつためになるセッションでした。もう少し予習していけばよかった～。
＜～VisualStudioTeamSystem連携ソリューション～テスト・運用サポート作業を効率化する、アプリケーション解析ソリューション AppSight のご紹介＞
要レポートセッションなので、ちょっと詳細に。
製品情報
しばらく前に、会社でも類似製品のデモを見たことがありましたが、そちらに比べるとより開発者向けを意識しているようには感じられました。
デモで障害を発生させて、その原因分析を本製品の機能を使いながら見ていくというセッションでしたが、ありがちな障害を題材としていたので、興味を惹かれました。
基本的には、色々な観点から集めたログを見ていくという形ですが、フィルタリングも強力そうです。
また、オフショア開発におけるコミュニケーション齟齬をなくすためにも使える、というお話もありましたが、それはありかなと思います。オフショアでは、ドキュメントよりもユニットテストの力が大きくなるのではないかと思っていますが、このような製品の力も使えるのかなと思いました。
資料については、あちこちに「○%改善」みたいな表現があちこちに出てきますが、これについては、対象者を考えると、数字よりも具体的な作業で話していただくほうがよいかなと思いました。
また、VSTSとの連携について見えなかったのは残念でした。
デモは面白かったですし、こういう製品がどういうログを収集するか、というのを意識しておくと普段の開発においても危険ポイントを意識できるのでは、と言う面で勉強になりました。
職場が秋葉原のため、あまり周囲をウロチョロするのも気まずく、早々に退散。
楽しい一日でした。
序盤から当たり負けしてたことで、やはり体力もなくなっていたのではないでしょうか。
あんな巨漢と取っ組み合いしているようなもんですからね。
ケネディは、映画に出てくる暗殺者っぽくて怖いし。
川口よかったけど、立て続けにファインセーブをやったことで、失点の場面は出すぎてしまったかも。
福西はもっと決められるはず。
あと2勝、お願いします！
本日懇親会の場で囲碁の初歩を教えていただきました。
1個取ったら勝ちというルールでしたが、なかなか面白い。
そして、後輩に負けたのが、なかなか悔しい。
こういうのは性格が出るのでしょうか、攻めまくるタイプと罠を仕掛けていくタイプがあるようで。
アジャイラーはやはり攻めですよね！
こうやって新しいトビラを開くのは楽しいですね。ゆくゆくは梅沢由香里さんともお知り合いになれるかもなぁ（違）