エヴァンゲリオンとPHPに意外なつながりがあった！
そんな話をします。

https://speakerdeck.com/sapi_kawahara/php-with-high-synchronization-rate-with-evangelion
これのリニューアル版です。

phpstan/phpstan-strict-rules というパッケージがあります。
これは、PHPStanに「より厳しい」規約を追加しちゃうよ！！！というものです。

コーディング規約の理想は「良いコード(とチーム開発)」の実現であり、その中には「断言的であること」「記述がコンパクトであること」などなどが含まれていると思います。
これは「不吉な臭い」を避けるtips集としての効果もあります。

開発者が不吉な臭いを発するのを避けたい・・・そうした方向性の進化は、PHP自体も歩んでいるところです！

「良いコード」を標榜するチームのためのphpstan-strict-rulesと、「PHP7の後半や8で出来るようになったこと」を一緒に眺めてみましょう。
今っぽいPHPでの「当たり前」を見出したり、「PHPって便利になったね！」という喜びを分かち合いましょう。

PHP歴だけは長いぼくが Laravel よくわからないので避けようとしたものの
結局 Laravel を使うことにしました
その結果 Laravel の乗り方がようやくわかりました

アーキテクチャ(設計) というほど高尚なものではありませんが
フレームワークの利便性とアプリケーションコードの適切な分離を思いついたので話したいと思います

平たくいえば
「ぼくのかんがえたさいこうのLaravelのつかいかた」
です

多くの Web アプリケーションでは一度開発したらそのまま運用を続けていくことはなく、変更や追加開発を続けていくことになります。
変更は避けられないものでありますが、無秩序に変更を続けていくと複雑度が増し、変更するのがより困難になっています。
変更したら思いも寄らない箇所に影響があって冷や汗をかいた経験がある方も多いでしょう。

本セッションではこの変更容易性に着目して、設計や実装において変更容易性を高めるための手法を考えていきます。

初めて作られた時にはピカピカと輝いていたソフトウェアも、時が経つにつれて「劣化」していきます。
うまく使われれば機能は増えていきます。コード量も育っていきます。そこが問題です。
増殖していくコードたちを、誰が・いつ”良く”するのか。

実行するには、組織内にマインドとスキルの両方が必要です。
それらを育むには、どこから取り組んでいけば良いでしょうか？
本セッションは、「なぜソフトウェアが『劣化』するのか」「それを解消するためにどんな事を狙っていくか」と、そこから演繹して「自分自身の取り組んでみたこと」を紹介します。

まだまだ取り組みの最中なので、必ずしも「成果」をベースに語れるものではありませんが、何かしらのヒントになれば幸いです。
また、オーディエンスの皆さんからのフィードバックをもらったり、そこから更に踏み込んだ議論が生まれていくことを期待しています。

紹介するお話

例えば、以下のような取り組みが「自分なりに考えたこと」でした。

• 「技術力」を定義する
• プロダクトと技術力の関係
• 自分自身が「技術的な成長」を感じた瞬間を構造化して捉える
• その「良いフィードバックの獲得の仕方」を組織的に再現できないか？

こうした話を「議論のネタ」として提供したいと考えています。

この課題を選んだ背景

プロダクト開発や(Web)サービスの提供を行う会社において、
Webエンジニアに求められる主要な成果は「プロダクトを良くする」ことだと思います。
プロダクトをよく出来るエンジニアとは、どういう存在でしょうか？
実は、「プロダクトをよく出来るエンジニア」になるには「プロダクトを開発する以上の技量」が要求されるのではないでしょうか。

ここには大きな矛盾があると考えています。
「プロダクトを良くし続けるには、プロダクトに必要なレベルの技量では足りない」という矛盾です。
これについて、自分自身が、所属先の企業でのロールが変化したのをきっかけに取り組むようになりました。
組織の姿が「プロダクトを作れる」を超えた「プロダクトの未来を作れる」ようになるにはどうすればよいか・・？と現在進行系で考えています。

「早くPHP 8.1を使いたい… でもうちはまだ7.3なんだお…」

