「オブジェクト指向・システム開発」カテゴリーアーカイブ

@IT情報マネジメント:ペルソナとシナリオを用いたソフトウェア開発──実践編(後編) 1/2

@IT情報マネジメント:ペルソナとシナリオを用いたソフトウェア開発──実践編(後編) 1/2
後編登場。
複数のペルソナが必要なケースでは、思い切ってアプリケーションを分割するか、何らかの形でUIの分離が必要だと思ったり。実世界と同じく、システム化対象への関心がペルソナ毎に違うので、全く別の形のUI、機能が必要になるはず。それを無理に一つにまとめようとすると結局すべてのものにとって使いづらいものになってしまう。

伸びるエンジニアについて

sanonosa システム管理コラム集: 伸びるエンジニアについて
大変興味深い記事だったので、煽り無しで考察してみます。
この記事の中で、著者は以下の三つの資質をあげています。
【条件1:自腹で技術書を買っていること】
【条件2:全体を理解しようとしていること】
【条件3:プロジェクトをたくさん経験していること】
先ず条件1ですが、これは自己への投資意欲がある、基本的に自分の仕事に対する興味、情熱があるということでしょう。わたしはこれらが自分の技術力を伸ばしていくためには必要最低限の資質であると考えています。後、学習という点では、出来れば自分の専門外の知識に対する欲求の持続やそれへの学習のサイクルが個々の中に出来ればよりよいと思います。悪い意味での専門バカにならないためにも、そうしておいた方が身のためです。
次に条件2ですが、全体を見渡すとしても全体の定義が難しいですね。Javaや.netではいったいどこまで確認していけばいいのか途方に暮れてしまいそうです。その時々で、全体を定義していく必要がありそうです。
ただ、何かのきっかけを元にその周辺についての理解を深めていくことは重要でしょう。
これ以上書くとトランスパーソナルの話を書き始めそうなので、ボロが出ないうちに止めておこう。
最後に条件3ですが、これはもうやっぱり学習を力に買えるには場数を踏むしかないわけで、致し方ないなぁ。とにかく書くしかない所はありますが、そのとき重要なことは間違った知識、方法で書かないようにすることだと思います。間違ったことを反芻しても仕方がないことなので。(あーいっぱい遠回りしたよ)そういう点では学習過程でよいメンター・本に出会うことは本当に重要だなぁ。
というわけで、以上を自分の戒めとして今年もがんばっていきたいと思います。

カプセル化

構造化設計技法でのローカル変数による外部へのデータ構造の隠蔽と言うことの延長に、オブジェクト指向のカプセル化があるわけですが、なんか頭の中でスコンとその関係が抜けてしまっている人がいるんですよね。要は何のためのカプセル化か理解が出来ていない人。
それをアホだ馬鹿だ言うのは簡単なんですが、何で抜けてしまうのかって言うのが見えてこないとその人に対してどう対処して良いか解らないんですよね。オブジェクト指向勉強すればそれ以前の知識はいらないとか、基礎知識という土台なんかいらないぐらいの勢いって言うのはどこから来てるんでしょう。日経ソフトウェアのせい?
自分自身が痛い目に何度もあっているのにねーとも、思うわけですよ。気付け、何度も言ってるだろと。
やはりアホだ、馬鹿だと矯正するしかないのかもなぁ。優しくメンタリングするほどおいらは人間が出来てないしなぁ。
というようなことをここ読んで思ってみたりして。

ソフトウェアについての雑感: Windows 2000 以降対応って言うけど、Permission/Privileges は…

ソフトウェアについての雑感: Windows 2000 以降対応って言うけど、Permission/Privileges は…

Windows 2000/XP 対応を謳うのであれば、そもそもの設計段階から、運用管理の現場の声を聴きながら、構成してほしいものだ。そんなわけで、アプリケーションデベロッパなみなさん、がんばってください~。

