アカウント名:
パスワード:
「NTTデータや日立製作所は作業工数が不要だと受け取られそうな不用意なコメントですが」ってあるけど元記事見ると「昭和から平成への元号変更の際に培ったノウハウを生かせるためだ。」ってあり一度元号関連の処理やっているので内規があるってことじゃないん？不用意ってのはちょっと悪意ありすぎるような
客：日立さん、ノウハウあって工数少なくて済むんだって？じゃ予算これだけだからあとはよろしく日立：おい、客の予算これだけだって。ノウハウあるだろ？どうにかしろ〇〇システム：あの頃の技術者はみんな定年でいなくなってます。今は派遣と〇国人ばかりです。日立：・・・。
日立：・・・。日立を舐めるなっ！こうですか
三十年前のノウハウとか言われても余計胡散臭く感じるが…
当時は相当大騒ぎになったので、改元に関する基本的なノウハウはしっかりまとめられているはず、っていうかしてなかったら本当にバカ。問題になるとしたらそのノウハウを知らない世代が開発した比較的新しいシステムなのでは。大手のITベンダーより、まだ歴史の浅い独立系ベンダーのほうが怪しい。
# まあいまなら普通Enum使ってるよねー。使える言語なら。
enumなんぞは使いません，フツーは。 外部リソースに持たせます。
元号改正にこれだけ時間がかけられるのは今回が初です。 たいていは「明日改元だから，よろしく」なわけです。 ビルドやら配信やらが必要なenumは筋が悪い。
いやいや、頻繁に追加や変更があるなら外部リソースにするでしょうが、数十年に一回ならenumでしょう。一度決まった元号が変わったりするわけでもないですし。
数十年に一回なんだけどいつなんどき来るかわからないので外部リソースから読み出す方式のほうが安全だと思うなー。
＞数十年に一回これ自体が勘違い。
明日にでも天皇崩御して元号が変わり、その次の日にでも事故で新天皇が崩御なされて更に改元されることだってあり得る訳で
「いつ何時、何回おきるかわからないランダム」が正解
そうそう、昭和と平成を区別できればいいんだからboolで十分なのに無駄なことしますよね。https://twitter.com/naron__A/status/937184628388933633 [twitter.com]
自分の会社とか鑑みて30年も前のノウハウをちゃんと継承し続けてる？本当に？
年号管理に Enum 使うとか、どんだけ頭悪くてもやらんだろう。ベンダーの経験があるとか無いとかじゃなくて、普通に考えたら、そんな馬鹿げたことはしない。
そもそも、前回は元号が変わってからの対応。今回は元号が変わる前から対応しなきゃならん。全く生かせないとは思わないが、素人目には結構異質な気がするのだけど。
平成の時は突然元号決まったので、テストは事後だった。今回はテストは事前にできる。
でも、事前にテストするってことは、結合テスト規模なら計算機の時計をセットしなおすってことだ。これが結構大変じゃないかな。月次処理とか、テスト項目ごとに、「みなさーん、時計を確認してくださーい」
業務日付って概念知らないの?
0時から変われば楽だけど午前6時からは新元号とか言われたら泣きながら岸壁に立って下を見下ろす
地球上で同じ扱いの Julian day を考慮すると，日本時間の午前9時近辺を指定されることは大いにありえますね。それがどうしたとだからなんだと撥ね退ける強い意志が必要?
午前9時に年号が変わるのでご心配なく。
#だよね？JST基準なんて恐ろしい事しないよね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
日立のコメント (スコア:2, すばらしい洞察)
「NTTデータや日立製作所は作業工数が不要だと受け取られそうな不用意なコメントですが」
ってあるけど
元記事見ると「昭和から平成への元号変更の際に培ったノウハウを生かせるためだ。」
ってあり
一度元号関連の処理やっているので内規があるってことじゃないん？
不用意ってのはちょっと悪意ありすぎるような
Re:日立のコメント (スコア:1)
客：日立さん、ノウハウあって工数少なくて済むんだって？じゃ予算これだけだからあとはよろしく
日立：おい、客の予算これだけだって。ノウハウあるだろ？どうにかしろ
〇〇システム：あの頃の技術者はみんな定年でいなくなってます。今は派遣と〇国人ばかりです。
日立：・・・。
Re: (スコア:0)
日立：・・・。日立を舐めるなっ！
こうですか
Re: (スコア:0)
三十年前のノウハウとか言われても余計胡散臭く感じるが…
Re: (スコア:0)
当時は相当大騒ぎになったので、改元に関する基本的なノウハウはしっかりまとめられているはず、っていうかしてなかったら本当にバカ。
問題になるとしたらそのノウハウを知らない世代が開発した比較的新しいシステムなのでは。
大手のITベンダーより、まだ歴史の浅い独立系ベンダーのほうが怪しい。
# まあいまなら普通Enum使ってるよねー。使える言語なら。
Re: (スコア:0)
enumなんぞは使いません，フツーは。
外部リソースに持たせます。
元号改正にこれだけ時間がかけられるのは今回が初です。 たいていは「明日改元だから，よろしく」なわけです。
ビルドやら配信やらが必要なenumは筋が悪い。
Re: (スコア:0)
いやいや、頻繁に追加や変更があるなら外部リソースにするでしょうが、
数十年に一回ならenumでしょう。
一度決まった元号が変わったりするわけでもないですし。
Re: (スコア:0)
数十年に一回なんだけどいつなんどき来るかわからないので外部リソースから読み出す方式のほうが安全だと思うなー。
Re: (スコア:0)
＞数十年に一回
これ自体が勘違い。
明日にでも天皇崩御して元号が変わり、その次の日にでも事故で新天皇が崩御なされて更に改元されることだってあり得る訳で
「いつ何時、何回おきるかわからないランダム」が正解
Re: (スコア:0)
そうそう、昭和と平成を区別できればいいんだからboolで十分なのに無駄なことしますよね。
https://twitter.com/naron__A/status/937184628388933633 [twitter.com]
Re: (スコア:0)
自分の会社とか鑑みて30年も前のノウハウをちゃんと継承し続けてる？
本当に？
Re: (スコア:0)
年号管理に Enum 使うとか、どんだけ頭悪くてもやらんだろう。
ベンダーの経験があるとか無いとかじゃなくて、普通に考えたら、そんな馬鹿げたことはしない。
Re: (スコア:0)
三十年前のノウハウとか言われても余計胡散臭く感じるが…
そもそも、前回は元号が変わってからの対応。今回は元号が変わる前から対応しなきゃならん。
全く生かせないとは思わないが、素人目には結構異質な気がするのだけど。
Re: (スコア:0)
平成の時は突然元号決まったので、テストは事後だった。
今回はテストは事前にできる。
でも、事前にテストするってことは、結合テスト規模なら計算機の時計をセットしなおすってことだ。
これが結構大変じゃないかな。月次処理とか、テスト項目ごとに、「みなさーん、時計を確認してくださーい」
Re: (スコア:0)
業務日付って概念知らないの?
Re: (スコア:0)
0時から変われば楽だけど午前6時からは新元号とか言われたら泣きながら岸壁に立って下を見下ろす
Re:日立のコメント (スコア:1)
地球上で同じ扱いの Julian day を考慮すると，日本時間の午前9時近辺
を指定されることは大いにありえますね。
それがどうしたとだからなんだと撥ね退ける強い意志が必要?
Re: (スコア:0)
午前9時に年号が変わるのでご心配なく。
#だよね？JST基準なんて恐ろしい事しないよね？