みなさん、PHPを初めて学んだ時に感じた「？」を覚えていますか？

私の所属する開発チームでは、PHPマニュアルの精読を始めました。
精読してみて改めて感じたPHP独自の魅力について、皆さんに共有したいと思います。
このセッションでは、PHPの特殊な機能、他のプログラミング言語との比較、その機能ができた背景について、私なりに調べた結果や考察を発表します。

対象者:

• 他のプログラミング言語からPHPに転向を考えているエンジニア
• PHPの良さを知りたいエンジニア

「遅いのを早くしたい！」って思うじゃないですか。
そんな時に、「phperでも並列処理したい！！」と叫びます。

ある時、easy-coding-standardのREADMEを見ていたら、こんな文章を見つけました。

Acknowledgment
The parallel run is heavily inspired by phpstan/phpstan-src by Ondřej Mirtes. Thank you.

なんと！あの素敵なプロダクトも、PHPStanの実装に触発されて参考にして、並列処理を実装している！？
・・・つまり、phperにとって「あの処理を並列パワーでどう早くするのか」の野望を叶えるヒントが、そこにある！！！

そうと分かれば、飛びついてみたくなるのが性ってやつです。
PHPStanのパワーの源を、読んで・試してみました！

こんな話

• PHPStanの並列処理、どんな風に動いているのか(利用者目線)
• どのように実装して、実現しているのかな
  • ReactPHPの利用プロダクトとしてのPHPStan
• 実装したら、テストはどんな感じに書いているんだろう？

「テストがないコードはレガシーコードだ！」
Webアプリ開発において、PHPUnitなどでテストコードが書かれることは一般的になりました。

ですが、テスト完走までにかかる時間は適切でしょうか？
テストにかかる時間は生産性に直接的な影響を及ぼす重要な要素です。早ければ早いほど良い。
本トークでは、PHPUnitで書かれているテストを高速化するテクニックについてお話します。

対象観客

• 開発生産性を上げたいと思われている方
• テストの実行時間が長くてキレそうな方

お話すること

• 「phpunit-speedtrap」プラグインを使って遅いテストを検出する
• Googleが提唱する「Test Sizes」を取り入れて、テスト対象をCIとローカルで変えるテスト戦略
• makeやparatestを使ったテスト実行の並列化
• (Laravelの場合) DatabaseMigrations Traitは遅いので出来るだけ使わないほうが良い
• テスト時でもOPcacheは効くのか

php-srcのIssueの中に、「マルチバイト対応のtrim関数を作ってくれないか」という機能要望(Feature request)がありました。
しかし、様々な事情で長らく膠着状態だったため、ぼくがpingをしてみたところ「自分で作っちゃえば？（意訳）」と返事が来ました。
そうと決まれば実装するのみです。
PoCとRFCを記述し、RFCの投票によって、mb_trim, mb_ltrim, mb_rtrimの3つの関数はPHP 8.4（多分）で入ることになりました。
本トークでは、これら3つの関数の使い所と、どうやって実装したのか、RFCの書き方などを共有したいと思います。

だいぶ市民権を得てきたフリーランスという働き方。
Web開発者界隈でも人気のキャリアになりつつあると感じます。

本トークでは2019年にフリーランスになって4期目を迎え、酸いも甘いも経験してきたわたくしがフリーランスのWebエンジニアとして働くということのメリット・デメリット、理想と現実についてお話します。

想定観客

• Webエンジニアとしてのキャリアに悩まれている方
• フリーランスという働き方に関心がある方
• フリーランスになるか迷っている方

お話しすること

• そもそもフリーランスとは何なのか
• 正社員との働き方の違い
• 理想と現実
• どういう人がフリーランスに向いている、向いてないのか
• どうやって仕事を取るか
• いつまでフリーランスとして働けるのか
• みんな大好きお金の話
• 住宅ローン組める組めない話

その他

かいつまんだものをテテミートLT会でお話しました。
https://speakerdeck.com/pinkumohikan/about-freelance-web-engineer-for-tetemeet-vol4

私も含め知っている中小企業で働くエンジニアは、経験年数が2 ~ 3年を超えてくると役職としてリーダーとなることが多いです。

私はリーダーとなった1年間は、自分以外のプロダクトに関係する人のことを考える機会が増えました。
その中で、多くの細かい失敗もしました。

