12/10(Mon)
/** まーぼー丼にハマる */ 豆腐切って入れるだけだし(^^; お手軽でうまいです(^^) /** マニアック系雑誌 */ うちの新人君(って呼ぶには、もうすぐ半年だしなぁ(^^;)が、見つけてきた、 「UML Press」とかいう雑誌。 創刊になったばっかりらしく、目次を見たら興味をひくっぽい記事がいっぱい(^^) ちょうど、本を読む時間が増えたので、買ってみるのもいいかも。 とか思ってるところです(^^; 雑誌っていえば、この業界の人がよく買ってるっぽい、 「日経ほにゃらら」は、どうなんでしょうねぇ。 いまだかつて、ぱらぱら眺めたことぐらいしかないんですが、 どうにも技術の核心に迫って無さそうな気がして読む気が起きません(T_T) っていうか、大きな誤解? まあ、かつて読んでた、 「DB Magazine」だの、「Network Magazine」に戻るのも一つのテなんですが、 多分、全く新しいところに行った方が、身に付くことも多いでしょう。 ちなみに価格は1480円。 マニアック系雑誌の標準価格です。12/9(Sun)
/** 思い立っても実行できず... */ JavaWorldを読んでいると、jRefactory on JBuilderとか、SOAP/UDDI/WSDLとか、IIOSSとか、 いろいろ実験したくなることが出てくるが、時間的な問題は無いのに、 インターネットに接続できないので、どうにもならなかったりします(T_T) とりあえず2日ですが、ADSLにするまでは快適にならないだろうなぁ...(>_<; っていうか、情報から隔離されてる感が否めず。 インターネットに接続できないっつーのは、精神不安定になるかも(^^; /** なんかオカシクないか? */ Pentium4のCMナレーション。 「メールやインターネット、もちろん、デジタルだって楽しみたい。」 前半は、「インターネット = Web」と捕らえれば分からなくもないが、 デジタルを楽しむってどういうこと??? う〜ん。わけ分からん... もしかして、なんか深く考えすぎ? /** 日曜日は休みなんかいっ */ 近所のパン屋。 2件あるんですが、どっちも休みでした(T_T) 今、商店街のキャンペーンみたいのをやってて、 ポイントためると、なんか福引出来るらしいんですが、 日曜日の商店街は、かなり静まり返ってるっぽいです(^^; キャンペーンのアナウンスは、商店街中に響いてるんですが、 空しく響き渡ってるだけのような気がしたのは、きっと僕だけではないでしょう。 仕方ないので、オリジン弁当(弁当屋 + 惣菜屋; ハイブリッド弁当屋!?(^^;)で、 お弁当買うことにしました。 パン＆コーヒーで、優雅な午後を満喫♪ な予定だったのに、 なんとなく味気なかったのでした(T_T) ちょっと遠出して、オリンピックまで行けば、 パン屋さんが入ってるから、そこまで行けば良かったかなぁ...12/8(Sat)
/** お買い物♪ */ 本日は、「湘南育ちのヨーグルト」を3コパック78円でゲットしました♪ いつも食べてる、「牧場の朝ヨーグルト」とどの程度違うのかは分かりませんが、 とりあえず、値段だけで3パックも買ってしまいました(^^; あと、いつも飲んでる「野菜生活」1リットルのペットボトルなんですが、 いつものスーパーに無かったので、別のスーパーに行ってみたところ、 なんと「258円」でした。高い〜(>_<; というわけで、ちょっと離れたところにあるスーパーにも行ってみました。 が、「268円」でした。もっと高い〜(>_<; 仕方が無いので、自転車10分ほどのところにあるOlympicに行くことに。 ここで売ってる野菜生活は、198円であることは既に調査済みなので、 何の問題もなく、「198円」で買うことができました(^^) ついでに、1本25円ハンガーx8も買って、ハッピー♪ ちなみに牛乳は、先週に引き続き、「最上の郷牛乳」を、138円でゲット! 最初は、「とね牛乳」こちらも138円を飲んでいたのですが、 広告の品っつーことで、今のを飲んでたりします。 けど、どっちも味は変わらないけどね(^^; /** ついに自転車屋発見!! */ その名も、「茶輪古屋」。 ......大丈夫か?(^^; /** ふとん屋あらわる! */ 即撃退(-_-; っていうか、あやしすぎ... /** あんたの目は節穴か? */ 近所のTSUTAYAで会員証を作りました。 その際、名前＆住所の確認手段として、免許証を出したのですが、 まだ住所変更の手続きとかしてないので、(ちなみに、本籍はぜんぜん違うところで変えてないし(^^;) 今の住所と違うから、あかんかなぁ... とか思っていたんですが、ぜんぜん見てないらしく、オッケーでした(^^; おいおい! そんなんでいいんか!? 必要無いんですかねぇ...そんなことないと思うんだけどなぁ...... /** 近所のそば屋へGo! */ 近所のちっちゃいそば屋に行ってみました。 天ぷらそばが630円、かつ丼600円など、なかなかリーズナブルっぽい。 味も悪くはないっぽい。お客さんもいっぱい入ってたし。 昼ご飯 or 晩ご飯作るの面倒になったら、お世話になるかも(^^;12/7(Fri)
/** 晴れて */ 横浜市民となれました(^^) 転入届が拒否されなくて良かったです(^^; しっかし、区のはずれのせいで、区役所まで遠かった... 実家だったら、役場まで自転車で5分ぐらいなのに、 電車乗り継いで、大体30分ぐらいだもんねぇ(>_<; 事務手続きとかは、できるだけ少ない方が良いっぽです。 まあ、それほどあるとは思えないけどね。 /** 水増し請求(^^; */ なんとか遠回り or 高いルートを見つけて、交通費を高く請求しようという、セコい試みです(^^; まあ、それが通るかどうかは分からないんだけどね(T_T) でも、それしないと、一駅しかないから、 1ヶ月で3780円しかもらえません(T_T) つーわけで、実際バス乗ってみたりして、がんばろうと思います。 (→もっと別のところでがんばれっつー声もありそうだけどね(^^;) /** バス代 */ 実家の近くを走ってるバスは、距離に応じた課金になっていて、 遠くに行くほどお金がかかりますが、 こっちのバスは、一律な値段になってるらしいです。 なんでも、前者はイナカに多いとのこと(T_T) 前者の場合は、降りる場所にならないとバス代が分からないので、 降りるところでお金を払います。 後者の場合は、一律な値段なので、最初にお金を払います。 お金を払う場所は、運転手さんに見えるところじゃないとダメなので、 入口/出口の仕様が違ったりするのです。 つまり、後払いの場合は、真中とか後ろに入口、前に出口があり、 先払いの場合は、前に入口、真中に出口があるという感じです。 う〜ん。文化の違いってやつですかねぇ。 僕は、後払いの文化に慣れているので、 1駅乗っただけでも、一律料金取られちゃうのは、 なんかヤだなぁとか思ったりするんですが、 やっぱ、イナカものなんでしょうかねぇ(^^;12/6(Thu)
/** めっちゃ風邪...(T_T) */ だいぶ直ったっぽい(^^) いい感じです♪ /** 歩き... */ 会社から家まで、普段は自転車で15分程度なのですが、 今日はとある事情で、帰りだけ歩きました。 すると...35分もかかってしまいました(>_<; とても毎日どころか、週1回だってする気になれないねぇ(-_-; 僕が、歩くの遅いってのもあるんですが... やっぱ、自転車ですいすい〜と行くのが、一番良いみたいです(^^) /** JavaWorld */ ようやくありつける(^^; 読むものがいっぱいあって、困っちゃうねぇ(^^;; ぱらぱらっとページをめくってみたら、 一番最初の広告ページに、JRunの広告が載ってたんですが、 カスタムタグを使って、ごにょごにょしてたコードが、こんなにスッキリ☆ みたいなの書いてありますが、JSPにSQLが書いてある自体、 やっぱりModel-Viewの分けがうまくできてないってことで、僕的には却下でしょう。 なんか、VB(Power Builder) - Oracleな2層システムとかで使われてる、 表形式のコンポーネントに、データベースの表データを直結させて表示させる ってのに似てるかもなぁって思いました。 システム作って、それで終わりっ! っていうなら良いけど、 後々拡張とか、メンテとか入った時に、柔軟性低そうで怖いですね(^^; まあ、便利さの裏返しみたいな部分なのかも知れないですけど。12/5(Wed)
/** めっちゃ風邪...(T_T) */ やや回復(^^; でも、若干咳き込み気味... /** 要求定義工学 */ ようやく読み終わりました(^^) 読んでいて、「なるほど」と思うところはいくつかあったのですが、 特に印象深かったのは、以下の一節です。 > 非機能的要求を正しく勘案することに間違い、手抜かり、失敗などがあると、 > いったんシステムが完成した後にそれを修正することは、一般的に最も費用がかかり、 > また難しいと考えられる。非機能的要求を把握しなかったり満たすことに失敗すると、 > 絶え間なく変更が必要となることから、プロジェクトのキャンセル、役に立たない成果物、 > 不幸なユーザ、無秩序な構造のシステム、予算とスケジュールの超過、といった結果に至る。 う〜ん。恐ろしいですねぇ。 でも、非機能要求を要求仕様書に、「きちんとした形で」盛り込んでいるプロジェクトなんて、 一体いくつあるんでしょうか? オブジェクト指向開発において、最もポピュラーな開発プロセスである、 「ユースケースドリブン」という手法がありますが、 この場合、機能要求をユースケース図でモデリングし、それぞれのユースケースに対しシナリオを書き、 シナリオに現れた名詞や動詞に注目して、クラス図を起こして...とやると思います。 が、このプロセスには、非機能要求をモデリングする機会がないのです。 厳密に言えば、今僕がここで書いた「ユースケースドリブン」なプロセスには、 非機能要求をモデリングする機会がないのです。 ちなみに、良く聞く話として、 「システムが完成して、運用テストの一環としてパフォーマンステストをしてみたら、使い物にならない程遅かった...」 というものがありますが、これなどは典型ではないでしょうか。 (もちろん、プロセスの最後にのみパフォーマンステストを行うというところにも問題がありますが...) --- 一通り読んだ感想としては、一部「ラショナル統一プロセス入門」とかぶるなぁと思ったことです。 「ラショナル統一プロセス入門」は、あくまでも開発プロセスについて書かれている本なので、 「要求定義工学入門」のような、特定基本フェーズ固有の本を読んだあとに、 「ラショナル統一プロセス入門」を読んだ方が、よりRUPの理解は深まるのではないかと思いました。 とかく下流工程ばかりやらされがちなプログラマですが、 将来の、「知識 → 実践な応用力」のための礎作りと、 非機能要求定義のできない上司の監視(^^; のためにも、読んでおきたい一冊です。12/3(Mon)
/** めっちゃ風邪...(T_T) */ あかん...何もする気せん... こんな時は、実家からかっぱらってきた(^^; コーンポタージュスープがノドにも体にもいいね♪ /** 知識 → 実践 ＆ 過去 → 未来 */ 本とか、セミナーとか、その他もろもろで得られた知識を、 実際の開発現場で活かすためには、「知識 → 実践な応用力」が必要になると思います。 具体的な例を挙げれば、 オブジェクト指向の入門本なんかで、バスとか電車は同じ乗り物だから、 バスクラスと電車クラスは、乗り物クラスのサブクラスになります。 っていう、乗り物世界をオブジェクト指向モデリングする説明が書いてあったとします。 じゃあ、実際現場で扱っているシステム(たとえば、在庫管理システムとかね。)は、 どうやってオブジェクト指向でモデリングしたらいいんだろう? と、考えるのが、「知識 → 実践応用力」なのではないかと思います。 ところが、現場のエンジニアは「実践＝現場経験」に頼る傾向があるために、 あまり知識を付けようとしないようです。(してるヒマがないとも言う(-_-;) それでも通用しているのは、「過去 → 未来な応用力」があるからだと思います。 「過去 → 未来な応用力」な応用力とは、 Javaは、C言語と文法が似てるから、C言語マスターには覚えるの簡単だね。 というようなことです。 しかし、「過去 → 未来な応用力」な応用力は、過去あってのものですから、 今までみたこともないような手法が出てきた場合には、対応できなくなる可能性があります。 ------------------------------------------------------------------------------- 例えば、C言語 → Javaの応用を考えた場合、 まずC言語を学ぶのに、「知識 → 実践応用力」が必要になり、 Javaを学ぶのに、「過去 → 未来な応用力」が必要になります。 これは、ソースコードを書いて、コンパイルして、実行させれば、 「知識 → 実践応用力」が確認できるので、さほど難しいことではないでしょう。 こうして得られた実践経験は、実際の現場において、 「過去 → 未来な応用力」となって、有効に使われることになると思います。 ところが、データモデリング → オブジェクト指向分析/設計を考えた場合、 E-R図や、UMLが動作するわけではないし、妥当性検証(書いた図が正しいかどうかを確かめる事)が難しいので、 学ぶことが難しくなっているのだと思います。 そうした結果、実際の現場において、直接「知識 → 実践応用力」を使わねばならず、 うまく行かないことも多いのではないかと思います。 じゃあどうするか。 結局、実践に近くなるように、より多くの知識を付ける(より多くの情報を集める)しか、解決策は無いと思います。 よく現場の人間は、「本に書いてあることは、現場のことと程遠くて使い物にならないんだよなぁ。」 などと言いますが、それは集めている情報が少なすぎることと、 「知識 → 実践応用力」を発揮していないことが原因と考えられます。 ------------------------------------------------------------------------------- 最後に。 応用力それ自体は、どうやって身に付けるのか? う〜ん。これも難しいところだと思いますが、 知識 → 実践 ＆ 過去 → 未来 の変換プロセスを多く経験することなんじゃないのかなぁと。 目に見えるものではないので、成長を確認するのも難しいと思います。 ------------------------------------------------------------------------------- まとめ。 1) 将来においても通用する人材になるためには、「応用力」が大事だ。 2) 応用力を発揮するためには、インプットとなる「十分な知識」と「過去の経験」が必要だ。 ぜひ、Applicableな人材になりましょう!