エンジニア文化祭

先日開催されたエンジニア文化祭に参加しました。

と言っても当日は普通に平日だったのでアーカイブでの視聴となりました。

まだ全部見たわけではないのですが、大変勉強になる講演がたくさんあったので箇条書きですがざっくり書いてみます。

視聴した講演とそのまとめ

フロントエンドの潮流から見る需要と進化　〜これまでとこれからのフロントエンドの話〜

  • モダンフロントエンドの課題と背景について
  • 「今」のフロントエンドを作る技術とその需要
    • Node.jsを中心にツールが発達 (Webpack, Babel etc...)
    • スマホの普及とともにUI・フロントエンドの重要性・複雑性が高まってきた
    • 2015~2016年頃が過渡期、「フロントエンドの進化速すぎ、疲弊」
    • 宣言的なUIがReactのキャッチーなところ
    • 『「表示」と「更新」を同じ書き味で書きたい』という思想からできたのがReact
    • Reactコミュニティだといろんな機能全部盛りみたいなToo muchなライブラリが多いがそれはなぜ？
    • 各コンポーネントが状態を持つとアプリケーション全体からは各コンポーネントの状態が見れない
    • それを集約したのがFlux, Redux
    • グローバル変数であっても使うところと更新するところを集約すればいいんじゃないの的発想
    • Hooks以降のReactだと各コンポーネントごとに状態を持たせる方に流れていってる
    • 全部Reduxに集約するのではなく、例えばAPIのキャッシュはそのレイヤーで管理する方が合理的、Too muchなものからの揺り戻し
    • SPAがモダン⇒でも初期表示遅い⇒SSR⇒じゃあ最初から生成すればOK⇒SSG
  • いつまで「今」は続くのか
    • モダンフロントエンドとは
    • 数年スパンでは大きな変化はない、10~20年単位だとwebアプリケーションの作り方自体が変わってくる
    • 作り方が画一的、whatが一緒でhowが違うだけ
    • 技術的なオプションよりも事業価値に目を向ける時期？
    • コモディティ化された技術へのキャッチアップが差別化に繋がった時期から事業価値へシフトする時期に来ているのでは
    • 専門家的立場の人たちは数年後にそうなるかもしれないが、まだ完全にコモディティ化していないのが現状
    • 組織の状態やフェーズによっても異なる
  • 「フロントエンド」の概念が劇的に変わる時
    • 大きな変化からの揺り戻しの繰り返し
    • 作り方がよりシンプルになった時
    • copilot, chatGPT等の技術的革新
    • 現状のフロントエンドの考え方は今後も必要

ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること

  • chatGPTの書くコードはセキュアなの？
    • SPAで改行を
      タグに変換するコードをVueで
    • XSSは大丈夫？⇒大丈夫じゃない
      • Reactだと大丈夫なコードが生成された
    • 常に高品質なコードが生成されるわけではない
    • 脆弱性があるコードが生成される場合もある
  • 検索やAIによる情報収集の問題
    • SSRFについてBing Chat AIに聞いてみる
    • そのソースを見てみると徳丸さんや他の方が書いた記事から転載・改変したもので内容は不正確
      • 既存記事を組み合わせたキメラのような記事
    • もはやググって上位の記事を参照する方法では質の高い記事を見つけることはできない
    • 今後はSEO目的の記事をAIを使って量産⇒さらに加速
    • 検索やAIを使う場合でもセキュリティの基礎的な知識が無いと見分けられない
  • CapitalOne事件に学ぶDevSecOpsの落とし穴
    • DevSecOpsとは
      • ソフトウェア開発ライフサイクルの全てのフェーズでセキュリティを自動化し、統合する手法のこと
    • SSRF攻撃の被害事例についてBing Chat AIに聞いてみる
    • WAFの設定ミスによる個人情報漏洩事件
    • Apacheでリバースプロキシを設定する例
    • ProxyRequests On はNG
    • IMDS: Instant MetaData Service EC2の仮想エンドポイントで設定情報がJSONで返ってくる
    • 推測される本事件の原因
      • WAFがオープンプロキシになっていた
      • WAFに多数の不要なクレデンシャルが付与されていた
      • S3に1億件超の個人情報を保管
      • IMDSが無効化されていなかった
    • CapitalOneはDevSecOpsの先駆的企業だったがWAFに対する脆弱性対策ができていなかった
      • AWS設定監査基準CIS ControlsにはIMDSに関する監査項目は無い
      • AWS基礎セキュリティのベストプラクティスにはIMDSの項目がある⇒CapitalOne事件後に追加？ (IMDSv2)
      • ツールに頼りすぎてセキュリティの生の状態を人がチェックしていなかったのでは？
    • SDLC
    • シフトレフト
      • 開発プロセスのできる限り早期の段階にセキュリティ施策を実施すること
    • 上流工程で「実際に何をするのか」はあまり語られていない
    • AIやツールを導入するだけではダメ、セキュリティの知識を身につけ、実践することが必要

