企業向けにサービスを作ったことはありますか？実際に企業へ導入するには様々な障壁がありますよね。
技術的なセキュリティはもちろん、組織的なセキュリティや管理体制など幅広い対策が求められるため、ハードルが高いと感じるのではないでしょうか。
そこで本セッションでは、エンタープライズでも導入できる"本気"のお買い物メモサービスを作りながら要点を解説していきます。
個人、スタートアップで開発をしていく方にとって役立つ情報となるかもしれません。

話すこと

• エンタープライズで求められる、もしくは"求められない"セキュリティとは
• 技術的な対策(マルチテナント、脆弱性管理の自動化や可視化、IaaSの活用)
• 組織的な対策(承認フローの構築、仕組みの文書化)
• 実例を基にした対策(OSS管理、データの越境移転)
• エンタープライズで求められがちな機能(認証と認可、データダウンロード)

全文検索エンジンGroongaは、高速で高機能な全文検索を提供します。

Groongaはライブラリーとしてプログラムに組み込む事もできますし、HTTPサーバーとして起動してHTTP経由で全文検索することもできます。
Perlからは、Groonga-HTTPというCPANモジュールを使ってHTTP経由でGroongaを使えます。

また、PostgreSQLでは、PGroongaという拡張を使って、MySQLやMariaDBでは、Mroongaというストレージエンジンを使って、
Groongaで提供している高速で高機能な全文検索を使えます。

本発表では、Groongaがどのような特徴を持つ全文検索エンジンなのかと、その使い方について紹介します。
Groonga、PGroonga、Mroongaを詳しく知らない、または、高速・高機能な全文検索に興味がある人向けの発表です。

技術的負債はどこの現場でも多かれ少なかれ存在します。技術的負債ゼロな現場はありません。

技術的負債を継続的・定期的に返済できていれば問題はありません。しかし長年放置され「負債度」が高まった技術的負債を返済するのは非常に厄介で骨が折れる作業です。

本発表では、下記のトピックを扱います。

• 技術的負債の生まれ方
• 「技術的負債の倒し方」のはじめ方
  • 「負債」という言葉の限界
  • 共通言語で語る
• 技術的負債の倒し方
  • ソフトウェア開発の三本柱を建てる
  • コードフリーズ宣言
  • ４つの負債解消アプローチ
• 技術的負債の倒したあと
  • 継続的負債返済

技術的負債はなぜ生まれ、それにどう立ち向かい、その後どうすべきなのか。私自身が経験したEOLを迎えたPHPの移植・アップグレード事例を踏まえて発表します。

Kubernetesの採用は、複数チーム、マルチクラウド、異なるスタックを持つ組織にとって複雑な課題です。本セッションは、これらの課題を解決するアプローチを提示します。プラットフォームエンジニアリングの原則とKubernetesへの適用を軸に、OSSとベストプラクティスを活用した解決策を紹介します。Helm、Tekton、Argo CDなどを統合したプラットフォームの構築方法を解説し、開発チームの認知負荷を軽減しつつ、生産性を向上させる戦略を探ります。さらに、ソフトウェアリリース手法や、デリバリーメトリクスを用いた最適化戦略も紹介します。CrossplaneによるマルチクラウドインフラやKnative ServingとArgo Rolloutsを活用した段階的アップグレードなど、クラウドネイティブ環境の実現に向けた技術も取り上げます。とにかく盛って今のクラウドネイティブを紹介します。

現在YAPCを始め、たくさんの技術コミュニティが存在します。そして技術コミュニティにはスキルアップはもちろん、他の技術者との交流や新たな「好き」の発見、そして新たなキャリアの開拓など、参加者の未来を拡げる数多くのメリットが存在します。（実際、私も技術コミュニティを通して、数多くの「好き」の発見やキャリア開拓などを実現できました）

しかし、技術コミュニティに興味は持っていても「なかなか第一歩が踏み出せない」「自分には難しそう..」という方も多くいると聞きます。（私も最初はそうでした）

