トーク

第4のWebサーバーといわれる LiteSpeed ですが、PHP の実行の仕方が ApacheModule、cgi/fcgi、fpm とも違った独自の SAPI になっています。
LiteSpeed Web サーバーとPHPプロセスはそれぞれ独立プロセスでありながら、うまく連携しながら動作をしています。

この独自の LiteSpeed SAPI を使って、どのようにWebサーバーとPHPプロセスがやりとりしているのかを深堀りしていきたいと思います。

グリーグループのリミア株式会社で開発を担当しています。
リミアでは、aws ec2の上でfpmを乗せています。
開発速度向上のため、aws ecsに移行しようとしています。
しかし、様々な問題にハマりました。
ハマった問題と解決方法について発表します。

「PHP の仕様は RFC によって決められている。」これは PHPer ならご存知かと思います。
技術ブログや Twitter でときどき取り上げられる RFC ですが、実は自分で読んだことがない方は多いのではないでしょうか。
RFC は大抵の場合、我々より PHP に精通した人が提案し、議論し、要否を決定しているため、RFC を読み、その提案理由を考えることは、PHP 上級者への一歩です。
しかし、RFC は英語で記述されていますし、そもそもの仕組みを理解していない場合はどこから手をつけていいのかわからないなど、ハードルが高くないでしょうか。
本セッションでは、そんな PHP の RFC について、他の言語とも比較しながら、仕様が決定されるまでの基本的な仕組みや、読み方を紹介します。

働き方改革、すすんでますか？
子供がいると、どうしても母親に無理がかかってしまいがちですよね？しかもシングルマザーという不利な境遇。
そんな中、わたしは約1年前に転職してから、かなり柔軟な働き方ができるようになりました。
子供がいて全国各地に飛び回りながら楽しく仕事をしている母さんエンジニアはいったいどんな働き方をしているのか？

小難しいソースコードの話は出てきません。
女性も男性も、子供がいる方もこれからと思っている方も、まだまだ自分には子供なんてムリなんて思っている方でも、休憩がてら聞きにきてください。

「AWS Fargate の上で PHP (Laravel/Lumen) でAPIを提供する」
「Amazon API Gateway 経由で Lambda Function を Web APIとして提供する」

巷ではよくあるパターンですよね。
ではみなさん、これらを組み合わせて使ったことがあるでしょうか？
実際に使ってみると、たくさんのメリットがあったのでご紹介します。

※ Lambdaの話は出てきません

OpcacheはコンパイルされたPHPのソースコードを共有メモリにキャッシュすることで、PHPの実行スピードを上げてくれる拡張です。現在のほとんどのPHPアプリケーションはOPCacheが有効化された環境で動いていると思います。さらに、PHP7.4ではOpcacheのpreloadが導入され、OPCacheは今後ますますの活躍が期待されています。

本トークでは、このOPCacheの仕組みを基本から解説することで、どのようにPHPの速度向上が行われているのか、また各種設定値がどのように速度に影響するのかを解説します。OPCacheの中身が知りたくてしょうがない方々に贈ります。

PHP 7.4からFFI(Foreign Function Interface)拡張が導入可能になりました。FFIによりネイティブの共有ライブラリ呼び出しが簡単になったので、PHP-GTKと組み合わせることで、PHPでデスクトップアプリケーション作成が捗ります。

本トークでは、PHP-FFI、PHP-GTKの簡単な使い方から解説して、PHPでもデスクトップアプリケーションが作れる！そんな可能性をお見せできればと思います。

ユーザのログイン、リダイレクト後のエラーメッセージの表示等、現代のウェブアプリケーションで多用されているセッションですが、セッションとは何かと聞かれた時に正しく答えられますか？
初心者に近いPHPerがセッションを多用すると、中堅エンジニアから「セッションは危ないから多用しないように」とアドバイスされることも多いと思いますが、それは何故でしょうか？

本トークでは、ウェブアプリケーションにおけるセッションについて、その正体を分かりやすく解説します。また、セッションの正体を知ることで、ウェブアプリケーションのアーキテクチャーに対してセッションが及ぼす影響についても解説します。セッションにまつわるアレコレを明らかにすることで、初心者と中堅エンジニアの間に存在する知識と経験の差を少しでも埋めることが狙いです。

きっかけは、オフィスの会議室で行った、PHPerKaigi2019の発表の上映会でした。
上映会後に参加者から様々な意見が飛び交い、活発な議論が生まれたことから
「デザインパターンの話に興味がある人、結構多いのでは？」という気づきを得て勉強会を開始することにしました。

勉強会を実施して継続していくにはいくつか工夫が必要だと思います。
・主催側の負担を減らす
・参加者がまた来たいと思える内容にする

