今までサマータイムとタイムゾーンについて雰囲気でやってきていませんか？僕は少なくとも雰囲気でやってきました。
実際そんなに困ることねーし・・・！とそう思っていたそのとき！困る時がやってきます・・・。(震え声)
RFCなどを追いつつ、PHPの実装をどうするのか？といったところまでふかぼっていきます！

このトークではPHP Parserを利用して静的解析ツールを作る話をします。

題材は簡易的な依存可視化ツールです。クラス間の依存の方向、数、深さからコードの複雑さを認識すること、バッドスメルを察知して設計を見直すこと等を目指すものです。

静的解析はコードを隅々まで見渡し、人が認識しにくい気づきを与えてくれます。これを活用しない手はありません。しかし、静的解析だの抽象構文木だの小難しく敷居が高く感じられるかもしれません。

このトークでは、具体例を通じて静的解析というものの解像度を高め、より身近に感じられるようになることを目指します。
また、実装する際の思考過程や設計判断に触れつつPHP Parserをどのように使ったのかを説明し、静的解析を知ることを通じて解析対象であるPHPの理解を深めることも目指します。

PHP、静的解析の仕組みや付随する設計に触れ、日頃の開発にいかせるヒントを見つけていただけたら幸いです。

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

「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とともに、もっとコードライフを楽しみましょう！

例外はただのトラブルシューターじゃありません。コード内の誰が何を担当するのかを教えてくれる、責務の指針なんです。

『PHPの例外、多すぎてどれ使えばいいかわかんない！』『例外、いつキャッチすればいいの？』『エラー情報、どこに吐き出すのが正解？』こんな疑問を持ったことはありませんか？

PHPの組み込み例外クラスの選び方から、自分で独自例外を定義するノウハウまで、コードをもっと読みやすく、管理しやすくするための実践的なアプローチについて考察してみます。

例外をマスターして、エラーハンドリングをもっとスマートに。

私たちが古くなったPHPアプリケーションをRuby on Railsに移植することを決断したのが2016年―。
私たちが移植対象としたPHPは下記のようなものです。

• とっくにEOLなPHPバージョン
• オレオレ・独自フレームワーク
• 標準サポート終了しているAmazon Linux AMIなEC2サーバー
• PEAR/PECLなライブラリ管理
• 自動化されていないテスト・デプロイ
• 仕様ドキュメントほぼ無し（ソースコードが仕様書）
• 担当プロダクトオーナー不在

過去に本PHPアプリケーションの移植プロジェクトは断続的に立ち上がっていたものの、それらは局所的な移植として終わってきました。
2022年、この戦いに終止符を打とうと本格的な移植プロジェクトが再始動、ついに2023年、移植を完遂しました。

本プロジェクトは正直、カッコいい移植プロジェクトとは言い難いものです。
そんな泥臭く長い移植の軌跡を、技術的負債解消の一事例としてお話できればと思います。

想定聴講者

• 技術的負債の解消に興味がある方
• 現在進行系で技術的負債と闘っている開発者

話すこと

• なぜ移植するか
• どのように移植を進めたか
• 移植前後の改善結果
• 移植後も山積する課題と今後の展望

話さないこと

• ナウい技術的負債の解消方法
• 移植後のシステムの技術的詳細

このトークでは、10年以上にわたり運用されているサービスにおけるPHPフレームワークの進化(FuelPHP 1.8.2からFuelPHP 1.9-devへの移行)とPHPのバージョンアップ(PHP 7.3からPHP 8.1へのアップデート)の戦略について語ります。

プロジェクトマネジメントと技術の観点から、ソフトウェアのバージョンアップを成功させるための「プロジェクトをリードする上での力学」や「バージョンアップにおいて有用だった技術的アプローチ」について具体的にお話します。

FuelPHPを使っている方はもちろん、それ以外のPHPフレームワークを使っている方も対象に、PHPフレームワークとPHPのバージョンアップの知見を共有します。
様々なトレードオフやハードルを乗り越えるために、どのように計画し、アプローチしたかをお話します。

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

アジェンダ

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

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

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

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

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

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

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

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

まとめ

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

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

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

効果測定した項目

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

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

皆さんはリリース後に文字化けが発生して、道頓堀に飛び込みたくなったことはありますか？
私はあります(※)。

PHP8.2の下位互換性のない修正の1つにmb_detect_encodingの文字コード検出の仕様変更があります。

私が担当しているメール共有サービスのメールディーラーで、バージョンアップ後に一部の受信メールが文字化けをしました。
原因は受信したメールのエンコード時に、前述のmb_detect_encodingを使っていたことです。

下位互換性がないPHPの仕様変更だったため、文字化けを回避することができませんでした。
その結果、メールヘッダに文字コードの指定がないRFCに準拠していないメールまで対応することとなり、大変苦労しました。

メールディーラーの保守運用・顧客対応チームのリーダである私が、顧客対応で泣きをみたことを中心に苦労した経験をお話いたします。
私と同様に顧客対応されているエンジニアの方々の参考になれば幸いです。

※道頓堀は大阪市中央区の繁華街である通称ミナミを流れる川の略称。
阪神タイガースの優勝やサッカー日本代表がW杯で勝ったとき、
年末年始のカウントダウンなどのイベント時に、
グリコの看板がある戎橋から道頓堀川に飛び込むことがある。
実際には私は飛び込んでいません。

静的解析ツールは使っていますでしょうか？
昨今のPHPのバージョンアップでは型定義が厳しくなってきており、静的解析ツールを導入することの優位性が高まってきています。
15年以上続いているレガシーシステムにPHPStanを導入した際の課題と効果について紹介します。

・既存の静的解析ツールからPHPStanへの移行
・PHPStanの導入時の課題
・導入から半年での効果と課題

既存の静的管理ツールに課題を感じている方や、静的解析ツールを導入したいと考えている方にとって参考になる内容となっています。

※ PHPConference関西2024と同じ内容になります。

しばらく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 の詳細な使い方、設定
• 型にまつわるお話

フレームワークのドキュメントに従って、あるいはプロジェクトの既存のコードに従ってファイル上部に書いた「namespace」「use」といったキーワード。

この意味、正しく理解していますか？
「ディレクトリ名と対応させて書くやつ」「他の言語でいう import みたいなやつでしょ？」みたいな認識をしていませんか？

実は PHP の機能としては namespace（名前空間）とディレクトリ名、ファイル名には一切の関係はありません！

「じゃあ、なんで require とかを書かずに他のファイルに定義したクラスを使えているの？」と思ったあなたに、その仕組みと、それらを支えている存在をお教えします。

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

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