ChatGPTやGitHub Copilot Xなど、今年に入ってさらに熱くなってきたAI業界。
今年からGitHub Copilotを使い、AIと一緒にプログラムを書いていますが、私たちの仕事にも大きな変化が訪れる気配を感じます。

今セッションでは、PhpStormとGitHub Copilotを使ったライブコーディングを行いながら、AIと協働するメリットや気をつけるべき点などをご紹介します。

超強力な統合開発環境 PhpStorm
今や多くの PHPer にとって無くてはならないエディタでありIDEであることに疑いはありません
多機能であるがゆえ、「えっ、何そんな便利機能があるの？知らんかった！」がまれによく発生します

PhpStorm を使い始めてそろそろ12年 (マジかよ) になりますが
まったく使いこなせている気がしません

ライブで「こんな機能あるんだよ」を紹介しますので
おおーなどと反応したり
こんな機能もあるぞーなど紹介(ガヤ)してほしいです

(ショートカットキーの話はしないです)
(PhpStorm を使っていない方はその便利さに圧倒されてください)

2018年のPHPカンファレンス関西で発表した「すばやく実装するための戦略とテクニック」から5年、「速さは力」をモットーに相変わらずスピードを出してコードを書いています。
自分では「長く在籍してドメイン知識がついたせいでは？」と思っていましたが、副業に行っても、転職しても、やはり「プルリクが光速」「レビューが追いつかない」と同僚から褒められたりクレームを言われたりします。
文系ですし、20代半ばで初心者からPHPを始めた身なので、才能があるわけではありません。
速さを実現するために積み重ねている工夫や使っているテクニックを、2023年現在の内容にアップデートしてお伝えします。

マネジメント、「私には無理」とか「億劫だな、やりたくないな」と思っている人も多いでしょうか？
その一方で、組織は何かしらの期待を持って、プログラマーに対して「マネジメント職をやってほしい」と依頼をしてくる事があります。

さて、最近では「マネジメント」というと「1on1をしよう」という話がありませんか。
そして、「1on1」と聞くと「コーチングを〜〜」という単語も、関連して想起されることがあるのではないでしょうか。

では、「1on1」「コーチング」という言葉から、何を思い浮かべますか？
あるいは「良い1on1」「良いコーチング」を自分の言葉で説明できるでしょうか。
私は、プレイヤー→リーダー→マネジメント(8人程度)→マネジメント(15人程度)→ジュニアなマネジメントも対象に含むマネジメント(35人程度)と、職務上の役割がシフトしてきました。
それに備えて、パーソナルコーチングのトレーニングを受けたり、組織開発や臨床心理学の領域に近いような学習も進めています。

そんな経験の中で、個人的には「コーチングのマインドやスキルを知ることで、良かった・明らかに役に立っている」と感じています。
本トークでは、主観的な経験を踏まえて「なぜ、どうやって、どうして役に立ったのか」をシェアしていきます

本トークの想定聴衆

• マネジメント職を担う(これから取り組む)上で、人と向き合う「難しさ」を感じている人
• コーチングという言葉は知っているが、それが何をもたらすのか・どういった概念なのかを知らない・興味がある人
• メンティーの立場から「効果的な1on1を実施できていない」と感じている人

本トークのねらい

• マネジメント(する側・される側)における、「幅」を増やして、苦しさや辛さを少し軽減する
• いち個人と向き合って、その人のエネルギーを充実させることの楽しさを知ってもらう

免責

• 発表者はコーチングのトレーナーとしての訓練を受けているわけではなく、プロとしてコーチ業を提供している訳ではありません
  • そのため、本セッションは「コーチングのやり方」を提供する事は目的としません

Composer大好きな皆さん、その愛をもっと強い形でぶつけてみたいな〜と思ったことはありませんか？
好きなものを自分のものにするには、やはり作ってみるのが1番ですよね。
既に高い完成度で存在しているComposerを、コレを機にわざわざバラバラにして再発明してみましょう！

このトークのねらい

• Composer内部の主要な概念/実装についての解釈を進めて、理解を深める
• それによって普段使っているツールの気持ちをちょっと理解する

このトークで得られるもの

• (Packagist等のリモートや、ローカルファイルなどの)レポジトリ情報・パッケージ情報の内容を理解できる
• それらを扱うためのプログラムとしてのComposerの仕組みを理解できる
• PHPのautoloaderの設定方法について理解できる

やること

• composer install や composer dumpautoload の「端折った」実装を行い、解説します
• そのために前提知識として必要な概念の解説をします
  • Composerのレポジトリ
  • Composerのパッケージ
  • PHPのオートロード
  • PSR-4

PHPアプリケーションのコード品質を上げて、メンテナンス性をあげて、寿命を伸ばすためによく使われるようになったphpstan。
皆さんのプロジェクトのphpstanのlevelはいくつですか？baselineは解消できていますか？
SymfonyやLaravelで作ったアプリケーションに対してlevel:maxを設定してbaselineなし・エラーなしにした経験から、コードを書くときに気をつけること＆phpstanを納得させるテクニックをお伝えします。

PHP の pcntl 関数を使おうと思っても，使い方が難しそうに感じるという方は，結構いらっしゃるのではないでしょうか。
ちなみに，pcntl はプロセスコントロールと読みます。pnctl 関数を使えば並列/並行に何かしらの処理を非同期でできるようになります。
また，pcntl 関数に近いもので posix 関数もあります。本トークではこれらの使い方の説明や，それに関連する周辺知識から，どういったケースで利用できるかなど，幅広くお話できればと思います。

