心理学者のロサダをご存知でしょうか。
ロサダは対人関係において、ポジティブな表現とネガティブな表現の比率を3:1とすると信頼感や安心感を与えやすいことを提唱しました。
俗にこれはロサダ比と言われています。

また私事ではございますが、先日PHP Conference2023にて「CodeReviewerが求められること」を発表してまいりました。
https://fortee.jp/phpcon-2023/proposal/25891e6c-7762-47b5-8cb3-e3db7f056abc
そこで、CodeRevieweeが求めるものの中に「自信を持ちたい、安心したい」という気持ちがあることが明らかとなりました。

本セッションでは、CodeReviewerが求められることを満たすために、ロサダ比を用いることはできるのかという点に迫ります。
また、僕の現場におけるコードレビューの実例や、エンジニアにインタビューなどにより、「自信を持たせるReviewerの極意」を考察していきます。

レビュー時、依頼時に少しでもお役に立てると幸いです。
対象者： コードレビューを行う全エンジニア（役職問わず）
お話しないこと： 心理学の専門家ではありませんので、心理学の深いお話をする予定はありません。

クリーンアーキテクチャを知っていますか？
そう(層)ですね。

クリーンアーキテクチャは層を切り分けることで、テストをし易い構造を作る設計手法です。
Controller -> UseCase -> Repository -> DataAccessObject
　　　　　　　　　　-> QueryService -> DataAccessObject
　　　　　　　　　　-> Service -> DomainService

こういった IO や処理を切り離し、各層において逆順での接続を許さないことで
ある程度のビジネスや機能に沿った実装をメインに置きながら、テストをしやすくした機構になります。
これだけをメインに据えたものは 軽量DDD ともいわれますね。

この構造を維持をするのは、人力レビューが基本のため、とても手間がかかります。
しかし、 php には phpat というアーキテクチャの定義ライブラリが有るのです。
これを使うことで、この構造を機械的に確認してくれるようになります。

リアーキテクチャを行う際に phpat を設定し、
1 年程度 実際に運用した内容とその変遷、
簡単な設定方法について皆さんにお話させていただきたいと思います。

皆さんはPHPサーバーのセットアップをどのように行っていますか？
手動で行う方法、構築済みサーバーを利用する方法、コンテナ技術を用いる方法など、様々な方法があると思います。
しかし、これらの方法は時間がかかったり、手順が複雑であったり、構成変更の柔軟性に欠けたりすることがあります。

今回紹介するのは、Ansibleという強力な構成管理ツールを用いた、PHPサーバーの構築・デプロイメントの自動化です。
AnsibleはSSH接続によってエージェントレスで動作し、軽量で学習コストも低いため、PHPサーバーの環境構築に最適なツールです。

このセッションでは、PHPエンジニア向けに、柔軟な構成で効率的にPHPサーバーを自動構築する手法についてお伝えします。

主な対象

• PHPサーバーの環境構築に興味のある方
• インフラ・DevOpsに興味のある方

このトークでは、LaravelのORMシステムであるEloquentのアクセサ・ミューテタが何か、またクエリビルダとの違いは何かについて、PHP初心者に向けてわかりやすく解説します！！
その後、Eloquentとクエリビルダを組み合わせて使用する際の注意点について、実際に起こった失敗談を紹介します。
そして、この失敗から得た教訓をもとに、同様の問題を避けるためにはどうしたら良いのかについても掘り下げます。

このトークを聞くことで、Laravelを利用しているけれどもEloquentとクエリビルダの違いが分かっていない方も、明日からこの2つの違いを理解し、安全にデータベース操作ができるようになるでしょう！乞うご期待！

みなさん情報設計という言葉を聞いたことはありますか？
PHPerのみなさんは普段からどういった情報を扱っていますか？

情報設計は、扱う複雑な情報を整理することでチーム開発をより円滑にすることが期待されます。

本トークでは情報設計という考えを実プロダクトの開発フローに組み込み、具体的に何をやってどんな知見を得られたかをお話しします。

また導入はしていないが、他の情報設計を開発フローに組み込むかの方法についても考察します。

PHP8.3ではOpcacheにも改善が入りました。php.iniを僕は雰囲気で使っていますが、これを機会にしっかり最高の設定を考えたい。本業でECSで利用しているphp.iniについて最高のパフォーマンスを出すためのPHP
にするための設定を考えます。

WordPressが好きなエンジニアがいるでしょうか？いいやいない。と反語を使いそうな勢いで、エンジニアは嫌いだという方を多く見ます。
もしかしたら、そんな中で良いところや悪いところを整理できていないかもしれないと考えました。
(ああぁ！！！！と叫びたくなる衝動を抑えて)冷静にWordPressの良いところ、悪いところを整理して発表します。

ジュニアエンジニアが多く、テックリードがあまりいないかも・・・？そんな環境でお仕事した方々はいないでしょうか？
ジュニアエンジニアの方々はすごく頑張ってくれているので、しっかりレビューしたいけど、する時間がない！
やるならできれば自分が本当に必要なレビューだけ頑張れるようにしたい！そう思っている方々も多いことでしょう！特にLaravelなら！！！
そんな時に僕がやっていたCI/CDを公開しつつ、何を考えてそのようなことをやっていたのか？についてお話しさせていただきます！

