March 31, 2004

ファイル交換

ファイル交換とレコード業界の売上減少は無関係†米経済学者が論文


これまでの音楽業界の主張が既得権益が侵害されている。諸悪の根源は、ファイル交換サービスだ。このままでは音楽業界はつぶれる、というものを真っ向から否定する純粋な経済学的な論文、まぁ、自分とこの業界なり、会社なり、部署なりの成績、業績が悪化したとき、外部要因を理由に挙げ、責任回避することはよくあることで(実は、景気悪化の諸悪の根源は、この外部要因に対する個々の甘えを合成したことによる誤謬が原因だったりして。)、気持ちはわからなくもない。こうなったら、音楽業界は、逆に、自分たちが売り出したい新しい音楽をプロモートするための新しい媒体としてファイル交換サービス、といったものを捉えてお互いに利用するぐらいの方が面白い展開になると思うんだが甘いのだろうか? だからといって、違法なファイル交換が認められる、という話にはならないとは思うが。でも、文化発展の足かせになってる可能性とクリエイティブコモンズという考え方も踏まえて、新しい著作権の考え方が必要になるんだと思う。がんばってくれ、法律屋さん。

Posted by money at 12:12 PM | Comments (0) | TrackBack

ビットの経済的価値

そして、次の言葉も的を得ていると思った。

[dgcr.com]デジクリバックナンバー

見えないものや、
手に取れないものだがお金を支払うというケースは、労働の対価であることが
ほとんどだ。デザインや情報の内容・質自体には、どんどん値段が付かなくな
っている一方、労働には確かな値付けがなされるようになってきている。


ソフトウェア屋としてこの事実をどう捉えるか、と考えてみると、やはり、人月という数字が一人歩きしている現状を踏まえると、結局「労働」といういものに価値のものさしを置き換えてしまっているということになる。結局開発請負というビジネスモデルでは、人海戦術、労働集約産業から逃れられず、知識集約には程遠い。一部には納めたシステムが生み出す利益、価値を金額で評価してそれに対する一定の割合をシステムの対価とする、という例も報告されてはいるが、この評価自体恣意的に操作可能であり、こういった手法に頼ることはできない。また、正確な評価が可能なのかどうかも疑問。
最近「白い巨頭の放映等により話題に上がる医者の世界でよく言われているのが、「診療報酬は、全国一律で決められている。これでは、優れた医者であろうが、未熟な研修医であろうと、変わらない。こんな状況で医者がモチベーションが維持できるのか?」という議論も似たようなものか。いや、我々の世界の方が人月単価で差をつけることが可能なだけ健全なのかも知れない。でも、この言葉、「 なお,自らIT技術の第一線にある者が納期・予算を守れず,人海戦術頼みであることを心より恥じる.」、笑えません。

Posted by money at 10:34 AM | Comments (2) | TrackBack

March 30, 2004

Domain Driven Design

あらゆる場所で絶賛されていたので早速アマゾンから取り寄せました。
Domain Driven Design: Tackling Complexity in the Heart of Software
Eric Evans (著), Martin Fowler (著)


ファウラー氏による前書きから気に入ったことば。


If you're trying to add automation to complicated human enterprise, then your software cannot dodge the complexity -- all it can do is control it.


なんか、チャーチルの演説(つーか、Aces Highのオープニング)の言葉を思い出してしまった。

We shall go on to the end, we shall fight in France, we shall fight on the seas and oceans, we shall fight with growing confidence and growing strength in the air, we shall defend our island, whatever the cost may be, we shall fight on the beaches, we shall fight on the landing grounds, we shall fight in the fields and in the streets, weshall fight in the hills; we shall never surrender.



Posted by money at 1:15 PM | Comments (0) | TrackBack

March 29, 2004

J2EE 1.4 tutorial

Sun releases tutorial for J2EE 1.4

PDF版で1500ページだそうです。多すぎです。このボリュームでは辞書代わりにしか使えません。将来のJ2EEチュートリアルは200ページ*1くらいで書けるように簡単にならないといけないです。


1500ページも書かないとチュートリアルにならないもの、って?リファレンスマニュアルならわかるが、あくまでもチュートリアルは「♪はじめのだいいっぽ!」なんじゃぁ?
で、このチュートリアルの中身がどうなってるかはこれから調査。