社内勉強会を開いてみたいがなかなか開始できないという方や、始めてみたが、なかなか長続きしなかった、
といった方を対象に、スモールステップから始める社内勉強会の進め方についてお話できればと思います。

ウェブサイトやサービスの表示速度の最適化は、サーバーサイドのプログラム、ネットワークやサーバー、データベースなどのバックエンド方面の対応と、HTML/CSS/JavaScriptや画像などのメディアデータを扱うフロントエンド方面の対応の両方が必要になります。
ですから、サーバーサイドでPHPのプログラムの最適化を行ったとしても期待通りの結果にならないことも多々あるでしょう。
その時に問題の切り分けを行うには、フロントエンド方面での表示速度の最適化で行われることを知っておく必要があります。

このセッションでは、PHPerの皆さんの作成したプログラムをより活かすための、フロントエンドでの表示速度最適化の手法を解説します。
セッションで得たことを、自身で活用したり、フロントエンド方面の人達とのやり取りに役立ててください。

※ PHPカンファレンス沖縄2019で行った同タイトルのセッションをバージョンアップしてお届けします

セッションの内容（予定

1. 表示速度をとりまく状況
2. バックエンド？フロントエンド？ひと目で原因を切り分ける方法
3. フロントエンドでの表示速度最適化の手法・考え方
4. 改善ポイントを見つけ出す
5. 改善ポイント別対応例
6. フロントエンドの速度改善のためにサーバーサイドにお願いしたいこと

想定している対象者

• 受託制作でウェブサイトを制作している方
• ウェブサービスの開発/メンテナンスしているエンジニア
• CMS/EC/CGMなどを開発しているエンジニア

本セッションでは触れないこと

• FPS60を目指すといったこと

PHP 7 になってからいくつかの新機能がありましたが、その中でも型宣言については注目されていたのではないかと思います。
ただ、私の日々の作業の中に取り入れられているかと言われれば、その答えは No でした。
型宣言をすることで得られるメリットも複数あります。

そんな、あんまり PHP の型って使ってないし、いまいちよく分からないな、という型向けのセッションにしたいと思っています。

近年のWebアプリケーション開発において、サーバーを使うとなるとAWSやGCPを使うケースが殆どでしょう。
そんな中でもDockerやKubernetesの登場により、コンテナを開発から本番まで利用するケースが増えてきました。
しかし、Kubernetesなどは複雑な知識を必要とし、すぐに取り組むにはなかなか難しいものです。

そこで、2019年半ばに新たにGCPでサポートされたGoogle Cloud Run。
Cloud Runなら、コンテナをお手軽にリリースできるんです。

本LTでは、LaravelのコンテナをCloud Runにサクッとデプロイする流れを、ハンズオン形式でご紹介します。

近年当たり前の用に使われれている、AWS、GCPを始めとしたパブリッククラウドサービス。
DevOpsの概念の浸透とともに、アプリケーションエンジニアでもインフラ層を触ることはしばしば見受けられるようになりました。
しかし、そんな中でも意識する機会が少ないネットワーク。
あなたは雰囲気で触っていませんか？

弊社でEKSを使用しkubernetesクラスタをAWS上に構築したのですが、その時にネットワーク周りの様々な制約が出てきました。
その時の問題点の解決策と登場する概念を踏まえ、AWSのネットワークの基本を紐解きます。

こんな方へオススメ
・EC2を立てるときは、デフォルトVPCを使っている
・将来的にAWS上にkubernetesクラスタを構築したい
・AWSにちょっと詳しくなりたい

普段AWSを懇意に利用している私がふとしたきっかけでAzure Functionsを利用する事になりました。

せっかくなのでAWS Lambdaとの勝手の違いをAWS エンジニア目線からお届けしようと思います。

PHPerKaigai2020が行われている頃には紆余曲折して悩み、苦しみ、答えを出している頃です。

その経験を赤裸々にお話しようと思います。

・想定する聴講者
　- Serverlessに興味のあるWEBエンジニア
　- AWSを利用しているクラウド系エンジニア
　- Azureに興味のあるクラウド系エンジニア

・お話する内容
　- AWS LambdaとAzure Functionsの違い
　- 構築するうえで感じたクラウドリソースの違い
　- Azure Functionsのメリット、デメリットの主観
　- 紆余曲折の内容を話せる範囲で

・お話しない内容
　- Azureゴリゴリのエンジニアに向けた話
　- Azure Functionsを利用する上での答え

Serverlessは一般化してきています。

一方でPHPにおいてServerlessをどの様に構築するのかはまだ確固たるものは固まっていないと思います。