そこでこのセッションでは、AWS Community Builderである私がどのように技術コミュニティに参加・貢献するようになったのか、そして技術コミュニティにはどんな魅力があり、技術コミュニティを通してどのように自分の未来が拡がったのかなど、技術コミュニティの魅力やメリットをお話ししたいと思います。

AWS Lambda FunctionURLを活用し、従来の開発モデルで作られたWebアプリケーションを最小限の変更でサーバーレス化する手法を紹介します。

カヤックが運用するeスポーツ大会支援サービスTonamelでは、Goで実装されたマイクロサービスをECSからLambdaへ移行し、急激な負荷増加への対応とコスト削減を実現しました。

今回のYAPC::Hakodateスポンサー連動企画Perlbatrossでは、Perlで実装したWebアプリケーションをLambda上にデプロイし、CloudFrontと組み合わせて低コスト運用を実現しています。

本トークでは、Lambdaに移行するメリットとデメリット、GoやPerlアプリケーションのLambda化、デプロイ手法、複数開発環境やサービスメッシュの実現方法、VPCアクセスとインターネットアクセスの両立など、実践的な内容を扱います。

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

深く話さないこと

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

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

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

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

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

さくらインターネットの「さくらのクラウド」は2023年度にデジタル庁が募集したガバメントクラウドに、2025年度末までに全ての技術要件を満たすことを前提に認定されました。
2024年6月現在、デジタル庁の技術要件を満たすため、パブリッククラウドとしての機能強化とサービスの開発に取り組んでいます。

数多くの技術要件を満たすには、開発力の大幅な強化のためのエンジニアリング組織の拡大、また一人ひとりのメンバーの変化と成長が必要となっています。
そのために、私たちは学び、一丸となるための取り組みを行い、組織体制の改善を進めてきました。

本発表の主な内容

• ガバメントクラウドとは何か
• パブリッククラウドに向けた開発にあたり、私たちが取り組んだこと
• エンジニアの変化（と成長）

大きなチャレンジをする開発組織についての一つの事例として、また議論のきっかけになれば幸いです。

カンファレンスでは、「これをやらずにはいられない」という情熱を燃やし、昼夜問わず邁進する人々との出会いがあります。自分も変わりたい、なにかを成し遂げたい。でも、何かって？
やりたいことがあるわけではないけれども、ずっと今のままではいけないという焦燥感があるーー。自分もかつてはそうでした。リーマンショックによる早期退職という後ろ向きな理由での転職を経て、目の前にある仕事をこなしていく日々。
けれども目の前の仕事と向き合い、やりきり、そのことで自信を得る繰り返しの中で、私のキャリアは変わっていきました。いつのまにか自らコミュニティに飛び込んだり、ワクワクする目標をつくろう！と呼びかけるようになったり、開発組織のアジャイル導入推進を牽引したり・・・。
そんな、検査と適応を繰り返しながら変化してきた私のキャリア戦略が、かつての私と同じようなキャリア迷子の方が一歩ふみだすきっかけになれば幸いです。

OSS開発ってなんかかっこいい感じします。僕は、GitHubでスター17Kを超える化け物ソフトのクリエーターでありメンテナをやっています。

楽しいけど、憂鬱になることもあります。そしてたぶん、それを皆さんは全然知らない。言ってこなかったし。なのでそれを、初めて話します。

• Honoと僕の話
• あなたの知らないOSS開発の現場
• GitHubの通知ボックスが恐怖
• ありがたいIssueと厄介なIssue
• It's not a bug!
• Share a minimal project to reproduce it!
• Discordには顔を出さない
• Whyをきかれると辛い
• PRが全てではない
• 嫉妬される
• リファクタリングのdiffで貢献を測りたくない
• やりたいことをシェアしない

でもOSS開発をやっていて思う。OSS開発は面白い。