頭痛そして発熱

今日は朝から体調が悪く、

途中で頭痛を併発したのだけれど、

私由来ではない、トラブル対応のため、

さすがに早退するわけにもいかず、

結局家に帰ってきたら発熱してました。

今は快方に向かいつつも、まだ油断は大敵。

体調が良かったら、某食事会に参加したかったのになぁ。

Share

プロジェクトのリーダが学生症候群を患っていたら危険

学生症候群とは、期日が決まっていると、その日までに終わらせれば良いと思い、ギリギリまで何もしないという特徴がある。

そう、まるで夏休みの宿題を夏休みが終わる直前になってやっと始める学生のように。

まだ、プロジェクトのメンバというレベルであれば、リーダおよびマネージャがフォローする事ができるが、リーダおよびマネージャが学生症候群を患っていると性質が悪い。

スケジュールなんてあったもんじゃないし、結局メンバがリーダおよびマネージャのロールをサポートせざるを得ない状況になる。つまり、逆管理状態。

メンバがそれなりにフォローできる能力を持っている場合は良い。

だが、メンバがメンバとしてのロールしか果たせないレベルの場合は、ぐだぐだになってしまうだろう。

きっと、アラームも納期直前に上げるのだろうから、ぐだぐだである事が発覚する時には既に手遅れになっている可能性が高い。

ぜひ、プロジェクトのメンバはメンバである事以外に、つぶさにリーダを観察するという事をしてほしい。

もし、学生症候群を患っているなと思ったら早期の段階からフォローする必要がある。

また、場合によっては、より上位のロールを持った人にアラームを出し、よりダイナミックな対処を施す必要がある。

もちろん、上述した事はプロジェクト失敗に至る原因の一つでしかなく、ほかに原因がある場合も少なくないので、あくまで一つのパターンとして留めておいてほしい。

ちなみに、学生症候群というキーワードについては下記の本が詳しい。

Share

アップルの強み、ソニーの弱みのうちの一つについて

アップルの強みでもありソニーの弱みであるところはいろいろとあると思いますが、

そのうちの一つについてフォーカスしたいと思う。

  • 発表即発売が出来るアップル
  • 発表2ヶ月後発売なソニー

この辺りに差があるのでは無いかな。

鉄は熱いうちにうて。

というか、考える余地を与える前に買わせてしまえ。

というか・・・

それにしても、凄いのは、アップルの驚くべき統制力。

通常、前日に各店舗に入荷しているのだろうし、

アップル社以外の商品関係者にも情報は渡っているのだろうから、

どこからか、もっと具体的な情報が漏れそうなモノなんだけど、

それが無い。(もちろん、具体的ではないが近しい情報はたくさんあったが)

その情報統制力こそが、発表即日発売を可能にしているのかもしれない。

Share

自分が何をコーディングしているのか理解しないまま仕事しちゃ駄目

下記のコードをネット上で見て、うすら寒い思いをした。

(原文ママではありません)

Dim dv As New DataView

Dim dt as New DataTable

dt = CreateData() ‘DataTableを返すメソッド

dv = dt.DefaultView

この場合、dtはCreateData()から返されたDataTableのインスタンスを取得するのに、

宣言時にもインスタンスを生成している。

dvはdt.DefaultViewから返されるDataViewのインスタンスを取得するのに、

これまた宣言時にもインスタンスを生成している。

この事から、このコーダはクラスとインスタンスの関係を理解していない。

理解していないまま、なんとなく動いちゃうから、それでいいやになっている。

仕事でやっているのなら、せめて、自分が書いたコードがどう動いているのか理解しましょう。

ちなみに、プログラムは自分が思った通りに動くと思ったら大間違いです。

プログラムはコーディングした通りにしか動きません。

Share

コピーバイブル

私は、よく異業種の本でも有用だと思えば購入して読んでいる。

この本もその一つで、私はコピーを書く技術というのは、

そのまま提案力、設計力、はたまたコーディング能力にも活かせると思っている。

この書籍もその一つである。

例えば、この書籍の中にこんな言葉があった。

すべては名前から始まる。

