怠惰であることは危険だ。

ソフトウェア開発プロジェクトにおいて、納期までまだ時間があるから

ゆっくりやって大丈夫だ。。。。という考えは、危険だ。

ソフトウェア開発プロジェクトがうまく行かなくなる原因は、

様々あると思う。

私がよく直面する問題は、実装方法の問題。特に新しいフレームワークや

開発環境で開発するとき、実装方法が分からず、進捗が極端に

悪くなる。

こういうリスクがあるのだから、納期まで時間があると高をくくって

いると、後で痛い目にあう。

今、クラウドアプリを設計中。。。。

今クラウドアプリを設計しています～。

詳細は、後日。

人を育てたいと思った。

おれも今年で３５歳。いい年です。未だ、再婚はしていない。

こういう年になると、下から上がってくる若い人が気になります。

追い越されるとかは、心配していないけど、

これからは、年下の人ともうまくやってゆかなければ、

いけません。そういう人を育てる側になれたらいいなと思うのです。

それには、まず、自分が人を育てるに値する人間にならないと！

久々の更新。仕事の進捗。

最近の近況報告などをちょっと。

市内の酒類の卸売店の販売管理システムをやっています。

基本的なところは、弥生販売で、それに不足している部分を

作成しています。

基本設計は、出向先の社長が担当しています。

最初は、弥生販売のカスタマイズなんてやったことないので

いったいどうなってしまうんだろう。。。と

不安でしたが、しばらく進んでみると、

それほど難しくはなかった。

周りの人のサポートもあったおかげで順調に

進んでいます。

いまは、ちょっと休憩をさせてもらっています。

スクラムソフトウェア開発。

こんなのあったんだな。。。。

http://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0_%28%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%29


の上で。これおもしろい！

http://www.ryuzee.com/contents/blog/3321

今は、ひとりでプログラムを組んでいます。

ある会社の仕事で酒卸業の販売管理をやっています。

基本ソフトは、弥生販売で、それにカスタマイズして

補助プログラムを開発しています。

今後は、こういう仕事が増えてくるのかなという

いい例です。

規模も小さいのでプログラマは、おれひとり、

もうひとり業務を理解しているエンジニア

この人が SE かな、年は、50歳くらいの

その会社の社長です。

この社長が、まじめでいい人！とても気が合いそうです！

こんな年でもプログラマとして使ってもらえるのは、

うれしい限りです。

言語は、Visual Basic 2005 .Net、開発スタイルは、

一応、アジャイルかな。。。。。

プログラミングしていてわからないことは、

質問管理表に記入していって、たまったら、社長に聞く

って言う感じで、何とかなっています。

やっぱりわからないことをすぐに聞けるって言うのは、

大事だね。

GWT module 'guestbook' may need to be (re)compiled

Google App Engine の説明ページの通りにアプリケーションのひな型を作って、

実行させようとしたら「GWT module 'guestbook' may need to be (re)compiled」

というエラーに悩まされた。

結局、Firefox で http://localhost:8888/ にアクセスすると

このエラーになり、http://127.0.0.1:8888/ にアクセスしたら

ちゃんと起動した。

Google Chrome では、http://localhost:8888/ でも

ちゃんと起動した。

変なところでひっかかちゃったな。。。。

Google Web Toolkit って何？

Google Web Toolkit ってなんだろう、Google App Engine のアプリケーションを

実行するブラウザには、インストールしなきゃいけないのかな？

今日は、午前中プログラミング、午後から勉強。

Google App Engine を勉強しています。

昨日、帝京大学であった「クラウドコンピューティングがやってきた」という

公開講座に参加したのです。

その講義の中で Google App Engine でサービスを立ち上げ、

２，３か月で立ち上げられたという話。

しかもアクセス数に応じて、Google のサーバが適時、

性能を上げてくれるからキャパシティプランニングが

必要ないなど。。。。

「それは、いいな。。。。」

と思い、勉強をしているわけです。

手順通りにやってみたけど、いまいち。。。。

書いてあるようには、動かない。。。。

もっと簡単な手順書を見た方がいいのかな。。。。？

職業訓練と仕事と。

職業訓練と仕事と並行してやっています。

あと一週間くらいだから頑張ろう。。。。

