アカウント名:
パスワード:
天皇が変われば元号も変わるって事自体はある程度予測が出来ると思うんだが、どうして初めから改元を想定したシステムを組まないんだろうか。
何となく想定できたのはこんなイメージ。1) エンジニアが改元を知らなかった2) 客が改元対応をを要求しなかった3) 改元対応した場合の見積があまりに高かったので削られた4) 改元時の受注を想定して敢えて改元対応しなかった
5)改元まで使われるシステムとは思わなかった
> 5)改元まで使われるシステムとは思わなかったそれな。
今年の頭にDOSプロンプトで動くエラーチェックプログラムが動かないって問い合わせがあって調べてみたら、ソース日付が2001年のプログラムで、15年分のテーブルが書かれてて、2016年12月で終わってたんだが、テーブルが書いてあるところの最後には「とりあえずこのくらい書いておけば大丈夫だろう」って書いてあったw
ええ、もちろん20年分テーブルを書き足しておきましたとも。
対応は最初からできているんですよ。もっと言えば、テーブルに1行足せばちゃんと動くようにすでになっていると思います。それでも、それをした時にちゃんと動くかの検証にお金がかかると日立とかは言っています。富士通もそれをしているけど、もったいぶって言っているように思えます。両方共、作業の内容は一緒だと思います。
富士通とNTTのはなってないよ。「そんな処理は作らないのが常識」とのお言葉wなので力業コード記述があちこちに。日付が数値型ならまだまし。文字列()で書式入り乱れて謎の値なんてのが有るから。元号記号らしきもので「G」みたのはどっちだったかな。。
日立は基本的に元号テーブルの形を取ってた。
タコなプログラマがびっくりするような対応やってたりするし検証は必要なんじゃね?
if(year.startWith("平成"))
だからそれら必要なテストを全部洗い出してテストするのが大変、ってのが富士通の見解でしょ。
おいstartsWith("Windows 9"))をバカにしていたらブーメランが返ってきた [livedoor.jp]OSの悪口はやめろ
どことは言わないが、俺は1文字目が「H」だとtruth、それ以外だとfalseを返す処理とか見たことがある…
truthって文字列ですかね。エラー時にはfalseって戻り値の方はvariant系ですかね?# 野暮な突込み
処理が高まってどっか走り抜けていってしまうのかもしれない。
#あのころはF1が元気だった
和暦を使うシステムなら改元を想定したシステムにはしてあると思うよ。
でもいつ、どの様な形で変わるかが確定してない状態じゃ最終なテスト出来ない訳で
・和暦を使っているシステムを全部洗いだして・実際の変更内容を反映してテストする
となると、そりゃまぁ相応に負荷は発生するよね。
可能性としては、最悪の場合は数日後に変わる場合もあるのだから和暦を使うなら普通は考慮してるものだしねそれ自体はテスト含めて大した作業工数じゃないのだから何かと批難されるWindowsも近年はwindowsアップデートさえすれば何もしないで済むシステムが構築できるようになってるし
まあ問題に挙がってるのは「普通」ができる余裕がなかったり「普通」の設計や実装ができる人間がいなかったシステムなんだろうけど
「普通」にやっているところは「普通の工程」として、「普通に」洗い出しとテストをやるんですよ。それが「普通に出来ない」ところは
・客に予算か理解か営業の交渉力(あるいは全て)が無い・技術者に度胸があり過ぎる
などな訳です。
# さて、普通とはなんだろう。
># さて、普通とはなんだろう。
「普士通」の略称
> # さて、普通とはなんだろう。
不通(コミュニケーションが取れない)のこと。
> 何かと批難されるWindowsも近年はwindowsアップデートさえすれば何もしないで済むシステムが構築できるようになってるし
とか安易に考えるバカのためにMSがわざわざ特設サイトまで [microsoft.com]立ててたな。
Windows95買ったのにPCついてこない!とかWindows7入れたのにタッチパネルないPCでタッチパネル使えるようにならない!とか中国版Windowsが認証はじかれる!とか
まあ、、、ある意味歴戦の猛者だからねえ。。w
#なにがあってもMSが悪い!と言い続けないと気が済まない人なんか訴訟しちゃえYO!
「天皇が死んだ時に切り替わる」という「変則ルール」がデフォだから。しかも今回はその原則を曲げて、異なるタイミングで切り替えることまでやってる。
「4年に一回あるが、100年に一回ない」とかでも検証はそれなりに手間取るのに、「期間は不規則です!次回がいつかはまだ決まってません!名称はこれから決めます」なもので対応も糞もあるか。
#ところで、新しい名前は決まったのかな?あれって「常に漢字2文字である」って#決まってるんだろうか。ルール変更して3文字以上になったら阿鼻叫喚。
https://ja.wikipedia.org/wiki/%E5%85%83%E5%8F%B7%E6%B3%95 [wikipedia.org]「留意」事項としては漢字2字であること。ってあるらしい。# 逆に言えば、法文としては明記されないのかな?どれくらいの強制力なんだろう。# 漢字2文字以外になったら帳票レイアウトを再設計とかありえるからホント地獄だろうね。。。
「期間は不規則です!次回がいつかはまだ決まってません!名称はこれから決めます」なもので対応も糞もあるか。
それはさすがに頭が悪すぎるのでは?
いつから何という元号に代わるかを入力すれば対応できるように設計することは、まあ言うほど簡単なことではないけど、「対応も糞もあるか」と思考停止してしまうほど難しい物ではあるまい。
事前にハードコーディングする、という設計しか知らないのなら話は別だけど。
「4年に一回あるが、100年に一回ない」とか
グレゴリオ暦の2/29日のことかしら。それだったら「4年に1回あるけど、400年に3回ない」だよね。
「天皇が死んだ時に切り替わる」じゃなくて、「天皇が代替わりしたときに切り替わる」でしょ。
伝統的にいいことや悪いことがあったらほいほい変えていたものを、ついこの間変更したものなので、そのへん細かいこと言っても意味ないんじゃないかしら
2000年が来ることは100%確実にわかってたのに(しかも事前にタイミングまで完璧に)どうして2000年問題に対応していないシステムが溢れていたと思います?
2000年が来る前に人類が滅亡する事を信じていた居た人が同等程度には溢れていたから。
「コンピューターが誤動作?なら手作業でやりゃあいいじゃん」という偉いさんもいたようです。残念ながらソロバンと帳簿の山でそれやってた経理"職人"たちは2000年を待たずして定年退職しており、帳簿も社内から消えてしまっています。
「システム管理者の眠れない夜」でした...
6) 天皇崩御後に対応する予定なので誰もやりたくなかった
テストが余計になるからでしょ。
昭和/平成までのテストで済むか、任意の文字列・日付を想定して将来の年号までテストするか。
書いてみたら後者のテストは手抜きになるわな。
漢字二文字になるのはほば確実だけど、過去には四文字年号もあるので絶対大丈夫とはいえない。(当時の)JISにない漢字が使われる可能性もないわけではない。とか考え出すと、どこまで想定すればいいのか仕様を決めるのもけっこうめんどう。
あの安倍さんなら漢字の文字数に制限なんて無いはず
7)改元=崩御を想定するなど不敬だから
でも今回で不敬ではなくなりますねよかったよかった
問題はUnicodeがいつ対応するかかな ㍾ ㍽ ㍼ ㍻ □ □ □
グリフはともかく、コードポイントぐらい決まったのかねえ。https://blogs.technet.microsoft.com/jperablog/ [microsoft.com]
まー、合字の追加がきまったところで、今更BMPに入れれるわけもなし。「UTF16ならサロゲートペア必須です」「新元号を合字で表示したいばあいはS-JIS不可です(WindowsがMS932の変換表を更新しないから)」「今時Windows XPとか使ってると、トーフになります」「Updateのかかっていないローカルなサーバ・PC連中も非対応」でレガシー環境が阿鼻叫喚になるので結局は使われない予感。
合字なんてまともに使ってるところ見たことないしなぁ…「本当に必要か」と言うと要らないよなShift-JISに入ってたから入れた、ってだけじゃろ
一応準備はしてあったんだけれど、これだけじゃ足りない。
Era Handling for the Japanese Calendarhttps://msdn.microsoft.com/en-us/library/windows/desktop/ee923790.aspx [microsoft.com]
こんなのがWindows Updateで降ってくるかもWindows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras]"2019 05 01"="仮名_仮_Test Era_X"
さすがに"1855 01 15"="安政_安_Ansei_A""1860 04 08"="万延_万_Mannen_M""1861 03 29"="文久_文_Bunkyuu_B""1864 03 27"="元治_元_Ganji_G""1865 05 01"="慶応_慶_Keioh_K"何て登録されていないか。
いま気づいたんだけど、"1868 01 01"="明治_明_Meiji_M"って間違ってないか(明治改元はグレゴリオ暦だと1868年1月25日、天保暦の1868年1月1日)?
オフトピだけど
別件で政府が公務員から月給泥棒することを正当化するために太陽暦採用というのも明治期の出来事だったから
元号表示の各年が旧暦・新暦でそれぞれ何月何日から何月何日まであって合計通日何日までだったなどということは漏れなくおこなっているかどうかとかとか。
規格書に盛り込んで保守維持すればかなりの手間が減るわけだが。
そもそも太陰暦に対応してるの? 天保暦だけじゃないし。
世界規模のOS・アプリケーションソフトなら、ヒジュラ暦に対応しているべきだろう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
素朴な疑問 (スコア:0)
天皇が変われば元号も変わるって事自体はある程度予測が出来ると思うんだが、
どうして初めから改元を想定したシステムを組まないんだろうか。
何となく想定できたのはこんなイメージ。
1) エンジニアが改元を知らなかった
2) 客が改元対応をを要求しなかった
3) 改元対応した場合の見積があまりに高かったので削られた
4) 改元時の受注を想定して敢えて改元対応しなかった
Re:素朴な疑問 (スコア:3, おもしろおかしい)
5)改元まで使われるシステムとは思わなかった
Re:素朴な疑問 (スコア:2, おもしろおかしい)
> 5)改元まで使われるシステムとは思わなかった
それな。
今年の頭にDOSプロンプトで動くエラーチェックプログラムが動かないって
問い合わせがあって調べてみたら、ソース日付が2001年のプログラムで、
15年分のテーブルが書かれてて、2016年12月で終わってたんだが、テーブルが
書いてあるところの最後には「とりあえずこのくらい書いておけば大丈夫だろう」
って書いてあったw
ええ、もちろん20年分テーブルを書き足しておきましたとも。
Re:素朴な疑問 (スコア:2)
対応は最初からできているんですよ。
もっと言えば、テーブルに1行足せばちゃんと動くようにすでになっていると思います。
それでも、それをした時にちゃんと動くかの検証にお金がかかると日立とかは言っています。
富士通もそれをしているけど、もったいぶって言っているように思えます。
両方共、作業の内容は一緒だと思います。
Re:素朴な疑問 (スコア:1)
富士通とNTTのはなってないよ。
「そんな処理は作らないのが常識」とのお言葉w
なので力業コード記述があちこちに。
日付が数値型ならまだまし。
文字列()で書式入り乱れて謎の値なんてのが有るから。
元号記号らしきもので「G」みたのはどっちだったかな。。
日立は基本的に元号テーブルの形を取ってた。
Re: (スコア:0)
タコなプログラマがびっくりするような対応やってたりするし検証は必要なんじゃね?
if(year.startWith("平成"))
Re: (スコア:0)
だからそれら必要なテストを全部洗い出してテストするのが大変、ってのが富士通の見解でしょ。
Re: (スコア:0)
おいstartsWith("Windows 9"))をバカにしていたらブーメランが返ってきた [livedoor.jp]OSの悪口はやめろ
Re: (スコア:0)
どことは言わないが、俺は1文字目が「H」だとtruth、それ以外だとfalseを返す処理とか見たことがある…
Re: (スコア:0)
truthって文字列ですかね。エラー時にはfalseって戻り値の方はvariant系ですかね?
# 野暮な突込み
Re:素朴な疑問 (スコア:1)
処理が高まってどっか走り抜けていってしまうのかもしれない。
#あのころはF1が元気だった
Re:素朴な疑問 (スコア:2)
和暦を使うシステムなら改元を想定したシステムにはしてあると思うよ。
でもいつ、どの様な形で変わるかが確定してない状態じゃ最終なテスト出来ない訳で
・和暦を使っているシステムを全部洗いだして
・実際の変更内容を反映してテストする
となると、そりゃまぁ相応に負荷は発生するよね。
Re: (スコア:0)
可能性としては、最悪の場合は数日後に変わる場合もあるのだから和暦を使うなら普通は考慮してるものだしね
それ自体はテスト含めて大した作業工数じゃないのだから
何かと批難されるWindowsも近年はwindowsアップデートさえすれば何もしないで済むシステムが構築できるようになってるし
まあ問題に挙がってるのは「普通」ができる余裕がなかったり「普通」の設計や実装ができる人間がいなかったシステムなんだろうけど
Re:素朴な疑問 (スコア:2)
「普通」にやっているところは「普通の工程」として、「普通に」洗い出しとテストをやるんですよ。
それが「普通に出来ない」ところは
・客に予算か理解か営業の交渉力(あるいは全て)が無い
・技術者に度胸があり過ぎる
などな訳です。
# さて、普通とはなんだろう。
Re: (スコア:0)
># さて、普通とはなんだろう。
「普士通」の略称
Re: (スコア:0)
> # さて、普通とはなんだろう。
不通(コミュニケーションが取れない)
のこと。
Re: (スコア:0)
> 何かと批難されるWindowsも近年はwindowsアップデートさえすれば何もしないで済むシステムが構築できるようになってるし
とか安易に考えるバカのためにMSがわざわざ特設サイトまで [microsoft.com]立ててたな。
Re:素朴な疑問 (スコア:1)
Windows95買ったのにPCついてこない!とか
Windows7入れたのにタッチパネルないPCでタッチパネル使えるようにならない!とか
中国版Windowsが認証はじかれる!とか
まあ、、、ある意味歴戦の猛者だからねえ。。w
#なにがあってもMSが悪い!と言い続けないと気が済まない人なんか訴訟しちゃえYO!
Re:素朴な疑問 (スコア:1)
「天皇が死んだ時に切り替わる」という「変則ルール」がデフォだから。
しかも今回はその原則を曲げて、異なるタイミングで切り替えることまでやってる。
「4年に一回あるが、100年に一回ない」とかでも検証はそれなりに手間取るのに、
「期間は不規則です!次回がいつかはまだ決まってません!名称はこれから決めます」
なもので対応も糞もあるか。
#ところで、新しい名前は決まったのかな?あれって「常に漢字2文字である」って
#決まってるんだろうか。ルール変更して3文字以上になったら阿鼻叫喚。
Re:素朴な疑問 (スコア:2)
それ以外は全て二文字ですね。
-- To be sincere...
Re:素朴な疑問 (スコア:2)
#ところで、新しい名前は決まったのかな?あれって「常に漢字2文字である」って
#決まってるんだろうか。ルール変更して3文字以上になったら阿鼻叫喚。
https://ja.wikipedia.org/wiki/%E5%85%83%E5%8F%B7%E6%B3%95 [wikipedia.org]
「留意」事項としては
漢字2字であること。
ってあるらしい。
# 逆に言えば、法文としては明記されないのかな?どれくらいの強制力なんだろう。
# 漢字2文字以外になったら帳票レイアウトを再設計とかありえるからホント地獄だろうね。。。
Re:素朴な疑問 (スコア:1)
「期間は不規則です!次回がいつかはまだ決まってません!名称はこれから決めます」
なもので対応も糞もあるか。
それはさすがに頭が悪すぎるのでは?
いつから何という元号に代わるかを入力すれば対応できるように設計することは、まあ言うほど簡単なことではないけど、「対応も糞もあるか」と思考停止してしまうほど難しい物ではあるまい。
事前にハードコーディングする、という設計しか知らないのなら話は別だけど。
Re: (スコア:0)
「4年に一回あるが、100年に一回ない」とか
グレゴリオ暦の2/29日のことかしら。それだったら「4年に1回あるけど、400年に3回ない」だよね。
Re: (スコア:0)
「天皇が死んだ時に切り替わる」じゃなくて、「天皇が代替わりしたときに切り替わる」でしょ。
Re: (スコア:0)
伝統的にいいことや悪いことがあったらほいほい変えていたものを、ついこの間変更したものなので、
そのへん細かいこと言っても意味ないんじゃないかしら
Re:素朴な疑問 (スコア:1)
2000年が来ることは100%確実にわかってたのに(しかも事前にタイミングまで完璧に)どうして2000年問題に対応していないシステムが溢れていたと思います?
Re:素朴な疑問 (スコア:1)
2000年が来る前に人類が滅亡する事を信じていた居た人が同等程度には溢れていたから。
Re: (スコア:0)
「コンピューターが誤動作?なら手作業でやりゃあいいじゃん」という偉いさんもいたようです。
残念ながらソロバンと帳簿の山でそれやってた経理"職人"たちは2000年を待たずして定年退職しており、帳簿も社内から消えてしまっています。
「システム管理者の眠れない夜」でした...
Re: (スコア:0)
6) 天皇崩御後に対応する予定なので誰もやりたくなかった
Re: (スコア:0)
テストが余計になるからでしょ。
昭和/平成までのテストで済むか、任意の文字列・日付を想定して
将来の年号までテストするか。
書いてみたら後者のテストは手抜きになるわな。
Re:素朴な疑問 (スコア:1)
漢字二文字になるのはほば確実だけど、過去には四文字年号もあるので絶対大丈夫とはいえない。
(当時の)JISにない漢字が使われる可能性もないわけではない。
とか考え出すと、どこまで想定すればいいのか仕様を決めるのもけっこうめんどう。
うじゃうじゃ
Re: (スコア:0)
あの安倍さんなら漢字の文字数に制限なんて無いはず
Re: (スコア:0)
7)改元=崩御を想定するなど不敬だから
Re: (スコア:0)
でも今回で不敬ではなくなりますね
よかったよかった
Re: (スコア:0)
問題はUnicodeがいつ対応するかかな ㍾ ㍽ ㍼ ㍻ □ □ □
Re: (スコア:0)
グリフはともかく、コードポイントぐらい決まったのかねえ。
https://blogs.technet.microsoft.com/jperablog/ [microsoft.com]
Re: (スコア:0)
まー、合字の追加がきまったところで、今更BMPに入れれるわけもなし。
「UTF16ならサロゲートペア必須です」
「新元号を合字で表示したいばあいはS-JIS不可です(WindowsがMS932の変換表を更新しないから)」
「今時Windows XPとか使ってると、トーフになります」
「Updateのかかっていないローカルなサーバ・PC連中も非対応」
でレガシー環境が阿鼻叫喚になるので結局は使われない予感。
Re:素朴な疑問 (スコア:2)
合字なんてまともに使ってるところ見たことないしなぁ…
「本当に必要か」と言うと要らないよな
Shift-JISに入ってたから入れた、ってだけじゃろ
備えあれば・・・ (スコア:0)
一応準備はしてあったんだけれど、これだけじゃ足りない。
Era Handling for the Japanese Calendar
https://msdn.microsoft.com/en-us/library/windows/desktop/ee923790.aspx [microsoft.com]
こんなのがWindows Updateで降ってくるかも
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras]
"2019 05 01"="仮名_仮_Test Era_X"
Re: (スコア:0)
さすがに
"1855 01 15"="安政_安_Ansei_A"
"1860 04 08"="万延_万_Mannen_M"
"1861 03 29"="文久_文_Bunkyuu_B"
"1864 03 27"="元治_元_Ganji_G"
"1865 05 01"="慶応_慶_Keioh_K"
何て登録されていないか。
Re: (スコア:0)
いま気づいたんだけど、
"1868 01 01"="明治_明_Meiji_M"
って間違ってないか(明治改元はグレゴリオ暦だと1868年1月25日、天保暦の1868年1月1日)?
Re:備えあれば・・・ (スコア:1)
オフトピだけど
別件で政府が公務員から月給泥棒することを正当化するために太陽暦採用
というのも明治期の出来事だったから
元号表示の各年が
旧暦・新暦でそれぞれ何月何日から何月何日まであって合計通日何日までだった
などということは漏れなくおこなっているかどうかとかとか。
規格書に盛り込んで保守維持すればかなりの手間が減るわけだが。
Re: (スコア:0)
そもそも太陰暦に対応してるの? 天保暦だけじゃないし。
Re: (スコア:0)
世界規模のOS・アプリケーションソフトなら、ヒジュラ暦に対応しているべきだろう。