全くその通りだと思う。

示唆に富んでいる。

名前の付け方一つで説得力のある提案、説得力の無い提案にわかれる。

名前の付け方一つで分かりやすい設計書、分かりにくい設計書にわかれる。

名前の付け方一つで保守性の高いコード、保守性の低いコードにわかれる。

名前の付け方一つで認識のされ方が変わる。

この言葉で、名前を付けるというのは大事な事なのだと再認識させて貰った。

Share

HP Officejet7410が欲しい

オフィスのニーズを満たす、信頼性とコストパフォーマンスに優れたビジネス・オールインワン。

・高性能/高画質はそのままにHP Photosmart 2710 All-in-Oneをビジネス仕様にカスタマイズ。

・ADF+自動両面ユニット搭載だからプリント、コピー、ファクス、スキャンも自動両面対応。

・IEEE802.11g無線LANと有線LANに標準対応。

・新開発、自動両面印刷対応ハガキトレイ標準付属。大量のハガキ印刷もラクラク。

日本HP ビジネスインクジェット Officejet 7410トップページ

これが欲しい。いつのまにか、42800円まで値下げしちゃってるし。

HP Directでしか購入できないのが痛いなぁ。現物を見たい。

CDに印刷できない事をのぞけば、ベストな選択です。

Share

むやみにキャッチしないでね。ゴールキーパー以外はハンドで反則ですよ。

まぁ、そんなわけで、私が書いているコードはほとんどTry-Catch-Finallyではなく、Try-Finallyばかりだ。
正当な理由がある(Catchする事に意味がある。)時や、付加情報を付けて再Throwしたい時くらいしかcatchしない。
では何処でcatchしているかというと、global.asaxのApplication_Errorイベント内。
ここに例外が飛んできたら、イベントログに、その内容を書き出してDebugモード時は画面にも例外の内容を、Releaseモード時は「ご迷惑をお掛けしています。」ページに遷移するようにしている。

では、なぜむやみにcatchしては駄目かと言えば、

  • 正当な理由がないのにcatchして例外を消してしまうと、一見うまく行っているような動作をしてしまう
  • そのため傷口がどんどん広がる。
  • そのためバグが発覚しにくい。
  • 発覚した時には手遅れになっている可能性がある。
  • 事前条件に基づいてメソッドの先頭で例外をThrowするようにしているとより効果的。

逆に、正当な理由が無いものについては個別にcatchしないでAppication_Errorで一元管理すると何が良いかと言えば、

  • 起きてほしくない例外を漏らさす知る事ができる。
  • そのためバグがすぐ発覚する。
  • つまり、それを潰す機会が早期に与えられる。

また、

  • 想定外の例外に対して、そこら中にエラー処理を記述する実装だと、エラー処理を記述し忘れる不具合が発生する可能性があるが、それが無い。
  • 不必要で不可解なコードを作り込まない。
  • 結果的にシンプルかつ見通しが良くなる。

一応、上記の根拠に沿って、こういう実装をしているわけです。

もし、そこら中で意味も無くcatchしているとしたら、それはバグ許容宣言をしているようなものなので、やめた方が良いでしょう。

Share
カテゴリー: .NET

とりあえず、今月中に買わないと行けない

ProかEnterprise Developerか・・・

すべてはVSSと2005になった時の事を考えないと行けない。

6万の差は安い?

Visual Studio .NET 2003 Pro MSDN DX 優待パッケージ

Visual Studio .NET 2003 Pro MSDN DX 優待パッケージ

Visual Studio .NET 2003 Enterprise Developer MSDN DX 優待Package

Visual Studio .NET 2003 Enterprise Developer MSDN DX 優待Package

Share
カテゴリー: .NET

日本代表、何やってるんだー

点、とられ過ぎですよ。

久々に見た点数。

サッカーの国際親善試合、日本??ホンジュラス戦は7日夜、宮城スタジアムであり、日本が5??4で勝った。ジーコジャパンは監督就任後、中南米勢に初勝利を収めた。

asahi.com:日本、ホンジュラスに逆転勝ち サッカー国際親善試合??-??スポーツ

Share