ロゴ作り直し。

ロゴが作り直しになった。。。。。

いや、理事長が、どんな感じのロゴがいいのか言ってなかったから

先日のミーティングでその話になって、

やっと「柔らかい感じのロゴ」がいいと言うことになった。

初めから言ってよ！って気もするけど。

まぁ、６月末まで締め切りが延びたからいいか。。。。

会社のロゴ。

会社のロゴ。こんなん作ってみました～。

cic_logo_final_06.pdf

cic_logo_final_05.pdf

cic_logo_final_04.pdf

cic_logo_final_03.pdf

mixi で知らない人から仕事頼まれた。

mixi で知らない人からメッセージが来た。

内容は、ホームページを作ってほしいとのこと。

なんでもカスタムハーレーの工房のようなものを

やっている方らしい。

サンプルのホームページもあって、

これならなんとかできそう。。。。

就職決まりました。

先月の話ですが、就職が決まりました。

それまで三年務めた会社は、ソフトウェアシステムの開発会社だったのですが

不況のあおりで仕事がなくなり、５人の技術者を辞めさせたのです。

私は、契約社員だったのですが、正社員も辞めさせるということでした。

それくらいその会社は、厳しい状況だったのでしょう。

今回決まった会社は、チャレンジド・コミュニティの

チャレンジド・ＩＴセンターという事業部です。

就職活動は、一か月で終了、ボランティアなどいろいろやってみたいことが

あったのですが、それよりも就職活動を優先しました。

農業なんかも興味はあったのですけどのね。

今は、そのＩＴセンターでロゴ作成の課題をやっています。

現在、考えたロゴは、こんな感じ。。。。。↓

cic_logo_final_01.pdf

cic_logo_final_02.pdf

まだまだ会社自体ができたばかりで、すべてを最初からやっている感じです。

このブログでは、ＮＰＯ法人で働く、統合失調症の私 den256 の

仕事の様子を綴ってゆきたいと思いますのでよろしくお願いします。

プログラムを早くたくさん組め！というのは、間違いだ。

私は、プログラムを早く組め！という考え方には、反対だ。

プログラムを早く組むという言うことは、

記述の量が増えるということだ。

記述量が増えるということは、管理しなければならない

プログラムの量が増えるということだ。

管理しなければならないプログラムの量が増えるということは、

読まなければいけないソース増え、結局、

管理コストが増える。

その結果、重複コードが増えて行き、

ますます管理コストが増えてゆくという悪循環に陥る。

しまいには、そのシステムの管理が立ち行かなくなる。

そうならないためにもコード量を減らす、リファクタリングが

重要になる。

そのシステムを長生きさせたいのなら、急いでシステムを

構築するのではなく、ゆっくり良く考えてシステムを

構築してゆくのがまともな考え方だと思う。

システムエンジニアは、和製英語で、海外では通用しない。

http://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2

引用。

ただし、「システムエンジニア」(SE)は和製英語であり、海外では「プログラマ」「ソフトウェアエンジニア」の領域である。

システムエンジニアには、なりたくない。。。

システムエンジニアには、なりたくない。

システムエンジニアというのは、

わがままで

協調性がなくて

人の話が聞けなくて

力で人を支配しようとして

言葉がうまくて

信用できない

それに対して、プログラマは、

やさしくて

協調性があって

賢くて

人の痛みがわかって

きつい仕事をみんなで協力して

乗り越えようとする

自分は、プログラマでいたいと思う。

客をだまそうとするな。

客をだまそうとしても無駄だと思う。

だいたい客をだましたつもりになったひとの話は、

お客には、ばれている。

顧客との信頼関係なくして、

おれたちの仕事は、成り立たない。

バグは、どんなに気をつけていても、

思わぬところで出てくるものだ。

そういうときに顧客との信頼関係が重要になる。

バグがあっても、顧客には、最低限、迷惑をかけない

予防策が必要だと思う。

よくあるシステム会社は、そういう社会人としての

常識みたいなことが、わかっていないと思う。

開発者が自信を持って、リリースできないシステムを

営業が自信たっぷりに売り込むところに

すべての悪の元凶がある。

そんなことをやってるから日本のシステム会社は、