でも、今までのチュートリアルも、確か800ページ強あったしな。

Posted by money at 2:50 AM | Comments (0) | TrackBack

March 28, 2004

録画処理手順メモ

PCでテレビ番組を録画した後の処理手順のメモ。
1. MPEG2ファイルをDVD2AVIに読み込ませ、メニューから[File]→[Save Project]を選択して適当なファイル名で保存。
〇[File]→[Save AVI]でないのがポイント。何の設定もしてないがここはMPEG2対応のための処理なのでこれだけ。
〇仮に、「嘉門達夫ライブ.m2p」を処理したとすると、「嘉門達夫ライブ.d2v」(プロジェクトファイル)と「嘉門達夫ライブ MPA T01 DELAY -66ms.mpa」(音声ファイル)ができる。
2. TMPGEncで映像ソースに「.d2v」を、音声ソースに「.mpa」をドラッグ&ドロップして設定ボタンクリック。
〇ビデオタブ:
  サイズ: 704×480 に。元の映像は720×480だが、大抵左右の端に黒い部分があるのでそれを除去する。
  レート調整モード: 自動可変レート(CQ_VBR)
  品質: 100
  最大ビットレート: 100000 kbit/sec
  最大ビットレート: 10000 kbit/sec
  動き検索精度: 最高画質(最低速)
〇ビデオ詳細タブ:
  画像配置方法: 画面全体に表示(アスペクト比保持)
  ソースの範囲: CMカットなどこまめに
  インターレース解除: 偶数・奇数フィールド(フィールド・適応)
〇GOP構造タブ:
  編集用ビットストリームを出力する(Closed GOP): チェック付与
〇オーディオタブ:
  ストリーム形式: MPEG-1 Audio Layer II
  サンプリング周波数: 48000 Hz
  チャンネルモード: ステレオ
  ビットレート: 384 kbit/sec
  音声加工: チェック付与
  ボリューム変更: チェック付与
  正規化ボタンで100に正規化
全て設定が完了したら、メニュー[ファイル]→[プロジェクトの保存]で適当な名前をつけて保存 →「嘉門達夫ライブ.tpr」ができる。
3 VFAPIconvに「.tpr」をドラッグ&ドロップして、実行ボタンクリック →「嘉門達夫ライブ_tpr_vfapi.avi」ができる。
4. VirtualDubに「.avi」をドラッグ&ドロップして、
(4-1)メニュー[Video]→[Compression]を選択し、一覧から「DivX Pro 5.0.5 Codec」を選びConfigureボタンクリック
  〇profilesタブ:
    1-Choose your profile: チェック付与
    High Definitionを選択
  〇MPEG4 Tools:
    Use Bidirectional Encording: チェック付与
  〇Bitrate Controlタブ:
    Variable bitrate mode: Multipass, 1st pass
    Encoding bitrate: 1500 kbps
    Multipass encoding files: divx.logファイルをどこでもいいので設定
    Write MV file: mvinfo.binファイルをどこでもいいので設定
  〇General Parametersタブ:
    Enable Resize:チェック付与
    width: 528
    height: 360
    Bilinear (very soft)を選択
    ※ここの設定が出来上がりの動画の表示サイズになる。
    Keyframe: 900 frames
    Perfoemance/quality: Slowest
    Source Interlace: Encode as prograssive
    全てOKを選択してウィンドウを閉じる
  (4-2)メニュー[Audio]→[Full processing mode]を選択したうえで、再度[Audio]→[Compression]を選択し、一覧から「Lame MP3」と「48000Hz, 128 kbps CBR, Stereo」の組み合わせを選択
  (4-3)メニュー[File]→[Save as AVI]を選択して適当な名前をつけて保存。
    ※「Don't run this job now; add it to job control so I can run it in batch mode.」にチェックを入れる
  (4-4)メニュー[Video]→[Compression]を選択し、一覧から「DivX Pro 5.0.5 Codec」を選びConfigureボタンクリック
    〇Bitrate Controlタブ:
      Variable bitrate mode: Multipass, nth pass
      Encoding bitrate: 1500 kbps
      ※ここのレートが画質とファイルサイズに直接影響する。
  (4-5)メニュー[File]→[Save as AVI]を選択して適当な名前をつけて保存。
    ※「Don't run this job now; add it to job control so I can run it in batch mode.」にチェックを入れる
  (4-6)メニュー[File]→[Job control]を選択すると2つのjobがエントリされたウィンドウが開くので、Startボタンをクリック