みなさんは，PHP で電卓を作ろうとしたとき，どのような実装を思い浮かべるでしょうか。正規表現で式を分解したり，そのまま eval に突っ込んだり…と，様々な方法があるかなと思います。電卓を作るからには「4 × √ ((5! + 2^8) - (4! + 2^8))」のような複雑な式を計算したいと考えるはずです。
そこで，本トークでは，数式をトークンごとに分割し，トークンそれぞれに意味を持たせるために抽象構文木と呼ばれる形に変換して，実際に計算をさせるまでお話します。また，時間があればデモも行います。

アクセスカウンターといえばインターネット黎明期に流行ったコンテンツの一つですね。アクセスカウンターは，ウェブサイトにアクセスしてきたクライアントをカウントしていくものです。番号がゾロ目であったり，キリのいい数字になると「キリ番」と呼んだりしていました。
実は PHP だけでアクセスカウンターを本気で実装しようとすると考慮しなければいけないことがあります。例えば同時アクセスがあった場合に，数字を保持しているファイルが破損してしまったりしないように，悲観的ロックや楽観的ロックといった技術が必要になってきます。
本トークでは，本気のアクセスカウンターを作るにはどのような実装とすべきか，またそれに付随する周辺知識などをお話できればと思います。

フレームワークや独自実装を用いて、ファイルのアップロードを対応しているプロダクトも多いのではないでしょうか。
実は私は、画像や音楽ファイルを含めたファイルのアップロードが、おそらくプロダクト開発をする上で苦手だなと感じることが多々あります。
「$_FILES を参照するだけでいいじゃん」そう思う人もいると思います。しかし、ファイルのアップロードというのは、より気を使わなければいけないことが多々あります。拡張子だけで、特定のファイル、例えば image.jpg というファイルの中身が png で送られている場合などもあり得ます。これはまだかわいいレベルです。そしてこれよりも悪質なものをアップロードされてくる場合もあり得ます。
以前、PHP を用いたファイルアップローダーサービスを一時的に運営しておりましたが、実装の際に、気をつけていた脆弱性や攻撃などを、フレームワークや独自実装において気をつけるべきアップロードされたファイルへの対応についてお話できればと思います。

Laravel sail を使っている方なら、一回は目にしたことがある Mailhog。他にも MailCatcher といったローカルでメール送信のテストをすることがあるのではないかと思います。
実際にこういった SMTP サーバーの役割を果たすものは使ったことがあるものの、どういう仕組みでメールのやり取りがなされているのか
興味がある方もいらっしゃるかと思います。
そこで、本トークでは SMTP サーバーとしてのプロトコルの解説から、PHP だけで SMTP サーバーを作るにはどうしたらよいのか、テクニックも含めて解説します。

ほぼエンジニアがいない状態からある程度の人数までスケールした組織で、コードの変化や Developer Experience がどのように
変化したのか、時系列で語られることはそうそう多くないです。採用から始まり、プロダクトを作っていく過程で、避けて通れないのが組織の成長です。
少ない人数では上手く機能していたのに、エンジニアが増えた途端、組織が機能しなくなったという話もよく耳にします。
そこで本トークでは、組織規模が大きくなるにつれて、実践した Developer Experience への取り組み、取り組んだ結果、どのように PHP で書かれたプロダクトに影響が及ぼされたのか、ノンフィクションでお話します。

PHP 8.1 から Fibers が導入されました。それ以前の非同期処理といえば、Swoole などが筆頭になっていました。
非同期処理ライブラリが PHP にビルトインされるのは PHP に革命をもたらしたと言っても過言ではありません。
しかし、Fibers ではできないこと、Swoole でできることなど、実際には分かれています。
そこで、Fibers と Swoole の違いはなにか、それぞれの使い方を広く浅く本トークで解説します。

PHP に FFI が導入されてから、どういう用途で使えばよいか悩んでいる PHPer も多いかと思います。
PHP FFI を介したモジュールの呼び出し方から、自作 の C/C++ のモジュールの作成から呼び出し方、
そして libusb と呼ばれるモジュールで USB で接続された機器の一覧を取得する方法など、どのように FFI を活用していけばよいのかを本トークで解説します。

重たい処理をキューに任せることで、早めにレスポンスを返すことが可能です。しかし、Laravel 標準のキューサーバーの処理速度にはある一定の限界があります。
弊社では、1 回あたり数十秒かかるような処理をキューに任せているのですが、キューが積まれすぎて処理しきれず破棄されるといった事象が起こっていました。
Laravel には Laravel Horizon と呼ばれる並行並列でキューを処理ができるライブラリがあるのですが Redis のみのサポートで、弊社では Amazon SQS を使用しているため、導入には至りませんでした。そこで、Amazon SQS 向けに Laravel のキューサーバーを自前で実装し直し、処理速度を 4 倍に向上させました。
どのように処理速度を高めるのか、そのテクニックのご紹介と実際のプロダクションへの投入、得られたパフォーマンスなどを本トークでお話します。

何度も遭遇する PHP の「Allowed memory size of ...」。しかし、結局解決方法がわからず、最後には「ini_set('memory_limit', -1)」でその場を凌ぐという苦い経験をした方も多いのではないでしょうか。
PHP ではガベージコレクションもそれなりに発達しており、メモリを気にしないで書けるから良いと思っている人も少なからずいらっしゃると思います。
しかし、裏を返すと、メモリについてあまり考える機会がないとも言えます。PHP7.4 から弱参照といった機能も入り、メモリ管理に少しずつ関心が寄せられてきているのではないかなと思います。
そこで本トークでは、PHP でどのようにすれば省エネにメモリを使えるか、書き方のヒントまで含めてお話できればと思います。