しかし、心理学を知っていくことで、これらの失敗の原因もより違う観点で見え、再現性を持った失敗を少なくする考え方ができました。
それら実例を交えながら解説し、心理学を身近に感じてもらえたらと思っています。

日々会社で開発していると、こういうことよく起きませんか？

• 設計方針を固めたけど、気づいたら乗っ取っていない
• 確認を投げたけど、返信が遅い
• 業務時間に良い方法を思いつかなかったけど、散歩中に良い案を思いついた

こういうあるあるは、自分だけに起きるのではなく、色んな人が経験しています。
つまり脳や心の働きとして、そういう行動をとってしまう傾向があるとも言えます。

それらの現象を心理学から学び得ることで、日々の開発体験に活かしてもらえたらと考えています。

ライブラリの管理やクラスのオートローディングはどのようにされていますでしょうか？
多くの現場ではComposerを使ってライブラリの管理やクラスのオートローディングを行っていると思います。
しかし、レガシーシステムではComposerを使っていないという現場も存在するのではないでしょうか？
レガシーシステムにComposerを導入した際の課題と効果について紹介します。

・Composerを導入するメリット
・Composerのオートロード機能の紹介
・レガシーシステムにComposerを導入するためのTips
・独特な開発環境による課題
・導入後から半年の効果と課題

すでにComposerを導入している方も、Composerの仕様をより知ることでより効率的にComposerを使えるようになるかと思います。

私は自社で開発運用している「はたらこねっと」というサービスの開発を行っております。
私が所属しているチームでは新機能の開発、ABテストの実装、バグや不具合の修正など、日々様々な開発業務を行っています。
そんなチームで開発者である私がサービスのSLI/SLOを策定してみてどう思ったかを語らせていただきます。

開発者がサービスの信頼性について考えることで得られる新たな視点とサービスに対する考え方の変化や、策定にあたってのビジネスサイドとのコミュニケーションと策定時に意識した要点についても併せてお伝えします。

本トークを聞いていただくことで、"開発者が"サービスの信頼性について考える重要性やメリットについて認識していただけると思っております！

わたしのチームでは、KPTをベースとしたふりかえりを9年以上にわたり実施してきました。
ふりかえりの議題はアプリに記録しているのですが、先日そのふりかえりアプリに登録された議題が1万を越えました。
現在ではふりかえりは職能やサブチームにかかわらず欠かせない活動となっています。

しかし、ふりかえりが定着するまでには苦労もありました。
Problemの登録ばかりで盛り上がりに欠けたり、言い出しっぺに改善の負担が集中するといった問題が発生していました。

本トークでは、1万のふりかえり内容をもとに、チームがどのようにしてKPTベースのふりかえりを定着させ、成長していったのかをご紹介します。

いつも目の前のコードとにらめっこしている皆さん！
「このコードには問題がある(気がする)、どうにかしたい」
・・・そんな風に感じつつも、「効率的にリファクタを実施していくぞ！！」と踏ん切りがついていない、なんて事はありませんか？

そうなるのは、コード自体や環境まで含めて、多種多様な要因があるでしょう。しかも、複合的に絡み合っています。
大きく複雑な問題だからこそ、「解き明かすための最初の一歩」を踏み出す勢いが欠かせません。
定量的なデータによって「ここから手を入れるべきだ」を語れたら、勇気を育めるのではないでしょうか。

このトークでは、ソフトウェア開発を「活動」「成果物」の両面から捉えて、現状を数値で表す指標ってどんなものがあるのかな？を示していきます。

ターゲット

• 「メトリクスベースで、リファクタや品質管理を考えたことがないな」という人
  • 既に実践している人や経験者は対象外
• 「リファクタが必要そうとは感じるが、どこから始めるか判断しあぐねている」人、計画を立てたい人

話すこと

• どのようにリファクタリング戦略を立てるか？
• 眠っている問題の大きさを示す、コード品質に関する指標
• 改善時の効果の大きさを示す、活動量や利用量に関する指標

話さないこと

• 「メンテナビリティやリファクタの価値、どう金額に置き換えるか？」の踏み込んだ話

