June 30, 2004

人はなぜウェブログを書き続けるのか

Asako Miura, Ph. D. (Social Psychologist): KSP終了しました

「それはね、そこにウェブログがあるからだよ」

なんて話ではなく、インターネット上のコミュニティツール、情報発信ツールとしてのウェブログに着目した社会学の真面目な研究発表の資料が公開されています。
おそらく、我々エンジニアとは視点が違うはずなので、「いや、こういう側面もあるんじゃ?」なんてことを言いたくはなるが、概ね一般論としては、間違ったことは書いてないと思った。

個人的には、こちらにも言及されているように、これから先にフォーカスした話を呼んでみたい。例えば、下世話な話になるが、「ウェブログを書く人と書かない人で、出世のスピードに差異は出るのか」とか、「ウェブログ書いてる奴の方が、生涯獲得賃金が何%高い」とかって調査結果が仮に出るとすると、それはそれで面白いと思うのだが、ありえんな。

Posted by money at 2:53 PM | Comments (6) | TrackBack

ライブドアバッファローズ!?

なんか、言いにくいなぁ。
いっそのこと、ライブドアの持ってるプロダクトを前面に出して、
「オペラ・ライブドアーズ」ってどうよ?

商品名を頭につけてもいいんでしょ?「日本ハム」とか。(違)

あ、猛牛打線じゃなくなるのか。猛扉打線。

それにしても、これまでと違う業種の企業が野球チームを持つようになるのは賛成です。いつまでも、電鉄会社、食品、巨大マスコミだけのもんでもないしね。
NTTが球団を持って、全試合、フレッツでストリーミング生配信なんてどうよ?

そんなアタシは、当然ながら、「虎液」が体内に流れています。

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

SprngにAspectJを統合

本家のSpringframeworkのメーリングリストにて、ロッドジョンソン氏による、SpringとAspectJの統合についてのメールが流れた。 以下は、それの意訳の試訳の超訳。

みなさん、

僕はこの週末、Spring/AspectJを統合するための作業をいっぱいやった。ファクトリメソッドのIoC拡張をやった以外は(これは、これでとても有用なんだけど、大部分はAspectJの統合のためのものだ)、Springの実装に手を入れないといけないものではない。つまり、実際にどう動くかを確認するためのただの実験だ。

この努力の成果は、aspectjディレクトリ配下の"sample"モジュールに置いてある。

これは、teacher,bankという2つのサブプロジェクトをもつEclipse AspectJプロジェクトだ。

TeacherはAdrian Colyerのgirl/boy/teacherの例を基にしている。これについて、彼はTSSシンポジウムの後、自身のブログで手短に触れている。Dependency Injectionを使ってどうやってアスペクトを設定するか、というSpring/AspectJを統合する上での基本的な問題は彼が解決してくれたことに感謝したい。(ところで、あるアスペクトが使われる前に設定されていることを保証するために"depends-on"属性を使うことに注意して欲しい。Adrianのコードで使われている特別なアスペクトの初期化ビーンは必要としない)

bankというのは新しいサンプルで、エンタープライズで用いられる適切なシナリオをいくつか示したものである。これは、粒度の細かいアカウントオブジェクトを管理するBankインタフェースに基づいたものだ。これは、Spring DIを使って設定されたアスペクトとを使って、これらのオブジェクトにアドバイスを注入するのにAspectJを用いている。粒度の細かいオブジェクトにアドバイスを注入するのは、Springの自前のAOPフレームワークのようなプロキシベースのソリューションがうまく適合できない問題だが、AspectJはこの点では完璧なんだ。

私は今、Springで"perthis"アスペクトを設定できるようにするといったような、いくつかの難解な機能に取り組んでいるが、Spring/AspectJ統合化の本質はここにあるのだ。私はこの数週間で、サンプルモジュールにコードを追加してブラッシュアップしようと思ってる。そして、7月中に、個別のサンプルとしてダウンロードできるようにリリースするつもりだ。

私は、AspectJの統合は多くのSpringユーザの役に立つだろうと思っている。これは、Spring 1.1での新規機能の大きな1つになると思う。私は、AOPに興味をもつユーザのみなさんにこれを使ってもらって、是非、フィードバックコメントや貢献をお願いしたい。

ところで、同じアプリケーションの中で、AspectJとSpringの自前のAOPを一緒に使うのは別に矛盾することじゃぁありませんぞ。

現状、aspectjのサンプルにビルド用スクリプトは用意されておらず、Eclipseにお任せの状態だ。だからビルド用スクリプトの寄贈はいくらでもウェルカムだよ。

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

