お知らせ
現在サイトのリニューアル作業中のため、表示が崩れているページが存在することがあります。
2025/03/03 16:30
NTT西日本でフレッツ 光ネクストを契約しているが引っ越しの時に何故か登録住所が更新されなかったときに使える方法。
やり方
0120-116-116に電話をし、フレッツ 光ネクストの登録住所が現住所と異なるので変えて欲しいという。
備考
Club NTT-Westでは住所変更ができないので電話でやるのが早い。なんでないんだろうね？
チャットボットの選択肢にもない。
よくある質問の現在契約している回線の住所を変更したいによると有人チャットで対応してもらえるらしいので、こちらでもいいかもしれないが、画面が中々開かないので私は諦めてしまった。
なお登録住所を確認できる手段が恐らくないため、恐らく自分で気づくのは不可能。私はWebビリングに申し込んだときに面倒なエラーが発生し、電話対応が必要になり、その時に住所がおかしいと指摘されて知った。
2025/03/01 22:10
定期的にデスク環境の写真を探すのだが中々見つからないのでSAOPのタペストリーが揃った記念に残しておく。
斜めと正面から見たデスク。
SAOPタペストリー3連拡大。
一番右のタペストリーが最近届いたやつで、去年の11月に注文して、今年の2月末に届いたやつだ。正直注文したこと自体忘れていたが、SAOゲームクリアデザインというだけあり、中々いい塩梅である。
左二枚のタペストリーも含めて全て10th Anniversaryのグッズなので、SAO好きな私にはたまらない光景だ。
また、ついでなので昔記事にした個人的なリモートワーク環境についてで紹介しているUSB KVMとHDMIも載せておく。ノートPCの上に載っているファンはノートPCを無理なく冷やすで書いた機構で、これがあるとないとではパフォーマンスに雲泥の差が出る。
2025/03/01 09:00
10分程度で作れるお手軽レシピ
材料
上の写真では野菜にアイスプラント、葉玉ねぎ、ブラウンマッシュルームを使用している。
| 材料 | 分量 |
|---|---|
| 野菜 | 好きなだけ |
| 豚バラ肉 | 2枚 |
| ケンミンの焼きビーフン | 1食 |
| サラダ油 | 適量 |
| 水 | 160mlくらい |
調理方法
- 豚バラを一口サイズに切る
- 野菜も一口サイズに切る
- フライパンに適当に油をひく
- 豚バラ肉をフライパンに敷く
- ビーフンをフライパンに敷く
- 更にその上に野菜を乗せる
- 水を入れ中火にかけ、フライパンに蓋をして蒸し焼きにする。
もやしなど水分量の多い野菜がある場合は水を減らしたほうが良い。水気が多すぎると麺が伸びる - 2分したらビーフンを裏返す
- 1分したらフライパンの蓋を外し、ビーフンをほぐし、水で戻っていない場所をなくす
- 水が残っていたら強火で飛ばす
2025/02/27 13:13
最近思っている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になりすぎると考えており、そこが課題になると考えている。
- 画面として考える場合、実装レイヤーとしてはAPIを呼ぶ以外何もしないAdapter、ビジネスロジックやイベントハンドリングの実処理などを行うController、画面要素を配置しただけのView、画面状態を保持するState、それらをつなぎ合わせるUsecaseが、Usecaseを置くだけのPage（Next.jsのpageコンポーネントに埋め込むコンポーネント）、SSGやSSRをする場合のServer Side Controllerがあるとよいと考えている。大まかには下図のような感じで考えていて、過去の実務でもこれに相当するものを作ったことがある。
- テストが容易なコードは必然的に疎結合になる
- 疎結合にする場合、命名を抽象的にしておくと処理の入れ替えが容易になる（命名が具象、つまり実装の詳細に依存しないため）
- 疎結合にするとパーツが増えるので認知負荷が上がる
- 疎結合でかつ、命名が抽象化されている場合、仕様を知らない人にとっては実際の処理内容を推測しづらくなる
- つまりこれは属人性が増えると考える
- 例外についてはErrorクラスを継承し、カスタム例外を作成して、用途に応じたハンドリングができるようにする
- 原則として処理を止める場合にのみ用いるべきで、続行する場合には使わない
- 例外は原則としてスローして、カスタムエラーは特定の階層でフィルタしてハンドリング、全てすり抜けてきたものはルート処理でキャッチしてハンドリングすることで、取りこぼしをゼロにする。例外の握り潰しは原則行わない
- 基本的にすべてロギングする
- 処理を継続するものについては例外とせず、ワーニング用の処理フローを作成し、それに則って行う（例えば入力バリデーションはワーニング）
2025/02/27 00:20
スマホでWebを見てるときにキーボードがUIにかぶって操作しづらくなることがあるので、いくつかのサイトでどうなっているか調べてみた。
去年の9月にAndroid Edgeで調べた内容なので、今とは事情が異なるケースもある。Android Chromeでは起きなかったケースもあったので、Edge特有の挙動と思われる。
ログイン画面
キーボードが入力欄やログインボタンにかぶる。
ミュート設定
入力欄が上にあるためかぶらない。
投稿画面
入力欄が上にあるためかぶらない。
YouTube
コメント画面
キーボードがボタンにかぶる。
通報モーダル
キーボードがボタンにかぶる。
GitHub
Issueのコメント画面
入力欄が丸ごとキーボードにかぶる。
一休
検索モーダル
宿泊予算の入力が丸っとかぶる。
じゃらん
検索画面
キーボードと被らないようにするためか入力UIをモーダルにして画面トップに出すように工夫されている。これなら大抵の端末やブラウザで対応できそうなので、よくできていると思う。
Amazon.co.jp
レビュー画面
入力状態になると若干のラグの後に画面下に余白ができ、入力状態が外れると同様のラグの後、画面下の余白が消えるという挙動をする。
割と凝ったJSで何かしらの計算を行い、かなり頑張って調整しているようだった。タイムラグがあるのはイベント発火もあるだろうが、キーボードの検出や画面サイズに応じた余白計算に時間がかかっているのもあるのだろう。
ここまで凝った実装をしているのは他のサイトでは見られず、Amazon.co.jp特有に見えた。なお、Amazon.comのほうは見ていない。
あとがき
この調査時点では、じゃらんとAmazon.co.jpを除き入力欄を画面の上部に配置するなどレイアウトで調整しているサイトが比較的多く、どうしてもボタンなどが隠れる傾向があるように思った。
じゃらんは強制的に画面上部に入力欄を出すようにし、Amazon.co.jpは気合でキーボードが隠れないように調整していて、腐心の跡が見られた。
なお、今回動画を作成するにあたり一部をぼかす必要があったため、やり方を調べ実践したのでAviUtlで動画の一部にモザイクをかけ、動かす方法という記事を作成し、その過程を残している。
本動画の作成過程では上手くモザイクをかけられなかったが、上記の記事を作っているときに上手く行くようになったので、本記事の動画はモザイクではなく、ぼかしとなっている。