プロポーザル

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

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

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

本発表の主な内容

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

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

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

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

最近私が副業を始めたのは、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%防ぐことは現実的ではありません。一方で同じ障害を頻発させていては、サービス品質の低下と運用効率の悪化につながります。そのような事態を避けるため、発生した障害について「調査・分析・対応」を行い、原因を特定し再発防止策に取り組むことが重要です。さらに、「意図的に障害を起こす」や「障害が起きたらどう動くか？」を事前に考え、対策を取る未来へ向けたアプローチも効果的です。本セッションでは、これまでの実例を交えながら、再発防止策の見つけ方や考え方を紹介します。

対象

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

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

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

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

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

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