J2EE5.0?

バージョン番号を5にするんであれば、J5EEになるんじゃないの?

わけわからん。

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

アジャイルでオフショア

この道はいつか来た道... REBOOTED: アジャイルを使ってオフショア開発

知らぬ間に、マーチンファウラー氏の原文がアップデートされてました。どうりで、ここ最近、原文から飛んでくる方が多数いらっしゃったわけですね。すいません。早急にキャッチアップします。しばしお待ちを。

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

June 28, 2004

Spring Framework 当面のロードマップ

本家の[Springframework-user]MLにてロードマップの発表がありました。以下、そのメールの意訳の試訳の超訳のようなものです。ご参考まで。

皆さん、こんにちは。既にご存知の方もいらっしゃるかと思うけども、次のリリースは、1.1RC1とすることに決めました。これは、一旦1.03としてマイナーリリースを出すのではなく、直接1.1のリリース候補にする、ということです。主な理由は、既に、1.1を名乗るにふさわしい新しい機能がCVSにコミットされているからです。
現時点での予定では、以下のような新しい機能を盛り込んだものを7/11に1.1RC1としてリリースするつもりです。

*Cglib2AopProxyの実装をリファインした
*BeanFactoryでスタティックなファクトリメソッドをサポートする
*メソッドベースのDependency Injection(DI) 別名ルックアップメソッド
*より強力なルート/子 ビーン定義コンセプト
*同じ名前でクラスパスリソースを検索するための”classpath*"プレフィクス
*アプリケーション開始イベントの取り扱い(Muleとの統合を考慮)
*入れ子トランザクションのサポート(JDBC3.0のセーブポイントによる)
*DBCオペレーションパラメータとしてのカスタムSQLタイプバリュー
*JDBCオペレーションパラメータ(LobHandlerによる)としてBLOB/CLOBバリュー
*便利なバッチ操作用BatchSqlUpdateクラス
*JDO2.0 互換の準備としてJdoDialectのりファイン
*JdoTemplateに便利な操作(HibernateTemplateによる)
*JDO用に、OpenPersistenceManagerInViewInterceptor/Filterを追加
*Springリソース管理で永続的なQuartsジョブのサポート
*HTMLチェックボックスの明示的なサポート(field marker パラメータによる)

これらの機能は全て既にCVSに登録されていて、レビューできるように公開されています。我々は、次の2週間をみなさんのフィードバックに感謝しつつ、レビューとリファインに費やすつもりです。

7月末までには、1.1の最終版のために、以下の点についても検討するつもりです。

*SQLException 変換の増強
*JDBC3.0の自動生成キーのサポート
*JMSメッセージ送信(サンドボックスから移動)のサポート
*基本的なJFS統合用ヘルパー(既存のStrutsヘルパーに類似)
*(JSP2.0, Velocity, FreeMarker用)単純化マクロの形式化

残りの追加要望は全て1.2(秋には出したいな)以降に持ち越されました。一番主なものとしては、PortletのサポートとJMSサポートでしょう。さらに、Keithのルールベース宣言的バリデーションはサブプロジェクトになり、最初の安定化バージョンのリリースはSpring1.2の中で行われると思います。

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

GMailアカウント締め切りました。

この道はいつか来た道... REBOOTED: GMailアカウント

多数のご応募、ありがとうございました。当選者の方は、こちらからご連絡を差し上げています。残念ながら、こちらからご連絡を差し上げていない方、ご希望に添えなくて申し訳ございませんでした。また、機会がございましたら、宜しくお願いします。

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

お料理占い

はてなダイアリー - koichikのひとりごと

やってみた。

あなたを料理にたとえると、・・・点心族 春巻きです。

「点心族」の特長


  • 野心的。

  • パワフル。

  • 欲張り


「春巻き」なあなたは、
「春巻き」なあなたは、「点心族」のなかでももっとも欲張りなタイプです。それは、あなたの強い向上心の表れでもあります、周囲からすると、いつも元気で才能があり向上心が強いため、「欲張り」というふうに移ってしまうのでしょう。

「春巻き」なあなたのベストパートナーは


  • スケールの大きな組み合わせ   「めん族」

  • 自分の才能を引き出せる    「軽食族」

「春巻き」なあなたのお値段は


  • 一人前 947円

今日の「春巻き」なあなたは
今まで努力してきたことが、花開く日になりそうです。また、うまくいってることでも、もう一度見直してみましょう。


うーん、微妙。。。

Posted by money at 11:22 AM | Comments (0) | TrackBack

GMailアカウント

