私のキャリアの直近3~4年は、東京のエンジニア採用に加え、地方のエンジニア採用をしてきました。
採用活動を通じて、地方のエンジニアが現地に根を張り、活躍することに非常に大切な意味があると思っています。
特にリモート普及後、「フルリモート」「現地の企業」「地方拠点」など、企業の選択肢も格段に増えてきました。

■話をしたいと思っていること
・関東と地方のキャリアの違い
・リモート普及後の地方のエンジニアの変化
　・どのような活躍の仕方があるか
　・逆にどのような問題がおきているか
　・技術コミュニティの在り方の変化
・リモート時代の地方のエンジニアの存在意義
　・地方でエンジニアが活躍することにどのような存在意義や価値があるのか

日本社会は、労働力減少や少子高齢化など直面している問題が山積みで、関東一極型の働き方は難しくなっています。
福岡であったり、それ以外の地域でのエンジ二アが活躍・活動する場所が増えていったり、居住地を含めた柔軟な働き方は今後ますます必要になっていくため、地方でキャリアの挑戦をしたいと考えている人の後押しになる発表を目指していきたいと思います。

私自身の経験を通じて、地方のエンジニアの活躍・地域ITコミュティの重要性についてお話したいと思います。

PHPのフレームワークやライブラリを作成する人に向けて、「みんながこういうノリで実装してくれたら嬉しいな」を形にした「PSR」と呼ばれる取り決めがあります。

https://www.php-fig.org/psr/psr-14/

「PSR-4(オートローディングに関する規約)」「PSR-7(HTTPメッセージの取り扱い表現方法に関する規約)」「PSR-12/PER Coding Style(コードのスタイルに関する規約)」などは、耳にしたことがある人も多いのではないでしょうか。

そんなPSRの中に、「PSR-14: Event Dispatcher」があります。イベントやその発行・購読についての規約です。
この14番は、どちらかというと知られていない部類のような気もしています！

このセッションで、改めてスポットライトを当ててみましょう。
「PSR-14とはどういうもので、リアルワールドにおいてはどのような実装があるのか」について知ってみませんか？

話すこと

• PSR-14は何を狙ったものなのか
  • この取り決めが議論され形になった背景には、どのようなプログラミング上の課題があったのか。何を解決するものなのか
  • = 「Observerパターンとどう付き合うか」みたいな話
• PSR-14を用いた実装例(ライブラリ)を覗いてみる

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

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

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

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

本トークの想定聴衆

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

本トークのねらい

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

免責

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

みんな大好きWordPress！世界のWebサイトの4割以上と圧倒的シェアを誇る皆様御存知のPHP製超有名CMS！
そんなCMSで作られたWebサイトのインフラをリプレースする機会に恵まれたので、イキって「時代はコンテナ！冪等性こそ至高！」とEC2からFargateに載せ替えようとしたら大失敗？！

今回のトークでは上記のEC2からFargateへのリプレースプロジェクトにおいて得られた知見を共有させて頂きます。

お話すること

• 実際に行った移行手順
• ハマったポイントとその解決策
• リプレースしてみた感想

PHPのビルトインウェブサーバーを使ったことはありますか？
Laravelユーザーの方ならお馴染みの「php artisan serve」というコマンドで使用しているかもしれません。

実際HerokuやAWS ECSのLaravelデプロイ時に「php artisan serve」を使用する例もちらほら見受けられますし、公式サイトでもこのようなサンプルが紹介されています。

しかしながら、php公式がビルトインウェブサーバーを本番環境で使用することを禁止しています。
https://www.php.net/manual/ja/features.commandline.webserver.php

実際にビルトインウェブサーバーを使用した経験に基づいて、その弊害についてお話ししながら、ビルトインウェブサーバーの注意点をまとめてみました。

見知らぬコード、深いスタック、多様なクラスやメソッド・・・・
それらに立ち向かうのは、楽しくもあり大変でもあることですね！頭がパンクしちゃうこともしばしば！

どうしたら、少しでも効率よく・安心しながらコードリーディングを進められるでしょう。
ポイントは、「要点を掴む(=肝心でない所は脳みそからflushする)」「振り回されない(=コードを行ったり来たりしやすくする)」事だと思います。
それを実践するためのツールや技法を用意できると良いですよね。

脳内で補いきれない所は、「道具」で補って賢くやりましょう。
Xdebugのステップ実行と、ホワイトボードツール(Miro)の付箋とメモを活用することで、とっても効果的にコードの理解を進めることができます！

ある程度複雑なライブラリを例に、実際に「どうやったのか」をお見せします。

「翻訳してほしい技術書」あるいは「鈍器」として名高い、xUnit Test Patternsという書籍があります。
読んだことはありますでしょうか？あるいは、「名前は聞いたことあるけど・・」という方も、非常に多いと思います。

「興味があるし、役に立つとは確信しているのに、読んで見るに至っていない」
それは何故なのでしょう？要因の1つとして、 あなたの興味が足りないから という不都合な事実はありませんか！！

このトークでは、「どんな事が書かれているのか」を、時間が許す限り紹介していきます。
物量も情報量も多い書籍なので、興味を持っても「全部読む」のハードルは引き続き高いかも知れません。
それでも、「どんな事が分かる本なのか、自分の求めるヒントになりそうなのか」「どういう風に、読んでいけな良いのか」の解像度が上がってしまえば、きっと手にとってみたくなりますよね・・！
「45分」枠のうち、自己紹介やまとめの時間を除いて「40分」でxUTPアトラクトを目指していきます。

このトークのねらい

• 聴いている人の中にある、ユニットテストに対する”怖さ”を少しでも取り除く
• チームの「ユニットテスト力」を高めるための形式知をインストールする。あるいは、インストールの仕方(引き出し)を増やす

話すこと

• xUTPの全貌
• どんな事が書かれていて、どんな時に/どんな人に役に立つか
• どんな風に使っていけば良さそうか

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 でどのようにすれば省エネにメモリを使えるか、書き方のヒントまで含めてお話できればと思います。