トーク

ウェブサイトやサービスの表示速度の最適化は、サーバーサイドのプログラム、ネットワークやサーバー、データベースなどのバックエンド方面の対応と、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にちょっと詳しくなりたい

弊社ではPHP未経験者の採用もやっております。その中の研修カリキュラムで独自フレームワークを作ってもらっており、研修用のPHP独自フレームワークの作り方を一挙公開します！
具体的に自作する内容は下記です。

• routing
• CSRF対策
• Cotroller
• Model
• バリデーション

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

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

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

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

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

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

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

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

Serverless においてある程度決まったPatternがあります。

ServerlessなArchitectureを組むことでそのシステムはどの様なメリットを享受出来るのでしょうか。

今回はAWSを利用したServerless Patternを適用することで、
そのシステムが享受出来るメリットと構築する上での注意点を解説します。

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

・お話する内容
　- AWS Lambdaを中心としたServerless Pattern
　- Serverless Patternを構築するうえで考えるべきAWSリソースの特徴
　- Serverless Patternを構築することで得られるメリット
　- Serverless Patternを利用するうえで注意すべき事項

・お話しない内容
　- GCP、Azureの話
　- PHPを利用したServerless Pattern

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

世にはEloquentやDoctrineなど多くのDBIとそれに付随するクエリビルダーがあります。

ですが、実案件上では次の課題があり、痒いところに手が届き切らない面がありました。
・特定フレームワークと密結合なため、既存案件に導入できない
・メソッドの切り口がクエリの見た目に沿っているため、「だったら生で書けばいいじゃん」と言われがち
・文字列表現を使わないと表現できないクエリがある
・クエリの再利用は一度テキストに落とさないとならない
・妙な所でインジェクションができるし、それを推奨するかのようなインターフェースがある

そこで、15年以上商用でPHPを使用した知見を活かし、クエリビルダーを開発しました。

このセッションでは上記課題を解決し、様々な現場で導入しやすいクエリビルダーについてご紹介します。

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

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

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

現在では PHP も立派なオブジェクト指向パラダイムを持つ言語のひとつとなりました。しかし、オブジェクトとは一体何でしょうか？

モデリングパラダイムとしてはオブジェクトの他にもデータモデルの設計によく使われるERモデルやリレーショナルモデル、または関数型言語のベースになっているラムダ計算などがあります。

本発表ではオブジェクトとは抽象データ型であるという立場を基本とし、その他のモデリングパラダイムとどのような共通点・相違点があるのか考察し、異なるモデリングパラダイムの間に生じてしまうインピーダンスミスマッチをどのように最小化していくかについて述べていきたいと思います。

PHPといえばレンタルサーバー、そういう時代がありました。いや今もあります。

数多くのサイトを提供しているレンタルサーバーは、PHPerKaigiのようなカンファレンスにいらっしゃる「エンジニア」な人たちには少々嫌われているような気がします。おっしゃることはわかります、私も人に手放しで勧めたりはしません。

しかし、私はレンタルサーバーが好きです。

長らくCMS実行環境としてしか見られていないレンタルサーバーですが、時代が進むにつれ、あれ？これっていいんじゃないの？もしかしてワンチャンあるのでは？という魅力も増えていると私は考えています。

いま一度私とレンタルサーバーを見つめてみましょう。

話す事
・PHPer目線で見る、レンタルサーバーの強みと弱点
・レンタルサーバーをPHPerとして活用するテク
・モダン（？）なデプロイと開発、運用
・VPSからレンサバにアプリを移管する話

話さないこと
・WordPressなどのCMSに関係すること
・定番フレームワークがどうたらこうたら

想定聴講者層
・上記にピンときた人
・レンタルサーバーをつかったことがない、最近つかっていない人
・レンタルサーバー業者の人

非想定聴講者層
・マイノリティな好奇心や探究を、マジョリティでないだけで最大公倍数的な優劣と考えてしまう人
・フレームワークのフレームに完全にはまっている人
・業者から最悪Banされることに耐えられない人

最近注目を浴びているPHPの非同期処理機能拡張が「Swoole」です。Swoole を利用することで、PHP単独では実現不可能だった同時並列処理が実現できます。
では Swoole の非同期処理は、一体どのように実装されているのでしょうか?
本セッションでは Swoole のC++ソースコードの奥深くまで探索し、非同期処理がどのように実現されているかを解説します。
このセッションを聞けば、ブラックボックスの魔法のようだった Swoole がより身近になり、中で何が起きているか容易に想像できるようになるでしょう。

PHPでも競技プログラミングは学べるんだ。
競技プログラミングのズブの素人が、PHPで簡単な問題を中心に100問やってみた結果を共有する。
PHPの懐は広い。便利関数を使って楽できることもある。しかし便利関数の裏の動きを想像しないと実行が遅すぎたりするのだ。

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

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

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

ツールの概要や使い方、独自のルール作成の方法を紹介したいと思います。

かつて

Q.「セキュアなWebアプリケーションを作るにはどうすればいいか」
A.「まず PHP を避ける」

とまで言わしめた 古い PHP が活躍していた時代、その中心的機能である register_globals を知っていますか。この機能を on にしたが最後、リクエストパラメータは問答無用でグローバル変数に展開されてしまうという、お手軽且つ凶悪な機能でした。変数汚染攻撃の温床ともなり、「PHP is 脆弱性」とまで言われるようになった所以です。

そんな register_globals も PHP 5.4 で姿を消し、この機能を使ったことのある人の方が少ない時代になっていると思います。
しかし、そんな時代だからこそ皆さんと振り返っていきたいです。

・ register_globals とはどんな機能なのか
・ ドキュメントには載っていない register_globals の動き
・ PHP 5.4 以上でも使える！ register_globals