5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

コボラは横長DBがお好き

1 :おめこ:2006/10/13(金) 22:19:44
コボラは外部キーを横長(XXコード1、XXコード2などを列で持たせる)に持つ習性がある。
35〜45くらいの人がDB設計するとそうなるよな。RDB台無し。

このスレはそんな馬鹿コボラの目を覚まさせてあげようという、
ちょっとしたボランティア。

チョボラ。


2 :おめこ:2006/10/13(金) 22:21:31
ていうか、35〜45でDB設計なんかしてんなよ。
出世汁!!ボケって感じだけど。


3 :仕様書無しさん:2006/10/13(金) 22:43:47
この業界、現場でやっと使い物になるようになった奴を
現場から追い出すよな。

4 :仕様書無しさん:2006/10/14(土) 00:03:53
使い物になるようになった奴は追い出さないよ。
使い物にならなかった奴が追い出される『場合がある』だけちゃいますか?

5 :仕様書無しさん :2006/10/14(土) 01:53:33
ひよっこが生意気いっとるな

コーダ卒業してからスレ立てろや

6 :仕様書無しさん:2006/10/14(土) 02:28:03
コボラーがオープン系でやっていいのはVBのコーディングだけ。

7 :仕様書無しさん:2006/10/14(土) 02:35:24
最近、ビジネスロジックだけをコボルとかジェイシーエル?で
書けるようなJava/.NETのフレームワーク作れば一儲けできるような気がしてきた。
プログラムの再利用性の次は人材の再利用性ですよ?

8 :仕様書無しさん:2006/10/18(水) 21:34:45
おめコボラ

9 :仕様書無しさん:2006/10/18(水) 21:52:01
異次元コボラ

10 :仕様書無しさん:2006/10/18(水) 22:12:19
俺は35だがRDB+WEBから入ったのでコボラは大嫌い。

11 :仕様書無しさん:2006/10/19(木) 01:41:31
>>7
臓器以外に再利用できるものがない

12 :仕様書無しさん:2006/10/19(木) 12:50:39
>>11
あんなヤニ臭いモノが使い物になるのか?

13 :仕様書無しさん:2006/10/19(木) 23:16:14
こぼらは『リレーション』を理解できないらしい。

14 :仕様書無しさん:2006/10/19(木) 23:18:26
PLに出世したてのコボラが仕切ってるプロジェクトはマジ危ない。


15 :仕様書無しさん:2006/10/20(金) 23:54:08
コボラー含有率30%以上の開発は火を噴く。よってコボラーは可燃性物質であると認められる。

16 :仕様書無しさん:2006/10/21(土) 00:40:35
その30%の中は1%は放射性同位体だ。
それがあると、核爆発になる。

17 :仕様書無しさん:2006/10/21(土) 00:49:11
横長デブってなに?

18 :仕様書無しさん:2006/10/21(土) 01:00:02
デブは縦よりも横に長いと飛鳥時代から決まってる。

19 :仕様書無しさん:2006/10/21(土) 02:19:52
>>16
そんでもって、プロジェクトはβ崩壊

20 :仕様書無しさん:2006/10/21(土) 13:47:45
>>19
そして被爆した(まちがった手法を覚えた)新人が他プロジェクトへ飛散して
そこも、被爆する。

21 :非核3原則:2006/10/21(土) 13:51:54
1.コボラを雇わない(持たない)
2.コボラに新人を育てさせない(作らない)
3.コボラに仕事を依頼しない(持ち込ませない)

22 :仕様書無しさん:2006/10/21(土) 18:57:39
早い話がコボルすら読めない自称スーパープログラマが吠えるスレ
でいいのか?
こんなこと書くと高確立で

コボラ乙


って言われんだろうけど

23 :仕様書無しさん:2006/10/21(土) 19:57:30
そっか使い物にならんコボラーでもコボルは読めるんだ。目から鱗。











いやだから汎用機に張り付いてりゃ誰も文句いわんて。

24 :仕様書無しさん:2006/10/22(日) 01:41:08
>>20
つまり、汎用機はCOBOLerをさらに増やすための高速増殖炉だということか?

25 :仕様書無しさん:2006/10/22(日) 01:54:29
コボラーとコラボレーション

26 :仕様書無しさん:2006/10/22(日) 02:24:55
コボラーにボコラーれた〜

27 :仕様書無しさん:2006/10/22(日) 06:23:14
>>1
あ、そーか。横長の原因はそれだったんだ。
もーね。Oracle でね。カラムが1000超えて表作る時にエラー出るから
ってんで表を分けたんだけどね、元の設計がそんな感じだったからさ、
COBOLer ってことね。たしかに作ったのは40代のやつだ。俺も40代
だけどさ。俺は COBOL は全然やったことなくてわからない。


28 :仕様書無しさん:2006/10/22(日) 07:25:45
そういえば10年ほど前、コボラーSEがACCESSが項目を256個しかもてないとか言って馬鹿にしてたな。
あの頃のオープンの業務系はコボラーSEと新米PGとでシステム作ってた。
今から考えると恐ろしいよw












でも・・・この業界には・・・未だにそういう開発が・・・存在する・・・

29 :仕様書無しさん:2006/10/23(月) 21:52:45
>>27
そうですよ。
コボラの脳味噌にはリレーションという概念がないのです。

そのため、入力できる明細数が固定だったりする。
『これ1個増やして』っていわれると結構手間だったりする。
縦にしておくと何の変更も要らないネ!

こういう仕様変更で金とるコボラは屑。

30 :仕様書無しさん:2006/10/23(月) 22:18:01
419 名前:仕様書無しさん[sage] 投稿日:2006/10/22(日) 01:35:48
create table hoge_geppou(
year char(4),
month char(2),
day1 number(3),
day2 number(3),

day31 number(3)
)

引継ぎに来た中国人が原抱えて笑ってた。


31 :仕様書無しさん:2006/10/23(月) 22:36:52
そうそうコレなんだよ。
コレがコボル病。
YMDをKeyにして1日1レコードが素敵。な場合が多い。


32 :仕様書無しさん:2006/10/23(月) 22:38:38
NUMBER(2) ではなく NUMBER(3) というとこもコボル病。
コボル病患者はやたら、予備を取りたがる。
列名 YOBI1,YOBI2 ... なんてのを見たことがある。
飯噴。

33 :仕様書無しさん:2006/10/23(月) 22:39:41
>>32
あ、そういうわけでもないかも。ね。


34 :仕様書無しさん:2006/10/23(月) 23:00:33
>>30
とても笑えないよ。こういうのに何度出くわしたことか。これから何度出くわすことか・・・

35 :69式フリーPG ◆hND3Lufios :2006/10/23(月) 23:01:03
おれなんか24個並んでるのを見たことあるぜ。しかもnot nullがついてなくて、
JDBC側から投げるSQLにNVLが24個並んでるの。

36 :仕様書無しさん:2006/10/23(月) 23:08:30
まぁ、何らかの値ならまだ増し。
外部キーを横に20個とか平気でやるよ奴ら。
で、
同じマスタを20回ジョイン OR
フロントで行数×20回LOOPでSELECT
最低なコーディングだが、その元凶はコボル病なのだ。



37 :仕様書無しさん:2006/10/24(火) 22:23:02
>早い話がコボルすら読めない自称スーパープログラマが吠えるスレ
>でいいのか?

『RDBを理解できないコボラを見下すスレ』

>こんなこと書くと高確立で

高確じゃなくて確定。

コボラ乙




38 :なぎさっち ◆Nagi/FmYMM :2006/10/25(水) 10:55:15
>22
確立してどうする。

39 :仕様書無しさん:2006/10/26(木) 02:45:03
横に256個以上カラムが定義できないと伝えると、烈火の如くRDB批判を繰り返すCOBOLer

256個以上の使用目的は、購入履歴001〜購入履歴999まで作りたかっただけ。

40 :仕様書無しさん:2006/10/26(木) 03:44:11
>>38
勃立でどう?

41 :仕様書無しさん:2006/10/26(木) 06:39:17
>>39
そりゃRDBって言うよりaccessの制限じゃねーか?
DB2だと4000個くらいカラム定義できたと思うが。
もっとも4000項目もINSERT INTO ・・・・なんてSQL書きたくないが

42 :仕様書無しさん:2006/10/26(木) 07:11:18
佐藤支ね

43 :なぎさっち ◆Nagi/FmYMM :2006/10/26(木) 13:06:06
>40
677  仕様書無しさん sage Date:2006/10/25(水) 21:35:28
>>670
つ疲れマラ