インドや中国、アメリカに負けるんだよ。。。。

一人で開発しているとアジャイルは、必要ない。

アジャイルは、ひとりで開発しているのでは、アジャイルにならないんだなぁ。。。と

実感した。

会社を辞職して、ひとりで開発をしているけど、アジャイルなことは、ひとりでは、

考えない。

言われてみれば、当たり前なんだけど、アジャイルというのは、

チーム開発のための開発手法なんだなぁ。。。と改めて、実感しています。

ひとりでも開発はできる。

じゃぁチームで開発するメリットは、なんなのか？というところが、

ひとつ重要なことだな。。。。という気がする。

確かにチームで開発すればたくさんのコーディングを

手分けしてできる。大きなシステムを開発できる。でも、そこには、

カウボーイコーディングにならないように制御する手法。アジャイルが

必要なんだなぁ。。。。と実感した。

テストで大事なのは。。。

車を運転していて考えたこと。

テストで重要なのは、「観点」だと思う。

どういう観点でテストをするかの？

その観点が多いほど、テストの品質は、

良いといって言いと思う。

たとえば、

誤った操作に対する耐性は、どの程度あるか？

とか。

単体テストは、どの程度行っているか？

とか。

（フェールセーフ）安全性（バグったときにどの程度、安全に動作するか？）の観点では、どの程度か？

とか。

機密情報に関する扱いは、どの程度安心できるのか？

とか。

シナリオテストは、十分に行われているか？

とか。

などなど。。。。これが多いほど、テストの品質が

高いといえるのではないだろ言うか？

他にもあったなぁ。。。。忘れた。。。

統合失調症プログラマ日記を始めました。

統合失調症プログラマ日記を始めました。

別に私は、統合失調症で差別を受けたわけではないのですが、

意外と知られていない、統合失調症について、

ブログにすれば、興味を持つ人もいるのではないかと

言うことに気づき、このブログをはじめます。

統合失調症は、様々な症状があるのですが、

その中の私の症状、被害関係妄想について、

書いてゆきたいと思います。

よろしくお願いします。

アジャイルソフトウェア開発プロセスは、大規模システムに向かないのか？

アジャイル開発のメリットデメリット
http://jp.meritdemerit.com/topic/712

このサイトのアジャイル開発のデメリットに大規模開発に向かない

という記述があるがそれは、捉え方の問題ではないかと思う。

そもそもアジャイルソフトウェア開発というのは、

大規模な開発によるリスクを軽減する開発モデルだと思う。

大規模なソフトウェア開発プロジェクトには、

プロジェクトが頓挫したり様々なリスクが考えられる。

そのリスクを開発規模の縮小化と部分ごとのリリースによって

リスク削減するのがアジャイルではないかと思う。

今、自分がいる場所は。。。

今、自分がいる場所は、ソフトウェア開発の本流から離れた

一地方なのだと気づいた。

本流に戻らなければいけない。

もしかしたら、ここのブログで自分が書いている気づきは、

もう本流のなかの誰かが既に気づいたことなのかもしれない。

ソースコードは、それ自体、知識の記述だと思う。

ソースコードは、それ自体、知識の記述だと思う。

問題は、ソースコードに埋め込まれた業務知識を

どうやって抽象的な定義にするかでは

ないだろうか？

そのヒントは、メソッド抽出だと思う。

どっちがマシ？

読めないけどバグはないプログラムと

バグはあるかもしれないけど、読みやすいプログラム。。。。

ソースコードは、コミュニケーションのツールだと思う。

ソースコードは、コミュニケーションのツールだと思う。

Excel で記述した設計書よりも ソースコードのほうが

より具体的だし、実行、検証もできる。

みんなソースコードで設計の話をするべきだ。

プログラムの品質。

プログラムの品質としてバグが無いことをまず最初に上げるべきなのかもしれないが、私は読みやすさ、変更のしやすさを上げたい。

プログラムが読みやすく、変更しやすければ、修正によってバグが入り込む可能性が下がるし、バグがあっても修正がしやすいからだ。

そのときにプログラムの読みやすさをセンスや個人の技量にゆだねては、いけないと思う。

読みやすいプログラムには、一定の規則がある、規約が正しく作られている会社であれば、誰もが読みやすいコードを記述できるはずだ。

