2025年はPHPが公開されてから30周年のようです。おめでたい年ですね。
私は15年以上Webアプリケーションエンジニアとして働いてきたのですが、
これまでPHPでコードを書く機会は経験はありませんでした。
そんな私ですが、PHPが30周年を迎えた今年、転職を機にPHPを使うことになりました。
私はマジメな性格なので、PHPを使うからには、しっかりと基礎を学びたいと思っていました。
そこで、まずはPHPの思想や基礎を学ぶために、PHP1.0から履修することにしました。
PHP1.0の環境を作るのはそれなりに大変でしたが、なんとか環境を用意し、公開当時のPHPをブラウザで表示することができました。
これにより、当時のPHPで実現されていたことや、思想、そして少しのC言語(?)を学ぶことができました。
このような充実感はありつつも、最近のPHPにつながる実務的な知識は身につかなかったので、まだまだ精進が必要です。
ただ、PHP1.0を動かすこと自体は面白い経験だったので、このカンファレンスを良い機会に、この経験をみなさんに共有したいと思いました。
本トークの内容や対象者については、以下のように考えています。
内容
対象者
深い話に踏み込むつもりは無く、気軽にどなたでもお聞きいただける内容にしたいと思っています。
PHPの標準関数やクラスで絶対日時を扱う時に利用するのが、strtotime
や DateTime(Immutable)
です。
引数には、どんな値が使えましたっけ?
どうしても『おしゃれ』に書きたい!そんな時には、色々な指定方法を知っておくと有利です。
どうやって知ればいいでしょう?PHPのことはPHPに聞くのが1番簡単そうですよね。
PHPについての信頼できるソースとして、php-srcを訪ねてみましょう。
構文解析の定義ファイルを読むことで、利用可能な形式を把握できます。
どこにあるファイルを、どのように読むべきかを知り、実際に使える値(とその調べ方)を知るLTです。
※ 2025年5月3日に実行すると、全て同じ値になります
<?php
strtotime('today');
strtotime('midnight');
strtotime('noon - 12 hours');
strtotime('3 days ago 00:00:00 + 72 hour');
strtotime('Sat.');
strtotime('00:00:00');
strtotime('00:00');
strtotime('2025-05-03');
strtotime('05/03/25');
strtotime('2025-W18-6');
strtotime('2025.123');
型定義が不完全、変更の副作用も予想しきれない、リファクタしたいけどリスクが読めない――そんなレガシーなPHPモノリスと日々向き合う中で、私たちのチームでは本番環境でユーザーに影響なく検証ができる「シャドーテスト」というお作法を実践しています。
このLTでは、
本番と同じリクエスト・入力を使って新旧ロジックを同時に実行し、
結果の差分を検証する
というアプローチを紹介します。
「テストコードは書きづらい」「型がないから静的検証も弱い」そんな環境でも、実行して確かめることで安全にリファクタや置き換えが進められます。実際にどのように組み込んでいるか、実施してどういうところが良かったか、5分でさくっと共有します。
レガシーPHPと戦う皆さんの一助になれば幸いです!
プログラミングはテキストの海。書けても読めない単語は意外と多く、チーム内でも呼び方がまちまち──そんなモヤモヤはありませんか?
もうこの場で決めてしまいましょう。明日からは自信を持って口に出せますよ。
対象者
PHP に限らず、コードの読み上げや口頭レビューで「あれ、どう読むんだっけ?」と一度でも戸惑ったことのある開発者すべて。
スナップショットテストは、複雑な出力の変化を検知するための便利な手法で、主にフロントエンド領域で発展してきました。近年では PHP においても導入されるケースが増えてきました。
しかし、テストの削除やリネーム、アサーションの回数の変化などにより、使われなくなったスナップショットファイルがリポジトリに残り続けてしまうという問題があります。これらの不要ファイルは徐々に蓄積し、リポジトリを散らかすだけでなく、レビュー時の混乱や誤認、さらには技術的負債や開発者のミスの温床となる可能性もあります。
この問題は長年にわたり認識されているにも関わらず、未だ決定的な解決策が存在しません。大規模なモノレポ環境で複数言語や複数スナップショットライブラリが併存し、独自のカスタマイズも加わっている状況では、汎用的な解法を構築するのは特に困難です。
この LT では、そうした課題に対し、使われなかったスナップショットを自動的に検出し、現実的でシンプルな解決策を提案します。
MCP(Model Context Protocol)の仕様が 2025/03/26 に更新され、MCP サーバをステートレスな HTTP サーバとして実装可能になりました。
そうなったら我々 PHPer のフィールドですね?
本トークでは MCP サーバの仕様を説明しながら、フレームワークも Composer さえも使わない、非常に小さな PHP 実装例を紹介します。
LLM、生成 AI、 MCP といったものに関する
「パフォーマンス調査をしたら凄まじい数のクエリが発行されていた」という経験、ありませんか?
私自身、重いバッチの調査でRDSのPerformance Insightsを見てひっくり返ったことがあります。
これが有名な「N+1問題」ですが、バッチやCSV出力といった大きめのデータ処理で陥りやすい問題の代表例かと思います。
その一因として、Laravel標準のORMであるEloquentでは、リレーション取得をループすることで意図せず大量のクエリが発行されてしまうことが挙げられます。
一方で対策は比較的簡単で、withメソッドを使用してEagerロードさせることで、リレーションデータも1回のクエリで取得することができます。
しかし、安易に「親データの取得時にwithメソッドを呼び出せば解決」と考えていると、思わぬ罠に嵌まる可能性があります。
本LTでは私の失敗を出発点として、Eagerロードさせる上での注意点からEloquentのリレーションの仕組みまでお話しします。
PHPに出会ってまもなく遭遇した奇妙なコード「$$」
まるで変数名が意思を持ち、少し不思議な動きを見せるその子は可変変数と呼ばれます。
本LTでは、可変変数について「変数名が踊り出す」とは一体どういうことなのか、PHP初心者の目線で簡単な例を通して、その基本的な仕組みを紐解きます。
便利な機能にも落とし穴はつきものです。可変変数を使うと、なぜコードが分かりにくくなってしまうのか、本当に使い所はないのか?について発表します!
対象者
・PHP初心者
・変数という概念は理解しているが、可変変数についてはまだ知らない方
・可変変数の使い所がわからない方
私は今、受託開発の会社に勤めていますが、受託開発だと複数案件に関わることはあるあるだと思います。
ただ、参画したタイミングや状況により様々なポジションや開発言語で案件をかけもつことがあります。
時にはマネージャーとして管理を行い、時にはメンバーとして開発を行う。イレギュラーな事態は毎日発生し、考えていた進捗まで中々届かない。。
このLTはそんな中で自身を管理しつつ各案件をなるべく燃やさずに進めている方法をお話します。
型エラーや未定義変数のアクセスなど、実行前にコードの問題を発見できる静的解析ツールは、モダンPHP開発の必須ツールとなっています。本LTでは、Laravel向け静的解析ツール「Larastan」の導入から実践的な活用方法までを5分間で簡潔に解説します。Eloquentモデルやファサードなど、Laravel特有の型安全性課題に対する解決策を中心に、明日から使える実践的なテクニックをお伝えします。
DB負荷問題に直面した時、インデックス、クエリチューニング、キャッシュ… 私たちは反射的に技術的な解決策を探しがちです。
しかし、本LTでは「ちょっと待ってください!その負荷、本当に技術だけで解決すべき問題ですか?」と問いかけます。
私たちがアプリのタイムライン機能で経験した、深刻なDB負荷との戦い。
そこで見出したのは、技術的な複雑化に頼るのではなく、「仕様そのものを見直す」という、シンプルかつ強力な解決策でした。
本トークでは以下の内容をお話します
対象者:
DB負荷対策の引き出しに、技術的アプローチと並ぶ選択肢として「仕様変更」を加えることの有効性を、具体的な事例と共にご紹介します。
あなたのPHPコードはif文の中にたくさんの条件を連ねて条件分岐していませんか?
可読性の下がりがちな条件分岐、実はもっと読みやすく・テストしやすくすることができるんです!
Specificationパターンを使ったリファクタの実例をライトニングに紹介します。
ある日突然、職場でWebアプリを作ることになりました。
最大の問題は、私にはWebアプリの開発経験がなかったことです。
そこで、完璧を目指すのではなく、まずは60点のWebアプリを目指すことにしました。
その結果、ほぼ知識ゼロの状態から小さなWebアプリを開発し、無事にリリースすることができました。
この経験を通じて、知識ゼロから実装に挑む方々に向けたポイントをいくつかお伝えします。
Webプログラミングに欠かせない「正規表現」。でも、なんとなく 「怖い」「よくわからない」 と思っていませんか?
本セッションでは、業務で出そうな易しめの問題から、書いたら地雷なアンチパターン問題まで、全5問のクイズ形式で楽しく学びます!
動機:
https://zenn.dev/shundeveloper/articles/e6405c323c555a
) やライブラリなど対象者:
参照:
カンファレンスで今まで知らなかったことやテクニックを学ぶことは多いと思います。その中には下記を感じることはありませんか?
私自身も最初は上記のことがあり、カンファレンスに行く必要があるのだろうかと悩んだ時がありました。
カンファレンスに行き初めて3年と短くはありますが、知識から経験にするために、大事にしている考えを共有できればと思います。
皆さんは、インプットだけでなく、記事を書いたり、LTをしたりといったアウトプットをしていますか?僕は、1年前Qiitaに記事を投稿し始めるまではほとんどアウトプットをしていませんでした。
そんな僕が、去年の2月からQiitaに毎日記事を投稿し始め、約1年でなんと160記事を公開しました。
テーマは主にPHPやReactなど、日々の学びや実践で得た知見です。
「アウトプット経験ゼロ」からスタートした僕が、どのようにして投稿を続け、何を得たのかについてお話しします。
お話しする内容:
• どんな内容の記事を書いたのか(例:PHPのTipsなど)
• 毎日投稿して感じたメリット(知識の定着、反応がもらえる楽しさなど)
• デメリットや大変だったこと(ネタ切れ、モチベ維持など)
• 投稿を通して得られた成長
• やってみて感じた素直な感想
アウトプットって実際どうなの?毎日投稿ってどうやるの?といった疑問に、僕なりの答えを届けられたらと思います。
「自分も何か書いてみようかな」と思ってもらえるきっかけになれば嬉しいです!
私は数年前からPHPカンファレンスに参加しはじめ、当日スタッフや実行委員を経験し、毎年のPHPカンファレンスが楽しみです!
先日登壇したPHPerKaigiも最高でした!
この二件以外のカンファレンスには行けてないですが、PHPカンファレンスは各地で開催されています。
ぜひ皆さんに魅力を伝えたいです!そして願わくば一緒にスタッフや登壇をしましょう!
という布教活動です。
皆さん、「Laravelインターフェースの恩恵」を受けた!と感じたご経験はありますでしょうか?
自分はエンジニア歴3年で入社当初から、先輩エンジニアの方々から「インターフェースのありがたみ、いつかわかる日が来るよ!」「3年後かな〜5年後かな〜そのタイミングが来る時がある!」と教育して頂いてきました!
まだまだ自分自身、本当の意味での「恩恵」を感じられたか。と言うとまだまだですが
今回、3年程Laravel開発を経験した自分が感じた、「インターフェースのありがたみ」をご紹介出来たらと思います!
新人エンジニアの教育をされる方、またこれからエンジニアとして技術と向き合われる方皆様に少しでも有益なセッションになれれば幸いです!