PHPにおいて、ServerlessなArchitectureを組むのはどの様な課題があるのでしょうか。
その課題を正しく認識して、解決することでServerless PHPの事例が増えるのではないかと考えます。

今回は主にAWSを利用してServerless Patternを適用して、その課題を解決するお話をしたいと考えています、

・想定する聴講者
　- Serverlessに興味のあるWEBエンジニア
　- AWS、GCP、Azureなどを利用しているクラウド系エンジニア

・お話する内容
　- AWS Lambdaを中心としたServerless PatternのPHP版
　- Serverless Patternを構築するうえで考えるべきAWSリソースの特徴
　- Serverless PatternをPHPで構築する上での課題
　- 上記を課題を解決する為の私の考える解法

・お話しない内容
　- GCP、Azureの込み入った話
　- 課題に関する「完全な」答え

‪https://github.com/rectorphp/rector は、既存のPHPコードのリファクタリングやアップグレードを自動実行するツールです。‬

‪フレームワークのバージョンアップをした、IDEを本格的に導入し始めた、新しいバージョンのPHPを使い始めた・・・開発を続けていると、色々な場面で「コードの書き方を変える必要が出て来た」「今までの書き方だと足りていない」という問題が発生します。かといって、膨大な量の(しかも退屈な！)書き換えを行うのは、なかなか気の進まない作業です。‬

‪rectorを利用すると、設定したルールに従い簡単な書き換えを自動的に実施できます！‬

‪ツールの概要や使い方、独自のルール作成の方法を紹介したいと思います。‬また、php-parserの動かし方についても言及しながら、「rectorは内部で何を行なっているのか？」というイメージを掴むことで、この不思議でパワフルなツールが皆さんにとって「怖くないよ！」といえるような、手助けになればと思います。

PHPUnitは、PHPソフトウェアのデファクトスタンダードとも言えるテストフレームワークです。それを利用して、どんなテストが書けるでしょう？
昨今のアプリケーションの開発は、より「責務」について重んじるようになり、それぞれの境界線を明確にする意欲が高まっているように感じます。そのため、開発者が「このテストは、何が出来れば(⇔何が出来なくて)良いんだっけ」を考えるのは正しい姿勢でしょう。

皆さんも、「モック」や「スタブ」が好きですよね。PHPUnitには、いくつかの「テストダブル 」の機能がサポートされています。このセッションでは、具体的なコード例を用いて、「やりたいテストを表現するための素敵な方法はないのかな」「どうしてこういう機能があるのかな」について考えてみたいと思います。

自作したソフトウェアを世の中に公開する時に考えることは何でしょう？
そのPJが解決する課題やコード自体の品質・機能はもちろんのこと、「オープン」しているからには、色んな人に関わってもらいたい！というのは、誰しも思うことではないでしょうか。
いくつかのPHP製OSSに取り組む中で気付いた、「こうしたらコントリビューターにとって便利かも」という点をお話したいと思います。

このセッション内では「良いコードの作り方」のようなトピックは扱いませんが、
これから初めてOSSを作りたい！発信したい！という人に、お届けしたい内容です。

皆さん、Laravelは大好きですか？私は大好きです。
皆さん、オレオレフレームワーク使ってますか？私は使っています。

今やPHPでWEBアプリケーションを作るならLaravelが候補に挙がるくらいには有名になりましたが、それはあくまでも新規案件のお話。
今回ご紹介するのは、レガシーなPHPアプリケーションにLaravelを導入したお話です。

しかしながら、一言に導入すると言っても、それは簡単な話ではありません。
いきなり全部のコードを入れ替えるわけにもいきません。
既存のサービスを止めるわけにもいきません。
Laravelは導入するけど、既存の資産はそのまま使いたい…！
などなど、いろいろな要望や懸念があるかと思います。

そんな中、私が担当するPHPアプリケーションでLaravelを導入するために取った戦略とは…！？

本セッションでは、以下のことを実際の実装を見つつハートフルにお伝えする予定です。

• レガシーアプリケーションにLaravelを入れるまでの苦労話について
• どのようなハマりポイントがあったかについて
• Laravelのどの機能を使っているのかについて
• プレーンなLaravelと比べて制限される機能について

Laravelをレガシーアプリケーションに導入してみたい方、どんな構成になっているのか気になられた方、どなたでも構いません。
ご興味を持たれた方はぜひご参加ください！！

fw3/ioで使用しているクエリビルダはクエリのすべての要素をオブジェクトで制御しています。

これはクエリの各要素が独立し、自身の関心ごとの枠内で文字列を構築すればよい特性があるためです。

このセッションでは実用クエリビルダの構築から得た再利用しやすい集約を作るためのクラス、インターフェース、トレイトの切り方についてお話します。