プログラムの規約が正しく記述されているか、それを検証する仕事もそのうちに必要とされるのではないかと思う。

規約の検証項目には、アルゴリズムの一意性を私は、加えたい。

何かしらの振る舞いの記述がシステム内で一箇所で記述され、それがメソッドとして抽出されていて、その振る舞いを必要とするプログラムでは、そのメソッドを呼び出すことで処理を実現しているということである。

この変数何！？って言うのもやめてほしい。。。

この変数名何！？って言うのもやめてほしい。。。。

もっと分かりやすい名前を付けてくれ。。。。

プログラムは、愚直であることが必要だなぁ。。。と思う。

そうだ。。。今気づいた。

変数名が閉じているか開いているかの違いなんだろうな。

公に知られている名前を変数名にすれば、

はじめてそれを見る人にも理解できる可能性が高い。

そういうことだなぁ。。。。

ドメイン記述言語とセマンティクWebって関係あるの
かな。。？

コピペでソースを作るのは、やめてくれ。。。。

あるシステムのソースを読んでいて、ほとんど処理が同じだ
という二つのプログラムを DF で比較してみた。。。。

すると更新処理は、ほとんど一緒。

なんで一緒なのに一つのモジュールにまとめないんだ。。。。

そういうことをしていると、どんどん管理するソースが
増えていって、しまいには、管理しきれなくなる。。。。。

ほんとそういうのは、やめてほしい。。。。

システム開発の流れ。

http://docs.google.com/fileview?id=0B9Mcgt67LaE4NjYxMGUyMTgtMjhkOS00NjBhLTk0NzAtMjkyOGViODFjYmRj&hl=en

一般的な業務アプリケーションの構造。

http://docs.google.com/fileview?id=0B9Mcgt67LaE4MDY3NDhjYjQtZDM2MS00NThkLTllMDctMWE5YmM3ODkzYTA5&hl=en

モジュール化で単体テストを自動化しよう！

テストに関して言えば、モジュール化は、
テストを自動化する上で意味があります。

データベースや画面に関係なく、計算処理など
モジュール化すれば、そのモジュールに対して
テストコードを記述することができます。

テストにもモデルって必要かも。。？

テストにもモデルって必要かも。。。。。？
と思った。

テストにもテストパターン（再利用できるテストの観点）が
あるよな。。。。？
と思った。

テストするときに重点テスト事項って言うのも
あるな。。。。要求が理解できたうえでテストを
するとそうなると思う。

設計にも検証（テスト）が必要だ。

設計にも検証（テスト）が必要だ。と思う。

失敗しそうになったプロジェクト（何とかなったらしい）で問題になったのが「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


昨日、ある異業種間交流会のようなものに出たのですが、
そこでホンダのソフトウェアの技術者がいました。

私よりぜんぜん若いのですが、ソフトウェアの検証と管理を担当している
ということで、納品されたソフトウェアの品質は、どうしたら保証できるのか？
という問題で悩んでいるという話でした。

彼がメーカーにソフトウェアの保証をしてくれといったら、
それはできないと言われたとぼやいていました。

確かに保証の範囲という問題があるので、単に保証してくれと言っても
どこまで保証すればいいんだ？となると保証できませんと言われるのかも
しれません。

テスト仕様書（チェックリスト）にチェックするか、テスト結果を
提出するしか、ソフトウェアメーカーとしてはできないと思います。

ユーザがどのような使い方をするかは、基本的に予測しにくいですし、
誤った使い方に対する耐性という意味でフールプルーフ（愚か者に対する耐性）
というのがありますが、ひとつづつ書き出していく以外に
保証する方法は、ないのではないでしょうか？

フリーソフトに関する話題。その十九。

フリーのスケジュール作成Excel

開発マイルストーン
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 です。使いやすいのかなぁ。。。。

フリーソフトに関する話題。その十七。

UWSC

http://www.uwsc.info/

使ってみたわけではないですが、画面操作を自動化できるツールのようです。
テストに応用できるかもです～。

フリーソフトに関する話題。その十六。

Folder Size

外人が作った、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>

とか、だとすると、もう少しプログラムで
処理できるかもしれない。

