>& STDOUT

主にソフトウェアに関する日々の標準出力+標準エラー出力

もう曜日を間違わない!2019年まで!

私、曜日を間違えるんです…。日付を書くとき、数字だけだと味気ないので補完する情報として曜日を併記したいじゃないですか。でもそれがズレてたりすると、情報の価値がゼロどころかマイナスになってしまうという諸刃の剣。


どっちかというとリスクの方が大きいので、厳正にやるならいっそ書かない方が良いのかもですが、21世紀にもなってそれぐらいコンピュータっていうの?アレでサクッとやってくださいよいい加減、とも思うのです。というか、機械で出来そうな事に1ナノたりとも注意を払うのが嫌なんです。


で、MS-IMEのプラグイン作れないかと探ってみたのですが簡単には見つからなかったので、最もダサいけど、とりあえず手っ取り早く解決できる方法で行く事にしました。そう、


辞書ファイル。


Excelさんでオートフィルったモノを正規表現でうにょうにょごにょごにょ置換して出来上がり!20分ぐらい。
20分で10年間違わないなら、いいじゃない!


yyyymmdd_with_youbi_win.txt 直
yyyymmdd_with_youbi_mac.txt 直


上がWindows用。下がMac用です。それぞれ、MS-IMEことえり の辞書登録からご利用ください。

使い方

「2010−10−1」とか打って変換すると、2010/10/1(金) と出ます。2010/10/1(金)〜2019/12/31(火)まで対応です。その頃までにはなんかもっとクールな方法があるでしょーということで。

ハッカーは

目の前の面倒くさい事を解決するためなら、どんな面倒な事でもやる。と何かの本で読みましたが、たぶんこういうことではないと思う。

テスターは

Excelのオートフィルを信用してないワケではないのですが、テストエンジニアの性として、こういうのみるとテストしたくなりますよね。よね。ということで、以下のテストケースで確認しました。


ID.入力値 → 変換後の期待値
A.2010−10−1 → 2010/10/1(金)
B.2012−2−29 → 2012/2/29(水)
C.2016−2−29 → 2016/2/29(月)
D.2019−12−31 → 2019/12/31(火)
E.2010−9−30 → 変換失敗
F.2020−1−1 → 変換失敗
G.2010−10−111 → 変換失敗
H.2010−9−31 → 変換失敗
I.2012−3−1 → 2012/3/1(木)
J.2010/3/1 → 変換失敗


考えかたとして、


A.境界値
B.日付をみたら閏年を疑え
C.日付をみたら閏年を疑え
D.境界値
E.境界値
F.境界値
G.異常値
H.異常値
I.有効同値クラスと閏年境界を兼ねて
J.無効同値クラス


です。結果、Gのケースが 「2010/10/1(金)11」 と変換されてしまう不具合あります。さらに、月の数字が1桁のとき、01とか、02とかついちゃってますね。修正しますー。ああああう。

修正しました

2011/1/1(土)!おし!
ああ、もう。テストエンジニア冥利に尽きるエントリになったわ。