サバンナ便り〜自動テストに関する連載で得られた知見のまとめ〜

  • 学習用テスト
    • 学びを自動テストとして書く
    • 即時性と再現性
    • 動かして初めて分かることは多い
    • 自分が作ったものじゃないものに対するテストを書いてみる（ライブラリ等）
    • 疑問をテストにする
    • 驚きをテストにする
      • コンストラクタをもう一度呼べてしまう（！）⇒破壊的変更ができてしまう
  • 偽陽性と偽陰性
    • 自動テストの信頼性をむしばむ現象を理解する
    • テスト自動化と企業の業績には因果関係がある
      • 信頼性の高い自動テストを備えること
      • 開発者主体で受け入れテストを作成・管理し、手元の開発環境で簡単に再現・修正できること
    • 信頼性とは
      • テストに合格⇒リリース可能、テストに不合格⇒重大な不具合がある
      • 誤検知（＝偽陽性）や見逃し（＝偽陰性）が多い
      • 偽陽性
        • 信頼不能テスト
        • 変更に極端に弱い、脆いテスト
      • 偽陰性
        • 空振り
        • カバレッジ不足
        • テスト対象ロジックのテストコードへの漏れ出し
          • 同じロジックでテストを書くとプロダクトコードにバグがあってもテストが通ってしまう
      • 信頼不能性が1%に接近するとテストは価値を失い始める
  • テストサイズ
    • 自動テストとCIにフィットする明確なテスト分類基準
    • ユニットテストのユニットとは？
      • 明確な基準がない
        • 依存するクラスに本物のクラスを使う派
        • 依存するクラスにはモックを使う派
    • Googleのソフトウェアエンジニアリングにおけるテストサイズ
      • 1つのプロセスに閉じている⇒Small
      • 1つのマシンに閉じている⇒Medium
        • MediumテストはCIに乗せられる
        • ネットワークアクセスはlocalhostのみ
      • それ以外はLarge
    • テストサイズとテストスコープのマトリクス
      • Small / Medium / Large × Unit / Integration / E2E
      • コスパが良い / 悪いのライン
  • テストダブル
    • 忠実性と決定性のトレードオフを理解する
    • モックやスタブ等、自動テスト用の偽物の総称
    • 利点
      • テストしにくいものをテスト可能に
      • テストの速度と決定性（毎回同じように動くこと）を向上
    • 注意点
      • テストが脆くなる
      • 偽陰性を招く
        • モックを自分で考えて作ると実際のクラスと違う動きを書いてしまうことも
        • 本物のクラスの変更が反映されてない場合も同様
  • テストピラミッド
    • 自動テストの信頼性を中長期的に保つ最適なバランス
    • 上からE2E / Integration / Unitの順
      • 低層になるほど
        • コストや忠実性は低い
        • 速度や決定性は高い
        • テストケース数は多い
      • 高層になるほど
        • コストや忠実性は高い
        • 速度や決定性は低い
        • テストケース数は少ない
    • 比率が逆になるとアイスクリームコーンアンチパターン
    • 人によってテスト範囲の基準の解釈が異なるので混乱しがち
    • テストサイズをピラミッド型に配置
      • LargeやMediumだとコスパが悪いテストをテストダブルでサイズダウン
      • 良い設計をすればSmallで書けるテストが増える

分岐を低減するinterface設計と発想の転換

  • 設計なんもわからん
  • interfaceを使うと分岐が劇的に低減してコードがシンプルになる⇒上手く使えてる？
  • 架空のホームセキュリティシステムの事例
    • いろんな仕組みに対応して欲しいという要望
    • 個別に対応するのは無理
    • 要望ごとに分岐が増えて複雑化
  • interfaceを上手く使うには大幅な発想の転換が必要
  • interface設計の要点
    • 目的単位で抽象化
      • システムには必ず目的がある
      • 問題領域に対し、それを解決する様々な解決領域が世の中にはある
      • 目的の具体化（ツリー構造化）
        • 目的が決まると課題が浮き彫りに
        • 課題に対処するための解決手段も決まる
        • 目的が違うと課題も解決手段も違ってくる
        • 目的/課題と解決手段はツリー構造
      • 目的達成手段を抽象化
        • 同一目的に対する達成のバリエーション
    • 「作る」と「使う」を分ける
      • 良くないロジックは「何を使うか」を判断する分岐と実行するロジックが混在している
      • 「作る」と「使う」を分離
        • 作って完成されたものを使う
      • 「作る」
        • factoryやDIコンテナに任せる
        • 組み立ては作る側にカプセル化
      • 「使う」
      • プラグインアーキテクチャ
  • 目的のバリエーションと機能性
    • 同一目的に対して手段にバリエーションがある
    • 達成手段それぞれで性能が異なる
    • 状況に応じて最適な手段は異なる
    • interface設計可能な箇所は同一目的でもより顧客にリーチする機能に置き換えられる可能性を秘めている
    • ただしinterfaceは銀の弾丸ではない
    • 手段のバリエーションという観点での設計を推奨

まとめ

以上、ざっくりしたまとめでした。

単純に技術力をつけることだけじゃなく、その背景だったり思想を学ぶことも必要だなと改めて感じた機会でした。

また講演の中で紹介されていた書籍も気になるものがたくさんあったので読んでみたいと思います。