プロのプログラマのプログラム教えて（パート2）

前のスレッドが大きくなりすぎて一般のブラウザでは読めなくなりました。
そこで、パート2を立ち上げます。前スレは
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=994898315
でした。
まだ、前のスレの後半部の議論は解決しておらず、また、いろいろお礼
もまだですが、とりあえず、再開いたしましょう。

みなさま、また、教えてください。m(__)m

http://members.jcom.home.ne.jp/katjusha/

　∩ ∩
　| ∪ |
　|　 〜
　|∧ ∧　　　／適当ですが
　( ,,ﾟДﾟ)つ ＜　ブラウザで過去ログヲ見られるようにしておきました。
　Ｕ　　　　　　＼

プロのプログラマのプログラム教えて
http://www42.tok2.com/home/from2ch/propropro/
http://www42.tok2.com/home/from2ch/propropro/1.html

新スレも順調に続くといいね。

>>3
Delギコさん、いろいろありがとうございます。
こんなことができるんですね。驚きました。
これからもよろしくお願いいたします。
まずはお礼まで。

＞3
＞4
ありがとうございます。最強の未熟モノなので
たいへん勉強になります。
2ｃｈでこんないい講座やってたなんて・・

>>前スレの732 （エラー処理について）
ありがとうございます。なるほどそうなのですか。

プログラムで「エラー処理」をする場合、プロのみなさんはどうするの
でしょう。「エラー処理をしろ」と書いてある教科書は多いのですが、
「具体的にどうするか」を書いてあるものは少ないような気がします。
もちろん、ケースバイケースと言えばそれまでなのですが、何か、話
していただけることがあれば、ぜひぜひお願いします。

エラー処理について。
もちろん参考にならないでしょうが、私が書くような「どうでもよいプ
ログラム」の場合、エラー表示をして即終了にします。ファイルクローズ
などリソースの後始末はしているつもりですが。

ちなみに、何でもないプログラムを、ネット越しで動かした（TCP/IPとか
ではなく、Windowsネットで見えているファイルをローカルにあるように
扱うドキュンもの）ことがあります。たいてい問題はなかったのですが、
途中で接続が切れたときに、アクセスしていたファイルが（おそらく）
開きっぱなし状態になって、難儀したことがあります。

新スレしょっぱなに、大バカな例ですみません。

エラー処理は最小限にね！

エラーの(原因箇所|発見箇所|対応箇所)×5W2H

まず、
>TCP/IPとかではなく、Windowsネットで見えているファイルをローカルにあるように
扱うドキュンもの

ってのは、プロは作らないな。

>>10
>ってのは、プロは作らないな。

俺は、過去いくつか作ったけど。
Windows-Netware連携モノとか、
NFS経由の連携モノとか。

>>11
ふーん。そりゃ、すごい。

>>11
自分も作ったなぁ。
クローズなシステムであることが前提ですが。

>>12
すごいだろー（藁

>>14
ふーん。そりゃ、すごい。
つーか、キミ、うざいよ。

>>11 >>13
こいつらは、プロじゃなくてドキュソ

　∧ ∧　 　／
　(,,ﾟДﾟ)　＜　>>新人氏、もそっと食いつきのよいネタキボーン
　 |つ つ　　＼
〜 　　|
　∪ ∪

エラー処理って。範囲広すぎるし〜。
共通して話せることないよ。やるときはやるしやってないときはやってない。


具体例をちょっぴり話すけど
ついこの間、客先で1年間動いてたシステムが
突然とある画面が表示されないと報告を受けて
どうも電話では要領を得なかったので、
逝ってきました。

つーか。1年も無事に動いてるシステムが突然止まるなんて
開発した折れも原因がさっぱりわからなくて
「かなりやべー。」と思いつつお出かけ。

で、逝ってｶｲﾊﾂﾂｰﾙを居れてトレースしながらようやくわかりました。
(ｶｲﾊﾂﾂｰﾙあってよかたよ。)

顧客の年齢を求める処理で
まず、客の生年月日と今年とで引き算して経過年を出す
今年の客の誕生日が過ぎているか過ぎていないかで±1をする
という処理をしてたんだけど

DelphiのTDateTimeという日付型は現実に存在する日付しか許容しない型がありまして、
さっきの処理で"今年の客の誕生日が過ぎているか過ぎていないか"という所にて
ここに。閏日。つまり2/29生まれの人が入ってきたわけ。
今年の2/29なんて存在しないから
いきなり例外発生して、プログラムはとりあえずストップ。
画面遷移中に計算する処理をしていたものだから
exeは存在するのに画面は存在しないという、素晴らしい動作をしていたわけさ。

だけど。こんなこと。事前にここで例外が発生することなんて予測できてないから
(予測してたら対応しているしさ)
例外発生したら止まるに決まってるわな。

で、テキトウにちょちょっと直して帰ってきました。

>>17
>さっきの処理で"今年の客の誕生日が過ぎているか過ぎていないか"という所にて
>ここに。閏日。つまり2/29生まれの人が入ってきたわけ。

つーか、キミ、そんなこと良く恥ずかしげも無く公表できるね。
寒すぎる。

>>18
はげどう。
Delギコ氏としては、ちょっと失敗だったな。

　　　 ∧ ∧　　　／￣
　　∩(,,ﾟДﾟ)　＜　折れは、自分のソースを恥ずかしくて隠すような
⊂,,⌒　,,つつ.　　＼ﾈｺにはなりたくないもんでね。
　　￣￣ 　　　　　　自分の失敗も同じ。

>>18-19
じゃあ、DelphiMLのヤツ全員に言ってやってくれ。
かの、年齢算出関数はMLのログから博ってきたから
安心して使ってたんだYO。

>>20
>かの、年齢算出関数はMLのログから博ってきたから
>安心して使ってたんだYO。

つーか、キミ、そんなこと良く恥ずかしげも無く公表できるね。
寒すぎる。

やっぱり、かっこいいDelギコ。

いや、待てよ。人のせいにしてる。
かっこわるいDelギコ。

　　　　　　　　　　　　　　　　　　　　　　　つーか　　　　キミ　　　　　　恥ずかし
　　　　　　　　　　　　　　　　　　　　　　　　げも無く　　公表　　　　寒すぎ
　　　　　　　　　　　　　　　　　　　　　　　　　∧＿∧　　 .∧＿∧　　∧＿∧
　　　　　　　　　　　　　　　　　　　　　　　　 （ ﾟ∀ﾟ　 ）　 （ ﾟ∀ﾟ 　）　（ ﾟ∀ﾟ　 ）
　　　　　ｶﾁｶﾁｶﾁｯ　　 　,＿＿　　　　　　 ⊂　　　　つ⊂　　　　つ⊂　　　　つ
　　（　　　∧_∧ｲｯﾃﾖｼ!! |_|＿_|　　　　　　　　 Y　 人　　　Y　 人　　　Y　 人
　⊂ ´⌒つ ﾟДﾟ)つ≧　　/∫ ヽ　　　　　　　　（＿） Ｊ　　 （＿） Ｊ　　 （＿） Ｊ
￣￣￣￣￣￣￣￣~~~~~~~￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　ﾋﾞｼｭ!!　　　　　　ﾋﾞｼｭｼｭｼｭｼｭｼｭｼｭ!!!!
　　　　　　　　　　　　　　　　　　　　　　　　　ﾋﾞｼｭ!!　　∧　　　。＿∧　；ζﾟ 　）;；*∴；
　　　　　　　　　　　　　　　　　　　　　　　。　 。　∧;：,∴。＿　つ　 ∧_　：*;：,∴ ∧＿∧：*;：,∴
　　　　　　　　　　　　　　　ｽﾞﾊﾞﾝ!!!　　。　。・　　;（ ﾟ∀ζ*　）（ﾟζ；　　*）　从（ ﾟ＜：;：,∴
　　　　　　　　　　　　　 　 , ﾉ从ゝ　　　　。　⊂　　∴　。　*　γ；　∴つ ⊂　：;：,*∴　：;：∪
　　（　　　∧_∧　　　　　 ||　　　Σ　。　　。。从从 ； 人。：*;：,∴　从Yζ　；人　　　Y　 人
　⊂ ´⌒つ ﾟДﾟ)つ≧　　/∫Wヽ　　　　。　（,∴＿）　。;：,∴　 Ｊ　（＿,∴） 　Ｊ　,∴（＿） Ｊ：*;：,∴
￣￣￣￣￣￣￣￣~~~~~~~￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　ｼﾝﾃﾞﾖｼ

　∧ ∧　　　 ／テストが足りなかったのは確か。
　(,,ﾟДﾟ)　　＜　XPでｶﾞﾘｶﾞﾘにテストコード書いておけば
　 | つ[|lllll］). ＼閏日なんて陥りやすい罠はチェックしがいがあるので
〜| 　 | 　　　　　きっと未然に防げたに違いない。
　 ∪∪ XPﾏﾝｾ--

でもーーーー
この程度のﾐｽ、2000年問題をひきおこしかけた
大勢のどこかの人々よりはるかにマシじゃないっす？

…例外やエラー処理の話とはかけ離れてしまﾀ。

それにしても。閏日に生まれるなよ。80いくつのジーチャン．．．(そのときのﾃﾞｰﾀの人)

日付の処理で閏年のことをテストするのは
ごっつ当然だから、やっぱりねー

＞ちなみに、何でもないプログラムを、ネット越しで動かした（TCP/IPとか
＞ではなく、Windowsネットで見えているファイルをローカルにあるように
＞扱うドキュンもの）ことがあります。

自分がやったのは制御系のCSシステムで、サーバーからクライアントPC
上のexe ファイル（VB)を起動させるというやつ。
・モニターがサーバーのものしかない。
・クライアント部分に属するPGはクライアントPCに置かなければならない。
という縛りの為、このような結果に。

でも、端末からサーバー上のファイルをアクセスしに行くのって
割と普通にしないか？（例：VB端末よりサーバーのAccessファイルを
アクセスしにいく）

>>27

>自分がやったのは制御系のCSシステムで、サーバーからクライアントPC
>上のexe ファイル（VB)を起動させるというやつ。

サーバーアプリをクライアントに置いて、サーバーからクライアントPCの
サーバーアプリへVBのexeを起動する命令を送るのが普通じゃないか？

>でも、端末からサーバー上のファイルをアクセスしに行くのって
>割と普通にしないか？（例：VB端末よりサーバーのAccessファイルを
>アクセスしにいく）

これてって、間違いなくドキュソじゃないか？

>>27
えーと、27は俺じゃないです。

>>11 >>13
ありがとうございます。プロの方も作るのなら、「ドキュン」とか勝手に
言ってはいけないですね。すみません。作らないという方も多いようですが。
再現実験を繰り返してないので、いいかげんですが、実はOSの責任もあるか
なとも思いました。NTだけだと大丈夫で、死んだやつはみな95がらみでした。

>>17
>新人氏、もそっと食いつきのよいネタキボーン
すみません。考えます。
でも、Delギコさんのお話、とても参考になりました。「Delギコさんでも
エラーを出すことはある」と解釈すべきですね。^^)
（>>24 笑いました。）
マイナーですが、実は、「客先で開発環境をインストール」も参考になり
ました。私の「客先」は、学校の事務職員だの同僚だのですが、開発環境
入ってたらなーと思うことがよくあります。

ちなみに、>>14も俺じゃない。
そんなことやって楽しい？

>>31
偽者が現れるなんてうらやましい。

>>30
>作らないという方も多いようですが。

ネットワークファイルシェアリングを使わないという人は、

・使わざるを得ない状況に遭遇したことがない
・リスクも無く使えるのに、わざわざ別の手段を使っているのでは

という気がします。

>でも、Delギコさんのお話、とても参考になりました。「Delギコさんでも
>エラーを出すことはある」と解釈すべきですね。^^)

うーん、Delギコ氏の話は、単なるバグの話のような（失礼）。
そういう話をしたいの？＞新人氏

　　　　　 ∧ ∧　　／￣￣￣￣￣￣￣￣￣￣￣
　〜' ― (,,ﾟДﾟ) ＜　やっぱし？>>33
　 　し― し-Ｊ　 　＼＿＿＿＿＿＿＿＿＿＿＿
　ﾊﾞｸﾞ ﾀﾞｼﾀｺﾄ ﾅｲ ﾌﾟﾛｸﾞﾗﾏ ﾊｲﾅｲ

エラーとか例外とか、何を話したらいいのやら。ｻｯﾊﾟﾘ・

前スレ読めねーよ

>>34
例えば、ファイルに何か書くような処理のときに、単に書き込む為のコードだけではなくて、
書き込みに失敗した場合の処理もちゃんと書いとけって話でいいんじゃないの？

起こりうるケースに対応できる全てのケースの処理を書けってのと同意でしょう。
＞エラー処理を書け

>>28
えーとですね、もうちっと解説しますと、

>>サーバーアプリをクライアントに置いて、サーバーからクライアントPCの
>>サーバーアプリへVBのexeを起動する命令を送るのが普通じゃないか？

クライアントアプリはクライアントアプリと言いながらも、サーバー上で
端末画面として起動させる必要がありまして…（ってことは、
クライアントPCで起動させてはいけない）、でもそれじゃあサーバー
アプリじゃん！って言われるかもしれませんが。。。

もっと突っ込んで話しますと、クライアント側にはまた別にクライアント
アプリが走っているんですよ。
で、サーバー上で動作するクライアントアプリ（画面）とそのクライアント
アプリが通信を行っているという。


＞＞でも、端末からサーバー上のファイルをアクセスしに行くのって
＞＞割と普通にしないか？（例：VB端末よりサーバーのAccessファイルを
＞＞アクセスしにいく）
＞これてって、間違いなくドキュソじゃないか？

じゃあクライアント一台、一台にきちんとODBCを設定しろとでも？
ん？サーバーでODBC設定すればクライアントからそれ
アクセスしにいけるんだっけ？
マジ忘れた。誰か教えて

>>37
>>>でも、端末からサーバー上のファイルをアクセスしに行くのって
>>>割と普通にしないか？（例：VB端末よりサーバーのAccessファイルを
>>>アクセスしにいく）
>>これてって、間違いなくドキュソじゃないか？
>じゃあクライアント一台、一台にきちんとODBCを設定しろとでも？
>ん？サーバーでODBC設定すればクライアントからそれ
>アクセスしにいけるんだっけ？
>マジ忘れた。誰か教えて

ODBCはあくまでもローカルコンピュータに対する設定なんで、ネットワーク越し
には覗けません。

ちなみに、上の人がサーバのAccessファイルを触ることに対して「ドキュソ」
と書いているのは、正確な意味でのデータベースの整合性が損なわれるためです。

要はAccessファイルを直接クライアントがいじる設定なので、裏を返せば
クライアント側からAccessファイルを壊すことが簡単にできてしまうということです。

もっと具体的に書くと、特定のクライアントのAccessドライバ(ODBCでも何でも良い)
にバグがあったとすると、そのクライアント一台だけのバグによって中央（サーバ）の
Accessファイルが壊されてしまいます。

すごくわかりにくいが、

>クライアントアプリはクライアントアプリと言いながらも、サーバー上で
>端末画面として起動させる必要がありまして…（ってことは、
>クライアントPCで起動させてはいけない）、でもそれじゃあサーバー
>アプリじゃん！って言われるかもしれませんが。。。

>もっと突っ込んで話しますと、クライアント側にはまた別にクライアント
>アプリが走っているんですよ。
>で、サーバー上で動作するクライアントアプリ（画面）とそのクライアント
>アプリが通信を行っているという。

って、

>>サーバーアプリをクライアントに置いて、サーバーからクライアントPCの
>>サーバーアプリへVBのexeを起動する命令を送るのが普通じゃないか？

ってことだよなー
それならそれで、別に文句言う気はない。

Accessについては38氏が代弁してくれたのでいいや。

>>18-19
失敗した事例を「ヴァカ」とあげつらうのは誰でもできる。失敗した原因を
系統的に分析して、二度と同じ失敗をしないようにするのがプロだろ？

すぐに失敗を責める傾向がある組織だと、みんな怖がって事例を出さな
くなる。その結果、いつになっても（組織全体として）失敗がなくならずに、
同じミスを繰り返すことになる。

失敗を責められることによって次は失敗しないようにするよ。
責められないとまた失敗する。俺は駄目な人間だ。

>>38
了解。

>>39
CSという形式を使わないほうが説明しやすいかもしれんが、
（というかCSじゃねぇな、これは）

・サーバー側にのみモニターがある。
・クライアント用画面exeはクライアントPCに置きたい。

という要望に答える為、サーバーアプリがネットワーク越し
にクライアント用画面exeを起動させるというハメに。

＞＞４２
うーん。やっぱりよくわからん。

クライアント用画面.exeはクライアントPCにあるんだよね？
で、そのクライアントPCにはモニタがないと。
で、サーバーPCからクライアントPCにあるクライアント用画面.exeを実行する。
もちろん、クライアント用画面.exeはクライアントPC上で実行されるんだよ。

ここまでがあってるとすると

サーバーPCからtelnetの用なものでクライアントPCに接続し
その中でクライアント用画面.exeを実行するっていうこと？
（もちろん、意味的にだよ。実際はアプリがやるだろうけど）

>>33 （最後の行） >>34
プレッシャーです。^^;)流れもありますし。

個人的には、今、XPにかなりお熱なんですが、3冊目が手に入らないのと、
ほかにもスレがたくさんあるのとで、ちょっと黙っています。
（まじで、何かやりたくてたまらなくなってますが。）
最近はCppUnitというのをダウンロードして読んでます。

>>27
おもしろそうな話題提供ありがとうございます。たぶん、もう少し具体的
に言ってもらえるとわかりやすいかもしれません。何に使うプログラムと
か。でも、そういうことはなかなか書けないですよね。

>>38
わかりやすい講義をありがとうございました。m(__)m
たぶん、整合性の問題は、サーバー側にDBサーバーを立てて、それにDB管
理を任せるべきという意味ですよね。

ただ、クライアント側のアプリがDBに排他的にアクセスするようにし、そ
のアプリそのものにバグがなければよい．．．ということにはならないの
でしょうか。「Accessドライバのバグ」は恐ろしいですが、それは、ロー
カルでも問題になるのでは、と思うのですが。
あるいは、問題発生時の問題の切り分けなどのため、サーバー上のファイ
ルに直接アクセスしない方針がよいということでしょうか。
おバカな質問ではあろうかと思うのですが、まじめに、DBやネットの勉強
をしたいので、お願いします。

＞ODBCはあくまでもローカルコンピュータに対する設定なんで
そうだったのか！Σ（ﾟдﾟlll）ｶﾞｰﾝ

ADO使ってAccess2000に接続すれば自動的に排他制御する。
Access2000でDBエンジンにMSDEを選択すればC/Sになる。
JetはDLLだからC/Sは実現できません(ファイル共有でリモート
におけばC/Sもどきにはなるが...)。

・・・らしいっす。某スレからのコピペなり〜。

>>43
>サーバーPCからtelnetの用なものでクライアントPCに接続し
>その中でクライアント用画面.exeを実行するっていうこと？
>（もちろん、意味的にだよ。実際はアプリがやるだろうけど）

あらかじめネットワークフォルダなどを作成しておいて、
サーバーアプリからネットワーク越しにクライアント画面.exe を
起動するっす。

クライアント画面.exe って言うからややこしかったか、
クライアント向け端末画面とでも言うべきだったか。
画面が表示されるのは当然、サーバー側のモニタだし。

