SRE NEXT 2024で爆誕したかえるとぺんぎんの妖精「信頼けろぺん」

SRE NEXT 2024でけろぺんをリードしたコアスタッフによる、技術カンファレンスにおいてマスコットキャラクターを作ること、をトピックとしたメタいセッションです。
マスコットキャラクターを作る中で得た気づき、ノウハウを共有します

話すこと

• けろぺんが生まれ、デザインに落とし込むまでの経緯
• 生成AIを活用デザイン草案のプロンプト
• マスコットキャラクターをデザインする上で重要な勘所、要点
• 技術カンファレンスでマスコットキャラクターを運用するためのポリシー

3Dセキュアはオンラインカード決済時の本人認証サービスで、なりすまし等の不正利用防止に貢献する20年近い歴史を持つ技術です。

当初はパスワードによる知識認証が主流でしたが、2.0以降はOTPを用いた所有物認証や指紋等による生体認証が可能になりました。さらに2.3.1ではW3Cが策定するSecure Payment Confirmationベースの認証が導入され、WebAuthnを使って迅速かつシームレスに認証を行えるようになりました。このようなパスワードに依存しない認証方式の潮流が決済領域でも見られるのは興味深いことですね。

本セッションでは開発・運用を通じて学んだ3Dセキュアの裏側を覗き、縁遠いと思われるオンラインカード決済のセキュリティはWebの認証技術の発展とともに切り拓かれてきたことを解説します。安全で使いやすい決済の歴史と現在地、そして未来について一緒に考えてみませんか。

eBPFについて紹介するトークです。
ただ紹介するのではつまらないので、eBPFのLoaderをPerlで自作し、KernelにAttachします。
この発表を通じて現代のLinuxにおけるeBPFの使われ方と、eBPFバイナリの面白さを伝えます。

• eBPFとは
  • 概要
  • 使われ方 (オブザーバビリティ、パケット処理、ミドルウェアのインジェクションコードなど)
• 自作eBPF LoaderをPerlで実装
  • PerlのコードからeBPFを実行
  • eBPFのELFバイナリをパースし、システムコールを叩いてKernelにロード
  • 可能であればeBPF Mapの読み書き機能も実装予定（実装が終わるのか...？）
• 実装したeBPF Loaderを使って実演

対象者

eBPFのバイナリの構造を理解したい方
PerlでeBPFを実行してみたい方

ソフトウェア開発におけるテストの重要性は言うまでもありません。一方で、テストフレームワークやテストツールにおいてテストを書く以外の側面を掘り下げることはあまり多くありません。
本発表では私が所属するLaunchableでの様々なテストフレームワーク/ツールをサポートしていく中での経験から、テストフレームワーク/ツールの現状と課題および今後の未来に向けた進化の方向性について議論します。

話すこと

• サポートしてきたテストフレームワーク/ツールの簡単な紹介
• テストフレームワーク/ツールの現状と課題
  • レポトーフォマットの多様性
  • テストツールごとのテストの実行単位
• 未来の話
  • 拡張性の重要性
  • データの活用
  • リアルタイム通知
• etc

深く話さないこと

• テストの書き方
• 各テストフレームワーク/ツールの詳細な使い方

オンボーディングプロセスがいかに新メンバーの未来を切り開くかを、オンボーディングする側とされた側の2人の視点から紹介します。
入社時やることリスト、専用Slackチャンネル、メンタリング制度、アジャイルなプロセス改善、Good First Issueの5つの重要ポイントを通じて、新メンバーの早期活躍を支援する取り組みを解説します。
特に注目すべきは、‘Good First Issue’という初期タスクの概念です。これにより、新メンバーは早期に成功体験を得て、自信を持って未来を切り開く準備が整います。
また、継続的なフィードバックとドキュメント更新により、オンボーディングプロセス自体も進化します。
本セッションでは、オンボーディングする側の実践と、新メンバーとしてオンボーディングされた側の実体験を対談形式で具体的に示し、参加者が自社での実践に活かせるヒントを提供します。