みなさんはこういった経験が無いでしょうか。

「PHPStanのレベル5まで対応完了！よしっ！」
「つづいて、レベル6っと、ッターン！」

Method xxx() return type has no value type specified in iterable type array.

「えぇっ！？」

このように対応レベルを上げた際、新たなエラーに直面した経験が誰しもあると思います。
特に、レベル6の型ヒントの欠落を報告での対応から厳しくなる印象です。

そんなとき、こう思った人も少なからずいるのではないでしょうか？

「PHPStanはLevel6で何を見ているのだろう」 と。

本トークでは、そういった疑問をコードリーディングを交えつつ、みなさんと一緒に解き明かしたいと思います。
PHPStanが見ている世界を知ることができれば、PHPStan(ひいては静的解析ツール)ともっと仲良くなれるはず！

■ 話すこと

話す内容としては、まずPHPStanのレベルについて概要を説明し、その後、レベル5とレベル6での解析方法の違いや、
字句解析や構文解析、評価などの基本的な概念について触れていきたいと思っています。

■ ターゲット

• PHPStanの対応(特にレベル6)で苦労したことがある人
• PHPStan(静的解析ツール)と仲良くなりたい人

このセクションではリアルなLaravelのプロジェクトを例に、ドメインイベントを用いてどうやってコードをすっきりさせるかをナビゲートします。

テストも楽チンになるし、コードも再利用しやすくなるような、ちょっとした工夫を伝授します。

リファクタリングって難しそう？

いえいえ、このセッション後は、もう怖くないですよ。

Laravelとともに、もっとコードライフを楽しみましょう！

私はこれまで幅広いキャリアを歩んできました。経歴としてはSES企業/Web系自社開発の上場企業/フリーランスエンジニア/起業/Web系受託開発企業/スタートアップ企業/プログラミングスクール講師/地方移住などです。
その中で得られた経験などを元にエンジニアとしてどのような選択肢があるのか？というお話をできればと思っています。
主に話す内容は下記になります。

アジェンダ

• 1.何故キャリアのゴールを決めた方が良いのか？

  • 日々の仕事の納得感が変わる
  • 人的資産、社会的資産、知的資産の計画を立てるとゴールが見えてくる。

• 2.日本と世界におけるエンジニア市場の違い

• 3.これまでの自分のキャリア

• 4.他のエンジニアのキャリアモデルケース

• 5.どうやったら、ユニークな人材になれるのか？

• 6.自分に合ったキャリアの最適解を決める方法

• 7.実際、エンジニア出身経営者としてキャリアを歩んでみてどうだったか？

まとめ

• ゴールを決めて、自分のロールモデルを見つけよう。
• 自分がやらない事を決めるのも重要。

テストコードを書いていますか？
テストを書いた方が良いと誰しもが思い現場でテストを整備していると思いますが、テストコードを書いた事でどんな効果が生まれるのか向き合った事はありますか。
また、エンジニア間であればテストコードへの大切さや取り組む意義について共通認識を持てている現場は多いと思いますが、
エンジニア以外の職種や事業決済者へ、テストコードの効果を理解してもらう事に苦労したことはありませんでしょうか。

今までテストコードを書かなかった現場が、主にPHPUnitによる沢山のテストコードが整備されたアプリケーションを立ち上げた時、開発・運用面・リリースの状況が変わった話や、効果を数値化した話をします。
テストコードを整備していく工数（コスト）も忘れてはなりません。その上で効果や恩恵を算出していきます。

効果測定した項目

• テストコードを書くようになるまでのチーム状況や書く過程、時間
• 多くの時間を割いていた人の手によるQAテストをテストコードでカバーできるか網羅率を算出
• テストコード整備工数とQAテスト実行工数の比較
• リリース数の変化と開発の工数変化
• テストコードによるコードと開発チームの変化

テストコードの普及がなかなかできないチームや、今後テストコード整備に取り組んでいきたい方の参考になれば幸いです。

しばらくPHP界隈から離れていたPHP5上級認定技術者資格者が、久しぶりにPHPの世界に戻ってくると、浦島太郎になっていました。
浦島太郎になって改めて学びなおしたポイントは、これからPHPを学ぼうとしている人や、他の言語からPHPを触ることになった人にもきっと活かせるはず。
PHP5の時代の苦労話も織り交ぜながらお話したいと思います。

・変わっていて驚いた言語仕様の変化
・PSRって何？
・外部ライブラリの使い方
・他の言語とごっちゃになってしまったポイント

古くからあるサービスには、機能強化とともにサブシステムが増えていきました。

最初は良いけれど、
・検証サーバーは共用だったり、個人毎だったりバラバラに存在
・共用サーバーには、交代して使用する為に待ち時間が発生
・複数の人が使うので、テストデータがぐちゃぐちゃに
・サブシステムが増える度にサーバーも増えてくる
・当然、ソース修正や管理、デプロイもややこしくなる
というような問題が、だんだん見えてきました。