>>45
ＣＳで説明したため、混乱を招いたみたいですが、
実際にはこんな感じのシステムです。
[制御機械側ＰＣ]-[ディスパッチャーＰＣ]-[端末ＰＣ]

[制御機械側ＰＣ]＝サーバー、
[ディスパッチャーＰＣ]＝クライアント
で説明していたのですが…。

つーか、キミ、とてつもなく説明が下手だね。
SEじゃなくて良かったね。

>>48
結局、わかりませんでした。
でも、もういいや。聞くのがあほらしくなってきた。

>>45
# 遅れたがいちおうちゃんとレス。

> たぶん、整合性の問題は、サーバー側にDBサーバーを立てて、それにDB管
> 理を任せるべきという意味ですよね。

少なくともクライアントに整合性の管理を任せてしまう（ファイル共有で
Accessファイルを触らせる等）よりはサーバでまとめて整合性管理をさせた
ほうが間違いないです。

コンピュータに限らず人間でも同じことが言えます。仕事の際にはリーダー
（サーバ）がきちんと身勝手な部下たち（クライアント）の要求や希望を
調整してあげないとプロジェクトが思いも寄らぬ方向に進んでしまいます。
それと同じです。

> 「Accessドライバのバグ」は恐ろしいですが、それは、ローカルでも問題になるのでは、と思うのですが。

確かにその通りですね。ただ、Accessに限らずファイルで動作するデータベースシステムは内部的に
トランザクションログ（最近の読み書き処理の記録）を持っているので、次回起動時に自動的に修復
される処理が動くので、気づかない場合も多いです。

ただ、ネットワーク上で共有させてしまうと、その修復処理は排他的に（他のユーザには誰もアクセス
させないで）行なわないと行けないので、常に利用されている可能性がある共有ファイルでは
その修復処理が動けないわけです。

> あるいは、問題発生時の問題の切り分けなどのため、サーバー上のファイルに直接アクセスしない方針がよいということでしょうか。

そういう期待感も実はあります。

# 蛇足ですがMSDE (Microsoft SQL Serverの無料版) がダウンロードして使うことが出来る
# （合法的に）ので、それを使ってみることをお勧めします。

ちょっとすみません。
MSDE用ODBCドライバにバグがあったらどうなるんでしょう。
ドライバのバグは、ファイル共有のDBだけなのでしょうか？

>>52
ありがとうございます。
>確かにその通りですね。ただ、Accessに限らずファイルで動作するデータベースシステムは内部的に
>トランザクションログ（最近の読み書き処理の記録）を持っているので、次回起動時に自動的に修復
>される処理が動くので、気づかない場合も多いです。
なんかものすごく勉強になりました。感謝感激です。
MSDEもダウンロードしてみます。DB関係はまだ相当のタコなんですが、奥が深いようですね。

スレに関係ないですが、今、かちゅ〜しゃを使ってます。もっとおどろおどろしいものを想像していたの
です（すみません）が、使い心地いいですねー。WEBサーバじゃなくて、独自のサーバソフトを作った
のでしょうね？って、すみません、これは質問ではなくて感想です。

>>47
45へのレスですよね。ありがとうございます。
Access+MSDEで勉強してみます。

>>55
サーバソフトじゃなくて、クライアントソフトだよ・・・。

>>54
学習という面から見ると、SQL92の準拠度の高さから、PostgreSQLが
おすすめです。
Windowsで動かそうとすると、ちょっと面倒だけど。

>>55 ん？
かちゅ〜しゃは2chのWEBサーバにある、テキストファイルを落としてきて
整形して表示してるだけだよ。
ブラウザで普通に２chを見るときはCGIがそのテキストを整形してhtmlをつく
ってる。

どうしようもなく馬鹿な俺様はここの管理人様↓
http://www.geocities.co.jp/Playtown-Queen/3674/
どうしようもなく馬鹿な俺様はここの管理人様↓
http://www.geocities.co.jp/Playtown-Queen/3674/
どうしようもなく馬鹿な俺様はここの管理人様↓
http://www.geocities.co.jp/Playtown-Queen/3674/
どうしようもなく馬鹿な俺様はここの管理人様↓
http://www.geocities.co.jp/Playtown-Queen/3674/
どうしようもなく馬鹿な俺様はここの管理人様↓
http://www.geocities.co.jp/Playtown-Queen/3674/
どうしようもなく馬鹿な俺様はここの管理人様↓
http://www.geocities.co.jp/Playtown-Queen/3674/
どうしようもなく馬鹿な俺様はここの管理人様↓
http://www.geocities.co.jp/Playtown-Queen/3674/
どうしようもなく馬鹿な俺様はここの管理人様↓
http://www.geocities.co.jp/Playtown-Queen/3674/
どうしようもなく馬鹿な俺様はここの管理人様↓
http://www.geocities.co.jp/Playtown-Queen/3674/

　 ∧ ∧　 　 ／かちゅーしゃなら
　 (,,ﾟДﾟ)　 ＜　　"59"を左クリックして[透明あぼーん]
　 |⊃ ,⊃　　 ＼
＠|　　|　ﾎｯﾄｿﾞﾇ ﾔ 2chﾌﾞﾗｳｻﾞ ﾊ ｵｰﾌﾟﾝｿｰｽ ﾃﾞ ｲｲｶﾝｼﾞ
　 ∪∪
　　　　　monazilla.orgをﾖﾛｼｸね

>>57 >>58
わざわざありがとうございます。
IEブラウザよりかなり速いので、かちゅ〜しゃサーバが立ててあるのかと思ったのです。
かちゅ〜しゃのログにない部分だけをやりとりするような。
速さの差は、たぶん、CGIの分なのですね。

PostgreSQLも見てみます。

学習用ならＡｃｃｅｓｓがいいと思うけど。
Accessでテーブルリンクを利用して、共有データファイルと
処理用画面ファイルを分ければいいし。

>>60
えっ。オープンソースなんですか？

最近、プログラム技術板も見るようになりました。
Delギコさんは、とても偉い方だったんですね。
Delphiは最初のバージョンを買ったのですが、Pascalがわからず挫折した覚えがあります。
また勉強してみたい気もしています。

　　∧ ∧∩ 　ｾﾞﾝｾﾞﾝ ｴﾗｸ ﾅｲｯﾃ ﾊﾞ
　　(ﾟДﾟ,,)ﾉ
　　 | 　つ 　　ﾀﾝﾆ ｶｷｺﾑ ﾘｮｳ ｶﾞ ｵｵｲﾀﾞｹ　
　　　|　⊂)〜
　　　 ∪ 　

ｵﾚ ﾅﾝｶ ｶﾞ ｴﾗｶｯﾀﾗ ｷｯﾄ ｳﾁｺﾛｻﾚﾙ

∩ ∧∧∩　　／￣￣￣￣￣￣￣￣
（ ( ゜Д゜)）　＜ 　撃たないで下さい
　 |　　 |　　　＼＿＿＿＿＿＿＿＿
　 | x |
〜| 　 |
　 ∪∪

　　　　　 　 ∫
　　　∧,,∧ ∬　　　　 　 ／￣￣￣￣￣￣￣￣￣
　　 ミ,,ﾟДﾟノ,っ━~　　＜　でも、えらそうにしてみるか。ﾌｻﾌｻ
＿と~,,,　　~,,,ﾉ＿.　∀　　＼＿＿＿＿＿＿＿＿＿
　　　 .ﾐ,,,/~),　　.|　┷┳━
￣￣￣ .し'J￣￣|...　┃
￣￣￣￣￣￣￣ 　 .┻
トコロデ、ｴｸｽﾄﾘｰﾑﾌﾟﾛｸﾞﾗｰのﾋﾟﾝｸ本読みました。(8割がた)

すばらしーと感じたんだけど新人氏はﾍﾟｱﾌﾟﾛｸﾞﾗﾐﾝｸﾞや
ｺﾐｭﾆｹｰｼｮﾝしつつの開発の現場に居る方ではないので
あのすばらしさが伝わるのだろうかしら。

XPの素晴らしい所は開発現場の生の声から生まれたものだから
と思っています。
他の理論は(ってそんなに氏らないんだけど例えばUMLとかさ。)
どうもSE的視点ばかりで机上の空論っぽくて
劇的に何かを変えてくれるというものを感じなかったんですが
XPは実行できれば素晴らしい世界が待っていると
感じさせてくれまする。

XPだと当然SEなんて役割のﾋﾄは居なくなりますね。
顧客とPGが密接になる事が重要で
間にSEが挟まるとよい結果を生まない。


XPで気になったのは
テストについての項目に"GUIのテストはできません"って
かかれてて、ちょっと萎え．．．
どうりで、Delphi自体のGUIにはバグがちょこちょこあるわけか。

>>62
うーん、Accessは「データベースの学習」以外に、Access独自の使い方の
勉強をしないといけないから、俺はあまりすすめたくないな。

MSDEだとどう？
こっちの方が良さそうな気がする（俺は使ったことないけど）

>>65
>テストについての項目に"GUIのテストはできません"って
>かかれてて、ちょっと萎え．．．

XPにおけるテスト/コーディングサイクル: 第一部　モデル
http://www.ki.rim.or.jp/~omura/XPlorations1/XPlorations1J.html

XPにおけるテスト/コーディングサイクル: 第二部　 GUI
http://www.ki.rim.or.jp/~omura/XPlorations2/XPlorations2J.html

は（特に第二部）読んだ？

結局は「何を」テストするかなんだよね。

>>64-65
　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 ∫
　　　　　　　　　　　　　　　　　　　　　　　　　　∧,,∧ ∬　　　　 　 ／￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　　　　　 ミ,,ﾟДﾟノ,っ━~　　＜　でも、えらそうにしてみるか。ﾌｻﾌｻ
　　　　　　　　　　　　　　　　　　　　　　　＿と~,,,　　~,,,ﾉ＿.　∀　　＼＿＿＿＿＿＿＿＿＿
　　　　　ｶﾁｶﾁｶﾁｯ　　 　,＿＿　　　　　 　　　 .ﾐ,,,/~),　　.|　┷┳━
　　（　　　∧_∧ｲｯﾃﾖｼ!! |_|＿_|　　　　￣￣￣ .し'J￣￣|....　　┃
　⊂ ´⌒つ ﾟДﾟ)つ≧　　/∫ ヽ　　　　 ￣￣￣￣￣￣￣ 　 　┻
￣￣￣￣￣￣￣￣~~~~~~~￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 ﾋﾞｼｭｼｭｼｭｼｭｼｭｼｭ!!!!
　　　　　　　　　　　　　　　　　　　　　　　　　　∧,,;；∴；　　　 ∴；
　　　　　　　　　　　　　　　　　　　　　　　　　 ミ,,ﾟД･*∴；　　∴
　　　　　　　　　　　　　　　ｽﾞﾊﾞﾝ!!!　　　　＿＜：ζ：,∴　~,,∴＿.　：,∴
　　　　　　　　　　　　　 　 , ﾉ从ゝ　　　　 　　　 .ﾐ,,ζ：;：,∴　.|　┷┳━ ⊂
　　（　　　∧_∧　　　　　 ||　　　Σ　　　　￣￣￣ .し'J￣￣|....　　┃
　⊂ ´⌒つ ﾟДﾟ)つ≧　　/∫Wヽ　　　　　　　￣￣￣￣￣￣￣ 　 ┻
￣￣￣￣￣￣￣￣~~~~~~~￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　ｵﾔｸｿｸ

>>67
しんいりさんにそれやらしとくと効果がありそだとｵﾓﾀ。

余談
何度見てもおいら的には
「ＸＰ＝教育用」
の頭がぬけﾅｰｲの。
だって「実戦でそれくらいふまえとかんで何がプログラマよ？」
っと思うところがあるから。(~-~;)

逆説的に考えて。
やらないかんことを新しい言葉で語ってくれてるから、
実戦配備されなくてイイレベルのヤツ見かけたら
　　　　　 　 ∫
　　　∧,,∧ ∬　　　　 　 ／￣￣￣￣￣￣￣￣￣
　　 ミ,,ﾟДﾟノ,っ━~　　＜　とりあえずXP理解してこいや
＿と~,,,　　~,,,ﾉ＿.　∀　　＼＿＿＿＿＿＿＿＿＿
　　　 .ﾐ,,,/~),　　.|　┷┳━
￣￣￣ .し'J￣￣|...　┃
￣￣￣￣￣￣￣ 　 .┻
っという突っ返しができそじゃのﾎｯﾎｯﾎっとほくそえみ。

　∧∧
　( -д-)
　| っ日~~　　ﾜｼﾉ ｵﾂﾑﾓ ｶﾀｸﾅｯﾃｷﾀﾉｫ
　と_）_）　　　　　　　ｯﾄ ↑ｶｲﾃﾃｼﾞｯｶﾝ ｼﾀﾉｫ

>>69
XPには教育的な面もあるけど、あくまでも実践が目的じゃないかな。
「教育用」なんて言い始めたら、ありとあらゆるものが、そう取れるでしょ？

>だって「実戦でそれくらいふまえとかんで何がプログラマよ？」

つっこみたいが、我慢する（笑

ペアプログラミングとか実践しているところあるの？
人員をそこに割り当てられるのがうやまらしい

http://objectclub.esm.co.jp/eXtremeProgramming/xp-faq.html

計画ゲーム(The Planning Game)
ビジネス優先度と技術的見積により次回リリースの範囲を早急に決める。現実が計画と変わったら、計画を更新する。

小規模リリース(Small Releases)
シンプルなシステムを早急に生産に投入する、それから新バージョンを非常に短いサイクルでリリースしていく。

比喩(Metaphor)
どの様に全体のシステムが機能するかを示すシンプルな喩え話(メタファー)をメンバーが共有することで全ての開発を導く（ガイドする）。

シンプルデザイン(Simple Design)
いつでもシステムは出来る限りシンプルに設計されるべきだ。余分な複雑さは見つけ次第取り除かれる。

テスティング(Testing)
プログラマは継続的にユニットテストを書く、それは開発を続けるために完全に動かなければならない。顧客は、機能の開発が終わったことを示す機能テストを書く。

リファクタリング(Refactoring)
２重コードを取り去り、コミュニケーションを改善し、単純化し、柔軟性を加えるために、プログラマは、システムの動作を換えることなくシステムを再構成する。

ペアプログラミング(Pair Programming)
全てのコードは２人のプログラマにより一台のマシンで書かれる。

共同所有権(Collective Ownership)
誰でも、どのコードでも、どこででも、いつでも、プログラマはコードを修正できる。

継続的インテグレーション(Continuous Integration)
システムを一日に何回もインテグレードしビルドし、テストを 100% パスさせる．

週40時間(40-Hour Week)
週４０時間以上仕事をしてはいけないのがルール。

オンサイト顧客(On-Site Customer)
現実のユーザをチームに加えて、フルタイムで質問に答えられるようにする。

コーディング標準(Coding Standards)
プログラマは、コーディング標準に従って全てのコードを書く。

>>69
> だって「実戦でそれくらいふまえとかんで何がプログラマよ？」
> っと思うところがあるから。(~-~;)
ぜひともシンプルデザインとリファクタリングの説明をよく読み、そして実践して
下さい。

前スレでの５年氏の対応を見ていると、そう突っ込みたくなったり。

> だって「実戦でそれくらいふまえとかんで何がプログラマよ？」

　　＿＿＿＿＿
　/.....　　　　..　.../
　||:::　　 ∧ ∧　　／￣￣￣￣￣￣￣￣￣￣
　|￣＼ (　ﾟДﾟ)＜　　XPのテストだけに関してはそういえるかもな。
　|　　 |:￣U U￣:|＼＿＿＿＿＿＿＿＿＿＿

　　　　　　　ﾊﾞﾀﾝ !!
　＿＿＿＿＿__ミ　 ∧＿∧　　／はいはい。
　|￣＼　　　　 ＼　（´∀｀　）＜　 自分のテストが出来るように
　|　　 |:￣￣￣￣:|⊂　　　 ）　＼　なってから言いなさい。
　|　　 |:　　　　　 .:| ｜ ｜　| 　
　|　　 |:　　　　　 .:|（＿（＿_） 閏年くらいテストしとけよ

　　 ＿＿＿＿＿_
　／:＼.＿＿＿＿＼ ／￣￣￣￣￣￣￣￣￣￣
　|:￣＼ (∩ﾟДﾟ)＼＜　XPはテストだけじゃねーぞ。
　|:　　 |:￣￣ U￣:|　＼＿＿＿＿＿＿＿＿＿＿

ところでDelギコ氏は、いつ働いてるの？

Delギコ、ヒッキー疑惑

>>75
以前、プログラム技術板の方で「近いうちに会社辞める」と書いてたような気がする。
よって、現在はプーの２ちゃんねらーじゃない？

　　　　∧ ∧　　／
　　　　（,,ﾟДﾟ）＜　　プーじゃないよ。
　　　　 |つ つ　 ＼
　　　＠　　 | 　
　　　　∪ ∪

来月末に会社辞めるの。
来月はずーーと有休消化。だから実質今月でｵﾜｰﾘ
ｵﾜｰﾘ前だから、糞忙しいProject横目に何もせず。
というか、趣味プログラミング全開.

休み中に転職活動でもするさ。

イマイチ転職活動する気が起こらないけど。しなくちゃね。

誰か雇ってﾁｮｰよ。
って、他力本願じゃダメだな。精進精進っと。

Delギコ氏がdelphiで飯食っていけるかどうか報告きぼん

>>62 >>66
Access見てみます。いずれにしても学校ではAccessですし。
（私が教えているのではありませんが。）

>>65 >>67 >>69 >>70 >>71
それでは、いよいよXP編突入ということですね。
71さん、明確なまとめ、ありがとうございます。XPをまだ知らない方は、とりあ
えず、これを読んで．．．でいいですよね。>みなさま

>すばらしーと感じたんだけど新人氏はﾍﾟｱﾌﾟﾛｸﾞﾗﾐﾝｸﾞや
>ｺﾐｭﾆｹｰｼｮﾝしつつの開発の現場に居る方ではないので
>あのすばらしさが伝わるのだろうかしら。
現場にいないということは確かなのですが、それゆえ、勘違いかもしれませんが、
XPにはとても感動しました。

>>78
78さんはDelギコさん？びっくりしました。
でも、とても優秀ですから、ステップアップというやつですよね。

えーと、それでは、XPで聞かせてください。

まず、おそらくXPの実践の中心であると思われるペアプログラミングですが、実はこれが
かなり難しいのではないでしょうか？私が想像する困難は以下のようなものです。

１．PG自身がやりたがらない。「一人が好きなのに、なんであんな奴と．．．」
　　などと言う。
２．管理者がやりたがらない。「効率が半減する」などと言う。
　　（ちなみに、私はそうは思いません。プログラムを知らない管理者の話です。）
３．XPでペアなど決定的なところだけ除いて実行しようとする。
　　「実行可能なところから取り入れて．．．」などと言う。
４．PGか管理者が、ペアをOJT（このスレで学んだ言葉です）などと思う。
５．誰かが給料の分配の話をする。

「やっぱりXPはすばらしい」という結論になってほしいのですが、困難も多いよう
に想像してしまうのです。

XPと聞いても、うちに会社には某OSのバージョンのことだと思う人間しかいない。
ほんとにこのスレの人はレベルが高い。