この道はいつか来た道... REBOOTED: GMail
結構、需要があるようで、ないのでしょうか?それとも僕の周りはみんな既に持ってる、ということか。 えー、あと3人の方、ご招待できます。僕と直接面識がない方でももちろん構いません。 ご希望の方は、こちらまでご一報ください。 
Posted by money at 2:16 AM | Comments (1) | TrackBack

所得格差は悪?

NIKKEI NET:経済 ニュース

家計の所得格差が広がり続けている。


パレートの法則に従うと仮定すると、やはり、意図的に所得格差が縮小するように恣意的な操作がなされている、と考えるべきなんだろう。日経の記事を読んだ限りでは、所得格差が広がるのはよくない、みたいなことをいいたげな行間だったのだがどうなんだろう? 所得格差が広がるのが問題なのではなくって、所得格差がそのまんま社会的身分につながり、自分の属する階層から出ることが困難になることが問題なのだと思う。所得格差には何も問題はないはず。

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

June 27, 2004

EJBの使い方

はてなダイアリー - koichikのひとりごと

それでもEJBは注目と期待を集め続けてきたようですが,多くの人が必要としたのは「ビジネスコンポーネント」を実現する技術としてのEJBではなく,単に宣言的トランザクションやO/Rマッピングを使いたかっただけというのが現実のようです.不幸にも,それらを実現する最も身近な存在がたまたまEJBだった,というだけのこと.


この文を読んで思い出した、とある人がおっしゃってたことば。
「みんなねぇ、ITだITだって騒いでますけど、だれも、インフォメーションなんか求めてないのです。みんなが求めてるのは、あくまでもデータです。」と。

つまり、データかを有機的に結び付け、それが情報になるのだが、そんな高度で抽象的なことを望む人はいなくて、あくまでも、データであり、テーブルであり、ちょこっと便利な、SQLクライアントが欲しいだけ。だから、本来はもっと使われるはずのEJBが、しょせん、宣言的トランザクションだとか、ORマッピングだとか、そういう、小手先の技術をまかなうものとしてしか使われなかった、というのが真相なのではないだろうか。
僕は、元(?)OODB屋なので、ユーザにデータベースを直接触らせるべきではないと考えているが、データベースを直接触りたがるユーザが多すぎるような気もする。

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

EJB論

はてなダイアリー - koichikのひとりごと
以前に、koichikさんの「EJBはすでに死んでいるというエントリを読ませていただいて、とても面白かった。でも、それが、とあるメーリングリストで物議となっているようで、いささか宗教論争のようだ。でも、我々エンジニアはそれぞれの要素技術を道具としてソリューション(あるいは現実に動くシステム)としてアウトプットを出すことが重要なんであって、その道具として使える、使えないというのは、それぞれの置かれている立場や、解決しようとしている問題、あるいはコストだとかいろんな面で判断するんであって、koichikさんの「EJBは死んでいる」という発言に対し、外野が「それは間違っている」と反論するのってなんか筋違いのような気がする。koichikさんは、彼の立場から「EJBは使えないー」と判断しただけであって、もちろん、使えると判断する人もいるだろう。それは、その人が、EJBを使って素晴らしいシステムを作ってしまえばよくって、「ほら、EJBって使えるでしょ? これがあれば、楽できるし、信頼性の高いシステム作れるんだよよ。まぁ、使う、使わないはあなた方の勝手だけどね」でいいんだと思う。それをどう評価してどう取り入れようがそれは、その人の責任でやればいいわけで。僕は、使える、使えないの不毛な議論なんかではなく、「使えるんだ」という人による、「実績」だとか、実際に動いているものだとか、あるいはこういう風に使うといいよ、とか「適用事例」だとか、もっと先の話を知りたいと思うのだ。

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

June 22, 2004

Spring Frameworkの日本語メーリングリスト

って、まだないような気がしてますが、需要ってあるんでしょうか?
もし、ある程度の需要があるようでしたら、立ち上げてみようかと思います。
興味のある方、いらっしゃいましたら、コメントなりトラックバックなりいただければ、幸いでございます。

Posted by money at 4:09 AM | Comments (2) | TrackBack

Spring Framework リファレンス

第5章まで、最新にキャッチアップ完了。

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

June 21, 2004

琢磨、表彰台

F1アメリカGPにて、佐藤琢磨が表彰台に上った。日本人としては、鈴木亜久里氏以来14年ぶり2度目の快挙らしい。いや、すばらしい。でも、それよりもびっくりしたのが、佐藤琢磨がゴールに駆け込み、チェッカーフラッグを受けた瞬間から番組中に流れたBGMが、「Rock'n Roll Gypsy」だったこと。なんか雰囲気に合ってるような、合ってないような微妙な選曲に、僕は涙した。担当者の方、いい趣味してます。

