アカウント名:
パスワード:
今まで動いてきたシステムに、ちょっとの変更を加えるだけだとしたら、やっぱり今までの環境を持ってくるよなぁということですよね。
#ふさふさから一本毛を抜いてもふさふさだから、何本毛が抜けてもふさふさだろう理論
そうやってどんどん進化の袋小路に追い詰められて、時代遅れの生きている化石になることを、負の遺産と言ったりしませんか。#変更にかかる期間の長期化、保守費用の高騰、保守部品は年々入手困難に、etc
>#ふさふさから一本毛を抜いてもふさふさだから、何本毛が抜けてもふさふさだろう理論#ふと気がついてみたら毛が三本。
> #ふと気がついてみたら毛が三本。
おばQですか?
ヒトより頭髪が三本足りない奴はサル、という古伝説もあった。最近人口に膾炙しないほど忘れられているけど。
きっとわしゃ爬虫類くらいまで退化しとるかの......日々の抜け毛が3本どころでないわい。
いかに拷問されても、五エ門はルパンの弱点を吐かなかった
サザエじゃね?
銀行・金融系はリソースが沢山注ぎ込まれるとか理不尽とかよく言われてるけど、金ドブ権は実在するんだから存分に使ってくれって感じ。金持ちがバカなことをやって損するのに「効率が悪い」と進言するような印象を覚える。損するのが意図なら「損をしている」と指摘してもしょうがない。
金ドブ権ってなに?銀行が金持ちって何のジョーク?
銀行の運用益は預金者や何かに返すべきものであって、ドブに捨てて良いようなもんじゃないよ。#そういう人の金を自分の物だと思う勘違い君って、マジに存在するんだろうか。
>銀行が金持ちって何のジョーク?
元コメが勘違いか無知でで銀行をバカにし過ぎだというのは同意だけど、営業利益の額をみれば、銀行は金持ちで差し支えないと思う。
金融がIT装置産業だというのもあるけど、事業会社ではなかなか百億円単位のIT投資なんて信じられないですよ。
製鉄業が自前の製鉄プラント建設したり、鉄道業が自前でリニア建設するのと同じでしょ。
>> 預金者や何かに返すべき預けた時に約束した利子をがっちりもらってるくせにずうずうしい。それ以上、びた一文だってやる必要はない。銀行の運用益は銀行、またはそのオーナーのものだよ。どこに返せっていうのさ。
人の金を自分の物だと思う勘違い君ってお前自身じゃないか。
ってことは金ドブ権は存在するのか預金者も相当のリスクを負えばいいと言うなら預金させる代わりに銀行の株とか投資信託でも買わせりゃいいんだろうけどどうせローリスクハイリターンな商品は他の人には売らないでしょ
互換性というものがいかに強いものであるか、というやつですね。電子立国だったかな。
ユニットテストと無縁な言語なせいでリスク値さらに高止まり新旧に繋がりの無い業務形態が突然現れでもしなけりゃ百年先もCOBOLを使ってるだろうね
xUnit 系に沿った COBOL Unit [google.com] とかありますよ。
ぽっと出の新人でも「ユニットテスト」なら、旧人を凌駕する議論が出来るでしょうけど、
個々のテストは新旧繋がりを考慮した配慮が要るのでしょうね。
ちょっと海老鯛が過ぎるかと。「ユニットテスト」で個々のテストはとても釣れないでしょ。
なにCOBOLとユニットテストが関係ないような話をしているのかな?COBOLの開発作業では創成期からユニットテストしていますよ。
COBOLの悪口を言う人はこういう知識不足ばかりだね。
過去の遺産(財産)といえば聞こえはいいですが、要は「アンタッチャブル(=なぜ存在するのか、なぜそうなったのかが誰にもわからない)なソースコードが少なからず存在する」ってことですよね・・・
また、コーディング仕様としては変化させなくても、システム全体としてはソフトウェア/ハードウェア/オペレーティングシステムのすべてで続々と変化しているわけですから、その点での変化は受け入れざるを得ない状況もあります。
現にとある金融系プロジェクトでは、現行のコードで想定とは異なる実行結果が出てしまい、さんざんソースコードをすべて洗って調べてみたら、最終的にはCOBOLランタイム側のバグ(正確にはCOBOLのランタイムが依存するシステムライブラリのバグ)だったという笑えないことがありました。
金融に限った話ではないですが、「自分が変えなくても他者が変われば全体としては変わる」という点がなかなか理解していただけませんね。。
>過去の遺産(財産)といえば聞こえはいいですが、要は「アンタッチャブル(=なぜ存在するのか、なぜそうなったのかが誰にもわからない)なソースコードが少なからず存在する」ってことですよね・・・
逆だろ。単に動くものを置き換える為の検証コストが膨大で、基本、金融系のプロジェクトは先ずもって全てミッションクリティカルだから。
膨大なコストと人員さえ突っ込む様な所が有れば何処だって喜んで移行すると思うけど、たぶんその見積もりが想定されるリスクにそぐわないんだな。
・自分が変えなくても他者が変われば全体としては変わる領域と・他者が変えても関係ない領域があるだけで、後者の領域(私企業の個別の業務)を扱っている部署に理解しろと言うのは、単なるタイプミスマッチです。
敢えて代えるメリットが無いからはやりのスクリプト言語なんぞを使えば生産性が飛躍的に向上するようなたぐいのプログラムをCOBOLerがせっせと作ってると思ってるのかしら?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
過去の遺産(=財産) (スコア:5, すばらしい洞察)
Re: (スコア:0)
今まで動いてきたシステムに、ちょっとの変更を加えるだけだとしたら、やっぱり今までの環境を持ってくるよなぁということですよね。
#ふさふさから一本毛を抜いてもふさふさだから、何本毛が抜けてもふさふさだろう理論
Re: (スコア:0)
そうやってどんどん進化の袋小路に追い詰められて、時代遅れの生きている化石になることを、
負の遺産と言ったりしませんか。
#変更にかかる期間の長期化、保守費用の高騰、保守部品は年々入手困難に、etc
>#ふさふさから一本毛を抜いてもふさふさだから、何本毛が抜けてもふさふさだろう理論
#ふと気がついてみたら毛が三本。
Re: (スコア:0)
> #ふと気がついてみたら毛が三本。
おばQですか?
Re:過去の遺産(=財産) (スコア:1)
ヒトより頭髪が三本足りない奴はサル、という古伝説もあった。最近人口に膾炙しないほど忘れられているけど。
Re: (スコア:0)
きっとわしゃ爬虫類くらいまで退化しとるかの......日々の抜け毛が3本どころでないわい。
Re: (スコア:0)
いかに拷問されても、五エ門はルパンの弱点を吐かなかった
Re: (スコア:0)
サザエじゃね?
Re: (スコア:0)
銀行・金融系はリソースが沢山注ぎ込まれるとか理不尽とかよく言われてるけど、金ドブ権は実在するんだから存分に使ってくれって感じ。
金持ちがバカなことをやって損するのに「効率が悪い」と進言するような印象を覚える。損するのが意図なら「損をしている」と指摘しても
しょうがない。
Re:過去の遺産(=財産) (スコア:1)
金ドブ権ってなに?
銀行が金持ちって何のジョーク?
銀行の運用益は預金者や何かに返すべきものであって、ドブに捨てて良いようなもんじゃないよ。
#そういう人の金を自分の物だと思う勘違い君って、マジに存在するんだろうか。
Re:過去の遺産(=財産) (スコア:1)
>銀行が金持ちって何のジョーク?
元コメが勘違いか無知でで銀行をバカにし過ぎだというのは同意だけど、
営業利益の額をみれば、銀行は金持ちで差し支えないと思う。
金融がIT装置産業だというのもあるけど、事業会社ではなかなか百億円単位のIT投資なんて信じられないですよ。
Re: (スコア:0)
製鉄業が自前の製鉄プラント建設したり、鉄道業が自前でリニア建設するのと同じでしょ。
Re: (スコア:0)
>> 預金者や何かに返すべき
預けた時に約束した利子をがっちりもらってるくせにずうずうしい。
それ以上、びた一文だってやる必要はない。
銀行の運用益は銀行、またはそのオーナーのものだよ。どこに返せっていうのさ。
人の金を自分の物だと思う勘違い君ってお前自身じゃないか。
Re: (スコア:0)
ってことは金ドブ権は存在するのか
預金者も相当のリスクを負えばいいと言うなら預金させる代わりに銀行の株とか
投資信託でも買わせりゃいいんだろうけど
どうせローリスクハイリターンな商品は他の人には売らないでしょ
Re: (スコア:0)
互換性というものがいかに強いものであるか、というやつですね。電子立国だったかな。
Re: (スコア:0)
ユニットテストと無縁な言語なせいでリスク値さらに高止まり
新旧に繋がりの無い業務形態が突然現れでもしなけりゃ百年先もCOBOLを使ってるだろうね
Re:過去の遺産(=財産) (スコア:1)
xUnit 系に沿った COBOL Unit [google.com] とかありますよ。
Re:過去の遺産(=財産) (スコア:1)
xUnit 系に沿った COBOL Unit [google.com] とかありますよ。
Re: (スコア:0)
ぽっと出の新人でも「ユニットテスト」なら、旧人を凌駕する
議論が出来るでしょうけど、
個々のテストは新旧繋がりを考慮した配慮が要るのでしょうね。
ちょっと海老鯛が過ぎるかと。「ユニットテスト」で個々の
テストはとても釣れないでしょ。
Re: (スコア:0)
そのようなプロジェクトに参加したことはありませんが。
Re: (スコア:0)
なにCOBOLとユニットテストが関係ないような話をしているのかな?
COBOLの開発作業では創成期からユニットテストしていますよ。
COBOLの悪口を言う人はこういう知識不足ばかりだね。
Re: (スコア:0)
過去の遺産(財産)といえば聞こえはいいですが、要は「アンタッチャブル(=なぜ存在するのか、なぜそうなったのかが誰にもわからない)なソースコードが少なからず存在する」ってことですよね・・・
また、コーディング仕様としては変化させなくても、システム全体としてはソフトウェア/ハードウェア/オペレーティングシステムのすべてで続々と変化しているわけですから、その点での変化は受け入れざるを得ない状況もあります。
現にとある金融系プロジェクトでは、現行のコードで想定とは異なる実行結果が出てしまい、さんざんソースコードをすべて洗って調べてみたら、最終的にはCOBOLランタイム側のバグ(正確にはCOBOLのランタイムが依存するシステムライブラリのバグ)だったという笑えないことがありました。
金融に限った話ではないですが、「自分が変えなくても他者が変われば全体としては変わる」という点がなかなか理解していただけませんね。。
Re: (スコア:0)
>過去の遺産(財産)といえば聞こえはいいですが、要は「アンタッチャブル(=なぜ存在するのか、なぜそうなったのかが誰にもわからない)なソースコードが少なからず存在する」ってことですよね・・・
逆だろ。
単に動くものを置き換える為の検証コストが膨大で、基本、金融系のプロジェクトは先ずもって全てミッションクリティカルだから。
膨大なコストと人員さえ突っ込む様な所が有れば何処だって喜んで移行すると思うけど、たぶんその見積もりが想定されるリスクにそぐわないんだな。
Re: (スコア:0)
・自分が変えなくても他者が変われば全体としては変わる
領域と
・他者が変えても関係ない
領域がある
だけで、
後者の領域(私企業の個別の業務)を扱っている部署に
理解しろと言うのは、単なるタイプミスマッチです。
Re: (スコア:0)
敢えて代えるメリットが無いから
はやりのスクリプト言語なんぞを使えば生産性が飛躍的に向上するようなたぐいのプログラムをCOBOLerがせっせと作ってると思ってるのかしら?