という理由からかもしれないと、思いました。

が！

フリーソフトに関する話題。その十三。

C#にも対応、カスタマイズ性もアップした「JUDE/Professional 5.3」

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

どちらもフリーウェアのようです。

フリーソフトに関する話題。その十一。

「情報共有」：JUDE/Professional, Community の 5.4 が公開されました

Jude Community Edition が UML 2.0 に対応したそうです。

Community Edition というのは、コミュニティでバグ取り、検証を行うためのバージョンで

無料で利用することができます。

UML を描くツールにお金をかけたくない場合は、こちらを利用するとよいかもしれませんね。

フリーソフトに関する話題。その十。

写真

「知識共有」：どこでもホイール。

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（システム工学モデリング言語）は、システムの境界を越えて存在する「要求」を客観的にモデル化することに成功し、ハードとソフトの境界を越えた「システム」の設計を初めて実現するものとして熱い注目を集めています。

フリーソフトに関する話題。その八。

Visual Stuido でタスク管理できることに気づきました！

http://msdn.microsoft.com/ja-jp/library/zce12xx2(VS.80).aspx

// TODO

でやることを記述できるようです。

Eclipse と変わらないんですね！

フリーソフトに関する話題。その七。

Visual Studio 2008 って、クラスダイアグラム描ける
んですね！

今日、はじめて知りました！

皆さんも試してみてください！

○なぜクラスダイアグラムが必要かについて（私見）

プログラムを組んで、完成して、それを別の誰かに
引継ぐような場合。

そのプログラムがどんな特性を持っていて、
どんな静的な構造をしているのか？という情報は、
プログラムを理解するうえで重要です。

それを表すのがクラスダイアグラムと言えるのでは
ないでしょうか？

もちろんクラスダイアグラムだけでは、
表現しきれないこともあると思います。

そのときは、適時、コメントを加えたりしながら
知識の伝達をした方がよいのではないでしょうか？

フリーソフトに関する話題。その六。

さらにメソッドを選択して、「すべての参照の検索」をすると
メソッドが参照されている箇所が一覧できますね。

Eclipse とほとんど変わらないかもしれませんね！

フリーソフトに関する話題。その五。

> このアドインを利用すれば、Eclipse 見たいに メソッドの一覧が見れるようですね。
> アスペクト指向っぽくなるかな？

クラスビューを使えば、このアドインは、必要なさそうですね。

フリーソフトに関する話題。その四。

.Net のアドイン CodeSmart を紹介しているサイトのようです。
いろんな機能があるんですね～。

http://www.axtools.com/codesmart-vb6-screenshots.htm?gclid=CPPb8qeRg5cCFQEspAodxHXFYA

このアドインを利用すれば、Eclipse 見たいに メソッドの一覧が見れるようですね。
アスペクト指向っぽくなるかな？

でも、残念ながら、これは、フリーウェアではないようです。

$249 だから、２万４０００円くらいでしょうか。。。。

フリーソフトに関する話題。その三。

写真

.Net 版もあるようですね。

http://www.mztools.com/index.aspx

フリーソフトに関する話題。その二。

MZ-Tools 3.0 for VBA / VB6 / VB5
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 は、いまいち、心細いんですよね～。

ユーザー横断的な部品を作るには？その一。

以前、○○さんからユーザが変わっても使いまわしの利く
部品を作って、開発効率を上げてよ！！！

という要望がありましたのでこのスレッドを立てます。

基本的には、各プロジェクトのソースコードを
部品化してゆくことと、ユーザが変わっても普遍的な
テーブル定義の二つができれば、
ユーザを横断した部品が定義できるのではないかと
私は思うのですが、皆さんはどう思いますか？

というスレッドです。

それか、テーブルの定義に依存しない抽象的な
アルゴリズムを定義できれば良いのかもしれません。

まぁソースコードの話ですので、なにより読みやすいほうが
良いと思います。

共通部品の開発には、詳細設計が重要。。。？

Windows 運用に関する Tips、その二。

Tomcat の Web アプリケーションマネージャは、攻撃の対象に
なるようです。

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://d.hatena.ne.jp/higayasuo/20090509/1241852749

ひがやすをブログのコメントより。