PHPの新バージョン8.1の機能は既に確定していますが、PHPは毎年11月末にリリースされるので、あと2ヶ月待たなければいけません。
また、そもそもリリース済みの7.4や8.0の機能を使いたいけれど、自分の一存では上げられない… そんなこともあります。
このLTではそんなときに便利なsymfony/polyfillと、その限界についてお伝えいたします。

型付けしてますか？ PHPで型安全なコードを追求しはじめると、やや取り回しの悪いPHPの標準関数の型に煩わされます。
そのような型には歴史的事情があるのですが、このLTでは標準関数の型の問題を解決するthecodingmachine/safeパッケージについて紹介します。

先進技術を貪欲に取り入れ続ける皆様にとって、PHPとGoを組み合わせた全く新しい (ver1リリースが2017年) FrameworkであるSpiral Frameworkの存在は周知のことかと思います。今回はこのSpiralとそれが採用しているCycleORM利用することで、エンティティの定義からデータベースのテーブル定義を同期させる機能をご紹介いたします。
Laravelなどのような積み上げ式のデータベースマイグレーションを採用している場合、時とともにマイグレーションファイルが増えていき、現在のデータ定義がわかりにくくなっていきます。一方、CycleORMを採用するSpiralでは、エンティティのプロパティ定義を利用して、データベースのテーブル定義との差分を検出し、定義内容を同期する機能が用意されています。この機能を活用することで、積み上げ式のマイグレーションファイルは不要となり、テーブル定義もエンティティのプロパティを見ればわかるようになります。
今時だとLaravelやCakePHPが割と覇権みたいに言われていますが、だからこそ、あえて、このSpiral Frameworkを通して、新しい開発体験をしてみてはいかがでしょうか。

AWS Lambda の新機能としてコンテナイメージのサポートが開始されました！

PHPerがサーバーレスラーになれる！嬉しくてたまりませんね！

じゃあどうすれば良いのか、具体的なデプロイ手順をライトニングなトークでお話します！

デプロイさえ出来ればあとはあなた次第、
めくるめくサーバーレスライフを堪能しましょう！

■想定する聴講者
　- サーバーレスアーキテクチャに興味がある方
　- とにかくPHPをサーバーレスで動かしたい方

■お話しないこと
　- Productionで利用できるようなためになるお話
　- 細かい理論

速いは正義、アプリケーションは速くあるべきです。

ではどうすれば良いのか

細かい理論などは気にしない、こうしたら早くなった

結果を貼り付けながら、何をしたのかひたすら話しますが、細かいことは話しません

OS、Webサーバー、PHP、RDBMS等の見直すべき要素に関して、情報を詰め込むだけ詰め込むことに挑戦します。

※注釈は付けますので細かな理論はそちらでご確認ください

■想定する聴講者
　- PHPWebアプリケーションのパフォーマンスに興味がある方
　- PHPのインフラを整備するエンジニア
　- PHPでISUCONに挑戦する方

■お話しないこと
　- パフォーマンス以外の話
　- アプリケーションコードによる改善
　- 劇的なパフォーマンス改善策

話者はPHPerですが、なんとなく全部出来るからという理由で
渡されるインフラの整備に疲れている時期がありました。

そんな中メンテナンスフリーと言われてきたサーバーレスという技術に興味を持ち
今では全てがAWSのマネージドサービスにて構成されているアプリケーションを作成する術を身に着けました。

それは話者の悩みを全て解決するものではありませんでしたが、
本来解決したかった以上の課題を解決し、初期認識よりも出来る事の幅の広さも感じました。

PHPerがフルサーバーレスアプリケーションを構築出来るまでに至った軌跡をなぞり、
メンテナンス、コスト、疎結合化などのメリットやデメリットについてお話します。

■想定する聴講者
　- サーバーレスアーキテクチャに興味がある方
　- サーバーレスアプリケーションの開発フローに興味がある方
　- サーバーコストを最小化したい方

■お話しないこと
　- PHPを中心としたアーキテクチャ
　- 完全なメンテナンスフリーインフラを手に入れる事

コンテナは便利、開発環境の構築から本番の運用まで様々なメリットがあります。

そんな中Dokcerを使った開発を行っている中で発生する、
パフォーマンス問題などのデメリットが存在するのも事実です。

今回はパフォーマンス、テスト実行まで意識した
Dokcerの開発環境整備について解説したいと思います。

