トーク

Rustは高いパフォーマンスとメモリ安全性を両立したプログラミング言語で、最近ではLinuxカーネルの開発に一部取り入れられたことでも話題になるなど、人気の高い言語の一つです。

そのRustで、PHPの拡張モジュールを作ることができるのをご存知ですか？
拡張モジュールは通常C言語で開発されますが、ext-php-rsというライブラリを利用すると、Rustで書いたコードをPHP拡張モジュールとしてコンパイルすることが可能になります。

このセッションでは、PHPerでありRust初心者の私がRustを使ってPSR-7ライブラリを開発した経験をもとに、以下のことをお話しします。

• Rustはどんなプログラミング言語か、PHPとの比較
• PSR-7について
• RustでのPHP拡張モジュールの作り方・デモ
• Rustを使ってみて感じたこと

障害が起こった時には全力で対応しますよね。
障害が起こった後の再発防止までちゃんと検討してますか。

このセッションでは、再発防止のアイディアを捻り出すための方法と、それを実行に移すためのチームルールについて共有します。

例えば、アイディアを捻り出す方法には、こんなステップを踏んでいます。

1. ロジカルシンキングで原因を網羅的に洗い出す。
2. 原因を解釈する。
3. 事実や解釈に対応する再発防止策を考えてみる。
4. 良いものが出なかったら突飛なアイディアも出してみる。
5. ロジカルシンキングでマッピングして、よりアイディアを抽出する。
6. ROIを考えて実行するものを決める。

PHPフレームワークにおける「ミドルウェア標準化に関するガイドライン」であるPSR-15は、主にフレームワークの内部で使用される技術であり、普段の開発では意識する機会が少ない部分です。

しかし、PSR-15はリクエストの処理とレスポンスの生成に直結する部分であり、この概念を理解することでフレームワークがどのように動いているかを知る手助けになります。また、PSR-15を用いれば簡単なフレームワーク作成も視野に入るかもしれません。

本LTでは実際にコードを見ながら、「5分で理解するPSR-15」と題してお話ししたいと思います。

皆さんにとって、最もお気に入りのPHPフレームワークは何でしょうか？私はFlowです。

昨年秋に新しいプロジェクトに配属され、初めてFlowに触れる機会を得ました。
以来、約一年間、業務を通じてFlowを利用してきました。Flowを触る度、直感的でわかりやすい設計と豊富な機能に心が躍り、気が付けばドはまりしていました。

しかし、GitHubのスター数は150ほどであり、LaravelやSymfonyのようなメジャーなフレームワークと比べると知名度が低いのも事実です。
今回のLTでは、Flowの良さを少しでも知っていただけるよう、私の感じたFlowの魅力を皆さんにお話ししたいと思います！

話すこと
・Flowの特徴
・個人的なFlowの好きなところ

話さないこと
・他FWとの比較

Select2というライブラリを使ってサジェスト機能を導入しようとしたものの、PrototypeJSとのコンフリクトや、データ量が多い環境でのパフォーマンス問題に直面しました。最終的にライブラリを使わず1から独自に実装した結果、パフォーマンスが大幅に向上し、機能を完成させることができました。この5分の発表では、その経験から学んだライブラリ選定の課題と、バックエンド処理を使ったサジェスト機能の実装方法を紹介します。

PHPStanは静的解析ツールとして、日々の開発で多くのエラーや警告を教えてくれます。今回の発表では、私が独断と偏見で選んだPHPStanのエラーをできるかぎり紹介し、そのエラーがどのような状況で発生するのか、また具体的な修正方法を一挙に発表します！

PHPStanのエラーを理解して、あなたも今日からPHPStanをあなたのより良い同僚の一人にしましょう！
そして開発品質を上げていきましょう！

PHP開発者ならおなじみのvar_dumpとvar_exportですが、これらの関数がどのように動いているのかを考えたことはありますか？

本発表では、var_dumpとvar_exportの違いを簡単に紹介し、それを切り口にPHPのソースコードを読み始める方法とそのメリットをお話したいと思います。PHPの内部動作を知ることで、デバッグや開発スキルをさらに向上させるきっかけを提供します！

開発初期段階で、社内だけにUIを公開して早期にフィードバックを集めるために、isProduction()を活用しました。
スプリントレビュー会前にUIや文言を改善できることで、リリース前の手戻りを減らし、開発スピードを向上させる具体的な方法についてお話しします。

課題:
UIや文言の修正がレビュー会後に集中してしまい、リリースが遅れることがありました。
実際の操作性の問題や細かいバグも見逃されがちで、後で修正することもありました。

解決策:
isProduction()を利用して、社内ではUIを早期に公開し、開発段階でも社内メンバーからフィードバックをもらい、リリースまでに改善することで手戻りを減少させました。

結論:
isProduction()を活用することで、早期にフィードバックを集め、リリース前の手戻りを減らし、開発の効率化を図ることができました。

Laravel 11 待望のリリース！
公式のアップグレードガイドを見るとこのような記載が。

『アップグレード見積もり時間：１５分』

・・・本当に？

公式が言うのであればそうなのでしょう。
幸い、えんさがそっ♪は PHP 8.3 / Laravel 10 と好条件が揃っている。
では 15分 でアップグレード完遂という高みに挑戦しようではないか。

外部システムと連携を行うときに、頭を痛めるのが ”APIでの連携” です。
API で機能連携を行う場合、みなさんも一度はこんな経験があるのではないでしょうか？

「レスポンスデータが扱いづらい」
「エラーレスポンスを適切にハンドリングできない」

私たちのチームでも同様の課題に直面しましたが、
API 呼び出し時に専用の Result 型 を用意することで、解消することができました。

これであなたも、API の仕様に惑わされない実装ができるようになります。

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

