タグ

2008年1月22日のブックマーク (7件)

  • 2008-01-22

    (日付変わってしまった・・・ このWeb時代においては切り売りなんてナンセンスすぎる。そうではなくて、良質のナレッジをアウトプットすることで良質のインプットが得られるということにもっと目を向けるべきです。 (中略 ナレッジやTipsで提供できるのは「こういう問題は、最終的にこういう結論になった」という結果だけです。不確実で不透明な問題を前にして、自分が悪戦苦闘して得た問題解決のプロセスや思考回路は、何人たりともコピーすることはできません。それを「ノウハウ」というのです。ナレッジは提供できますが、ノウハウは自分の手で築き上げるしか得られないものでしょう。 いいからアウトプットを晒せよ、ハゲ。 - GoTheDistance そうそう、これってとても大事な視点ですよね。 Tipsとかナレッジを出し惜しみしない方が、より多くを得られるぞという。 そもそも、自分の考えが合っているか間違っているか、

    2008-01-22
    mima3
    mima3 2008/01/22
    「検証可能な所においておく」「Disられても何でもいいじゃない」こんど、会社で言ってみる。
  • いいからアウトプットを晒せよ、ハゲ。 - GoTheDistance

    どうもこの業界には自分のナレッジやノウハウ的なものを出し惜しむような方がいらっしゃるようなのだが、それって何か意味あるのかなと正直思う。自分のナレッジの提供が切り売りになると。何でオレがコストかけて学んだナレッジを公開せねばならないんだ、って感じで。ナレッジだけ得ようなんてムシがよすぎる、と。 でもね、それは間違っていると思うんですよ。 私は仕事ができる人ほど自分の持っているナレッジを提供してくれると思ってます。技術的なTipsであったり、こうやってはならないというアンチパターンであったり、と。まぁ確かに何かしらの問題に遭遇して自分で頑張って解決して得たナレッジだけを教えてくれというのは問題です。「いいとこどり」と解釈されます。でもそれはその人の姿勢の問題だし、いつか彼らがFOFAしなくてはならない局面になった時に後悔するだけの話だな、と思ってます。FOFAってのは「Fix Once Fi

    いいからアウトプットを晒せよ、ハゲ。 - GoTheDistance
    mima3
    mima3 2008/01/22
    激しく同意。あと、出し惜しむというより、出すのをめんどくさがっている人が多い。彼らの知識をアウトプットしやすい環境、ならびにモチベーションを維持する仕組みをどう構築するかが課題かも。
  • 啓蒙活動の大事さと難しさ - 学び、そして考える

    自分がこう思っていて、それをそのまま相手に伝えても、自分の頭の中をコピーするようにそのまま伝えることはできない。だから、相手の立場や状況を踏まえて、こう言ったらこう伝わるはず、と絶えず軌道修正しながら伝えることが必要となる。 とはいってもなかなか難しくて。 データベース系の人に向って、LINQ 便利だよ、こんなことができるんだよ、と熱く語ったが、「使いどころが分からない。」と一蹴され。。 パトラッシュ、もう疲れたよ。 いや、自分が未熟だったのが原因です。伝えることの大事さ、難しさを認識できていなかったのです。 引き続き地道にやるです。

    啓蒙活動の大事さと難しさ - 学び、そして考える
    mima3
    mima3 2008/01/22
    伝えるって難しい。受け手にとって新しい概念だと本当に難しい。でも、あきらめたらそこで試合終了じゃよ>自分
  • 境界線ははっきりと

    式の受注・発注の関係というのはやはりこちらの会社のそれとは違うのだなあ、という話を書いた。 この仕組みは阿吽の呼吸というか、同じ背景を共有できている場合にはうまく機能してきた。 たとえば、曖昧な責任・業務範囲なんかも、下請けは、発注元の要求をうまく汲み取っていくことで、範囲外の業務をこなして信頼関係を形成していく。それによって次のプロジェクトでも自動的に受注を得られるような関係を築いてく。 勿論こちらの人々にはそんなストーリーは理解されない。予定に無い仕様変更があったのなら、費用請求するのが普通なのである。なので、同僚のエンジニアも自分だけが無理難題を押し付けられているかのように思って怒っている。 「どうして、彼らの曖昧な仕様と彼らのバグとドキュメント不足ために、こんな手戻りを自分が何回もやらなければならないだっ!」 というわけで、こちらのエンジニアにはまったく理解されない。 考えてみ

    境界線ははっきりと
    mima3
    mima3 2008/01/22
    仕事を(可能なかぎり)明確な境界がわかるように切り分ける能力が必要といってみる。で、その能力がない人が上流という工程にいるのは犯罪だと思う。
  • Software Testing - Columns: スモークテスト

    テストの進捗を妨げる最大の原因は何でしょう。操作ミスをしてしまい、テストケースどおり実施できないことでしょうか。テストツールが使いこなせないことでしょうか。それとも担当者が失踪することでしょうか。 多くの組織でテストケースが消化できない最大の原因は、テスト対象のソフトウェアにバグが多すぎることです。テストをする度にバグが発生していては、いつまで経ってもテストが終わりません。試しに、バグの発生しない(OKの)テストケースと、バグの発生する(NGの)テストケースの両方について、テストケースあたりの実施時間を測定してみて下さい。圧倒的にNGの場合の方が時間がかかるでしょう。 NGテストケースの方が実施時間が長いのは、現場にいらっしゃる方なら肌でお分かりのことと思います。少なくとも不具合報告書(バグ票)を書く時間はかかりますね。OSごと落ちてしまうバグの場合は、再起動の時間がかかります。ファイルや

    mima3
    mima3 2008/01/22
    最低限とおるべきテスト。こういうのを自動化する方向に持ってきたい。
  • 2007-10-05

    知っていれば簡単な事なのに、調べてみると意外と大変でした。 msbuildの標準機能ではメール送信が出来ないため、MSBuildCommunityTasksをインストールします。 インストール時にエラーになる事があります。( Failed to open XML file, system error:-2147024786) その場合は以下の手順でとりあえず使えるようになります。 ソース一式をダウンロードして解凍します。 続いてC:\Program Files\MSBuild\MSBuildCommunityTasks フォルダを作成し、解凍したフォルダから「MSBuild.Community.Tasks.Targets」と「MSBuild.Community.Tasks.dll」をコピーしてください。 (ヘルプファイルも解凍したフォルダ内にあります) プロジェクトファイルをリビルドし、エ

    2007-10-05
    mima3
    mima3 2008/01/22
    あとで試す
  • .NETビルド・エンジン「MSBuild」使いこなし術 ― @IT

    .NET Framework 2.0では、CLR上で動作するプログラム(以降、.NETプログラム)を生成するための新たなビルド・エンジンとして「MSBuild」が搭載された。 そこで特集では、前・後編の2回に分けてMSBuildの詳細を解説する。前編では、「MSBuildとは何かについてとその利用方法」について、後編では「ビルドの手順(以降、ビルド・プロセス)を記述したMSBuild用ファイルの読み方や書き方、またMSBuildにカスタムの機能を追加して拡張する方法」について説明する。 それではさっそくMSBuildとは何かから説明していこう。 1. 「MSBuild」および「MSBuildファイル」とは? MSBuildとは、独自のXMLフォーマットのファイル(以降、MSBuildファイル)を解釈して、それに従い.NETプログラムをビルドするためのツールである。 MSBuildファイル

    mima3
    mima3 2008/01/22
    あとで試す