今、自分がいる場所は、ソフトウェア開発の本流から離れた
一地方なのだと気づいた。
本流に戻らなければいけない。
もしかしたら、ここのブログで自分が書いている気づきは、
もう本流のなかの誰かが既に気づいたことなのかもしれない。
2010年1月28日木曜日
ソースコードは、それ自体、知識の記述だと思う。
ソースコードは、それ自体、知識の記述だと思う。
問題は、ソースコードに埋め込まれた業務知識を
どうやって抽象的な定義にするかでは
ないだろうか？
そのヒントは、メソッド抽出だと思う。
問題は、ソースコードに埋め込まれた業務知識を
どうやって抽象的な定義にするかでは
ないだろうか？
そのヒントは、メソッド抽出だと思う。
ソースコードは、コミュニケーションのツールだと思う。
ソースコードは、コミュニケーションのツールだと思う。
Excel で記述した設計書よりも ソースコードのほうが
より具体的だし、実行、検証もできる。
みんなソースコードで設計の話をするべきだ。
Excel で記述した設計書よりも ソースコードのほうが
より具体的だし、実行、検証もできる。
みんなソースコードで設計の話をするべきだ。
2010年1月27日水曜日
プログラムの品質。
プログラムの品質としてバグが無いことをまず最初に上げるべきなのかもしれないが、私は読みやすさ、変更のしやすさを上げたい。
プログラムが読みやすく、変更しやすければ、修正によってバグが入り込む可能性が下がるし、バグがあっても修正がしやすいからだ。
そのときにプログラムの読みやすさをセンスや個人の技量にゆだねては、いけないと思う。
読みやすいプログラムには、一定の規則がある、規約が正しく作られている会社であれば、誰もが読みやすいコードを記述できるはずだ。
プログラムの規約が正しく記述されているか、それを検証する仕事もそのうちに必要とされるのではないかと思う。
規約の検証項目には、アルゴリズムの一意性を私は、加えたい。
何かしらの振る舞いの記述がシステム内で一箇所で記述され、それがメソッドとして抽出されていて、その振る舞いを必要とするプログラムでは、そのメソッドを呼び出すことで処理を実現しているということである。
プログラムが読みやすく、変更しやすければ、修正によってバグが入り込む可能性が下がるし、バグがあっても修正がしやすいからだ。
そのときにプログラムの読みやすさをセンスや個人の技量にゆだねては、いけないと思う。
読みやすいプログラムには、一定の規則がある、規約が正しく作られている会社であれば、誰もが読みやすいコードを記述できるはずだ。
プログラムの規約が正しく記述されているか、それを検証する仕事もそのうちに必要とされるのではないかと思う。
規約の検証項目には、アルゴリズムの一意性を私は、加えたい。
何かしらの振る舞いの記述がシステム内で一箇所で記述され、それがメソッドとして抽出されていて、その振る舞いを必要とするプログラムでは、そのメソッドを呼び出すことで処理を実現しているということである。
2010年1月26日火曜日
この変数何！？って言うのもやめてほしい。。。
この変数名何！？って言うのもやめてほしい。。。。
もっと分かりやすい名前を付けてくれ。。。。
プログラムは、愚直であることが必要だなぁ。。。と思う。
そうだ。。。今気づいた。
変数名が閉じているか開いているかの違いなんだろうな。
公に知られている名前を変数名にすれば、
はじめてそれを見る人にも理解できる可能性が高い。
そういうことだなぁ。。。。
ドメイン記述言語とセマンティクWebって関係あるの
かな。。？
もっと分かりやすい名前を付けてくれ。。。。
プログラムは、愚直であることが必要だなぁ。。。と思う。
そうだ。。。今気づいた。
変数名が閉じているか開いているかの違いなんだろうな。
公に知られている名前を変数名にすれば、
はじめてそれを見る人にも理解できる可能性が高い。
そういうことだなぁ。。。。
ドメイン記述言語とセマンティクWebって関係あるの
かな。。？
2010年1月25日月曜日
コピペでソースを作るのは、やめてくれ。。。。
あるシステムのソースを読んでいて、ほとんど処理が同じだ
という二つのプログラムを DF で比較してみた。。。。
すると更新処理は、ほとんど一緒。
なんで一緒なのに一つのモジュールにまとめないんだ。。。。
そういうことをしていると、どんどん管理するソースが
増えていって、しまいには、管理しきれなくなる。。。。。
ほんとそういうのは、やめてほしい。。。。
という二つのプログラムを DF で比較してみた。。。。
すると更新処理は、ほとんど一緒。
なんで一緒なのに一つのモジュールにまとめないんだ。。。。
そういうことをしていると、どんどん管理するソースが
増えていって、しまいには、管理しきれなくなる。。。。。
ほんとそういうのは、やめてほしい。。。。
2010年1月13日水曜日
モジュール化で単体テストを自動化しよう！
テストに関して言えば、モジュール化は、
テストを自動化する上で意味があります。
データベースや画面に関係なく、計算処理など
モジュール化すれば、そのモジュールに対して
テストコードを記述することができます。
テストを自動化する上で意味があります。
データベースや画面に関係なく、計算処理など
モジュール化すれば、そのモジュールに対して
テストコードを記述することができます。
テストにもモデルって必要かも。。？
テストにもモデルって必要かも。。。。。？
と思った。
テストにもテストパターン（再利用できるテストの観点）が
あるよな。。。。？
と思った。
テストするときに重点テスト事項って言うのも
あるな。。。。要求が理解できたうえでテストを
するとそうなると思う。
と思った。
テストにもテストパターン（再利用できるテストの観点）が
あるよな。。。。？
と思った。
テストするときに重点テスト事項って言うのも
あるな。。。。要求が理解できたうえでテストを
するとそうなると思う。
設計にも検証（テスト）が必要だ。
設計にも検証（テスト）が必要だ。と思う。
失敗しそうになったプロジェクト（何とかなったらしい）で問題になったのが「SEの設計ができていない」と言うことだった。
「設計ができていない」と言うのは、どういうことか？
設計書に基づいてコーディングを行い、テストフェーズに入ったときに設計レベルでバグが多発し、設計をしなおすと言うこと。
これを「設計ができてない」と言うらしい。
じゃぁ、設計ができているというのは、どういうことか？
私は、それは、設計の検証ができていると言うことだと思う。
失敗したケースでは、コーディング、結合テストまで、設計の検証をしなかった。
あまい設計だったということだと思う。
設計の検証手法については、さまざま有り、議論の必要なことだと思うので具体的な方法については、皆さんで考えてください。
たぶん要求定義、基本設計、詳細設計でテストケースの洗い出しをするかどうかかもね。
失敗しそうになったプロジェクト（何とかなったらしい）で問題になったのが「SEの設計ができていない」と言うことだった。
「設計ができていない」と言うのは、どういうことか？
設計書に基づいてコーディングを行い、テストフェーズに入ったときに設計レベルでバグが多発し、設計をしなおすと言うこと。
これを「設計ができてない」と言うらしい。
じゃぁ、設計ができているというのは、どういうことか？
私は、それは、設計の検証ができていると言うことだと思う。
失敗したケースでは、コーディング、結合テストまで、設計の検証をしなかった。
あまい設計だったということだと思う。
設計の検証手法については、さまざま有り、議論の必要なことだと思うので具体的な方法については、皆さんで考えてください。
たぶん要求定義、基本設計、詳細設計でテストケースの洗い出しをするかどうかかもね。
ルール（規約）よりモデル。
ソフトウェアの開発という仕事をしているとコーディング時点でさまざまなルールを目にします。
コーディング規約などです。
コーディング規約がそもそもなぜあるのかと言えば、開発したソフトウェアのメンテナンスをより簡単にし、ソフトウェアの変更に対する耐性を上げるためではないかともいます。
しかし、ルールでコーディングを縛るのは、私は、息苦しさを感じます。
プログラミングやソフトウェアの開発というプロセスは、創造的なものでルールによって縛り上げるものではないと思うからです。
そこで、では、私たちにとって何が本当は、必要なのかと言えば、それは、昨今、話題になるモデルではないかと私は思います。
ソフトウェアの構造や動作をモデル化し、オープンで共有可能なものにすることで、メンテナンスの容易さや変更に対する耐久性をあげることができるのではないでしょうか？
話は戻りますが、コーディング規約が必要ないということを言うつもりはありません。
むしろより拘束力の強いプログラミング言語があってもいいかもしれないとさえ思います。
うんちゃらかんたら。。。。。
モデルとは何か？
コーディング規約などです。
コーディング規約がそもそもなぜあるのかと言えば、開発したソフトウェアのメンテナンスをより簡単にし、ソフトウェアの変更に対する耐性を上げるためではないかともいます。
しかし、ルールでコーディングを縛るのは、私は、息苦しさを感じます。
プログラミングやソフトウェアの開発というプロセスは、創造的なものでルールによって縛り上げるものではないと思うからです。
そこで、では、私たちにとって何が本当は、必要なのかと言えば、それは、昨今、話題になるモデルではないかと私は思います。
ソフトウェアの構造や動作をモデル化し、オープンで共有可能なものにすることで、メンテナンスの容易さや変更に対する耐久性をあげることができるのではないでしょうか？
話は戻りますが、コーディング規約が必要ないということを言うつもりはありません。
むしろより拘束力の強いプログラミング言語があってもいいかもしれないとさえ思います。
うんちゃらかんたら。。。。。
モデルとは何か？
より安心なソフトウェア納品に必要なもの
プログラムを記述し、顧客に納品するとき、本当にそのプログラムにバグが無いかどうか不安なになることがあります。
仕様、要求事項を十分に理解していれば、バグの無い完全なプログラムを作ることができますが、コミュニケーションや諸々の問題で要求事項（仕様）を十分に理解できないときもあります。
これまでは、設計から要求を推測することによって、各プログラマが要求を理解しました。
。。。。。。
言いたいのは。。。。
テストケースを書くと安心してプログラムを納品することができると思うよ。
仕様、要求事項を十分に理解していれば、バグの無い完全なプログラムを作ることができますが、コミュニケーションや諸々の問題で要求事項（仕様）を十分に理解できないときもあります。
これまでは、設計から要求を推測することによって、各プログラマが要求を理解しました。
。。。。。。
言いたいのは。。。。
テストケースを書くと安心してプログラムを納品することができると思うよ。
テストにユーザを巻き込むべきでは？
ユーザも交えた実データによるテストの必要性を実感しました。。
県○○課の○○システムですが、
実運用に入った今月から帳票の文字の桁数が不足している為に
ちゃんと表示されないデータが存在することがわかりました。
まぁ、帳票の桁数を少し直すだけなのでそれほど大きな問題では、
ないのですが。。。。。
顧客は、ただ待っていれば、完璧なソフトを納品してもらえると
考えがちだと思います。
しかし、私たちのようなカスタムメイドのソフトを作っている
会社では、顧客とのコミュニケーションなしに完璧なソフトを
納品することは不可能です。
発注した顧客も開発に巻き込む必要があるし、
そのことを顧客にも理解してもらう必要があるなと思いました。
県○○課の○○システムですが、
実運用に入った今月から帳票の文字の桁数が不足している為に
ちゃんと表示されないデータが存在することがわかりました。
まぁ、帳票の桁数を少し直すだけなのでそれほど大きな問題では、
ないのですが。。。。。
顧客は、ただ待っていれば、完璧なソフトを納品してもらえると
考えがちだと思います。
しかし、私たちのようなカスタムメイドのソフトを作っている
会社では、顧客とのコミュニケーションなしに完璧なソフトを
納品することは不可能です。
発注した顧客も開発に巻き込む必要があるし、
そのことを顧客にも理解してもらう必要があるなと思いました。
ソフトウェア品質を保証するには。。。
テストについて議論する前に、ソフトウェアの品質とは何か？という定義が必要かもしれません。
ソフトウェア品質
http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%93%81%E8%B3%AA
昨日、ある異業種間交流会のようなものに出たのですが、
そこでホンダのソフトウェアの技術者がいました。
私よりぜんぜん若いのですが、ソフトウェアの検証と管理を担当している
ということで、納品されたソフトウェアの品質は、どうしたら保証できるのか？
という問題で悩んでいるという話でした。
彼がメーカーにソフトウェアの保証をしてくれといったら、
それはできないと言われたとぼやいていました。
確かに保証の範囲という問題があるので、単に保証してくれと言っても
どこまで保証すればいいんだ？となると保証できませんと言われるのかも
しれません。
テスト仕様書（チェックリスト）にチェックするか、テスト結果を
提出するしか、ソフトウェアメーカーとしてはできないと思います。
ユーザがどのような使い方をするかは、基本的に予測しにくいですし、
誤った使い方に対する耐性という意味でフールプルーフ（愚か者に対する耐性）
というのがありますが、ひとつづつ書き出していく以外に
保証する方法は、ないのではないでしょうか？
ソフトウェア品質
http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%93%81%E8%B3%AA
昨日、ある異業種間交流会のようなものに出たのですが、
そこでホンダのソフトウェアの技術者がいました。
私よりぜんぜん若いのですが、ソフトウェアの検証と管理を担当している
ということで、納品されたソフトウェアの品質は、どうしたら保証できるのか？
という問題で悩んでいるという話でした。
彼がメーカーにソフトウェアの保証をしてくれといったら、
それはできないと言われたとぼやいていました。
確かに保証の範囲という問題があるので、単に保証してくれと言っても
どこまで保証すればいいんだ？となると保証できませんと言われるのかも
しれません。
テスト仕様書（チェックリスト）にチェックするか、テスト結果を
提出するしか、ソフトウェアメーカーとしてはできないと思います。
ユーザがどのような使い方をするかは、基本的に予測しにくいですし、
誤った使い方に対する耐性という意味でフールプルーフ（愚か者に対する耐性）
というのがありますが、ひとつづつ書き出していく以外に
保証する方法は、ないのではないでしょうか？
2010年1月6日水曜日
フリーソフトに関する話題。その十九。
フリーのスケジュール作成Excel
開発マイルストーン
http://www.vector.co.jp/soft/dl/win95/personal/se424886.html
■開始日と日数の入力だけで自動的にガントチャート表示
■月単位、週単位、日単位、時間単位での表示が可能
■実績入力により、遅れ/進捗状況などを自動的に表示
■休日や祝日などが自動的に計算されて終了日を決定
■担当者の作業が重ならないように工数調整可能
■標準工程を用意すれば、簡単にスケジュール挿入可能
■工数統計グラフにより、過剰工数などの把握が可能
■MSProject(XML形式)データのインポートが可能
です！
開発マイルストーン
http://www.vector.co.jp/soft/dl/win95/personal/se424886.html
■開始日と日数の入力だけで自動的にガントチャート表示
■月単位、週単位、日単位、時間単位での表示が可能
■実績入力により、遅れ/進捗状況などを自動的に表示
■休日や祝日などが自動的に計算されて終了日を決定
■担当者の作業が重ならないように工数調整可能
■標準工程を用意すれば、簡単にスケジュール挿入可能
■工数統計グラフにより、過剰工数などの把握が可能
■MSProject(XML形式)データのインポートが可能
です！
フリーソフトに関する話題。その十八。
Joomla!（ジュームラ）
http://www.c3inc.co.jp/
http://ja.wikipedia.org/wiki/Joomla!
Joomla!（ジュームラ）はオープンソース、フリーソフトウェアのコンテンツマネージメントシステムである。
スワヒリ語の"Jumla"を語源としており、一斉に、全体としてという意味が込められている。
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84%E3%83%9E%E3%83%8D%E3%83%BC%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0
初めて聞く CMS です。使いやすいのかなぁ。。。。
http://www.c3inc.co.jp/
http://ja.wikipedia.org/wiki/Joomla!
Joomla!（ジュームラ）はオープンソース、フリーソフトウェアのコンテンツマネージメントシステムである。
スワヒリ語の"Jumla"を語源としており、一斉に、全体としてという意味が込められている。
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84%E3%83%9E%E3%83%8D%E3%83%BC%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0
初めて聞く CMS です。使いやすいのかなぁ。。。。
フリーソフトに関する話題。その十六。
Folder Size
外人が作った、Folder のサイズを表示してくれるツールです。
バックグランドでプロセスを走らせ、フォルダサイズを集計し、
Explore に表示してくれます。
結構、役に立ちますので、機会があったらご利用ください。
http://www.forest.impress.co.jp/lib/sys/wincust/explrextn/foldersize.html
外人が作った、Folder のサイズを表示してくれるツールです。
バックグランドでプロセスを走らせ、フォルダサイズを集計し、
Explore に表示してくれます。
結構、役に立ちますので、機会があったらご利用ください。
http://www.forest.impress.co.jp/lib/sys/wincust/explrextn/foldersize.html
フリーソフトに関する話題。その十五。
Excel のブック共有は使わないほうが良いかもしれません。
○○○建設のときに、スケジュール管理の共有ブックが
壊れてデータが消えたことがありました。
通常の排他制御で十分なようです。
○○○建設のときに、スケジュール管理の共有ブックが
壊れてデータが消えたことがありました。
通常の排他制御で十分なようです。
フリーソフトに関する話題。その十四。
Microsoft、フリーのXMLエディター「XML Notepad 2007」を公開！だそうです。
http://www.forest.impress.co.jp/article/2006/11/24/xmlnotepad2007.html
http://www.atmark.gr.jp/~s2000/r/xml_notepad.html
なぜ XML なのか？ということについて。。。。
aaaがaabであることは、bbbであるためであり、
cccでなければならないことはない。
というように知識が表現されていたとすると、
コンピュータは、理解できない。
<aaa>
<aab reason="bbb" shouldnot="ccc"/>
</aaa>
とか、だとすると、もう少しプログラムで
処理できるかもしれない。
という理由からかもしれないと、思いました。
が！
http://www.forest.impress.co.jp/article/2006/11/24/xmlnotepad2007.html
http://www.atmark.gr.jp/~s2000/r/xml_notepad.html
なぜ XML なのか？ということについて。。。。
aaaがaabであることは、bbbであるためであり、
cccでなければならないことはない。
というように知識が表現されていたとすると、
コンピュータは、理解できない。
<aaa>
<aab reason="bbb" shouldnot="ccc"/>
</aaa>
とか、だとすると、もう少しプログラムで
処理できるかもしれない。
という理由からかもしれないと、思いました。
が！
フリーソフトに関する話題。その十三。
C#にも対応、カスタマイズ性もアップした「JUDE/Professional 5.3」
http://techtarget.itmedia.co.jp/tt/news/0808/28/news02.html
http://techtarget.itmedia.co.jp/tt/news/0808/28/news02.html
フリーソフトに関する話題。その十二。
「情報共有」：使えそうなツール見つけました。
改行文字と文字コードを一括変換するようです。
Linux で作ったソースを Windows のソースに変換するのに使えそうです。
http://bousiya.sakura.ne.jp/modules/d3blog/details.php?bid=73
上のツールの開発者が開発した HTML エディタのようです。
使ったことはないですが、有力かもしれません。
http://www.kashim.com/eve/index.html
どちらもフリーウェアのようです。
改行文字と文字コードを一括変換するようです。
Linux で作ったソースを Windows のソースに変換するのに使えそうです。
http://bousiya.sakura.ne.jp/modules/d3blog/details.php?bid=73
上のツールの開発者が開発した HTML エディタのようです。
使ったことはないですが、有力かもしれません。
http://www.kashim.com/eve/index.html
どちらもフリーウェアのようです。
フリーソフトに関する話題。その十一。
「情報共有」：JUDE/Professional, Community の 5.4 が公開されました
Jude Community Edition が UML 2.0 に対応したそうです。
Community Edition というのは、コミュニティでバグ取り、検証を行うためのバージョンで
無料で利用することができます。
UML を描くツールにお金をかけたくない場合は、こちらを利用するとよいかもしれませんね。
Jude Community Edition が UML 2.0 に対応したそうです。
Community Edition というのは、コミュニティでバグ取り、検証を行うためのバージョンで
無料で利用することができます。
UML を描くツールにお金をかけたくない場合は、こちらを利用するとよいかもしれませんね。
フリーソフトに関する話題。その十。
写真
「知識共有」：どこでもホイール。
http://www.vector.co.jp/soft/win95/util/se044875.html
Visual Basic 6.0 では、普通は、ホイールが利かないのですが、
このソフトを起動していれば、ホイールが使えます。
「知識共有」：どこでもホイール。
http://www.vector.co.jp/soft/win95/util/se044875.html
Visual Basic 6.0 では、普通は、ホイールが利かないのですが、
このソフトを起動していれば、ホイールが使えます。
フリーソフトに関する話題。その九。
『SysMLとシステム工学支援環境の現状と動向』 * 刊行以来ロングセラーです。
http://www.otij.org/research/index.html#reports
機械、電気、通信、環境、経営など、製品設計には様々な設計要素が関係し、それらを総合して最適化する手段が求められてきました。航空や自動車産業の強いニーズを背景に、システム工学とソフトウェア設計表記法(UML)が融合して2006年5月に生まれたSysML（システム工学モデリング言語）は、システムの境界を越えて存在する「要求」を客観的にモデル化することに成功し、ハードとソフトの境界を越えた「システム」の設計を初めて実現するものとして熱い注目を集めています。
http://www.otij.org/research/index.html#reports
機械、電気、通信、環境、経営など、製品設計には様々な設計要素が関係し、それらを総合して最適化する手段が求められてきました。航空や自動車産業の強いニーズを背景に、システム工学とソフトウェア設計表記法(UML)が融合して2006年5月に生まれたSysML（システム工学モデリング言語）は、システムの境界を越えて存在する「要求」を客観的にモデル化することに成功し、ハードとソフトの境界を越えた「システム」の設計を初めて実現するものとして熱い注目を集めています。
フリーソフトに関する話題。その八。
Visual Stuido でタスク管理できることに気づきました！
http://msdn.microsoft.com/ja-jp/library/zce12xx2(VS.80).aspx
// TODO
でやることを記述できるようです。
Eclipse と変わらないんですね！
http://msdn.microsoft.com/ja-jp/library/zce12xx2(VS.80).aspx
// TODO
でやることを記述できるようです。
Eclipse と変わらないんですね！
フリーソフトに関する話題。その七。
Visual Studio 2008 って、クラスダイアグラム描ける
んですね！
今日、はじめて知りました！
皆さんも試してみてください！
○なぜクラスダイアグラムが必要かについて（私見）
プログラムを組んで、完成して、それを別の誰かに
引継ぐような場合。
そのプログラムがどんな特性を持っていて、
どんな静的な構造をしているのか？という情報は、
プログラムを理解するうえで重要です。
それを表すのがクラスダイアグラムと言えるのでは
ないでしょうか？
もちろんクラスダイアグラムだけでは、
表現しきれないこともあると思います。
そのときは、適時、コメントを加えたりしながら
知識の伝達をした方がよいのではないでしょうか？
んですね！
今日、はじめて知りました！
皆さんも試してみてください！
○なぜクラスダイアグラムが必要かについて（私見）
プログラムを組んで、完成して、それを別の誰かに
引継ぐような場合。
そのプログラムがどんな特性を持っていて、
どんな静的な構造をしているのか？という情報は、
プログラムを理解するうえで重要です。
それを表すのがクラスダイアグラムと言えるのでは
ないでしょうか？
もちろんクラスダイアグラムだけでは、
表現しきれないこともあると思います。
そのときは、適時、コメントを加えたりしながら
知識の伝達をした方がよいのではないでしょうか？
フリーソフトに関する話題。その五。
> このアドインを利用すれば、Eclipse 見たいに メソッドの一覧が見れるようですね。
> アスペクト指向っぽくなるかな？
クラスビューを使えば、このアドインは、必要なさそうですね。
> アスペクト指向っぽくなるかな？
クラスビューを使えば、このアドインは、必要なさそうですね。
フリーソフトに関する話題。その四。
.Net のアドイン CodeSmart を紹介しているサイトのようです。
いろんな機能があるんですね～。
http://www.axtools.com/codesmart-vb6-screenshots.htm?gclid=CPPb8qeRg5cCFQEspAodxHXFYA
このアドインを利用すれば、Eclipse 見たいに メソッドの一覧が見れるようですね。
アスペクト指向っぽくなるかな？
でも、残念ながら、これは、フリーウェアではないようです。
$249 だから、２万４０００円くらいでしょうか。。。。
いろんな機能があるんですね～。
http://www.axtools.com/codesmart-vb6-screenshots.htm?gclid=CPPb8qeRg5cCFQEspAodxHXFYA
このアドインを利用すれば、Eclipse 見たいに メソッドの一覧が見れるようですね。
アスペクト指向っぽくなるかな？
でも、残念ながら、これは、フリーウェアではないようです。
$249 だから、２万４０００円くらいでしょうか。。。。
フリーソフトに関する話題。その二。
MZ-Tools 3.0 for VBA / VB6 / VB5
http://www.mztools.com/v3/mztools3.aspx
○魔界の仮面弁士さんのコメント
強化された検索機能、コメント入力補助、仕様書出力、ソースのレビュー機能など、多くの便利な機能を提供してくれる アドインソフトです。
複数言語に対応しており、英語,スペイン語,フランス語,イタリア語,ドイツ語,ポルトガル語が選択可能ですが……残念ながら日本語には非対応です。
漢字等は化けて表示されてしまうため、万人にお奨めする事はできないのが難点。それでも、強力なツールの一つだと思います。
○佐藤さんのコメント
Eclipse の呼び出し階層と同じような機能がありました。
仕様書出力機能は、メソッドクラスなどのアウトラインで内部のロジックについては、仕様化してくれませんでした。仕様書(設計書？)自動生成ツールの限界でしょうね。現状では。。。。。
Visual Basic の過渡期にもう遅いか。。。。
http://www.mztools.com/v3/mztools3.aspx
○魔界の仮面弁士さんのコメント
強化された検索機能、コメント入力補助、仕様書出力、ソースのレビュー機能など、多くの便利な機能を提供してくれる アドインソフトです。
複数言語に対応しており、英語,スペイン語,フランス語,イタリア語,ドイツ語,ポルトガル語が選択可能ですが……残念ながら日本語には非対応です。
漢字等は化けて表示されてしまうため、万人にお奨めする事はできないのが難点。それでも、強力なツールの一つだと思います。
○佐藤さんのコメント
Eclipse の呼び出し階層と同じような機能がありました。
仕様書出力機能は、メソッドクラスなどのアウトラインで内部のロジックについては、仕様化してくれませんでした。仕様書(設計書？)自動生成ツールの限界でしょうね。現状では。。。。。
Visual Basic の過渡期にもう遅いか。。。。
フリーソフトに関する話題。その一。
Visual Studio で Subversion
http://feedtailor.jp/oishi/2007/03/visual_studiosubversion_1.html
http://www.atmarkit.co.jp/fdotnet/opensrcverman/opensrcverman01/opensrcverman01_04.html
Visual Studio でも Subversion が利用できる見たいですね。
VSS は、いまいち、心細いんですよね～。
http://feedtailor.jp/oishi/2007/03/visual_studiosubversion_1.html
http://www.atmarkit.co.jp/fdotnet/opensrcverman/opensrcverman01/opensrcverman01_04.html
Visual Studio でも Subversion が利用できる見たいですね。
VSS は、いまいち、心細いんですよね～。
ユーザー横断的な部品を作るには？その一。
以前、○○さんからユーザが変わっても使いまわしの利く
部品を作って、開発効率を上げてよ！！！
という要望がありましたのでこのスレッドを立てます。
基本的には、各プロジェクトのソースコードを
部品化してゆくことと、ユーザが変わっても普遍的な
テーブル定義の二つができれば、
ユーザを横断した部品が定義できるのではないかと
私は思うのですが、皆さんはどう思いますか？
というスレッドです。
それか、テーブルの定義に依存しない抽象的な
アルゴリズムを定義できれば良いのかもしれません。
まぁソースコードの話ですので、なにより読みやすいほうが
良いと思います。
共通部品の開発には、詳細設計が重要。。。？
部品を作って、開発効率を上げてよ！！！
という要望がありましたのでこのスレッドを立てます。
基本的には、各プロジェクトのソースコードを
部品化してゆくことと、ユーザが変わっても普遍的な
テーブル定義の二つができれば、
ユーザを横断した部品が定義できるのではないかと
私は思うのですが、皆さんはどう思いますか？
というスレッドです。
それか、テーブルの定義に依存しない抽象的な
アルゴリズムを定義できれば良いのかもしれません。
まぁソースコードの話ですので、なにより読みやすいほうが
良いと思います。
共通部品の開発には、詳細設計が重要。。。？
Windows 運用に関する Tips、その二。
Tomcat の Web アプリケーションマネージャは、攻撃の対象に
なるようです。
http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/015.html
なるようです。
http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/015.html
Windows 運用に関する Tips、その一。
○○君の使用しているデスクトップ（前○○機）が重いので
メモリを増やしたほうがいいんじゃないか？という話になって、
じゃ、対応するメモリは何だ？とか、本当にスラッシングがおきているのか？
について、調べました。
・必要メモリ・サイズを見極める
http://www.atmarkit.co.jp/fwin2k/win2ktips/166memoryusage/memoryusage.html
タスクマネージャでスラッシングが発生しているかどうかを見る見方が書いてあります。
・メーカー別メモリ対応表
http://www.iodata.jp/pio/memory/
結局、メモリは、最大１Ｇのところ、７６８ＭＢまで乗っていて、
これ以上増やしても大きくは変わらないということがわかりました。
それで、笹沼さんの時に入れた、アプリケーションサーバの
ようなものをアンインストールしたら少し改善されたようです。
----------------------
その他、Windows で使える機能として、
コントロールパネルの「管理ツール」の「パフォーマンス」と
「ローカルセキュリティポリシー」があります。
パフォーマンスは、
メモリ利用料の時間変化やディスクアクセスの時間変化、
ネットワークアクセスの時間変化を見ることができるし、
その他にもスレッド数、プロセス数などの時間変化も
見ることができます。
ローカルセキュリティポリシーは、特定のユーザのネットワーク
アクセスやネットワークからのログインを制限したり、
ログイン履歴をとる監査設定をすることなどができます。
機会がありましたら利用してみてください。
以上です。
メモリを増やしたほうがいいんじゃないか？という話になって、
じゃ、対応するメモリは何だ？とか、本当にスラッシングがおきているのか？
について、調べました。
・必要メモリ・サイズを見極める
http://www.atmarkit.co.jp/fwin2k/win2ktips/166memoryusage/memoryusage.html
タスクマネージャでスラッシングが発生しているかどうかを見る見方が書いてあります。
・メーカー別メモリ対応表
http://www.iodata.jp/pio/memory/
結局、メモリは、最大１Ｇのところ、７６８ＭＢまで乗っていて、
これ以上増やしても大きくは変わらないということがわかりました。
それで、笹沼さんの時に入れた、アプリケーションサーバの
ようなものをアンインストールしたら少し改善されたようです。
----------------------
その他、Windows で使える機能として、
コントロールパネルの「管理ツール」の「パフォーマンス」と
「ローカルセキュリティポリシー」があります。
パフォーマンスは、
メモリ利用料の時間変化やディスクアクセスの時間変化、
ネットワークアクセスの時間変化を見ることができるし、
その他にもスレッド数、プロセス数などの時間変化も
見ることができます。
ローカルセキュリティポリシーは、特定のユーザのネットワーク
アクセスやネットワークからのログインを制限したり、
ログイン履歴をとる監査設定をすることなどができます。
機会がありましたら利用してみてください。
以上です。
要求定義？その一。
動かない仕様をあーだこーだ議論するより、さくっと動くコードを書いて、実際に
使ってみたほうがいい。
http://d.hatena.ne.jp/higayasuo/20090509/1241852749
ひがやすをブログのコメントより。
これは、ひがさんの信念なのでしょうね。私もどちらかというと、賛成です。
使ってみたほうがいい。
http://d.hatena.ne.jp/higayasuo/20090509/1241852749
ひがやすをブログのコメントより。
これは、ひがさんの信念なのでしょうね。私もどちらかというと、賛成です。
設計学？その十六。
Dao について某医療機器販売会社のソースを読んでいて気づいたことです。
http://docs.google.com/fileview?id=0B9Mcgt67LaE4OTZkYmY1NTAtZDdjMC00ZmQyLTk2YzAtNmQzMTkwNjEzNGE4&hl=en
Dao の設計を末端のプログラマに託すべきではない。
Dao の設計は、テーブルを設計した（定義した）者にやらせるべきだ。
なぜならデータの発生、更新、消滅のライフサイクルを知っているのは、
テーブル定義者だからだ。
http://docs.google.com/fileview?id=0B9Mcgt67LaE4OTZkYmY1NTAtZDdjMC00ZmQyLTk2YzAtNmQzMTkwNjEzNGE4&hl=en
Dao の設計を末端のプログラマに託すべきではない。
Dao の設計は、テーブルを設計した（定義した）者にやらせるべきだ。
なぜならデータの発生、更新、消滅のライフサイクルを知っているのは、
テーブル定義者だからだ。
設計学？その十二。
http://ja.wikipedia.org/wiki/Object_Constraint_Language
中略。
ナビゲーション言語として見た場合、OCLはXPathと対比することができる。XPath が XMLツリーに対してナビゲーションを行うのに対して、OCL は MOFベースのモデルやメタモデル（つまり XMIツリー）に対してナビゲーションを行う。換言すれば、OCL と UML や MOF との関係と、XPath と XML の関係が似ているのである。
----------
OCL は、XPath に近い位置づけなのでしょうか。。。。
中略。
ナビゲーション言語として見た場合、OCLはXPathと対比することができる。XPath が XMLツリーに対してナビゲーションを行うのに対して、OCL は MOFベースのモデルやメタモデル（つまり XMIツリー）に対してナビゲーションを行う。換言すれば、OCL と UML や MOF との関係と、XPath と XML の関係が似ているのである。
----------
OCL は、XPath に近い位置づけなのでしょうか。。。。
設計学？その十三。
[SDC]【SDC SQUARE 5月号】 JavaOne 2008 レポートなど
UML のブックレビューがあるようです。
インターネットの記事で業務系の分野には、オブジェクト指向設計は、適用しないほうが良いという
記事があったのですが、皆さんそう思いますか？
自分は、使い方を知らないだけではないかなと思うのですが。。。。
http://www.atmarkit.co.jp/fjava/rensai4/programer11/programer11_1.html
「これは、対象となるシステムにもよるものなのですが、例えば業務システムのようなジャンルでは、オブジェクト指向分析・設計は採用しない方が現時点では多数派です。不思議なことのように聞こえますが、これもプログラマーの常識です。」
UML のブックレビューがあるようです。
インターネットの記事で業務系の分野には、オブジェクト指向設計は、適用しないほうが良いという
記事があったのですが、皆さんそう思いますか？
自分は、使い方を知らないだけではないかなと思うのですが。。。。
http://www.atmarkit.co.jp/fjava/rensai4/programer11/programer11_1.html
「これは、対象となるシステムにもよるものなのですが、例えば業務システムのようなジャンルでは、オブジェクト指向分析・設計は採用しない方が現時点では多数派です。不思議なことのように聞こえますが、これもプログラマーの常識です。」
設計学？その十一。
「知識共有」：Object Constraint Language
http://ja.wikipedia.org/wiki/Object_Constraint_Language
wiki です。
Object Constraint Language（OCL）は、統一モデリング言語 (UML) モデルに適用する規則を記述するための宣言型言語である。
---------
こんなものも出てきたんですね。勉強しなきゃ～
http://ja.wikipedia.org/wiki/Object_Constraint_Language
wiki です。
Object Constraint Language（OCL）は、統一モデリング言語 (UML) モデルに適用する規則を記述するための宣言型言語である。
---------
こんなものも出てきたんですね。勉強しなきゃ～
設計学？その九。
「思ったこと」：COBOL ちっくな BV と C ちっくな VB。
VB のコードを見ているとそのコードを
書いた人が以前に使っていた言語が見える
気がします。
私は、C を以前にやっていたので C ちっく
な VB のコードは、読みやすく感じるの
ですが、COBOL ちっくな VB のコードは、
読みづらくてしかたありません。
これは、各言語の文化の違いなのでしょうか？
具体的に言うと 某医療機器販売会社のコードで
参照するテーブルをあらかじめ使う前に変数に
セットしてその後、その変数名で呼び出している
箇所が多々見られます。
これは、COBOL の使用するファイルを
あらかじめ宣言して使用するという習慣から
きていると思われます。
SQL文を読もうとすると重要な情報である
テーブル名が別の変数名に置き換えられ、
隠蔽されているため前のテーブル宣言に
戻って変数が示すテーブルを見なければ
なりません。
このようなコードを読みづらくする
習慣がいつまでも引きづられてなくならない
原因は、各自がオリジナルのコードを
作ろうとしないことによると思います。
オリジナルにある程度、読みやすい
コードを記述するように心がけていれば
自然と読みづらいコードは、無くなってゆく
と思います。
コードを読んでいて、ストレスが
たまったので、ここで発散しただけです。。
VB のコードを見ているとそのコードを
書いた人が以前に使っていた言語が見える
気がします。
私は、C を以前にやっていたので C ちっく
な VB のコードは、読みやすく感じるの
ですが、COBOL ちっくな VB のコードは、
読みづらくてしかたありません。
これは、各言語の文化の違いなのでしょうか？
具体的に言うと 某医療機器販売会社のコードで
参照するテーブルをあらかじめ使う前に変数に
セットしてその後、その変数名で呼び出している
箇所が多々見られます。
これは、COBOL の使用するファイルを
あらかじめ宣言して使用するという習慣から
きていると思われます。
SQL文を読もうとすると重要な情報である
テーブル名が別の変数名に置き換えられ、
隠蔽されているため前のテーブル宣言に
戻って変数が示すテーブルを見なければ
なりません。
このようなコードを読みづらくする
習慣がいつまでも引きづられてなくならない
原因は、各自がオリジナルのコードを
作ろうとしないことによると思います。
オリジナルにある程度、読みやすい
コードを記述するように心がけていれば
自然と読みづらいコードは、無くなってゆく
と思います。
コードを読んでいて、ストレスが
たまったので、ここで発散しただけです。。
設計学？その八。
「思ったこと」：ソフトウェアの流通。
特定の顧客向けにシステムを開発しますが、そのシステムの管理者が
変わると言うことは、ソフトウェアが流通していることと同じことに
なるのではないだろうか？
なぜこんなことを思ったかというと。
某医療機器販売会社のデータを見ていると製品テーブルにバルク品が入っていたりするのです。
バルク：http://kaden.yahoo.co.jp/dict/?type=detail&id=2004
これは、製造中止になった製品のバルク品を処分するために
製品として登録して、販売したということではないかと思いました。
このとき、システム管理者がバルク品を製品テーブルに登録しても
よいかどうか判断するのですが、それは、システム管理者によって
判断が分かれると思います。
それは、今後、システムをどう運用してゆくかと言うことにも
かかわってきます。
私だったら、あまり融通を利かせないで、例外的な処理、又は、
データは、システムには含めないと思います。
そういうことも含めて、開発しているシステムは、流通できる
（他の人の手に渡せる）ものなのでしょうか。。。。
何でもできる、汎用性を高くするのは、大変だし、
何でもできてしまうのは、システムじゃないんじゃないのかなぁ。。。。
そうすると利用頻度が高いものから、手作業で行うとコストのかかるもの
からシステム化してゆくべきなのかな。。。。
特定の顧客向けにシステムを開発しますが、そのシステムの管理者が
変わると言うことは、ソフトウェアが流通していることと同じことに
なるのではないだろうか？
なぜこんなことを思ったかというと。
某医療機器販売会社のデータを見ていると製品テーブルにバルク品が入っていたりするのです。
バルク：http://kaden.yahoo.co.jp/dict/?type=detail&id=2004
これは、製造中止になった製品のバルク品を処分するために
製品として登録して、販売したということではないかと思いました。
このとき、システム管理者がバルク品を製品テーブルに登録しても
よいかどうか判断するのですが、それは、システム管理者によって
判断が分かれると思います。
それは、今後、システムをどう運用してゆくかと言うことにも
かかわってきます。
私だったら、あまり融通を利かせないで、例外的な処理、又は、
データは、システムには含めないと思います。
そういうことも含めて、開発しているシステムは、流通できる
（他の人の手に渡せる）ものなのでしょうか。。。。
何でもできる、汎用性を高くするのは、大変だし、
何でもできてしまうのは、システムじゃないんじゃないのかなぁ。。。。
そうすると利用頻度が高いものから、手作業で行うとコストのかかるもの
からシステム化してゆくべきなのかな。。。。
設計学？その四。
http://www.microsoft.com/japan/powerpro/TF/column/tn_09_1.mspx?rss_fdn=MSDNTopNewInfo
ソフトウェア開発においてモデリングは、重要な成功要因として挙げられますが、果たして現場で効果的に適用できているでしょうか？難しいといわれるモデリングの実践ですが、原点回帰し見つめなおすと糸口が見出せるかも。by Microsoft
モデリング自体は、コーディングをしていれば自然にしているので
モデリングすることが重要というより、モデルを図面化していることの方が
重要なのでは？と思います。by 佐藤
ソフトウェア開発においてモデリングは、重要な成功要因として挙げられますが、果たして現場で効果的に適用できているでしょうか？難しいといわれるモデリングの実践ですが、原点回帰し見つめなおすと糸口が見出せるかも。by Microsoft
モデリング自体は、コーディングをしていれば自然にしているので
モデリングすることが重要というより、モデルを図面化していることの方が
重要なのでは？と思います。by 佐藤
設計学？その三。
東大の先生が提唱している設計学のページがありました。
皆さんの設計業務の再考にお役立てください。
http://www.race.u-tokyo.ac.jp/~takeda/designtheory-j.html
皆さんの設計業務の再考にお役立てください。
http://www.race.u-tokyo.ac.jp/~takeda/designtheory-j.html
設計学？その一。
一品香でラーメンを食べていた思ったことがありました。
どこかに記録しておかないと忘れるのでここに
残します。
もし皆さんもこのテーマについて、意見がありましたら
書き込みをお願いします。
何年か前、ITアーキテクトという雑誌がありました。
JavWorld がインターネットの普及で売れなくなったのか
IDG（だったかな？）が発行を始めたものです。
その雑誌も時が流れて、今はなくなり（だったかな？）
ITアーキテクトと言う言葉だけが、私の記憶の片隅に
存在していました。
IT の建築家？そりゃ分かるけど。。どういう意味？
そのときの私の理解は、情報システムを構築する
基盤を設計する人のこと。。。。
確かに情報システムは、度重なる変更にも耐えうる
アーキテクチャが必要だと言うのは、わかります。
-------
設計をするときにそのシステムの変更可能性についての
要求は、あまりはっきりせずにシステム化することは
多いのではないでしょうか？
今は、オブジェクト指向が普及しているので
クラスの継承によって、新しい振る舞いの
プログラムを安全に追加できる仕組みができてきました。
-------
プログラムの変更が安全にできるかどうかは、
プログラム変更者がそのプログラムの構造を理解しているか
によるのではないでしょうか？
ある部分への変更が他の箇所へ影響しないことも
必要かもしれません。（情報の隠蔽、カプセル化）
-------
あと早くプログラムを作ることも要求されがちです。
早く作ると言うことは、その分、コストが下がり
顧客の必要なそのときに必要なシステムを提供する
ことができます。
-------
プログラムを作るうえで規約やルールに
従順であることは。。。規約やルールを作り出すことにも
創造性が発揮されるのではないでしょうか？
ルールや規約に柔軟に対応できると言うことは
ルールや規約に縛られているようでも
実は、ルールや規約から自由なのではないでしょうか？
-------
設計やプログラミングをしていて、
うちの会社はこういうやり方があるから。。。とか
うちの会社の習慣だからという理由で
実装が決まったりすることがあるように
思います。
たとえば某ＳＩのシステムでは、
理由が分からないですが、データベースにメニュー項目を
持たせます。
一見、何でそんなことをするのかと問いたくなります。
今回のシステムでそれほど頻繁にメニューの追加や削除が
あるのでしょうか？
システムの実装の習慣を引継ぐことは、
本当に変更に強いシステムになるのでしょうか？
そんな時、システムのアーキテクトが必要だと感じます。
---------
なんか大事なことを忘れた。。。。。気がする。
どこかに記録しておかないと忘れるのでここに
残します。
もし皆さんもこのテーマについて、意見がありましたら
書き込みをお願いします。
何年か前、ITアーキテクトという雑誌がありました。
JavWorld がインターネットの普及で売れなくなったのか
IDG（だったかな？）が発行を始めたものです。
その雑誌も時が流れて、今はなくなり（だったかな？）
ITアーキテクトと言う言葉だけが、私の記憶の片隅に
存在していました。
IT の建築家？そりゃ分かるけど。。どういう意味？
そのときの私の理解は、情報システムを構築する
基盤を設計する人のこと。。。。
確かに情報システムは、度重なる変更にも耐えうる
アーキテクチャが必要だと言うのは、わかります。
-------
設計をするときにそのシステムの変更可能性についての
要求は、あまりはっきりせずにシステム化することは
多いのではないでしょうか？
今は、オブジェクト指向が普及しているので
クラスの継承によって、新しい振る舞いの
プログラムを安全に追加できる仕組みができてきました。
-------
プログラムの変更が安全にできるかどうかは、
プログラム変更者がそのプログラムの構造を理解しているか
によるのではないでしょうか？
ある部分への変更が他の箇所へ影響しないことも
必要かもしれません。（情報の隠蔽、カプセル化）
-------
あと早くプログラムを作ることも要求されがちです。
早く作ると言うことは、その分、コストが下がり
顧客の必要なそのときに必要なシステムを提供する
ことができます。
-------
プログラムを作るうえで規約やルールに
従順であることは。。。規約やルールを作り出すことにも
創造性が発揮されるのではないでしょうか？
ルールや規約に柔軟に対応できると言うことは
ルールや規約に縛られているようでも
実は、ルールや規約から自由なのではないでしょうか？
-------
設計やプログラミングをしていて、
うちの会社はこういうやり方があるから。。。とか
うちの会社の習慣だからという理由で
実装が決まったりすることがあるように
思います。
たとえば某ＳＩのシステムでは、
理由が分からないですが、データベースにメニュー項目を
持たせます。
一見、何でそんなことをするのかと問いたくなります。
今回のシステムでそれほど頻繁にメニューの追加や削除が
あるのでしょうか？
システムの実装の習慣を引継ぐことは、
本当に変更に強いシステムになるのでしょうか？
そんな時、システムのアーキテクトが必要だと感じます。
---------
なんか大事なことを忘れた。。。。。気がする。
登録:
投稿 (Atom)