LaravelのEloquetにはupsert関数があって便利だなぁ♪
あれ？updateOrCreate？
あれあれ？updateOrInsert？

一体どれを使えばいいんだーーー！！！

本セッションではこんな悩みを解決するために、それぞれの関数の説明とどう使い分けるかについてお話します。

さあリファインメントを始めよう
→適切なサイズに区切るには見積もりが必要だな
→見積もりの精度を上げるには何を作るかが明確じゃないと
→リファインメントが終わらない！！

リファインメントに時間がかかりすぎる我々のチームは、「リファインメントとは何か」を考え直すことにしました。
スクラムガイドの定義を調べ、実際にやっているリファインメントと比較した結果、
辿り着いた答えは「我々のリファインメントはリファインメントじゃない」でした。

このトークでは、なぜ我々のリファインメントはリファインメントではないのか、方針を変えたことでチームにどのような変化があったのかをお話しします。

さあリファインメントを始めよう

皆さんは、Laravelでの定期実行をどう実現していますか？？

我々のチームでは、サービスをECSにてデプロイしていることもあり、Laravelのタスクスケジュール機能を使わない選択をしました。

しかし、ECSのLaravelサービスに対して定期実行する方法には、以下のようなものがあります。
・ECSのスケジュールされたタスク
・Amazon EventBridge SchedulerからのECSタスクの実行
・Amazon EventBridge SchedulerとLambdaを使用したAPI呼び出し
この中から「早くて安くて安心な」手段を選ばねばなりません。
そこで、AWSのコストを抑えつつ、必要な要件を満たし、運用が簡単な方法を見つけるべく我々はアマゾン（AWS）の奥地へと向かいました。

そして冒険の果てに見つけた、最適な定期実行の方法をお話します。

DKIM、DMARC、SPF
これらを説明できるでしょうか？

2024年4月から本格的に始まったGmailのガイドラインに基づくメールの受信拒否設定によって、メールセキュリティの考慮は他人事ではなくなりました。
これは、非エンジニアにとっても同じです。
場合によっては、サービスの利用者にGmailガイドラインに対応するよう依頼する必要があるからです。

しかしながら、これらの知識はどうしても専門的な技術知識なしでは説明しづらく、非エンジニアにとってはなおさら理解しづらい分野です。
難しい専門用語を使わないよう注意しながら、非エンジニアの方に理解してもらおうと頑張って資料を用意して説明した方も多いのではと思います。

この発表では、非エンジニアの人にも伝わるよう、今押さえておくべきメールセキュリティについて解説します。

皆さん「学ぶ・勉強する」と聞くと「机に向かって本を読む」「カンファレンスに参加する」というようなことを想像しませんか？
実際それらは学びに繋がる大事なアクションなので間違ってはいません。
でも「毎日本を読む」「毎日カンファレンスに参加する」ってしんどくないですか？
私はしんどいと思っちゃいます。
「本を読んで学ぶ」は手段のひとつでしかありません。
日常のありとあらゆるものが学びの対象となります。
例えば日々行っている業務から学ぶこともあるでしょうし、漫画やアニメから学ぶこともあるでしょう。
そういった全てのことから学べるようになると頑張らなくても学べて成長できるようになります。

本セッションでは

• どういったものが学びの対象となりえるのか
• 私が個人的に日常から学んできたことの例
• どうやったら何からでも学べるようになるのか

などをお話できればと思います。

世の中にはたくさん便利な言葉があります。
その中でも開発に関わる便利な言葉において「今の場面においてはその言葉は逃げじゃないか？」というシーンが多く見られます。
私もつい便利に使って逃げてしまうことがあります。
具体的には以下のような言葉は、便利ではあるが使い所を間違えると逃げに繋がる言葉だと思っています。
認知負荷・属人性・技術的負債・心理的安全性・視座…etc

本セッションでは

• なぜこれらが「逃げ」なのか
• 適切な場面と、適切ではない場面はどういったものがあるのか
• 逃げないためにはどうすればよいか

このあたりを中心にお話できればと思います。

背景
あるプロジェクトでたくさんの障害を発生させてしまった。。。
障害はユーザーに迷惑をかけてしまうし、エンジニアのメンタルが削られるし、進行中のスケジュールを圧迫する。全然いいことがない。障害はこの世から無くなって欲しい。せめて減らしたい。。。
そんな思いから開発プロセスを見直す動きが社内で生まれました。

お話しすること
・そもそも障害と何なのか？障害と向き合う
・適度な障害予防コストのバランス
・プロセス確立までの道のり
・実際のプロセスや工夫を紹介

障害を少しでも減らしたい、自分のチームに見合ったプロセスをカスタマイズしたいと同じ悩みを抱えているPHPerの皆さんにお伝えできれば幸いです！

「コンフォートゾーンを抜けましょう」っていうフィードバックもらったことありませんか？
私はあります。
でも「そもそもコンフォートゾーンって何？」「抜けろって言うけどどうやって抜けるの？」って思いませんか？
私は思います。

本セッションでは

• コンフォートゾーンとは何か
• どうしてコンフォートゾーンから抜け出せないのか
• なぜコンフォートゾーンを抜け出さなければならないのか
• コンフォートゾーンを抜け出すには具体的にどうすればいいのか
  このあたりを中心にお話できればと思います。

皆さんCI/CD回してますか！
日々のルーチンワークを仕組み化して定期実行させるのは効率化の観点で非常に重要ですよね。
ローカルマシンでcrontab書いて手元のスクリプトを定期実行…みたいなことしてる人、いませんか？
それ、GitHub Actionsでできますよ！
本セッションでは

• GitHub Actionsで定期実行する方法
• 弊社での活用事例
  などを中心にお話しします！