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

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

想定される対象者

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

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

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

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

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

最近私が副業を始めたのは、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は初心者です）

僕自身、ずっと起業したいと思いつつ、なかなかいいアイデアが見つかりませんでした。
自分自身が頑張るのもいいが、勝ち馬に乗れるなら乗るのも良いなと思っていました。
そんな中、現職の代表と出会い、起業に至った経緯、なぜこの事業を選び、僕ならこの事業を伸ばすことができると思ったのかをできるだけわかりやすく話
します。

対象

• 共同創業者として利益は得たいけど自分自身にアイデアがない方
• 将来的に自分自身での起業や共同創業での起業を検討している方

話すこと

• 僕の今までのキャリアについて
• 起業するアイデアの選び方
• 選定基準
• なぜこの事業をやっているのか
• なぜこの事業を伸ばせるかと思ったところ
• 実際やってみて大変なところ
• 実際やってみて良いところ

みなさんは型システムについてご存知でしょうか？

最近では、TypeScriptやPythonなどの静的解析や型推論システムがビルトインで容易に利用されるようになり、その採用が増えています。
その中で、動的型付け言語であるRuby on RailsやPHPは勢力を失いつつありますが、独自の型保護システムを採用することで時代の潮流に適応しようとしています。

そうした中で、これまでの言語はどのように時代の変化に対応してきたのでしょうか？
今回は「型システム」に焦点を絞り、その歴史を整理し、将来の技術的な不確実性にどう対処するかを考えたいと思います。

サービスを運用する上で、障害の発生を100%防ぐことは現実的ではありません。しかし、同じ障害が頻発することは、サービス品質の低下と運用効率の悪化を招きます。そのような事態を避けるためには、発生した障害について「調査・分析・対応」を行い、原因を特定し再発防止策を講じることが重要です。さらに、「意図的に障害を引き起こす」や「障害が発生した場合の対応方法を事前に考える」などの未来志向のアプローチも効果的です。

このセッションでは、GMOペパボのSREが、Root Cause分析といった根本原因分析プロセスの紹介と、これまでに実施した再発防止策の実例を交えながら、具体的な取り組み方や進め方について紹介します。

対象

• 障害の振り返りで初めて再発防止策を考えることになった方
• 普段からサービス運用で障害対応および再発防止策までを行なっている方

話し手が所属する企業では、旧来ngx_mrubyを利用して動的証明書や動的プロキシに対応してきましたが、組織での運用課題に対応するため、Goでプロキシサーバを開発しています。
現状、一部のサービス、社内サービスにおいて置き換えが完了しており、そのときに生まれた課題や、得られたメリットについて共有します。
特にマルチテナント環境における技術的なチャレンジについては他では聞けない話も多いと思うので、ぜひ期待してください。