エンジニア文化祭2023 現地参加レポート
はじめに
Google Pixel Magic Eraserで人を消したら不自然になりました
2023年3月3日 エンジニア文化祭 2023 presented by Forkwell に現地参加しました。オフラインの技術イベントに参加するのは数年ぶりでした。講演内容の詳細は講演者の皆様のスライドに譲りつつ、簡単に個人的な感想やレポートを書きます。
2023年もSRE再考と叫びなさい
株式会社スリーシェイク nwiizo 氏
SREの定義から説明していただけました。"SRE = インフラ" ではなく "SREはDevOpsというInterfaceの実装である" とのことでした。
まずは計測/モニタリングから始めることが大切、という内容に共感しました。計測で現状を知ることによりモチベーションも危機感も抱けて、そこから信頼性向上への動きへ繋がる、というのは私自身も経験したためです。
信頼性が一定水準に達したら、変更速度のために信頼性を落とすことすら可能になる、というのは面白い視点だなと思いました。私の携わっている開発ではまだその域に達していませんが、頭に留めておこうと思います。
フロントエンドの潮流から見る需要と進化 これまでとこれからのフロントエンドの話
potato4d氏 ＆ 古川陽介氏
資料なし
お二人の対談形式でした。私は現状バックエンド中心の開発者のため、フロントエンド技術には詳しくないのですが、一般的に目まぐるしい技術変遷とどう向き合うか、という視点でお話を伺えて興味深かったです。
ReduxやHooksの歴史から見られるように、技術的に善とされるものは螺旋階段や振り子のように行ったり来たりを繰り返すのでは、というご意見に同意するとともに、諸行無常を感じました。
"近年のスマホの普及と進化により、キーボード等でなくジェスチャーで実現しなければいけない機能が増えて、フロントエンドに求められる役割が増えて複雑化している" というご見解に納得しました。
ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること
徳丸浩氏
徳丸さんがChatGPTをある意味公開デバッグしていて面白かったです。現状ChatGPTはあくまで何らかのソース(信頼できるものも信頼できないものも含む)の切り貼りによる回答である、というのは頭に置いて置く必要があるなと改めて思いました。
またCapital Oneの事例から "セキュリティ事故を防ぐために、優秀なツールに頼って安心しきることは危険である" というメッセージは身につまされました。とはいえ全開発者がセキュリティのエキスパートになることは現実的には難しいので、どのようにセキュリティと付き合っていくのが良いのだろう、と考えさせられます。組織内に少なくとも数人セキュリティのエキスパートが必要で、かつ彼らとの連携を密に行うべき、という無難な結論に至ってしまいそうです。
DevSecOpsに関してはメルカリがとても良い事例、と徳丸さんがおすすめされていました。
MLエンジニアとデータサイエンティストのこれまでとこれから
TJO氏 × ばんくし氏
資料なし
ばんくしさんとTJOさんの対談形式で、マサカリとの付き合い方、仕事や職場の選び方、AIやAI業界の今後、などについてお二人のご意見を聞くことができました。
発言内容は共有禁止なので感想のみになりますが、お二人のご意見や着眼点が非常に興味深く、かつ職種は違えども技術者として随所で深く共感できる内容でした。このセッションのために現地に行ってよかったです。
また他セッションは基本的にリモートの講演を中継で観る形式だったのですが、このセッションは実際にお二人が現地にいらっしゃり、臨場感やその場の笑いがあってよかったです。
サバンナ便り 自動テストに関する連載で得られた知見のまとめ
t_wada氏
端的に表現すると "テストの偽陽性 (失敗が日常になっている) & 偽陰性 (失敗するべきなのに成功する) が多いと、テストの信頼性が下がって誰もテスト結果を信じなくなるので、適切にTest Sizeを区切りTest Doubleを使っていきましょう" という内容でした。
偽陽性: 成功するべきなのに失敗するテスト。変更に極端に弱いテスト
偽陰性: 失敗するべきなのに成功するテスト。実際にロジックが実行されていないなど
こちらのスライドの通りTest Scopeは大きく分けて3つで、Scopeが大きい方から以下です。
- E2E Test
- Integration Test
- Unit Test
テストケース数の構成比は、ピラミッド型 (Unitが多くE2Eが少ない) であるべきで、アイスクリーム型 (E2Eが多くUnitが少ない) にならないように気をつけるべき、という指針を示していただけました。良い設計をすることで、Test Double (Mock, Stub, Spyなど) を使わなくてもMediumからSmallにサイズダウンできることがある、というご意見も参考になりました。
またTest Sizeを下げることに成功しても、Unit Testにおいてプロダクトコードとテストコードを同じロジックで書いているために、間違っていても結果的に出力が一致してOKになってしまうケースが本当に多い！と強調して注意喚起をされていました。
私の携わっている開発では、まだテストの網羅性自体が低くこれらの改善を行う境地に至っていないな、と身につまされました。Test Sizeを大きくしないよう意識しつつ、かつ検証すべき機能は適切にTest Doubleを活用してテスト網羅性を高めていこうと思いました。
t_wadaさんが講演中に紹介されていた本
Googleのソフトウェアエンジニアリング
この本でTest Sizeの定義がされています。Googleによると、テストの信頼不能性が1%を超えると、人はテストの失敗を信じなくなってくるそうです。
XUnit Test Patterns
以前はTest DoubleパターンのMock, Stub, Spyの定義がぶれぶれでしたが、この本で定義が統一されたそうです。
単体テストの考え方/使い方
t_wadaさんイチオシの本とのことです。
分岐を低減するinterface設計と発想の転換
ミノ駆動氏
エンジニアとして働き始めた頃は意識していたデザインパターンですが、最近忘れかけていたので改めて学び直すとリファクタリングの余地を発見できそうだと思いました。"仕様変更のたびに(モードやバリエーションを切り替えるために)変更しているコード箇所があったら、Interfaceを使えるか疑うと良い" という分かりやすい指針が参考になりました。
Interfaceの機能がないRuby on Railsなどではどうするべきですか？という聴講者からの質問もありました。ミノ駆動さんは "RubyではInterfaceは心の中にしかないが、ModuleをInterfaceの代わりに使っている" とのことです。
私は class NotImplementedError (Ruby 3.2 リファレンスマニュアル) を使って実装したりしていますが、厳密にInterfaceとイコールではないので何とも言えないです。
また "抽象クラスは難易度が高いのでそもそも使わないようにしている、Super ClassとSub Classが密結合になりがちなので" というご意見は興味深かったです。
会場の様子
軽食として、ちょっとした小ギャグと共にスパムおにぎり、カツサンド、コーヒーや紅茶などが用意されていました。運営の皆様ありがとうございました。
参加する時間はなかったのですが、射的やバグ封じの祠もあり、さながら文化祭でした。
Discussion