では、この問題の改善にチャレンジしよう！とは言いつつ、
「今まで使い慣れたエディタやリポジトリ構成、開発の流れは変えたくないよ」という声もあります。
さて、どの様に改善していったでしょうか。

・Dockerで共用サーバーを廃止して、メンバー毎の環境を整理しましょう
・コンテナ環境でも今まで通りPhpStormで開発作業ができるようにしましょう
・ユニットテストもうまく連携しましょう

※この内容は、PHPConference関西2024と同じ内容になる予定です

GitHubが提供するCI/CDサービス 「GitHub Actions」。
ドキュメントが充実していて簡単に使い始められる反面、ジョブが終わらなくてキャパを食い尽くしてしまったり、GitHub Actionsが障害中でCI/CDが出来ない、などのトラブルも耳にします。

本トークでは数多のプロジェクトでGitHub Actionsと戯れときに事故に向き合ってきた体験をもとに、GitHub Actionsを使うときにやっておくと良い設定をご紹介します。

お話しすること

• GitHub Actionsのおさらい
• タイムアウトの設定は必ず
• バージョンは明確に
• CIで出来ることはローカルでも出来る状態が理想
• 3rd-party Actionsは定期的にバージョンアップしましょう
• Environment VariablesとSecretsは正しく使い分けよう

Laravelは良くも悪くも雰囲気で書けてしまう反面、実は予期せぬ振る舞いをしていたり、パフォーマンスの悪いコードを書いてしまう恐れがあります。
本トークではLaravelでやりがちな間違いを取り上げて「これは」「こうすると良い」という話をします。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• 「えっ...うちのプロダクト、遅すぎ・・・？」と感じられている方 (パフォーマンスの良いコードを書きたい方)

お話しすること

• 不具合起きちゃう編
  • Eloquent Modelの create() update() get() find() first() の返り値を正しく理解してから使いましょう
• パフォーマンス悪い編
  • レコード数多いテーブルに whereHas() や whereDoesntHas() を使うとDBが泣きます
  • そのクエリ、1,000回呼ばれてるけど大丈夫ですか？
• Laravel Wayに乗れていない編
  • クエリを書くときにとりあえずjoinを使っていたり、インスタンス生成するときにとりあえずnewしているならLaravel Wayに乗れてないかも

みなさんはシステム障害が起きた時、どのように調査を行いますか？
根拠となるデータを元に仮説を立てて検証するというのがセオリーですが、時に必要なデータが無くて行き詰まったり、経験則や自身の勘に頼ってしまいがち、という事もあると思います。

ログ・メトリクス・トレースはシステムの状態を可視化するデータ(テレメトリーデータ)の代表格で、これらを上手く活用することにより事実に基づいて仮説・検証プロセスを回すことができます。このようにして、どれだけ複雑なシステムであっても理解しやすい状態にすること、いわゆるオブザーバビリティを高めることが近年注目されています。

OpenTelemetryはこれらのデータを収集するためのツールとして登場し、これによってオブザーバビリティを高めやすくなってきています。そして、OpenTelemetry PHPが最近GAされ、PHPにもオブザーバビリティの波がやってきました。

本セッションではまずOpenTelemetryについて紹介し、サンプルアプリケーションを通じてPHPでテレメトリーデータを収集・分析する方法を見ることで、オブザーバビリティを体感する場にできればと思っています。

想定ターゲット

オブザーバビリティ入門したい方
オブザーバビリティは知っているが、PHPでの実践方法について知りたい方

少し前にパスワードにまつわる「ハッシュ」と「ソルト」という言葉が話題になりました。
また「平文で保存していたパスワードが流出する」といった事件もたびたび耳にします。

パスワードの扱いについては、Web アプリケーションフレームワークを使っていればあまり意識することは無いかもしれません。
実際、意識しなくてもフレームワークがよしなにしてくれます。

でも、いったい「ハッシュ」や「ソルト」とは何なのか？
上述のような事件を起こさないよう、アプリケーション開発者としてしっかり押さえておくべきポイントをお話します。

不具合が確認され、丸一日かけて調査したら原因はうっかりミスによる構文エラーだった.......そんな経験ありませんか？
「そんなうっかりミスを実行する前に気づけたらいいな」そう思ったあなたにお勧めするのが静的解析です！

本トークでは PHP 静的解析ツールの一例として PHPStan を取り上げて、それが使えるとどんなことがいいのかをお話します。

本トークで話すこと

• 静的解析と PHPStan についての概要
• こんなうっかりミスを検出できます

本トークで話さないこと

• PHPStan の詳細な使い方、設定
• 型にまつわるお話

私が開発を担当しているサービスでは Laravel をフレームワークとして採用しています。
Laravel が提供している認証機構は、通常ほとんどのニーズを満たせるほど充実しています。
しかし、現場では「独自の認証方法を追加したい！」というニーズが発生することも多々あると思います。

私はつい最近、そのようなニーズに合わせて Laravel の認証機能を探求し、独自の UserProvider を作成しました。認証機能を探求して分かったことやカスタマイズのプロセス、全体を通しての気づきについて共有したいと思います。