NotionにはデータベースにCSVでレコードを一括投入するための 「CSV取り込み」 という機能が標準で搭載されています。
が、少なくとも2023年11月現在においては正直だいぶ貧弱な機能で、本当に最低限のことしかできません。
（例えば、インポートできるプロパティの種類が限られている、ページ本文はインポートできない、「名前」カラムの値が重複している行があると正常にインポートできない、など）

そこで最近、必要に迫られてPHPでNotionのデータベースにCSVをおインポートするフォームを自作しました。
このトークでは、このフォームの具体的な実装手順を、デモを交えつつサクッと解説します。

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう優れもので、
Symfonyのエコシステムにおいてはすでに決定版と言える存在となっています。

このトークでは、API Platformの導入方法から、State Provider・カスタムコントローラ・State Processorといった重要な基本機能の概要までを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです！

PHPUnitには、テストの起動〜実行〜終了の様々なタイミングで任意の処理を挟み込める、「Extension」というプラグイン機構があります。
これを利用することで、単体テストの実行やCI運用にまつわる「痒い所」に手が届くかもしれません！

例えば、
「テストが増えてきて、実行に時間がかかる・・・改善をしていきたい」
「テスト実行中にNOTICEが出た時に、処理を挟み込みたい」
「独自のアノテーションやAttributeを扱えるようにしたい」
などなど、細かい需要に向き合える可能性があります！

いざという時に、知っておくとお得かもしれない・・・？
そんなExtensionの仕組みについて、紹介していきます！

はなすこと

• PHPUnitのExtensionの概要
• 例えばどんな機能を提供できるのか、実例
• 簡単なサンプルを用いた開発・利用方法の紹介

昨今、よく分からず不用意にGitHubのパブリックリポジトリに上げてしまうなどの、コードの流出事故が問題になっています。
またChatGPTやGitHub Copilotなど、ソースコードを読み込んで学習し自動でコードを生成してくれる技術も進歩がめざましいです。

コード上に秘匿情報を持つべきではありません。
万が一流出した時にリスクになります。
ChatGPTなどに不用意に打ち込んでしまうとそれを学習し外部に漏れるリスクとなります。

そんな問題をgitleaksを使って解消しましょう！

• gitleaksの使い方
• どんなことができるか
• 実際に活用した例

本セッションではこのような内容のトークを予定しています！

皆さんは、PHPの file_get_contents() 関数をご存知でしょうか？
とっても便利な関数です！
これを利用すると、file(ファイルでなくても可)をget(POST等でもOK)してcontents(つまり全て)を取得する事ができます。

$contents = file_get_contents('https://exmaple.com');

これだけで、インターネットからデータを取ってこれるのです！
「1発で何でも出来る」という感じが、最高にPHPっぽいなと感じます。
その一方で、あらゆるリソースにたった1つのコマンドでアクセス出来る世界観は、everything-is-a-fileの原則に則ったUnix哲学的な価値観も感じるところです。

このとっても便利な関数について、門を開いてみませんか？

話すこと

• file_get_contentsを使ってみよう
• file_get_contentsは何をしてくれるのか・何をしないのか
• file_get_contentsとPHPらしさ、Unixっぽさ
• file_get_contentsでサーバーを立てよう (※ 実装イメージ )

PHPUnitのメジャーバージョンアップ、9.xから10.0の移行には「大きな変更が含まれている」という印象を持っている人も多そうです。
とりわけ、PHPUnit\Framework\TestCase::at() や PHPUnit\Framework\MockObject\Rule\ConsecutiveParameters() のdeprecatedについては、移行に際して不安を感じる声もチラホラと耳にします。
ここでの頭痛の種は、「今まで使ってきたテストコードを、どう置き換えればいいか」というものです。
フレームワークのAPI的な意味での「使えなくなる」ではなく、テストの意図と実現方法の見直しを促すという意味で、本当にBraaking Changeと言えます。

PHPUnitは、これまでも「利用者に適切なテストコードを書くことを促す」ように進化をしてきました。
では、 at() withConsecutive() のない世界が来ることで、我々は何を得られるのでしょう？
この変更をきっかけとして、「どんなテストが良い単体テストなのか」について考察します

伝えたいこと

• 良いテストの価値: 寿命、偽陽性/偽陰性、理解容易性
• テストコードとプロダクトコードの「疎結合」を意識する、実践する