MasaKu's BLOG

PHP成分多めでWeb関連技術の記事を書きます

PHPerKaigi 2021 二日目 参加メモ

はじめに

PHPerKaigi 2021 に参加しました。

1日目はあいにく別件の用事があり参加できませんでしたが、タイムシフトで後日参加いたします。

2日目の参加メモを公開します。

※個人的なメモですので、支離滅裂かと思いますがご了承くださいませ

聴講セッション

  • 無駄な物をなるべく作らないリプレイス戦略
    • 11:50 Track B
  • 今こそ理解するDI(Dependency Injection)
    • 14:10 Track A
  • DNSを制する者はインターネットを制す!DNS世界
    • 14:50 Track B

無駄な物をなるべく作らないリプレイス戦略

  • ママリ
    • 記事の管理
    • 記事のCMS
  • 技術スタック
  • リファクタリング
    • コードの最適化
  • リライト
    • 設計から1から作りなおす
  • リプレイス
    • 置き換えること
  • 完全な書き直し(リライト)は最終手段
    • 大きなリスクがあるため
      • リライトして何年も立つがまだ終われない
      • リライトしたあとの方が性能が悪い
      • 想像していなかった仕様や機能の漏れがあった
    • 記事サービスの場合、複数の機能があるため、リライトは現実的ではない
  • そのためリファクタリングの方針とした
    • リライトまでの経緯
      • コーディング規約
      • Linter
      • 静的解析ツール
      • テストの充実バレッジの計算
      • 開発環境のコンテナ化
      • 不要なコードの削除
        • 一番の問題は解決されない
    • アーキテクチャとしての課題を明らかにする
      • イケてないことを放置しない
        • コードを修正する
        • 直せなくても同じミスをしなければ良い
            • オブジェクトではなく配列がた多用される
            • 責務の大きすぎるクラス
            • Viewに漏れ出すロジック
      • モダンなプラクティスを使えば課題の多くを解決できる
  • リライトにすることになりました
    • 無駄なものをなるべく作らないりプレイス戦略とは
      • 必要なものから少しずつ作っていく
        • ログインログアウトだけできても意味はなく、それに付随する必須機能を組み合わせて進めていく
  • 必要なものを作る戦略
    • 知るところから始める
    • とにかく対話する
      • 実際に使っているユーザと対話する
      • 現状のサービスの使われ方を明らかにしていく
        • プロダクトとして何らかの課題を解決できる最小単位
      • ユーザインタビューを行う
        • インタビュー中の発言やメモなど
    • 共通理解を持つ
      • 実際に作ってみたら思っていたものと違ったを防ぐ
      • 狩りで決めたスコープに抜け漏れがないか、関係者で認識にずれはないかを検証する
        • ユーザストーリーを前提として設計する
          • ユーザの操作のストーリーを書き出す
            • 作成して、プレビューして・・・・。
    • まずはリファクタリング、リライトは最終手段
      • 無駄なものは作らないはキホン

今こそ理解するDI(Dependency Injection)

  • DIとは方法論
    • 保守性の高いコードを書くことを目的としたソフトウェエア設計原則とパターンのセット
    • 粗結合の実現を目的としたデザインパターン
  • 制御の逆転
    • 呼び出す側と呼び出される側が逆転する
    • 必要になったら呼ぶ
      • フレームワークを利用したアプリケーション開発に当てはまる
        • アプリケーション側から呼ぶことはほぼない
        • 呼ばれるタイミングはフレームワーク側で実施している
    • ユニットテスト
      • setUP
      • tearDown
    • IoCとDIの関係
      • IoCは制御の逆転
        • Inversion of Controll
      • DIは依存関係に対する制御の逆転と表現
    • メールを送信するメソッドを例にする
      • init で設定を行っている
        • しかし、この中でAWSのメール送信オブジェクトを利用している場合、AWSに依存していることになる
        • つまり、オブジェクトを関数内で作ってしまうとそのオブジェクトに依存している状態になってしまう
    • テストを支援するのが目的ではなく、
      • オブジェクトがそ結合になることでテストしやすくなっているだけ
    • DIコンテナラは必須ではない
      • フレームワークはDIコンテナを利用している前提になっているだけで、必須ではない
      • 依存関係をコンテナに定義しておくだけで、コンテナ側オブジェクトの依存関係を解決してくれる
      • サービスロケーターではない
    • サービスロケーターについて

DNSを制する者はインターネットを制す!DNS世界

  • ドメイン名ハイジャックは恐ろしい
    • 悪意あるユーザが名前解決先のIPを書き換える
      • レジストラ経由で変更されてしまうため気づきにくい
      • MXが変更されるとメールが乗っ取られる
      • クラウドサービスのパスワードリセット
    • 悪意あるWebサーバへ誘導される
      • HTTPSもOKになってしまう
        • 徐々にやられていくと気づきにくい
          • 10人に1人だけなど
  • 過去あった自称
  • レジストラの問題が起点となるため、防ぎようがない
    • なるべく早く気づいて対策を実施する
  • NSchecker
    • TLD権威サーバに登録されているNS情報をチェック
    • 改ざんを検知するとコマンドが異常終了
    • コマンドの結果からメール通知やほかの連携も可能
      • Slack通知機能
  • DNSプロトコル
    • 30年以上の歴史がある
    • UDP上の512バイトいないのデータ
      • TCPフォールバック有り
    • 1ビット単位でフォーマットが決まっている
      • dig コマンドでDNSのデータが出せる
      • DNSのレスポンス
        • 名前はラベルで区切られている
        • vaddy.net -, 5vaddyy3net\0
      • 同じ文字データは圧縮される
        • オフセットでデータ量を無駄にしない
      • 子供が 20 時を過ぎててもYouTubeを見ている
        • YouTubeだけを止めたい
          • DNSCOP
            • DNSパッケットをフルリゾルバに転送
              • 転送時にメインをチェックしてコントロール
          • 子供がPCでアクセスするドメインが全て丸見えに(プライバシー上の問題)
      • 私たちのDNSクエリ
        • フルリゾルバにはこう見える
          • あるIPの利用者はXX時に example.cam をよく見てる
        • 暗号化されていない
          • 自分がどういうDNS結果が見られている
      • DNS結果の汚染防御
      • 経路の暗号化
    • フルリゾルバ(キャッシュサーバ)には誰が何のIPを知りたいかは防げない
      • ODoH
        • DNSメッセージを暗号化してDNSプロキシに送信
          • そのまま、DNSプロキシがフルリゾルバに転送