俺もXPは実践用だと思うなァ。でもある程度周りの意識が高くないと面倒くさがって
やってくれないと思う。あと、学生にはあまりメリットが理解できないと思う。
あまり多人数での開発経験して無いだろうから。

でも40Hour/Weekってのが、どう考えても無理っぽい・・・

>81
>３．XPでペアなど決定的なところだけ除いて実行しようとする。
> 　　「実行可能なところから取り入れて．．．」などと言う。

別に、実行可能なところから取り入れるのは XP として間違ってないよ。

XP エクストリーム・プログラミング実行計画
ttp://www.amazon.co.jp/exec/obidos/ASIN/4894713411/xpjp-22/249-6195836-7066758
第 27 章
> XP の計画をあなたの状況に適応させる 1 つの方法は、
>あなたが有効だと思う XP の断片を少しずつ、
>現在のプロセスに取り入れることである。

うーん、俺のチームもペアプログラミングは出来てない。

原因は、チームリーダーの俺にある。
一人でプログラミングしたほうが、最も効率よくプログラミングできるし、
ヘッドホンで音楽聴きながらプログラミングしてるから、ペアプロは
やりたくない。だから、提案しない（藁

うちが実践してる、あるいは、めざしてるのは、以下の項目。

> 計画ゲーム(The Planning Game)
> 小規模リリース(Small Releases)
> シンプルデザイン(Simple Design)
> テスティング(Testing)
> リファクタリング(Refactoring)
> 共同所有権(Collective Ownership)
> 継続的インテグレーション(Continuous Integration)
> 週40時間(40-Hour Week)
> コーディング標準(Coding Standards)

共同所有権は、こまめにレビューしてペアプロ出来ない分をカバーしてる。
UnitTestは、ほぼ完璧に出来てるから、修正・テストは誰でもやる。

俺が最も力を入れてるのが、週40時間労働。
チーム全員が、とはいかないけど、なかなかいい線行ってるよ。
俺自身は管理職じゃないので残業はつくけど、なるべく残業しないようにしてる。
７，８月は、残業0だったよ。某スレでも言ったけど、年間100時間くらいしか
残業しない。
まー、家で勉強したり、調べものしたりするから、イカサマなんだけど、
「リーダーが帰らないので帰りづらい」
という状況が一番いやだったので、今は無理して帰ってます（藁

↑96か

>>82
私もXPはWinの名前だと思ってました。このスレのみなさまに感謝です。
>>83
「周りの意識」というのが大きな要素ですよね。
「学生にメリットはわからない」はその通りだと思います。ただ、学生は、
ときどき誰かがキーボードを打ち、後ろから何人かがのぞきこんで、
「そんなんでいいんかー」などとわいわいやっています。もちろん、プロの
お仕事と学生のレポート書きを一緒にするつもりはありません。ただ、XPに
はたぶんに心理学的要素を感じます。もとは、ああいうノリなのでは、とも
思うのですが．．．。甘いでしょうかね。
>>84
>別に、実行可能なところから取り入れるのは XP として間違ってないよ。
なるほど。始祖のお言葉ですね。
「実行可能」の度合いと、組織の向いている方向によっては、「実行可能な
ところを取り入れました」が「見かけだけとりつくろいました」になる可能性
もあるのでは、と思ったのです。すみません。
>>85
貴重な例をありがとうございます。「実例」であるだけにとても興味があります。
「ペアプログラミングのみ無し」というのは、ある意味では妥当かなとも思って
いたのですが、「コードの集団所有」が心配でした。しかし、これは「こまめに
レビューしてペアプロ出来ない分をカバー」なのですね。さすがだと思いました。
（「なるべく残業しない」というのも、すばらしいリーダシップだと思います。）
いろいろお話していただければ、他のみなさんにも大いに参考になるのではない
でしょうか。お願いします。

また悪い癖で、長くなってきましたね。m(__)m

他のスレなどを見ていて思ったのは、「ペアは無理」という意見と「ペアをやっ
てみたい」という意見の両方が散見されるということです。Error401さんのよう
な方式は（実践は知らないので、重みはまったくありませんが）私にはとても
よい案のように思えます。しかし、ペアプログラミングができればそれはそれで
すばらしいとも思います。
このスレのみなさまはどうお考えなのでしょう。また、すでにペアをやられている
方はいらっしゃるのでしょうか。

うちの会社（といっても社員２０名）では
必ず、男女をペアにして夜飲みに行かせて
デキちゃうようにしむけてます。
効果抜群です。いっとくけどまじの話です。

>>89
厨房？

>XPと聞いても、うちに会社には某OSのバージョンのことだと思う人間しかいない。
>ほんとにこのスレの人はレベルが高い。
でも、XPに関しては日本語訳の本がいくつか出回っているし…
理解しているのが普通じゃない？
とは言っても、家の会社は…（ｗ

でもやっぱり、「ペアプロ」と「オンサイト顧客」はXPの真髄のような気がする。
「共同所有権」も、ペアプロをやって初めて実現できるものだと思うし。

あ、知らない人の為に説明しておくと、「共同所有権」は、「ペア」でコードを
共有するのではなくて、チーム全体で共有することだからね。ペアも変われば、
コーディング対象のソースも変えて共有する。
Aさんが作ったベースクラスに変更を加えたいと思ったら、その人が変更・テスト・
リリースするといった具合。

今、お互いにレビューしあったり、UnitTestのassertion（表明）を見て、その
コードを理解するということをやってるけど、余分なコミュニケーションや待ち
時間が発生してしまうんだよね。
共同所有というより、「誰もが変更の権利を持っている状況」なのかな。

UnitTestの品質も、今のところは個々人のスキルと、レビューに頼ってる状態。
レビューやったことある人ならわかると思うけど、詳細なチェックは疲れるん
だよね。レビュワーのスキルも要求されるし。

ペアプロを取り入れれば、レビューというプロセスを大幅に簡略化出来ると
思うんだけど、ドラスチックなプロセスの変更は、体力がいるし、何より俺が
やりたくない（藁

まー、ワタクシごときが取り留めの無いことをダラダラ話すより、
http://objectclub.esm.co.jp/eXtremeProgramming/XpPracticeReport.html
とかを見るといいかも＞新人氏

「僕の私のペアプロ日記」みたいなページどっかにないかな？（藁

>>91
ウチの会社はＸＰと聞けば間違いなくOfficeですなぁ。

　∧ ∧　 　／ とりあえず、GUIに対しても
　(,,ﾟДﾟ)　＜　　テストが大切だという事は
　 |つ つ　　＼ 身をもって知った　　2001年ｾﾌﾟﾃﾝﾊﾞｰ
＠|　　|
　 ∪∪ >>67ｱﾘｶﾞﾄｳ401氏

最初はXPでかかれているような
単純なGUIじゃないから無理かと思ったのだが

XPでは"複雑でテストできない"というのはウソってのを
考えて、ねっちりテストしてみたら
見た目のテストだけにしてもかなり書く事が出来ました。

そんでもって
バグがみつかりまくったよ。

品質の高いコードを書くにはテストをまず書く。
これ重要ですね。

>でもやっぱり、「ペアプロ」と「オンサイト顧客」はXPの真髄のような気がする。

XPの真髄はフィードバックのスピードにあると思います。

「ペアプロ」ならコーディングをしているその時点でコードを
レビューできる。
「オンサイト顧客」なら疑問点をすぐに顧客に問いただすことが
できる。
「ユニットテスト」なら作成したコードのバグをコーディングする
端から見つけることができる。
「継続的インテグレーション」なら結合による問題をすぐに見つける
ことができる。
「小規模リリース」なら完成品に対するエンドユーザの不満、要望を
リリースのたびに受け取ることができる。

自分のアクションの結果をすぐに受けることができるのがXPの利点
だと思います。

そうそう、ペアプロには「サボれない」という利点(欠点？)も
ありそうです。

.＿＿＿＿＿＿＿＿＿＿＿＿＿
|　　　　　　　　　　　　　　　　　　 .|
|　　GUIはテストの宝庫です。　｜
|＿＿＿＿＿＿＿＿＿＿＿＿＿|
　　 ∧,,∧　||
⊂ミ.,,ﾟДﾟ彡つ 　OSﾄ ﾀﾀｶｯﾃﾙﾖｳﾅ ｷﾆﾅﾚﾙ

っとそのむかし「試験工程」っちゅう過程で思った。

たとえば画面上に作られた１つのボタンに対して。
　・クリック
　・ダブルクリック
　・トリプルクリック
　・フォーカスの遷移の有無
　・カーソル合わせてスペースキー押下
　・カーソル合わせてEnterキー押下
　・カーソル合わせてスペースキーとEnterキーを交互に連打

複数のボタンになると
　・できる限り短時間のうちに押せるだけおす

ってのが加わる。
マウスでなくてスペースキーとTABきーにEnterキーとか駆使すると
コンマ１秒のあいだに３つ分くらいは楽にいける。

普通に使う分ならﾏﾀｰﾘと動作しているもんでも、
そんなことするとﾊﾟﾆｯｸに陥ることがほんまにある。

極めつけになると、
ボタンを押し、その処理が終わりきる前に「Alt＋F4」。
これでメモリリークされてるかどーかとか見たりした。

テストって被虐的楽しみを見出せる過程かもしれないと感じた瞬間でした。

>>96
もしかして、手作業でテストしていたの？　それだと逆に再現性がなくなるから
やめた方が良いと思う。

リファクタリング直後にテストして「以前と変化ないから OK」と言えなくなって
しまうもの。

>>97
昔のWinAPI環境でのテストではないのかな？

ＧＵＩのボタンなどの挙動について手作業以外でどうやって行うのか
ちょっと知りたいっす。

ペアプログラミング。
思い起こしてみたらバグ対処の時にちらっとやってるかも。
（これをそういうのか？↑はちょっとおいといて。）

しもべ作のコードをおいらが追うという状況で。

バグを追いきれないしもべを隣において、
バグの現象とそれにいたる過程を聞きながら、
ソースをおっかけていく。
おっかけるときも「何がどうでこうだからこうしてみる」など
いちいち言いながら試してくとそのうちつぶれる。

　しもべ：「ｗ（ﾟｏﾟ)ｗｵｵ!!」っと思う。
　　↓
　わしの株あがる
　　↓
　(ﾟдﾟ)ｳﾏｰ

いやいやそうでなく。
しもべ自身も次回なんぞ追っかけるときの参考になってるハズ。
そう信じたい。

このときに思ったポイント。
　・ソースを追っかけるときのツールの使い方
　・筋道の立て方と確かめる対処方法
　・試験用コードをおしげもなくいれる姿勢
そんなところを実際に見せるという点が、言葉で語ると長いだけで
耳に入るも右から左になりそうなことを教えれる状況だと感じた。

生産力（高）と生産力（低）の組み合わせだと、（低）の「成長促進」に有効と思われた。
ってのもペアプログラミングの有効性ってのになるのかな。（まだ用語に馴染めず

　　　　>>98
　　　　　そのとーり。（昔のってのが気になるが）

　　　　>>97
　　　　　98と同じ質問したいぞ。

　　 ￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧
　( ﾟДﾟ)
　| っ日~~　　ｻｲｹﾞﾝｾｲﾉﾅｲ ﾊﾞｸﾞ ｯﾃﾉﾓ ｱﾙﾃﾞ-
　と_）_）　　　　　ｯﾁｭﾉﾊ ﾏﾀ ｾﾞﾝｾﾞﾝ ﾍﾞﾂﾉﾊﾅｼ ﾆﾅﾙﾅ。sage。　　　　　

ｷﾘﾊﾞﾝ　とってたー
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（・д･⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

>>101失敗？

>>89 少子化対策には貢献していそうですね。^^)

>>92
ペアプロの重要性は認める．．．けど、やりたくはない．．．というところで
しょうか。うーん、なるほど。
HP見させていただきます。ありがとうございます。

>>94
私もGUIはどうするのだろうと思っていました。件のHP、私も見てみます。
>品質の高いコードを書くにはテストをまず書く。
>これ重要ですね。
なるほど。「テスト」は、なんだかうまく導入できそうな、気がしますね。
（って、私は素人ですが。）

>>95
>XPの真髄はフィードバックのスピードにあると思います。
これも、なるほどです。。シンプルにして有用なコメントありがとうございます。
「ペアプロはさぼれないから、週40時間で限界」というレスが前にありましたね。

>>97
「手作業をやめる」には、代替物が必要ですよね。たとえばどういう方法を使わ
れるでしょうか。とても興味があります。

>>99
「なじみのない仕事の責任者になったら、経験者にペアになってもらう」とあり
ますね。
ただ、実力的には、あまり差がないことが条件ではないでしょうか？
（これもペアの難しさの一つのような気がするのですが。間違いならご指摘を。）

GUIのテストなんですけど、まだ、HPとか見ていないのですが、たとえば、タイマー
でメッセージを出しまくるようなコード（SendMessageなどで）などはどうでしょうか。
やったことはないのですが、確か、他のプロセスやウインドウを捕まえてメッセー
ジを送ることも難しくはないですよね。

ただ、それでも、表示とかの確認を目でしないとだめなら、テストコードそのもの
がかなり面倒ですよね。タイミングを見ないといけないので。
表示もログを取るようにすると、ログと表示が本当に一致していたのか悩みそうです。
それにタイマーもWindowsだとあやしいのですよね。
うー。どうでしょうか。

目で確認することは、どうかと思うが

>>104の自己レス
あんまり日に何度も書かないようにしているのですが、気になったもので。

>>67の引用ページ読んでみました。すみません。ちゃんと書いてありますね。
Delギコさんも読まれたのですね。

>fieldとボタンはgetText()やsetText()、doClick()などによってシミュレートできる。
C/C++（Delphiも？）では「メッセージ送り」でもよいと思いますが、テストコードで
OnClickなんかを呼び出して、結果（表示など）をassert系の関数でチェック
する．．．ということですよね。

Error401さん、ありがとうございます。
今見ると、104はまだまだKISS的に考えが足りない感じがします。
（KISS＝Keep it simple, stupid!　「ややこしくすんな、このアホウ」？）

>>105
アニメーションの表示とか、GUIのテストは目でしないと．．．と思ったのですが。
>>67の引用ページでは、assertでチェックしまくりですね。「テストは自動」も実際
的には重要なので、やはり、基本的には、「目で確認」はだめそうですね。
ご指摘ありがとうございます。

えーと。2、3日、留守にします。m(__)m

>>107
>>>67の引用ページでは、assertでチェックしまくりですね。「テストは自動」も実際
>的には重要なので、やはり、基本的には、「目で確認」はだめそうですね。

そうですね。出来るだけ「目で確認」しなければならないテストを排除します。
前スレでも言ったけど、その為にコードの構造を変更することもいといません。

誰でもが、何の前準備も無く、繰り返しテストできるテストスィートが理想です。

「目で確認」のテストが数多くあると、ついついテストを怠るようになってしまい、
いつのまにか、デグレードしていた、ということもありえます。

age

Keep it stupid! は
(今必要でない)賢い仕組みは使うな、ってことでしょう。

上司がＸＰ導入を検討しています。上司のいうところによると
「ＸＰだとＤＢとか画面の設計が入らなくて楽だ」ということでした。
ただこちらのお話を読ませて頂いているとなんとなく違う様ですね。
私もまだまだよく分らないのでこちらで勉強したいとおもいます。

>>111
その上司をリファクタリングしてください

イターイです、存在が
ＵＲＬ
http://kaba.2ch.net/test/read.cgi?bbs=net&key=1001261547&ls=50

ＸＰって逆に工数とかかかるんじゃないの？

今まで：基本的に前工程へ逆戻りすることが無いから、早いうちに必要な機能などを決める必要がある。
　　　　途中で機能の変更があった場合とかに対応しづらい。

XP：まずプロトタイプを作る⇒フィードバックを元に必要な機能を追加、変更できる。
　　それを繰り返すから「作ってみたらなんか機能不全だった」ということが無い。

こんな感じでしょうか？

ただ繰り返しの回数とか開発期間はちゃんと決めとかないとヤバいことになりそうですけど.....。

>>114
>ＸＰって逆に工数とかかかるんじゃないの？

確実に言えるのは、保守費用が大幅に削減される、ということです。
いわゆる「デグレード」がほとんど無くなりますから。

個人的な感想で言えば、製造工程でも、大幅に工数は削減されます。

>>115
>XP：まずプロトタイプを作る⇒フィードバックを元に必要な機能を追加、変更できる。
>　　それを繰り返すから「作ってみたらなんか機能不全だった」ということが無い。

XPはプロトタイピング手法とはちょっと違います。
従来のプロトタイピング手法で「プロトタイプを提示」するところで、
「実際のアプリケーションを提示」するんです。
どの時点を取ってみても、その段階で完結しているアプリケーションを
段階的に実装していく、といったイメージですね。

もちろん、プロトタイプが有効な場合もあり、その場合は使いますけどね。

>>116
おそらく全てがスケジュール通りに進む仕様変更なしのプロジェクトなら
既存のウォーターフロートモデル（或いはスパイラルモデル）の適用が
いいのでは…と思えますが。

ただ、現実には仕様変更はザラ。
そういった場合でもスケジュール的には不可逆的なものはなしとして、
ムリクリスケジュールを進行させてしまう・・・

>>116
あっ。
XPは従来のスパイラルモデルとは違いますよ。
「繰り返し回数」という概念はありません。

けっ、仕様変更があっても納期はかわらない。
こんな状態じゃ何を使っても無理

>>120
ウォーターフロートでの仕様変更は本当に悲惨です。
プロセスの後戻りにはまるで耐えられない

s/ウォーターフロート/ウォーターフォール/g

これが日本の学術的情報処理産業の現状か…

　　　∧ ∧　　．・°
　 　（ ﾟДﾟ）--」 　　　　　　　　　　　　　　　_-~
　　＜　　つ 　　　　　　　　　　　　　　　　日　　　　ﾎﾞｵｰｰ
　 〜） ）―Ｕ 　　　　　　　　　＿＿＿□□□＿＿
　 　∪　　ＴＴ　　　　　　　　　＼＝＝＝◎＝＝／
￣￣￣￣￣￣￣|　^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

http://www.catena.co.jp/topics/2001/20010917.htm
http://www.lyee.co.jp/webapp/jp/kozo/index.htm
http://www.catena.co.jp/lyee/index.htm

ショックだわー、この国滅びるんじゃない？
2chのネタどころじゃないね。

Σ級・ネオ麦茶級だーね。

これが、プロの現状だyo!

http://mentai.2ch.net/test/read.cgi?bbs=prog&key=1000494408&st=52

帰ってまいりました。
ようやくXPの3冊目（ピンク本）を手に入れ、狂喜しています。
（ついでにAccessを勉強しようとして、OfficeXPもインストールして、その登録
方法にちょっと鬱です。でも、コピー防止には、これが正常なんですよね。）

スレの方は、また書きにくい話題にしてしまったのかと、深く反省していました。

>>108
>「目で確認」のテストが数多くあると、ついついテストを怠るようになってしまい、
リアルなお話ありがとうございます。テストのためには、「表示と他の処理を分離」
がよいということでしたよね。（ちょっと古い地雷を掘り出すような話題ですが。）
>>110
な、なるほど。^^;)
>>111
うーむ。その上司さんは、（112さんの言うように？）勘違いかもしれませんね。
>>114
ナイスな質問だと思います。（素人の私は工数の定義もよくわからないのですが。）
>>117
なるほど、なるほどです。
>>119
そのようですね。ただ、「外に出さない小リリース」などは、スパイラルに似てい
るとも言えるのではないでしょうか。この辺を、ちゃんと説明して「XPったって、
どうってことないんだろ」という人を説得したいですね。
>>123
なんか、こわい感じがしました。^^;)