不便な点もあるけど便利だから我慢しているという方に
少しでも快適なDokcerライフを送って頂ける一助になれば幸いです。

■想定する聴講者
　- Dokcerを使って開発しているPHPer
　- CircleCI等を使ってCI/CDを回している方

■お話しないこと
　- ProductionへDeployするためのテクニック
　- Windows、Macにおける細かな違い

皆さんLaravelは使っていますか？私はここ数年Laravelを使ったアプリケーションばかり書いています。
Laravelでの開発を続けていると、やりたいことがドキュメントに載ってない！ということが結構あると思います。しかし、LaravelのIlluminateにはドキュメントに詳しく説明されていないInterfaceやLibraryがあり、これを実装したり継承したりすれば、かゆいところに手が届くということが多々あります。このような例を実例と合わせて複数紹介させていただきます。

「この機能をリリースしたらユーザーって増えるの？」

・・・・・・・・・

「〇〇したら☆☆になる」が100発100中でできる人がいたら申し訳ありませんが、プロダクトづくりにおいてなんらかの問いに対して正解を持っている人はいないように思います。
しかし、「誰も正解をもっていないものをそれでも形にする」ということがプロダクトづくりをはじめ我々の仕事では求められるケースが少なくないと思います。
プロダクトづくりの「不確実性」は日々新しい技術が出現したり、ユーザーが持つ課題が多岐に渡ったり、関わるチームメンバー・ステークホルダーが様々だったりなど様々な要因がそうさせるのではないかなと思います。
そんな中、少しでもプロダクトを前進させるためにできることは仮説を立てその検証をするというプロセスをいかに素早く回していくかというのが大事ではないかと感じています。
さらにそれは自分1人で完結できるものではなく、チームの力が必要です。
現在わたしの現場ではスクラム開発を取り入れプロダクト開発を進めておりますが、よりよいコミュニケーションでよりよいプロダクづくりをチームでするためにやっていること、工夫してみていることを共有させていただきたいと思っています。

普段我々が使っているコンピュータシステムというのは、階層的なシステムです。

物理法則から電気回路が作られ、ハードウェアが作られ、ハードウェアの上で動くファームウェアや OS があって、更にその上で動くアプリケーションがあって、アプリケーションの中でも C 言語で書かれた PHP 処理系、更にその上で動く PHP で書かれたスクリプト、というように、何重もの階層化がされています。
土台になるものから高く階層を積み上げていく、というイメージで、階層の上のほうにある技術を高レイヤー、下のほうにある技術を低レイヤーと呼んだりします。

PHP のスクリプトというのは比較的高レイヤーに属するプログラムなわけですが、PHP コードがコンピュータ上で実際にはどう振る舞っているのか、どういう仕組みでできているのか、というのは、当然より低レイヤーの技術で成り立っています。

今回のセッションでは、そんな PHP より低レイヤーの世界へ FFI を通じて PHP スクリプトからアクセスし、PHP 自身から階層をぶち抜いてスクリプトの動作を下の方から覗き見てみるという、少しひねくれたことをやるツール、php-profiler についてお話します。

雑に言うと、PHP スクリプトによって ELF/DWARF と procfs と ZendEngine の内部構造体をパースしつつ、FFI で外部プロセスのメモリやレジスタ内容を読み取り、gdb などのデバッガと同じようなやり方で、スクリプトの動作を処理系の内部動作レベルから盗み見るお話です。

ある瞬間に PHP プロセスが PHP コードの何行目を実行しているのか、どんな処理系内部のバイトコードを実行しているのか、そしてそのために処理系や拡張モジュールの C 言語コードのどの部分の何行目が実行されているのかを、観察対象の PHP スクリプトへ全く手を入れないままに読み取ります。

