Google PayからチャージすればモバイルSuicaの年会費は払わなくて良い

Pixel 3aがバレンタインセールで1万円引きだったので注文して、きのう届いた。なぜ買ったかというとFeliCaが使えるということに尽きる。
地下鉄に乗ったりコンビニで買い物したりするときにスマホをかざせば完了するのはよさそうと思っていて、試してみたらすでに最高の暮らしが始まっている。
モバイルSuicaで買い物できるのは便利だけど、買い物以外の体験はいまいちだった。モバイルSuicaの公式アプリは悲惨な出来で、ガラケー用のUIがそのまま登場したり、チャージボタンを押すと、ファーストビューはお知らせが埋まっていて、下までスクロールするとチャージに飛べたりする。また、年会費1030円かかる。
というあたりが不満という話をしたら、Google Pay経由で入金すればモダンなUIが出るし、年会費1030円もかからない、とのことだった。なんだそれ感が強い。
時間のほうがもったいないのでふだん小銭のことは気にしないので1000円くらいの出費は無視してるのだけど押すボタンの違いによって1000円かかったりかからなかったりするのは理不尽だなと感じる。

モバイルSuicaを使い始めたい人はまずこのページを見ると良さそう。
www.jreast.co.jp

更にタイミング悪いことに来週くらいから年会費無料になりそうだった。

JR東日本は、「モバイルSuica」について、2020年2月26日以降、年会費を全面的に無料とすると発表しました。

japanese.engadget.com

歯医者

• 先週は歯型を取った。今日は麻酔して歯の治療をする
  • 先週18:30くらいに会社を抜けたのはちょっと無理があったので今週は19:30で予約を取った
• 所見
  • 噛み合わせが悪くて、噛んだときに物が詰まりやすい構造であり、虫歯ができやすい
  • 虫歯は削って、隣の歯との間も詰めて、物が詰まりにくい形にする
  • 小さければ白い詰め物、大きければ金属を詰める
• 神経を抜いたりする必要はありますか?
  • 大きな虫歯だけど、そこまでひどくはないであろう
    • きっと神経を抜くことになるだろうけど不安を抱えているよりはマシだろうと思って来てみたので意外だった!
• 麻酔して5分待つ
  • 麻酔好きで、顔の半分だけ酔っ払ってるみたいな状態になる
  • 二重あごが解消する顔の体操の映像を見ていた
• 削っていって、白い詰め物をして、謎の光を浴びて、完成
  • 謎の光はレジンを固める光っぽい 歯医者で青い光を歯に当てる理由 [虫歯] All About
• 虫歯の様子の写真を見せてもらう
  • 恐怖写真だった
  • 今はなんともないけど、痛くなったら神経を抜くことになります
• 麻酔が切れると痛くなる可能性があるので痛み止めを出しておきます
• 1週間後に噛み合わせを見せに来てください
• 2160円
  • PayPayで支払った

半年前くらいに家の裏の歯医者に行ったときは、これは神経抜かねばなりません、という話になったので行くのをやめてしまった。同僚が神経抜いている様子を見ると大変そうで、定期的に詰め物を外して殺菌して〜みたいな話を聞くとめまいがする。ほかにも、心の準備ができていないのにいきなり根管治療されて困った、みたいな話も聞いたりする。根管治療怖すぎる。

根管治療の回数・期間 東京都内歯医者 神谷町虎ノ門神経根っこの治療

しかし悪いものを見ないふりして放っておくのは、サーバー監視ツールとか作っている会社の人間としてはよくない姿勢だと思って、前から通ってた信頼のおける歯医者に行ってみることにした。そしたら神経は抜かずに済んだので良かった。やはり歯医者のスキルや方針には差があって、しっかりとした信頼関係ができていればついて行けるけど、そうでないと、信頼貯金を使い切って関係が途切れてしまうと思う。これで改心して今後は定期検診も行きたい…。

選挙カー 法螺貝 動画

たまに見たくなるので貼っておく
www.youtube.com

すでに1日8時間働いているということは新しいことはできない

