アカウント名:
パスワード:
プログラマをやってると「あの家電の液晶画面は俺が作ったんだよねー」的な昔話ができるんですが「バグ作り込んだら新聞に載っちゃったよー」的な話も一度ぐらいあっても良いなぁと思いました.
和暦の1の位が「1」だった場合に「元」に変換する処理なんて,ネタとして面白すぎます.楽しい職場だと思いませか?私も愉快なバグを作って歴史に名を残したい.
>和暦の1の位が「1」だった場合に「元」に変換する処理なんて,ネタとして面白すぎます.楽しい職場だと思いませか?
なんで「和暦の1の位」だけ見ちゃうんでしょうね。素直に 和暦の値自体が "1" であれば "元" に置き換える でいいのに。if($koyomi = 1){ $koyomi = "元";}
ウチの若いプログラマは日付(和暦)をいぢるロジックにおいて「年は二桁」として扱うコードを書いた。そして改元対応による検証時にそれが発覚した。
1桁の年を経験したことがなかったことが原因らしいが,月とか日とか時とか,いくらでも類推できる材料はあるだろうに。
「これは友人の・・・あくまで私の友人の話なのだが。」
わかります。
現行ルールだと三桁も想定するかどうかは悩みどころですね一世一元なので幼児で即位すれば3桁はありえるけど、そもそも幼児即位が起こりづらい
現皇太子殿下が59歳、流石に(よほど革命的な医療技術の進歩がない限り)160歳まで現役、ということはなかろうし。最短で100年後まで現行システムが動いてたら、それは文字通り「世も末」だろうしなぁ。
というか、現皇太子殿下が160歳まで健在でおられる確率について考えないとしても、その頃までITシステムに元号が残ってる可能性は、ほぼ0になるのではなかろうか。
超長期国債の場合,発行時の償還期限が元号3桁になる場合がありそうだけど.
s/1年/元年/g; とか(相当する各プログラミング言語の機能で)やってたんじゃないですかね。
ソースコードの、"平成31年"という文字列に変更されて以降の処理の部分しかいじれなかったので、s/1年/元年/gを入れた、とか?
そもそもソースが不明で、変換後の文字列の格納域を外部から書き換えているとか。
なるほど元を触れない場合もありますね。役所の処理系とかだと、かなりこだわった仕様や制約もありそう。
せやろか
なるほど元を触れない場合もありますね。
いや、だから「元」だけ触った結果こうなったんだってば。
データ仕様的に文字列では?#問題起こるとこ共通仕様
昔ながらの固定長レコードかそれに近い感覚で扱ってて参照すべき桁数指定間違えたとか、文字列配列のN番目(文字列)のつもりで文字列のN番目(文字)参照しちゃったとか、フィールド切り出しか置換のどっちかで正規表現使っててミスったとか、まぁ想像だけなら色々できる。
むしろ見ない処理の方が多そうなのに。
1th, 2th, 3th, 4th,5th
いちおう後で直す気はあったんだよーーー
油断すると、21th, 22th, 23th をやっちゃう罠。#「トゥウェンティーファースト」って読めば間違えないんだろうけど、#「にじゅういちす」って読んでたりするので気づきにくい…
自分が見たのは逆だ。最後の桁しか見てないので、11st,12nd,13rd
$koyomiの入力元データが"01"の場合と" 1"の場合を想定し確認しましたか?
ifの中で代入するんですか?
そこ突っ込むのならそもそも1が文字列じゃない(何らかの型変換に頼っている)って部分のほうにも突っ込むべきでは。明示的に10進数で数値化してから比較すべきかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
歴史に名を残す仕事 (スコア:1)
プログラマをやってると「あの家電の液晶画面は俺が作ったんだよねー」的な昔話ができるんですが
「バグ作り込んだら新聞に載っちゃったよー」的な話も一度ぐらいあっても良いなぁと思いました.
和暦の1の位が「1」だった場合に「元」に変換する処理なんて,ネタとして面白すぎます.楽しい職場だと思いませか?
私も愉快なバグを作って歴史に名を残したい.
Re:歴史に名を残す仕事 (スコア:2)
>和暦の1の位が「1」だった場合に「元」に変換する処理なんて,ネタとして面白すぎます.楽しい職場だと思いませか?
なんで「和暦の1の位」だけ見ちゃうんでしょうね。
素直に 和暦の値自体が "1" であれば "元" に置き換える でいいのに。
if($koyomi = 1){ $koyomi = "元";}
Re:歴史に名を残す仕事 (スコア:1)
ウチの若いプログラマは日付(和暦)をいぢるロジックにおいて「年は二桁」として扱うコードを書いた。そして改元対応による検証時にそれが発覚した。
1桁の年を経験したことがなかったことが原因らしいが,月とか日とか時とか,いくらでも類推できる材料はあるだろうに。
Re:歴史に名を残す仕事 (スコア:1)
「これは友人の・・・あくまで私の友人の話なのだが。」
わかります。
Re: (スコア:0)
現行ルールだと三桁も想定するかどうかは悩みどころですね
一世一元なので幼児で即位すれば3桁はありえるけど、そもそも幼児即位が起こりづらい
Re: (スコア:0)
現行ルールだと三桁も想定するかどうかは悩みどころですね
一世一元なので幼児で即位すれば3桁はありえるけど、そもそも幼児即位が起こりづらい
現皇太子殿下が59歳、流石に(よほど革命的な医療技術の進歩がない限り)160歳まで現役、ということはなかろうし。
最短で100年後まで現行システムが動いてたら、それは文字通り「世も末」だろうしなぁ。
というか、現皇太子殿下が160歳まで健在でおられる確率について考えないとしても、その頃までITシステムに元号が残ってる可能性は、ほぼ0になるのではなかろうか。
超長期国債 (スコア:1)
超長期国債の場合,発行時の償還期限が元号3桁になる場合がありそうだけど.
Re:歴史に名を残す仕事 (スコア:1)
s/1年/元年/g; とか(相当する各プログラミング言語の機能で)やってたんじゃないですかね。
Re: (スコア:0)
ソースコードの、"平成31年"という文字列に変更されて以降の処理の部分しかいじれなかったので、s/1年/元年/gを入れた、とか?
Re: (スコア:0)
そもそもソースが不明で、変換後の文字列の格納域を外部から書き換えているとか。
Re:歴史に名を残す仕事 (スコア:1)
なるほど元を触れない場合もありますね。
役所の処理系とかだと、かなりこだわった仕様や制約もありそう。
Re: (スコア:0)
せやろか
Re: (スコア:0)
なるほど元を触れない場合もありますね。
いや、だから「元」だけ触った結果こうなったんだってば。
Re: (スコア:0)
データ仕様的に文字列では?
#問題起こるとこ共通仕様
Re: (スコア:0)
昔ながらの固定長レコードかそれに近い感覚で扱ってて参照すべき桁数指定間違えたとか、
文字列配列のN番目(文字列)のつもりで文字列のN番目(文字)参照しちゃったとか、
フィールド切り出しか置換のどっちかで正規表現使っててミスったとか、
まぁ想像だけなら色々できる。
Re: (スコア:0)
むしろ見ない処理の方が多そうなのに。
1th, 2th, 3th, 4th,5th
いちおう後で直す気はあったんだよーーー
Re:歴史に名を残す仕事 (スコア:2)
油断すると、21th, 22th, 23th をやっちゃう罠。
#「トゥウェンティーファースト」って読めば間違えないんだろうけど、
#「にじゅういちす」って読んでたりするので気づきにくい…
Re:歴史に名を残す仕事 (スコア:2)
自分が見たのは逆だ。最後の桁しか見てないので、
11st,12nd,13rd
Re: (スコア:0)
Re: (スコア:0)
$koyomiの入力元データが"01"の場合と" 1"の場合を想定し確認しましたか?
ifの中で代入するんですか?
Re: (スコア:0)
そこ突っ込むのならそもそも1が文字列じゃない(何らかの型変換に頼っている)って部分のほうにも突っ込むべきでは。
明示的に10進数で数値化してから比較すべきかと。