これは、ひがさんの信念なのでしょうね。私もどちらかというと、賛成です。

設計学？その十六。

Dao について某医療機器販売会社のソースを読んでいて気づいたことです。


http://docs.google.com/fileview?id=0B9Mcgt67LaE4OTZkYmY1NTAtZDdjMC00ZmQyLTk2YzAtNmQzMTkwNjEzNGE4&hl=en


Dao の設計を末端のプログラマに託すべきではない。

Dao の設計は、テーブルを設計した（定義した）者にやらせるべきだ。

なぜならデータの発生、更新、消滅のライフサイクルを知っているのは、

テーブル定義者だからだ。

設計学？その十五。

設計をするなら。。。。

Excel で設計をするよりもプログラミング言語で設計したほうが、

工数が削減できるのでは？

設計学？その十四。

【伝わる！モデリング】はじめようUML！

http://www.thinkit.co.jp/article/40/

業務フローは、アクティビティ図。
要求定義は、ユースケース図。

のようです。

設計学？その十二。

http://ja.wikipedia.org/wiki/Object_Constraint_Language

中略。

ナビゲーション言語として見た場合、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

「これは、対象となるシステムにもよるものなのですが、例えば業務システムのようなジャンルでは、オブジェクト指向分析・設計は採用しない方が現時点では多数派です。不思議なことのように聞こえますが、これもプログラマーの常識です。」

設計学？その十一。

「知識共有」：Object Constraint Language

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文を読もうとすると重要な情報である
テーブル名が別の変数名に置き換えられ、
隠蔽されているため前のテーブル宣言に
戻って変数が示すテーブルを見なければ
なりません。

このようなコードを読みづらくする
習慣がいつまでも引きづられてなくならない
原因は、各自がオリジナルのコードを
作ろうとしないことによると思います。

オリジナルにある程度、読みやすい
コードを記述するように心がけていれば
自然と読みづらいコードは、無くなってゆく
と思います。

コードを読んでいて、ストレスが
たまったので、ここで発散しただけです。。

設計学？その八。

「思ったこと」：ソフトウェアの流通。

特定の顧客向けにシステムを開発しますが、そのシステムの管理者が
変わると言うことは、ソフトウェアが流通していることと同じことに
なるのではないだろうか？

なぜこんなことを思ったかというと。

某医療機器販売会社のデータを見ていると製品テーブルにバルク品が入っていたりするのです。

バルク：http://kaden.yahoo.co.jp/dict/?type=detail&id=2004

これは、製造中止になった製品のバルク品を処分するために
製品として登録して、販売したということではないかと思いました。

このとき、システム管理者がバルク品を製品テーブルに登録しても
よいかどうか判断するのですが、それは、システム管理者によって
判断が分かれると思います。

それは、今後、システムをどう運用してゆくかと言うことにも
かかわってきます。

私だったら、あまり融通を利かせないで、例外的な処理、又は、
データは、システムには含めないと思います。

そういうことも含めて、開発しているシステムは、流通できる
（他の人の手に渡せる）ものなのでしょうか。。。。

何でもできる、汎用性を高くするのは、大変だし、
何でもできてしまうのは、システムじゃないんじゃないのかなぁ。。。。

そうすると利用頻度が高いものから、手作業で行うとコストのかかるもの
からシステム化してゆくべきなのかな。。。。

設計学？その七。

それと某ＳＩは、規約は良くできているのですが、
実際の実装は、えっ！それってどうなの。。。。？って言うのがありますね。

たとえば、データベースのアクセスをすべてストアドプロシージャで
記述するというところ。。。。。

確かに外だし SQL っぽくて、SQL文自体は、読みやすくなるのかもしれないけど。。。

なんかデータベースのアクセスは、クライアントで記述するって言うのが、
これまでのやり方だったのでちょっと戸惑いがありますよね。。。。

設計学？その六。

某ＳＩの規約が先週届きました。
それを読んでみて、結構良くできているな～と思いました。

どの辺がかというと、

「変数に二つ以上の意味を持たせてはいけない」
「関数の戻り値に二つ以上の意味を持たせてもいけない」

というところです。

確かにプログラムが長くなるとひとつの変数が
いろんな意味で使いまわされることもあるかもしれません。