Posted by money at 1:33 PM | Comments (0) | TrackBack

仕事は趣味ではない

というのは、フツーの文脈では、「遊びじゃないんだから真剣にやれ」という意味であるとか「遊びじゃないんだから規約を守れ」というどちらかといえば積極的にプラス方向へモノゴトを進めるために使うべきものなのだが、ことプログラムに関して言えば、「手を抜け」であるとか「後先を考えちゃおしまいよ」とか「目先の利益優先」とか「形式さえ合っていれば内容は問わない」とマイナス方向へ進めるために利用されているのではなかろうか。


昔、同じセリフを違う部署の部長に言われたことがある。そのとき彼が言いたかったことは、「仕事は趣味ではない。だから仕事で楽しみを求めるのは不謹慎だ。」というような文脈だった。そのとき僕は、「この人は可哀想だなぁ。」と思い、何も突っ込まなかったと同時に、この人とだけは仕事をしたくないな、と思った。

Posted by money at 2:13 AM | Comments (0) | TrackBack

March 27, 2004

ITアーキテクトへの道

新入社員相手の研修のネタに使えそう。
Posted by money at 10:33 PM | Comments (1) | TrackBack

SIer(死語)とは?

それは、(当たり前ですが、名前のとおり)SI企業は、システムを「つなぐ」
ことが一番大きな使命であり、価値の源泉だということです。


元々は、顧客の要望に沿ったプログラムの開発を請負うという立場から、顧客の要望の複雑化、ハードウェア、ソフトウェアの複雑化等により、システム化の実現、導入、運用までもを請負い、その対価を頂くのが本来のSIerの立場か。そういう意味では、

視点や立場、目的が違うもの(組織も人も、システムもですが)同士をつなぐことはとても難しく、失敗する可能性が高く、これは期間の限られたプロジェクト形式の活動内では大きなリスクとなります。この部分を専門的に担当することで失敗を減らして作業のリスクを軽減し、顧客からはリスクを引き受けることに対する対価をもらう。(軽減済みの)リスクを担保する費用と、顧客から得る"リスクを引き受けることに対する対価"との差分を利益とするのがSI企業ではないかと思います。



というのは自戒を込めてとても納得できる。(顧客のもつ)リスクを代わりに請負うことでその対価をいただく。顧客は対価を払うことでリスクをヘッジする。SI屋は、その技術力によりリスクを抑え、コントロールすることでそのリスクをヘッジする。あれ?うちにそんな技術力、あったかな?

Posted by money at 10:31 PM | Comments (0) | TrackBack

March 25, 2004

Spring has come.

Spring Framework 1.0 Final Release.
Posted by money at 2:18 PM | Comments (0) | TrackBack

NTTグループのネーミングセンス

確かにねぇ。直近の話題だと、「パケホーダイ」とか? あとは「ドラグリとか、ヘア写ロンとか。その他にもシステム名とかいろいろあるけど、こんなところでは言えません。

で、こういったネーミングセンスがどうやって出てくるんだ?とお思いの方もいらっしゃるかと思いますが、ご想像の通り、お年の召した偉い方々が会議室に一同に会し、眉間にしわ寄せてあーだこーだ議論しながら決まります、きっと。キラリと光る名前なんか出てくるわけねーべ? 

Posted by money at 1:13 PM | Comments (0) | TrackBack

March 24, 2004

OODB

うーん、これでなんでパフォーマンスがあがるのか、よくわからん。Sparse Multidimensional Arrayってのもよくわからん(これ、シグネチャ―インデックスの派生かな? >シグネチャ―インデックスのエライ人)し、この説明に使ってるクラス階層の絵もなんの階層だかよくわからん。(普通クラス階層といえば、クラス図の継承関係の階層か、包含関係の階層のことを言うと思うんだけどこれはそのどちらでもなさそう。) それにOODBでわざわざSQLインタフェースを用意することが重要だとも思えない(だったら、RDBを使えばいいんだし)し、このOODBが目指すものがよくわからないや、やっぱり。
Posted by money at 10:17 AM | Comments (0) | TrackBack