2024年。令和も6年になりました。みなさんPerlでプログラミングしてますか? 私はPerlで色々書いてます。
様々なプログラミング言語には様々なコーディングガイドがあります。それはだいたい最新機能やカッコいい書き方が紹介されています。
しかし、Perlでインターネットを検索すると未だに「use strictしましょう」がナウでヤングな情報として扱われてはいませんか?

本トークでは令和最新版のPerlコーディングガイドを実際にプロダクトで動作しているバージョン5.40のPerlを題材にご紹介します。
これを聞けばナウでヤングなPerlの書き方がわかるでしょう。

内容

• ローカル開発環境
• builtin, use feature
• 型システム
• cpanfile
• 様々な最近の機能
  • レキシカルサブルーチン
  • try/catch
• CPANモジュール

皆さんは Perl を書いていますか？ 私は、ほぼ毎日書いています。
それでは、自転車には乗っていますか？ 私は、ほぼ毎日 30Km 以上の距離を乗っています。

自転車に乗ると、自分が過去に行ったところをまとめたくなりますよね。このトークでは、はこだて未来大学まで自分の自転車で来る方法・・・ではなく、ワークアウトはもちろん、通勤や旅行を含む過去のありとあらゆる位置情報の履歴を集めて、 Perl で可視化するためのノウハウを紹介します。以下のトピックをカバーする予定です。

• Apple watch / Fitness app / Strava etc...
• GPX format
• Google Timeline
• OpenStreetMap / Slippy Map
• Web Mercator projection
• Geohash

アプリケーションの設計・開発において、「セキュリティ」は必須であり、AWSの「Well-Architected Framework」においてもセキュリティは最重要項目として挙げられています。
ただ、AWSには「Secrity Hub」など本格的なセキュリティ関連のサービスがあるのは知っていても、なかなかアプリベースでサクッと出来る対策が分からない...という方もいらっしゃると思います。

そこでこのセッションでは、「アプリベースで出来るセキュリティ対策の第一歩」として、ECS FargateやAWS CDKなどで実施できるコンテナセキュリティ対策の基本を紹介したいと思います。
なおこのセッションでは「第一歩」ということもあり、「（ほぼ）無料で」「手軽に」導入できる手法を中心に紹介します。

皆さんにとって、セキュリティ対策の第一歩を踏み出すきっかけになればと思います。

「プロダクトエンジニア」という職種についてご存知でしょうか。テクノロジーだけではなく、ビジネス・顧客にも越境して開発を行うエンジニアのことです。

私は、技術のスペシャリストになることで機能開発や運用面で良い影響を与えることを目的として立ち上げたチームに所属しています。
しかし、現在では市場/競合調査・インタビュー・PoC・機能開発と幅広い領域を担っています。
最近では、自由に越境してプロダクトエンジニアとして動くことで、プロダクトに価値を提供できるようになったと感じています。

本セッションでは、「どうしてプロダクトエンジニアを志したのか」「どのようなアクションを取ってきたのか」「どんな価値をプロダクトに与えることが出来たのか」をお話しします。
越境してエンジニアリングを行う楽しさをお伝えして、一緒にエンジニアとしての動き方を考え直す機会にできればと思います。

自分の推し技術カンファレンスに対して、所属企業の理解を得て、スポンサーしてもらったり、業務としてカンファレンスに参加したいという方は多いのではないでしょうか？
しかし、上司や会社から理解を得たり、スポンサーをしてもらうのは難しいという人も多いでしょう。

私の所属企業では私が入社してからの1年間でYAPC::Hiroshimaを含む16件の技術カンファレンス協賛を行いました。
また、スポンサーだけではなく国内外を問わないカンファレンスへの参加支援制度もあります。

本登壇では、これらを実現してきた経験を元に所属企業に推しカンファレンスを応援してもらうために理解するべきことや、必要なアクションをお伝えします。
技術職ではないステークホルダが何を考えているのか、彼らの理解をどの様に得るのか。企業がそもカンファレンスに協賛する価値とは何なのかを皆様が自分の所属企業に持って帰れる形でお伝えします。