みなさんの現場では1on1は行われていますでしょうか？
わたしの現場では2週間に1回の頻度で1on1を行ってきました。
1on1回数を重ねていくごとに、エンジニアリーダー的な立場でメンターとしてメンバーと1on1を行っていた場合は、「この1on1は相手にとって有意義なものになっているのだろうか？わたしの自己満足になっているのでは？」と思うようになったり、逆にわたし自身がメンティーとして上長と1on1する際には「自分にとってはいい1on1になっている気はするけど本当にそうだろうか？上長にとっても期待した1on1になっているだろうか？」と考えモヤモヤしていました。
1on1の実態がお互いに期待している効果を生み出していないとするとそれはとても残念なことであり時間も無駄になってしまいます。
一般的にはチームビルディングやコミュニケーションの促進のために行われる1on1ではないかなと思いますが、現場によっても多少のニュアンスの違いは生まれるでしょう。また、1人1人のメンター・メンティーが1on1に期待することにも違いがあると思います。
そのような期待値の調整をするために1on1のふりかえりを行っているのですが、このセッションではわたしの現場で1on1ふりかえりをどのようにやっているのかを共有させていただきたいと思っています。

トークの概要

Google Cloud Platformの Cloud Run をご存知でしょうか。
Dockerのイメージで起動し、PHPで書いたWEBアプリケーションが直ぐにデプロイされて公開できる便利なサービスです。

デプロイするだけで証明書付きURLが発行されたり、トラフィック量調整によるカナリアリリースができたりと、
ものすごく便利でものすごく強力なのですが、意外に皆さんご存知ではないのでしょうか？
ということで、実際に現場で使っている感想も交えてCloud Runについてお話します。

トーク対象

• サーバレスでサクッとPHPを動かしてAPIを作りたい方
• サーバレスだけど、PHPのバージョンや自分で最新を維持したい方

分野

• Google Cloud Platform
• Cloud Run
• サーバレス

初めての登壇チャレンジです。 よろしくお願いします！

bugs.php.net は PHP の公式 issue トラッカーで、処理系本体と公式バンドル拡張、PECL 拡張をあわせて現在 2000 以上の未解決のバグが登録されています。

古いものでは PHP4 時代のチケットで残っているものもあり、現在サポートされている処理系バージョンにおいてすでに解決済のものや、そもそもバグではないもの、当初は明らかにバグだったとしても 10 年以上その挙動が続いたことで、もはや仕様としてしまった方がよいのではないかと疑われるものなど、色々なチケットがあります。

そんな bugs.php.net の古くからある塩漬けチケットについて、現在サポートされている PHP 7.4 以降でも再現するか、レポート内容が妥当かなどを検証しつつ、修正可能なものについては PR を投げ、修正不可能であったり修正の必要がないものについてはコメントを追加して現在の状況を付記する、という清掃活動に取り組んでみました。

bugs.php.net 自体やチケットの調べ方について紹介しつつ、見つけて面白かったチケット、実際に対応したチケットについてお話します。

日々の業務の中でコードレビューは頻繁にされているでしょうか？
コードレビューは好きでしょうか、それとも嫌いでしょうか？　もしくは、得意でしょうか、苦手でしょうか？

コードレビューはどうしても負担になる作業であり、誰が誰のコードをレビューするかによってその負担量も大幅に変わってきます。
また、レビューによって見つけた問題点をどうやって指摘するかによって、今後のコミュニケーションに影響を与える可能性があると言っても大げさではありません。
私自身コードレビューは好きという変わったタイプではあるのですが、細かい指示ばかりで本質を見失ってしまったり、指摘の仕方を間違ってしまったと後悔したり、レビューを妥協して良くないコードを世に放ってひやひやしたり、反省すべきことはたくさんあります。

良いコードレビューや悪いコードレビューの経験は誰しもがあるとは思いますが、本セッションでは良いコードレビューとは何かということを話したいと思います。
特に、以下のような内容について紹介します。
・良いコードレビューとは何か
・良いコードレビューをするために心がけるべきこと
・悪いコードレビューとは何か
・悪いコードレビューをしないために心がけるべきこと
・コードレビューを依頼する側の話
・コードレビューの負担を少しでも減らすために

Composer で見かける「PSR-0」「PSR-4」、コーディングスタイルでみかける「PSR-2」「PSR-12」など、PHP に関わっていると自然と目にする「PSR」という言葉。
「PHP Standard Recommendation（標準勧告）」の頭文字なのですが、果たしてこれは何なのか？使い方は？どんなメリットがあるのか？
そんな疑問に対して、具体的なコードとともに解説していきます。