アカウント名:
パスワード:
天皇陛下「俺ももう歳だし、五輪前に急に死んじゃったらみんなに迷惑だから退位するわ」←わかる政治家「新元号の発表は新天皇即位まで発表しません。理由はそのほうが盛り上がるから」←わからない役所「対応間に合わないんで新元号になっても平成を使います」←ばかなの？
退位の意向を示されたのが2016年7月 [bbc.com] で、もう2年近くが経過しようとしているにもかかわらず、「間に合わない」って何なんでしょうかね。
今回は生前退位なので準備期間が長いですが、昭和天皇の際は体調を崩された(吐血)のが1988年9月 [wikipedia.org]で崩御が1989年1月ですから、今よりずっと短い期間(4ヶ月弱)で切り替えてることからすると、お役人さんたちは約30年でびっくりするくらい無能になったということなんでしょうか？
当時はほぼ紙と手書きだから、役所内の自分たちだけで頑張れば良かったから対応も簡単だったけど、コンピュータは自分たちで頑張れないし、変える範囲がどの程度あるかすら解ってなかったから。
どのぐらい掛かるか聞いたけど、オリンピックみたいに見積もりが甘くて、どうしよう？
長期的にはいずれ改元があるのはわかりきってる事で、仕様に含まれていない事がおかしいです。
UNIX timeみたいな感じで西暦も和暦も関係ない共通の内部コードつくっとけばいいのに。
長期的にいずれ、でしか無ければ製品寿命の方が短い可能性は十分あるので仕様に含めないことは必ずしもおかしな事では無いです。
そもそも共通の内部コードさえあれば変更が発生しない訳ではないので、、、# 表示や印字部分は何になるかが確定しないことには(少なくともデータセットは)変更できない
ただ、ソフトウェアの寿命は恐ろしいほど長いってのは2000年問題で学習したはずなので、あれから18年後の今の言い訳には苦しい。
さすがに2038年問題はtime_tの制限なので「対応したくてもできなかった」って弁解の余地くらいはあるだろうけど。
それって全ソフトウェアの寿命が長い訳ではなく「予想に反して恐ろしく長い寿命になってしまうものも一部ある」というだけなので、全ての製品で仕様に含めることを求められないのでは。# そういった可能性を理解して、顧客が仕様に含めて掛かる費用や必要な手間を受け入れてくれるなら、そりゃそれが一番良いんでしょうけど。
耐用年数無視して延命措置してムリヤリ動かしてた（動かされた）のが原因ですよね。
物理的劣化あるハードウェアですらそんな感じの扱いする人の手にかかれば、物理的劣化ないソフトウェアは永久に使えるモノ扱いされる（そして永久無料サポート要求クレーマー化）のでしょう。
初期のシステムは「耐用年数」なんて考えていないでしょう。
時が経過してシステムが重要になってくると、継続性が求められる金融機関や政府機関では、後方互換性を損なう改修は不可能なことが露呈してますね。
同時に古くて安定稼働したロジックは「信頼性」を勝ち取ってしまうので、ハードは更新されても中身は全く更新されていないことも珍しくない話で。(Z80なんて互換CPU含めて40年も生産され続けたし、今後も何十年使われ続けるのか分からない)
耐用期限を一方的に宣言して許されるのはコンシューマ向けの話だけ。（まぁ、心情的には許されてるわけでもないと思うが・・・・・）
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
わからない (スコア:5, すばらしい洞察)
天皇陛下「俺ももう歳だし、五輪前に急に死んじゃったらみんなに迷惑だから退位するわ」←わかる
政治家「新元号の発表は新天皇即位まで発表しません。理由はそのほうが盛り上がるから」←わからない
役所「対応間に合わないんで新元号になっても平成を使います」←ばかなの？
Re: (スコア:0)
退位の意向を示されたのが2016年7月 [bbc.com] で、もう2年近くが経過しようとしているにもかかわらず、「間に合わない」って何なんでしょうかね。
今回は生前退位なので準備期間が長いですが、昭和天皇の際は体調を崩された(吐血)のが1988年9月 [wikipedia.org]で崩御が1989年1月ですから、今よりずっと短い期間(4ヶ月弱)で切り替えてることからすると、お役人さんたちは約30年でびっくりするくらい無能になったということなんでしょうか？
Re: (スコア:0)
当時はほぼ紙と手書きだから、役所内の自分たちだけで頑張れば良かったから対応も簡単だったけど、
コンピュータは自分たちで頑張れないし、変える範囲がどの程度あるかすら解ってなかったから。
どのぐらい掛かるか聞いたけど、オリンピックみたいに見積もりが甘くて、どうしよう？
Re: (スコア:0)
長期的にはいずれ改元があるのはわかりきってる事で、
仕様に含まれていない事がおかしいです。
UNIX timeみたいな感じで西暦も和暦も関係ない共通の内部コードつくっとけばいいのに。
Re:わからない (スコア:2)
長期的にいずれ、でしか無ければ製品寿命の方が短い可能性は十分あるので仕様に含めないことは必ずしもおかしな事では無いです。
そもそも共通の内部コードさえあれば変更が発生しない訳ではないので、、、
# 表示や印字部分は何になるかが確定しないことには(少なくともデータセットは)変更できない
Re: (スコア:0)
ただ、ソフトウェアの寿命は恐ろしいほど長いってのは2000年問題で学習したはずなので、あれから18年後の今の言い訳には苦しい。
さすがに2038年問題はtime_tの制限なので「対応したくてもできなかった」って弁解の余地くらいはあるだろうけど。
Re:わからない (スコア:2)
それって全ソフトウェアの寿命が長い訳ではなく「予想に反して恐ろしく長い寿命になってしまうものも一部ある」というだけなので、全ての製品で仕様に含めることを求められないのでは。
# そういった可能性を理解して、顧客が仕様に含めて掛かる費用や必要な手間を受け入れてくれるなら、そりゃそれが一番良いんでしょうけど。
Re: (スコア:0)
耐用年数無視して延命措置してムリヤリ動かしてた（動かされた）のが原因ですよね。
物理的劣化あるハードウェアですらそんな感じの扱いする人の手にかかれば、物理的劣化ないソフトウェアは永久に使えるモノ扱いされる（そして永久無料サポート要求クレーマー化）のでしょう。
Re: (スコア:0)
初期のシステムは「耐用年数」なんて考えていないでしょう。
時が経過してシステムが重要になってくると、継続性が求められる金融機関や政府機関では、
後方互換性を損なう改修は不可能なことが露呈してますね。
同時に古くて安定稼働したロジックは「信頼性」を勝ち取ってしまうので、ハードは
更新されても中身は全く更新されていないことも珍しくない話で。
(Z80なんて互換CPU含めて40年も生産され続けたし、今後も何十年使われ続けるのか分からない)
耐用期限を一方的に宣言して許されるのはコンシューマ向けの話だけ。
（まぁ、心情的には許されてるわけでもないと思うが・・・・・）