Posted by money at 11:54 AM | Comments (2) | TrackBack

June 20, 2004

GMail

最近、あちこちでGMailのinviteの話をよく見かけるようになったなぁ、と思ってた。確かに僕のアカウントでも、ここ数ヶ月、inviteができるようになってたんだけど、人数制限があるのを知らなかったので、なんだ、もう事実上、誰でも使えるのか、ぐらいに思っていたら、実はinviteできる人数に制限があることがわかった。ってことでどうやらあと4人の方をご招待できるようです。ご希望の方いらっしゃいますか? 欲しい人、オンライン、オフライン問わず連絡ください。なお、申し込み者多数の場合は、抽選とさせていただきます。当選者の発表は、メールの発送をもって替えさせていただきます。

Posted by money at 5:04 PM | Comments (2) | TrackBack

June 16, 2004

Spring Framework リファレンス

第3章まで、最新版にキャッチアップしました。微妙な違いのみ。

Posted by money at 6:33 AM | Comments (0) | TrackBack

June 15, 2004

アナパタは難しい?

概念モデルが理解できないのなら、その部門ユーザーは開発プロセスに参加すべきではないでしょう。これまでは、部門ユーザーが理解できないのをいいことに開発者だけで勝手に進めるということも往々にしてありました。しかし、これはこれでうまくいきません。

ファウラーたん、日本のエンジニアを買いかぶりすぎ。部門ユーザが理解できないならまだしも、開発エンジニアが理解できていませーん。だって、抽象的な話ができる人材がどれだけいるよ?
打ち合わせで、話題を限定的にしたくなくて、どうしても抽象的な議論にせざるを得ない場合というのは多々ある話。当然、その中で「じゃ、具体的な例を出してよ」というのもありだと思う。ここで、例というのはあくまでもサンプルであり、議論の対象の中の一インスタンスであるに過ぎない。でも、一旦具体例を出したことによって、議論が、それ1点のみにフォーカスしてしまう、ということがよくある。正直、抽象的な議論ができない人間がソフトウェアの開発はできないと思うけど、抽象的な議論のできるソフトウェアエンジニア、って思いのほか少ない、というのが、僕の実感。 こんなこと、僕の周りだけなのか?

モデルの扱いをきちんと理解し、それを実装するには時間がかかるのです。最初から完ぺきなアイデアを得るのは難しいでしょう。この世界はそういうふうにはできていないのです。
神の思し召し。ありがたく拝聴せよ。

でも、これだけ日本のソフトウェア界を代表する早々たる面々を集めてはいるが、内容が薄すぎないか? 編集の都合でそう見えるだけなのか? それにしても、DDDマンセーですな。僕も、まだ読んでる途中ですが、得られるものは大きいと感じます。 早く、邦訳でませんか?

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

June 14, 2004

日本一速い光ファイバ

今日出張のために、駅に向かうと、駅前で某電力会社系ブロードバンドな方が、チラシを配ってた。そこで、そのバイト君が一言。「日本一速い光ファイバをご用意しております。是非、お試しください。」

いや、あの、私の記憶が確かならば、古今東西、光の速度は一定なのですが。。。あなたは、アインシュタイン博士に喧嘩を売るとですか?

Posted by money at 9:05 PM | Comments (1) | TrackBack

アークエネミー@東京初日

行ってきました。ALL AREA ACCESS OK なパスでした。サウンドチェックも見学させてもらいました。ショータイム中は、関係者席で見たのですが、なんとお隣の女の子は、マイケルアモットのお嬢さんだそうな。ライブ終了後、楽屋にお邪魔して、ビールをもらった上、メンバとも握手してきました。 感無量とはこのことかと。 で、僕を招待してくれたフランス人の友人は?というと、ライブ中、リハーサル中は、PAコーナーやらあっちゃこっちゃでビデオ撮影、その成果は、終了後、楽屋にてメンバがそれをみながらなにやら反省会といった感じ。もう、満腹です。 フランスからの友人F氏に感謝。ありがとう。今度会うときまでに、英語鍛えます。

ちなみに。
車で彼らのCDをかけてる最中、「このボーカル、女性だよ」というと必ず驚かれる、というアンジェラ・ゴソウ女史ですが、とても小柄でチャーミングな女性でした。飛行機に乗ったときに、フライトアテンダントにまぎれててもきっと違和感ないと思われます。でも、ステージだと大きく見えるんだよなぁ。これもオーラのなせる業か。

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