確かにそれは、プログラムを読みにくくすると
思います。

やっぱりプログラムは短く、

長くなりそうになったら、いくつかの関数に分割するのが

いいですね。

設計学？その四。

http://www.microsoft.com/japan/powerpro/TF/column/tn_09_1.mspx?rss_fdn=MSDNTopNewInfo

ソフトウェア開発においてモデリングは、重要な成功要因として挙げられますが、果たして現場で効果的に適用できているでしょうか？難しいといわれるモデリングの実践ですが、原点回帰し見つめなおすと糸口が見出せるかも。by Microsoft

モデリング自体は、コーディングをしていれば自然にしているので
モデリングすることが重要というより、モデルを図面化していることの方が
重要なのでは？と思います。by 佐藤

設計学？その五。

UML で絵を描くことだけがモデリングではないと思う、今日この頃。
by 佐藤。

設計学？その三。

東大の先生が提唱している設計学のページがありました。
皆さんの設計業務の再考にお役立てください。

http://www.race.u-tokyo.ac.jp/~takeda/designtheory-j.html

設計学？その二。

思い出しました。

行き当たりばったりはよくない。
計画、設計は、大切だということに気づいた
という話でした。

まぁ、設計しろと言われても
どこまで設計できんだよ！という話で。

そんな設計時点では、はっきりしていなくて、
決めらんないこともありますよね～。

そいうときは、ある程度抽象的なレベルでの
設計になっていいはずですよね！

それに設計したよ！って渡されても、
その設計の内容がいまいち良くわかんない
こともあります。

それは設計者が実装者にちゃんと
伝えなきゃいけないと思うのですよ。。。

。。。。そんな話です。

設計学？その一。

一品香でラーメンを食べていた思ったことがありました。
どこかに記録しておかないと忘れるのでここに
残します。

もし皆さんもこのテーマについて、意見がありましたら
書き込みをお願いします。

何年か前、ITアーキテクトという雑誌がありました。
JavWorld がインターネットの普及で売れなくなったのか
IDG（だったかな？）が発行を始めたものです。

その雑誌も時が流れて、今はなくなり（だったかな？）
ITアーキテクトと言う言葉だけが、私の記憶の片隅に
存在していました。

IT の建築家？そりゃ分かるけど。。どういう意味？

そのときの私の理解は、情報システムを構築する
基盤を設計する人のこと。。。。

確かに情報システムは、度重なる変更にも耐えうる
アーキテクチャが必要だと言うのは、わかります。

-------

設計をするときにそのシステムの変更可能性についての
要求は、あまりはっきりせずにシステム化することは
多いのではないでしょうか？

今は、オブジェクト指向が普及しているので
クラスの継承によって、新しい振る舞いの
プログラムを安全に追加できる仕組みができてきました。

-------

プログラムの変更が安全にできるかどうかは、
プログラム変更者がそのプログラムの構造を理解しているか
によるのではないでしょうか？

ある部分への変更が他の箇所へ影響しないことも
必要かもしれません。（情報の隠蔽、カプセル化）

-------

あと早くプログラムを作ることも要求されがちです。

早く作ると言うことは、その分、コストが下がり
顧客の必要なそのときに必要なシステムを提供する
ことができます。

-------

プログラムを作るうえで規約やルールに
従順であることは。。。規約やルールを作り出すことにも
創造性が発揮されるのではないでしょうか？

ルールや規約に柔軟に対応できると言うことは
ルールや規約に縛られているようでも
実は、ルールや規約から自由なのではないでしょうか？

-------

設計やプログラミングをしていて、
うちの会社はこういうやり方があるから。。。とか
うちの会社の習慣だからという理由で
実装が決まったりすることがあるように
思います。

たとえば某ＳＩのシステムでは、
理由が分からないですが、データベースにメニュー項目を
持たせます。

一見、何でそんなことをするのかと問いたくなります。

今回のシステムでそれほど頻繁にメニューの追加や削除が
あるのでしょうか？

システムの実装の習慣を引継ぐことは、
本当に変更に強いシステムになるのでしょうか？

そんな時、システムのアーキテクトが必要だと感じます。

---------

なんか大事なことを忘れた。。。。。気がする。