いい日旅立ち

週末、実家に帰省してました。用件は妹の結婚式。花嫁の兄なんてなんもすることはありません。せいぜい、親族用に写真をパシャパシャ取ることと出てくる旨い物を食うこと。けど、さすがに、花嫁が最後に読んだ手紙にはこみ上げてくるものがありました。 式そのものは妹の飲み友達というプロの司会者による進行でつつがなく進み、無事にお開きとなりましたが、隣でかたくなに高砂を見ようとしないうつむいてばかりの父の姿が印象的でありました。式が全て終了し、帰宅してからも、泣いていたことを認めようとしない頑固な父です。こんな日のBGMはやはり、「親父の一番長い日」でしょうか。

Posted by money at 1:28 AM | Comments (1) | TrackBack

March 17, 2004

そんなん、あり?

作者の構想がふくらみ、新聞連載による完結が不可能になりました

その作者の膨らんだ構想(妄想?)こそ、読者が読みたいものなのに。。。 って、わたしゃ、この連載読んでませんが。

Posted by money at 12:06 PM | Comments (0) | TrackBack

週刊文春

今朝のニュースで話題になってた、出版前の販売指し止め命令という異例な決定。でも、どうやら、決定が下ったのが遅かったため、雑誌の出荷には間に合わず都内コンビニ等で販売されている可能性が高い、各書店の判断に委ねられる、とのこと。へぇ、と思ってテレビを消して出社してたら、途中のコンビニで発見!思わず購入。 で、その内容は、、、全然たいしたことなかった。 販売指し止め命令も使いようによっては宣伝効果抜群、ということで。
Posted by money at 9:21 AM | Comments (0) | TrackBack

March 13, 2004

パソコン使うのに、まずは勉強?

パソコンが全くダメなある女性のお話。彼女曰く、仕事でパソコンが使う必要が出てきた、そこで、まずはコンピュータの勉強を勧められたそうな。CPUとかコンピュータの仕組みとか勉強してるんだがちんぷんかんぷん。奥がとても深いことを実感してて自分にどこまでついていけるか心配だ、とのこと。
これを聞いて私の反応は、「あ、それ、間違ってます。コンピュータのエンジニアなり専門家になるわけじゃなく、単なる便利な道具としてコンピュータを使おうとしてる人が仕組みを学ぶ必要はありません。理屈はいらないからとにかく触って慣れること。分からなかったらその都度解決していけばいい。」と。
専門家、あるいはコンピュータで飯食ってる奴でも勉強しない奴、仕組みが分かってない奴がいっぱいいる、ってのに。なんか世の中間違ってる。

Posted by money at 3:29 AM | Comments (0) | TrackBack

March 12, 2004

雪山

今晩は、これから支度して岩原スキー場へ。

Posted by money at 9:13 PM | Comments (0) | TrackBack

March 10, 2004

yahoo IM

いきなり、英語で話しかけられた。なんか適当に話をあわせてる(と言っても相手は英語なので、頭はフル回転だったりする)と、奴はフランス人。しかも、アークエネミーの大ファン(この時点で少し変)。で、早い話が、アークエネミーのJapanツアーについて調べてたら、ここにたどり着いて、そこから僕のサイトに飛んできた。それで、Yahoo IMのアイコンが貼り付けてあったので、声をかけた、と。で、さらに驚いたのは、アークエネミーのJapanツアー、全制覇するそうな。(ほら、変でしょ?) 東京、名古屋、大阪、福岡のライブ会場のWebサイトを教えて、さらに、いいCDショップしらないか?と聞かれ、当然ながら御茶ノ水のDISK UNIONを教えて、じゃ、東京にいる間に飯食おう、ということになった。人類平和、ヘビメタ万歳!しかも、「おまえは、アークエネミーのライブ行かないのか?」って言うから、「チケット取れなかっただ〜」って言ったら、「来週、追加公演のチケット発売するぞー、取れなかったら連絡してくれ。マネジメントに話通じるから」だと。こいつなにもんだ? ということで、いっしょにアークエネミーいかね?>きっかけを作ったあなた。ちなみに、日程は、6月下旬。果たしてどうなることやら。その前に、どうやって相手と待ち合わせするんだろう?まぁ、6月までゆっくり考えます。 (くそー、睡眠時間奪いやがって。。。でも面白かったのでよしとしよう。)