June 13, 2004

Spring Framework リファレンス 5章

かなり、間が空いてしまいましたが、Springフレームワークのリファレンス第5章をお届け致します。そろそろ大きくなってきたので、今回から章ごとにHTMLファイルを分割しました。 また、先日1.0.2がリリースされましたが、5章については、1.0.1の段階のリファレンスを底本としています。なお、1章だけは、1.0.2バージョンに追従積み(変更箇所がないことを確認済み)です。2章以降も引き続き、キャッチアップの予定。 なお、いつものとおり、誤訳等のご指摘は大歓迎でございますので、なんなりとご指摘いただければ、幸甚でございます。また、今回の5章はAOPがテーマでであり、私自身、訳語があやふやな点が多数ございます。これは、ワタシ自身の不勉強ゆえのものですが、これについてもご指摘いただけると幸甚でございます。 では、お楽しみください。

誤訳のご指摘等のタレコミにつきましては、tkaneda@gmail.comまで。

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

人名用漢字追加

人名用漢字追加 「苺ちゃん」「牙君」などOKに


追加するのは選択肢が増えていいんだけど、文字コードのコードポイントがちゃんと定義されている文字なんだろうか?一部に今回新たに異字体が追加されているのが特に気になるところ。戸籍関係、自治体システム担当者殿の苦労がしのばれます。やっぱりなければ、外字対応ですか? 外字という考え方を捨てない限り、電子政府、いーがばなんて夢物語なんだがなぁ。
たぶん、使っていい漢字を列挙する際に、「この漢字は、コンピュータでは表示できません。」って断り書きは最低必要だと思う。くさなぎくんの「なぎ」の字とかさ。
個人的には、異字体を含めて、「文字」の正規化が必要だと思う。言語学的、文化的に許されるのかどうかは別にして。そうしないと、知らず知らずのうちに、むやみに、社会システムが高コスト化してしまうと思われ。

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

初ハワイ

hawaii.png

遅くなりましたが、友人の結婚式にご招待いただき、ハワイに行ってきました。まぁ、ここには書ききれませんので、サボります(そのうち、こちらにアップされるかもしれません。)が、楽しいひと時を過ごすことができました。今回の主役であるイナミ氏今嬢はもとより、現地でお会いした、ケイちゃんめぐみさんガクさんと信子さん、ゴト薫さん、かっぱちゃん、カントク、ぱるちゃん、エリザベス改め千夏の皆様(順不同)、大変お世話になりました。今後ともよろしくお願いします。最後になりましたが、改めて。イナミ、今嬢、おめでとう。末永くお幸せに。

P.S.
で、次開催の方、場所はどこ? 今度はニュージーランドあたりのリゾート地でやんない? モナコとかでもいいぞー。

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

テスト軽視

で、ソフトウェアというものはちゃんと動いているかを確かめるのがとても難しい部類に属するというところじゃないでしょうか?

本来はそのために受け入れテストやQA部門があるのでしょうけど、ちゃんと動いてない気がする。

日経ITプロでもなぜテストは軽視されるのか?という記事があるくらいですし。


・有能な人材を人海戦術的に見える(?)テスターに回すだけの人的リソースがそもそもない。(テストするぐらいなら設計とか検討してよ!と思ってしまう。) →この時点でテスト工程が軽視されている。
・実は、他の産業に比べて試験工程の重要度が高い
・でも、検討、設計にウェイトを置けば試験の重要度が軽くできる、という妄想がはびこっている
・試験は、プログラム書いたものと別の人間が実施すべきだ、という仮定に立つと、プログラム書ける人間を試験工程に温存させる余裕がない。→結果、プログラムが書けない人間が試験にあたる。 → プログラム書ける奴はプログラム書け、書けない奴は、試験要員に回せ、というロジックが成り立つ?
・理想は、設計者が試験することだろう。
・でも、試験工程やってるころって、設計担当って、次のフェーズの検討やってたりしない?
・あと、有能な人材って、試験工程時は、バグ発生時の解析担当だったりするなぁ。
・やっぱり、それらに回せない人間が試験やるしか
・試験って、ブラックボックステストと称して実装を知らない人間を当てるべき、という風習もあるねぇ
・でも実装を知らない=何も知らないじゃないはずなんだが。
・プログラム書けない、コンピュータの基本すら分からない新人が余ってるんだけど、なんか仕事ない? → 試験のオペレータでもやらせとけ。
・QA部門がちゃんと機能するためには? → 要件定義からQA担当をプロジェクトに張りつけなきゃ。 → そんなに人いるわけないだろ。 → でも、出荷前にチェックはするよ。それがQAの仕事だもん。 → 要件知らずに、何をチェックするの?