昨年ChromiumにView Transitions APIが実装されました。Safariも実装される予定になっています。また、Firefoxも未実装なもののポジティブな立場を取っています

• https://chromestatus.com/feature/5193009714954240

この登場でMPAでもSPAのような画面遷移体験が作れるようになったと言われています

SPAとMPAの違いや利点を整理し、ページ遷移体験の向上について、今一度議論の整理を提供します。SPAの例としてReactアプリケーションを取り上げます。比較対象として@hotwire/turboやhtmxなどについても取り上げたいと考えています

皆さんがSPAやMPAなどに捉われず、ユーザーに取って快適なページ遷移体験を提供することに重きを置いた自由な技術選択を行えるようになる一助になることを目指しています

2024年、電子書籍のタイトルは混沌に満ち満ちていた！

半角/全角、多様な数字表現、バージョン違いの展開エトセトラエトセトラ・・・
そんなとき人はどのように書籍タイトルを正規化していくのか・・・

概ね「パワーで解決」という感じで解決することになりましたが、実際にどのようなパターンがあったのか、そしてどのように解決したのか共有します！

想定される対象者

• 電子書籍タイトルを正規化してグルーピングしたい人
• 電子書籍タイトルのパターンに興味がある人
• 困った書籍タイトルに興味がある人

プログラミング言語AWK第2版の発売やシェルスクリプトのテクニックなどが以前に比べて多くみられるようになっています。一時的なスクリプトを作るには少々手間なコンパイル言語が普及してきたことや、さまざまなバックグラウンドを持った人でも読めるようなリンガフランカとしてこれらの軽量なスクリプト実行環境が用いられてきたと考えています。

しかし元々そのポジションにいたのはperlコマンドではないでしょうか？　CGI時代の影響からかPerlはWebアプリケーションを書くための歴史的な言語であるという認識が広くみられますが、本来得意なのはテキスト処理です。またコマンド同士を繋げるグルー言語としても非常に有効に機能します。
このトークではawk,sedとの互換性、もしシェルスクリプトをPerlに置き換える場合などを例に、Perlを採用するメリット・デメリットを述べていきます。

本セッションでは、学生の時にPerl入学式 in 千歳を開催し、今では同じ会社のメンバーに登壇依頼、カンファレンスのスポンサーを会社に依頼、スポンサー窓口担当や共にカンファレンスの登壇や参加準備することで職能間の境界を越えて交流することができ、私の社内でのコミュニケーション量が増加してきた話をします。
私が所属している会社は職能ごとにチームが分かれており、プロジェクトによっては他の職種のメンバーと話すことがないこともあります。そこで、私は勉強会を主催や会社にカンファレンス協賛依頼などを行い職能間の境界を超えてきました。
今では職種が異なるエンジニアとも勉強会をきっかけに交流し、関係を継続することができています。そして、他のエンジニアにカンファレンスや勉強会に一緒に参加や登壇しています。
自身の技術領域外の勉強会やカンファレンスを通して職能間の境界を超える方法と楽しさについてお話しします。

Mutation Testingとは、プロダクションコードに対するテストコードがどれだけ十分に書かれているか？という観点から、テストコードの品質自体を評価するテスト手法です。

これまでのプロダクションコードの品質のみを担保するのではなく、一歩進んでテストコードの品質をも担保しようという比較的新しい観点です。

これを導入することで何がよいかというと、見かけ上のコードカバレッジが高く、全般的にテストコードが網羅できていたとしても、テストコードが正しく書けているとは限らないのですが、その部分を簡単に検出できるということです。

今回は「Mutation Testingとは？」という詳しいお話から始め、実際にMutation TestingをJavaScript,PHPに導入するまでの道のりや、その際に直面した問題点、その問題点をどうクリアしたか？なども含めてお話しできればと思います。