ちなみに、yahoo IMの友達リストに追加しようとしたら、拒否しやがったから、「許可出してくれよー」 「ああ、ごめんごめん。日本語のメッセージ、難しいのよ。」なんて会話を交わしたが、そりゃ、難しかろう。きっと、向こうでは、文字化けしてるはずだ。日本人でも読めん。向こうの名前もこちらでは化けてたし。

Posted by money at 5:32 AM | Comments (0) | TrackBack

March 9, 2004

仕様のFix

業務仕様とは、どこでFixさせるべきなのでしょうか.
  1. ウォータフォールならば、上流工程でFixさせる。
  2. 最後まで決まらなくて、プロジェクトがデスマに陥るのがこの業界の慣例
  3. 流行のXPやRUP等を用いて変化に対応する。
  4. 無理やりFixさせて客に仕変をせまる。

うーん、理想はやっぱり、(3)なんだろうけど、お客さんを選ぶ必要があります。というのも、最近、むやみやたらとXPやれ、と迫るお客さんが多い。個人的にもいろいろ試してみたいことがあるので、嬉しくなって話を進めようとするとどうも、話がかみ合わない。よくよく話をつっこんでみるとなんてことはない。XPのことなんて少しも分かってなくて、ただ単に、「変化を抱擁せよ」tと言う言葉を勘違いして「XPって、仕様変更の無理が利くんでしょ?」とか、「テストファースト」を勘違いして「いきなりテストからやるんでしょ?メイク工程省けていいね」とかその程度の理解でしかない。そこで、「テストファーストというのは、まずテストプログラムを書いてそのテストがちゃんと動くようにコードを書け、ということです。テストプログラムが通るということは、まずこれさえできればOK,という仕様を決めていただかないと、テストプログラムは書けません。」とか、「最大限、仕様変更には対応しますが、手戻りの工数は全てご請求させていただきますがよろしいでしょうか?」といった話をすると、途端にトーンダウンしてしまう。あと、オンサイト顧客やってくれ、って話もまずは聞いてもらえない。まだまだお客さんに対する啓蒙が必要です。でも、お客さんさえ了承が取れれば、上司は押し切れるんだがなぁ。結局、開発側としては、現時点では自己防衛も含めて、(4)しかなさげ。コツは、お客さんに、「申し訳ない。こちらの検討ミスが見つかったので、お願いだから仕様変更させて!」と思わせること。何事も主導権を取ったもん勝ち、ということで。
でも、自分が開発側であることを一歩離れて考えると、「Fixしないから仕様なのだ」と思う。仕様が全く変わらない開発なぞ面白くありません。仕様とは生き物なのだ。

Posted by money at 3:51 AM | Comments (0) | TrackBack

雪山

最近、「組織とは2割の優秀な人間が8割の仕事をこなすことを実証してみよう」キャンペーン期間中、いや、「たまにはまじめに仕事に集中してみよう」キャンペーン実施中につき、ご無沙汰だった雪山に久しぶりに出かけて参りました。場所は、今シーズンの雪山初めにも使った舞子後楽園スキー場。うちからだと、そのまま北上して関越乗ってそのまま1本、しかもインター降りて2分という便利なところです。
あいにく吹雪と快晴が入り混じる微妙な天候でしたが、頭を真っ白にしてきました。舞子後楽園は、ちと易しめとは言え、中上級者コースから初心者コースまで、コースを選り好みせずにトライできるレベルにはなったような気がします(軽快に滑られる、とは言ってない)。お土産として、(1)首が回らない(人にぶつかってこられ、頭を打った際に衝撃を受けた模様。)(2)頭が痛い(たんこぶ?)(3)腕が痛い(筋肉痛)(4)右足が痛い(これも筋肉痛)(5)左足も痛い(これは、少し痛めた模様) とフルコース。
今年度内は恐らく今週末の湯沢近辺にて最後でしょう。(来年度? 雪山シーズンはまだまだ続きます。)

