おはよ
起動しています
このアカウントは、notestockで公開設定になっていません。
家の前で下水工事はじまってすごい音なので、骨伝導イヤホンとカナル型イヤホンを両方付けてる
(カナル型の方はただの耳栓代わり)
(カナル型のはウォークマン用でコード短いのでパソコンまで届かない)
null安全じゃない言語は型安全でもないという思想をもっています
型シグネチャ上呼べるはずのメソッドを呼べないオブジェクトだからね。
(ぬるぽだと言わずに、そんなメソッドはnullにはないというエラーを出すJSとかRubyだとはっきりするよね)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
住宅ローンの固定金利は上がってても変動金利のやつはまだまだ低いままっていうじゃない
でも、世の中うまい話はないの法則からいきますとね、多分固定金利ががっつり上がりきって借り換えで逃げる先がなくなってから満を持して変動金利が上がってくると思うんですよね
(逆の順番だったら、変動金利が上がるってなったら固定金利に借り換えて逃げればいいじゃない、でもそんな簡単に逃げられるような都合のいい話があるわけはないからってこと)
このアカウントは、notestockで公開設定になっていません。
日本時間のタイムゾーン書くとき、 +09:00 って書いてる? Asia/Tokyo って書いてる?
この二つは意味が違うのよね。日本の政治家はときどきいきなり「2時間のサマータイムを導入しましょうね」とか言い出すので、サマータイムが入った瞬間に Asia/Tokyo と +09:00 が別のタイムゾーンを指すようになっちゃう。
そうなったときに大丈夫なんだっけで書き分けてね。
UI層は、生活時間を表示するのがいいからAsia/Tokyoのほう。
処理とか格納ではある日突然時刻がずれると多分困るので +09:00 の方がいいよ。(たとえば、日本時間ベースで日次集計値を出してます、なんてときはサマータイムの入口と出口で22時間の区間と26時間の区間ができちゃいましたとか、困る)(DBに日本時間を格納している悪い子はいないと思うけど、もし格納するとしても+09:00にしとかないと大混乱するぞ)
あるとき突然サマータイムを導入したときの社会の混乱だけど、契約上の日時がずれた結果のトラブルってのが、決して大量には起きないだろうけど面倒そう。
例えばサマータイム2時間を導入したとする。
その前に契約された自動車保険が、サマータイム期間中の8/31 16:00 までっていう契約になっていたとする。
この自動車保険が有効なのは、その日の(サマータイムで早まった)時計の16時まで?
それとも、契約時点で合意された瞬間(法改正後の呼び方だと18時)まで?
ピンポイントで17時に事故起こして保険有効無効で盛大にもめてほしい気持ちがある。
このアカウントは、notestockで公開設定になっていません。