世の中のプログラミング言語には変数などの言語要素の型が静的に定まるものと、基本的に実行時まで定まらないものがあります。一方で、近年はTypeScriptのように動的言語の静的型つき指向の変種や、Pythonのように型定義を言語に取り込んだもの、Rubyのように型宣言ファイルを外部に用意することで静的解析の補助に用いるものなど、プログラムの潜在的誤りを検出するために型の概念を取り入れる流れが生まれています。

このトークにおいてはPHPで静的解析の改善に取り組んでいる筆者の立場から、Perl特有の型システムと歴史的な型付けのアプローチを踏まえ、PHP, JavaScript, Ruby, Pythonなどのアプローチを交えてそれぞれの特徴をお伝えします。

カンファレンスって楽しいですよね。同好の士が集まる場があるということは、それだけで私たちをワクワクさせてくれます。
では、自分でやってみたいなと思ったこと、ありませんか？カンファレンスと言わずとも、何人かで集まって、お互いに知見を交換し合ったり、お悩みを相談し合ったり…そういった場に、何かしらの形で関われたら…と思ったことは？

このトークでは、私が勉強会やカンファレンスに飛び込んだり、立ち上げたり、広げたり、誰かに託したり、諦めたり、そして人生が変わったり（！）してきた経験から、そんな皆さんの後押しになるかもしれないエッセンスを、「今日の懇親会で早速使える小技」なんかも挟みつつお伝えします。
YAPCは、みんなで作るお祭り。今日のこの場は、運営の皆さんの「やっていき」と、私を含む全員の「のっていき」の連鎖によって作り上げられた場です。
あなたも、ほんのちょっとだけ勇気を出してみませんか？

本セッションでは私が考えている「自社のプロダクトを開発するうえでエンジニアとしてのバリューの出し方」についてお話します。
新規事業開発においてPdMといっしょに価値検証やプロダクトを開発するうえで、「いかに最適な設計をしたり、メンテナンス性が高いコードを書いても、そもそも「何を作るか」「なぜやるのか」という部分がニーズとずれていると、自分が開発したものが使われない」という課題を持っていました。この課題に対してエンジニアとして向き合う中で、「作る」というバリューの出し方から「複雑なものをシンプルに提供すること」とバリューの出し方視点を変える方法を見つけたため、実例を交えながら解説します。

想定される対象者

• 自社プロダクトの開発者
• ジュニア〜ミドルエンジニア
• プロダクト志向のエンジニア

Debounce 処理というのはクライアントでよく使われる技術です。 高頻度で呼び出されるイベント（キー入力やマウスの移動、ウインドウのサイズ変更）などを制御するテクニックのひとつです。たとえばJavaScriptのライブラリLodashに実装されていたりそれなりにクライアント側では使われる技術です。
そんなDebounce処理をサーバサイドで実装したので、そのお話をしようと思います。
Debounce処理自体の説明から、 クライアントで処理すべきものをなぜサーバサイドで実装しなくてはいけなかったのかの背景の説明、 実際にどうやって複数のサーバで実装しているのか、なぜ3回も実装したのか、そして4回目の実装の構想などをお話します。

前身のasm.jsを含めると、WebAssembly(以下Wasm)が登場してから10年近く経過しました。ブラウザでCのプログラムが動作する「おもちゃ」として認知され、vimやffmpegが大きな変更もなく移植されブラウザで動作する様子は、当時見た人にとっては異様な光景に映ったかもしれません。

Dockerを中心としたコンテナ技術もまた10年近くの歴史があります。創業メンバーの1人でCTOも務めたSolomon Hykesが「Wasmが当時存在していたらDockerを作成する必要はなかった」、と発言したことは有名な話ですが、その言葉の意味を真に理解している人は意外に少ないように思います。

本セッションでは、WasmやDockerの出自や現状を振り返りつつ、これらがどのように交差し、これからどのような道を辿っていくのかについて、スピーカーの私見も交えながらお話しようと思います。