Posted by money at 3:24 AM | Comments (0) | TrackBack

March 8, 2004

ベイジアンフィルタ

Becky! Ver.2(以下、Becky!)でSPAMを自動的に振り分けするプラグインです。Rubyで書かれていて、Becky!でRubyスクリプトを走らせるプラグインであるBeckrbの上で走ります。

重い腰を上げてベイジアンフィルタを導入してみた。これは、ベッキーのプラグイン形式になってて、実際には、ベッキーのrubyスクリプトプラグイン上で走るrubyスクリプトになっている。これで、少しはSPAMが減ればいいのだが。。。

Posted by money at 2:11 PM | Comments (0) | TrackBack

March 6, 2004

ITプロジェクトの実態

笑えます。でも、笑えない。。。 問題は、どうやってこの「タイヤ」を導くか、なんだが。ひとごとではありません。
Posted by money at 6:24 PM | Comments (0) | TrackBack

ゴーログ

あの、下手したら(?失礼!)これからの日本の金融業界を動かす人になりそうな予感をさせてくれる、木村剛氏のブログ発見。記念にトラックバック。(ミーハー) しかも、著書やブラウン管から垣間見られる冷静沈着冷血理論派という雰囲気とは全然違ってブログ上ではとてもはしゃいでおられるご様子。ますます気に入ってしまった。そんな彼が飲み会やるぞーとサイトで公言されておりますが、木村剛氏と一緒に飲めるとなったらあなたならどうする? 僕だったら、「これからの日本金融界の進むべき方向性について熱い議論を交わしたい」と言いたいところだけど、木村氏と議論を戦わせるだけの金融業界に関する知識はないので
  • とりあえず、本にサインしてもらう。
  • あなたのIT分野のブレーンにしてくれと直談判する
が関の山か。いかん、これじゃ飲み会の場が持たない。あとは、木村氏の持論をとうとうとグラス片手に拝聴するのも贅沢かも。
Posted by money at 2:41 PM | Comments (2) | TrackBack

プロジェクトと情報共有

ソフトウェア開発に限らず、プロジェクトを円滑に運営していくための鍵としてよく挙げられるのが「情報共有」であり、多くのグループウェアはこの情報共有を如何にコストをかけずに円滑に行うかに焦点をあてたものが多い。僕が大学院で「グループウェア」をテーマにしてた頃は「グループウェア」といえば「ホワイトカラー(つまり事務系)向け」のものが主流(Notesが流行り出したのもこの頃か?)で、僕が趣向してた、ソフトウェア開発チームのためのグループウェアはどうあるべきか?というのは当時はよく分からず、結局挫折したんだが。結局、巷のオープンソースプロジェクトによくある、CVS Webポータル、ML、掲示板等というとこに落ち着きつつあるが、このWebポータルと掲示板の双方を兼ね備えたようなWikiの有効性を最近よく耳にする(目にする?)。かのMartin Fowler氏もUsing an Agile Software Process with Offshore Developmentの中でオンショア(本国側)とオフショア側の両チーム間の情報共有の手段としてWikiの有効性に言及している。ただ我々のような受託開発の場合、Wikiを開発プロジェクトの情報共有ツールとして採用するのに二の足を踏んでしまう理由が1つある。Wikiに蓄積した情報を納品物、あるいはドキュメントとしてまとめる手段だ。もちろん、内部の要員に対してはそのままWebサーバを運用しておけばいいので、それほど問題とはならない。僕が欲しいのは、Wikiに書いてあるものがそのまま例えばSmartDoc形式のファイルに落とすことができて、最終的に体裁の整ったドキュメントに変換が可能にする機能だ。この辺の、プロジェクト内情報共有ツールとドキュメント生成あたりがもう少しシームレスにつなげることはできないか、と思うのである。(でも、マーチン氏は上記の記事の中で「ドキュメントを最新のコードに追従しようとはするな。必要に応じてその都度作れ」とおっしゃってるので、それに反するような気はするけど、でもドキュメント作業を少しでも簡略化しようというマインドは同じような気もする)。何かいい手は無いものだろうか?