仕事していて何か新しいことをしたくなったときに、何もせずゴロゴロしている時間でもあるなら別だけど、すでに1日8時間あくせく働いてしまっている人には、新しいことをする時間は残されていない。
今やってことをどれか選んでやらないようにするか、今やっていることのスピードを上げるか、今やってることの品質を下げるかしないと、新しいことをする時間は捻出できない。
ということを考えると、全社的に何か効果のあることをすることを期待されているのだとしたら、これまでどおりの動きに加えてプラスアルファではだめで、今やっていることはちょっと分量を下げて、余った時間で新しいことに取り組む、というのを意識的に行う必要がある。
ということに気づかないと、求められる貢献の種類が変わるたびに1日に働く時間がどんどん伸びていく、みたいな事象が発生してしまって、コードを書くのは昼休みか定時後、みたいなことになってしまう。
自分も昼休みにコード書きがちなので気をつけたい。

■

なんらかのテンション上がるものを食べたい…と選ぶと毎回これを選んでしまっている気がする。

品川駅、毎回この弁当買ってる気がする、そしてハーフボトルを買ったら短時間で一人では飲まないと思われたのかグラスを2つもらえた pic.twitter.com/AGWvAirosu

— 趣味はマリンスポーツです (@hitode909) 2020年2月18日

【現在は対応不要】Chrome80以降でALBの認証を使っているとcookieが4096バイトを超えて認証できないことがあり、社内サービスではcookie名を縮めて対応した

2020/2/18追記

サポートに問い合わせたところ、ALBの不具合はロールバック済みで、cookie名を縮める対応は不要、とのことでした。試してみたところ、たしかにcookie名の指定をやめても問題なく認証できました。

---

AWSのApplication Load Balancerの認証機能を使って、スタッフからのアクセスのみ許可する社内向けウェブサービスを運用しているのだけど、昨日くらいからGoogle Chromeで認証が通らなないという声を聞くようになった。
現象としてはリダイレクトループが発生していて、コンソールを見るとSet-Cookie headerが長すぎるというエラーが出ていた。

Set-Cookie header is ignored in response from url: https://****/oauth2/idpresponse?code=e51b4cf0-8b8e-495f-8db0-3bb0039dfed4&state=****. Cookie length should be less than or equal to 4096 characters

問題の起きたタイミングでデプロイしたわけでもないので、ブラウザの都合かAWSの都合かな、と思って調べたところ、フォーラムに同じ現象に遭遇している書き込みがあった。

When using ALB authentication, the default session cookie name (AWSELBAuthSessionCookie) and Chromium 80, the ALB attempts to set cookies which are too long (greater than 4096 characters). This causes the browser to reject the cookies and authentication to fail.

Use Case #4 from this post (https://forums.aws.amazon.com/ann.jspa?annID=7413) says:
"To ensure customers are backwards compatible after the Chromium update, ALB will parse the user-agent header to determine if a client is using a version of Chromium 80 or greater and set ‘SameSite=None’ attribute if they are."

The length of an ALB session cookie with the default name is usually at most 4092 characters. Using Chromium 80 it is 4106, with the 14 extra characters coming from "SameSite=None;". This seems like an ALB bug.

The workaround is to set a shorter session cookie name (9 characters or less).

https://forums.aws.amazon.com/thread.jspa?messageID=932968&tstart=0

• 2020年2月のALBのアップデートで、ALBがChromium 80以降のUser-AgentならSameSite=Noneを付与するようになった
• そのさいcookie headerの文字数が上限を超えてしまうことがある
• cookie nameを9文字以下に縮めるワークアラウンドがある
  • デフォルトのCookie名はAWSELBAuthSessionCookie

問題の起きていた社内サービスでは、cookie nameを9文字以下に縮めたところ無事ログインできるようになった。
CloudFormationのドキュメントはこのあたり。

• https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-properties-elasticloadbalancingv2-listener-authenticatecognitoconfig.html#cfn-elasticloadbalancingv2-listener-authenticatecognitoconfig-sessioncookiename

一方で、ほぼ同じ構成で動かしている別のサービスではcookieの長さが700バイトくらいで済んでいるものもあり、再現条件は分かっていない。

追記(2020/2/17)

どうやらcookieが分割されたらしいという情報もある。AWSのサポートに問い合わせてみています。何かわかったら追記しようと思います。

いま手元の環境で見てみたら、AWSELBAuthSessionCookie-0とAWSELBAuthSessionCookie-1の2個のcookieを喰わされたので、ALB側で分割して対応したのかも?

— fujiwara (@fujiwara) 2020年2月17日

追記(2020/2/18 11:14)

サポートに問い合わせたところ、ALBの不具合はロールバック済みで、cookie名を縮める対応は不要、とのことでした。試してみたところ、たしかにcookie名の指定をやめても問題なく認証できました。