07/04/16 03:39:17
なんですか？
汎用機でいいじゃん。
処理スピードは断然速い。
インターネット系のシステムはともかく、会計（決算）、受注出荷、生産、債権債務管理、請求入金、原価計算等々、
いわゆる基幹系システムにおいては、オープン系で作るメリットが分からない。
操作性？
日常的に利用する基幹システムでは、『慣れ』の方が大事。
今時？古い？COBOLer？ドーテー？夢？幻？
誰か俺を論破してください、お願いします（´・ω・｀)
2:デフォルトの名無しさん
07/04/16 03:46:28
んなもん、ねーよ。
俺が稼げるからオープン系にしろって客にいってるだけ。
3:デフォルトの名無しさん
07/04/16 07:13:49
あ？そりゃ逆だろ。
汎用機の方が稼げる。だが、それだと高くて売れない。そんだけ。
4:デフォルトの名無しさん
07/04/16 09:34:46
>>3
汎用機だと今時のポッと出のSIerには無理じゃん
5:デフォルトの名無しさん
07/04/16 12:37:50
マジレスすると
バカにも扱えるようにするため
6:デフォルトの名無しさん
07/04/16 13:02:53
マジレスすると持ち帰って開発できる
7:デフォルトの名無しさん
07/04/16 13:15:46
メンテナンスや、不具合のときの対応がある程度のレベルの人間で可能
8:デフォルトの名無しさん
07/04/16 17:00:26
１台いくらよ？保守料ひと月いくらよ？
9:デフォルトの名無しさん
07/04/16 23:16:01
>>8
うちの例で言うと・・・、
汎用機は、コミコミで6,000万/月くらい。
オープン系は、ミッションクリティカル少ないのに、1,800万/月くらい。
動いているシステムの重要度で言ったら、比較にならんくらい汎用機のが上。
これらをオープン化すると、6,000万/月で済むとは思えない。
10:デフォルトの名無しさん
07/04/16 23:19:14
うちの例でいうと
10万/月くらい。
11:1
07/04/16 23:26:33
メンテナンスや不具合は、ベンダと連絡すれば短時間で解決する。
しかし、オープン系はサポートにたらい回しにされ、非常に時間がかかる。
何より、汎用機はノウハウが溜まっているのに対し、オープン系は枯れる前に
新しいのが流行るから、大抵の人間は狭い範囲のスキルしか持っていない。
12:デフォルトの名無しさん
07/04/16 23:29:21
汎用機のノウハウ・スキルってなにさ？
13:デフォルトの名無しさん
07/04/16 23:38:46
>>9
6,000万／月・台？オープンだとその１％程度。
サポートの質の差が6,000万/月以上の利益をほんとに生んでるの？定量的に説明できる？
とくに、ノウハウが溜まってるなら、サポートはそんなに重要じゃないんじゃないの？
14:1
07/04/16 23:41:54
>>12
・プログラムが異常終了したことを迅速に検知
・障害箇所を迅速に特定、対策
・１つの箱（同じ汎用機）でいくつものシステムを作る為、できる事／できない事が
周知であり、要求定義の段階で見積り精度が高い＆計画的な工程管理が「出来ている」
・ログを出力する勘所が明白
（オープン系はやや角度を変えただけログが一杯だったり、本当に欲しいログが
抜けてたりする）
15:デフォルトの名無しさん
07/04/16 23:50:22
>>14
上二つはまあいいとして、下は設計がうんこなだけじゃねえか
16:デフォルトの名無しさん
07/04/16 23:51:10
「できない事」＝「やらなくていい事」ではない件
17:1
07/04/16 23:52:14
>>13
6,000万の価値というのは、動かしているシステムの基盤としての価値です。
オープン系だと1%どころではなく、6,000万を超えると試算しています。
（導入支援SE費の償却費も含め）
ハードも高いし、ソフトもべらぼうに高い。
UNIX、Oracle EE RAC、運用監視、印刷処理、ストレージ、負荷分散機、太い回線。。
作ったJavaプログラムを動かすのにも、TOMCATじゃサポートないからWebLogic。
18:1
07/04/16 23:55:38
>>15
そりゃごめんな。
けどな、オープン系ではオンスケで開発進むのが普通だと思ってるのかい？
>>16
投資対効果という言葉があるように、例えば100万ならやって欲しいけど、500万
ならいらない、という機能もあるのです。
19:デフォルトの名無しさん
07/04/16 23:57:38
>>17
価値ってどういう計算で出てきたのよ。それがなきゃ曖昧すぎるよ。
だからまず、汎用機の購入価格と、支払ってるサポート料はいくらなのって聞いてるの。
20:デフォルトの名無しさん
07/04/16 23:58:16
> ・１つの箱（同じ汎用機）でいくつものシステムを作る為
そのせいで１システムのトラブルが他所に波及するんだがな。
１つ糞重いジョブが動いたら全システムがレスポンス低下したり。
汎用機とオープン系の連携なんざやってる場合オープン系の多種のシステムにも影響がいく。
21:デフォルトの名無しさん
07/04/17 00:00:29
よくわからんけど、開発工数はオープン系の方が圧倒的に少ないんじゃない？
うちは同じフロアで汎用機とオープン系と両方やってるけど、汎用機やってる連中は
ちょっとしたことやるのにどんだけ稼動かけてんだって感じ。
22:デフォルトの名無しさん
07/04/17 00:00:52
>>14は単に経験とスキルの問題にみえるけど、
オープン・汎用機関係あるの？
23:1
07/04/17 00:07:05
>>19
汎用機はハウジングなので、利用料金。
サポートは6,000万に込み。
で、価値について。
稼動している個々のシステムには、それぞれ開発当初に見積りを行います。
その見積りには、開発費用、システムの規模に応じたインフラ利用料、運用費用等が
含まれます。
システム費用は、利用部門（全社で利用するシステムは本部）が費用を負担します。
当然ながら、金額に納得がいかないなら、開発は中止。
多数のシステム費用の合計は、6,000万よりもっと上。
その差額が、情報システム部門の給料やら飲み代やらになります。
利用部門は当然ながら、システムにかかるコストと、恩恵たるメリットを
上申書に纏め、役員のハンコを貰ってはじめて「金を負担する」と言える
わけです。
つまり汎用機は、利用部門が認めた価値を生み出している、と言える訳です。
24:デフォルトの名無しさん
07/04/17 00:08:10
ブランコの風刺画
URLﾘﾝｸ(www.cagylogic.com)
25:デフォルトの名無しさん
07/04/17 00:10:33
＞当然ながら、金額に納得がいかないなら、開発は中止。
汎用機なんかで見積もり出してたら、全部中止になっちまわね？
26:1
07/04/17 00:15:33
>>20
そのためにオペレータがいる。
又、周りの人間が「おかしいことやってる」とつっこめる。
しかしオープン系では、自由度が高すぎていまいち外から見えにくい。
>>21
例えばSAPで基幹システムをリニューアルしようとすると、100億はかかる
と試算されました。たっけーよ。
>>22
汎用機は、１０年前の経験、スキルが武器となる。
オープン系は、１０年前の経験の半分が思い出だけになる。
>>25
汎用機１台で、多数のシステムを稼動させています。
つか、基幹系全部と＋＠
27:デフォルトの名無しさん
07/04/17 00:19:25
>>23
なるほどやはり、月6000万か。
それが月6000万以上の利益を生んでいるのはそうなんだろう。
しかし、オープンで月1000万に抑えたら、毎月の利益が5000万増えるんだが。
年間で６億をどぶに捨てるってのは、いくら儲けてる会社でも無視すべきではないと思うが。
28:デフォルトの名無しさん
07/04/17 00:22:45
＞オープン系は、１０年前の経験の半分が思い出だけになる。
この辺、単なる願望くさい。
29:デフォルトの名無しさん
07/04/17 00:27:15
>>28
俺も、半分は言い過ぎと思うな。表面は変わっても経験は生きる。
逆に、汎用機は10年前と(ハード性能以外)変わっていないのか？
30:1
07/04/17 00:34:03
>>27
全くもって無視してません。
そして、月1,000万に抑えるのは非常に難しい。
いろんな会社さん、その思惑でもってSAPを導入したものの、なかなかうまく
いってない。
オールJavaやオール.NETで基幹システム成功した事例があったらご教授下さい。
>>28
乱筆で失礼しました。
１０年もあれば、技術的な部分は大きく変わる。
そうすると、「判断」する為の材料としては弱い。
当然ながら、プロジェクト管理経験、業務知識等は有益なノウハウ。
31:1
07/04/17 00:42:02
>>29
言い過ぎました。３割に訂正。
しかし、肝心な判断材料のネタにパラダイムシフトは痛い。
汎用機も変化する。
しかし、その変化を少数の専門家でもって吸収することが出来る。
オープン系では、そもそも動かない事が多い。
Oracleのバージョンが変わって仕様が、JDBCが、Windowsが、APIのインターフェイスが、
DOSの○○命令が無くなった、、。
基幹システムなんて、サブシステムでも億単位なので、数年サイクルで再構築なんて
やってられません。
又、汎用機には少なくとも、
・再起動したら直った
・もう一度動かしたら正常終了した
なんてのはない。
32:デフォルトの名無しさん
07/04/17 00:49:06
>31
俺オペレータだが、残念ながら
> ・もう一度動かしたら正常終了した
は汎用機でも存在するぞ。
> ・再起動したら直った
はあまり聞かないがな。
33:デフォルトの名無しさん
07/04/17 00:52:25
つか、基礎的な技術の理解無しに「最新の技術だけ」習得することなんて出来んぞ。
JDBCやWindowsのAPIなんて枝葉もいいとこ。
34:デフォルトの名無しさん
07/04/17 01:06:07
>>30
オープンで、数台でサポート料＋ハード＆ソフトの償却で月1000万超すなんてのは普通ない。
システム開発が汎用機よりブレやすいってのはあっても、
ここで問題なのは基盤としてのコストなんだから、それは直接関係ない。
まず固定の費用で数倍から数十倍の差がある。それをごまかしてはいけない。
その差を埋める汎用機のメリットを、定量的に示さないとダメ。
>>31
＞しかし、その変化を少数の専門家でもって吸収することが出来る
ノウハウが溜まってるってのと矛盾するな。
35:1
07/04/17 01:11:07
>>32
>> ・もう一度動かしたら正常終了した
>は汎用機でも存在するぞ
そこは、マスタの状態とか、参照整合性的なものとか、処理日が
違うことに起因する問題ではないでしょうか？
Windowsでは、それら全く関係無しに起こりえます。
もしそれらが同じ状態で起こるなら・・・、勉強不足でした。
しかし、銀行振込みデータや請求書、決算書作る処理でそんなこと
起きたら、恐ろしいですね。
>>33
そこは汎用機と同様、本人の勉強でカバーするところだと思います。
しかし、その枝葉が変わる影響が理不尽にでかすぎる。
オブジェクト指向の「設計」なんて、もてはやされた割には廃れてしまった。
（もちろん、オブジェクト指向型言語は申し分なし）
Java Appletも昔は・・・。
ＳＯＡなんてのも、どうなることやら。
36:デフォルトの名無しさん
07/04/17 01:22:57
技量で生産性が変わるのが良くないって理屈？
最低レベルの生産性に強制的に合わされる＝見積もりし易い環境よりも、
技量によってはより高い生産性を獲得できる可能性がある環境のほうが
よいのじゃありません？
37:1
07/04/17 01:26:48
>>34
>>1にも書いたとおり、業務系基幹システムを想定しています。
会計（決算）、受注出荷、生産、債権債務管理、請求入金、原価計算等々
を動かすのに、そんなに安く出来るでしょうか？
Oracle EE 500万（Intel系２コアあたり）←デュアルコア４つのせて、2000万
Oracle RAC 250万（同上）
ストレージ 数千万（バックアップ装置だけでも数百万）
それぞれ、保守費は年額で購入費の20%が相場。即ち５年で倍。
RACやBlade、障害設計の設計・設定SE費で計1000万～3000万。
汎用機と違って壊れやすいので、冗長化が必要。
汎用機は１０年償却。
サーバは３～４年償却。
具体的な数字を書くのは簡便して貰いたいが、売上げ数千億、社員数千人の会社
の基幹システムと思って欲しい。
数台のサーバで賄えるとは思えない。
>＞しかし、その変化を少数の専門家でもって吸収することが出来る
>ノウハウが溜まってるってのと矛盾するな。
？
38:デフォルトの名無しさん
07/04/17 01:42:43
Oracle+WebLogicなんて、はっきりいって何もいいことないからなー。
39:1
07/04/17 01:43:21
誤字脱字が多いのはごめんなさい。
殴り書きで読みづらいのもごめんなさい。
汎用機に対して優位性が本当にあるのか、真剣に疑問なんです。
40:デフォルトの名無しさん
07/04/17 01:44:59
周辺系システムについてはどう考える？
41:デフォルトの名無しさん
07/04/17 01:50:25
>>37
月額と購入費をごちゃになってるので整理すると、
月額１０００万となるには…
償却を４０ヶ月として、月額は、初期購入費÷４０
サポート料は、月額（初期購入費÷５）÷１２。
初期購入費÷４０＋（初期購入費÷５）÷１２＝１０００万
初期購入費×３＋（初期購入費÷５）×１０＝１２００００万
初期購入費×５＝１２００００万
初期購入費＝２億４千万
初期購入費だけ（当然開発費やそのほかの費用は含まず）で、２億４千万のシステム。
売上げ数千億、社員数千人の会社なら、こんなもんじゃないの？
42:デフォルトの名無しさん
07/04/17 07:26:51
>>38
それだけは激しく同意
43:デフォルトの名無しさん
07/04/17 09:51:10
>>38
の理由はわからないが
汎用機と連携する時に俺の相手が痛い連中ばっかだったのでしんどい目を見て以来
汎用機が嫌いになった
たまたまかもしれんが･･･
44:デフォルトの名無しさん
07/04/17 10:36:27
何がダメかって語りは基本的につまらない
批評っつーのは才能であり芸だからな
1はもっと積極的に汎用機の利点をアピールすべき
汎用機バッシングにもおなじことが言えるんだけど
45:デフォルトの名無しさん
07/04/17 11:58:25
>>1
SAPがオープン系だったら絶対使うが・・・。
46:デフォルトの名無しさん
07/04/17 17:34:36
オープン系でも汎用機でもどっちでも良いよな
業務に影響が出なければ
あともっと安くなるといいよね
47:1
07/04/18 00:20:54
>>40
帳票処理などの専用サーバのことですか？
それとも、データウェアハウスなどの戦略型システムのとですか？
>>41
業種にもよるが、製造業、流通業などでは、売上げの１％を情報システム投資に
まわすのが一般的。（とSIerさんが言ってた）
不思議とうちもそれに当てはまり、年額で数十億が掛かっている。
そのうち、インフラに関しては汎用機、サーバそれぞれ前述の通り。
あなたの口調からすると、お金周りのことは想像で話していると見受けます。
社内構成の話はさすがに出来ないので、インフラのアドバンテージは少ない、
としか言えません。
逆に言えば、オープン系のメリットはそれだけでしょうか？
48:デフォルトの名無しさん
07/04/18 02:03:29
あんた言葉遣いは丁寧だけど、全く論理的じゃないし話があちこち飛ぶな。
あきらかに汎用機が不利なポイントだからわざと話を拡散してごまかしてる？
事実：ハード＋ソフト購入＋サポート費をひと月１千万に抑えたら、毎年５億浮く。２千万なら４億浮く。
事実：毎年５億浮くのは、ハード＋ソフトの初期購入費だけで２億４千万規模の場合。５億規模なら浮くのは４億。
汎用機なら別だが、オープンなら２億４千万でそれなりに揃う。５億掛けても毎年４億浮く。
オープン化を否定するには、
その毎月６千万のシステムをリプレースするのに、初期購入費がこの額に納まらない事か、
リプレースによる損失リスクの期待値が年額５億か４億を上回ることを示す必要がある。
いっとくけど、オープンに切り替えるってのは頭も切り換えるって事。
念のため念のためで取捨選択せずにストレージにドバドバ金注ぎ込むとかは無し。
49:1
07/04/18 02:53:52
>>48
というか、論点がかみ合ってないのは間違いなさそうです。
>オープンなら２億４千万でそれなりに揃う。
１日１０万件のトランザクションと、同数程度の印刷、数１０万の検索が
行われる基幹システムです。
定時間内のサービスダウンは許されません。
インフラ面は大手ベンダ数社とも打合せをしており、それなりのレスポンスを確保し、障害対策を
汎用機並みに行うと、価格面でのアドバンテージが無いことは結論として出ております。
従ってインフラ価格の面は不毛だと思ったので、こういう事は開示していませんでしたし、
「インフラ以外で」と何度も主張しました。
#加えて、インフラのお話は板違いなので、話にも出ないと思ってました
うちの環境をコンサルして欲しい訳ではなくて、プログラム技術板らしい観点で、
「業務システムをオープン系にするメリット」
を教えて頂けると嬉しい。
50:デフォルトの名無しさん
07/04/18 10:21:02
>>49
ム板向きの言い方をするなら、
HaskellとかPrologの切り口を付けたいと言うときに
・ プログラマが得られない。
・ コンパイラが得られない場合が多い。
このような場合、他システムとの連携を設計思想とする
オープン系だとうまくいく可能性がある。
51:デフォルトの名無しさん
07/04/18 13:47:33
汎用機は後継者が育ちにくいだろうな
オープン系のプログラミングは自宅でも学べるし
多くの学校でも教えている
だが汎用機なんて個人じゃ持てないし
学校で置いてあったとしても古かったり
JCLが異なったり思うようにいかない
おまけに変なジジイばっかの環境でメイン言語はCOBOL…
52:デフォルトの名無しさん
07/04/18 13:52:44
確かに長いこと同じような環境でやってるジジイどもは
そこの環境や動いてるジョブの保守はよく出来るだろうが
それ以外の人間には理解不能な環境になってることも多い
ジジイどもがくたばったら後が続かないんだよ
53:デフォルトの名無しさん
07/04/18 15:50:59
典型的な後だしじゃんけんだな
どんどん条件が増えていく>>1にご期待ください
54:50
07/04/18 18:10:13
以下の話は規模によって事情が違うと思います。それを断った上で。
事務計算は記号処理部分をPrologで記述し、十進演算をCOBOLで
処理するという切り分けがシステムのSDLCの観点から本来は望ま
しかったと思う。しかし、アトムが増え続けるPrologのような系を
汎用機に本格的に導入することは危険であり、それがこのような
方向のシステムが開発されなかった理由です。
オープン系の開発だと、HaskellやPrologといった高級言語系を
別のサブシステムに分離する設計が可能で、業務システムを
抜本的に洗練された記述で知識化する道筋が漸く開かれるのでは
ないでしょうか。
55:デフォルトの名無しさん
07/04/18 21:54:48
>>49
一日たった１０万トランなのに２億４千万円じゃ不足って、ベンダにとって最上級の鴨だな。
（その半分が定時前１０分に集中する、とかならともかく）
そもそも、ベンダにとっては汎用機の方が利益率が圧倒的に高いんだから、
それを基準にしてる客に、安上がりの提案なんかするわけがない。
＞障害対策を汎用機並みに行うと、価格面でのアドバンテージが無い
>>48の最後の２行読んだ？
それは、汎用機並みに行うじゃなくて、汎用機のやり方で行う、の間違いだろう。
しかし、そういう思考の人間しかいないなら、確かにオープンにするのはリスクばかりでコストも下がらんかもな。
>>36も言ってるが、プログラミングセンス最低のＰＧに合わせるのがCOBOLだが、
ほんとに最低ばかりなら、しかも組織風土がＰＧをコーダー（パンチャー）みたいに考えてるなら、
オープンの生産性メリットも得られないだろう。
それで下手にオープンの底辺ＰＧを外注したらもう破綻しかない。
＞プログラム技術板らしい観点で、
これってどういうのを言ってるの？ どっちもコンピュータなんだから、
汎用機でだって方法が変わってもやれば出来るに決まってんじゃん。
だからどうしたってコストの比較は捨て置けない。
56:1
07/04/19 00:42:07
>>55
４ベンダが談合し、うちを鴨っているということでOKです。
できれば、240百万でどんな構成のサーバを作るのか、簡単に教えてくれると幸いです。
ほかの方たちの意見は、技術者育成問題ですか。
たしかに今、ITSSなんていう体系もあります。
しかし、勉強には本人の自覚と意識による部分が非常に大きく、優秀な技術者とそうでない技術者の
二極化が問題となっています。
技術に興味を示さない人は、生産性があがらないばかりでなく、問題の種になったりする。
かといって組合がある以上、個人の生産性云々で解雇は不可能。
汎用機は、各社標準化がきっちり成されており、優秀でなくてもコーダーにはなれた。
そして、有識者によるコードレビューもやりやすい。
又、オープン系は、言語やフレームワーク毎にコーディング基準が必要で、学ぶべき範囲が
非常に広くなる。
57:デフォルトの名無しさん
07/04/19 01:39:28
常に up to date にしてようと思ったら、結局学ぶべき範囲は非常に広いから問題無す。
学ぶべき範囲みたいなのが明確に定まっていて、しかもそれが十分に狭いなら、それは
儲からない仕事だろうね。
58:デフォルトの名無しさん
07/04/19 19:20:08
ITSSの体系が整備されていくと社内SEって人達は言語とは完全に切り離されるよ
59:デフォルトの名無しさん
07/04/20 00:48:19
>>56
断っておくけど、俺自身は関連する職だがSEじゃない。
しかし、SE達が基幹と呼ぶシステムの情報からは、
１０万トラン/日の規模で浮かぶのはこんな感じ。OracleをSEにしたい気すらする。
RAC４台（サーバ込み１０００万×４） ４０００万
APサーバ４～８台（同５００万×８） ４０００万
運用管理 １０００万
ストレージ ３０００万
バックアップ ３０００万
ネットワーク（分散込み） ２０００万
テスト系・ほか のこり
＞しかし、勉強には本人の自覚と意識による部分が非常に大きく、
＞優秀な技術者とそうでない技術者の二極化が問題となっています。
＞かといって組合がある以上、個人の生産性云々で解雇は不可能。
分かってるじゃん。で、その切れない不勉強技術者の割合は？
それが高ければ上に書いたとおり、オープンじゃ破綻のリスクありだ。
しかし、汎用機の思考でよく分からないのが、>>31の
＞又、汎用機には少なくとも、
＞・再起動したら直った
＞・もう一度動かしたら正常終了した
＞なんてのはない。
だ。直って欲しくないの？調査はコアなりログなり取っといて後でじっくり調べりゃ良いじゃん。
60:1
07/04/20 02:19:36
で、既存のオープン系システム
１．DB許容量について
価格からみて、１ＣＰＵのサーバ４台と判断します。
Xeon5160を積んだと想定しても、無理です。
（クアッドコアだと、その予算に収まりません）
キャッシュフュージョンって知ってますか？
４台積めば、４倍の処理能力になるわけではありませんよ？
１０万トランザクション／日を賄えるとも思えないし、更に
数１０万の検索がある。>>49参照。
トランザクションというのは、イメージ沸きますか？
１つのトランザクションには、例えば受注でも複数品目が登録
される。
生産処理において、１つの物を作るには、多数の原料が使われる。
即ち、１つのトランザクションにおいて多数の在庫更新、原価計算等
が行われます。
更にビジネスロジック以外の処理として、入力内容のチェック、ログ、
エラー処理等も必要。
ちなみに検索対象というのは、小規模データの検索もあれば、上記
のように膨らんだデータを検索することもあります。
経験上、１ＣＰＵ４台じゃまず無理です。
２．導入作業費
あなたの仰る構成だけでも、導入ＳＥ費に1～2000万はします。
キャッシュフュージョン対策を行うなら、その倍では済みません。
61:1
07/04/20 02:20:16
>>60へのコピペミスです。。。
先頭に、以下があると思ってください。
>>59
割とまともな価格感がでてきたので多少驚いてます。
俺は職種でいうとSEです。
62:1
07/04/20 02:24:34
３．残りといっている7000万では賄えないサーバ、パッケージ
負荷分散装置
開発用ＤＢ
開発用ＡＰ
印刷処理
認証関連
モジュールの配布
パッチ適用関連
企業内FW関連
障害検知
ネットワーク上のデータが膨らむことによる回線の増強
その他、ストレージは3000万で収まらないだろうし、開発（又はテスト）ＤＢ
にもストレージが必要になる。
不勉強者の割合は、意味が無いので割愛します。
>だ。直って欲しくないの？調査はコアなりログなり取っといて後でじっくり調べりゃ良いじゃん。
直って欲しいです。
しかし、後でじっくり調べても分からないことがあります。
再現性がなければ、コアダンプが無かったり、ログが不足したりします。
ログがあっても、ＭＳ有償サポートでも分からない（自分んトコは悪くないと
言い張る）、ベンダさんでも分からない（同）こともあります。
63:1
07/04/20 02:35:03
株式会社 基幹 サーバ台数 例
で、ぐぐってみました。
URLﾘﾝｸ(www.google.co.jp)
サイジングのイメージが掴めると思います。
64:デフォルトの名無しさん
07/04/20 02:55:07
横槍ｽﾏﾝが、1 トランザクションの重さなんてシステムによって全然違うでしょ。
あと、Xeon で Windows なのは決まりなの? 汎用機から Windows とは
急転直下だねw
65:デフォルトの名無しさん
07/04/20 09:22:12
日本のソフトウエア産業、衰退の真因
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
以上のような様々な問題点に加え、日本のソフトウエア開発の産業構造には、決定的な欠陥がある。
ソフトウエア技術者の派遣ビジネスである。
大規模な開発プロジェクトの場合、ソフトウエア開発の仕事は、ほぼ例外なく複数の会社に分割発注される。
ところがソフトウエアシステムをサブシステムに分割して請け負わせるケースは少なく、
多くの場合、「一カ月いくら」で契約する派遣プログラマーを雇い、プロジェクトチームに組み込む。
派遣会社の間で技術者を貸し借りするので、技術者が多層化する。いわゆる多重下請け構造である。
発注者でさえ、実際の階層数や末端の会社名を知らない。ある政府のプロジェクトで、
危険視された宗教の信者が最下層に参画しており、それに管理者は気付かなかったという話さえある。
当然、開発責任は曖昧になる。厄介なことに、派遣契約の多くは請負契約を装っているので、
書類だけでは実態はわからない。
派遣がすべて問題なのではない。現に欧米でも派遣に相当する契約はある。
それは、開発規模を決めるビジネスモデルをコンサルタントが作る場合や、
不確定要素の大きい革新的なプロジェクトでリスクを避けるために使われる。
また、成果物の品質責任を問われない事務的な仕事では、派遣は便利な形態である。
しかし、品質に関して重大責任を負うに至ったソフトウエア開発ビジネスで、
成果責任を負わない派遣形態がかくも横行しているのは日本だけである。
66:デフォルトの名無しさん
07/04/20 12:41:16
そのレベルでその値段とは時代にそぐわないすげぇボッタクリシステムだな～
67:デフォルトの名無しさん
07/04/20 14:17:19
>>63
住友電気工業っていうのは何をやってる会社だろう。
68:デフォルトの名無しさん
07/04/20 14:21:34
DB設計が糞ってことはない？まともなDB技術者がやってる？性能考えて取捨選択してないでしょう。
テーブル内容も、なんでもただナイーブに突っ込んでみましたみたいな。
IsolationもSerializableとかしてそう。
69:デフォルトの名無しさん
07/04/20 16:17:54
>>54
業務ルールを他と分離しましょうってお話は、3月中にあっちのスレ
ｽﾚﾘﾝｸ(prog板:373番) (方針と実装の分離原則)
でさんざやったよな～
今更恥ずかしげもなく何を言い出してるの？
70:デフォルトの名無しさん
07/04/20 23:09:44
>>62
言いたい事はいろいろあるけど、特に３の半分は贅沢。定時外なら計画停止ありなんだろ？
汎用機系は、オープンからみて、コスト意識が欠如してるように見える。
役人体質というか。100%でなく97%にすればコストは半減。
あとは選択・技術・運用ルールでカバーする。
それはともかく、1000歩譲って２億４千万で足りないとして、
倍にしても、毎月４千万浮く。年間で毎年５億のコスト減。
71:デフォルトの名無しさん
07/04/21 00:03:44
業務屋って陳腐なシステムしか作れない癖に
話を大袈裟にして大金ふんだくろうとするから
業界で嫌われてるんだと思う。
お前らには文系出身の似非コボラーがお似合いだ。
72:デフォルトの名無しさん
07/04/21 01:53:51
>>62
＞又、汎用機には少なくとも、
＞・再起動したら直った
＞・もう一度動かしたら正常終了した
＞なんてのはない。
＞再現性がなければ、コアダンプが無かったり、ログが不足したりします。
直るのが最善は当然として、わからなかったら仕方ない。
業務データを間違うって障害ならそうも言えないが、
情報部門の趣味のために業務を止めるなんて、発想が根本からおかしい。
73:デフォルトの名無しさん
07/04/21 13:40:43
要するに
・実績が少ないと不安だからヤだ
ってことじゃないのか？
その一言で片づければ、ベンダもユーザの気持ちも少しはわかるが。
74:デフォルトの名無しさん
07/04/21 16:00:50
>>67
弱電系で商売になる物は何でもじゃないの？
そう言う事じゃなくて？
75:デフォルトの名無しさん
07/04/21 19:00:40
私も昔はU-Stationのユーザだった。電線だけ売ってるのでない
ことはわかる。でもシステムが障害を起こすと人命にかかわる
業務はそれほど多くはないだろう。これほどITを厚くする理由
が正直わからない。何をしているか、とはそんな意味。
76:1
07/04/21 20:38:07
>>72
あなたひょっとして、エンドユーザか学生さん？
雑誌や情報処理の教科書をそのまま信じているだけに見えてきた。
現場を（ＰＭ・ＰＬとしてでも、ＳＥ・ＰＧとしてでも）見れば
当たり前のことを、さも自慢げに語る。
言葉に重みを感じない。
あなたの理屈でいえば、投資対効果でいえば比べるまでもなく汎
用機に利点はないことになる。
では何故、何年もの間、「基幹システムのオープン化」という
キーワードが無くならないのか？
情報システム業界の２００７年問題なんてものが取り沙汰される
のか？
（ＳＡＰ導入企業が増えたことで減りはしたが、ＳＡＰを強行導
入した各企業の憂鬱は業界では有名）
77:1
07/04/21 20:39:13
>言いたい事はいろいろあるけど、特に３の半分は贅沢。定時外なら計画停止ありなんだろ？
勿論です。
例えば、一部を除いて２０時でサービス終了でも構わない。
>役人体質というか。100%でなく97%にすればコストは半減。
１年の営業日を240日と過程します。
240 × 0.03 ＝ 7.2
１年のうち、7.2日分のシステム停止は考えられない。
企業である以上、何かしら物・サービスを売っている。
受注、出荷、購買、生産、会計で、システムに頼った業務を行って
いる人が1000人と仮定する。
又、１日８時間労働。福利厚生等々込みで平均時給を3,000円とする。
57.6時間（7.2日） × 3,000円 × 1,000人分 ＝ １億7280万
止まっている時間だけでこれだけ掛かる。
その間、ユーザ部門は代替手段の模索、実施に追われる。
復旧後、それまでの代替手段とシステムの辻褄あわせに手をとられる。
協力会社への影響を考えるともっと膨らむ。
更に出荷が遅れることによる信用失墜の損害は計り知れない。
あなたはこれだけ非現時的な話を、鬼の首を取った様に述べている。
以上により、あなたは基幹システムに関わったことが無いと確信した
78:デフォルトの名無しさん
07/04/21 21:05:35
このスレ、あちこちの計算がデタラメで笑えた
79:デフォルトの名無しさん
07/04/21 21:09:20
誰かの脳内対話ではきっと動かしがたい真実なのだろう
80:1
07/04/21 22:26:05
>>78
具体的にどうぞ
81:デフォルトの名無しさん
07/04/22 00:09:33
>>1 は以前 UNIX スレで暴れてた人と文面が似てるんだけど、
世代的な特徴なのかな。部下に仕事を任せて、自分は暇だから
2ch をやってるとか言ってたけど。
82:デフォルトの名無しさん
07/04/22 00:51:01
例のキチガイコンサルが
2007年問題絡みのマイグレーション仕事にありつこうと
必死にもがいてるだけだろ
83:デフォルトの名無しさん
07/04/22 00:54:39
>>78
＞１年の営業日を240日と過程します。
＞240 × 0.03 ＝ 7.2
稼働率が97%なんて言ってないよ。言うはずがないでしょ。
トランザクションがたまに失敗したって、リトライして貰えばいいじゃない。
それがヤバイ時があるなら、ヤバイ時専用にロジックを用意すればいいじゃない。
どこかがコケけたら、その間だけは方肺でレスポンス時間が3倍になったっていいじゃない。
本当の本当にリアルタイムなビジネス遂行にクリティカルじゃない奴は、別の安上がりシステムでいいじゃない。
そういうことを言ってるんだよ。要求に対する考え方をいってるんだよ。
ずっとやってきた思考をいきなり切り替えるってのは難しいだろうけどね。
それまでのやり方に、あんたなりの誇りみたいな物があるんだろうし、それはそれで意味はある。
だが、供給側のこだわりが本当の需要を正しく射ているとは限らない。
利用者に対しても経営者に対しても。
84:デフォルトの名無しさん
07/04/22 01:02:27
>>76
あんた、全然>>72に反論出来てないよ？解ってる？
それを理由とするのが自分の主張を否定すらしうるって解る？
85:デフォルトの名無しさん
07/04/22 01:06:15
ｼﾞｻｸｼｴｰﾝ
86:デフォルトの名無しさん
07/04/22 01:09:53
空理空論と空理空論のガチンコでアミダのトグロｗ超絶無意味
87:1
07/04/22 01:24:24
>>83-84に関しては、
>当たり前のことを、さも自慢げに語る。
>言葉に重みを感じない。
で、答えになってると思っている。
あなたのほうこそ、
>では何故、何年もの間、「基幹システムのオープン化」という
>キーワードが無くならないのか？
>情報システム業界の２００７年問題なんてものが取り沙汰される
>のか？
に、答えてみて下さい。
88:デフォルトの名無しさん
07/04/22 01:42:42
深夜の自問自答
それは自殺の兆候
89:デフォルトの名無しさん
07/04/22 01:50:13
>>86
ここでアルマゲドンしている内は、他に被害が行かないから良いんじゃない。
90:デフォルトの名無しさん
07/04/22 01:52:07
kwsk
91:デフォルトの名無しさん
07/04/22 02:04:16
まさか、ここまで版画の魔手が及んでいるのか？くわばらくわばら
92:デフォルトの名無しさん
07/04/22 02:05:42
汎用機の良さをきちんとアピールできない>>1は
ウンコみたいなマイグレーションにたかる銀バエが作り上げた仮想人格。
93:デフォルトの名無しさん
07/04/22 02:12:26
>>44
こいつは汎用機の知識はもちろんのこと、
オープン系の知識もテキトーなゴミだから
それは能力的にムリ
94:デフォルトの名無しさん
07/04/22 02:14:27
>>1
あんたさぁ、自分が信じることをやればいいじゃないよ。
俺はクリティカルなことはやっぱ汎用機に分があると思ってる。
だいだいハードもソフトも極度に限定されるんだから、その分安定して動いてもらわなきゃ困るさ。
安定して動かすために金をかけるわけですから。
ただ今のご時世、70がいうところの100%を望まなくてもいいんじゃない？って会社もでてきてる。
そういうところがオープン化して安くすませるわけでしょ？
オープン系と汎用機を同列に見てるのがそもそも間違いなのよ。分かった？
適材適所ですよ。保険とおんなじだって。
高額でも手厚い保障を望む人もいるし、保障は最低限でいいから安いのを選ぶ人だっている。
選ぶのは買う人(会社)なんだから、売り手の押し付け論理は通じませんよ。
市場で勝負していけばいいじゃん。
どっちかか負けてなくなるかもしれないし、比率は変わっても両者生き残っていくかもしれない。
自然と答えは出るでしょ。
95:デフォルトの名無しさん
07/04/22 02:15:16
なんと空虚な文章・・・メーカの人間が見たら泣くだろうな
96:デフォルトの名無しさん
07/04/22 02:15:49
営業出身だからこんなもんだろ
97:デフォルトの名無しさん
07/04/22 02:20:00
科学技術分野だと、専用機の地位はここまで低くないんだけどな。
特に国内の地球環境とか素粒子物理分野。
アメリカさんがとっくにあきらめた、専用計算機やベクトル計算機の技術が
未だに重宝されてて、超並列機と住み分けているような状態。
98:デフォルトの名無しさん
07/04/22 02:23:46
あの分野は伝統保存芸能扱いだからなｗ
99:デフォルトの名無しさん
07/04/22 02:37:54
やけに伸びてるなｗ
>>87
それはつまり、>>84の答えを教えれってことだね。
簡単だよ。
>>76はあんたは単に俺に悪態を付いてるだけで、なんら反論してない。
代わりに「基幹オープン化」「2007年問題」のキーワードを持ってきただけ。
>>77は反論の形にはなってるが、趣旨を外してるので無意味。
なんで「基幹のオープン化」って言葉がなくならないかって？
そりゃあんたみたいのがウジウジと二の足を踏んでる、あるいは踏ませてるからだよ。
物事にはただでも慣性があるんだから、抵抗勢力が居たらますます変化は遅れる。
あんたはいわゆるLaggard。それはそれでいいけど、みんながそうだと思うのは間違い。
「2007年問題」が騒がれる？そりゃあんた達がそういう事態を作ってるからじゃないか。
というわけで、あんたが引っ張ってきたネタも、なんら>>72の反論になってないんだよ。
100:デフォルトの名無しさん
07/04/22 02:48:00
ダメコンサルの化けの皮がとうとう剥がれたなｗ
恫喝営業は受け付けないよ。さっさと巣に帰れ
> あんたはいわゆるLaggard
俺はモルツ頼むわ
101:デフォルトの名無しさん
07/04/22 02:51:30
脳内議論にしても、あまりに乱暴だと思った
この先、その調子でうまく営業していく自信ある？
102:1
07/04/22 03:00:13
>>99
不思議と、全く同じ感想をあなたに持っている。
「悪態をついているだけ」「反論していない」「論旨がずれている」
まず、言葉に具体性が無い。
又、根拠なしの結論が多い。
出来れば、事例とか調査結果とか示してくれないだろうか？
インフラ費用の話は平行線が続いてるけど、それ以外にオープン系
のメリットはないのかね？
103:デフォルトの名無しさん
07/04/22 03:02:18
相手から望んだ答えを得られないのは、相手の話をちゃんと聞いていないからだよ。
これ昔からの真理ね。
104:デフォルトの名無しさん
07/04/22 03:05:10
また ゲイ の細かい自作自演だこと
105:デフォルトの名無しさん
07/04/22 03:53:20
>>76のどこら辺が反論になっているのか、小一時間…。
まあそれはともかくだ。現場のSE経験はあんたが圧倒してることは確かだ。
言葉に具体性がない？それは手痛い指摘だ。正しい。
で、そういう現場に精通したあんたにこそ、具体的な根拠をご教授願いたい。
とりあえず、>>62だ。
残り7000万では賄えないと列挙した物が、
本当に必要不可欠な範囲で7000万で賄えない、具体的な根拠。
ストレージは3000万で収まらない、具体的な根拠。
ガツンと示してくれないだろうか。
106:デフォルトの名無しさん
07/04/22 04:25:39
前提条件も定かじゃないのに、何億円で収まる収まらないの話しても
意味が無いと思うので、もっと話を続けて下さい。
107:デフォルトの名無しさん
07/04/22 07:58:52
まー、正直マイグレだけで数十億ポーンと飛ぶようなプロジェクトを見てると、
オープン化へ進んでるのはただ、今後の保守が技術者減って大変ですおと言ってるだけに感じる。
108:デフォルトの名無しさん
07/04/22 08:30:12
こんな議論しかできない奴とだけは
一緒の仕事したくないな。
無意味な主張に必死になっちゃって
火病かよ
109:デフォルトの名無しさん
07/04/22 11:19:03
俺はオープン系だけど、UIだけWindowsに外出しする仕事が
多いです。
110:デフォルトの名無しさん
07/04/22 12:20:20
中出しの方が好きです。
111:デフォルトの名無しさん
07/04/23 11:46:32
これだから業務系とは会話にならないな、と思った漏れは制御・情報系。
112:デフォルトの名無しさん
07/04/23 12:53:07
汎用機はそんなに売れないからもっと値段上げても良いですか？ってメーカの質問にNoと答えたのがユーザー
なにか勘違いをしているが作り置きで余っているならともかく、受注生産品で売れない物は値段を下げて作っても仕方が無い
だからオープン系に移行してるだけなのだが
そもそも安くしろってのはユーザー側の要件なんだよ
性能の劣化とコストダウンを計りに掛けて考えるのが良いSE
113:デフォルトの名無しさん
07/04/24 03:41:21
インターネット技術のいい加減さでも業務で支障無いから、汎用機なんてゴミ。
原子炉制御とか、エラーで大規模事故にでも成る用途でもない限り不要だ。
つーか、汎用機の信頼性以前に、汎用機のプログラムミスでエラーが多い件に付いて。
定時のバッチ処理すらまともに処理できないなんて異常。オープン系のようにリアルタイム処理なんて絶望的だわ(w
銀行とかで汎用機使ってるのは行員には嬉しいだろう。
でも預金者には、インターネットで口座チェックや振込出来たり、一円でも安い手数料のほうが嬉しいのであって、高コストの汎用機を求めている訳ではない。
業務ユーザもオープン系にしてコストダウンできる分だけ、給料や賞与で還元受けるなら汎用機なんて捨てたいよ。目的は業務を管理したいだけで、汎用機を使いたい訳じゃないし。
汎用機を売りたがる／導入したがるのは、汎用機技術者の利己主義に過ぎない。
114:デフォルトの名無しさん
07/04/24 21:40:39
版画は下らない茶々ばかり入れてないで、なんか主張して見ろよ。
115:デフォルトの名無しさん
07/04/24 22:27:03
業務システムは奴隷にやらせとけばいい。
終了
116:デフォルトの名無しさん
07/04/25 03:08:31
そして奴隷のプログラムミスで大事故発生。
りそなのATMシステム障害も検証不十分の奴隷の仕業ですね。
117:デフォルトの名無しさん
07/04/25 09:06:13
URLﾘﾝｸ(www.sankei.co.jp)
118:デフォルトの名無しさん
07/04/25 09:30:53
ほんとあいつらばかじゃないのかと思うんだが・・・・
119:デフォルトの名無しさん
07/04/25 10:09:23
検証不十分を彼らのせいにするのは同業者として間違ってるだろ
むしろそもそも短い開発期間しかないにも関わらず
運用開始日を頑なに守って強引に稼動させた経営側に問題がある
120:デフォルトの名無しさん
07/04/25 10:16:52
自作自演ばかりするお前の存在が間違っている
121:デフォルトの名無しさん
07/04/25 11:09:18
>>119
だからといってバグや不具合を起こしていいわけがない
ミスしたPGの責任は免れない
例えお前の言うような状況だったとしてもな
おまえ仕事したことないだろ？もしくは生ぬるい場所なだけか
122:デフォルトの名無しさん
07/04/25 11:52:07
銀行系で１日遅れたらいったいどれだけ損害賠償請求されるか判らんぞ
123:デフォルトの名無しさん
07/04/25 12:35:15
>>122
一時間でもすごいことになったからな
124:デフォルトの名無しさん
07/04/25 12:38:23
業務システムのトラブルは奴隷が発生原因なのだから
奴隷に尻拭いをさせておけば良い。
抜本的解決策は奴隷の全廃。
125:デフォルトの名無しさん
07/04/25 16:40:56
かくして奴隷PGは低給で短納期でこき使われると。
奴隷PGのわがままにつきあってたら運用開始日は１年後とかだしねえ。
バグが無いプログラムぐらい一発で出してこいよと思う。
つーかちょっと使ってみれば不具合見つかるのにあきらかに確認すらしてないだろうってのが、奴隷PGの仕事。
126:デフォルトの名無しさん
07/04/25 16:43:29
金払いの悪い相手にはそれ相応の対応をされるのが世の常
ああ無情
127:デフォルトの名無しさん
07/04/25 19:05:22
>>125
まあ、奴隷にすら見はなされて数億の損害出してるプロジェクトを見ると
そんなセリフも外には出せない世の中・・・
128:デフォルトの名無しさん
07/04/25 19:21:51
抜本的解決策は奴隷の全廃。
129:デフォルトの名無しさん
07/04/25 21:08:11
そもそもIT化って業務の効率を良くする目的で始めたはずなのに
逆の結果を産んでないか？
130:デフォルトの名無しさん
07/04/25 23:30:50
国内の場合、ＩＴのアウトソーシングが進みすぎていて
企業側情報システム部門が弱すぎるのだろう。
現場に突っ込んでいって業務改善する力もなく
ただメーカやSIの言いなりになってシステム構築するだけ。
それが国内でマイクロソフトやＪａｖａみたいなのの
企業システムがうまく展開できない理由だ
って誰かがblogに書いてたｗ
奴隷ちゃんガンバ
131:デフォルトの名無しさん
07/04/26 00:10:16
だってホントは誰もシステム化なんて望んでないんだもん。
たとえ非効率の極みであろうと誰しも自分の居場所を失いたくは無い。
132:デフォルトの名無しさん
07/04/26 02:31:59
>>131
それが一番デカいよね
結局経営者の都合だからうまくいくほうがおかしい
133:デフォルトの名無しさん
07/04/26 06:17:42
Win上で動かせる
汎用機とターミナルのエミュってある？
134:デフォルトの名無しさん
07/04/26 06:29:09
ある
135:デフォルトの名無しさん
07/04/26 06:33:29
なんだ相変わらず他人とろくすっぽ会話できねぇのか
だらしない奴だな
136:デフォルトの名無しさん
07/04/27 12:13:10
奴隷PGは隣の席同士でもメールでしか会話しない。
生産性悪すぎ。
137:デフォルトの名無しさん
07/04/27 16:45:45
理解できねーな
138:デフォルトの名無しさん
07/04/27 18:41:27
偉大なるSE様は階違うのに口頭でしか指示しない。
記録性悪すぎ。
139:デフォルトの名無しさん
07/04/27 20:48:26
>>138
俺のことですか ごめんなさい
URLﾘﾝｸ(up.kabubu.net)
140:デフォルトの名無しさん
07/04/27 20:50:27
>>139
明日からウチに来ないか?
141:デフォルトの名無しさん
07/04/28 15:54:00
>>1は逃亡したようだが、せっかく立ったんだし、 ここを
ｽﾚﾘﾝｸ(tech板)
の次スレって事にしてはどうか。
142:デフォルトの名無しさん
07/04/28 16:55:12
>>141
おまえ>>1だろ
143:デフォルトの名無しさん
07/04/28 22:22:02
コストが安いから
信頼性？いっぱいハード買っとけばいいよ
144:デフォルトの名無しさん
07/04/29 01:02:44
ハードが安くても、Oracleの値段でそんなん吹っ飛びます＞＜
145:デフォルトの名無しさん
07/04/29 01:16:44
オープン系なんだからORACLE使うのは間違いだろ
MySQLで何が不満？
146:デフォルトの名無しさん
07/04/29 01:20:19
何かとんでもない勘違いをしているな
147:デフォルトの名無しさん
07/04/29 01:25:50
>>145
「オープン」を理解してない小僧っ子か。
昔は（そして今も中堅以上の企業の基幹システムの相当部分）、UnixでもWindowsでもない、
メーカ独自規格のハードとOSで他社の製品と組み合わせられない完全ロックイン状態だったんだよ。
148:デフォルトの名無しさん
07/04/29 01:26:58
おいおいオープン系ってのはLAMPみたいにオープンソースで構成する事じゃないぞ
149:デフォルトの名無しさん
07/04/29 01:31:43
>>148
「オープンソース系」かｗｗｗｗ
最初なんで引き合いにMySQL出てくるかわからなかったｗｗｗｗ
150:デフォルトの名無しさん
07/04/29 01:34:20
>>145
オープンソースとオープン系を間違えてるのか？
151:デフォルトの名無しさん
07/04/29 01:35:51
下らない釣りに食い付き過ぎ
152:デフォルトの名無しさん
07/04/29 01:42:00
じゃあ、プロプラ系でオープンソースがあるわけ？
ないんだったらオープン系の特徴のオープンソースを使う意味はデカいだろ。
だいたい、ただで手に入るのがあるのに、何百万も金払うって馬鹿だろ。
153:デフォルトの名無しさん
07/04/29 01:44:59
またメンヘル出現か
154:デフォルトの名無しさん
07/04/29 03:07:22
根拠が判らず闇雲に有難がってORACLE使う馬鹿が多いのは事実
155:デフォルトの名無しさん
07/04/29 03:22:17
このスレの新しいﾃﾝﾌﾟﾚ： 『根拠が判らず闇雲に有難がって○○使う馬鹿が多いのは事実』
○○には好きな言葉を入れてね。
156:デフォルトの名無しさん
07/04/29 03:54:50
ｽﾚﾘﾝｸ(tech板)
157:デフォルトの名無しさん
07/04/29 05:32:07
まあ実際、Oracleの方が、対応SQLも全然多いし、関数も多いし、
ストアドもあるし、ロックしにくいし、いざというとき（内容はともあれ）サポートもあるし、
当然のようにデフォルトでトランザクションできるし。
158:デフォルトの名無しさん
07/04/29 09:34:32
というか藻まいら、板違いなんじゃ…
159:デフォルトの名無しさん
07/04/29 16:19:49
じゃあ、WebLogicはどうだ？Tomcatで何か不満？
160:デフォルトの名無しさん
07/04/29 16:36:13
関連スレ
ｽﾚﾘﾝｸ(prog板)
ｽﾚﾘﾝｸ(prog板)l50
161:デフォルトの名無しさん
07/04/29 20:11:42
>>159
WebLogicとかTomcatとか、
アプリケーションサーバーであって、
業務システムでは無い！
162:デフォルトの名無しさん
07/04/29 20:33:10
>>161
Oracleじゃなくてもいーじゃん的な話が出たから、その対比だろう。
WebLogicじゃなくてもいーじゃん的に
163:デフォルトの名無しさん
07/04/29 22:48:24
昔は小規模な案件なのに無意味にOracle導入する奴いたけど
164:デフォルトの名無しさん
07/04/30 07:31:31
十年ひとむかし? 十六年はひとむかし、ゆめだぁ?
165:デフォルトの名無しさん
07/04/30 17:56:36
汎用機の10年は全然ひと昔じゃないな
普通に10年前のコードが現役で動いてる世界だ
166:ﾊﾞｸｼｮｳ
07/05/01 00:33:24
>>1
仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。
抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。
167:デフォルトの名無しさん
07/05/01 16:32:01
業務に使うからオラクル入れとくのが安心なのは確か。
趣味なら無料ソフトでも良いが、業務でソフトが無料だからデータ消えましたなんて言い訳通用しないし。
下らん会計処理程度でDB2動いてるのと同じ感覚。
168:デフォルトの名無しさん
07/05/01 16:50:39
まぁオラクルのせいにする為に金払ってる様なもんだし
169:デフォルトの名無しさん
07/05/01 22:21:41
2～3鯖のライセンスなんてカスみたいな値段だしな
170:デフォルトの名無しさん
07/05/02 09:11:25
じつは・・・・オラクル使ったことねぇ････
SQL鯖とかDB2だけだ・・・・
俺ありえねぇ・・・・
171:デフォルトの名無しさん
07/05/02 09:33:34
>>170
そんなことないよ
そう思わされている時点で君もORACLE病
早く洗脳から抜け出せ
172:デフォルトの名無しさん
07/05/02 09:46:52
ＰｏｓｔｇｒｅＳＱＬ使ってるところ無いの？
173:デフォルトの名無しさん
07/05/02 09:49:33
>>172
うち業務でも使ってるよ
PHPと組み合わせてる
174:デフォルトの名無しさん
07/05/03 00:20:13
それってもし業務データに問題が有ったときに誰が首になるの？
良ーく考えよう。業務は大事だよ。
175:デフォルトの名無しさん
07/05/03 00:21:33
下っ端には関係ないね
176:デフォルトの名無しさん
07/05/03 03:07:55
ﾏｼﾞﾚｽすると、客に断りなく勝手にオープンソースを重要な箇所に使ったりしない。
コストとリスクを説明して客に選んでもらう。
177:デフォルトの名無しさん
07/05/03 03:18:55
>>169
カスみたいかも知れないが、その金を工数に使ってたら何人月の補充になるだろう。
178:デフォルトの名無しさん
07/05/03 13:41:03
>>171
Oracle病は多いかも知れないが、アンチOracleは意思決定者を説得する
だけの話術を持っていない。
つまり、結果(Oracle以外を採用させる）を出せない。
小さな会社は別として。
179:デフォルトの名無しさん
07/05/03 14:58:46
>>178
構築ノウハウ含めて考えると、別に移行するほどのメリットないよね、ってことになるからね。
特にＳＩ案件では。
パッケージ販売とかの数売ってナンボな商売だとまた話は変わるんだろうけど…
180:デフォルトの名無しさん
07/05/03 19:21:04
上司説得するより客説得した方がいいよ
181:デフォルトの名無しさん
07/05/04 01:26:33
客は判断できないから頼んで仕事になってると思うけどな。
客が分かってるなら、自前でエンジニア雇ってシステム構築してしまうよ。
客の代わりにおまいが責任もってオラクル以外での不具合の責任を持てばいいだけ。
MySQLを使って発生した１０００万円とかの損失は生涯掛けて補填しますとかさ。
顧客情報流出程度でも５０００円（最高裁判決）×１万人で５０００万円とかさ。
182:デフォルトの名無しさん
07/05/04 01:35:28
>>178
話術じゃなくて理論的な説得材料な。
from 客
183:デフォルトの名無しさん
07/05/04 01:49:12
>>181
話の流れとしてはわかるが、情報流出はDB選定とは関係ないだろう
184:デフォルトの名無しさん
07/05/04 02:27:31
DBに格納する案件として顧客情報って割と多いよ。
185:デフォルトの名無しさん
07/05/04 03:33:26
>>184
そういう問題じゃなくて、DBMS製品とセキュリティ設計は
考える階層が違うだろう。
セキュリティ設計で、個別のDBMS製品に依存する部分は非常に少ない。
186:デフォルトの名無しさん
07/05/04 12:36:57
データ流出をORACLEのせいに出来るってすごいな
187:デフォルトの名無しさん
07/05/04 17:15:11
大体情報流出は，部長のデスクトップに張ってある付箋とか，
ダメ社内SEの持ち込んだUSBメモリとかからだろ．
そこで発生する危機はどんなDBや機器を使ったって軽減できない．
まぁトラブった時にサポートに聞ける，とか，
パフォーマンス関連でモラクルに一日の長がある部分も多いけどな．
188:デフォルトの名無しさん
07/05/04 17:38:33
>>187
「持ち出して盗難」「こっそり売り」を忘れてる
189:デフォルトの名無しさん
07/05/05 01:50:13
>>181
ありえない。
SEが年間どれだけのシステム作るか知らないでしょ？
永久補償（わざとこの字）とかありえない。
それに客に求めているのは技術力じゃないよ。
リスクとコストどちらを採るか判断して貰い、責任を取って貰うことだ。
責任というものがどういうものか実感してから出直してこい。
客が望んでいるのは無茶とか無謀なサポートするベンダーじゃないよ。
自分達がどこまでできるか理解していて、一緒に悩みながらシステムを安定運用に持って行くことだ。
190:デフォルトの名無しさん
07/05/05 08:43:01
オラクルなら不正アクセスも考慮された設計だし。MySQLとは違うよ。
悩む様な屑PGにお金なんて払いたくないよ。
優秀なPGが作った一つの瑕疵も無く動くシステムを納入してほしいだけ。
191:デフォルトの名無しさん
07/05/05 10:52:42
>>190
> オラクルなら不正アクセスも考慮された設計だし。MySQLとは違うよ。
もしかして本気で言っている？
ミドルウェアは道具にすぎないんだよ？
理想郷は君の頭の中にしかないよ？
> 悩む様な屑PGにお金なんて払いたくないよ。
> 優秀なPGが作った一つの瑕疵も無く動くシステムを納入してほしいだけ。
じゃあこの世に現存するすべてのものは使えないね。
OSでもどれだけのパッチが出てるか知らないでしょ？
現実を知らない営業とか客とかって、傍から見てると無様だねぇ…。
192:デフォルトの名無しさん
07/05/05 11:20:18
学生だろ
193:デフォルトの名無しさん
07/05/05 15:30:05
雑魚ＳＥが粋がるな
194:デフォルトの名無しさん
07/05/06 02:04:57
図星かい？
195:デフォルトの名無しさん
07/05/07 09:27:54
>>189
は小規模開発した事しかないチンカス学生
１年～かけてやるプロジェクトも平気であるんだよ
196:デフォルトの名無しさん
07/05/07 10:14:38
おちんちんにかすなんてたまってません！！
197:デフォルトの名無しさん
07/05/07 10:15:23
>>195
と学生が叫んでいます
198:デフォルトの名無しさん
07/05/07 10:16:04
× 学生
○ グロマン学生
199:デフォルトの名無しさん
07/05/07 10:58:59
>>197
と知ったかぶりのNEETが申しております
200:デフォルトの名無しさん
07/05/07 12:16:28
>>195
そういう問題じゃないだろ。
201:デフォルトの名無しさん
07/05/07 23:23:45
一年も時間かけてバグつぶせないなんて、糞PGですか？
給料泥棒！ ちゃんとバグの無いプログラム書けよ。
202:デフォルトの名無しさん
07/05/08 02:01:58
>>201 は未経験だということを自ら露呈しました
203:デフォルトの名無しさん
07/05/08 09:45:19
>>201
仕事ちゃんと経験してから煽ろうな？
204:デフォルトの名無しさん
07/05/11 01:23:17
>>1
こんな記事もある。
しかし、ム板で聞くこと自体が間違ってるんじゃないか？
URLﾘﾝｸ(www.itarchitect.jp)
>従来、この種のシステムの稼働環境としては、メインフレームが用いられてきた。
>しかし、レガシー※1・トランスフォーメーション、すなわち、Java EEなどの
>オープン分散プラットフォームを用いて、既存のミッション・クリティカル・システム
>を再構築しようという機運が高まってきている。メインフレームは高い信頼性を
>備えるため、新規システムの開発をメインフレーム上で行うケースもいまだ多いの
>は事実だが、メインフレームを扱える技術者の高齢化が問題となり、また若手技術者
>の教育コストを削減することを目的とし、基幹業務の稼働環境をメインフレームから
>オープン分散プラットフォームに切り替える例が増えてきているのである。
>※1 IT業界では、「レガシー」という単語が用いられる場合、それは主にメインフ
>レーム資産のことを指していると考えられる。筆者は、現在も技術革新を続け、
>オープン分散プラットフォームとは比較にならないほどの高機能を提供するメインフ
>レームをこのように呼ぶことには抵抗を感じる。しかし、一般的に通用する用語で
>あることは事実なので、本連載ではそれを踏襲することにする。
205:デフォルトの名無しさん
07/05/11 02:21:50
凡庸系なんかみたことないけど。
206:デフォルトの名無しさん
07/05/11 07:38:38
つ AS400コボラー
207:デフォルトの名無しさん
07/05/11 10:08:19
オープン系技術者の中では、ｺﾎﾞﾗｰは蔑称だなぁ…。
COBOLしかできないコピペPGなんてｲﾗﾈ。
もちろんCOBOL以外も書けて広い視野を持っている方に対しては、ｺﾎﾞﾗｰなんて言わない。
208:デフォルトの名無しさん
07/05/11 12:27:56
ぼんよう 0 【凡庸】
（名・形動）[文]ナリ
すぐれた点もなく平凡なこと。また、その人やさま。並み。平凡。凡人。
「―な作品」
［派生］ ―さ(名)
209:デフォルトの名無しさん
07/05/11 16:34:57
RPGでもいいじゃんAS頑丈だし完全上位互換するし
ちょっと7色しかないからってなんでもパソコンてのもどうよ？
210:デフォルトの名無しさん
07/05/11 18:06:12
うちのASは緑しか表示できないよ。
７色も出るなら買い替える(w
211:デフォルトの名無しさん
07/05/11 20:34:16
ASシリーズのシステム・アーキテクチャはオブジェクト指向だ(ただしアプリ記述言語はCOBOLだけど)
とかいう煽り文句を思い出した・・・出所は父の伝言あたりか？
212:デフォルトの名無しさん
07/05/11 21:47:21
商用マシンでオブジェクトって言い出したのはシステム38が最初かな。
オブジェクト指向的な要素は陽には見えなかったが・・。
213:デフォルトの名無しさん
07/05/12 05:37:35
>>204
>若手技術者の教育コストを削減することを目的
ここでせっかくのノウハウの蓄積がなくなってしまう。
若い連中はインストラクターや本で覚えた知識をかざして
汎用機のプログラムを見てはダサイといい、
ｵｻｰﾝの言うことをきかなくなり、○○を使えば今までの１／３の工程とか言い始めて
その結果、同じ失敗を繰り返す。
しかもフレームワークがころころ変わる昨今、若い世代でも同じようなことが・・・。
ベテランがあたらしめのアーキテクチャをマスターして
若い世代に教育できればいいんだけど、そんな人はほとんどいないからな。
オレはオープン系だけど、たいしてコストも変わらないのに
２０代のボンクラプログラマばかり集めて基幹システムをオープン系でやる意味が分からない。
細かい話でいえば、データベースとオープン系言語との間に
そもそもデータ型の互換がなくプログラムのほとんどが型変換やチェックばかりで
しかもそれがバグの温床にもなってて非常にバカバカしく思う。
214:デフォルトの名無しさん
07/05/12 06:55:26
汎用機にゃ汎用機の、オープンにゃオープンの利点があって使い分けるべきなのに
ソレをオープン系や若手のせいにしてるようじゃ
若手もついてこないだろ
汎用機の「変化が少なく安定」てのは利点だからそこは否定せんけど
それに甘えて、変化の早いオープン系を解らんポイと捨てる奴や
個人じゃ学びにくい汎用機についての教育をろくにしなかったり
汎用機そのものについていい加減にしか理解してないベテラン
どう考えても言語としての機能が見劣りするCOBOLそれ一つしか解せないPGがベテランの椅子に「でん」と構えてたり
…そんなんじゃ若手もそっぽ向いて「汎用機は時代遅れ」ってイメージ持つだろうよ
215:デフォルトの名無しさん
07/05/12 09:10:08
>汎用機にゃ汎用機の、オープンにゃオープンの利点があって使い分けるべき
システム構成としてはもちろんそれが理想だが、
どちらにも柔軟に対応できる人材はあまりいない。
結局はベンダやソフト屋の都合次第なんだと思う。
>どう考えても言語としての機能が見劣りするCOBOLそれ一つしか解せないPGがベテランの椅子に「でん」と構えてたり
おれはオープン系だがこれは別に悪いことではないと思う。
また開発手法や標準化が徹底しておりビジネスロジックのみに専念して記述してある
COBOLのソースを見ると芸術的とさえ思う。
設計や行程についてこういう人に質問することは多々ある。
むしろ悪いのは言語により優劣をつけてベテランを論破しようとする若手。
それで結局だれが得をするのかと・・・。
216:デフォルトの名無しさん
07/05/13 01:05:02
>>215
ビジネスロジックの部分だけCOBOLで実装するとかそう言う選択が出てきてもいいのにな．
Web～Service層までJava/.NET
Serviceの内部でビジネスロジックをCOBOL実装
DAO以降のレイヤーをまたJavaとか．
ってここまで書いて思ったけど，COBOLとそれ以降では，
データ構造とか取り扱いが根本的に異なるから無理かな？
217:デフォルトの名無しさん
07/05/13 08:33:54
コボルが芸術的とは到底思えない。
オブジェクト指向ですら無いじゃん。
昨今のインターネット対応なんてコボルでは絶望的。
218:デフォルトの名無しさん
07/05/13 13:53:07
>>216
ハブの所に使うCORBAの実装費用だけでもう一システム余計に作れるな
219:デフォルトの名無しさん
07/05/13 14:20:16
>>217
オブジェクトCOBOLの名前すら知らないお前にCOBOLを語る資格はない。
220:デフォルトの名無しさん
07/05/13 15:21:11
Excelでゲームは造れるけどCOBOLでは造れないだろ
221:デフォルトの名無しさん
07/05/13 16:14:23
Obj-cobolって実際使われてるの？ どんな汎用機？
222:ﾌﾟ
07/05/13 19:34:30
百五銀行のWindows勘定系が稼働、フルバンキングで世界初
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
三重県の地方銀行である百五銀行は
Windowsで構築した新基幹系システムの
稼働を開始した。マイクロソフトによれば、
勘定系を含むフルバンキングをWindowsで
構築した銀行は、世界で初めてだという。
ゴールデンウイーク最終日の5月6日（日）
に稼働を開始し、7日（月）から平日稼働を
開始した。現在のところ、トラブルはなく
順調に稼働している。
新システムの構築は2003年から始めた。
OSに「Windows Server 2003 DatacenterEdition」、
サーバー機に日本ユニシスのIAサーバー「ES7000」、
パッケージには日本ユニシスの「BankVision」
を使っている。
旧基幹系システムは日本ユニシスのメイン
フレームで稼働していたが、新商品開発のス
ピード向上や運用コストの削減、周辺システ
ムとの連携などを図るため、Windowsで再構
築することを決めた。新システムでは休日の
窓口での入出金、コンビニに設置したATM
（現金自動預け払い機）の24時間取引などを
可能にした。
223:デフォルトの名無しさん
07/05/13 20:00:39
>>222
これ、何時間で止まるかな？
224:デフォルトの名無しさん
07/05/13 22:41:49
ASでも安定運用には毎日再起動してたし、ウィンドウズも毎日再起動すれば良い。
225:デフォルトの名無しさん
07/05/13 23:16:46
>>220
何が目的でプログラムしてるかは知らないが、
こういう考えを本気で持ってる人間が業務システムにも多いのは事実。
もうカルト宗教の世界だよ。
金の勘定にそんなのいらない。
こんな輩が再利用や部品化といいOOPを導入しては、
数年後、やっぱりDIでないととか言って作り変えるのだろう。
オープン系の人もバッチはPL/SQLとかで書くのに、
これはOOPじゃなくてもいいんだよね・・・。結局権威主義なんだと思う。
最終的に目指すところが安定したフレームワークや再利用可能なクラスを用いて、
ビジネスロジックのカスタマイズに専念って、
結局は汎用機がやってることじゃん。あほらしい。
俺は汎用期こそがベンダ主導だと思ってきたが、１０年オープン系をやってきて、
こっちも結局はベンダに振り回されてただけなんだとつくづく思うよ。
であればきめられた枠の中で技を磨き続けるほうがいいな。
226:デフォルトの名無しさん
07/05/13 23:58:31
何が目的ってお金が目的でしょう
同じ事続けていても儲からないからね
227:デフォルトの名無しさん
07/05/14 00:41:48
ここまで読んで、結局は人の品質なんだな、と思った。
しっかりとしたコスト意識を持ち、手段と目的の違いを考えきれる技術者が
多い企業には、オープン系が良い。
それは、汎用機と同等のことをオープン系で実現した上で、更なる可能性を
追求できるからだ。
しかし、現実にオープン系の基幹システム成功例が少ない以上、今のオープン系
技術者は汎用機の水準まで達していない人が大半と言える。
＋αを夢見るも、足元を固めきれていない。
従って、技術者の品質が高まるまでは業務システムをオープン系にするメリット
は無い。
228:デフォルトの名無しさん
07/05/14 01:02:20
何か凄い論理だな…
229:デフォルトの名無しさん
07/05/14 10:24:42
>>223
毎晩再起動するんだと思うよ
230:デフォルトの名無しさん
07/05/14 10:27:36
>>227
禿
231:デフォルトの名無しさん
07/05/14 10:28:58
>>223
49.HOGEHOE
なんかTimeGetTimeかなんかの限界値があって到達したら戻るとかってのあるじゃない？
あれでなんか起きると期待したい
というかネタ的に早く止まってすげーこｔになってほしいわけだがｗｗｗ
232:デフォルトの名無しさん
07/05/14 13:06:46
>>231
いつの時代の人ですか？
233:デフォルトの名無しさん
07/05/14 13:47:05
>>231
49.7日のことか
>>232
なつかしいけど、今でもまだ残ってたりするよなぁ･･・そういうPG
運用でどうにでもなる問題だが
234:デフォルトの名無しさん
07/05/14 15:42:03
ﾏｼﾞﾚｽするとオープン系での高可用性はクラスタが基本。
だからFailOverして何ごとも無く動くだけだよ。
汎用機は集中型だけど、オープン系は分散型。
元々、多ノード構成は得意。
235:デフォルトの名無しさん
07/05/14 15:52:48
別にオープン系とクラスタ構成は関係ないと思うが。
たまたま、汎用機とはちがって、クラスタ構成化できるハードソフトをそろえやすいだけ。
236:デフォルトの名無しさん
07/05/14 16:12:50
関係在るよ。
汎用機の文化は一点豪華主義というか、高い部品を使ってMTTRを良くする、集中投資型。
オープン系の文化はRAIDと一緒で、高可用性が必要ならサーバを束ねて使う、クラスタ型。
高可用性においてオープン系サーバとクラスタは常にペアなんだよ。
237:デフォルトの名無しさん
07/05/14 16:39:56
>汎用機の文化は一点豪華主義というか、高い部品を使ってMTTRを良くする
そ・・・そうか？？？
238:デフォルトの名無しさん
07/05/14 16:48:01
汎用機＝鎖国
オープン系＝黒船
双方とも、メリット・デメリットが入り乱れて訳ﾜｶﾒ
239:デフォルトの名無しさん
07/05/14 20:31:55
いくら可用性を上げても事故が起きるのは人為的なミスが大多数だよ。
240:デフォルトの名無しさん
07/05/14 22:13:23
>>238
×黒船
○海賊船
241:デフォルトの名無しさん
07/05/14 23:01:13
>>239
新人にデータの容量調べさせてたら、客のＤＢまるごと飛ばしたり、
エクスプローラでプログラムのフォルダをどっかにやっちゃったり。
ま、これはどっちでも起こりうるか・・・
242:デフォルトの名無しさん
07/05/15 00:26:01
>>239
それを言っちゃあ、おしめぇよ
ってゆーかそれは、内部統制の範疇な
243:デフォルトの名無しさん
07/05/15 09:55:29
でも、人為的ミスを警告やビジュアル化して表示する事ですこしは減らすことは可能だろ
まぁ・・・・その減らそうとしてやったことも スルーされて
「でてたけどそのまんま処理しました」
といわれ人為的ミスが起きるわけだが
もういやだがや・・・・・
244:デフォルトの名無しさん
07/05/15 10:17:58
>「でてたけどそのまんま処理しました」
多いんだよなそれ
245:デフォルトの名無しさん
07/05/16 01:14:14
矮小化した例でｽﾏﾝが、checkstyleの警告なんて見てもくれないのな。
（そもそも規約でチェック有効にしとけっつってるのに無効にしてるっぽい。アフォか。）
自分も中～下の間くらいだと自覚してるが、
下の集団を相手にするのは疲れるよ。
246:デフォルトの名無しさん
07/05/16 01:17:53
>「でてたけどそのまんま処理しました」
つ フールプルーフ
247:デフォルトの名無しさん
07/05/16 02:12:06
みなさんコンパイルしたときのワーニングは放っておきますか？
248:デフォルトの名無しさん
07/05/16 02:34:57
自分が書いた部分なら全て直すよ。
249:デフォルトの名無しさん
07/05/16 09:24:40
>>247
ワーニング出ないように修正してる
なんか気持ち悪いしｗ
250:デフォルトの名無しさん
07/05/16 09:31:34
わーにんぐレベルをさげる・・・。ｗ
251:デフォルトの名無しさん
07/05/16 09:42:42
>>250
ちょっｗｗｗｗｗｗ
そして>>250のその行為が引き金となり後に伝説の事件を生むこととなるのである
252:デフォルトの名無しさん
07/05/16 10:07:44
641億円を投じた技術試験衛星「きく8号」、故障の原因は回路のショート
URLﾘﾝｸ(www.technobahn.com)
253:デフォルトの名無しさん
07/05/16 12:13:56
>>251
いや、ワーニングは所詮警告だよ。
本来そんなグレーゾーンはなくすべきだから、レベルMAXで通らないと駄目ってのが正しい。
それを規定してない開発チームだったら、下げても問題ない。
254:デフォルトの名無しさん
07/05/16 23:37:13
>>253
日本語で
255:デフォルトの名無しさん
07/05/17 01:09:22
>>254
漏れは >>253 じゃないけど
日本人としてちゃんと意味分かったよ
256:デフォルトの名無しさん
07/05/17 01:22:14
昔、汎用機用の周辺機器開発やってたが、
汎用機にはトラブル対応の為ぶら下がってる人がたくさん居て
常に解析できる人をフルタイムとはいかないまでも待機させておいたり、
保守チームを残しておく必要があった。
それにトラブル修正の為の予算、要求はほとんど通り、
再現性が低いけどバグ以外考えられないといったトラブルに関しては、
半年掛けても直せとか命令されたこともあった。
その仕事に関しては、考えうる限り妥協が許されなかったよ。
トラブルが直ったら、ある程度の責任者が報告書を持ってお得意様まで説明しに行ってた。
いまでもそうなのかは知らない。
今は辞めちゃったので良く知らないけど、
現在は昔ほど厳密じゃないと言う噂を聞いた。
257:デフォルトの名無しさん
07/05/17 01:47:10
実際その通りです
波があるからまた変わるだろうけど
258:デフォルトの名無しさん
07/05/17 02:44:13
だから汎用機には高いコストを払うってだけだと思うんだが
今の時代はミスはミスとして認めれば許されるケースも多いので
リスクから考えて安いオープン系で開発するのも有り
259:デフォルトの名無しさん
07/05/17 02:54:58
>今の時代はミスはミスとして認めれば許されるケースも多いので
>今の時代はミスはミスとして認めれば許されるケースも多いので
>今の時代はミスはミスとして認めれば許されるケースも多いので
人為ミスは無くならないが、あなたはシステム屋としての姿勢がおかしい
260:デフォルトの名無しさん
07/05/17 06:52:30
一時栄華を誇ろうとも時代を経るごとに駄目になっていくのは歴史の定めなのだろうか。
261:デフォルトの名無しさん
07/05/17 09:25:39
>>260
だが時代は繰り返す
きっと「これじゃダメだ！」て風潮になる････って信じたい
つうか、仕様書や説明書ひとつとっても相手から金取ってるんだからもっと真剣にやれと････
若い連中のスタンスに問題があるような気がする
とかいう俺も20後半だけどさ･･･
>>259
これを前提にしているようではダメだと思う
1ミスが命取りくらいに思わないと信用失っちゃいそうで･･･
262:デフォルトの名無しさん
07/05/17 09:50:16
>>258
エラーが本当に致命的な所以外は皆そうなってると思う。
運用でカバーしろって奴か。
止まっても、再立ち上げで動けば無問題、そういう開発者も多いと感じるよ。
263:デフォルトの名無しさん
07/05/17 11:14:19
>>261
しかしミスがありえないと考えてしまうのも考えものだぞ
264:デフォルトの名無しさん
07/05/17 11:17:40
>>262
前に下請けの会社が作ってきたものに不具合があって
結局漏れがソース中に原因を発見したんだけど
途中のやりとりではそいつは
サーバー再起動してください。そうしたら治りますから。
あと、おたくは毎日一回再起動しないんですか？
って平然と言いやがった
実際再起動すると一時的に症状が出なくなるパターンだったんだけど
265:デフォルトの名無しさん
07/05/17 11:52:34
>>264
> サーバー再起動
まさか reboot じゃないよな?
266:デフォルトの名無しさん
07/05/17 12:05:07
>>263
いや、それぐらいのつもりで書かないと
謝れば許してくれるからまぁいいか
じゃぁダメってことです(；´Д｀)
267:デフォルトの名無しさん
07/05/17 12:05:56
>>264
恥さらしだな･･
まったく持って恥ずかしい・・・・
268:デフォルトの名無しさん
07/05/17 16:04:43
サバ管「サーバの不具合の今後の対策として毎週１回OPによるリブートをしてもらうということになりました」
俺(OP)（…ハァ！？）
…ソレ対策って言わないよな？
先週は「一時的な対策として今週だけリブート」って言ってたよな？
つーかリーダーの承諾取れてますってぉ～ぃ何で通したんだよ…
数週間後、リブートの翌日にフリーズって事態が起こったんだけどな。
269:デフォルトの名無しさん
07/05/17 16:08:36
抜本的解決を要求するニダ！！
270:デフォルトの名無しさん
07/05/17 23:57:27
恥さらし というより 面汚し
271:デフォルトの名無しさん
07/05/19 07:50:55
ニューヨーク証券取引所(NYSE)のシステムがIBMメインフレームから
AIXが動くIBM System pとLinuxが動くHP IAサーバーへ移行開始されているそうだ。
NYSEでは、この移行によってトランザクションあたりのコストが半分になると見ているとのこと。
これでロンドン証券取引所はWindows、東京証券取引所は富士通のPRIMEQUESTでLinuxとなったわけだが、
三者三様というのはちょっと興味深い。
272:デフォルトの名無しさん
07/05/19 08:31:50
不治痛ってあれだろ
いろいろ問題起こしてるところだろ
273:デフォルトの名無しさん
07/05/19 13:02:17
それぞれのシステムに精通した奴をシステムの寿命が終わるまで確保できていれば
何でもいい気はする。
使えない奴をコロコロ替える体制なら何使っても駄目。
274:デフォルトの名無しさん
07/05/19 18:39:00
取引所の件もそうだけど、オープン系の良いところは選択肢が沢山在ること。
競争原理が働き、良いものが安く手に入る。
だからこそしっかりとした技術のあるSIerを選ぶのがとても重要。
275:デフォルトの名無しさん
07/05/19 18:48:44
>しっかりとした技術のあるSIerを選ぶ
結局、それで高くつくんですが。なんとかなりませんか？
276:デフォルトの名無しさん
07/05/19 18:54:18
良い物を手に入れるにはそれなりにお金が掛かるんです。
以下ループ
277:デフォルトの名無しさん
07/05/19 18:55:34
人沢山抱えないといけない汎用機に比べたら、かなり安いだろう。
仮にも業務の中核となるサーバをそこらに転がっている
Windows端末に毛が生えたものなんて認識していると痛い目に遭うよ。
278:デフォルトの名無しさん
07/05/21 00:17:28
>>277
オープン系の方が人たくさん必要なんじゃないか？
システムのリリース時期、規模、個人の嗜好によってプラットフォームが
違う以上、運用に求められるスキルも多様化する。結果、人がたくさん必要。
279:デフォルトの名無しさん
07/05/21 00:28:19
汎用機の方が教育コストというかノウハウの蓄積が大変なんじゃないか？
280:デフォルトの名無しさん
07/05/21 00:56:00
>>279
おっさんたちが新しいことをおぼえないのはそういう習慣がないから。
一度教育を受ければあらたしく覚えることはそんなにないし、
メーカーには腐るほど資料がある。
ネットには資料が落ちてないけどこれで十分。
そもそもこいつらが作ってるんで問い合わせたらまちがいなく解決する。
バージョンごとにプラットフォームに振り回されて、
挙句の果て新たなフレームワークが登場したら
若手に邪魔者扱いされるオープン系とは雲泥の差。
今回のシステムはどうやって紙を印刷するかを
基盤系の連中が集まって丸一日会議してるのなんてあほらし・・・。
どのスキルがあるかを証明するためにころころ変わるベンダ試験を受けて、
せっかく試験に受かっても有効期限付き。
そして若手はしょーもないトラブルに振り回されて徹夜・・・以下ループ
281:デフォルトの名無しさん
07/05/21 01:14:50
お疲れ様です
282:デフォルトの名無しさん
07/05/21 01:18:05
汎用系だろうとオープン系だろうと、メーカーやSIerの取り分は変わらないよ。
オープン系に切り替えてコストダウンしようなんて絶対無理。
いＢＭなんて、金取れそうに無い客は露骨に無視するしね。
283:デフォルトの名無しさん
07/05/21 01:42:07
システム開発部門は企業の寄生虫だな
284:デフォルトの名無しさん
07/05/21 01:48:02
>>283
その寄生虫がいなけりゃ、何もできないくせにｗ
285:デフォルトの名無しさん
07/05/21 02:17:31
>>278
それはない。
たしかにオープン系は多種多様なスキルが必要だが、方針が決まったら詳しい人間を連れてくるだけ。
ちなみに１芸しかできない奴は使いものにならないよ。
少数精鋭がオープン系のやり方。
だから、下手なSIerにやらせると大変なことになる。
自由度が高い分、スキルもピンキリなんだよ。
286:デフォルトの名無しさん
07/05/21 02:29:26
>>285
なにお前の狭い物差しできめてんだ？カス
287:デフォルトの名無しさん
07/05/21 02:30:04
>>280
何点かつっこみ。
・オープン系だろうが汎用機だろうが、勉強をやめたら技術者じゃない。
それはオペレータと言うんだよ。
・客が求めているものに汎用機の印刷システムが応えられない現実を忘れるな。
選択肢の多さとレイアウトの自由さは汎用機の比ではない。
・それと、オープン系技術者もピンキリだ。
君の周りにいるのが全てではない。
288:デフォルトの名無しさん
07/05/21 02:33:30
根拠の無いレスは負け惜しみと一緒だよ？
289:デフォルトの名無しさん
07/05/21 02:38:28
一行しかレス付けられない香具師ってなんなの？
あ、俺もかｗｗｗ
290:デフォルトの名無しさん
07/05/21 02:43:42
>>285
>たしかにオープン系は多種多様なスキルが必要だが、方針が決まったら詳しい人間を連れてくるだけ。
>ちなみに１芸しかできない奴は使いものにならないよ。
馬鹿か?
1芸の人間を種類別に集めりゃいいんだよ
291:デフォルトの名無しさん
07/05/21 02:47:08
>>290
１芸しかできない人間って他の分野の人間を理解する能力に
欠けてることが非常に多いから使い物にならんよ、マジで。
292:デフォルトの名無しさん
07/05/21 02:51:43
>>287
上から目線乙
> それはオペレータと言うんだよ。
そいつらに言ってくれ。
あくまで新しいことを覚える必要がないと言っている。
パラダイムシフトにはついていかなければならんが新しいだけが技術ではない。
誰も過去の知識にしがみついてやっていけるなんて思ってないよ。
> レイアウトの自由さは汎用機の比ではない。
どの程度システムを経験してるのか知らんが
見掛け倒しの帳票なんて客は求めてない。っつーか役に立たない。
そんな枝葉のシステムはそれこそパソコンでやってればいいけどね。
印刷速度を求めるとオープン系もオーバーレイ使うようなでっかい印刷機が必要じゃね？
> ピンキリ
あたりまえ。だがプロジェクトは腕のない奴に足を引っ張られる。
だから長年かけてプロを育てる必要がある。
オープン系の連中にはちゃんと足元固めてるやつもいるが（こいつらと仕事するとマジ楽しい！）、
ベンダの広告に振り回される浮足立ったやつも多い。
できて当たり前のことを一から説明しなきゃならんので
オープン系の会議ほどあほくさいものはない。
せっかく会議で合意が取れて規約を作っても出来上がってくるものは各社バラバラ。
オレはキャリアの後半をオープン系のＰＭとしてやってきたが、
品質も集まる人材も汎用機の方が上だった。主観ばかりですまんね。
293:デフォルトの名無しさん
07/05/21 07:42:11
>オレはキャリアの後半をオープン系のＰＭとしてやってきたが、
>品質も集まる人材も汎用機の方が上だった。主観ばかりですまんね。
禿堂
294:デフォルトの名無しさん
07/05/21 08:32:17
>>292
> オープン系の連中にはちゃんと足元固めてるやつもいるが（こいつらと仕事するとマジ楽しい！）、
少ないんだよ, こうゆう連中。
つか、アホが束になってかかっても(ry
295:デフォルトの名無しさん
07/05/21 09:12:27
ここでおまいらと話してるとマジ楽しい！
296:デフォルトの名無しさん
07/05/21 09:27:51
>>258のような人が沢山集まるから大変なんだろうね。
チームの性能は一番能力の低い人と同じぐらいになる、とどこかで聞いたことがある。
297:デフォルトの名無しさん
07/05/21 09:34:23
>>296
秀同
こんな許されると思って作ってるカスはいらない
時間なくってもそんな考えは持たないだろ
その油断こそバグの元
298:デフォルトの名無しさん
07/05/21 09:36:30
>チームの性能は一番能力の低い人と同じぐらいになる、とどこかで聞いたことがある。
率速段階がどこにあるかっつー琴屋根
サブプロジェクトが直列に結合された状態走っているときに
遅い部分に引っ張られて全体が遅くなるということはあるが
並列に走っている場合はそうでもない
つまり能力低い香具師にはそいつをカバーする香具師をつける必要がある
299:デフォルトの名無しさん
07/05/21 09:46:27
>>298
そうなんだろうど、カバーする余裕（能力）のある奴を足かせ（能力低い奴）無し全速で動かしたほうが
効率が良いと思う。
やる気のある新人を教育する目的以外では非効率的。
使えない、やる気も見れない奴はサッと切る能力こそ重要。
300:デフォルトの名無しさん
07/05/21 10:24:26
やる気の無い奴を切ることは出来ても。
やる気のある無能者を切ることは出来ない。
301:デフォルトの名無しさん
07/05/21 12:57:54
オープン系は人口が多い分、裾野もまた広い。
裾野の人間しか集められないのはPMの力不足だよ。
それにオープン系を汎用機の文化で管理しようとすると悲惨なことになる。
早めにプロジェクトのオープン系部分全体を技術的に広く浅く知っているリーダーを探した方がいい。
302:デフォルトの名無しさん
07/05/21 13:07:17
プロジェクトのまとまりは人数に反比例する。
一芸ばかり集めるからそうなる。
しかも、一芸技術者は協調性がないからさらに迷走する。
あとPM側の問題のパターンも在る。
使える奴を使えるのは誰でも出来る。
使えない奴を使えて始めて上に立てる。
自分の管理能力、客観的に見たこと在る？
303:デフォルトの名無しさん
07/05/22 00:47:40
>>302
そうなんよねー。
スーパースターがときどきいるけど、そんな奴がいればラッキー！というくらいの価値。
別にいなくてもいい。
オープン系なんかでは若手から神扱いされてむしろ邪魔な存在になることも。
あたらしい開発手法のレクチャーなんて教祖様なみの憧憬のまなざしだもの。自分で勉強しろっての。
そこで「スゴイ！スゴイ！」としか言えない若者をいかにきちんとまっすぐ歩かせてあげるかなんだよね。
すぐに客寄せパンダを見に道草食っちゃうんだけどさ。
304:デフォルトの名無しさん
07/05/22 01:14:21
ある意味、客寄せパンダで回ってる業界だからね
305:デフォルトの名無しさん
07/05/22 01:37:45
>>303
オープン系の基盤プロダクト作ってる連中にはザラにいるんだけどな,
とんでもなく頭きれるやつ...
でも, 出来上がったもの使って物を作ってる連中は何も考えてない.
306:デフォルトの名無しさん
07/05/22 10:05:51
逆引き辞典かコピペしている漏れの様なＰＧも居れば、
便利なＡＰＩ作る奴も居るってことでつか？
オープン系って呼び名から胡散臭いんだよね。
会話にカタカナが多いほど信頼できないって意見には同意出来る。
307:デフォルトの名無しさん
07/05/22 14:30:30
対応する日本語を作るほど誰もヒマじゃないのだろう。
日本語版がないのに中国語版があると知ったときこりゃ駄目だと思ったよ。
英語の名詞を日本語の文法で繋いでる状態じゃ英文のままのほうがマシと思われても仕方が無い。
308:デフォルトの名無しさん
07/05/22 21:06:52
オレら千年近く漢語の名詞を日本語の文法で繋いで来てる訳ですが…
技術情報は英語で得るのが普通だと思うけど。
309:デフォルトの名無しさん
07/05/22 23:31:59
現在使われている熟語の大半は
明治時代に西洋の言葉に対応づけるために日本で作られた造語
310:デフォルトの名無しさん
07/05/23 00:39:23
中国の義務教育の教科書に出てくる単語の三分の一は近代日本で作られた熟語らしいね。
実は「人民」も「共和国」も元は日本語だってテレビで言っとった。それと、英単語から翻訳された
中国語は音を当てた字が多いから、日本人がカタカナで書くのとほぼ一緒らしい。実際には
英語に対応する中国語熟語を作ってるわけではないのよね。
まぁ、勝手に負けた気になってる人間はそのまま負けといてくれれば良いと思うけど。
311:デフォルトの名無しさん
07/05/23 02:02:36
>>306
> オープン系って呼び名から胡散臭いんだよね。
たとえば IP の上に乗っかるプロトコル層ってほとんどオープンなんだよね...
# つか, プロトコルをクローズにするってのは自殺行為だと思う
> 会話にカタカナが多いほど信頼できないって意見には同意出来る。
上記の様なところに行くと, 日本語定義してる暇がないのも確なんだわ
IETF が sample/prototype 実装主義だから, あれだけ rfc でてるのに
std はほとんどない.
でもって, 数少ない std すら理解していないアホたれが大口叩いているのが
今の日本のオープン系って称されてる連中だと思う.
あくまで, たとえばの話なんだが...
312:デフォルトの名無しさん
07/05/23 02:19:54
>>308
あほか >>309-310 に書いてある通りだ
>>309-310
おまえら油断しすぎ
今は 英->日 の造語生成数よりも
英->中 の造語生成数の方が圧倒的にペースが上
そういう漏れは
>>307 に胴衣
>日本語版がないのに中国語版があると知ったときこりゃ駄目だと思ったよ。
313:デフォルトの名無しさん
07/05/23 02:23:11
フランス人を見習え
314:デフォルトの名無しさん
07/05/23 07:39:45
>>310
どこでそんなデマを仕込まれたんだｗ
315:デフォルトの名無しさん
07/05/23 08:23:08
「人民」 と 「共和国」 が日本語なのは常識だろ
実際日本も社会主義国化に足半分突っ込んでた訳出汁
316:デフォルトの名無しさん
07/05/23 10:48:40
>>312
駄目なのはあんさんだけですがな。オレはコミュニケーションが英語オンリーになっても
困らんし、英語の読めない日本人技術者が路頭に迷っても知ったこっちゃない。
むしろおかしな日本語をバシバシ作られる方がむかつく。
317:デフォルトの名無しさん
07/05/23 10:53:49
>>316
でも喋れないんだろ？
無理するなよｗ
318:デフォルトの名無しさん
07/05/23 10:57:03
自分基準で物事を考えるなよ…
319:デフォルトの名無しさん
07/05/23 11:05:48
>>316
お前みたいな ｵﾅﾆｰSEとかPGが居るから周りが迷惑なんだYO!
320:デフォルトの名無しさん
07/05/23 11:26:33
中国にはカタカナがないだけの話だろう、常識的に考えて…
321:デフォルトの名無しさん
07/05/23 11:28:47
結論、業務系は所詮烏合の衆。
322:デフォルトの名無しさん
07/05/23 11:53:15
>>319
その気で頑張れ。英語の壁なんて大した事が無いって分かるから。
323:デフォルトの名無しさん
07/05/23 12:04:37
まぁ・・読みではなんとなく意味がわかるが
ヒアリング・スピーチ全くできない俺が来ましたよ～
324:デフォルトの名無しさん
07/05/23 19:38:32
無理やり変な日本語の造語ができるくらいなら
そのまま英語の方がいいよ
325:デフォルトの名無しさん
07/05/24 03:14:26
平日の真昼間に2ch書き込んでる連中なんて、業務システムの世界では
末端ワーカーでしかないと考えるのは偏見だろうか
326:デフォルトの名無しさん
07/05/24 03:17:28
無類のサッカー好きなだけかもしれんよ。
327:デフォルトの名無しさん
07/05/24 07:21:10
俺はケータイ手放すと死んじゃう人。
もう充電とか禁断症状でまくりで必死ですよ。
328:デフォルトの名無しさん
07/05/25 01:36:42
オープン系って幅が広いんじゃ？
エクセルＶＢＡでウインドウズアプリ作っているのも立派なオープン系開発者だし
Ｗｅｂから組み込み端末まで何でもござれと言う奴でもオープン系。
329:デフォルトの名無しさん
07/05/26 15:31:14
DB2の接続プロトコルなんてクローズだが囲い込みに成功して、他に移れないけどな。
オペレータが懸命にエクセルに抜いて加工している。
帳票は馬鹿みたいに開発費かけても良ければ汎用機のほうが完璧なものが作られた実績はある。
今のコストダウン至上主義の時代には合わないが。
公共料金の請求書なんて全部独自フォーマットだし。
330:デフォルトの名無しさん
07/05/26 19:27:14
接続プロトコル？Excel？
よく知らない事無理して書かなくても良いんだよ？
ODBC以外は殆ど非公開だよ。
DB2だってクライアント入れてAPI越しだ。
印刷についても、ちょとフォントサイズ変えた文字出そうとしただけで
OSの印刷機能がまったく使い物にならなくて、プリンタの独自コマンド山盛りなのに？
つか直接コマンド送るなら汎用機関係ないよね。
それともオーバーレイ？
オープン系で作ったレイアウト使ってオーバーレイして威張られてもなぁ…。
331:デフォルトの名無しさん
07/05/26 22:35:44
>>329の
背伸び具合はどっかのスレで見た気がするなぁ…・
332:デフォルトの名無しさん
07/05/26 23:05:57
どこのスレにでも一人は居るもんだ
333:デフォルトの名無しさん
07/05/27 16:06:57
リナ廚ってにちゃんならどこにでも居るからね。
現実だとマカ以下の絶滅危惧種だが。
334:デフォルトの名無しさん
07/05/27 16:09:09
Linux?何の関係が？
335:デフォルトの名無しさん
07/05/27 20:40:17
はい、お一人様ご案内～
336:デフォルトの名無しさん
07/05/27 22:19:14
【航空/IT】全日空システムの障害原因は、事前のシステム入れ替え [05/27]
ｽﾚﾘﾝｸ(bizplus板)l50
まあ、この場合でもごめんなさいすれば済むらしいねｗ
納期短縮？予算節減したんだろうか？
オープン系にすればもっと予算を減らすことが出来た。
どうせ失敗するなら、予算が低いほうが良かったね。
減らした予算と今回の問題解決に費やした費用、どちらが多いのか？
信用はプライスレスだけど。
もう信用なんて無いも等しいし。
337:デフォルトの名無しさん
07/05/27 22:30:11
全日本空輸（ANA）が国内線の予約・発券システムを全面刷新する。
30年近くメインフレームで動かしてきたシステムを、
オープン・システム上に再構築する。
新システムへの移行により約70億円を抑制できる見込みだ。
それに向け、日本ユニシスと10年間の包括契約を結んだ。
誤ったなｗ
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
338:デフォルトの名無しさん
07/05/27 22:53:02
まだメインフレームだよ。
スケジュールよく読め。
339:デフォルトの名無しさん
07/05/27 23:17:10
>>338
ホスト接続システムがメインフレームだとは書いてないyo
１万台の操作端末--ホスト接続システム（３系統、オープン系？）--チェックインシステム（メインフレームの新機種）
詳しいなら詳細よろ。
340:デフォルトの名無しさん
07/05/27 23:25:13
>>338
俺も少し詳細に解説してみてほしい
341:デフォルトの名無しさん
07/05/27 23:30:32
>新システムで利用する米ユニシス製パッケージ「AirCore」の開発言語はJava。
>「全世界でみれば技術者数は多いし、特定プラットフォームに依存しない点も評価できる
なんかJAVAだからプラットフォームに依存しませんって100%思ってそうだけど、やっぱみんなそう思ってるんだろうか・・・・
342:デフォルトの名無しさん
07/05/27 23:50:37
>>341
>なんかJAVAだからプラットフォームに依存しませんって100%思ってそうだけど
100% 思ってると思ってるのは君しか知らないけど。
単なる OLTP だったら互換性は高いんじゃないかね。
343:デフォルトの名無しさん
07/05/28 01:28:50
>>341
しっかりした開発方法論とルールの徹底で、プラットフォーム依存部分を
限定的（外だし等）にすることが出来る。
ITインフラの変化には、その辺の調整とテストで対応、と。
.NETは無理だろう。常識的に言って。
344:デフォルトの名無しさん
07/05/28 09:30:39
>>339
それは問題のすり替えだ。
>>337の書き込みが的外れだと書いているだけだろ。
現行のメインフレームを中心としたシステムの構成なんて知らん。
345:デフォルトの名無しさん
07/05/29 01:14:39
ＡＮＡでは７０億円もの経費節減ができたんだけど、既に総投資額を使い切っちゃったのかもしれないね。
346:デフォルトの名無しさん
07/05/31 09:48:54
未確認情報だけど・・・
ネットワーク機器の設定しくじった模様。
ｽﾚﾘﾝｸ(bizplus板:225番)
>今回のANAシステム障害の根本原因はANAの100%子会社のACC（ANAコミュニケーション）って会社のバカが
>コアスイッチの設定しくじって、天文学的な量のデータを湧き出させたおかげです。
347:デフォルトの名無しさん
07/06/02 23:47:52
PGなのにNWになんて手を出しちゃったとか？
NWが本業の香具師のミスなら、プロ失格だが。
348:デフォルトの名無しさん
07/06/19 13:36:49
>>342
別にOLTPでなくとも、COBOLよりはプラットフォーム依存は低いんじゃない？
というか、プラットフォームで困ることなんか文字コード以外ない気が。
単純すぎ？指摘があればどしどしプリーズ。
>>343
なんで？？WindowsがインストールできるPCという限定つきながら、
プラットフォームに依存しないという言い方はできなくもないきがするが。