Lycolog

フレッツ光ネクストを契約している場合で、OCNをISPとして利用している場合に、請求先クレジットカードを変更しようとすると以下の画面が出るケースがある。このときに請求先クレジットカード番号を変える方法。

やり方

1. Club NTT-Westにログイン
2. 契約確認・お手続きを開く
3. 「お支払い方法の変更」から「ご登録中のクレジットカード情報（クレジットカード会社やカード番号等）の変更お手続き」を開く
4. 頑張って変更情報を入力する
5. おわり

あとがき

OCNの請求カードを変えたいのにOCNのサイトからできないのは罠だと思う。

NTT西日本でフレッツ 光ネクストを契約しているが引っ越しの時に何故か登録住所が更新されなかったときに使える方法。

やり方

0120-116-116に電話をし、フレッツ 光ネクストの登録住所が現住所と異なるので変えて欲しいという。

備考

Club NTT-Westでは住所変更ができないので電話でやるのが早い。なんでないんだろうね？

チャットボットの選択肢にもない。

よくある質問の現在契約している回線の住所を変更したいによると有人チャットで対応してもらえるらしいので、こちらでもいいかもしれないが、画面が中々開かないので私は諦めてしまった。

なお登録住所を確認できる手段が恐らくないため、恐らく自分で気づくのは不可能。私はWebビリングに申し込んだときに面倒なエラーが発生し、電話対応が必要になり、その時に住所がおかしいと指摘されて知った。

定期的にデスク環境の写真を探すのだが中々見つからないのでSAOPのタペストリーが揃った記念に残しておく。

斜めと正面から見たデスク。

SAOPタペストリー3連拡大。

一番右のタペストリーが最近届いたやつで、去年の11月に注文して、今年の2月末に届いたやつだ。正直注文したこと自体忘れていたが、SAOゲームクリアデザインというだけあり、中々いい塩梅である。

左二枚のタペストリーも含めて全て10th Anniversaryのグッズなので、SAO好きな私にはたまらない光景だ。

また、ついでなので昔記事にした個人的なリモートワーク環境についてで紹介しているUSB KVMとHDMIも載せておく。ノートPCの上に載っているファンはノートPCを無理なく冷やすで書いた機構で、これがあるとないとではパフォーマンスに雲泥の差が出る。

10分程度で作れるお手軽レシピ

材料

上の写真では野菜にアイスプラント、葉玉ねぎ、ブラウンマッシュルームを使用している。

調理方法

1. 豚バラを一口サイズに切る
2. 野菜も一口サイズに切る
3. フライパンに適当に油をひく
   

   

4. 豚バラ肉をフライパンに敷く
   

   

5. ビーフンをフライパンに敷く
   

   

6. 更にその上に野菜を乗せる
7. 水を入れ中火にかけ、フライパンに蓋をして蒸し焼きにする。
   もやしなど水分量の多い野菜がある場合は水を減らしたほうが良い。水気が多すぎると麺が伸びる
8. 2分したらビーフンを裏返す
9. 1分したらフライパンの蓋を外し、ビーフンをほぐし、水で戻っていない場所をなくす
10. 水が残っていたら強火で飛ばす

最近思っているNext.jsを使った画面設計に関する考えを箇条書きで雑に殴り書きしていく。この記事は考えの垂れ流しなので深い説明はしない。AppRouterではなく、PageRouterの考え。

• TypeScriptで実装し、型が騙せるような実装は極力避け、コードによる戻り値の型指定は不具合の原因になることがあるため、可能な限り型推論に任せる
• SOLIDな設計を意識することで疎結合でテストしやすい設計になる
• Clean Archtectureを意識することでSOLIDのSを意識しやすくなる
  • 画面として考える場合、実装レイヤーとしてはAPIを呼ぶ以外何もしないAdapter、ビジネスロジックやイベントハンドリングの実処理などを行うController、画面要素を配置しただけのView、画面状態を保持するState、それらをつなぎ合わせるUsecaseが、Usecaseを置くだけのPage（Next.jsのpageコンポーネントに埋め込むコンポーネント）、SSGやSSRをする場合のServer Side Controllerがあるとよいと考えている。大まかには下図のような感じで考えていて、過去の実務でもこれに相当するものを作ったことがある。
    

    

  • ただこれはModelに相当するものがなく、ビジネスロジックの共通化に課題が出てくるのと、ControllerがFatになりすぎると考えており、そこが課題になると考えている。
• テストが容易なコードは必然的に疎結合になる
• 疎結合にする場合、命名を抽象的にしておくと処理の入れ替えが容易になる（命名が具象、つまり実装の詳細に依存しないため）
• 疎結合にするとパーツが増えるので認知負荷が上がる
• 疎結合でかつ、命名が抽象化されている場合、仕様を知らない人にとっては実際の処理内容を推測しづらくなる
  • つまりこれは属人性が増えると考える
• 例外についてはErrorクラスを継承し、カスタム例外を作成して、用途に応じたハンドリングができるようにする
  • 原則として処理を止める場合にのみ用いるべきで、続行する場合には使わない
  • 例外は原則としてスローして、カスタムエラーは特定の階層でフィルタしてハンドリング、全てすり抜けてきたものはルート処理でキャッチしてハンドリングすることで、取りこぼしをゼロにする。例外の握り潰しは原則行わない
    • 基本的にすべてロギングする
  • 処理を継続するものについては例外とせず、ワーニング用の処理フローを作成し、それに則って行う（例えば入力バリデーションはワーニング）