ざっとこんなもんではないかと。うーん、デフレスパイラル。何とかしたいな。

P.S.
どうやら、ソフトウェアへの情熱は失ってないようです。じゃ、なんでモチベーションが落ちてるか。それは、ちとここでは書けません(笑)。でも、ありがとう。>K氏

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

June 12, 2004

役得?

ひょんなことがきっかけで知り合ったフランス人。きっかけのいきさつはこちら。そんな彼が、アークエネミーのジャパンツアーのために来日するってんで、上野まで迎えにいった。会ったのはもちろん初めて。以前チャットで、コンピュータショップのオーナーやってる、って話だったので、なんだ、桁外れなメタルオタクなのか?と思いきや、ツアーのバックステージ等のカメラマンで、後日発売するDVD用映像を作るらしい。なんだ、ツアースタッフじゃん。他にも、アイアンメイデン、WASP、ジューダスプリースト等のワールドツアー同行したこともあるとかでいろいろバックステージパスを見せてくれた。そんな彼の計らいにより、明日のアークエネミーのバックステージパスを入手できるらしい。感謝。マイケルアボットとかアンジェラに会えるかな?
そんな彼には、とりあえず、御茶ノ水DISK UNION 奥の院改め、ヘビィメタル館をご案内しますた。そこで僕は、彼お勧めのフランスのバンド、MALEDICTIONのCDをゲット。ここのギターもご学友。マイケルアボットも友達、ってやっぱり、なんか変な奴かも。でも、ちゃんとフランスからお土産に、カメラとかビデオとか機材が重いにも係わらず、本場のシャンパンのボトルを持ってきてくれる律儀なところも。結構、いい奴だ。やっぱり、フレンチなまりなイングリッシュは聞き取れねぇ。(いえ、アメリカンなイングリッシュもききとれません、はい。)

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

すげー

すごいです。 このまさに思いつきのようなタイトル(本当に思いつきらしい)から、繰り広げられる日本文化論(?)。 以前に、どっかで山形浩生氏が、橋本治のことを誉めてた文章を読んだことがあるんだけど、そのときは、「え?あの桃尻娘を書いた人?」と正直思ったんだが、山形氏が絶賛するのがちょっぴり分かったような気になれました。中身的には、結構飛躍っぽい(? 僕はあんまり違和感なく読めた。)ところもあるんだけど、それも気持ちいい飛躍として読めたのも大きい。

上司は、自分よりも経験もあるし、いっぱい給料もらってるし、自分よりも有能で当たり前だ、という前提条件と現実とのギャップに悩んでる方(僕もその一人)に読んでいただきたい一冊。なんだ、上司をバカにしてもいいんだ(うそ)。

Posted by money at 6:48 AM | Comments (0) | TrackBack

モチベーションの維持

今さらながら、モチベーションを維持しつづけることの難しさに遭遇しています。おそらく、社会人になって初めてでしょう、ここまで仕事に対するモチベーションが欠如しているのは。今はひたすら、降りてきてくれるのを待つ毎日です。そう、モチベーションがあるときって、何か、こう、魂のようなものが降りてきて、憑いてくれてるような気がするんです。彼に動かされてるようなものかな、と思います。その彼がどこかへ行っちゃったような、そんな感覚です。彼は、ターボエンジンみたいなものかもしれません。能力ないぶん、努力とターボエンジンだけが頼りです。そのターボが全く効かない。そんな中、買ってきた本が、これ。
なぜ、「頑張っている人」ほど、うまくいかないのか?
たぶん、普段の僕だったら、手に取らなかったかもしれません。これを機会にして、モチベーションのコントロールが身につけばいいなぁ、と思ってるのですが。。。なんか、いい方法知りませんか?あなたのモチベーションを維持する方法を教えてください。

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

June 9, 2004

マーチン・ファウラー特別ラウンドテーブル 現場レポート [前編]

ファウラー 基本的に、一括請負契約という考えは危険な幻想だと思っています。

平澤 それは開発者側の立場から?

ファウラー 開発者と発注者、両方の立場から。(中略)一括請負契約は、開発を開始する前に相手の要求仕様が完全に理解できている場合にはいい考えですが、実際にはそんな状況にほとんど遭遇したことがありません。

一同 (笑)。

