コード化されていない稼働中のサーバを移設/再構築する必要が出てきたことはないでしょうか？私はこれまで四度経験してきました。この経験を通じて、手動設定が多いシステムや長期間運用されているサーバの移設/再構築がいかに難しいかを実感しました。

現代のIT運用では、インフラのコード化（IaC）が主流ですが、すべてのサーバがコード化されているわけではありません。本セッションでは、コード化されていない稼働中のサーバを安全かつ効率的に移設するための技術と手法について解説します。未来のインフラ運用を見据え、移設後の最適化と将来的なIaC導入の可能性についても考察します。実例を交えながら、具体的な移設方法を共有し、参加者が未来のシステム運用を切り拓く一助となることを目指します。

キーワード
strace, ltrace, tcpdump, netstat, procfs, gdb, Sledge

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

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

話すこと

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

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

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

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

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

話すこと

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

深く話さないこと

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

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

皆さんは 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年、電子書籍のタイトルは混沌に満ち満ちていた！

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

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

想定される対象者

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

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

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

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

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

想定される対象者

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

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

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

「エンジニアリング」という言葉を聞いて、何を思い浮かべますか？
ソフトウェアエンジニアの方々は「コードを書くことだ」という考えの方が多いかと思います。

最近私が副業を始めたのは、HDMIケーブルの正しい繋ぎ方を誰も知らないほどアナログ中心な、小さな印刷会社。NASのデータ整理アドバイザーとして雇われた私の業務はもっぱら社長・支店長との会議で、PCに向かう時間はほぼありません。
PCを使っていないけれど、エンジニアとして働いている。普段ほぼ出会うことの無いこの状況が、私に気づきを与えてくれました。

本セッションでは、私が現在持っている「エンジニアリングは、手段でなく目的によって定義されるものである」という考えを、そこに至るまでの経緯やそれを活かすプラクティスと交えてお話しします。
このセッションが、みなさんと共に「エンジニアリング」を再考・議論するきっかけとなれば幸いです。

正規表現はテキストの抽象表現です．ソフトウェアでは入力値が正しいか確認する処理やテキストの整形などに用いられるので，私たちにとってこれからも大切な技術といえるでしょう．

ところで，正規表現の「正規」という名前が「良い性質」という意味を持っていることをご存知でしょうか．しかし，開発者に正規表現の話題を振ると 読めない・混沌・辛い という声が多いです．

本セッションは，正規表現が何故複雑になり，読めなくなってしまうのかという疑問に答え，その解決方法を示します．

本セッションはPHPerKaigi 2024で発表し，改良したものです．多くのフィードバックをいただき，中には発表内容を元にPRを出したという内容もありました．YAPC::Hakodateでも聴講者の未来のコードに貢献することを目指します！
https://github.com/shunsock/phper_kaigi_2024

これからもずっと働き続けるのならば、エンジニアがいい。
そう考えて最近、Engineering Manager から Engineer にキャリアチェンジしました。
実際のところ現在進行系で、簡単な道のりではありません。

• 現役 Engineer としてのブランクは長く、力不足を感じることが多い。
• 加齢による身体の衰えの恩恵を受けすぎている。
• 衰えているのが自分だけではない (親も) という現実。

それでもこの仕事は楽しいし、長くこの業界にいることによる自分にしかできない利点もあるはず。あります！

「アクティブシニア」という言葉があります。身体機能や認知機能に若干の衰えがあったとしても、逆に向上する能力もあるとのことです。
ではエンジニアならばどうだろう？
これからシニアに突入する、自分も含んだ未来のすべての仲間たちに向けた話ができたら、と考えています。

GoogleCloudが提供する 「ImmmersiveStreamForXR」 というサービスをご存知でしょうか。
2023年に一般提供されたUnrealEngineをビルドからデプロイまでを全部クラウド上で管理し、そのままクラウドレンダリングで利用でき、没入感のある体験を簡単に提供できるというなんとも未来を感じるマネージドサービスです。

私が所属する会社では、ImmmersiveStreamForXRを活用して提供するサービス「αU live」の開発、運用に携わりました。この経験を踏まえて、その素晴らしさや気をつける技術ポイントを紹介しながら、未来のサービスを一緒に考えたいです。

対象とする方

• クラウドやサーバの知見がなくてもクラウドレンダリングで何かしてみたい方
• UnrealEngineはわかるがクラウドがよくわからない方（私はUnrealEngineは初心者です）