44 :仕様書無しさん:2006/10/26(木) 15:40:47
さなぎっち(;´Д`)ハァハァ

45 :仕様書無しさん:2006/10/26(木) 22:14:51
>>39
縦推奨。

46 :仕様書無しさん:2006/10/26(木) 23:55:54
それはまぎれも無く奴


47 :334:2006/10/27(金) 00:53:35
Oracleで何で横長DBにするのか?
コボラの意見聞きたいわ。

なんで?


48 :仕様書無しさん:2006/10/27(金) 01:03:27
>>47
どこの>>334だよw

49 :仕様書無しさん:2006/10/27(金) 01:23:10
_')対応checkは存在したのですか。大丈夫だったですか。

50 :仕様書無しさん:2006/10/27(金) 01:31:02
Rらいと

51 :仕様書無しさん:2006/10/27(金) 02:21:34
>>334
そういう設計が正しいとされる世界の住人だったから。

52 :仕様書無しさん:2006/10/27(金) 12:27:43
ここまでに「正規化」という単語が出てきていない件

53 :仕様書無しさん:2006/10/27(金) 21:20:22
>>52
性 器 化 で す か ?

54 :仕様書無しさん:2006/10/28(土) 05:45:04
>>52
リレーションという概念のない人にそんな言葉が通じるわけが

55 :仕様書無しさん:2006/11/06(月) 22:54:19
あげ

56 :仕様書無しさん:2006/11/07(火) 19:27:56
素で聞くが、縦とか横とか言っている意味から分からん。
>39の言ってることは分かる。そりゃバカなことだと分かる。

そんだけのことか?

57 :仕様書無しさん:2006/11/08(水) 00:45:55
>>56
藻前がアフォーなだけ。

58 :仕様書無しさん:2006/11/08(水) 02:21:56
>>56
RDBの表のカラム数だよ。
10や20ならまだいい。Oracle の限界の 1024 を超えるようなものをお前は許せるか? 人として。


59 :仕様書無しさん:2006/11/08(水) 10:00:23
>>58
×人として
○PGSEは人に非ず

60 :仕様書無しさん:2006/11/08(水) 10:13:24
>>57
>39の例で言えば
 1つのデータレコードに対して可変的に累積される項目データについて、
 レコードに対して逐次項目増として対応するのが終わっている。

と取れるし同意するのだが、>1の書いていることは別のことに見えるんだよ。

>>58
オレの常識でも許せんよ。ド馬鹿か狂気を含む天才だな。それ。

61 :仕様書無しさん:2006/11/08(水) 13:21:36
こぼらにテーブルを設計させると、必ずといっていいほど
FILLER
とかいう列がある

62 :仕様書無しさん:2006/11/08(水) 16:38:06
>>60

>>1
>横長(XXコード1、XXコード2などを列で持たせる)に持つ

>>39
>購入履歴001〜購入履歴999まで作りたかった

そんなに違う事は書いてないようだが。

63 :仕様書無しさん:2006/11/08(水) 16:51:23
>>62
>横長(XXコード1、XXコード2などを列で持たせる)に持つ

項目数が多かろうが少なかろうが、固定的か可変的かで全然意味が違う罠。
ケータイの着信履歴は最大30件〜みたいな仕様だったら、横でいいだろ。

64 :仕様書無しさん:2006/11/08(水) 18:01:06
>>63
その着信履歴を番号ごとや時間帯ごとに件数だしてくれって言われたらどうする?
日時の逆順にソートしてくれって言われたらどうする?

65 :仕様書無しさん:2006/11/08(水) 20:04:38
>>64
そう言われたら作り直してがっつり工数稼ぐ算段じゃね?



まあ工数分の金が出るかは別として

66 :仕様書無しさん:2006/11/08(水) 20:35:27
>>64
今のケータイだったらあり得ん要求だろうが、その場合そもそもDBなんか(ry

まあぽまいら、答えは ケース バイ ケース って分かってんでしょ?


>>65
ケータイの場合は死者が出そうだなw

67 :仕様書無しさん:2006/11/08(水) 21:20:47
横持ちとは関係ないけどフィールド名をF010〜F220という風にするって
ワガママ言ってるんですがどうすればわかってくれるのか・・・
ちゃんと名前付けてほしいのと、増えたら間に入れるというのに危険を感じる。
当然ながら項目内容も横持ち&なぞの多い複合キーだらけです。

68 :仕様書無しさん:2006/11/08(水) 22:14:42
>>63
市ね。

固定かどうかじゃなくて、データの意味を考えろ。

69 :仕様書無しさん:2006/11/08(水) 22:24:21
カラムは1024で終わりかもしれんが
char(256)で、1カラム中を固定長フラグ項目で埋めるという技も併用してくるぞ

70 :仕様書無しさん:2006/11/08(水) 22:38:30
ワロタ

71 :仕様書無しさん:2006/11/08(水) 22:48:21
>>69
おる!!
そういう奴。


72 :仕様書無しさん:2006/11/08(水) 22:50:07
まったく敵はいろんな手を使ってくるな・・・
そういう敵を打ち負かすにはスキルだけでなく理論武装もしとかないとな。

いかに相手のテーブル設計&テーブル設計能力がダメか分からせてやらんといかん。

73 :仕様書無しさん:2006/11/09(木) 01:22:34
>>69
まじか!
そこまですごいのは見たことねえ。上には上がいるんだなあ。


74 :仕様書無しさん:2006/11/09(木) 02:42:18
こぼらは、先天的な脳疾患を抱えている可愛そうな人たち
だから許してやろうよ。




 許せるか!あほコボラw

75 :仕様書無しさん:2006/11/09(木) 03:08:15
あ、そうか。だからなんでもまっすぐに配置したがるわけだ・・・。

76 :仕様書無しさん:2006/11/09(木) 08:04:43
>>63
新しい着信履歴をどの列に入れるかでアプリ側でごちゃごちゃ処理が入るし、
古い着信履歴を削除する場合にもいろいろやらなくちゃならん。

コボラーはそんな処理アプリでやって当然じゃんとか思ってるのかもしれんが。

77 :仕様書無しさん:2006/11/09(木) 09:37:07
>>76
色々処理って・・・これくらいでどこまでコストかけるんだよ
心太で十分じゃん

78 :仕様書無しさん:2006/11/09(木) 09:40:07
で、1行になんでもつめこんで、「速くなった。チューンした。」
とかいいだすんだよな。



79 :仕様書無しさん:2006/11/09(木) 10:17:45
クイズ 世界はケースバイケース

司会はIt's Me こと逸見政孝でお送りいたします。

80 :仕様書無しさん:2006/11/09(木) 15:18:37
>>78
おまえかっ!!もっさりケータイをリリースしやがるのは!?

81 :仕様書無しさん:2006/11/09(木) 16:36:52
最近のケータイにはRDBが搭載されているのか・・・すごいな・・・

82 :仕様書無しさん:2006/11/09(木) 22:25:17
ええことを考えた。

職場におるコボラにここのURL送れ!!
つーか、漏れは送ったった!! ww

83 :仕様書無しさん:2006/11/09(木) 22:42:10
>>82
やつらはそのくらいじゃへこたれんよ。

84 :69式フリーPG ◆hND3Lufios :2006/11/09(木) 23:05:48
おいらさ、引数指定レコードのフィールドをずらすストアドをPL/SQLで
書いてあげたことあるよ。用途は言うまでも無い。

85 :仕様書無しさん:2006/11/09(木) 23:11:33
>>84
それ公開しろよwwww

86 :仕様書無しさん:2006/11/09(木) 23:30:45
http://upld.dip.jp/3d_adult/src/1162044232694.jpg

87 :仕様書無しさん:2006/11/10(金) 00:20:43
>>86
不覚にも保存した。

88 :仕様書無しさん:2006/11/10(金) 00:57:12
>>http://upld.dip.jp/3d_adult/src/1162044232694.jpg
異様にかわいい。

89 :仕様書無しさん:2006/11/10(金) 00:58:25
1000万出してもいいからこの娘のマンコ舐めたいやつ手ぇ上げろ!!

90 :仕様書無しさん:2006/11/10(金) 21:00:03
>>89
娘じゃないかもよ

91 :仕様書無しさん:2006/11/10(金) 21:51:00
え?
どゆこと?

92 :仕様書無しさん:2006/11/11(土) 00:01:31
遅無歩がついてる

93 :仕様書無しさん:2006/11/11(土) 09:09:57
遅無歩?
ついててもええわ w


94 :仕様書無しさん:2006/11/12(日) 18:17:46
コボラって負け組?


95 :仕様書無しさん:2006/11/12(日) 21:34:25
ヤック デカルチャー

96 :仕様書無しさん:2006/11/14(火) 20:40:35
コボラ=NEET?

97 :仕様書無しさん:2006/11/16(木) 03:23:12
設計がいまいちで縦長過ぎるのもまた大変だったりして。
SQL文が異様に長くなっちゃったりして。

ていうか、なった。
やっぱ view やストアドプロシジャ作るべきか・・・。


98 :仕様書無しさん:2006/11/16(木) 03:37:51
>縦長過ぎる
レコード数が多いってことか?そんなことで「また大変だったりして」だとか、
「SQL文が異様に長くなっちゃったりして」にはならんと思うがw

99 :仕様書無しさん:2006/11/16(木) 14:50:47
今のトレンドは斜め

100 :仕様書無しさん:2006/11/16(木) 18:55:38
>>99
弊社のタコはAccessで表計算らしきことをしてた。
レコードをみると「斜め」だった。

101 :仕様書無しさん:2006/11/16(木) 19:27:55
器用ダナw

102 :仕様書無しさん:2006/11/16(木) 20:44:57
>>101
縦横に空白と見出しが並んでるんだぞw
まさにエクセル。

103 :仕様書無しさん:2006/11/16(木) 22:02:44
斜めってどういう状態???

104 :仕様書無しさん:2006/11/16(木) 22:13:18
>>98
「正規化し過ぎて」って事なんだろうな。

105 :仕様書無しさん:2006/11/17(金) 01:14:46
結局逐次JOINするぐらいなら横長でもOKと言いたくなる
ま正規化のやり方が間違ってるわけだがな
誰だよこんなアホなDB設計した香具師は

106 :仕様書無しさん:2006/11/20(月) 22:46:06
DB(デブ)は横長にきまっとるがな。

107 :仕様書無しさん:2006/11/21(火) 10:30:47
とりあえず質量があればどうにでも整形できる。

108 :仕様書無しさん:2006/11/23(木) 17:28:46
俺の先輩は、影でオッカーズと呼ばれ、恐れられている
大事な打ち合わせでは、呼ばないようにしている

109 :仕様書無しさん:2006/11/23(木) 21:51:40
>>オッカーズ

どういう意味?

110 :仕様書無しさん:2006/11/23(木) 22:41:24
何でも夜のおかずにする人かな?

111 :仕様書無しさん:2006/11/23(木) 23:35:42
COBOLのOCCURSだろ?
いわゆる配列と思えばいい。
RDB定義体でOCCURS指定すると、第一正規形を崩すからな。

でも、OCCURSならまだいいよ。
MEMO1〜MEMO999なんてカラム作られて、
MEMO675, MEMO675, MEMO676
なんてやられた日には殺意覚えるからな。

112 :仕様書無しさん:2006/11/23(木) 23:38:11
素朴な疑問。
何でコボラは横長にしたがるの?

113 :仕様書無しさん:2006/11/23(木) 23:41:41
JOINなんて面倒じゃん。ビシッと一列に揃えたほうが気持ちいいし。

114 :仕様書無しさん:2006/11/24(金) 00:20:31
>>112
データ読み出し方法の違い
前世代とRDB世代だと、そゆところの感覚が違う。

てか縦とか横とか言うのか、行と列って言ってた。orz

115 :仕様書無しさん:2006/11/24(金) 01:28:17
>>114
リアルで縦横言ってると思うかい?


116 :仕様書無しさん:2006/11/24(金) 20:57:05
周りの人は「縦持ち」「横持ち」ゆーとった

117 :仕様書無しさん:2006/11/24(金) 21:39:14
>>111
テストデータとしてこんなのを入れておくと良いだろう。

#!/usr/bin/perl
open(F, "| sqlplus -S /nolog") or die;
print F "conn hoge/fuga\n";
for ($i = 0; $i < 1000000; ++$i) {
 print F 'insert into hoge (' . join(",\n", map {"MEMO$_"} 1..999) . ')'
   . 'values (' . join(",\n", map {"'($i,$_) 馬鹿野郎!'"} 1..999) . ");\n";
}
print F "quit\n";


118 :仕様書無しさん:2006/11/24(金) 22:56:10
>>114
列=横
行=縦

ていうか、お前、コボラ?

119 :仕様書無しさん:2006/11/24(金) 22:57:17
連結って概念が無いんだろ。

120 :仕様書無しさん:2006/11/24(金) 23:08:55
>>114
まぁ、
ダブルクリック=叩く
CPU=石

みたいなもんだろ


121 :仕様書無しさん:2006/11/24(金) 23:09:39
>>113
>>JOINなんて面倒じゃん。ビシッと一列に揃えたほうが気持ちいいし。
おまえきしょい。

122 :仕様書無しさん:2006/11/24(金) 23:43:08
コボラをIT業界から追放しよう。
どうすればいい?

123 :仕様書無しさん:2006/11/24(金) 23:58:01
>>122
コボラを追放するなんてとんでもない。
彼等は最近のPGがやりたがらない退屈な仕事を片付けてくれる。
要は巣から出さなければいいんだ。

どっちかっちゅーと、VB厨の方が...。

124 :仕様書無しさん:2006/11/25(土) 00:00:22
あ、なるほどね。

コボラは出世など考えずに、コボルだけやってればええってこった。

VB厨はまだ更正がきくかも。

125 :仕様書無しさん:2006/11/25(土) 00:18:17
>VB厨はまだ更正がきくかも。

効くわけねーだろハゲ

126 :仕様書無しさん:2006/11/25(土) 11:22:48
そういえば
「DBアクセスはテーブルのみヴューは使わない」
ってルールのフレームワーク作ってた会社があったな

JOINするという理由で難易度があがるという

127 :仕様書無しさん:2006/11/25(土) 11:58:54
>>118
正面切った解説に正直おどろいています


128 :仕様書無しさん:2006/11/25(土) 13:37:10
>>124
>VB厨はまだ更正がきくかも。
彼等にはポリシーすら無い。
それこそIT業界から追い出すべきだ。


129 :仕様書無しさん:2006/11/25(土) 19:10:23
MSが.NETをあきらめない限り、今後VB6での開発ではなく、C#同様にJavaもどきの
VB.NETを使うことになるので、VB厨はJava厨に吸収されていくのではないだろうか。

130 :仕様書無しさん:2006/11/25(土) 19:29:46
コボラってテーブルを結合しないの?

131 :仕様書無しさん:2006/11/25(土) 19:34:19
>>129
VB.NETはダメだよ。
色々とキモいから。

132 :仕様書無しさん:2006/11/26(日) 00:34:36
>>130
テーブルを分ければ分けるほどプログラム作成工数が増大するらしいよ。

133 :仕様書無しさん:2006/11/26(日) 02:48:11
>>130
>>126

134 :仕様書無しさん:2006/11/26(日) 03:25:43
>>132
ほんとかなあ。

135 :仕様書無しさん:2006/11/26(日) 07:16:51
ステップ数で単価を換算するCOBOLerにはいい儲け話じゃないか?

つか、再利用できるモジュールや関数を作る、作らないは
プログラマーの技量であってテーブルの分割とは関係ないな。

まー、VB厨も上から下まで一直線で同じ処理はコピペで済ます
芸風があるから、その辺りはどっちもどっちだな。

136 :仕様書無しさん:2006/11/26(日) 20:03:03
>>132
コボル厨

137 :仕様書無しさん:2006/11/26(日) 22:17:24
>>136
コ、コボル厨ちゃうわ!

マジレスすると、自分のやり方が正しいと信じているコボラーSEを言い負かすには、
ある程度連中のやり方をしっとかないと。
「なぜ第一正規形にしないんですか」とか連中のしらん用語を使うのも効果有り。

138 :仕様書無しさん:2006/11/26(日) 22:36:44
>>137
コボラ語(コボルではなく)を学んでおくのは良いことだよな。
傾向と対策つか「こうきたらこう叩け」みたいな。
やつらの生態を知らないと、斜め上の発想に圧倒されてそのまま通す羽目になってしまう。


139 :仕様書無しさん:2006/11/26(日) 23:32:02
>>138
彼らは完成されてるからね。我々より。斜め上の方向にw。なかなか手強い。

140 :仕様書無しさん:2006/11/27(月) 09:17:24
迷うところがないというのは強いよね。
こちらが間違ってるんじゃないかという気になる。

141 :136:2006/11/27(月) 21:24:51
>>137
そうやったんか。すまん。
なるほどな。

やつらに言わせると『テーブルを分ければ分けるほどプログラム作成工数が増大する』
ということなんやな。

142 :仕様書無しさん:2006/11/27(月) 21:29:53
>>138
そうやな。

『コボラの言いそうなこと』と
『それを黙らせる論理』が重要やな。

一応、年上だから立てておいて、
技術者としては終わってることをわからせる。
怒らせてもつまらんしな。

本当は、自分で勝手に限界を感じて、
ローソンにでも転職してくれるのが一番ええけど。

143 :仕様書無しさん:2006/11/27(月) 23:38:27
>>134
本当。

何でもかんでもUNLOADしてFILEで扱いたがるから。
WHERE文入れてJOINしようとしても絞らずに結合してしまう
RDBMSが糞という話もあるのだが。

144 :仕様書無しさん:2006/11/29(水) 01:00:29
こどもの顔を3日ぶりに見ることができた
ぼろぼろの状態の俺
るいせんが、ゆるむ

145 :仕様書無しさん:2006/11/29(水) 01:18:16
こどもに頓着したい奴はこの業界に向かんぞ。
俺なんて、ほとんど子供と遊んだことない。

146 :仕様書無しさん:2006/11/29(水) 01:50:04
>>144
せつない縦だなあ

147 :仕様書無しさん:2006/11/29(水) 03:39:31
なぜここで縦w

148 :VB厨:2006/11/29(水) 03:54:00
>>129
いっそ吸収されたいぞ。いつまでVB6の開発なんてやらせられるやら。
スレ違い失礼。

ただしコボラもろとも吸収されるのはお断り。

149 :仕様書無しさん:2006/11/29(水) 03:55:39
コボラとか自称SEとかって、横長DBが大好きだよな。
○○○○ITソリューションの山本は、
100フィールド越えのDBを設計しやがったし。

あと、別プロジェクトで、全てのテーブルを「マスタ」と称してることもあったな。
顧客マスタとか、商品マスタは良いとして、「売上マスタ」って何よ?
俺が、「売上テーブル」と言ったら、「売上マスタだ!!」と烈火の如く怒り出すし。

そういうセンスの欠片もない人間は、一刻も早くこの業界から足を洗って、
実家の酒屋を継ぐべし。
もしくは、過労死すべし。


150 :仕様書無しさん:2006/11/29(水) 04:05:58
>>149
売上マスタに禿しくワロタ!

自称SEはさておき、コボラは横長テーブルマジ好きだよな。

151 :仕様書無しさん:2006/11/29(水) 09:49:38
>>150
俺としては、笑いごとじゃなかったのだが。

152 :仕様書無しさん:2006/11/29(水) 10:21:06
マスタ = Jesus → 神
売り上げ → お客様 → 神
よって、

 売り上げ = 神 = マスタ

ということではなかろうか?


とか思った徹夜明けの朝。
(もうすぐ昼だよ..)


153 :仕様書無しさん:2006/11/29(水) 10:41:16
山本マスター

154 :仕様書無しさん:2006/11/29(水) 11:41:18
マエストロ

とお呼びください。


155 :仕様書無しさん:2006/11/29(水) 15:28:02
ちなみに、ACCESSマクロで運用されていたシステムを、
SQL Serverにリプレイスするプロジェクトだった。

そのACCESSの中には、100個位の正規化されていないテーブルがあり、
処理用の「田中さん○○○○クエリ」やら、「山田さん○○○○クエリ」があった。

で、○○○○ITソリューションの山本が聞取り調査をして、
必要なテーブルを集めてきたら、売上マスタを始めとして、全部○○マスタになってた。

取りあえず、山本君も、キャリア15年を超えるのだから、マスタとはなんぞや位、
理解すべし。
もう、手遅れだろうけどね。

156 :仕様書無しさん:2006/11/29(水) 17:31:52
マスターなら喫茶店に居ます。


157 :仕様書無しさん:2006/11/29(水) 18:05:38
○○○○ITソリューションのSE(自称)の山本は、
テーブルに、インデックスを付けると全ての効率が上がると信じてる馬鹿者。

以前、SQLServerで一時テーブルを作成し、Excelファイルにエクスポートする
プログラム組んだら、「速度が遅いのはインデックス作成しないからだ。作成しろ」
とやかましく主張しやがった。
インデックス作成すると、インデックスの作成に時間がかかる上に、
新処理時にもインデックスを作成し直すから余計時間がかかると説明したが、
ヤツの頭では理解できなかったようだ。

現状のボトルネックになってるのがExcelの処理だと説明する為に、
ログ取ってやっと納得させた。

○○○○ITソリューションには、馬鹿を再教育する制度はないのか!?


158 :仕様書無しさん:2006/11/29(水) 18:20:42
VBプログラマは、ここ数年.NET Frameworkへの移行で四苦八苦してきた。
「静的型付言語」であるVisual Basic .NET(VB.NET)で従来のVBプログラマがまず叩き込まれるのは、「Option Strict On」である。
これによって、Visual Basicコンパイラが「正しい行い」をプログラマに強制する。
VBプログラマの苦痛は、VBが中途半端なニセモノプログラミング言語の汚名から解放され、真のプログラマが利用する言語へと進化するための痛みとして認識されている。
http://www.atmarkit.co.jp/fdotnet/special/pdc2005_02/pdc2005_02_01.html

@ITのVB関係の記事は、僻みか煽りか皮肉のどれかにしか見えない。

159 :仕様書無しさん:2006/11/29(水) 18:21:58
誤爆すまん。

160 :仕様書無しさん:2006/11/30(木) 23:01:44
>>147
DB設計は横じゃなくて縦だっていうコボラへの啓蒙のためじゃね?

161 :仕様書無しさん:2006/12/01(金) 00:25:53
    ./        \
   /\         .\
  ./   \         \
  │     \        |
  │ ⌒ ⌒  \       丿   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  .\・ ・    ∨∨∨∨∨ < ageちゃいますよ、課長。
    С       ∵∵∵/    \_________
   /       っ)∵ /
  .(__ノ      ∵/
     \__  __ノ
        丿 (

162 :仕様書無しさん:2006/12/02(土) 03:34:39
そんなに横長でもないのだが、マスタを作らないでそのまま入れるのはいかがなものか、
というような表をこの前見た。

まあ、いわゆる、製品番号を付けないで製品名そのまんま入れるようなものかな。
縦長の素質あり。


163 :仕様書無しさん:2006/12/02(土) 03:35:49
じゃない、横長の素質だ。w

164 :仕様書無しさん:2006/12/02(土) 03:40:55
骨太、横長で何が悪い!

165 :仕様書無しさん:2006/12/02(土) 03:50:39
美しいDB


166 :仕様書無しさん:2006/12/02(土) 08:07:39
Oracleで予算管理システムのテーブルを設計しているとき、PLのコボラーが
売上実績1、売上実績2、〜、売上実績6
みたいなカラムを延々と作るので、正規化しないと月別の集計がしにくいですよ
っつったら、
「画面も帳票も半期で閉じてるからいいんだよ!」
って烈火のごとく怒られた…

どこにでもいるんだね。RDBで横展開する年長者orz

167 :仕様書無しさん:2006/12/02(土) 09:39:37
だから、オープン系プロジェクトにコボラーを参画させてはいけないことは、
ずいぶん前から常識なんだけどな

ついうっかりコボラーが紛れ込んできたら、線表の管理に専念させろ
(してるつもりにさせろ)


168 :仕様書無しさん:2006/12/02(土) 16:40:19
会社名は言えないが、坂東さんと黒柳さんがパーフェクトを狙う
あの番組のスポンサーの会社が受注したプロジェクトで、
たしか、「工場マスタ」とかいうテーブルの主キーである「工場コード」に、
「○○工場」「△△工場」「××工場」
という値がセットされてるのを見て、こいつら駄目だと思った。

一体、おたくらのグループはどういう社員教育してるんだ!?
自前でデータベースも作って販売してるんだろ。

まぁ、あのDB、あんな程度の完成度だから、社員の質も知れてるってものかwwwww



169 :仕様書無しさん:2006/12/02(土) 17:02:00
そういや、そのデータベースのメーカーでもある会社のプロジェクトで、
第1正規化もされてない設計がされてたなぁ。

どうせ、まともに設計する気ないなら、いっそのこと、
全テーブルを非正規化しちゃえ良いのに。
上の方の技師だの主任技師だのは、馬鹿だから、
そんな設計しても、メクラ印押すんじゃないかな。

170 :仕様書無しさん:2006/12/03(日) 00:33:37
新人でJAVAの研修したのに何故か汎用の現場に回された。
コボルきらいなんだけど。

171 :仕様書無しさん:2006/12/03(日) 00:39:21
そーっすか

172 :仕様書無しさん:2006/12/03(日) 01:10:07
>>170
コボルに染まるとRDBやオブジェクト指向の考え方についていけなくなるよ。
もし既に君の中にそういうものが確立していたとしても崩壊する。

173 :仕様書無しさん:2006/12/03(日) 01:21:18
COBOLやる以上、OOPの考え方は一旦捨てざるを得ないな。
RDBについてはこぼらーがアホなだけだが。

174 :仕様書無しさん:2006/12/03(日) 12:00:24

そもそもコボルやってる奴は頭が悪い

175 :仕様書無しさん:2006/12/03(日) 15:45:03
MOVE MOVEうざいんだよ。コボルは。
何がCOPY句だ。うざいんだよ。


176 :仕様書無しさん:2006/12/03(日) 15:49:14
COBOLの構造体をそのまま文字列整形する仕組みは好きだなと思った。
C++でもprivateな文字列フィールドを埋め込めばいいと考えればそれまでだが。

177 :仕様書無しさん:2006/12/03(日) 20:10:54

今は、C#の時代

178 :仕様書無しさん:2006/12/03(日) 23:01:29
いいじゃん、横長定義くらいで済んでるなら。
俺の悩みはなー、引き継いでるDBのカラムが1列だけしかないってことだ。



その1列が、何桁目からN桁が項目Aで、次のM桁が項目Bで……。








誰だ、こんなの出荷したバカは〜!


179 :仕様書無しさん:2006/12/03(日) 23:30:54
>>166
コボラ由来のDBにそういうのよく見るよな。
このままやっていると頭がおかしくなるので、
俺はついこんなことしまう。

SELECT ・・・ ,'1' AS 実績月 ,売上実績1 AS 売上実績
FROM 予算管理テーブル
UNION
SELECT ・・・ ,'2' AS 実績月 ,売上実績2 AS 売上実績
FROM 予算管理テーブル
UNION
(以下略)


>>178
あまりの潔さに大爆笑(藁)

180 :仕様書無しさん:2006/12/03(日) 23:43:16
>>166 >>178
そういうのって、多分アンロードしてファイルで扱うことが前提なのだろうな。
正規化してると逆に扱いにくいから。

でも、>>178みたいなのは最初からDBなんて使うなよってレベルだな。

181 :291:2006/12/03(日) 23:51:28
>>180
さらに、客である○○○○ITソリューションの山本がそういう仕様を出してきた時に、
うちの会社の長居主任の作成した仕様書に、

○○の処理が終わったら、××フィールド(数値)をと4を足す。
○○の処理が失敗したら、××フィールド(数値)に2を引く。

みたいなことが書いてあった。

よくよく考えると、ある桁のビットのセットやリセットのことだった。

コボラーにもなれない馬鹿SEも痛々しいが、
オラクル厨でマスク処理とか知らない主任(現在課長)も死んでほしいと思った。

182 :仕様書無しさん:2006/12/03(日) 23:54:17
理由は判ってて、昔オフコン時代に動いていたのをPC+Windowsにリプレースする
際に、なーんも考えずにDATA DIVISIONをそのままベタで置き換えたから。
仕方ないから、後から別にsubstrが山と入っているviewを追加してしのぐという
パフォーマンス最悪なシロモノ。
ちなみに、当然のごとく文字コードはJA16SJIS厳守。位置がずれるから…。

こんなのでも世間では一式1千万円超のシステムとして売られてるってんだから、
恐ろしい話だ。


183 :仕様書無しさん:2006/12/04(月) 00:39:57
>>181
マスク処理が分からない人は意外にに多いよ。
バイナリフラグなのに8ビット平気で使うし。

まあいいけどね。INPUTとOUTPUTを必ずペアにしなければ
ならないことを完全に忘れてるUI設計をしなければ。
データが突然ボウフラのように沸いてくるような設計だけは
ホント勘弁だわ。

184 :仕様書無しさん:2006/12/04(月) 02:14:23
>>183
まぁ、マスク処理分からないなら、分からないで良いから、

「○○ビット目をセットすること」

と書きゃいいんだ。
分からんなら、早々に人に聞けばいいのに、聞かないからこういうことになる。

それにしても、「マスク処理を知らないが、ソフト会社の課長」って笑えるよなw


185 :仕様書無しさん:2006/12/04(月) 06:00:00
>>182
もし、COBOLで読み書きしていたデータをRDB化しろ・・・という
業務命令を受けたら、「正規化」という言葉が通じない職場なら
俺でもそうするかもしれないな。

世知辛い話だがとして後先考えても得するのが自分じゃなければ
むしろ、余分な工数かけるなと怒られるのが関の山だから。
COBOLerがあいつが勝手にいじったとちくられるはロクな事ないし。

もちろん自分が面倒みなきゃいけないことがわかっているなら
きちんと正規化して後々自分が困らないようにするけどね。

そうやって、横長RDBが増殖していくんだろうな。

186 :○○○○ITソリューションの山本:2006/12/04(月) 22:06:40
コレ以降は
『コボラが〜』
じゃなくて、すべて
『○○○○ITソリューションの山本が〜』

にしようぜ!!



187 :仕様書無しさん:2006/12/04(月) 22:09:33
>>181
ツーか、いまどき、Bitフラグ使うなよ w
ほんと、『○○○○ITソリューションの山本』はバカだな w

>>186
こういう使い方でええのか?

188 :仕様書無しさん:2006/12/04(月) 22:14:58
スレタイ変更

『○○○○ITソリューションの山本』は横長DBがお好き

189 :仕様書無しさん:2006/12/04(月) 22:16:38
あのさ、東芝ITソリューションつっても合併繰り返して従業員多いんだからさ、
お前の頭の中には特定の一人かもしれんが、中には役員クラスもいるかもしれん
のに、そんなに名前連呼してりゃどうなっても知らんぞ?


190 :仕様書無しさん:2006/12/04(月) 23:01:16
誰か東芝と言いました?

191 :仕様書無しさん:2006/12/04(月) 23:09:46
実際にはこの手の伏字もどきは気休めにもならないし。


192 :仕様書無しさん:2006/12/04(月) 23:48:22
TISのスレなかったっけ?

193 :仕様書無しさん:2006/12/05(火) 00:10:59
あー、
こりゃ、>>189
の罪だな。

194 :仕様書無しさん:2006/12/05(火) 00:13:21
じゃ、>>189の忠告に従って、
コボラは『コボラ』でいこうぜ。


195 :仕様書無しさん:2006/12/05(火) 00:16:49
おっと、俺は、その言葉を使った>>149
じゃないぜ。

○○○○ITソリューションはNGか。
○○○○。。○○。○○。○はOKか?

196 :仕様書無しさん:2006/12/05(火) 00:22:24
○○○○ITソリューションの山本は、今年で入社15年目の大ベテラン
彼のスキルを列挙します。

DB設計:独特な定義手法
 もしかして、正規化って言葉も知らないのか?と思う君は甘い。
 それこそ、「ITソリューション」
プログラム設計:21世紀の手法「ポンチ絵法」を確立。
 スピーディーな設計と、情報漏洩対策もバッチリです。
出世の戦略:信長方式です。
 現在は、家督争い中のようで、「うつけ者」を装っています。
 能ある鷹は爪隠すといいますが、仕事や雑談でも、才能を完璧に隠しとおします。
 いつ、才能を見せてくれるのか、楽しみです。


197 :仕様書無しさん:2006/12/05(火) 00:26:51
>>196
>情報漏洩対策もバッチリです。

単に、設計した本人にしか分からないってことでは・・・・・?


198 :仕様書無しさん:2006/12/05(火) 00:29:19
>>198
おい、もう
○○○○。。○○。○○。○の○○さんのことはやめとけって。
>>189
に怒られるぞ。

199 :仕様書無しさん:2006/12/05(火) 00:42:02
>>198
ポインタが自己参照してるよwwwww

>>189
○○○○ITソリューション≠東芝ITソリューション


200 :仕様書無しさん:2006/12/05(火) 02:45:19
富士電機?

201 :仕様書無しさん:2006/12/05(火) 07:45:35
>>200
君、具体的な人物に心当たりあるのかい?

202 :仕様書無しさん:2006/12/05(火) 08:53:55
create table文を作成するperlスクリプトがあったり。

203 :仕様書無しさん:2006/12/05(火) 12:30:17
なんか、日曜の夜中あたりからコボ厨よりレベルの低いガキが沸いてるな。
頭の固いコボラも困るが、社会常識の無いガキはマジで仕事に使えねぇ。

名前を出してる粘着さんなんか、クビにしたら去り際にリポジトリ破壊とか
していきそうだね。


204 :仕様書無しさん:2006/12/05(火) 14:55:10
perl -e 'print "create table hoge (" . join(",",map{"A$_ char(100)"}1..1000) . ");\n";' | sqlplus hoge/fuga


205 :仕様書無しさん:2006/12/05(火) 17:31:23
コボラの作ったDBの話ならしたいが、
○○さんの話は聞きたくない。

206 :仕様書無しさん:2006/12/05(火) 20:57:01
http://b.hatena.ne.jp/entry/http://www.rubyist.net/~matz/20061115.html
世の中の半数以上のプログラマはCOBOLに投入され、
メンテナンスだけではなくて新規の開発も行われています。

207 :仕様書無しさん:2006/12/06(水) 03:09:06
横長DBもそうだが、
画面設計も相当終わってるぞ。

モードを入力してから、(1:新規、2:修正、9:削除 など)
コードを入力して編集とか。

RDBだけでなくGUIも台無し。


208 :仕様書無しさん:2006/12/06(水) 05:00:34
そういやエンターキーでカーソル移動ってまだやってるとこあるんだろうか?

209 :仕様書無しさん:2006/12/06(水) 05:40:36
>>207
それGUIでやるんか??
頑固もそこまでやると潔い!!

210 :仕様書無しさん:2006/12/06(水) 11:11:51
F1押下でプリントアウトする

211 :仕様書無しさん:2006/12/06(水) 12:38:28
>>209
エミュレータを廃止してWebに移行したシステムで見たことある。
再設計することを考えたら、何も考えずにそっくり同じにするのもありだと思った。

212 :仕様書無しさん:2006/12/06(水) 15:54:50
>>207
ぱっと見、台無しに見えるけど、テンキー魔神のオペレータに対応したとか
そんなのじゃないの?

213 :仕様書無しさん:2006/12/06(水) 16:03:31
>>211-212
顧客の要望として「そうせよ」と言うのはよくあることでしょうね。

214 :仕様書無しさん:2006/12/06(水) 16:11:31
>>211-212
なるほど。俺もそれ見たことがある。
UI変わると、教育もやり直すことになるから、
ユーザ数の多いシステムではありうることだな。

215 :仕様書無しさん:2006/12/06(水) 17:57:20
>>212
本屋の棚卸風景を見たことがあるがテンキー打つ手が音速超えてるかと思った。
後、あんな使い方なら直ぐキーボード壊れるよなぁと感心した。


216 :仕様書無しさん:2006/12/07(木) 00:45:41
せめて、現行の動作も持たせつつ、
ドロップダウンリストとかにして欲しいな。

1,2,9以外を入力したら、
「(×)正しく入力してください[OK]」
とか出すらしい。

あー、ばかばかしい。

217 :仕様書無しさん:2006/12/07(木) 00:46:27
イレギュラーを作り出してる。

218 :仕様書無しさん:2006/12/07(木) 00:47:39
>>208
まぁ、それは一行で済むから許してやろうぜ。

219 :仕様書無しさん:2006/12/14(木) 22:21:27
いや、許さん。

220 :仕様書無しさん:2006/12/14(木) 22:22:51
    _
こぼらはタヒんでください。

221 :仕様書無しさん:2006/12/14(木) 22:23:21
     _
こぼらはタヒんでください。


222 :仕様書無しさん:2006/12/14(木) 22:37:12
      _
こぼらはタヒんでください。

223 :仕様書無しさん:2006/12/14(木) 22:38:36
『テーブルを性器化しないコボラーを叩くスレ』

224 :仕様書無しさん:2006/12/14(木) 22:40:52
いやだ

225 :仕様書無しさん:2006/12/14(木) 22:58:47
>>208
エンターキーさえ必要としない「フル桁入力でカーソル移動」が最強!
テンキーの0が叩かれすぎて可哀相だった。

226 :仕様書無しさん:2006/12/14(木) 23:15:09
ていうか、TABでええやん。

227 :仕様書無しさん:2006/12/14(木) 23:47:48
エェー、嫌だぁ。と入力専用女子に一蹴されますた。

228 :仕様書無しさん:2006/12/15(金) 00:06:25
デフォルトボタンの機能が「次の入力欄にフォーカスを移動すること」じゃ駄目かな?

229 :仕様書無しさん:2006/12/15(金) 09:37:50
標準の動作として、ダイアログでEnterしたらOKとかで
Escしたらキャンセルとかになるっていうのがあるんだよな。
OKにカーソルあるときにEnter押したら、次に飛ぶのか閉じるのか?

あるいは複数行入力があったとして
その上でEnterしたら改行入力?次に飛ぶ?


知ってる中で一番けったいな構造は介護保険の「単位数マスタ」かな。
データ構造も繰り返しばかりだし、過去にさかのぼって修正ってのをやらないから
日付によって項目の解釈を変えないといけなかったりする。


230 :仕様書無しさん:2006/12/15(金) 20:51:57
コボラは自分が亜フォであることをまず認めよう。
話はそれから。
10コ下の後輩に頭下げてRDB、GUIを真鍋。

231 :仕様書無しさん:2006/12/15(金) 20:52:53
あるいは、出世して現場離れろ。
コボラは、現場にいると害になる。

232 :仕様書無しさん:2006/12/15(金) 21:32:51
腐れ上司の一言スレに登場しそうだ w

233 :仕様書無しさん:2006/12/15(金) 21:46:26
単純に『コボラを叩くスレ』

234 :228:2006/12/15(金) 22:09:29
テンキーの傍にTABキーとShift+TABキーのペアがあればいいのにな。

235 :仕様書無しさん:2006/12/15(金) 23:01:19
TABでフォーカス移動ってのもどうかとは思うんだよな。Winのお作法とはいえ。

今までユザに教えてあげて知ってたヤツは皆無。
んで、タブーオーダーという概念も理解してないし。
Enter押したらデフォルトボタンが押されてダイアログが閉じられて発狂パターンも多い。

Enter=入力終了&次の項目へ
Tab=デフォルトボタン押下

ってルールでもいいかも知れんと思ってしまうオレガイル

236 :仕様書無しさん:2006/12/15(金) 23:44:37
TABで移動はS/390の頃からあったんじゃないのか・・・?
漏れがAS/400触った頃には既にあったので、Winの作法でも
なんでもなくて、Winが汎用機からパクったと思うのだが。

あと業務用のテンキーパッドはちゃんと打ちやすい位置にTABとバックTABがある。
そして[ENTER]と[実行]は別物なので、右手のみで自由に画面をカーソル駆け巡り
画面遷移が出来る。

237 :仕様書無しさん:2006/12/16(土) 04:49:15
Winのお作法かどうかはさておき、一般ユザは知らんことが多いよ。

238 :仕様書無しさん:2006/12/16(土) 12:45:42
コボラの辞書にGUIという文字はない

239 :仕様書無しさん:2006/12/16(土) 23:04:34
コボラは貴所イ。

240 :仕様書無しさん:2006/12/17(日) 04:59:53
「技術職なんだからこのくらい常識だ!」という言う片方では
(自分たちが技術者との知らないことは)「そんなの普通の人に解るわけないじゃないか!」と
平然と言い放てるようなスバラシイ精神をもっているのがコボラ。


241 :仕様書無しさん:2006/12/17(日) 09:55:54
>>240
この間、日立○作所の人間にソレ言われたよ。

そっちのミスでバッチ処理を走らせる順番間違えたので、
その報告を聞いた漏れが「間違えたジョブのプロセスを停止かKILLすれば?」って
言ったら「そんなの普通の人に出来るわけない」と逆ギレされますた。

言っている意味が解らんかったら少しは自分で調べてから返答しろよ。

242 :仕様書無しさん:2006/12/19(火) 10:28:16
>>241
「あなたは普通の人ではない」とやさしく言ってあげましょう。


243 :仕様書無しさん:2006/12/22(金) 21:29:27
>>242
いや、『エンジニアではないあなたにはわかりにくかったですね。すいません。』
と、言うべき。

244 :仕様書無しさん:2007/01/06(土) 18:22:46
あげ

245 :仕様書無しさん:2007/01/06(土) 18:28:23
暴力団アゲ

246 :仕様書無しさん:2007/01/06(土) 23:02:12
去年、コボラーのオッサンが作ったプログラムを
javaに書き換えるプロジェクトに参加させてもらったが
DBが全く正規化されていなかった。orz
まぁ、ある程度は覚悟してたからいいんだが、
そのオッサンがPLでプロジェクトが崩壊した
あっ、俺は勿論バックレ



247 :仕様書無しさん:2007/01/29(月) 01:29:54
そのまま移植しようとするからバカなんだよ。コボラは。


248 :仕様書無しさん:2007/01/29(月) 01:32:02
ばっくれる前にその親父叩き潰せよ。

249 :仕様書無しさん:2007/01/29(月) 03:34:47
データウェハウスの案件で、
「じゃ、DBみせてください。」と言ったら、
出てきたのがCOBOLのコピー句を印刷したものだった。orz

250 :仕様書無しさん:2007/02/01(木) 19:03:54
>>249
それは発音が悪かったからだよ。「デービー」って言っちゃったんだろ?
それじゃ COBOL が出てくるのはしかたがないよ。


251 :仕様書無しさん:2007/02/01(木) 19:41:57
>>250
いや、「デーベー」。www

252 :仕様書無しさん:2007/02/01(木) 20:31:43
代田橋

253 :仕様書無しさん:2007/02/10(土) 20:51:08
新人でコボル現場2年目なんだけど(本当はオープン希望だった)
俺の上司に教わったことが常識だと思ってたが不安に感じてきたな。
コボラの上司たちはコボルができれば仕事はなくならないから
見たいな事や、オープン系は糞って言ってたけど
実際どうなの?

254 :仕様書無しさん:2007/02/10(土) 20:52:29
>>253
かわいそうだけど、君はもう、、

255 :仕様書無しさん:2007/02/11(日) 16:27:31
>>253
>コボラの上司たちはコボルができれば仕事はなくならないから
嘘は言ってないな。真実を隠しているだけで。


256 :仕様書無しさん:2007/02/11(日) 21:50:24
>コボラの上司たちはコボルができれば仕事はなくならないから
>見たいな事や、オープン系は糞って言ってたけど

・・・・・という話が本当ならば、COBOLの教育がもっと頻繁に行われているはずなのだけど・・・・・ね。


257 :仕様書無しさん:2007/02/12(月) 00:58:38
まぁ、正規化は常に性能とトレードオフ。

どうせ一トランザクションで舐めることになるデータは一レコードに持たせておいた方が、CPU使用量(LockにかかるCPUとかも含めて)とか、I/OWAIT等々の観点で有利。

と言ってみるテスト。

258 :仕様書無しさん:2007/02/12(月) 01:09:37
>>253
COBOL→多言語のリプレースが今後増えてくるから
両方出来ればまだ生きれる

259 :仕様書無しさん:2007/02/12(月) 02:35:30
>>253
センスある香具師は言語の癖はすぐにわかるって。


あ。わからない、だめだこりゃ。

260 :仕様書無しさん:2007/02/12(月) 19:52:29
>>257
昔なら、非正規化の理由としてそれもあったかもしれんが、
現在のように機能強化や変更がたびたび起こる様な状況では
開発速度、追加した機能のパフォーマンスなどを含めた、
トータルの性能では正規化した方に分があると思う。

261 :仕様書無しさん:2007/02/13(火) 01:23:36
担当1〜担当4とかあって、開始時間と終了時間を含んだレコードがあるとする。
更新のたびに、日付と担当者コードで重複チェックしたり、
担当者ごとに日数集計したりするっていうのは
非正規化状態ではまともに読めるコードは書けなかった。
書いても遅かったし。

正規化を検討して、その結果やめるのはいいんだが
検討もせずに非正規化でほっておくのはなぁ・・・


262 :仕様書無しさん:2007/02/13(火) 13:38:18
>>258
>まだ生きれる
まぁ40年もあれば、俺ら大概死ぬしな。
意外とコボラはその人生を全うするかもしれんw

263 :仕様書無しさん:2007/02/13(火) 21:32:26
デットロック発生!

264 :仕様書無しさん:2007/02/14(水) 00:43:26
>>261
逆じゃねぇか?
正規化を前提に、非正規化を検討するのが妥当かと思うけど。

265 :仕様書無しさん:2007/02/14(水) 00:47:12
>>258
そりゃ自らの首を絞めてるな。
実際今のコボルの仕事ってそんなんだけど。

266 :仕様書無しさん:2007/02/14(水) 00:47:27
>>261
SELECT時に担当者マスタを4枚JOIN???
またはフロントで4LOOP/1RECORD???
または起動時に担当者マスタ全件SELECT???

糞だ!!!!



267 :仕様書無しさん:2007/02/14(水) 00:48:29
>>258
コボラ乙。
いまから、FORM-A買いに行け。

268 :仕様書無しさん:2007/02/14(水) 00:49:22
みすたーーーーーーーーー

FROM-Aだ。
買いに行くのは漏れか orz

269 :仕様書無しさん:2007/02/14(水) 00:56:08
コボラが作ったテーブルで
横長に250ほどカラムがあるんですが・・・
ざっくりリレーショナルに作っていけば100以下になりそうです
設計者を殺したいんですが構わないでしょうか?


270 :仕様書無しさん:2007/02/14(水) 01:48:12
250ならギリセーフ

271 :仕様書無しさん:2007/02/14(水) 01:51:00
>>270
な、わけが。

272 :仕様書無しさん:2007/02/14(水) 02:23:51
>>271
カラム増え過ぎでDBの限界を超えたら、1カラム char(255) して、 char(100)とchar(155)の2カラムとして扱う
なんて技を出してくる

273 :仕様書無しさん:2007/02/14(水) 02:25:35
>>272
コボラとはPg業界に巣食うシロアリ的存在なのですね?

274 :仕様書無しさん:2007/02/14(水) 02:26:37
>>273
それは、コンピュータは電気で動いてますよね?くらい間抜けな話

275 :仕様書無しさん:2007/02/14(水) 02:57:21
>>272
コボラはデータが固定長でないと気に入らないからな。

276 :仕様書無しさん:2007/02/14(水) 04:44:24
>>271
あるある w
というか、限界までかなり余裕があっても、その奥義を繰り出してくる。

KEYを同じにして別テーブルなんてことは
コボラの脳味噌の外にある概念。

277 :仕様書無しさん:2007/02/14(水) 04:58:12
なんか最近、コボラ的行動にいちいち腹立てる香具師を見るのも楽しくなってきた
もちろん自分に被害の無い範囲で

278 :仕様書無しさん:2007/02/14(水) 20:27:46
糞コボラは新規設計のテーブルになぜかフィラー512バイトを最初から付けてくる...。

279 :仕様書無しさん:2007/02/14(水) 21:14:11
>>278
フィラーをつけるのを当たり前だと思ってる俺は世間知らずの
糞コボラー

280 :仕様書無しさん:2007/02/14(水) 21:24:31
後から列を追加するコマンドとかあるみたいだけど、ああいうのは使わないのが普通なのかな?

281 :仕様書無しさん:2007/02/14(水) 22:07:39
>>279
FILLERをつけることによってタプルサイズをブロックサイズと同一にし、
それによりロックの競合やロックエスカレーションを避けることを意図している設計だ。

俺様は一流なので、ポンコツDBMS上で実装する時にそういう意図でやることはあるが、
なんてことはコボラーが思いつくはずはない。

つまり、野生の勘だけでそれを実装できるコボラーは、
ある意味では俺様より偉い存在だといえる。

282 :仕様書無しさん:2007/02/14(水) 22:46:57
>>281
とかなんとか言いつつコボラを持ち上げてる
お前はコボル厨。

283 :仕様書無しさん:2007/02/14(水) 22:50:15
今カスタマイズでやってる仕事がまさにコレだな。
テーブルにフィールドを追加するだけだから簡単だと思ったら
最大フィールド数を超えたとかで泣きそうになった。

284 :仕様書無しさん:2007/02/14(水) 23:08:16
>>281
Sybaseでそれやってたヤツはいたな
まだページロックの頃

285 :仕様書無しさん:2007/02/15(木) 00:39:17
SELECT * 〜で取ってきては1件読んでチェックして、1件読んでチェックして・・・・・・・
挙げ句に「何で遅いのかさっぱり解りません!コレだからOpen系はクソだ!わけわからん!」

なんて逆ギレして返品されたこぼらを最近見た・・・・・

286 :仕様書無しさん:2007/02/15(木) 00:56:02
>>285
ボコルに配列くらいないんだろうか?
RecordSetとは言わなくても。

287 :仕様書無しさん:2007/02/15(木) 01:39:24
配列もあるし,RecordSetじゃないけどPL/SQLのCursorみたいな機能もある.
ただCOBOLの処理が根本的に違うのは基本的にテーブル/ファイルを
全件操作するのが前提で物事を考えること.
顧客データをSQLでSELECT * FROM USER_M WHERE STATUS = 1
とか抽出するんじゃなくて,
SELECT * FROM USER_M で全件取得して,カーソルで回す.

昔のデータ件数と,汎用機の化け物じみたマシンスペックではそれも可能だったんだけど,
RDBとかオープン系とかはその辺の限界を打破するために出てきたようなもんだから,
いわゆるパラダイムシフトですね.
地動説と天動説の違いみたいなもんですよ.

ちなみに私が知ってるのは主流のCOBOL85より一つ?古いCOBOL74規格なんで,
最近は違うのかもしれませんが.

288 :仕様書無しさん:2007/02/15(木) 01:42:18
確かに、ちょっとはRDB知っているボコラはカーソル大好きだな。

289 :仕様書無しさん:2007/02/15(木) 03:24:51
コボラがつくったみたいなフレームワークで、DBアクセスの基本が1テーブルのみで、JOINが増えると開発難易度があがるというアホなのがある
使用するテーブルなどは別途宣言が必要で、VIEWを使う事は想定外


290 :仕様書無しさん:2007/02/15(木) 16:39:31
RDBにもカーソルがあるわけだが・・・


291 :仕様書無しさん:2007/02/15(木) 16:41:14
>>285
まずは "where" の単語の意味を教えてあげなさい。


292 :仕様書無しさん:2007/02/15(木) 17:50:57
>>288
それはヴビ厨にも言えるな。

293 :仕様書無しさん:2007/02/15(木) 21:09:20
>>289
なんじゃそれ?

>>292
そうか? そうなのか。

294 :仕様書無しさん:2007/02/15(木) 21:11:48
コボラDBで悪戦苦闘している人を今日みた。

どうやら主キーが10桁くらいの文字型になっている様子。
そのテーブルの前4桁くらいを外部キーとして別テーブルとJoinしたり、
大量UPDATEをする処理が重くてしょうがないそうだ。

295 :仕様書無しさん:2007/02/15(木) 22:30:42
いや、それは、オマエの文章もバグってる。

296 :仕様書無しさん:2007/02/15(木) 22:38:55
デバッグよろ。想像で。

297 :仕様書無しさん:2007/02/15(木) 23:30:29
おk

298 :仕様書無しさん:2007/02/16(金) 00:29:34
本来は
char(4)
char(6)
の2カラムでユニークにするべき所を
char(10)
の1カラムにしているってことだな

299 :仕様書無しさん:2007/02/16(金) 01:36:11
そう。そしてそのchar(10)がそのテーブルの主キーになっているらしい。

300 :仕様書無しさん:2007/02/16(金) 01:42:03
で、他テーブルとのJOINは

substr( char(10)のカラム ,1,4 )=他テーブルのキー

とかだな

301 :仕様書無しさん:2007/02/16(金) 01:47:24
>>300
そうそう。または、左右逆とか、両方がsubstr()。

そんなJOINとかしてたら、確実に遅そうだ。

302 :仕様書無しさん:2007/02/16(金) 01:49:53
同じUPDATE処理のはずが、substr( char(10)のカラム ,1,4 )の値によってUPDATEするカラムとか、カラム中のアップデートする桁が変わったりとかも

303 :仕様書無しさん:2007/02/16(金) 02:07:36
>>302
ボコラDB(汎用機のファイルをそのままテーブルにしたようなもの)の場合、
char(6)の方の先頭一文字目でUPDATE対象が変わったりすることが多い。


契約番号,入金日,自動継続,・・・・
A001P-1234,20070228,1,・・・・

みたいな感じで、
契約番号は本来

substr(契約番号,1,4) as 得意先コード
substr(契約番号,5,1) as 契約種別
substr(契約番号,7,4) as 得意先別シーケンシャルNo

だったりする。

304 :仕様書無しさん:2007/02/16(金) 02:11:27
こうだった orz...

契約番号,入金日1,,入金日2・・・,入金日12,自動継続,・・・

305 :仕様書無しさん:2007/02/16(金) 02:47:50
入金日1は4月な

306 :仕様書無しさん:2007/02/19(月) 20:59:38
お前2ちゃんねるに書き込みしただろ?って上司に言われた・・・

307 :仕様書無しさん:2007/02/19(月) 21:53:14
COBOLerの思考回路はどこいっても大差ないから、
書き込みで特定はされないと思うけど。

308 :仕様書無しさん:2007/02/19(月) 22:45:01
しかたがないよ。
我々とコボラは職業が違うのだから。

309 :仕様書無しさん:2007/02/19(月) 23:48:33
コボラは現代における「本物のプログラマ」です。

310 :仕様書無しさん:2007/02/20(火) 14:52:58
JOINしたら怒られた
SELCT * FROM テーブル名で関連テーブル全部開いて
ぐるぐるカーソル回して探すのが正しいやり方らしい

311 :仕様書無しさん:2007/02/20(火) 15:47:16
辞めたら?無能な連中と一緒にいてもいいことないよ。

312 :仕様書無しさん:2007/02/20(火) 21:21:54
そういう事をのたまうアフォがいる会社を晒せばいいんじゃないか?
たとえば某日○製作所とかサ

313 :仕様書無しさん:2007/02/20(火) 22:06:08
>>310
無茶無茶ただしくない。
しかし、俺の会社にも同じ思想の部署があった。

314 :仕様書無しさん:2007/02/21(水) 00:40:50
うん。指導担当に恵まれてたから正しくない事を理解できた。
その人は社内では新参SEで業務知識が弱いのとコボラ相手に疲れて転職したけどな
おいらも4年ちょいいてそろそろ潮時かなって思って辞めた。
でも職業PGとしての師匠は最初の指導担当の先輩だと思ってる。
コボラ達と意思疎通が困難な中で、自分が新人の頃には先輩に世話になった
今度はおいらの番だって指導にあたってくれたおかげで今がある。

315 :仕様書無しさん:2007/02/21(水) 22:49:58
>>310
怒られて黙ってるのか?
コボラを駆逐するチャンスだろ!!?


316 :仕様書無しさん:2007/02/21(水) 23:31:17
WindowsからAS400に接続して売上情報を
作成するプログラムを開発したが、もの凄かった
1テーブルのサイズが軽く3Kを越え
しかも、レスポンスが悪いからインデックスを張りましょう〜と
提案するとインデックスって何?
論理ファイル作ればいいじゃんって言われたorz
(後で調べたら論理ファイル=ビュー
彼らはRDBの概念も知らないし、
勿論、SQL文も知らない怪物だった



317 :仕様書無しさん:2007/02/21(水) 23:34:04
>>316
AS400ってまだいるんだね。

318 :仕様書無しさん:2007/02/22(木) 00:05:32
>>316
逆説的なんだが、そのIBMのRDBの根源のひとつがAS400なワケだが。
ここからDB2が生まれたとも言えるワケだし。
ちなみに今は中身がRS/6000相当なので、「ちゃんと設計すれば」
超安定かつそこそこ高速なRDBだ(OSとDBが融合してるので説明がムズい)

まー、けどRDBの概念知らんかったりSQL知らん奴多いよな。

論理ファイルは論理ファイルでいいとこあるよ。古代言語(RPG)使いにとっては。
SQL使いがほとんどの現世ではイイトコほとんどないが。

319 :仕様書無しさん:2007/02/22(木) 00:20:06
システム自体は安定してるセキュアだし悪くねーかもね。
しかしいかんせん開発効率悪すぎ。
インターフェースも70年代だし。
COBOLが悪いっていうより、もっと便利な新しいシステムを覚えられなくて
しがみついてる無能な奴が悪いって事だろうな。
CとかSQL使えた上で、必要に応じてCOBOL使ってるならわかるけど、
今の時代までCOBOLしか出来ないってのは、もうその時点で頭悪いから仕方ない。

320 :仕様書無しさん:2007/02/22(木) 00:24:34
レガシーシステムが奮戦していることが多々あるからやむをえまい。
コボル漬けになった担当者は気の毒。

321 :仕様書無しさん:2007/02/22(木) 00:25:47
>>315
華麗にスルーが暗黙の了解です

社内の半数がASかコボルで仕事してて
オープン系のSEもほとんど元ASかコボラ
若手の一部とオープン系からの中途しか
解ってくれる人がいない世界ですから…

322 :仕様書無しさん:2007/02/22(木) 00:33:53
AS400用のODBCなかったっけ

323 :仕様書無しさん:2007/02/22(木) 00:38:30
AS400(i5)はデフォルトと言うかJava+SQLがすでにセットアップ済みと言う恐ろしい
実験機と言うかある意味、そこらのLinuxよりも実はオープン系向きな
サーバーだったりするんだが、どうも古代人(W)がCOBOLやRPGに
しがみついている無能連中が多いから不当な評価を受けてる感があるな。

レガシーから最新技術まで使えるのが一応のウリのサーバーなんだが。

324 :仕様書無しさん:2007/02/22(木) 00:40:53
>>322
ある。
DB2/UDBのより不思議と高性能だとオモ。

325 :仕様書無しさん:2007/02/22(木) 00:47:16
取ってきた結果がソートされてるなんてどうやって証明するんだ?
万が一順番通りになっていなかったらどうするんだよ!
だから1件ずつ取ってきて調べるんだ!解ったか!!

うん、あなたをCOBOLERの巣に帰さなければいけないことは解ったw


326 :仕様書無しさん:2007/02/23(金) 18:14:26
AS400でストアド使ってるとえらい事になってるよ
素直にRPGでいいと思う。バッチ部分は。

327 :仕様書無しさん:2007/02/23(金) 19:31:38
>>326
kwsk

328 :仕様書無しさん:2007/02/24(土) 17:13:58
COBOLerの書くストアドなんて
select * from hoge;
とか平気で書いてそうだな。

それで、パフォーマンスがでなくて
RPGでいいとか言っていたら頭おかしいと思うが。

329 :仕様書無しさん:2007/02/25(日) 00:32:50
慣れたもんでやれって意味

330 :仕様書無しさん:2007/02/25(日) 08:42:44
それは慣れとか不慣れの問題ではなく、
COBOLerは無能って意味だと思うがw

まあ、自称慣れているRPGプログラマーでも
アフォみたいに論理ファイル作りまくったり、
ロックせずにファイル更新しようとしてエラーがでて
「おかしい」とかヌかしている素人がいたりするからなー。

331 :おめこ:2007/02/25(日) 20:25:12
いやー久々に見たら、案外盛り上がってるな。
うれしい。
この調子で、コボラ叩こうぜ!

332 :仕様書無しさん:2007/02/25(日) 23:00:10
やはり一番ウザく思うのは、

Key,日計1,日計2,・・・・,日計50

みたいなやつだとおもう。

333 :仕様書無しさん:2007/02/25(日) 23:47:09
READ一回で結局OCCURS配列にぶっ込んで
所望の処理してレコード変数に代入してREWRITEな。

I/F部分を隠蔽すれば嫌なCOBOLerの呪縛から現実逃避できる自分を最近発見した。

334 :仕様書無しさん:2007/02/26(月) 00:47:33
ボコラ課長が作ったストアドは内部でコミットするんだ…
だからストアド避けてトランザクションはるんだ…
やめよーって言っても皆いまさらマンドクセなんだ…

なんでそーなったか?○BMのサンプルコードが内部コミットしてっから

一連登録処理のそこだけ外出しにするの気持ち悪くないの…?
おいらは禿敷く吐き気がするよ…
直したいのに共通部分はさわるなってヒドイヨ

335 :仕様書無しさん:2007/02/26(月) 06:52:17
>>334
いや、藻前の日本語からすると藻前もストアド知ってるのか
怪しいんだが・・・。

そのソースを晒してくれないとそのボコラ課長をどうこう言うのは
藻前の私怨と思われる。

336 :仕様書無しさん:2007/02/26(月) 11:45:10
>>334
残念ながら、>>335に禿同だ。
ストアド知っているようには見えないな。

337 :仕様書無しさん:2007/02/26(月) 19:17:13
>>336
確かに、喪前らに禿同だが、

ストアドをCallした後に、他の更新処理があって
それそれでエラーになったら、全部ROLLBACKしたいけど
出来ないジャマイカー。(正常系には問題ない?が、異常系
に問題アリ)

と言っておるように思う。

ちがう?>>334


338 :仕様書無しさん:2007/02/26(月) 19:21:34
ただストアドを使いたかっただけなのでは

339 :仕様書無しさん:2007/02/26(月) 19:30:57
>>337
そうは思ったんだけどね。

多分ストアドのそこかしこに埋まっているcommitをどうにかしたかったんだろうと。
むやみにcommit書きまくるコボラ多いし。

340 :仕様書無しさん:2007/02/26(月) 21:33:58
個人的にはCOBOLerだとコミットすら知らん印象があるんだが。

あとIBMのどんなサンプルコードかしらんけど、
DB2UDBやDB2/400は普通に機能ケースに従ったサンプルだった。

しかし、>>334の発言はどーもアレなんだが。
トランザクションの使い方はシステムによってまちまちだから
第三者がどーこーいうのは難しい罠。

まあ、長く動いているシステム見ると直したくなる心境は
解らないでもないが、そういうのは暇人プログラマの
オナニーであるケースが多いな。

341 :仕様書無しさん:2007/02/26(月) 21:39:40
鉄則:問題なく動くソースはどんなに腐っていても手を触れるな。

342 :仕様書無しさん:2007/02/26(月) 21:55:10
ちゃんと理由や目的があり、ちゃんとテストするなら別に
ソースをいじるのは悪くないと思うけど、
キモいから、と言う理由でいじるべきではないな。

経験則でその「鉄則」があるシステムは多くの場合グダグダだしな。

極稀に天才エンジニア(?)が気ままにつくったっぽいシステムの
方が美しかったりするのはある。

#たぶん、一人で全て作ったと思われ

343 :仕様書無しさん:2007/02/26(月) 22:45:23
『コボラ』で検索したら、コボラ叩いてるっぽいスレはここともう一つしかなかった。
おかしい。コボラをのさばらしてていいのか!?
もっと、コボラ叩きスレを立てるんだ!!

344 :仕様書無しさん:2007/02/26(月) 23:30:19
1.高学歴、キモヲタ。35歳。
  GUI、RDBでの開発をまったく知らないコボラ。

2.高卒、普通の人。25歳。
  VB厨。

使うならどっち?

345 :仕様書無しさん:2007/02/26(月) 23:37:34
1の方がまだ学習能力ありそうだ。

346 :仕様書無しさん:2007/02/26(月) 23:41:40
1は、そいつより学歴が上ならアリ
2は、上手いこと鍛えることができればアリ

347 :仕様書無しさん:2007/02/26(月) 23:48:09
マジレスすると、そんな小手先の知識や経験で
使うやつは決めないんだが。

つかDB関連の仕事でSQL使えんやつは既に門前払いだろ。w

348 :仕様書無しさん:2007/02/26(月) 23:53:45
>>347
コーダー乙w

349 :仕様書無しさん:2007/02/27(火) 00:50:28
1も2も使う価値がないので、二次受けの会社へ押し込んで三割抜く。



350 :仕様書無しさん:2007/02/27(火) 00:59:39
>>348
派遣乙w

351 :仕様書無しさん:2007/02/27(火) 19:37:17
1.東大卒、25歳。
こいつに聞いたらわからないことなど何もないと言うほど
  豊富なスキルを持っている。
  が、狭量で自己顕示欲が強く、
  他人の些細なミスを人目をはばからず罵倒する。
  キモオタサディスト。

2.高卒、25歳。
  他業種からの転職で業界未経験。
  これから勉強する意欲に溢れ、飲み込みも早い。
  性格は明るく素直で誰にでも低姿勢な好青年。

3.5流大卒、25歳。
  業界経験3年。仕事は早いがスキルはたいしたことなく、  
  (成果物の品質が悪いという意味ではなく、出来ることの範囲が1よりは広くないということ)
  技術職に固執しているわけでもない。
  生意気だがしゃべりは面白く、職場のムードメーカ的存在。
  遊び人。

使うならどれ?

352 :仕様書無しさん:2007/02/27(火) 19:45:38
裁判長、>>351は誘導尋問です。

353 :仕様書無しさん:2007/02/27(火) 20:08:13
レッテル貼りが趣味みたいなやつがいるな。

なんか型にはめないと落ち着かないんだろうなぁ。

354 :裁判長:2007/02/27(火) 20:37:17
>>352
異議を認めます。


355 :仕様書無しさん:2007/02/27(火) 20:40:22
351は
スキルをとるか人格をとるか両方バランスをとるか
ってことが言いたいンジャマイカ?

漏れは使うなら、2か3だな。
1は使うこともあるかもしれんが、必要なことだけ吸収してポヰすればウマー。

356 :仕様書無しさん:2007/02/27(火) 21:02:27
なぜこのスレでこんな話題がでるか解らんが、
プログラマーに人格はいらんだろ。
技術職なんだし、できるやつしか必要ない。

そしてCOBOLなんかの案件に豊富なスキルなんか必要ない。

357 :仕様書無しさん:2007/02/27(火) 21:07:31
自分は、使うなら1>3>2。状況にもよるけどね。

「必要なこと」がどんどん膨張していく業界だから、「吸収してポヰ」なんて無理じゃない?
できても、吸収してポヰしたあとその分自分が働かなくちゃいけないなら本末転倒だよ。
最初から見通せてる仕事なんて少ないし、
困難な局面で頼れるのがいるのであればそっから使うにこしたことない。

ま、COBOLであれば2オンリーで。3も要りません。

358 :仕様書無しさん:2007/02/27(火) 21:41:40
>>342
一貫した思想で書かれたソースはそれなりに美しい。

が、コボラの書いたソースだけは別物だ。

359 :仕様書無しさん:2007/02/27(火) 21:42:50
>>351
1.格闘家
2.戦士
3.遊び人

まぁ、適材適所だな

360 :仕様書無しさん:2007/02/27(火) 22:28:54
>>358
無茶苦茶なCのソースよりは、
几帳面なコボラのソースの方がまだ見やすい。

ただし、どっちも手を入れたくない。

361 :仕様書無しさん:2007/02/27(火) 22:43:43
Cがある意味、技量と言うか美しさを体現できなくもない言語だな。

***hogeなんてやられた日にはプチ殺意が沸いてきたりこなかったり。w

362 :仕様書無しさん:2007/02/28(水) 09:56:23
コボルの唯一の良い所は、誰が書いても概ね似たような冗長さになることだと聞いたことがある。

76 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)