みなさん、どういう方向に話が進むとよいと思いますでしょうか？
テーマを決めて激討論する．．．とか、マターリ雑談するとか。
激討論希望の方は、ぜひ、問題提起を。m(__)m

>>123
　＞ショックだわー、この国滅びるんじゃない？
説明が利点一辺倒とか
肝心要の経路図の説明はどこよとか
でないところでショックをうけてる！？
んであればその理由に興味あり。

内容に関してならおっちゃんは
ハードの処理能力にべったり依存して、
「開発工程をけずる」っという命題だけはクリアしてる例だとおもた。
（エンドユーザコンピューティングってぇのの現在形ってな感もしなくもない）

できあがったものの体感速度はどぅよ？ってのはわからんけど。

余談：
「KnowledgeServer」ってナレッジマネジメント業務支援システムが
世の中にはあんねんけど、それと目的がにてるな〜ってんで
Lyeeを調べてみよかと現在行動中。

>>127は>>126の方向とはまた別のひどく個人的興味なので新人さんｺﾞﾒ-ﾝﾈ.

>>127
Lyee は変数名に全てをたくす。

「売上」に意味を持たすのはともかく「１月の売上」とかどうすんだろうなぁ。

あと、せめて名前空間の概念ぐらいはあっても…。

>>123
「政府がソフトウェア産業を免許製に、Lyee 導入を義務付け」とかだと笑えないが、
この程度の陣容では、話題にもならずに終わるに一票。

しかし、こんなネタをどこから拾ってきたんだ…

　　∧ ∧　　／
　　（ ﾟДﾟ）＜　>>130　すらっしゅどっとだよ。
　　 |つ つ　 ＼ http://slashdot.jp/search.pl?topic=programming
　〜|　　|
　　∪ ∪
　　∧ ∧　　／
　　（ ﾟДﾟ）＜　>>127
　　 |つ つ　 ＼ プログラミングは会議室で起きているんじゃない。
　〜|　　| 　　　　現場で起きているんだ！
　　∪ ∪
　　と思ったからよん。(伝わる??)
　　折れらも頭で考えているには違いないんだけど
　　この人たちは机上だけで考えているってことがヒシヒシと伝わってきたのー。
　
　　調べたらVBでLyeeというﾔﾂもありますね。ちょっとみてみるか。(時間の無駄にならなきゃいいが)

http://www.catena.co.jp/topics/2001/20010917.htm
のアドバイザリボードコメントという所見ると
この人の言っていることは大変すばらしいのだけど

　一般の人間にまで浸透させたいみたいだけど
　現場の開発者にとっても非常に意味不明なLyeeを
　どうやって広めさせられるんだろう。

　∧ ∧　　　 ／￣￣￣￣￣￣￣￣￣
　(,,ﾟДﾟ)　　＜　　この記事はどう思います？
　 | つ[|lllll］). ＼＿＿＿＿＿＿＿＿＿
〜| 　 |
　 ∪∪
http://www.atmarkit.co.jp/fjava/opinion/ul/ul03.html
微妙にXPを取り入れているようなんですが....

>>132

http://www.atmarkit.co.jp/fjava/opinion/ul/ul03.html
<blockquote>
仕様書がきちんと要求分析のインプットになり、要求分析のアウトプットが
設計のインプットになり、さらに設計のアウトプットが確実にJavaの
プログラムコードにマッピングされるという一連の流れ
</blockquote>

ってとこは、もろウォーターフォールの考え方だよね。
これに、スパイラル方式を加味しただけで、特に目新しい気はしなかった。

「コーディングする前に良く考えろ」

っていう、ごく普通の考えなんじゃない？
筆者は、「遮二無二コーディングする奴」に痛い目にあったのかな（藁

一部のIDEやRoseではラウンドトリップ方式を採用してるよね。
Roseのは使いづらいけど。
クラス図とコーディングを言ったり来たりするのも悪くないと思うよ。

>>128
いえいえ、とんでもありません。成り行きを見守らせていただきます。
ちょっと興味があるのですが、Lyeeのページでは「閉塞状況にあるソフト世界」とい
う言葉がキーワードの一つのようです。みなさんもそう感じておられるのでしょうか？

実は、私のもといた畑を、外部の人がよく「閉塞状況」と評していました。内部に
いたときはほとんどそう感じなかったのですが、別世界（情報の世界）に来ると、
確かにもとの畑は「閉塞的」だったような気もします。
ごちゃごちゃ書きましたが、つまり、私にとっての新天地（＝ソフト開発）もまた
「閉塞」と感じている人が多いのでしょうか、ということです。
（ちなみに、私個人は、とても張り切っています。学校やめたいくらいに。）

>>132 >>133
確かに「微妙にXPを」という感じがしますね。ただ、どちらかというと、マイナー
に参考にしている．．．という気がします。

Lyeeあり、ウルシステムあり、ですが、私もちょぼちょぼ質問させてくださいね。
それぞれが好きなことを聞いたり答えたり、ということで。
別に仕切りたいのではないのですが、1としては、何かしないといけないような。
そうでもないのでしょうけど。
（本当は「新人」を名乗るのがなんかこわいです。コテハンの方は偉いですね。）

135=新人です。すみません。

XPの本質とは．．．というのは荷が重いので、周辺からちょぼちょぼと、質問させ
てください。m(__)m

まず、私の理解では、XPのいろいろ（>>71参照）は、実はかなり密接に結びついて
いて、どれかだけを取り出すということは、難しいのではと思います。しかし、
（84さんもご指摘ですが、）全部できなければ、部分的にやっていくしかないです
し、それでもよいようです。（始祖のお言葉です。私自身は、まだ懐疑的なのでが。）

ということで、XPの部分実践の話を、パラパラと聞いてみたいです。
まず、Error401さんの85が、もう、一つの答えのように見えますが、それはそれと
して、プロから見ると「新人って、やっぱりパーだな」という話にもおつきあいくだされ
ば幸いです。

で、また、ペアプロです。
たとえば、あるソフト会社で、2人のプログラマが、勝手にペアを組んで、2人に与
えられた仕事をペアプロではじめたとします。（担当部分はたまたま近かったとし
ます。）たぶん、慣れるまで相当効率が悪いと思いが、さて、ペアプロに慣れた後は、
別々にやるより効率がよいと思われますか？（つまり、XPという「全体的な環境」が
ない場合に、ペアプロだけ取り出して実践できるでしょうか、という質問ですね。）

知らない人のために一応書くと、ペアプロは、1人がキーボードを持ち、もう1人が
後ろにいて、「助言」するようなやり方のようです。

私はプログラミングにかかる時間（エラー直しまで含め）は、エラーが減るため、
2倍にはならないと思うのですが、しかし、別々にやった場合と同じ効率になるのも
大変な気がします。それとも、もっと効率がよくなるでしょうか。

コードの安定性などで、上司に「ペアプロでやった方がよかったでしょ」と言える
ような成果を出せるでしょうか。もし、できれば、やってもよいわけですよね。
くだらない質問かもしれませんが、いかがでしょう。

http://www.f2.dion.ne.jp/~impact14/

>>136
試して結果を知りたくてもなかなか実践できないんだよね>ペアプロ

よくXPの欠点と言われる「スキル」の問題に触れる部分が
あると思われる。
質問では、あくまで一般論だけど、俺の主観的な感覚では
合う人と合わない人もいるだろうし、
出来る人、出来ない人でもかなり辛いものがあるように思われる。

つまりペアプロ==(常に)ブラボーでは、なさげな感じ。
実際にやった人の意見キボン。

＞慣れるまで相当効率が悪いと思いが

　∧ ∧　 　／
　(,,ﾟДﾟ)　＜　そーでもない。　と思われまする
　 |つ つ　　＼
＠|　　| 　ﾂﾈﾆ ｼﾞｯｾﾝﾊ ﾃﾞｷﾃﾅｲｹﾄﾞ ﾁｮﾄﾀﾞｹ ﾔｯﾀｺﾄｱﾘ
　 ∪∪
ある程度わかっている人間同士なら瞬間的に理解しあえますし
(ネット上ですら同じ問題に対峙するときは理解できるわけだから・)

技術レベルに差のあるもの同士でも
上の人が引っ張るときは下の人が目の前で問題解決していく
さまを見れますのですごく学習できます
(この仕事は常に学習ですからそれは仕事の一部)

逆に下の人がコード書くときも
指導員がそばについていると生産効率はそれほど落ちません。

　　　 　 　 ∧ ∧ 　／￣￣￣￣￣￣￣￣￣￣￣￣
〜′ ￣￣( ﾟДﾟ)＜　 レッツトライ
　 UU￣￣ U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿

>>138さん
>よくXPの欠点と言われる「スキル」の問題に触れる部分があると思われる。
利点では？
スキルのベクトルが違う場合も相互補完できます。
多分、折れとペア組むとDelphiやWin系のプロジェクトなら
ﾏｯﾀｸ問題ないでしょうし(本とかよ(ｗ)
逆に制御系とかなら折れはペアプロしてもらうと、楽だし。

直属の上司とはペアプロは嫌です。
業務としてやれといわれりゃやりますが･･･

まあ、その上司に変な仕様書押し付けられたり
変な納期設定されるよりかは、ペアプロの方がマシかな。

とりあえず「百聞は一見にしかず」です。
100回ガイシュツするより...やれる人とやって体感する方がよい
と思うﾃﾞｽ。

>>138
素早いレスありがとうございます。
私も「実際にやった人の意見キボン」です。ぜひ。^^)

しかし、一方で、「やったことのない人がどう思うか」も知りたいのです。
世の中は、「実績」より、「見込み」の方が勢いになることもあるようで、これも
とても重要だと思います。

まず、（XPに合わせて考えると、）「プログラミング時間」は「仕様書を受け取
ってから単体テスト完了までの時間」ですよね。（そもそも「仕様書がない（？）」
「変更がありすぎ」が問題であったわけですが、これは大丈夫として、です。^^;）

普通のやり方で、この「プログラミング時間」のだいたい何割を、（PG的意味での）
「内部設計」、コーディング、デバッグにかけているのでしょうか。
ペアを組んだ場合、「内部設計」（<-用語が間違っていたらすみません）が良いも
のになり、初期の論理的バグとコーディング時の勘違いが減り、デバッグも多少は
楽になりそうです。
一方、コーディングそのものでは、時間が2倍くらいかかるのは、しかたがないよう
な気がします。

これらをハカリにかけて、ペアをするかどうかではないでしょうか。
それとも、やはり、好みの問題が大きいでしょうか。

偉そうならすみません。大間違いなら、メタクソに言ってください。

ぐじょぐじょ聞いているのは、XPを部分的に少しずつ導入していく場合、ペアプロを
最初にすべきか最後にすべき（あるいはやらない）かを、知りたいからです。

と、書いたところで、Delギコさんのレスを受信しました。これは、また、ゆっくり読ま
せていただきます。

　　　　　 ∧∧　　／￣￣￣￣￣￣￣￣￣￣￣
　＠' ― (,,ﾟДﾟ) ＜　そんで、気になるお時間の方は
　 　し― し-Ｊ　 　＼＿＿＿＿＿＿＿＿＿＿＿
　　ｺﾝﾅﾝﾃﾞﾏｼﾀ(ﾃﾞﾃﾅｲｹﾄﾞ)

単純に数値としては短期間すぎるので自分の体験では完全には出ないですが
一人1時間ずつ計2人時間(?)という単位ですと1.5人時間強くらいには
なるような気がします

実際に二人ともJavaを知らないときに二人でガンガンに仕事をしたことがあったのですが
その際は共に学べる事が山ほどだったので(Java未経験だったから)大変効率がよかったです。

1週間(というか平日5日)でギリギリでむちゃくちゃの納期だったのですが
土日出社せずに出来ました。

二人別々にやっていたら多分できてないです。休出です。

>コードの安定性などで、上司に「ペアプロでやった方がよかったでしょ」と言える
>ような成果を出せるでしょうか。
その時は出来ましたよ。

ただ、XPの理想は二人ではなくグループでのペアプロだとは思います。

あと、完全にペアという形式にこだわっているようですが
30分間は別々にコード書いてまた一台に寄ってペアしてデバッグして
また1時間は別々になって･･･って形式でも
コミュニケーションが密に取れるのならペアプログラミングと呼べると思います。

あと、XP的なテストマンセーにならない状態であったとしても
時間で推し量れない質の高いものは出来ているという安心感はあります。
純粋なバグも設計ミスというバグも減るはずです。

>>139 Delギコさん

俺が、体重100KOverの汗かき、脇臭でもOKですか?
あと、モレは新人で2重loopすら理解できません。
大丈夫ですか?
(注)極端な例です。

こういうヤツ相手だと、俺には無理っぽいです。
そういう意味でどうしても躊躇してしまうんですよね。
どうしても人間臭さがでてきてしまって、受け入れたくても
生理的にダメな場合はどうすれば良いのか。
私以外のペアプロにも当てはまる問題なのです。

経験者の意見キボン。

>>142
あ、貴重な経験者の意見でしたか。

でも、やはり「スキル」に恵まれてるように
読めたのですが。
ビューティーペア(ふっるーっ)なら、素晴らしい結果を
出せそうなのは、予測できるわけですが。

＞大間違いなら、メタクソに言ってください。
　∧ ∧ ──────
　(ﾟДﾟ　) ＜ メタクソー
　⊂⊂　＼──────
　　　 ＼　　〜　────
　　　　 し し　─────

＿＿＿_∧ ∧＿ ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＿＿＿（　ﾟДﾟ）＜　うそだよー
＿＿ ／ ⊃ つ　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿〜′ ／
＿ ∪ ∪

>>138さんも新人さんも
XPの全てを一気に実践しなければいけないって思いすぎなのでは？

例えば「はじめにテストありき」の思想(なんかかっこよく命名して欲しい)では
確実に一人でも実践できます。

★折れなんか、それだけやっていてXPマンセーって逝ってます。★

また、具体例をageます。例えば以下のURLでやったことなのですが
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=999491550&rm=100
Delなので読めないと思うのでスイマセンですが

Delphiには昔からStrToIntという文字列から数値へ変換する関数があるのです。
そんで、変換不可能な文字列が与えられた時は例外が発生するのですが
例外が発生するといろいろ嫌だったので
StrToIntで例外が発生するかどうかを調べるCanStrToInt関数を
かいていきました。
(例えばこの関数。『$FF』という表現も受け付けるし『+000』という表現もOKですが
『+-123』や『-』という文字はだめ)
このStrToIntのライブラリ実装がマシンゴっぽかったのでソースも読めなかったので
自分で解析するためにテストコードを山ほど書きました。

CheckFunctionなどとかかれている所が軽く100行以上ありますがそれです。

例えばこんな感じ。
CheckFunction(True, '0000123');
CheckFunction(True, '+0000123');
CheckFunction(True, '+0');
CheckFunction(False, '-');
CheckFunction(False, '+-+');
CheckFunction(False, '+-50');
CheckFunction(False, '0+1');

このCheckFunctionでは与えられたTrue/Falseの真偽値と
与えられた文字列とで比較して
自作のCanStrToInt(文字列)という関数と真偽値を比較して
間違っていたらメッセージでお知らせするというコードです。

このCheckFunctionがあったから
非常に質の高い関数を作ることができました。