いやいや、こんだけ早々たるメンバが集まっていながら「一同 (笑)。」って。笑ってる場合じゃないだろ。
一括請負契約(僕の会社でいう、製造請負)がダメだとすると、残るは業務委託、つまり、人貸し頭数ビジネス、要するに人月計算ということになると思うんだが、マーチンは本当にそういう意図だったんだろうか?
一括請負契約がダメのは、GOALが見えない段階で見積もりをし、GOALが確定しない段階でGOALを保証する契約だからだ(これが、マーチンが言うところの『一括請負契約は、開発を開始する前に相手の要求仕様が完全に理解できている場合にはいい考えですが、実際にはそんな状況にほとんど遭遇したことがありません。』という言葉)。
だから一括請負契約は、開発側が全てのリスクを背負う契約とも言える。それを顧客、開発側双方でそれなりにリスクを分担しましょう、というのが、アジャイルの基本姿勢だと思う。そうすることで一方的に押し付けるのではなく、両者が協調する、と。
でも、実際は開発側も一括請負契約であることをエクスキューズに使うことが多い。曰く、「あれだけわがままな仕様変更に対応したんだから、少しぐらい品質は目をつぶってよ」とか。
ケントベックだったか誰だかは忘れたが、アジャイルで細かく刻んだイテレーション単位で契約するんだ、という話を以前にどこかで読んだ記憶がある。こうすることにより、あるイテレーションの中では、これまでの一括請負契約の形にはなるが、仕様変更は次のイテレーションに回すとか柔軟に対応でき、イテレーションの中では、GOALが明確になるのでリスクは減るというわけだろう。でも、これってベースになるシステムは既にあって機能追加がどんどん発生している状況ではとてもうまくいくだろうけど、最初のベースとなるシステムを開発するフェーズでは難しいような気もする。僕は、このフェーズをうまく回し、継続的イテレーションを軌道に乗せるまでのうまいやり方が知りたい。

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

ITは職人の世界?

 しかし話を聞いていると、ITプロジェクトのお客さんは素人が多いようだ。

 さらにITプロジェクトはベンダーも素人である場合が少なくないのではないか。

 素人同士が仕事を進めて上手くいくわけがない。
上司に恵まれないSEのために〓自分戦略策定ブログ α

まあ、今のITプロジェクトが職人芸なのは誰しもわかっていることでしょうが…

I現状は、ITの素人とITの素人が無い知恵を絞りながらなんとなく作ってるような気になってる、というのが正解ではないかと。
では、ITのプロフェッショナルはどこにいるか?というと、僕はベンダの製品開発チーム、研究機関にしかいないのでは?と思っている。開発ツールで商売しているベンダの売り文句は、必ず「だれでも簡単に使えます!」であって、「素人が触っちゃ、怪我するぜ」なんてツールは基本的にない。(実際は、そんなツールばっかりだけどねぇ) まぁ、本来職人技であるはずのシステム開発を素人集団作業になったのはソフトウェア工学が製造業のメタファをソフトウェアに持ち込み、工場のベルトコンベアー式流れ作業よろしく単純作業にブレイクダウンしようとした結果、その建前だけが一人歩きしてしまったのが原因ではないだろうか?と勝手に想像している。製造業メタファで語るとすると、例えば、テレビの設計というのは、電子工学が分かってないと当然ダメなわけで必然ながら、電子工学のプロフェッショナルが行うことになる。でも、工場の生産現場は、電子工学のプロがいる必要はない。
翻ってソフトウェアの開発を考えると、ソフトウェア工学を学んだプロフェッショナルにしかソフトウェアの設計ができないか?というとそうでもない(本当は、できないといいたいところだが)し、テレビの設計というのが、設計図(つまり、回路図)を書いて、試作して動作確認して初めて、どうやって大量生産のラインにのっけるかを考えるのに対し、ソフトウェアの設計と言った場合にその粒度は人それぞれ。しかも、製造工程にコストがかからない(つまり、ファイルコピーだけ)ので、ハードウェアで言う、設計、試作工程(研究所内で特定のプロフェッショナルだけが携わる工程)をソフトウェアの製造工程にマッピングしてしまっている(さらに、ここはマンパワーを要することもある)のでごっちゃになっているのだ。ソフトウェアの開発を工学的見地から研究する、というソフトウェア工学のテーマは必要なことだと思うが、実際の開発現場としては、「工学という言葉を使ったことが全ての誤解の始まりである」と思わずにおれない。ソフトウェア工学の研究者出身の現場デベロッパとしては、とても歯がゆい思いである。