ということをRFP(見積仕様書)に書いていただきたい。
これは頭に来た!とかで書いているのではなくて、私は(以前は)社内のシステム管理もしつつ、客様向けのシステムも作りますので、書かれている内容は解りますし、賛成ですが、たぶん一般的なデヴェロッパーの方々は感覚的にわかんないんじゃ無きかと。もう少し書くと管理者の苦労なんてマスとしての彼らには解りません。
基本的にデヴェロッパーやプログラマというのはデバッガを動かす必要もあって、恒常的に管理権限でログオンしている必要があり、これが普通の環境だと思ってしまいます。感覚的に制限ユーザーというものが存在すると言うことが認識できません。従ってそうしたユーザーでの仕様が無意識のうちに設計・試験から落ちます。
ですので、RFPに思われていることを書いていただけると、それは非機能要求案件とプロジェクトにきっと認識されるでありましょうから、問題なく制限ユーザーでも動作するソフトウェアが出てくるのではないでしょうか。
でもMSNメッセンジャーはなぜなんですかね。(W

サブジェクト指向プログラミング

とある日誌に書かれたサブジェクト指向プログラミング。
勉強不足で初耳。ということでインターネットのリソースを探してみました。
このIBM Research(ワトソン研究所)のこのページがリソースとしては基本のようです。
Subject-oriented programming Object-Oriented Programming-in-the-Large Flexible Integration of Object-Oriented Programs Non-intrusive Evolution
日本語の情報はほとんど無いようです・・・・・。
私の中ではまだ、オブジェクトもしくはICONIXでのロバストネス図を単位に、それらの関連性(本で言えばドイツ文学とか)を見つけて集合化して、その集合に対して共通の「何か」(ゲーテ的構文)を挿入するというイメージしか持ててません。英語が出来ないのもありますが、頭が足りません。
誰か漏れに優しく教えてください。

プログラマの本懐から2

共通ロジックの切り出しをサボって、コピー&ペーストプログラミングをやってしまったがために、ユーザー入力チェックの1カ所のコードのミスがすべての画面にばらまかれしまっていることはよくあります。~画面ごとにちょっとずつ違うコードで対処した結果、リファクタリングも出来なくなってしまった。

(T_T)

もっとVersionControlを! From Martin Fowler’s Bliki in Japanese

Martin Fowler’s Bliki in Japanese – もっとVersionControlを!

私はVisioなどを使って設計図を作っている。 diffを使うと、バージョン間でどこが変わったのか、他のひとがどこに変更を加えたのかが分かる。これは素晴らしいことだと思う。だが、こういったものから本当に価値を得ようとするなら、 セマンティックdiffをサポートしたツールが必要になるかもしれない

VisioのDIFFツールは真剣にほしいかも。
テキストファイルは比較的楽に管理できるのですが、バージョン管理をしたいんだけど中々上手くできないのが、Word, Excel, Visioの類ですね。モデリング/設計文書なんかで必要なものはVSSで管理しているのですが、バイナリファイルでしか使えないので、まるっとファイル毎差し替えるしか方法がないんですよね。部分的にここだけ戻したいってこともあるので、そこを何とかしたいですよね。結局シェアポータルサーバーなんかもそこまでは面倒見てくれないですしね。
そういえばVSTSではWhitehorseとかでのモデル成果物のバージョン間でDiffってとれるんですかね。無理そうですね。

くーす本が出版されるようで

はてなダイアリー – ひがやすをの「なれるものなら押切もえ」

正月休明けに最後の章をレビューにかけられれば、ぎりぎりセーフ。3末出版の予定です。

ということで3月末の発売のもよう。もうしばらく待たないといけないですね。
後はどう.netにアレンジしていくかだなぁ。

くーす本

@江青日記の昨日分を読んで、私もくーすは書籍として出版されるべきものだろうと思いました。
マイクロソフトはソフトウェアファクトリでこの先突っ走って行くのでしょうが、いつ如何なる時、如何なる場所でもソフトウェアファクトリが正しいかといえば、それは話が別でしょう。比較的小規模なシステム開発が主で、客先の業種が固定できないような、つまりは地方にたくさんあるSIerではソフトウェファクトリが必要とされることはまずないでしょう。プロダクトラインの整備に投資する正当性がありません。それよりも、軽量で顧客のニーズにもう少し細かくこたえていく開発方法が適しているように思います。
くーすはSeasar2とJavaで開発を行うためのICONIXを元にした方法論ですが、基本的には.NETでの開発でも応用できると考えています。そういう意味でも多くの人に、特に非Javaで開発をしている方々にくーすを知ってもらうのにも書籍化は良い話だと思うのですが。

続きを読む くーす本