>>145
逆です(w
最後に残ったのがペアプロなんです。
別に四角四面にXPをやろうなんて、はなから思ってません。

ペアプロだけは、どうしてもメンバーの相性などを
考えないといけないので、悩ましいところなのです。

　　∧∧ 　　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　(,,ﾟДﾟ)　　＜ もっといい例がありました。
　ヽ/つ且~~　　＼＿＿＿＿＿＿＿＿＿＿＿
　 （__　_）
　　ﾃｽﾄ ﾉ ﾊﾅｼ ﾆﾅｯﾃｺﾞﾒﾝ
　　ﾂｲﾃﾞﾆ ｶｲﾜﾊ キャッチボール ｦ ﾓ ﾑｼｼﾃ ｺﾞﾒﾝ


2chブラウザオプソのmonazilla.org(wより

読みやすいように一部日本語化してみました

以下ソース
////////////////////////////////////////////////////////////
　　手続き Check(A, B)　//ABはBoolean.
　　{
　　　　//二つのTrue/Falseが違う場合止まる処理
　　}

　　手続き mycheck(r{期待される数値}; s2, s3{関数に渡す文字列});
　　{
　　　　Check(r, StrCount1(s3, s2));
　　}

手続き testStrCount1;
{
　　mycheck(3, 'ああああああ', 'ああ');
　　mycheck(3, 'BorlandDelphiBorlandC++BuilderBorlandKylix', 'Borland');
　　mycheck(2, 'BorlandDelphiBorlandC++BuilderBorlandKylix', '+');
　　mycheck(4, 'http://www.2ch.net/hogehoge/test', '/');
　　mycheck(0, 'http://www.2ch.net/hogehoge/test', '+');
　　mycheck(0, '+', '+++++');
　　mycheck(0, '', '+');
}
上記手続きtestStrCount1によってStrCount1という関数が
一発でテストできるし、何をやっているのか伝わりますよね


　　手続き mycheck(r{期待される数値}; s2, s3{関数に渡す文字列});
　　{
　　　　Check(r, BackAnsiPos(s3, s2));
　　}
手続き testBackAnsiPos;
{
　　mycheck(9, 'ああああああ', 'ああ');
　　mycheck(31,'BorlandDelphiBorlandC++BuilderBorlandKylix', 'Borland');
　　mycheck(28,'http://www.2ch.net/hogehoge/test', '/');
　　mycheck(0, 'http://www.2ch.net/hogehoge/test', '+');
　　mycheck(0, '+', '+++++');
　　mycheck(0, '', '+');
}
上記 testBackAnsiPosで BackAnsiPos が何をするのかが
一発でわかると思います。(文字列の後方検索です)
ﾂﾈﾆこのﾃｽﾄコードを流しながらBackAnsiPosを作成していくのです。

　　エッチもプログラミングも二人でやった方がいいって事だ
＼＿＿＿＿＿　　＿＿＿＿＿＿＿＿＿＿＿＿　　　
　　　　　　　　　|/ﾔｯﾀﾓﾝｶﾞﾁ
　　　　　　　　∧ ∧∧∧
　　　　　　　 (,,*ﾟДﾟ) _　,,) ｿﾚ ｳｿｰ ﾃﾞｽｰ
　　　ﾊﾟｺﾊﾟｺ/ 　 つ 　 | 　ﾊﾆャｰﾝ
　　　　　 ((（ヽ　 ﾉ ／Ｕ
　　　　　　　Ｕ ＵＵ

>>143さん
> 俺が、体重100KOverの「ピー」でもOKですか?
> あと、モレは新人で「ピー」すら理解できません。 「ピー」ですか?
> (注)極端な例です。

自主規制してみました。

それは人として・・・・・・「ピーーーーーーーー」

それを言ったら、そういう上司だったら仕事できませんとか
そういう顧客なら会えませんと言うようなものなので

あーきーらーめーてーーー

っていうしかないです。

>こういうヤツ相手だと、俺には無理っぽいです。
　　　　　 ∧∧　　　／￣￣￣￣￣￣￣￣￣￣￣
　＠' ― (,,ﾟДﾟ)つ ＜　ﾈｺ ﾆﾓ ﾑﾘ
　 　し― ∪　 　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　ﾄ ｲｯﾄｷﾏｽ

　　　　　 ∧∧　　　／￣￣￣￣￣￣￣￣￣￣￣
　＠' ― (,,ﾟДﾟ)つ ＜　ｵﾈｰﾁｬﾝ と (セ)XPしてーな！
　 　し― ∪　 　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　ﾄﾓ ｲｯﾃｵｷﾏｽ

　　　∧∧　　　／￣
（ ＿(,,ﾟДﾟ)　＜　大分前のレスなのですが
⊂,,＿_つつ.　　＼＿

＞GUIのテストも見た目で判断しないように。

という記述もありましたが
DelphiでGUI部品を作っていて
１ドットのズレを判断するのに、見た目以外の判断方法は
多分ないですし。

マウスでのToolbarのドッキング機構などや
WindowのResize時の微妙な挙動のテストに関してもです。

ただ、それをﾑﾘと言ってあきらめずに
テストしようとする努力や、
人間の見た目というにもテストを課しておくことが
XPにつながると考えています。

>>148
ということはある意味、選民思想にXPは基づいていると考えて
良いかと思うのですが(また、極端ですが)

端的に言うと「ダメなやつはダメ、出来るヤツは出来る」思想と
捕らえてよろしいんですかね>XP?

>>150
　　　　　　　　　ｲﾔｲﾔ ｿﾃﾞﾊﾅｸﾃ
　　　　∧ ∧
　　　　(；ﾟДﾟ) 　ｱｵﾘｶｴ?
　　　　/　　| 　　ﾈﾀ ﾅﾗ ﾜｶﾘﾔｽｸ ﾀﾉﾑ
　　〜'( UUﾉ　
>>143で言っていることは
「かわいいおねえちゃんとしか仕事しない」
っていう程度に変な事を言っているわけで
常識としてそれはﾍﾝでしょ？

＞「ダメなやつはダメ、出来るヤツは出来る」思想
全然ちがうし。

折れもsageときます。

>>151
あ、マジだったんですが(w

俺の言いたいことは、PGの世界って泥臭いことが
多いのは皆さんご承知の通りで。
今までの理論は綺麗ごとばかり言って現実には目を
背けてたが、XPは違うとはっきり言ってる。

なら、ダメなヤツをどうすれば良いかの答えを知りたいって
ところが正直なとこですかね。
(ワインバーグ本なんかはさりげなくエグイこと書いてたりしますが)

でもXPマンセーなんですよ(w

ageときます。

うぉ。なんだか大盛況なくらいふえとる。

１日Lyeeをしらべてて思ったこと。
　・小難しぃ〜い話に終始される。
　・誇張は随所にある。
　・でもやりたいことはコレからの課題として同感できる。
　・今はまだムリやろ。（現実問題を想定した結論）
　　　開発者として人員的な問題もあれば、顧客への実現方式の中に穴もある。
　　　これだけ欠陥があったら適用しても結果はたかがしれ。
　　　っちゅうか通常の開発とたいしてかわれへんヽ（´ー`）ノ
　　　　　→最初の保守云々のメリットはどこへやら
　　　　　　　　→保守云々をむりやり正当化してみる。
　　　　　　　　　経路図引きなおした後全部ソース自動生成ってんならなっとくもいこうもの。
　　　　　　　　　途中手を加える部分が必ず残るはどぅよ？ってのがあるが

　　 ￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧
　( ﾟДﾟ)
　| っ日~~　　ｼｮｳｷﾎﾞ ﾅ　ﾓﾝﾅﾗ
　と_）_）　　　　　　　ｺｳｶｶﾞ ｱﾘｶﾄﾊ ｵﾓｳｶﾞﾉｫ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
>>129
　実際つかってもないけど、なんとなく納得。

>>131
　確かに（みょ〜になっとく）

>>132
　微妙にXPを〜っと言うよりは
　やらんとする方式がXPと似てる部分があった〜ってオモタ。
　>>133と同意見っぽい。

　ﾊﾅｼﾊ ｶﾜｯﾃー
　￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（・д･⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

>>152
　＞なら、ダメなヤツをどうすれば良いかの答えを知りたいって
に限って横から反応。

業務に使わなければいい。
ダメなヤツは今できない。
できるときに実戦投入すりゃええはなし。

っと言ったときに出る問題
「投入してない間はあそばせとくのか？」（今できないやつのことね）
[おいらの答え]
　→　投入したところで戦力としては＋１でなくマイナスだ。
　　　そうでなくとも１がせいぜい。期待を込めての成果が１なら
　　　いない方が実務ははかどる。コレ現実。
　　　教育なら脇で実戦見物しながらでも効果はあるとおもうぞよ。

実戦と教育は別個でやるってのがおいらの持論。
かつて体制の中で実戦投入され、
幾度となく足を引っ張ってきた記憶があるのでそう思う。

っていってておいらが言ってる「実戦」って組織戦を頭に浮かべてのことば
なのよね。今ふっと思った。

>>154
> 実戦と教育は別個でやるってのがおいらの持論。
運転免許を取るんだって、教習所で教わってから仮免、本番だよな。

車の運転をしたことない奴がいきなり一般車道に出るのは
車道を混乱させ、大事故につながるかも知れんのに、
プロジェクトではプログラムの組み方も知らんやつがプロジェクトに
平気で投入され、プロジェクトを混乱させ、大幅な赤字・納期遅れを引き起こす。

> 教育なら脇で実戦見物しながらでも効果はあるとおもうぞよ。
効果はあると思うが、大学や専門学校などの実習と大して変わらないと思う。
教習所で例えれば学科みたいなもの
それだけでは畳の上の水練と同じで大して役にたたん。

小さな失敗しても良い社内プロジェクトである程度仕事のやり方を
体験して、合格した奴が現場に来て欲しいと思う。

>>153
Lyeeはどうがんばっても電波にしか見えない…
情報システム板にスレがあるのでどうぞ。

カテナの開発手法Lyee その4
http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=998843224&ls=50

Lyeeについて
　　　∧∧　　　／￣￣￣￣￣￣￣￣
〜''~（,,ﾟДﾟ）　＜　難しいことを難しく言う人はキラーイ
　 UU'UU　　　 ＼＿＿＿＿＿＿＿＿
　　ﾑｽﾞｶｼｲｺﾄ ｦ ﾔｻｼｸ ｵｼｴﾚﾙ ﾋﾄ ｶﾞ ｼﾝﾉ ﾃﾝｻｲ
　　ｸﾗｽﾗｲﾌﾞﾗﾘ ﾄﾊ ﾂﾏﾘ ｿｳｲｳｺﾄ

特に大学教育ではこの手の
難しい事を難しく教えて、さもエライ事をやっている風な
研究者の自己満足教育＆研究ってのが大量に行なわれて
何も得るものがないのが実情だと、折れは思っています。

で、そのﾀｸﾞｲが非常に少ない、この業界。

ちゃんと理論を机上の空論ではなく正しくまとめあげたら成果物が出来るという
プログラミングの仕組みが好きでお仕事やっているんですが

こういう業界に対しても、机上の空論を振り回してくる
大学の研究者みたいな人たちは、頭悪いなーって
思いました。はい。

例えばローカル変数の存在しない時代に
構造化プログラミング理論を論ずることは正しい方向ですし
理解も難しくないでしょう。(実際にはコンパイラがないと実践できませんが)

同様に
オブジェクト指向が無い時に
オブジェクト指向を論ずるのも理解は難しくないし
方向は正しいでしょう。(これもオブジェ指向言語がないと実践は無理にしても)

そして、Lyee以前にLyeeを語ることは
理解が…不可能というか抽象論ばかりで意味不明です。

更に、Lyee研究者が周りに意味不明な事をいっていると
思われている事に気がつかず、自己陶酔に陥っている辺り、大変寒いです。


ま・実(ミ)にならない事をやるのが大学という噂もありますが
そういう日本にしか通用しない価値観では
日本はIT後進国のままだとオモタリ…

国家の税金や学生から巻き上げた金つかって何をやっておるのかと…

　 　　　　　　　　　　　　　 ∧∧ 　／￣￣￣￣￣￣
　　　　　　　　　　　　　　 (ﾟДﾟ)＜ 　このスレの住人は見なかったことにしましょう。
　 　　　　　　　　　　　 　 と　　と　＼＿＿＿＿＿＿
　ﾀｽｹﾃｸﾚ　　　　　　　 　｜　｜ ﾖﾉﾅｶ ｼﾗﾅｷｬ ﾖｶｯﾀｺﾄｶﾞ アル！
　∧＿∧ ／＼　　　 　 　∪∪
（e L e ／　 ／＼　 　／￣￣￣￣￣
　　y ／　 ／　 ／＼ ｜　とかいいつつリンクしてみる
　　　＼／ 　／ 　／ ｜
　　ゞヾ ＼／ 　／〃 ｜
〜〜〜ヾ∽〃〜〜〜〜〜
　 　 　ｻﾞﾌﾞﾝ

こんなにスレがあったんだね。

カテナの開発手法Lyee
http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=990411750
カテナの開発手法Lyee その4
http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=998843224

　　　　　　　∧ ∧　　・・・・。
　　　　　　　( ﾟДﾟ) 　　DQNには気をつけような。
　　　　　　　|∪ |
　　　　　 〜|　　|
　　　　　　　U U 　　

　∧∧
　( *ﾟдﾟ)
　| っ日　　ｳｨ-
　と _）_）　　　ｷｮｰﾊ ﾖｯﾊﾟﾗﾀ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

>>155
教習所のたとえ話！いいこと言った！！φ（．．）

ぜひ（めんどくさいけど）実務ライセンス制度とか実現されて欲しいと思う
今日この頃。なんとかでけへんかなと思考中。

>>156
Lyeeの言いたいことはまちがっちゃいない。
多分これからそんな方向に進んでいくだろうとも納得もできる。
だけど言い方と現在での実現レベルがあかんとおいらは思ふ。

>>157
言いたいことは大方同意。
研究者の言い分のことも同意。
せやけど、あんなたるいことを考えるのは現場以外の人間の方が向いていると
思えば考えれるだけ考えてもらっとこうと個人的に思う。
実務で没頭するとなかなか考えないし（−−；）

リソース依存で開発者が楽をしよ〜
ってのはハード性能がよくなればよくなるほど、
まかり通ってしかるべきものだと思う
（人間の反応速度に頭打ちがある以上。オカネ問題も含めて）

リンク先の所は流し見てみた。
想定したことに極端なズレがなかったな〜と思うのと、
出張32がいたことになぜかおどろいた。

>>157
> 特に大学教育ではこの手の
> 難しい事を難しく教えて、さもエライ事をやっている風な
> 研究者の自己満足教育＆研究ってのが大量に行なわれて
> 何も得るものがないのが実情だと、折れは思っています。
カチンときたんだが、ちゃんと裏とって言ってます？

　　　　　∧ ∧　　／￣￣￣￣￣￣￣￣￣￣￣
　〜' ― (,,ﾟДﾟ) ＜　裏っていうか、自分の体感なんで…
　 　し― し-Ｊ　 　＼＿＿＿＿＿＿＿＿＿＿＿
　多分、学部学系によっても全然違うでしょうから
　　　折れ,情報系じゃなかったし。。

　カチンと来たならスマソ。

　全部が全部そうだとは思ってませんが
　その傾向が強いと思ってます。

　その辺りの認識にカチンと来たならマジスマソ
　折れのガッコでは情報系を卒業してもプログラミング
　あまり理解していない人ばかりだった。


　そして、Lyeeの文章読んでみたら、やっぱりかと思った。

　裏というか実例がLyeeだとしてください。
　あれがマトモに論じられている時点で、折れには納得いかないです。
　折れがLyee研(なんてものがあれば)に配属されたら
　情報処理業界に絶望してプログラマにならないかも...

　このURLの内容がわかります？
http://www.lyee.co.jp/webapp/jp/kozo/index.htm
　わかる開発者がどれほどいます？
　何か役にたちます？

　5年氏はがんばって解読されたみたいですが、折れにはちょっとﾑﾘでした。

なんかすごいですね。個人的感想を書かせていただきます。

>>142
貴重な情報をありがとうございます。プログラミング時間が1.5倍くらいなら、
他のメリットが十分あるので、許容範囲のような気がします。

>ただ、XPの理想は二人ではなくグループでのペアプロだとは思います。
それはまったくその通りだと思います。

>あと、完全にペアという形式にこだわっているようですが
>30分間は別々にコード書いてまた一台に寄ってペアしてデバッグして
>また1時間は別々になって･･･って形式でも
>コミュニケーションが密に取れるのならペアプログラミングと呼べると思います。
「完全ペア」にどのくらい実現性があるかを知りたかったのです。
私も143=152さん同様、XPマンセーであります。

ここまでの話では、Delギコさんのおっしゃるような方式が、現時点では、現実的
かつ有効な気がしました。
（「ペアしてデバッグ」とありますが、「ペアのときは主にデバッグ」という意味
ではないですよね。念のため。）

>>143
問題提起ありがとうございます。実は、私も「臭い系」には弱いんです。
これは難しい問題ですよね。
ただ、142のような「部分ペア」なら、多少は我慢できるような気がしませんか？
>新人で2重loopすら理解できません。
あ、私ですか？2重までなら大丈夫です。3重ループはきついです。（冗談です^^）

>>152
>なら、ダメなヤツをどうすれば良いかの答えを知りたいって
>ところが正直なとこですかね。
「生理的にだめ」と「能力的にだめ」は一応分けてもよいですよね。それで「能力的に
だめ」というのは、前スレ56の「素直な中学生のほうがましなプロがいる」という話
を信じるなら（私は56さんのまじめなレスを信じます）、わかります。
結局、ある程度の「選民」はしかたがないような気がするのです。
また、ペアを教育に使えることもあるかもしれませんが、「ペアの目的は教育ではない」
と思います。

5年さんの>>154の
>業務に使わなければいい。
>ダメなヤツは今できない。
>できるときに実戦投入すりゃええはなし。
は、どうも表現がキツイのですが、そうかなと思います。
これに関しては、155さんの
>小さな失敗しても良い社内プロジェクトである程度仕事のやり方を
>体験して、合格した奴が現場に来て欲しいと思う。
が、ものすごく説得力があると感じます。

>>161
Lyee なんて日本の情報処理学界でも「電波」扱いでしょう。

調べてないけど、さすがに Lyee 関連論文で、フェローの査読を通ったうえで
掲載されたものって存在しないんじゃないかな？

Ｄｅｌギコさん、テストの具体例ありがとうございます。
もう少し理解が進んだらレス＋質問させてください。

Ｄｅｌギコさん、5年さん、Ｌｙｅｅの話ありがとうございます。
これはちょっと難しいので、もう少し、あとで研究させていただきます。

　　　　　∧ ∧　　／￣￣￣￣￣￣￣￣￣￣￣
　〜' ― (,,ﾟДﾟ) ＜　なるほどー。サンクス>>163
　 　し― し-Ｊ　 　＼＿＿＿＿＿＿＿＿＿＿＿

　Lyeeを見て、情報処理学会を評価するなって事ですね。
　それは申し訳ないです。


　ただ、Lyeeを許すと悪評にしかならないような気も…

　周りからﾃﾞﾝﾊﾟという評価されるのなら
　学会の良識ある人が
　つぶすのが研究者の義務かと…

161のURLを見に行ったんだけど。
いきなりこれだぜ　↓　よくあるトンデモ君じゃん。

> "意図"というものは、われわれ人間が言葉の発言や文章の記述という
> "言動"（生命現象）を引き起こす由来に位置する事柄であり、
> 言動として現象化される前の状態にある。

一行目からして、かってに「意図」なるものの定義してるしさ。
かってな定義の上に、かってな定義を重ねてるだけでさ。

2行目の「引き起こす由来に位置する事柄」あたりの言葉遣いも、
むりやり難しげに言いたいオーラがプンプンしてるしさ。

3行目の「言動として現象化される以前の意図」なんて、
言語学とか記号論とかやってる人間が聞いたら笑うぞ。
たぶん。

>>166
同意。
こんな表現しかできない奴は阿呆です。
本当にできる人は、もっと判りやすい表現を使うものです。

>>165
＞ただ、Lyeeを許すと悪評にしかならないような気も…
まぁどんな業界にもピンからキリまであるってことで、Lyee話題はもう
いいんじゃないですか？

XPって和気あいあいな職場であることが前提な気がする。

技術に対する心構えが皆一緒だったらいいのにね。

>>169
> 和気あいあいな職場であることが前提な気がする。
なるほど、
　・ペアプログラミングで片方だけがコードの設計・実装をやって
　　もう一人は見てるだけで何もしない。
　・ペア同士でコードの実装方法でもめ、決着がつかない。
　・工数は自分の申告なので、極端に多めに見積もることもできる
　・自分で最善のリファクタリングをしたと思ったのに、
　　誰かが変なリファクタリングをして改悪されている。
XPは数人のチームが向いていて、数十人のチームでは向かないと書いてあったが、
各員の相性が良く、モラルが高く、コミュニケーションも密でないと実現できないな。
できればスキルも同じぐらいでないとスキルが高い人に負担がかかりすぎるだろう。

でも、そんな優秀なチームは別にXPでなくとも生産性が高い仕事をするはず。
各員が足の引っ張り合いや責任逃れに汲々として、余計なことに気を回している
チームは生産性も低いだろうし、XPにも向かない気がする。

つまり、XPは民主主義のように民度が高い場合最良の効果を発揮するが、
民度が低い場合、優秀な独裁政治にはかなわない。

>>169
> つまり、XPは民主主義のように民度が高い場合最良の効果を発揮するが、
> 民度が低い場合、優秀な独裁政治にはかなわない。

そして、民度が高いプロジェクトは事実上存在しない。
「プロジェクトの９９％はクズである」

>>169
>XPって和気あいあいな職場であることが前提な気がする。
>技術に対する心構えが皆一緒だったらいいのにね。
確かに、そんな気がします。
あるいは、アメリカのドラマでよくあるような「クセのある（ならずもの？）
エキスパートの集団」とか。（特攻野郎Aチームでしたっけ？古すぎ？）

いずれにしても「チーム意識」を持てることは重要な気がします。
しかし、逆に、あまりに殺伐とした職場では、何式であってもつらいような．．．。

>>170
うーん。私は現場を知らないのですが、挙げてある項目はどれもとてもリアルに
感じられます。ご指摘ありがとうございます。

>スキルも同じぐらいでないと
そう思います。問題は、有能な人に負担がかかり過ぎないようにすることと、
きちんと代価を支払うことですよね。
これは「言うは易し、行なうは難し」だと思いますが。

ただ、たぶん、XPも「みんな平等の民主主義」ではなくて、強いリーダーが必要
ではないかと思います。それで、そのリードの仕方が、「おまえの担当はこれ。
じゃ、後はだまってやれ」式ではなく、なるべく、一人一人に責任を持たせる方向
なのでは、と思うのです。
これはうっかりするときれい事ですが、そうではなく、もっとシビアなもののよう
な気がするのですが。
いずれにしても「会社」は、「民主主義」ではないですよね。

>>171
>「プロジェクトの９９％はクズである」
今問題なのは、プロジェクトの質というよりPGの質ですよね。たぶん。^^;)
でも、この数字は本気でしょうか？

172の補足です。
>、後はだまってやれ」式ではなく、なるべく、一人一人に責任を持たせる方向
「一人一人」だとあんまりシビアなので、一人ではなくペアなのかな、と思うのです。
（もちろん、それだけという意味ではありませんが。）

「他人のコードを勝手にリファクタリングする」というのも、私のような常識人が一人で
やってるなら、むしろ躊躇し、何もしないことの方が多いような気がします。

>>161
リンク先をちょろっとだけ読みました。
何人が言うように、電波に特有な文章だと思いました。

良いスレですね。
(告白すると、ちょっと前に酔って煽り紛いのカキコしてしまいました(^^;)

>>172-173
> ただ、たぶん、XPも「みんな平等の民主主義」ではなくて、強いリーダーが必要
現在の民主主義も大統領か首相かの違いはありますが、リーダはいます。
XPもリーダという役割を誰かがこなす必要があるでしょう。
例えば
>　・ペア同士でコードの実装方法でもめ、決着がつかない。
を決着させる役割はリーダが行うべきでしょう。

> 「他人のコードを勝手にリファクタリングする」
XPではコードは共同所有なので自分のコード、他人のコードの
概念はないでしょう。

> むしろ躊躇し、何もしないことの方が多いような気がします。
躊躇する理由は何でしょう？
一応私が考えた理由としては
　・人のソースだから
　・動いているソースにバグを埋め込むのが怖い
　・スキルがないので改悪する可能性が高い
などを推察しましたが、あなたの考えはどうでしょう？

>>172
> >「プロジェクトの９９％はクズである」
> 今問題なのは、プロジェクトの質というよりPGの質ですよね。たぶん。^^;)
> でも、この数字は本気でしょうか？
およそ何に関しても、その９９％はクズです。
スタージョンの法則。
まぁそこまでは酷くないけど、８０％くらいはクズかなぁ。

プロジェクトの成否って、始まった瞬間に決定してる場合が多いような気
がするなぁ。つまり見積提出の時点。

>>176
スタージョンの法則は統計的に証明された法則ではないので、根拠を示さない
と弱いと思われますが。

> プロジェクトの成否って、始まった瞬間に決定してる場合が多いような気
> がするなぁ。つまり見積提出の時点。
確かに見積もりを依頼された時点で仕様が曖昧かつ、なぜかスケジュールは
明確に決まっているとか、どう考えても間に挟まっている SE の能力が足りな
いなど、デスマーチの香りが漂ってくるプロジェクトはありますね。

>>176
見逃しといたけど
「だからどぅなのよ？」って意見はかわれへんので
あえていっとく。
クズだからどうなの？

>>175
>>　・ペア同士でコードの実装方法でもめ、決着がつかない。
>を決着させる役割はリーダが行うべきでしょう。
なるほどそうですね。
>> 「他人のコードを勝手にリファクタリングする」
>XPではコードは共同所有なので自分のコード、他人のコードの
>概念はないでしょう。
えーと、すみません。「他人の書いたコードを．．．」のつもりでした。
躊躇する理由は、「バグを出して責任を取らされる可能性があるなら、
動いているものに触りたくない」でした。（私は小心者です。^^;）

ただ、よく考えてみると、XPの場合、基本的には「テストが通った＝
ＯＫ」なのですよね。リファクタリングするコードが他人に書かれたもの
の場合、その人がテストも書いているわけですから、そのテスト結果を壊
さないかどうかだけ見ながらリファクタリングすればよいわけですね。
（違いますか？）
それなら、仮に一人でも、やれるような気がしてきました。

>>176 >>177
>プロジェクトの成否って、始まった瞬間に決定してる場合が多いような気
>がするなぁ。つまり見積提出の時点。

>確かに見積もりを依頼された時点で仕様が曖昧かつ、なぜかスケジュールは
>明確に決まっているとか、どう考えても間に挟まっている SE の能力が足りな
>いなど、デスマーチの香りが漂ってくるプロジェクトはありますね。

そうなんですか。それは、なんとも、すごい話ですね。
スタージョンの法則って、なんでしょう。よろしければ教えてください。

また出張でちょっと留守します。

Lyee
Lyeeはライセンス料が高いのでまず当社で導入はむずかしそうでした。

XP
上司のXP観をリファクタリングしてみましたが性能は変わらないので無駄でした。
上司は今までプロジェクトを組んで開発された事が無いようなので、理解しにくい
のかもしれません。
ただ、分らない人が誤解してXPを導入するのは大変危険だと悟りました。
当社ではこのような感じに現在なっております。

仕様書（=コーディング規約、画面やDBテーブルの設計、仕様書という事らしい）
は不要。
・ペアプログラミング、共同所有権、リファクタリング
上司が全て作成途中のプログラムを書きなおす。
・コーディング標準
上司による一元管理
・オンサイト顧客
上司
いかがでしょう。

・コーディング標準
上司の気分による一元管理
でしたね

>>179
スタージョンというのは前世紀半ばに活躍したＳＦ界の大御所で、彼がＳＦ大会
で

　「ＳＦの９割はクズである、もっともあらゆるものの９割はクズである」

と述べたのが、スタージョンの法則らしいです。

私はこの発言をリアルタイムで聞いていないのでコンテキストは不明ですが、
これは統計的な根拠があっての発言ではなく、作家の鋭い観察眼が、粗悪品
乱造の当時のＳＦ界を通して社会全般を見透かした言葉と理解しています。

詳しく知りたければＳＦ関係の板で聞いてみると、よろしいかと。

>>新人氏
AirH"の調子はいかが？

>>180
「興味深い」（と言ったら怒られそうですが）実例をありがとうございます。
お互い、がんばりましょうね。^^)
>>182
スタージョンわかりました。ありがとうございます。私は光瀬龍が好きでした。
>>183
えーと、すみません、なにのお話．．．でしたっけ？

ペアについては、完全導入が無理なら、以下の方法が可能。

1．やらない。（>>85）
　>ただし、共同所有権は、こまめにレビューしてペアプロ出来ない分をカバー．．．。
2．部分的にやる。（>>142）
　>30分間は別々にコード書いてまた一台に寄ってペアしてデバッグしてまた1時間は
　>別々になって．．．

ということでしょうか。合理的な気がします。

発言数も減った様子ですね。XPに関しては、Delギコさんがいろいろ例を出されていますし、
テストの話とかに行きましょうか？

>>185
テストとなると、テスター専門会社の話とか聞きたいが。
ここにはいないかなぁ。

情シス板で例のスレが再燃してるみたいです＞Ｅｒｒｏｒ４０１氏

>>186
テスター専門会社というのがあるのですか。知りませんでした。
どなたかいらっしゃれば、ぜひ、ご発言ください。

書き込み、減っちゃいましたね。でも、も少し書き込んでみます。

で、今度はテスト関係です。（勝手に進めるな？）
テストはプロとアマをわける大きな要素だと思います。このスレはプロの方にパー
な教員が質問しているわけですが、学生さんや他のアマの方も見ているようなので、
少し「復習」させてください。
まちがいはもちろん、なんでも突っ込んでください。m(__)m

プロのプログラマは「モジュール」というプログラムの一部を担当することが多い。
モジュールとは手続き言語ならサブルーチンとか関数、オブジェクト言語ならクラス
などが代表的と思われる。

これらを個別にテストするのが「単体テスト」で、全部つなげてソフトウエア全体を
テストするのが「結合テスト」。前スレのレスでは、「単体テストはすんなり通る。
問題は結合テスト」という発言が複数見られた。

通常の工程では、コーディング（コード書き）の後にテストがある。デバッグ期間
（テスト期間？）はかなり多く予定している様子。コーディングよりずっと長い
との発言あり。3倍くらい？

（ただし、これが単体テストの話か結合テストの話か両方かは特定されていなかったと
思います。
　また、アマの私には「テスト期間」と「デバッグ期間」が同じものかどうか不明です。
とりあえずは、同じものと考えていますが、違うならご指摘を。）

一方、テスト期間の名の元、設計からコーディングをこなさなければならないという
意見もあり。

で、私なりのXPのテストの理解を書きます。これも違っていたらご指摘を。

1．XPでは目的のコードを書く前にテストコードを書く。（びっくり！）
2．テストコードをはじめに実行し、当然、失敗するところからコーディングをはじめる。
3．「コードが完成する」というのは「テストが成功する」ことである。
　　（もちろん、テストの妥当性には十分注意する必要がある。）
4．テストは、基本的に、「自動」とし、誰でも実行でき、結果を見れるものとする。
5．モジュールで単体テストに成功すると、即（2時間以内から最低でも1日以内？）、
　　結合テストを行う。

もし、問題なければ、まず単体テストのお話からうかがいたいと思いますです。

テストに関してちょっと書いてみます。

各社いろいろな呼び方があると思いますけど、ある程度のプロジェクトでは
次のようなテストをします。

* 単体テスト
　　モジュール単体のテスト。
* 結合テスト
　　モジュール間のインタフェースなどを確かめる。
* 総合テスト
　　システムテストなどとも言う。実運用を睨んだ総合的なテスト。
* 受け入れテスト
　　クライアントがテスト計画・シナリオを立案し、システムが
　　正しく動いていることを確認する。運用テストと言ったりもする。

テスト工程とは言いますけど「デバッグ工程」「デバッグ期間」というのは
あまり聞きません。これも会社によるのかも。

コーディング工程の全工程に対する割合は、プロジェクトの大きさによって
大きく違いますが、100人月を超えるようなプロジェクトでは、

調査・設計工程：50%
コーディング工程：15%
テスト工程：35%

くらいだと思います。もちろん、プロジェクトの大小・性格によって、数字は
上下しますけど。

とりあえず、こんなとこで。

>>187
あのスレは、もう興味ありません（藁

>>190
>1．XPでは目的のコードを書く前にテストコードを書く。（びっくり！）

従来のウォーターフォール式のプロジェクトでも、コーディング前に
「単体テスト仕様書」あるいはそれに類するものを書きます。
というか、書いたほうが良いのです。

論理的には、外部設計が終わった段階で総合テスト仕様書が書ける
はずであり、内部設計が終わった段階で、単体テスト仕様書・結合
テスト仕様書が書けるはずなんですよね。

コーディングが終わって、担当したプログラマが単体テスト仕様書を
書くと、自分が実装したものが実装した通りに動くのを確かめるだけの
テストになってしまい、仕様の取り違えやエラーケースの見落とし
などが発生しがちです。

・・・というのは、あくまでも理想論で、大抵は後付けのテストが多いですね。

>>193
おおむね同意するが、１点だけ
> コーディングが終わって、担当したプログラマが単体テスト仕様書を
> 書くと、自分が実装したものが実装した通りに動くのを確かめるだけの
> テストになってしまい、仕様の取り違えやエラーケースの見落とし
> などが発生しがちです。
単体テストについては別に「実装通りに動いているかを確認する」
でいいんじゃないの？

結合テストについては仕様通りに動いているかを確認する必要があり、
プログラマに任すことはできない。仕様書を書いた人がテスト仕様も
書く必要があると思う。

>>194
>単体テストについては別に「実装通りに動いているかを確認する」
>でいいんじゃないの？

んとね、単体テストで確認するのは、
・仕様通りに実装しているか
・意図した通りに実装できているか
だと思うんだ。

意図した通りに実装できているかどうかは、後付けのテストでも確認出来る。

問題なのは前者で、内部設計書とか、詳細設計書と呼ばれるものの
内容をプログラマが勘違いして実装してしまったり、ある機能が落ちて
しまったりしたときに、実装したという経験から、無意識のうちに実装
したものが実装した通りに動くことだけのテストになりやすい。
特に、100%カバレッジを要求されたときに、この状況に陥りやすい。

そういうこと無い？
XPのUnitTestでもそうなんだけど、一旦盲点になってしまうと、なかなか
気づかないんだよね。

それに、先にテスト仕様書を作れば、プログラミングとテスト仕様書の
レビューを平行して行えるしね。

>>195
なんか単体テストの定義にズレがあるような気がするのだが
> んとね、単体テストで確認するのは、
> ・仕様通りに実装しているか
> ・意図した通りに実装できているか
> だと思うんだ。
実装者はプログラムを作ったら作りっぱなしなのか？
実装者は「自分の思ったとおりに動くのか？」を確認する行程が存在し、
その行程が「単体テスト」だと思っている。
これが私の単体テストの定義だがそちらと意識は合っているか？

> 実装者はプログラムを作ったら作りっぱなしなのか？

いえいえ、単体テストはプログラマがやります。

> 実装者は「自分の思ったとおりに動くのか？」を確認する行程が存在し、
> その行程が「単体テスト」だと思っている。

はい、その通りなんですが、「思った通り」というのが曲者なんです。

実装しなければならないものを、もれなく、正しく「認識」出来てればいいんですが、
仕様を取り違えて実装してしまった場合、「それをそのように実装した経験」が、
「自分が書いたものが書いた通りに動くテスト」
だけを（自分に）させてしまったりしません？あ、僕だけかな？

自分が何をどう書いたかという記憶をきれいさっぱり忘れて、仕様書を読みながら
「要求される項目」のテストを書ければいいんですが、100%カバレッジを要求されて
いる場合などは、いつもソースを見ているため「盲点」が出来てしまいます。

・・・っていうのも僕だけ？なのかも・・・

カバレジテストはやらないのか?
めさせ100%

テストデータを用意するためのプログラムを何本書いたことか。

>>197
質問ばかりで悪いが、確認させてくれ
つまり、単体テストは
・単体テスト仕様書は実装者以外の人が作る
・単体テストは実装者が行う
のか？

> 仕様を取り違えて実装してしまった場合、「それをそのように実装した経験」が、
> 「自分が書いたものが書いた通りに動くテスト」
> だけを（自分に）させてしまったりしません？
仕様とズレがないかを行うテストは結合テストでやればいいと思っている。
というか、それが結合テストの目的ではないのか？

XPで言えばユニットテストが単体テストにあたり
受け入れテストが結合テストにあたると思っている。
ユニットテストはテストプログラム自体がテスト仕様書にあたり、
そのテストプログラムは自分で作るはず。

結合するまで仕様とずれが無いかわからんのか、この人は・・・

Error401さん、みなさん、レスありがとうございます。
とてもおもしろい話になっているので、蛇足のような気がしますが、一応、
レスさせていただきます。

まず、私の「結合テスト」の定義（>>189）は、微妙にずれているような気が
しました。正しくはError401さんの>>191を見ることにします。ありがとうご
ざいます。

>>193
>従来のウォーターフォール式のプロジェクトでも、コーディング前に
そうなのですか。言われてみれば（というかXP本を読んだ今では）その
ように思えますが、私にはこういう発想はありませんでした。
（実は、このレスを読んで、「単体テスト仕様書」と「テストコード」
の関係について、少し疑問が出てきました。素人考えなのですが、PGが行う
単体テストに「仕様書」というものが必要なのでしょうか、ということです。
ただ、今、194さんと興味深いお話をしているので、ちょっと後でまた質問
させてくださると幸いです。）

Error401さんのおっしゃる「盲点」は素人ながら、わかる気がします。

素人が横からすみません。
>>199
>仕様とズレがないかを行うテストは結合テストでやればいいと思っている。
199さんのおっしゃる「仕様」は「モジュールの外部仕様」（そういう言葉が
あるかどうか知らないのですが）ですよね。（それとも「アプリケーション
全体の仕様」？）確かに、モジュールが外部と正しく相互作用するのなら、
それ以上のテストはいらないような気もします。
そう考えると、それを確かめるのは（>>191の定義での）「結合テスト」？
しかし、インターフェース部分のテストも、結合前にしておいた方がよい
ような気もします。何か勘違いしてますでしょうか。

言葉で議論するより、具体例で話し合った方が、行き違いが少ないような気が
します。それとXPの話か、従来型の話かも、統一していただいた方が、読んで
いる人（つまり私のような人）は助かるかと思います。

たとえば、ある仕事をする関数（群）を書いたとします。この関数の内部状態
をテストするとしたら、それは単体テストですよね？それに、関数にいろいろな
引数を与えて動作をチェックするのも単体テストではないでしょうか？
（>>147のDelギコさんの例はXPだと思いますが、そういものですよね。
(A、Bは整数？））

もう逝ってくれのサンデープログラマの新人です。
ちょっと思ったことです。

私は自分の作ったプログラムが一応思い通り動くとかなりうれしいです。
しかし、そのあとのテストはあまり気乗りがしません。絶対テストが必要で稼働時
にバグを出すより今出した方がよいと、もちろんわかっているのですが、「徹
底したテスト」をコーディング時の気持ちで行うことはできないのです。

プロの方は「気乗り」だのなんだの言わないものかもしれませんが、そういう
ことはないのでしょうか。（あるいは、「テスト大好き」とか？）

XPの「最初にテストを書く」がすごくいいと思ったのは、最初にテストを書く
のはそれほど嫌ではなく、考えてみると、ちょっと楽しいかもしれないと思う
のです。「俺様は、こんなケースも考えるぞ」みたいな。（バカですみません。）
それから、テスト項目の失敗を1つ1つつぶしていくのも気持ちよさそうです。
そして、テストが全部通ったら完成。なんて気持ちいいんだろうと思って
しまいます。
XPには、そういう「心理学」もあるかと思ったのです。いかがでしょうか。

>>202
>します。それとXPの話か、従来型の話かも、統一していただいた方が、読んで
>いる人（つまり私のような人）は助かるかと思います。
199さんのお話が「不統一」と言っているのではありません。すみません。m(__)m
「今までのように、これからも、明記しながら議論していただけると助かります」
という蛇足的お願いの意でした。

あまりに書き込みしすぎました。すみません。寝ます。

えっと、この発言は、「ウォーターフォールにおける単体テストに関して」です。

>>199
>つまり、単体テストは
>・単体テスト仕様書は実装者以外の人が作る
>・単体テストは実装者が行う
>のか？

そうしなければならないわけでは無いでしょうが、普通はそうするでしょう。

>仕様とズレがないかを行うテストは結合テストでやればいいと思っている。

例えば「バグ票」なるものを書く場合に、その原因を書きますよね。
良くある「機能モレ」も、
・要求仕様書レベル
・外部設計書レベル
・内部設計書レベル
・コーディング
の各段階でもれる可能性があります。

「内部設計書では書かれていたのに、コーディングのときにもれたもの」
は、コーディング工程のエラーです。

これは単体テストで検出できるはずであり、コーディング後にテスト仕様書を書くと、
「自分が実装しなかったので、テスト項目としてもあげなかった」
ことになりやすい、というようなことを言っているのです。

>というか、それが結合テストの目的ではないのか？

結合テストで上記のような
・コーディングレベルの機能もれ
・コーディングレベルの仕様の取り違い
も検出するのであれば、それも目的になるでしょうね。

でも、そんなバグが結合テスト工程で発見されたら、
「そんなこともやってねーのか、ボケ」
「単体テストやってねーんじゃねーの？」
と言われてもしかたありません。

僕の結合テストの目的の定義は、
・各モジュール間のI/Fの確認
・各モジュール間の論理的な整合性の確認
がメインです。

>>201
>の関係について、少し疑問が出てきました。素人考えなのですが、PGが行う
>単体テストに「仕様書」というものが必要なのでしょうか、ということです。

（こういう単位で言うのはイヤなんですが）単体テストのテスト項目数は
コード1000行あたり50〜200件程度要求されます。これをテスト密度と言います。
テスト密度が薄い（低い）と、なんらかのイイワケを要求されたりします。

すべてのテストケースを文章で書かないにせよ、チェックマトリクスみたいな
ものを事前に書いて、もれなくテスト出来ているかどうかを確かめる必要が
あります。後からテストケースを考える場合、実際に書くことによって、
テストケースを思いついたりして、それをコードに反映する、なんてこともあるので、
「仕様書を書く」というのは必須でしょう。

また、ほとんどの場合は成果物として「単体テスト仕様書」を要求されます。

>しかし、インターフェース部分のテストも、結合前にしておいた方がよい
>ような気もします。何か勘違いしてますでしょうか。

えーとそのレベルは仕様書通りに作るし作られるというのが前提なので、
事前にやるのは無駄のような気がします。

ただし、I/Fが「電文」のような場合やハードウェア制御がからむ場合、
しかも担当するチームや会社が違ったり動作するマシンが違ったり、
OSが違ったりする場合、事前に疎通確認レベルのテストをすることもあります
（内部はスタブ）。これを「穴アケテスト」と呼んでるのも聞いたことがあります。

「境界値分析法」という言葉を忘れて、Webをさまよっていたら、
こんなページを見つけました。

comp.software.testing FAQ（日本語訳、ちょっとバージョンが古い）
http://www.tqm.t.u-tokyo.ac.jp/~nishi/swtest/faq.html

プライマリサイトはここ
comp.software.testing Frequently Asked Questions (FAQ)
http://www.cigital.com/c.s.t.faq.html

>>203
>プロの方は「気乗り」だのなんだの言わないものかもしれませんが、そういう
>ことはないのでしょうか。（あるいは、「テスト大好き」とか？）

いえ、おおいにあります。
また、実際に「テスト大嫌い」という人も多いようです。

僕も以前は嫌いでした。なぜ嫌いなのかというと、
・きちんとしたテスト仕様書を求められ、それを書くのがめんどくさい
・テスト環境を作るのがめんどくさい
・結果確認をするのがめんどくさい

動くはずだ、動くはずだ、動くはずだ・・・
と思い、
動いてるはずだ、動いてるはずだ、動いてるはずだ・・・
に変わり、
大丈夫かな、大丈夫かな、大丈夫かな・・・
となり、
次はちゃんとテストしよう、次はちゃんとテストしよう・・・
あーめんどくさい、あーめんどくさい・・・
となるんですね（藁

XPのUnitTestを取り入れてからは、そんな心配もストレスも無くなりました。

　新人氏と401氏、2人のビックショーに割り込んでスマソ

　　　　　　　∩ ∩　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 Ｏ′￣￣( ﾟДﾟ)＜　>>202　A,BはBooleanだよ
　　UU￣￣　U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

void Check(Boolean A, Boolean B)
{
　if (A != B) {AとB一致しねーじゃん例外投げちゃル}
}

void CheckString(String A, String B)
{
　if (A != B) {AとB一致しねーじゃん例外投げちゃル}
}
すべてはココから始まります。


単体テストのイメージ

---------------------------------------
・テストコード→関数実装→テスト実行→テストコード→関数実装→テスト実行→

※A
　　　　　　　　　　　　　　　←必要なときに戻れ
　　　　　前進しろ→
　　　←必要なときに戻れ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　前進しろ→
　　　　　　　　　　　　　　　　　　　　←必要なときに戻れ
　　　　　　　前進しろ→
　　　　　←必要なときに戻れ
　　　　　　　　　　　　　←必要なときに戻れ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　前進しろ→
　　　　　　　　　　　　　　　　　　　　　　←必要なときに戻れ
※Aまで満足するまでループせよ
---------------------------------------

完成したときは
非常に正確な関数(メソッド)＆抜け目のないテストコードが仕上がっている。

書いたテストが一気に動作するのはうれしいかも。
テストコードがどんどん増えるのも、それを通過することが目に見えるからうれしいかも

　　　　　　　∩ ∩　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 Ｏ′￣￣( ﾟДﾟ)＜　「間違う可能性があるものをすべてテストしよう」でしたっけ？
　　UU￣￣　U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

>>199
>・単体テスト仕様書は実装者以外の人が作る
>・単体テストは実装者が行う
XPのソースは共同所有。という理念がすっぽり抜けてます。
実装者以外の人がやっても実装者がやっても
共同所有している限り、どちらがやっても何の意味もないっす(ﾀﾌﾞﾝ)

今までのやり方では、単体テスト仕様書というのは、よく書かされます。
でも、普通の仕様書もプログラムと同期しないのに
単体テスト仕様書まで作ってる日には
何がﾎﾝﾓﾉかわけがわからなくなってしまう問題があると思います。

単体テスト仕様書の内容を完璧にコードにしてしまう。
これがＸＰだと思っています。

>>206
テスト仕様書を書くのは必須だとは思えません。
テストコードを書く事、リリースするプログラムコードと同じように
テストコードをリリースすることは必須だと思います。

　　　　　　　　　　　　 　 ∧ ∧ ﾀﾝﾀｲ ﾃｽﾄ ﾉ ｵﾊﾅｼ
　　　　　　　　　　　 ソ￣(,,ﾟДﾟ)
　 　 ／|￣￣￣￣￣￣　ヽ) ヽ)￣￣￣|
　　　|　| |￣￣￣￣￣￣￣￣￣￣￣| |
　　　|　| |　GIKO　NEWS　　　　　　　| |
　　　|　| |　　　∧ ∧ 　　／￣￣￣￣￣￣￣￣￣￣￣￣
　　　|　| |　　 （,,ﾟДﾟ）　＜　今日のバグです。ビルは壊れませんので安心ください。
　　　|　| |　　 （ <Ｖ>）¶　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　|　| |￣￣￣￣￣￣￣￣￣￣￣| |
　　　|　| |＿＿＿＿＿＿＿＿＿＿＿| |
　　　|　| 　　|　　　 　 　 　 　 　| ・・ロ　|
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
ソースが読めないのなら
Delphiは無料だからダウソして試すとヨシ、、

Delギコさんは以下の関数を書きました。日付文字列を返す関数です。

function TDateToYYYY_M_D(Value: TDate): String;
var
　DayStr: String;
begin
　DayStr := Format('%2s' ,[ FormatDateTime('d',Value) ]);

　Result :=
　　FormatDateTime('yyyy m',Value) + DayStr;
end;

DBに以下のような"日付文字列情報"があったでございます。(他のｿﾌﾄで書かれるデータ)

2001 5 5
2001 520

その文字列と同じものをDelphiのTDate型から生成する関数をつくったつもりだった。
つもりだった。つもりだった。つもりだった。つもりだった。つもりだった。つもりだった。つもりだった。つもりだった。

"まんま"と10月に入りました

DBの形式は
200110 1
折れの関数出力は
2001 10 1
・・・・(スペースがﾁｮｯﾋﾟﾘ違う)

で、システム動作せず！ﾝﾏｰｰ(ﾟДﾟ;)ｶﾞﾋﾞｰﾝ

>>196
> 実装者はプログラムを作ったら作りっぱなしなのか？
> 実装者は「自分の思ったとおりに動くのか？」を確認する行程が存在し、
> その行程が「単体テスト」だと思っている。

そうですよね。上のソースが
実装者がプログラムを作ったら作りっぱなしで大失敗の事例です。
作りっぱなしで、”安全に動作するというつもりだった。”というのがバグの原因です。
というか、全てのバグはそういう原因に集約されるでしょう。

ちゃんとテストしていればよかったね。
XPを知る前に作ったから許してね

　　　　　　　∩ ∩　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 Ｏ′￣￣( ﾟДﾟ)＜　テストの書き方
　　UU￣￣　U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

procedure CheckString(S1, S2: String);
begin
　if not (S1=S2) then
　begin
　　raise Exception.Create('S1とS2が違うんじゃ！この腐れが！！死んでお詫びしろや！');
　end;　//例外を発生させています。
end;

procedure testTDateToYYYY_M_D;
begin
　CheckString('2001 5 5', TDateToYYYY_M_D(StringToDate('2001/5/5')));
　CheckString('2001 520', TDateToYYYY_M_D(StringToDate('2001/5/20')));
　CheckString('200110 1', TDateToYYYY_M_D(StringToDate('2001/10/1'))); //★ここで例外が発生するからプログラム停止
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　//TDateToYYYY_M_D関数がバグあるという事がわかる
//StringToDateは日付文字からTDate型を返す標準関数です。

end;

TDateToYYYY_M_D関数をVersionUpする場合は必ずtestTDateToYYYY_M_D手続きを呼び出します。

TDateToYYYY_M_Dのプログラムコードも重要ですが同様にtestTDateToYYYY_M_Dのプログラムコードも重要なのです。

このtestTDateToYYYY_M_D手続きのコードがどんどん長くなっていくとテストが楽しくなる。
年を5桁にして試したりする必要はないけど
うるう年を考慮したり13月や32日を入れることはテストとして大事ですね。

>>208
ﾈｺ はまだUnitTestは導入していないのですが
以前テスト嫌いだったのは401さんと全く同じ思いです。
上のようなテスト手続きを書くようになってから、
テストの重要性と楽しさを汁ことができました。

ここにも同じようなｺﾄがかかれているかもです。

JUnit テスト熱中症：プログラマは、テストを書くのが好きになる
http://objectclub.esm.co.jp/eXtremeProgramming/TestInfected-J.html

一人でプログラミングし、UnitTestすることの怖いところは、

2001-10-1のときに、

"2001 10 1"でOKだと思い込んでしまい
そのように実装し、なおかつ、
CheckString('2001 10 1', TDateToYYYY_M_D(StringToDate('2001/10/1')));
というテストコードを書いてしまい、チェックOKだと思ってしまう。

・・・ということが、たまにあるんですよね。

しかも、データベースと結合するときに、
'2001 10 1'
と入れちゃったりもして・・・。

まぁ、そのうち検出できるんでしょうけどね。

>>205
誤解の原因がわかった。

> ・外部設計書レベル
私はこれを「仕様書」と呼び
> ・内部設計書レベル
これを「設計書」と呼んでいたので
結合で仕様もれのテストを行うのはおかしいと思った。
# DD書 PD書とか呼ぶときもあったりする．．．

それならば今までの話は納得できる。

ただし、私は単体テスト仕様書は実装者が作るようにしている
確かに問題点として
> 「自分が実装しなかったので、テスト項目としてもあげなかった」
> ことになりやすい、というようなことを言っているのです。
が発生するが、仕様書を作った人とテスト仕様書のレビューを行い、
テスト項目に偏りが無いかをチェックしてれば防げる問題だと思っている。
メリットとしてはやはり実装した人が一番処理のことは分かっているので
テスト項目を作りやすいというのがある。

>>206
> （こういう単位で言うのはイヤなんですが）単体テストのテスト項目数は
> コード1000行あたり50〜200件程度要求されます。これをテスト密度と言います。
> テスト密度が薄い（低い）と、なんらかのイイワケを要求されたりします。
あと、バグ検出密度とかいうのがあり、これも上限や下限を越えると
なんらかの言い訳を考えねばならない。

前システムを流用したプログラムだとバグなどは潰しきった後なので
簡単に下限を越える。

>>214
>誤解の原因がわかった。

理解してもらえてうれしいです。
この手の用語は、各社ばらばらで話しづらいですよね。

それから、最近の発言は全て「ウォーターフォールにおける単体テスト」についてです。
XPのUnitTestの話は、プログラマ板のスレとかぶっちゃいますね・・・。

そうそう、なんでDelphiUnit使わないの？＞Del*ギコ（コテハン変えるの？）
僕は使ったこと無いけど、>>212のようなテストは楽になるんじゃないかな。

　　　〜′￣￣ UﾟДﾟU<　単に使ったこと無いだけっす。
　　　UU￣￣　U U

>>213のカキコは激しく同意でございまする。

話の流れに全然関係ないが、
うさギコの姿がどっちかっちゅーとがクマに見えた。Σ(ﾟдﾟlll)ｶﾞｰﾝ

　　 ∧ ∧　　　／￣￣￣￣￣￣￣￣￣￣￣
　 ﾐ,,･д･ﾐ 　＜　 単体テストのﾊﾅｼはなにもゆーことﾅｰｼです。
ξﾐ ,,ｕ且ﾐ　 　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　　ﾏﾀｰﾘ

>>206
レスありがとうございます。後で改めて質問させていただこうと思ったのですが、
私が思ったことは、「どうせPGだけが読むものなら、日本語よりプログラミング
言語の方が意図が正確に伝わるのでは？したがって、日本語はいらないのでは？」
だったのです。しかし、このレスで理由は理解できました。
いつも明快な説明をありがとうございます。

>コード1000行あたり50〜200件程度要求されます。これをテスト密度と言います。
素人の私としてはこういう話も聞きたかったので、感謝感謝です。
しかし、1000行あたり200なら、（単純には）5行あたり1件。すごいものですね。
>また、ほとんどの場合は成果物として「単体テスト仕様書」を要求されます。
なるほど、です。
>えーとそのレベルは仕様書通りに作るし作られるというのが前提なので、
>事前にやるのは無駄のような気がします。
私の書いた「インターフェース部分のテスト」とは、たとえば、「クラスのpublic
関数の動作テスト」などの意味だったのですが、勘違いだったでしょうか？？？
（特にここで「議論」ということではないのです。
いずれにしても、変な言葉を勝手に使ってすみません。）

>>207
資料ありがとうございます。テストって、深いんですねー。

>>208
まずは、Error401さんのような方も、かつてはテスト嫌いだったと聞いて、かなり
うれしいです。^^)

>XPのUnitTestを取り入れてからは、そんな心配もストレスも無くなりました。
うーん。UnitTestだけでも導入の価値あり、という話がわかってきました。

>>209
>新人氏と401氏、2人のビックショーに割り込んでスマソ
ひえっ。私はError401さんはじめみなさんに聞いてばかりの教えて君です。m(__)m
>>>202　A,BはBooleanだよ
あれ、そうでしたか？すみません。^^;)

わかりやすい図説ありがとうございました。とても参考になります。
>非常に正確な関数(メソッド)＆抜け目のないテストコードが仕上がっている。
>テストコードがどんどん増えるのも、それを通過することが目に見えるからうれしいかも
なるほど。こういうことは大事な気がします。

あと、「Delウサギコさん　==　Delギコさん」なんですよね？

>>210
>単体テスト仕様書の内容を完璧にコードにしてしまう。
XPでは、単体テスト仕様書は（あまり）書かない、ということですね。

>>211 >>212
>Delphiは無料だからダウソして試すとヨシ、、
本題でないですけど、びっくりしました。ただなんですか。

Delphi、完全には読めませんが、意味はわかったと思います。
具体例ありがとうございます。私は本当に本当に具体的例に感謝します。
>以前テスト嫌いだったのは401さんと全く同じ思いです。
Del（ウサ）ギコさんまで。このスレの超優秀PGさんが2人も、そうだったんですね。

>>213
ものすごくリアルな話です。ありがとうございます。
［本題からずれる（と、またまずそうなので、あくまでコメントですが）のですが、
日本の多くの「学者さん」はこういう話はあまり考えないようです。代わりに、なん
ちゃらの統計手法や確率論を持ってきます。もちろん、統計や確率は重要ですが、生
きているPGさんが、わざわざ確立法則に従うようにバグを出すのでもないと思います。
こういう本当の実例から、ある程度普遍的なものができないものかと思います。］

>>216 >>218
話題を変えた方がよいでしょうか？

>XPのUnitTestの話は、プログラマ板のスレとかぶっちゃいますね・・・。
http://piza2.2ch.net/test/read.cgi/tech/998619229/-100
のことでしょうか？

プログラマ作業でおもろいのは単体テストまでではないかと我思ふ。

　　 ￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧
　( ﾟДﾟ)
　| っ日~~　　ｯﾄ　ﾀﾝﾀｲｼｹﾝｶﾗ
　と_）_）　　　 　ﾜﾀﾞｲｲｺｳ　ｦ　ｺｺﾛﾐﾃﾐﾀﾘ

プログラミング作業モード（戦闘モードとおいらは言うが）中は
結合試験がかったるくてしょ〜がない。
気分がﾏﾀｰﾘすると結合試験がお気楽に取り組める。

この差はなんなんだろうと作業中に思ったことを思い出した。

もちろん他部門がいたりすると、そことの戦闘はあることはあるけど、
基本的にここのフェーズ（ウォーターフォール方式での言い方だが）
で緊張の糸がぷっつり切れることが多い。

みんなはどぅ？
（経験者さんはもちろん、未経験者さんも想定で物言ってOKだとおもてます）

eXtreme Programming
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=989482113

＿＿_ 　ヽ
＿ ／⊂　｀∧ ∧　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　｜　|　 ＼(　ﾟДﾟ)＜　こっちじゃない？
　 | ／　　　∪ ∪　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
￣
　　　　　　　　　 ,,ヽ
　　　　　　　　　⊂, ｀＼⊃　ﾍﾞﾁｬ ／￣￣￣￣￣￣
　　　　　　　　　　 ＼∧∧　　　＜　　人気ないみたいだが
　　　　　　　　　　 ⊂(,,ﾟДﾟ)つ))　 ＼＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　ﾓﾘｱｹﾞﾃｸﾚﾖ

> 日本の多くの「学者さん」はこういう話はあまり考えないようです。代わりに、なん
> ちゃらの統計手法や確率論を持ってきます。もちろん、統計や確率は重要ですが、生
> きているPGさんが、わざわざ確立法則に従うようにバグを出すのでもないと思います。

SEにしてもPGにしても、概要/詳細設計,単体/結合/運用テストなど
すべて一まとめにすると、システム製造というのは
精神的創造活動には間違いないので、
漫画家や小説家、ｱﾆﾒｰﾀと同じように
個々人(および個々の集団)の力量に大幅に左右される
性質のものですから、統計的な測定は不可能ではないにせよ
なかなか難しいのではないでしょうか。

自動車製造でいうところの外装設計や
建築でいうところデザイン画やデザイン設計(っていうのか？)
だけを抜き出したもの≒システム全体の御仕事
のような感じなのかもしれません。

ただ、「学者さん」は
会議室で考えすぎて現場を見ていない(by踊る大走査線)
傾向はあるでしょう。
(前のLyeeの所でそう実感した
　ゴキブLyeeが1匹みつかると30匹は潜んでいると思われ)

>>221
＞プログラマ作業でおもろいのは単体テストまでではないかと我思ふ。
　　　　∧ ∧　　ソウカモ。
　　　　( ﾟДﾟ)
　　〜（　uu）

.＿＿＿＿＿＿＿＿＿
|　　　　　　　　　　　　　|
|　とりあえずＣＭです .|
|＿＿＿＿＿＿＿＿＿|
　　 ∧,,∧　||
⊂ミ.,,ﾟДﾟ彡つ

Borland Delphi 6 Personal ダウンロード
http://www.borland.co.jp/delphi/personal/
8末は一部ではお祭り騒ぎ状態だったのだが、知らないっすか・・・

ついでに宣伝。
米ボーランド，J2EEと.Netを結合するWebサービス戦略を発表
http://www.zdnet.co.jp/enterprise/0110/02/01100210.html
http://www.borland.co.jp/news/webservices_strategy.html
J2EEとMicrosoft .Netの2つのWebサービスを，
普遍的かつ業界標準に準拠した方法で結合するための基盤を提供するという。

>>219
>しかし、1000行あたり200なら、（単純には）5行あたり1件。すごいものですね。

どこで読んだか忘れてしまいましたが、うまくリファクタリングされている
smalltalkのライブラリのメソッドの平均ステップ数を調査したら、1メソッド
あたり、数行だったということです。
これを聞いた日本のある方も（どっかのMLだったかな？）手持ちのJavaのライブラリ
で計測してみたら、やはり数行だったんです。
1メソッドあたり10行としても、1000行のソースコードには、100のメソッドが
あります。それぞれのメソッドに対して2つテストをすれば200になりますね。

業務アプリケーション、特にデータベースを使うような場合は、ここまではいきませんが、
それでも平均すれば1メソッドあたり、20〜50行くらいになると思います。
メソッド数で言えば、50〜20メソッドですね。

そう考えると、50〜200というテスト項目も、それほどびっくりするものでは
ないと思います。

>私の書いた「インターフェース部分のテスト」とは、たとえば、「クラスのpublic
>関数の動作テスト」などの意味だったのですが、勘違いだったでしょうか？？？

単体テストが終わっていれば、正しい入力（メソッド引数やデータ）があれば
正しく動作することが証明されています。
結合テストでは、モジュール対モジュール、あるいは、機能対機能の結合を確かめます。
・期待通りの入力をくれるのか
・期待通りの出力をするのか
・呼び出し順序が強制される場合は、自分の使い方に誤りが無いのか
などをテストします。
これはあくまでも、僕の結合テストの定義ですけれど。

>>220
>XPでは、単体テスト仕様書は（あまり）書かない、ということですね。

僕の場合は、ドキュメント生成ツール（Javadocなど）やスクリプトを使って
あとから、一覧や簡単なドキュメントを自動生成できるようにしています。

>こういう本当の実例から、ある程度普遍的なものができないものかと思います。］

テスト密度やバグ発生率、バグ収束曲線などに加え、過去のそのチーム・個人の
実績や経験則から、そのような数字を判断する手法はある程度確立されてますよ。
「経験則」というのが曲者なんですけどね。

>>221
>プログラマ作業でおもろいのは単体テストまでではないかと我思ふ。
なるほど、わかるような気がします。

>>222
ありがとうございます。前に紹介されていたものですね。
Delギコさんも書かれているご様子。通しで読んでみます。

>漫画家や小説家、ｱﾆﾒｰﾀと同じように
>個々人(および個々の集団)の力量に大幅に左右される
PGには、「規格外の天才」もいれば、コーダー（ここで覚えました。
ただし、特定の言語を使う人を指す意味ではありません）に近い人
もいるわけですよね。だからおもしろいと思います。

>>223
>8末は一部ではお祭り騒ぎ状態だったのだが、知らないっすか・・・
知りませんでした。井の中のカワズでした（って、ちょっと意味が違いますね）。
BC++を無料にしたときは、近所で買った人たちは怒りまくっていましたが、
Delphiはうまくいったのですね。
>J2EEとMicrosoft .Netの2つのWebサービスを，
個人的には、うれしいニュースです。^^)

>>224
>smalltalkのライブラリのメソッドの平均ステップ数を調査したら、1メソッド
>あたり、数行だったということです。

>そう考えると、50〜200というテスト項目も、それほどびっくりするものでは
なるほど。言われてみるととても納得のいく数字です。
「1メソッド数行」っていいですね。そういうコードはすごく好きです。
結合テストの説明もありがとうございました。

>>225
>テスト密度やバグ発生率、バグ収束曲線などに加え、過去のそのチーム・個人の
>実績や経験則から、そのような数字を判断する手法はある程度確立されてますよ。
なるほど。そうなのですか。
たとえば、私のすぐ隣に、そういう論文を書いている方がいらっしゃいます。
画期的なのだそうです。^^)

私は、ひとつには「バグはどういうときに出るのか」や「どうすれば減らせるのか」
を考えてみたいのです。求めているのは「統計的な手法」ではありません。
（そういうものももちろん重要だと思うのですが。）
たとえば、XPが一つの答えなのではないでしょうか。

（横道ですが．．．）
Delギコさんの例やError401さんのコメントを見て、デザインパターンのようなもの、
「バグパターン」（こちらは意図的に作るパターンではありません）が整理できたら
おもしろいかな、と思いました。（「アンチパターン」はありますね。）
ここには本物のPGさんがいます。みなさん、いかがでしょうか。

ゲームプログラマーがここを見たら、笑うだろうな！
なにつまんないことで騒いでるんだって。こんな低レベルのことで悩むんなら、悩ませてくれっていうんだろうな。
本当一般企業のＳＥやプログラマーって、レベル低いんだね。
噂には聞いていたけど、まさかここまでとは・・・
君達はゲームプログラマーの足元にも及ばない！！！
ゲーム作りに比べたら、君達のしていることなんか、屁みたいなもんだよ。どうせ、大学に入って初めてプログラム組みましたーみたいな経歴の奴らがほとんどだろ？
情報科の４年にもなって、「アセンブラって何？」だって。間違いなく、独学で勉強した中学生のほうがよっぽど使えるよ！
なんか、バカバカしくなるよ。入社試験も、中卒、高卒、大卒関係なく、優秀なプログラムを書いた人間を採用すればいいのにね！！！

　ｳﾗﾚﾀ ｹﾝｶ ﾊ
　ｳﾘｶｴｼﾄｸ
　　 ∧ ∧　　　／　優秀な人材が毎年どっさり入ってきて
（∩(,,ﾟДﾟ)　＜　　　優秀な人を薄給でこき使うだけこき使って
⊂,,＿_つつ.　　＼　技術者をボロ雑巾のように捨てていくｹﾞﾑ業界の人からみたら
　　　　　　　　　　　　低ﾚﾍﾞｰﾙかもね。

あと、逝っておくと、ﾖﾉﾅｶはこのスレより
遥かにﾃｲﾚﾍﾞｰﾙです。

>>228のカキコはコピペかもねー

高レベルのつまる(<=>つまらない)話を
書き込んでちょーだいな。

>>227
「バグパターン」はどこかで見たなと思ったら、XP-MLで少し前に話題になって
いますね。

>>229
> 優秀な人材が毎年どっさり入ってきて
> 優秀な人を薄給でこき使うだけこき使って
> 術者をボロ雑巾のように捨てていくｹﾞﾑ業界の人からみたら
まことしやかに言われているけど、これってどうかなぁ。プログラマの
扱いが酷い会社があるのはゲーム業界に限らないし、逆にきちんと
人を育てようという会社はゲーム業界にも存在はする。

私は業界全体を見渡して比較できるほどのサンプルは持ってないので、
これ以上はなんともいえないけど。Delギコ氏は、もう少し詳しいデータ
持ってます？

ﾅﾝﾃﾞ ｳﾘｺﾄﾊﾞﾆ ｶｲｺﾄﾊﾞ ﾃﾞ
　ｹﾞﾝﾐﾂﾅ ﾃﾞｰﾀﾆ ﾓﾄﾂﾞｲﾀ ﾊﾂｹﾞﾝｦ ﾓﾄﾒﾗﾚﾅｯｷｬ イカンノよ
　　　　∧ ∧
　　　　(#ﾟДﾟ) 　FF作るたびに一人氏ぬって聞きますね。
　　　　/　　| 　　実際、ちょっと遠い知人のゲムプログラマが半年前逝ってしまいましたね。
　　〜'( UUﾉ　　 ｹﾞﾑではないけど普通のﾌﾟﾛｸﾞﾗﾏもｳﾂｰな人を知ってますね。

>>231噛み付くなら、折れじゃなくて
まず>>228に言えば？

もう、コノスレ、発言もすくないので、去りまする。


ゲム会社の面接に行ったことはあるけど
体躯会計のノリと徹夜徹夜を要求されそうな雰囲気は
ﾋｼﾋｼつたわったよ。

新人にグループ組ませて
ネットワークゲームを20日間で(つまり4月入社の新人に納期4月20日まで)
作成させるという教育方針は、引いたね。
中にはｷｰﾎﾞﾄﾞ触った事ない新人もいるのに20日で作らせるんだって。
(どんなﾈﾄﾜｸｹﾞでもよいから企画からやらせるそうな)

「それについてこられる？」って言われて
だるそうだから、嫌だなあ光線を面接官に浴びせたんだけど
でも、採用って言われたので、ﾀﾌﾞﾝ使い捨てだろうな。。と想定。

あー、こうやって労働者に労働基準法違反を強要して
人の人生を食いつぶして人を心の病に陥れて企業は生きていくのね。

って思ったよ、十数社まわって、そんなキティぶりを発揮してくれたのは
ゲーム系に関わっている数社でした。

>>232
別に、喧嘩売ったつもりは無いんだけどなぁ。

Delギコ氏、もしかしてお疲れ？

　　　　　　　　　　∧_∧　　　　そうみたい。(お疲れ)
　　　　　　　　　　(*ﾟДﾟ) 　　　本当にごめん。>>233
　　　　　　　　　　/　｜ 　　　　ﾓｳｼﾜｹﾆｬｲ
　　　　　　,, ,,,, 　（＿,ﾉ　,,, ,　,,
　　　　　　　　　　ノ ,,

2chで、よこからちらほら見ていると
ゲーム業界はやっぱりキツイみたい。

成果物の技術度、完成度の高さ(ゲームにバグないもんね)
には憧れるのだけど

それに比べて労働時間や待遇が
2chなどで、よこから見ていて可哀相。

XPのペアプログラミング並のサボれない気合入れ高速コーディングを
常に週60〜80時間実践しているような気がしなくもないです。

他山の石が、羨ましくないっていうのは
相当に酷いような気がする。



業務屋はこの業界では幸せな方ですね。
コンサル屋は、幸せ通り越してねたましいくらい
稼いでいる気がしなくもないですが。

ま。会社や環境によるのかな。
コンサルでも仕事きつくて辞める人多いらしいし

ところで、Delギコスレでも言ったのですが

今月号のTechB-ingに
青色LED開発者の中村さんのインタビューが
載ってました。(有名な話しってます？)

技術者の心意気を感じさせてくれる
実に尊敬に値する人物だと感じました。

技術者として読んでおいて損はないのでオススメします。
少pageだから立ち読みでよいよ。

￣￣￣∨￣￣￣￣￣
　　　 ∧∧　ﾌﾟﾊｰ
　　　(,, ﾟДﾟ) =3　＜　生理前はイライラするよねー。
　　　/つ日 　　　　　　参った参った。
　〜（＿♂_)
　　　ﾁﾝｺ ﾂｲﾃﾙｹﾄﾞ

優秀かどうかは知らないけど
オレも「ボロ雑巾」扱いされたな。
あの屈辱は死ぬまで忘れないぞ、
で、ここまで来ました

　　 ∧ ∧
　 ﾐ,,･Д･ﾐ 　228はマルチポストだよ〜（情報システム板でもにたよなのみた）
ξﾐ ,,ｕ且ﾐ　

>>227
>たとえば、私のすぐ隣に、そういう論文を書いている方がいらっしゃいます。
>画期的なのだそうです。^^)

その研究結果が、僕たちのような一般人が理解できるような形で
公開されて、誰でも読めるようになればいいのですけど。

>私は、ひとつには「バグはどういうときに出るのか」や「どうすれば減らせるのか」
>を考えてみたいのです。求めているのは「統計的な手法」ではありません。

そうですね。統計的手法は、あくまでも、結果を判断する手法に
すぎませんからね。
テストというものは、
・想定される正常パターンが正常に動く
・想定される異常パターンが正しく処理される
ことを確認するにすぎません。

それまでに、一度も話しに出てこなかった「暗黙の常識（ビジネスロジック）」
に対応できてなかったり、想定していなかった異常パターンに対処できなかったり
して、それが「バグ」と呼ばれたりします。

あ、なんか話が違う方向にいっちゃいましたね。

>>234
＞他山の石が、羨ましくないっていうのは

　∧ ∧　 　／ 烈しくことわざまちがってる！！！
　(,,ﾟДﾟ)　＜
　 |つ つ　　＼ 本当はなんていうんでしたっけ。
＠|　　| 　　　　隣の芝生は青いだっけ？
　 ∪∪ ﾊｽﾞｶｼ

ﾑｼｼﾃ ｸﾚｲ

えーと、地雷かもしれませんが、228さんは文面から判断すると、自分が
ゲームPGというわけでもなさそうですよね。（学校の話も妙にリアルだし？）
まあ、それはそれということで。
（5年さん、>>237のコメントありがとうございます。）

しかし、ゲームPGさんは、業務系のPGさんと、そんなに違うものなのでしょうか？

>>230
そうなのですか。情報ありがとうございます。
XP-MLの登録画面とかはXPのページからたどれるものでしょうか？
（MLってやったことがないのです。）

>>236
コメントありがとうございます。
軽々しくものは言えませんが、お互い、がんばりましょう。^^)

>>238
>その研究結果が、僕たちのような一般人が理解できるような形で
>公開されて、誰でも読めるようになればいいのですけど。
私の推定では、理解できているのはご本人だけのようです。m(__)m

>それまでに、一度も話しに出てこなかった「暗黙の常識（ビジネスロジック）」
>に対応できてなかったり、想定していなかった異常パターンに対処できなかったり
>して、それが「バグ」と呼ばれたりします。
なるほど、です。
すぐに解決策を提案するほど、私は賢くない（愚かでない）のですが、こういう
ことが頻繁に起こるなら、これについても「いい方法」を考えてみたいですね。
前に「PG/SEは業務に通じているべき」という話があって、よくわからなかったの
ですが、そういうことなのでしょうか。
>あ、なんか話が違う方向にいっちゃいましたね。
迷える子羊をお導きください。方向はどちらでも。^^;)

>>239
最近、「人間はどうなれば幸せなんだろう」と思うことがよくあります。年ですね。
スレ違い、すみません。

今日は、特に書き込みはなかったようですね。
>>240 自己レス
>しかし、ゲームPGさんは、業務系のPGさんと、そんなに違うものなのでしょうか？
「ゲームプログラマがＮＯ．１」というスレがものすごく盛況ですね。
そちらを見ることにします。

みなさま。
毎日、このスレを見ているのですが、どうも書き込みもなくなり、もしかすると
その「役割」も終わったのかなと思う日々です。
唐突な気もいたしますが、また、これまでかなりのハイペースであったかなと
も思います。

単なる小休止であってまた復活するのかもしれないので、お別れの言葉を
書くのはためらいます。
とは言え、ここまでについて、お礼を申し上げておきたいと思います。

いろいろ教えてくださり、本当に、ありがとうございました。

またいろいろバカな質問をさせていただくこともあると思います。
どうか、今後とも、よろしくお願いいたします。

話題希望age

定期age

凄いと言われるようなプロの具体的なテクニックを見せてみろ！
本当はそんなもん何もないんだろ？(藁

>>245
ここは、そういうスレッドじゃないし。

とりあえず WRITING SOLD CODE は読んだことある？

>>246
SOLD じゃなくて SOLID だ。鬱氏。

>>246
本の紹介をしろなんて一言も言ってないぞゴルァ！

>>248
具体的なテクニックを見たかったんでしょ？　あの本には、昔の MS で、実際に
使われていた具体的なテクニックが紹介されてるぞ。

「ライティング　ソリッド　コード」 ISBN4-7561-0364-2
http://www02.so-net.ne.jp/~yshibata/bookshelf/books/1-55615-551-4.html

短絡的な245を晒しage

いや、そういうことをするとヤツの術中にはまるから
放置プレイがよさそうでsage

age

あげ

agattenaiyo

まだ、ときどき書き込みがありますね。（よかったです。^^）

私はXPのピンクの本読んでます。おもしろいです。
ライティング　ソリッド　コードは読んでみたいのですが、まだちょっと時間が．．．
リファクタリングというのもおもしろそうですね。

もう少し勉強してから、また、質問に来たいと思ってます。

JavaScriptから文字を送信し、Parlのスクリプトで受けた場合、
InternetExplor4.0以降のバージョンで文字化けするのですが
回避策はありますか？
知っておられる方、教えてください。
よろしくお願いします。

>>257
送信してる文字コードは？

というかWebプロ板のほうが･･･

>>256
霧盤だ。

XPのピンク本買っかたけどまだ読んでません(w
Writting Solid codeは良いですが、チト古い部分ありです。
リファクタリングはお勧めです。いいです、これ。

JavaScriptもユニコードなのかねえ。

すみません。聞いた話なので実際の文字コードはわかりかねるのですが、
内部的にはユニコードで送信しているそうです。
あるWebPageにMicrosoftのIEではJavaScriptの動作は保証されて
おらずVBスクリプトを推奨していると書かれていたのですが・・・
ユニコードで送信されると何がまずいのでしょうか？

>>261
http://member.nifty.ne.jp/hippo2000/perltips/Unicode/MapUTF8.htm
このへんでどーよ？

どうもありがとうございます。早速読んでみます。
そのほか、何か情報ありましたらよろしくお願いします。
本当にResが早くて助かります。

てゆーかgoogleでperl Unicodeで検索一発だ。
自分で調べなさいよ。

今回は興味あったから俺も調べたけど。

読んでみました。
つまりこういうことでしょうか？
JavaScript内では、どのような文字コードで送信したものも
UTF8として送信されてしまい、それを受けるときはdecode
処理が必要である。それを提供しているのがUnicode::MapUTF8
である。
私の解釈が合っているのか自信がありませんので回答いただけ
ますでしょうか？
よろしくお願いします。
ちなみにUnicode::MapUTF8は最新のPerlを入れれば使えるもの
なのでしょうか？それとも追加でインストールを要するものなの
でしょうか？

Javaサーブレットでは死ぬほどｶﾞｲｼｭﾂ　＞文字化け。

>>265
自分で調べるか、実験してみれば？

というか、何でJavaScriptで送信しなきゃだめなの？
普通にformでいいんじゃないの？

ぉぃぉぃ。
本当にJavaScriptで送信してるのか？
XMLHTTPなんかのCOMを使えば送れるけど。（つーかJScriptだな、これは）

普通は、送信される文字コードはブラウザ（クライアントアプリ）依存。
Shift_JISでもeuc-jpでも送信される可能性がある。

受け取った文字列のエンコードを推定して、サーバアプリの
内部コードに変換するのが常套手段。
Perlは詳しくないけど、kconvとかjcodeとかいうのが無いか？

>>261
>あるWebPageにMicrosoftのIEではJavaScriptの動作は保証されて
>おらずVBスクリプトを推奨していると書かれていたのですが・・・

そのイカサマページのURLを晒したまへ。

jcode.pmを組み込んで使え。
以上。

>>257
ひょっとして、URLに付けるパラメータ(http://hoge?a=xxx)のxxxを日本語にして
JavaScriptでopen()してるんですか？
だったらそれはまずいです。
最低、日本語を何らかの形にエンコードして送信しなければなりません。

JavaScriptにはescape()という関数が用意されてるんですが、これには問題が
あります。
Perlで、JavaScriptのescape()したものをデコードできればいいんですが、
escape()はRFCに準拠していないので、駄目かもしれません。

やはり、formで渡すのが確実かと。

あげとくか

もちage

で、なんのはなしだ？

てｓｔ

sage

なんかなつかしーな。