アカウント名:
パスワード:
ただyyyymmddつけてだけじゃ伝わらないだろ・・・まだ末尾に日付をyyyymmddの形式でつけてくれって言ったほうが伝わるわからなければ聞き返せば良いって意見もあると思うけど最初から聞き返されない指示をするのも大事だよね
本人も認めている後だしttps://twitter.com/hyper_egg/status/1508431295046914056
この条件を踏まえて考えると、、「いつも曖昧指示出しているから部下or同僚から『言われたとおりに「yyyymmdd」つけましたよぉ』っていやがらせor反逆を受けたんじゃないの」と下衆の勘繰りがめばえてくるな
この推論に1票
曖昧な指示出しておいて「そうじゃない」と言い出す、「全部任せる」といったくせにあとから「そうじゃない」と言い出す上司って滅んで欲しい
Twitter上の振る舞いで自白したも同然だよね
ネタのインパクト優先していて、リンク先で後から補足されてるけど、
環境でのやらかしなのですよ
その後付けがうそくさいな
絶対つっこまれる内容を後出ししてる時点でまあ信用できるかっていうねでもツイッターだし気にしてもしょうがない炎上上等リツイート稼ぎ優先か
今度は「srad_日付をyyyymmddの形式で.pdf」が送られてくる…ことはさすがにないか。
言い方といえば、この元ネタを最初に見たとき「ん?同僚はyyyymmdd形式で送ったんだろ?『末尾(メールで)』は『メールの末尾』ってこと?」としばらく混乱してしまった
常識の余地が通じなかった相手を馬鹿にするエンジニアは嫌だなあ
みんな大好きMS Officeのワークシート関数とかVBA関数の日付指定書式なので、エンジニアでも馴染み深いのでは。少なくとも、私の職場に常駐している大手SIerの人たちはファイル名の付け方の説明でよく使ってます。
//同日でファイルをいくつも作ることを考えると、とても面倒な名前だと思う・・・。
>//同日でファイルをいくつも作ることを考えると、とても面倒な名前だと思う・・・。
テンポラリバックアップファイルだとfilename.yymmdd-nnファイル保存するときにすでにあると、nnをインクリメントしてます
最初 yymmdd-hhmmss にしてたら桁多すぎて見にくかった
個人的には、一日に数回程度編集する可能性のある物であれば、basename-yyyy-mm-dd-nn.extだな。nnは連番ね。一日に十回以上編集する可能性が有れば、nnnにする。年月日には、見やすさを優先して必ず区切り文字を入れる。桁数をケチる意味もか無かろう。8.3形式の時代じゃないんだから。
もちろん、バージョン管理システムが使えるのなら、そんなアホなことはしない。
basename-yyyy-mm-dd_山田2_田中2_佐藤みたいなのもありますね。
今更桁数を削る意識はないのですが yymmdd にすっかり慣れていて、逆に間にデリミタが入ると冗長だと感じてました。
2000年超えたときに yymmdd でソートするとちょっとめんどくさい結果になってたけど、もう今はそれも気にしてない。
テキストメモを残すときに、最初に書き起こした日付でソートしたい事がよくあるので。yymmdd_hogefuga_nn.txt というファイルを作り続けてます。
yymmddだと外国とのやりとりで誤解が生じやすいので(アメリカ人はmmddyyとしがちでヨーロッパ人はddmmyyとしがち)、外国とのやりとりがある場合には、誤解が生じにくいyyyymmddがおすすめですね。
やっぱり"HHMM"まで入れないと使いづらいですよね#そういうハナシじゃない
「MMはどっちが月でどっちが分なんです?ニヤニヤ」
hhも、HHだと24h表記、hhだったら12hというようにあるからね
Excelのフォーマット文字列は月も分もmで、前後にyかdがあったら月、前後にhかsがあったら分。yyyymmddhhmmssで年月日時分秒になるというのは確かにユーザーフレンドリーなんだけど、xlsxファイルを読み書きするプログラム作ってると殺意がわく。
MMが月でmmが分派
分や月だけを表示したいときはどうなるの?
すみません、元コメはちょっと間違えてました。hの後かsの前のmは分、それ以外は月 [microsoft.com]と、mの前後にy/dはなくてもデフォルトで月表示です。そのため月だけ表示はできますが、分だけ表示はできません。
ただし、経過時間を表す場合なら、大括弧でかこった「[m]」で分だけを表示できます(1時間20分が80表示になります)
yymmddhhmmss.ccまでつけなきや。
それはそれとして、04で済むものを「April」のようにソートの邪魔になるような文字列を使いたがる文化はヤードポンドと共に滅ぶべきである
先進的な我々は「卯月」とか使わない
中国は曜日も数字なんだよなぁ
アレは不思議ですよね。七曜って中国でから日本にやって来たもんだ [kcg.ac.jp]と思ってたんですが、いつの間にかに使わなくなってたんですかね。
しかも洋の東西でズレがないと言われると、ホントかそれと思ったりします。
中国で違うんのはなんでやねんと私も思いましたが、清朝末に当時の偉い人が音頭を取って変えたとかだったと思います
西洋と縁が薄いころは七曜はたいして使われてなかったんじゃないかな
日本式の場合曜日は末尾だし年月日の時点でソート順が確定するからソートの邪魔にならない。
04で済むものを「April」のようにソートの邪魔になるような文字列を使いたがる文化
まったくその通りだと思うけど、sortコマンドに「-M, --month-sort」オプションを用意してたりするのは大したもんだと思わんでも…。
ちょっと違うがgmailで日時を「昨日」「x日前」とかの表記も止めて欲しい
github「えっ?」
> 04で済むものを「April」のように
やった事あるなぁアメリカと欧州相手だと、dd-mm-yyyy か、mm-dd-yyyy か分からなくなるので、わざと April そして yy じゃなくて、yyyy
> dd-mm-yyyy か、mm-dd-yyyy か分からなくなる
やつらがいつまでたっても月を英名で表記するのはまさにそれが理由
数値で月を表して、親切にJANUARYやFEBRUARYといった定数を定義してくれたJavaという言語がありましてね。なおJANUARYが0。
逆に通じない。
yyyymmdd派とyyyyMMdd派が2大巨頭。
あと、実際にファイル名に付けてほしいのが"yyyymmdd"そのものだった経験があるから困る本人いわく自分が後で日付をつけるときの備忘のためだとか何とか…
他にもいろいろあってその人相手には指示通りそのまんまのことしかしなくなりました事前に確認しても反応なしならまだマシ、下手すると「わかるだろ!」とカミナリがとぶ#確認してもしなくても結果的に怒り出すなら確認しないほうが工数が少なくてすむ、、
うちもテンプレートになる文書はyyyymmdd付けることあるから変な指示でもないなと思う。
第一段落だけならそれほどおかしくないけど第二段落はちょっと
潜在バグがいつ爆発するかどきどきですね
まれによくある話ですね
逆に言うと、新人がそういうことやりだしたら自分が「それぐらいわかるだろ」式の対応をしていないか反省する必要がある。たいてい自覚すらないからね。件のツイート主もまさに条件後出しやってるし
こうやってすぐお前の説明ガーて噛みつく人いるけど、そういう人って日々の物事の説明を完全に伝えられているんでしょうか。
大体こういう話は双方のその時点でもつコンテキストの違いによって起きるのであって、そのコンテキストを一致させないと何処でも起きる話であり、そしてコンテキストを一致させる作業はそこそこ重いので、軽い作業指示の都度のコミュニケーションで毎回やるなんてのは非効率極まりない。だから「当然わかるよね」でそのフェイズを省いて伝えることなんかいくらでもある。そんなことはないという人でも例えば何かのデータの集計がほしいときに、まさか「加減乗除はわかりますよね?」から入ることはないだろう。てことは「日本にいる社会人なら加減乗除は当然わかっている」という前提で指示をすることになるわけで、この話とそんなに違うことではないよね。
日本がハイコンテキストな文化だったのは、日本の貧富の差・階層の差が小さかったからだと思うんだけど、今やそんなことは言ってられなくなったので、ローコンテキストなコミュニケーションを心がける必要がある、と言う事なんだろうね。
yyyymmddって加減乗除レベルで当然の話なの?
コンテキストを一致させる作業はそこそこ重いので、yyyymmddって加減乗除レベルで当然の話とさせていただきます。
違うでしょ端折って良い部分と端折ったらいけない部分があるってことでしょ
日本語わかる?計算わかる?なんてのは当たり前だけど言わなくてもわかる部分当然これは省略してもいい訳
今回のは末尾にyyyymmddをつけてという末尾にそのままyyyymmddとつけるのか日付をつけるのか明確になってない必要な指示を省略しておいて愚痴ったり、「わからないなら聞け」だとか無駄な説教をしたいなら別だけどな
> 端折っていい部分と端折ったらいけない部分その線引こそコンテキストなのでは。あなたと私のそれは間違いなく一致しないよ。
義務教育で学ぶから省略していい、という線引だとして、それ以外のことは全部前提を省略せずにコミュニケーション取ってるとすれば相当回りくどいよ。
わからないところは聞いて、を、マウントのためだと受け取る人には何言っても仕方ないが、本来は前提知識のギャップを埋めさせて、という意味だと思うけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
言い方が悪い (スコア:0)
ただyyyymmddつけてだけじゃ伝わらないだろ・・・
まだ末尾に日付をyyyymmddの形式でつけてくれって言ったほうが伝わる
わからなければ聞き返せば良いって意見もあると思うけど最初から聞き返されない指示をするのも大事だよね
Re:言い方が悪い (スコア:2, 興味深い)
本人も認めている後だし
ttps://twitter.com/hyper_egg/status/1508431295046914056
この条件を踏まえて考えると、、
「いつも曖昧指示出しているから部下or同僚から『言われたとおりに「yyyymmdd」つけましたよぉ』っていやがらせor反逆を受けたんじゃないの」と下衆の勘繰りがめばえてくるな
Re: (スコア:0)
この推論に1票
曖昧な指示出しておいて「そうじゃない」と言い出す、
「全部任せる」といったくせにあとから「そうじゃない」と言い出す上司って滅んで欲しい
Re: (スコア:0)
Twitter上の振る舞いで自白したも同然だよね
Re:言い方が悪い (スコア:1)
ネタのインパクト優先していて、リンク先で後から補足されてるけど、
環境でのやらかしなのですよ
Re: (スコア:0)
その後付けがうそくさいな
Re: (スコア:0)
絶対つっこまれる内容を後出ししてる時点でまあ信用できるかっていうね
でもツイッターだし気にしてもしょうがない
炎上上等リツイート稼ぎ優先か
Re:言い方が悪い (スコア:1)
今度は「srad_日付をyyyymmddの形式で.pdf」が送られてくる…ことはさすがにないか。
Re: (スコア:0)
言い方といえば、この元ネタを最初に見たとき
「ん?同僚はyyyymmdd形式で送ったんだろ?『末尾(メールで)』は『メールの末尾』ってこと?」
としばらく混乱してしまった
常識の余地が通じなかった相手を馬鹿にするエンジニアは嫌だなあ
Re: (スコア:0)
Re:言い方が悪い (スコア:1)
みんな大好きMS Officeのワークシート関数とかVBA関数の日付指定書式なので、エンジニアでも馴染み深いのでは。
少なくとも、私の職場に常駐している大手SIerの人たちはファイル名の付け方の説明でよく使ってます。
//同日でファイルをいくつも作ることを考えると、とても面倒な名前だと思う・・・。
Re:言い方が悪い (スコア:1)
>//同日でファイルをいくつも作ることを考えると、とても面倒な名前だと思う・・・。
テンポラリバックアップファイルだと
filename.yymmdd-nn
ファイル保存するときにすでにあると、nnをインクリメントしてます
最初 yymmdd-hhmmss にしてたら桁多すぎて見にくかった
Re:言い方が悪い (スコア:1)
個人的には、一日に数回程度編集する可能性のある物であれば、
basename-yyyy-mm-dd-nn.ext
だな。nnは連番ね。一日に十回以上編集する可能性が有れば、nnnにする。
年月日には、見やすさを優先して必ず区切り文字を入れる。
桁数をケチる意味もか無かろう。8.3形式の時代じゃないんだから。
もちろん、バージョン管理システムが使えるのなら、そんなアホなことはしない。
Re:言い方が悪い (スコア:1)
basename-yyyy-mm-dd_山田2_田中2_佐藤
みたいなのもありますね。
Re:言い方が悪い (スコア:1)
今更桁数を削る意識はないのですが yymmdd にすっかり慣れていて、逆に間にデリミタが入ると冗長だと感じてました。
2000年超えたときに yymmdd でソートするとちょっとめんどくさい結果になってたけど、もう今はそれも気にしてない。
テキストメモを残すときに、最初に書き起こした日付でソートしたい事がよくあるので。
yymmdd_hogefuga_nn.txt というファイルを作り続けてます。
Re:言い方が悪い (スコア:1)
yymmddだと外国とのやりとりで誤解が生じやすいので(アメリカ人はmmddyyとしがちでヨーロッパ人はddmmyyとしがち)、外国とのやりとりがある場合には、誤解が生じにくいyyyymmddがおすすめですね。
Re: (スコア:0)
やっぱり"HHMM"まで入れないと使いづらいですよね
#そういうハナシじゃない
Re: (スコア:0)
「MMはどっちが月でどっちが分なんです?ニヤニヤ」
Re:言い方が悪い (スコア:2, 参考になる)
hhも、HHだと24h表記、hhだったら12hというようにあるからね
Re:言い方が悪い (スコア:1)
Excelのフォーマット文字列は月も分もmで、
前後にyかdがあったら月、
前後にhかsがあったら分。
yyyymmddhhmmssで年月日時分秒になるというのは確かにユーザーフレンドリーなんだけど、
xlsxファイルを読み書きするプログラム作ってると殺意がわく。
Re: (スコア:0)
MMが月でmmが分派
Re: (スコア:0)
分や月だけを表示したいときはどうなるの?
Re:言い方が悪い (スコア:1)
すみません、元コメはちょっと間違えてました。
hの後かsの前のmは分、それ以外は月 [microsoft.com]と、mの前後にy/dはなくてもデフォルトで月表示です。そのため月だけ表示はできますが、分だけ表示はできません。
ただし、経過時間を表す場合なら、大括弧でかこった「[m]」で分だけを表示できます(1時間20分が80表示になります)
Re: (スコア:0)
yymmddhhmmss.ccまでつけなきや。
Re:言い方が悪い (スコア:1)
それはそれとして、04で済むものを「April」のように
ソートの邪魔になるような文字列を使いたがる文化は
ヤードポンドと共に滅ぶべきである
先進的な我々は「卯月」とか使わない
Re:言い方が悪い (スコア:2)
中国は曜日も数字なんだよなぁ
Re:言い方が悪い (スコア:2)
アレは不思議ですよね。七曜って中国でから日本にやって来たもんだ [kcg.ac.jp]と思ってたんですが、
いつの間にかに使わなくなってたんですかね。
しかも洋の東西でズレがないと言われると、ホントかそれと思ったりします。
Re:言い方が悪い (スコア:2)
中国で違うんのはなんでやねんと私も思いましたが、
清朝末に当時の偉い人が音頭を取って変えたとかだったと思います
西洋と縁が薄いころは七曜はたいして使われてなかったんじゃないかな
Re: (スコア:0)
日本式の場合曜日は末尾だし年月日の時点でソート順が確定するからソートの邪魔にならない。
Re:言い方が悪い (スコア:1)
04で済むものを「April」のようにソートの邪魔になるような文字列を使いたがる文化
まったくその通りだと思うけど、sortコマンドに「-M, --month-sort」オプションを用意してたりするのは大したもんだと思わんでも…。
Re: (スコア:0)
ちょっと違うがgmailで日時を「昨日」「x日前」とかの表記も止めて欲しい
Re: (スコア:0)
github「えっ?」
Re: (スコア:0)
> 04で済むものを「April」のように
やった事あるなぁ
アメリカと欧州相手だと、dd-mm-yyyy か、mm-dd-yyyy か分からなくなるので、
わざと April そして yy じゃなくて、yyyy
Re: (スコア:0)
> dd-mm-yyyy か、mm-dd-yyyy か分からなくなる
やつらがいつまでたっても月を英名で表記するのはまさにそれが理由
Re: (スコア:0)
数値で月を表して、親切にJANUARYやFEBRUARYといった定数を定義してくれたJavaという言語がありましてね。
なおJANUARYが0。
Re: (スコア:0)
逆に通じない。
yyyymmdd派とyyyyMMdd派が2大巨頭。
Re: (スコア:0)
あと、実際にファイル名に付けてほしいのが"yyyymmdd"そのものだった経験があるから困る
本人いわく自分が後で日付をつけるときの備忘のためだとか何とか…
他にもいろいろあってその人相手には指示通りそのまんまのことしかしなくなりました
事前に確認しても反応なしならまだマシ、下手すると「わかるだろ!」とカミナリがとぶ
#確認してもしなくても結果的に怒り出すなら確認しないほうが工数が少なくてすむ、、
Re:言い方が悪い (スコア:1)
うちもテンプレートになる文書はyyyymmdd付けることあるから変な指示でもないなと思う。
Re: (スコア:0)
第一段落だけならそれほどおかしくないけど第二段落はちょっと
Re: (スコア:0)
潜在バグがいつ爆発するかどきどきですね
Re: (スコア:0)
まれによくある話ですね
Re: (スコア:0)
逆に言うと、新人がそういうことやりだしたら自分が「それぐらいわかるだろ」式の対応をしていないか反省する必要がある。たいてい自覚すらないからね。件のツイート主もまさに条件後出しやってるし
Re: (スコア:0)
こうやってすぐお前の説明ガーて噛みつく人いるけど、
そういう人って日々の物事の説明を完全に伝えられているんでしょうか。
大体こういう話は双方のその時点でもつコンテキストの違いによって起きるのであって、
そのコンテキストを一致させないと何処でも起きる話であり、そしてコンテキストを一致させる作業はそこそこ重いので、
軽い作業指示の都度のコミュニケーションで毎回やるなんてのは非効率極まりない。
だから「当然わかるよね」でそのフェイズを省いて伝えることなんかいくらでもある。
そんなことはないという人でも例えば何かのデータの集計がほしいときに、
まさか「加減乗除はわかりますよね?」から入ることはないだろう。
てことは「日本にいる社会人なら加減乗除は当然わかっている」という前提で指示をすることになるわけで、
この話とそんなに違うことではないよね。
Re:言い方が悪い (スコア:1)
日本がハイコンテキストな文化だったのは、日本の貧富の差・階層の差が小さかったからだと思うんだけど、今やそんなことは言ってられなくなったので、ローコンテキストなコミュニケーションを心がける必要がある、と言う事なんだろうね。
Re: (スコア:0)
yyyymmddって加減乗除レベルで当然の話なの?
Re: (スコア:0)
コンテキストを一致させる作業はそこそこ重いので、yyyymmddって加減乗除レベルで当然の話とさせていただきます。
Re: (スコア:0)
違うでしょ
端折って良い部分と端折ったらいけない部分があるってことでしょ
日本語わかる?計算わかる?なんてのは当たり前だけど言わなくてもわかる部分
当然これは省略してもいい訳
今回のは末尾にyyyymmddをつけてという末尾にそのままyyyymmddとつけるのか日付をつけるのか明確になってない
必要な指示を省略しておいて愚痴ったり、「わからないなら聞け」だとか無駄な説教をしたいなら別だけどな
Re: (スコア:0)
> 端折っていい部分と端折ったらいけない部分
その線引こそコンテキストなのでは。
あなたと私のそれは間違いなく一致しないよ。
義務教育で学ぶから省略していい、という線引だとして、それ以外のことは全部前提を省略せずにコミュニケーション取ってるとすれば相当回りくどいよ。
わからないところは聞いて、を、マウントのためだと受け取る人には何言っても仕方ないが、
本来は前提知識のギャップを埋めさせて、という意味だと思うけどね。