話は戻るが、ITプロジェクトの場合、最高意思決定者がド素人なんだよなぁ。昔、(社会人1年目のころ)偉い人に、「君、プログラム書けるの? どれぐらい書けるの? すらすら書けるの?」と聞かれたときは、めまいがしますた。この一言で、ソフトウェアというものが、世の中で理解されていないことを痛感したことがあります。文法さえ知ってればプログラムが書けると誤解してる方も多数いらっしゃいますし。日本語かける奴は、日本に1億人ぐらいいるが、小説書ける奴は限られるんだ、ということを理解していただくにはどうすればよいのだろうか。

まずは、ソフトウェア開発から「製造工程(いわゆるメイク、テスト工程」という言葉をなくし、ソフトウェア開発は全てが設計工程なんだ、というところからスタートしないとダメか。

でも、「コーヒーとソフトウェアは素人が作るもの」という言葉もどっかで聞いたことあるしな。素人が作るという前提で開発環境(ツールや、理論等)を整備しないとダメなんだろう。

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

June 4, 2004

Spring Framework 1.0.2 リリース

リリースノートから、適当訳。あんまり信用しないように。

* 「mock」ソースツリーと「spring-mock」のjarファイルが新規追加。
* シャットダウン時にガベコレを有効にするためにCachedIntrospectionResultsがJavaBeans Introspectorをフラッシュするようにした
* 非侵略的なプロトタイプビーン生成のための、ObjectFactoryインタフェースとObjectFactoryCreatingFactoryBeanを新規追加
* Antスタイルのコンフィグロケーションパターン用にAbstractXmlApplicationContextがPathMatchingResourcePatternResolverを使うようにした。
* BindExceptionのgetFieldErrors()とgetFieldError()メソッドに"xxx*"というフィール ドパターンのサポートを追加
* JobDataMapと同様にQuartzJobBeanにビーンプロパティとしてSchedulerContextを適用
* UserCredentialsDataSourceAdapterを追加
* Rowをオブジェクトにマッピングする際に独自のRowCallbackHandlerの代わりに使うRowMapperResultReaderを追加
* AbstractLobStreamingResultSetExtractorとAbstractLobCreatingPrepagredStatementCallbackを追加
* DefaultImageDatabaseクラスの実装を再設計し、「imagedb」サンプルAPPを再度動くようにした。
* iBATIS SQL Maps 2.0 統合用クラスでSqlMapClientごとのDataSourceとページングされたリストのレイジーローディングをサポート
* ViewResolverチェインができるようにDispatcherServletが型によりViewResolverを判断できるようにした。
* SimpleFormControllerに「doSubmitAction」というテンプレートメソッドを追加
* AbstractWizardFormControllerで「_page」というリクエストパラメータをサポート
* "person.na*"/"person.address.*"形式のフィールドパターンをBindTagのパス属性に追加
* DelegatingActionProxyの代わりにStrutsのDelegatingRequestProcessorとDelegatingTilesRequestProcessorを追加

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

Spring Framework リファレンス

バージョンが上がってる。どこが変わったのかわからん。とりあえず、5章は今のまま続けることにします。もうちょい。

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

June 2, 2004

もったいない

清水健太郎容疑者を逮捕 4度目、覚醒剤所持で


なんとも、個性的な役者さんの芝居が見られなくなるのがもったいない。僕が気がかりなのは「首領への道」の続きはどうなっちゃうの?ってこと。島田組3代目桜井鉄太郎がぱくられたら、跡目はどうするのよ? やっぱり、越智が組長代行を務めるんだろうか。

Posted by money at 11:42 AM | Comments (0) | TrackBack

June 1, 2004

またか。。。

帰国しました。
さて、帰国していきなりだが、ワタシが一緒に仕事をしてみたいと思っていた優秀なエンジニアがまた一人我が社を去った。これで、今は全然違う部署にいて、僕の下で仕事をしたいと言ってくれて、そこから僕のところへの異動を希望し、その願いをかなえるために、社内のいろんな筋で働きがけをしたが、望み適わず社を去ったのは3人目ということになる。なんともやりきれない。こういうことが続くと社の部署間の壁というものがとても恨めしい。そんな壁すらを打ち破れず彼らを救うことすらできなかった自分のふがいなさを悔やまずにいれない。なんとかしてこの壁を砕かないといけないし、一部の意識の高い若い人たちが異動しやすくするように仕事を大きくしないといけないと心を新たにした。
新たな道へ旅立とうとしている、おそらくここを読んでる君へ今言えることは一つ。「輝く未来を手に入れられることを心から祈願しております。いつか必ずもう一度我が社へ呼び戻しますので、さらに成長しておいてください。僕も負けないように精進します。」

Posted by money at 1:30 AM | Comments (1) | TrackBack
Powerd by FC2.com
since 2/Feb/2004