Posted by money at 1:23 AM | Comments (0) | TrackBack

March 5, 2004

books

Springフレームワークってやっぱりまだ文献は少ないなぁ。日本語版までは期待してないけど。
Posted by money at 5:27 PM | Comments (0) | TrackBack

議論のアンチパターン

なんか、耳が痛いです。 僕がよくやらかす失敗。基本的に社内の目上、先輩に対してというのがほとんどですが、基本的なベースとなる考え方として相手にもプライドがある、自分よりもエンジニアとしての経験年数が長い、という前提に立つと、少なくともエンジニアの力量というか知識というか洞察力というかそういういわゆる能力として少なくとも自分と同等、いやそれ以上のものを持ってててあたりまえと考えてあくまで対等のエンジニアとして接します。すると、「なんでこんなこともわかんねーんだよ。何年コンピュータで飯食ってんだ?」という話になって、いつも怒られます。どうやら、新人さんのように懇切丁寧に教えてあげないと逆切れされます。部下、後輩から新人扱い、能無し扱いする方がよっぽど相手のプライドを傷つけるんじゃないかと思うんですが、どうも違うようです。こうして、私は今日も「言葉遣いかきつ過ぎる。それじゃ、ショック死する人が出てきますので、言葉は柔らかく」と怒られるのであった。 仕事を上手く進めるためには、議論が必要で、人間が複数人集まるんだから当然意見がぶつかることがあるのは当然で、ぶつかってから落としどころをどこへ持っていくかを探るのが腕の見せ所だと信じているのですが、どうやら意見がぶつかることそのものを由としない風潮が強い、と最近強く感じます。世知辛い世の中になりましたな(って、使い方違う。。。)
Posted by money at 3:25 AM | Comments (2) | TrackBack

March 4, 2004

IOCコンテナ?

最近話題のIOC, Inversion of Control コンテナ。概念的な説明は、こことかこことかを参照してもらうとして、さて、これどういう日本語訳を充てればしっくり来るんだろう?最近、悩み続けてます。
今時点の案では、「制御の裏返し」コンテナなんだけど、これだと概念の中身を知らない人に説明しようとすると何がなんだか訳わからんからボツ。

Posted by money at 11:14 PM | Comments (0) | TrackBack

コンピュータ内のファイル整理

実生活では、即だらしない人の烙印を押されてしまいそうなこんな整理法だが、コンピュータの中では結構有効だと思うのですがやっぱりだらしないですか? みなさんのオススメ整理法があればコメントやトラックバックどうぞ。
では、僕がいつも使ってる手を。 WindowsなんかでよくあるのはOSのインストール。さて、OSを再インストールときにMyDocumentsにあるファイルはどうしてる?まぁ、そのまんま別の記憶媒体なり別のマシンなり、ネットワークドライブなりにファイルをまとめてコピーして再インストールが終わったら同じようにMyDocumentsへ戻すというのが一般的だと思う。ここで一工夫。例えば再インストールした後に、まっさらなMyDocumentsに例えばoldなんてフォルダを作る、そしてバックアップを取っていたものは全てそこにそのまま入れちゃうんだ。毎回再インストールをする度にこれをやっていると、歴代の持ち越したファイルがMyDocuments/old/old ....という風に「OSのインストール」という単位に時間ごとにフォルダ階層が深くなっていく。あと、oldフォルダから必要なものが出てきたら、これをまず、今のMyDocumentsフォルダに直接持ってくる。すると参照しなくなったファイルほどフォルダ階層の奥底に眠る、ということになる。これも「超整理法」の一種だと思うけど、これするだけで結構すっきりするのでお勧めです。僕もこれは、本か何かでこういう方法を知ったんだけど。

でも、僕の一番の悩みは、WindowsのMyDocumentsと、cygwinの$HOMEをなんとかして統合したいんだけどいい方法が思いついていないことだったりする。

Posted by money at 4:21 PM | Comments (2) | TrackBack
Powerd by FC2.com
since 2/Feb/2004