トーク

ユーザ投稿型の音声配信サービス内のひとつの機能として、あるユーザにとって好きな投稿をレコメンドすることになりました。
分析の結果、「好きな投稿＝よく聴く投稿に似ているもの」であるだろうと仮定し、似ている投稿とは何なのかの研究が始まりました。
投稿データは音声の波形データであるので、その音声データを解析して特徴ベクトル化し、それを用いて似ている投稿を学習により推定することにしました。
そして最終的に、音声知識が皆無である中、音声データの解析手法やベクトル化手法とその実装について試行錯誤し、最終的にはサービスにそのまま組み込むのではなくGCP上でマイクロサービス化することで疎結合なシステムを作り上げました。

これは、Pythonを用いて、音声知識がゼロの状態から、数多の音声データを聴き様々な手法を試し学習させマイクロサービスを完成させた、PHPerによるトークとなります。

具体的には以下のような内容を予定しています。

• 音とは何か
• 「似ている」とは何なのか
• どのような解析手法を使ったのか
• どのように特徴ベクトル化しているのか
• どのような学習をさせたのか
• 最終的にどのようなレコメンドになったのか
• 設計・マイクロサービスについて

基本的にPythonを使って実装しており、PHPの話は一切出来てきません！

想定している対象者

• 音声解析に少し興味がある
• 機械学習に少し興味がある
• マイクロサービスに少し興味がある
• Pythonが好き

話さないこと

• 音声解析の本格的な理論
• 機械学習の本格的な理論
• PHP！

新規サービスの立ち上げに伴い新しいチームが発足しました。
これまではデータベースの設計であったりAPIエンドポイントの設計であったりはもちろんしっかりとやってきましたが、恥ずかしながらアプリケーションコード自体の設計はしっかりとはやってきませんでした。
ファットなコントローラーにテストも不十分という環境が当たり前のなか、新しいチームでの開発が始まるにあたり、せっかくなら良い設計のサービスにしようと思いたちました。
設計指針として様々な選択肢がありますが、今回はクリーンアーキテクチャを採用することにしました。
私自身も含めて設計に明るいメンバーはおらず、リリース日も決まってしまっているなかで、新たな「設計」を取り入れることをチームに受け入れてもらうために奔走し、挑戦しました。

これは、ひとりの設計初心者であるPHPerが、設計初心者チームに受け入れてもらうために取り組んだことに関するトークとなります。

具体的には以下のような内容を予定しています。

• なぜ「設計」に挑戦しようと思ったのか
• 設計で何を解決したかったのか
• なぜクリーンアーキテクチャを採用したのか
• どのような設計にしたのか
• チームメンバーに受け入れてもらうために取り組んだこと
• 取り組みとして成功したことと失敗したこと
• 設計に挑戦して良かったこと
• チームで設計に挑戦したその先

チームに受け入れてもらうために行ったことがメインで、設計手法自体はサブになる予定です。
PHPの話も少しだけ出てくると思います。

想定している対象者

• 設計を取り入れたいと悩んでいる
• レガシーな環境に辟易している

話さないこと

• 詳細な設計論

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

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

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

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

※ Lambdaの話は出てきません

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

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

我々が普段慣れ親しんでいるアプリケーションの最新の状態をデータストアに記録するという考え方をステートソーシングと呼びます。
対してイベントソーシングは、操作による状態の変更差分をイベントとして記録し、最新の状態を過去のイベントによる変更を積み重ねた結果として捉える考え方です。

PHPにも、Prooph、Broadway、EventSauceなどイベントソーシングに基づくアプリケーション作成を支援するライブラリが存在します。
本セッションではイベントソーシングの考え方を解説した上で、EventSauce (https://eventsauce.io/) を利用した実装についてご紹介します。

お話ししたいこと

• イベントソーシングの考え方
• CQRSとの関係性
• イベントソーシング用ライブラリと単なるイベントディスパッチャライブラリとの違い
• PHPとEventSauceを利用したWebアプリケーションの実装方法

話さないこと

• データストア、メッセージキューなどミドルウェア周りの詳細
• ドメイン駆動設計
• マイクロサービスアーキテクチャ
• 本番運用の事例

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

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

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

セッションの内容（予定

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

想定している対象者

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

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

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

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の込み入った話
　- 課題に関する「完全な」答え

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OSSにPRを出すのは、すごいエンジニアや上級者がやることだと思っていませんか？
そんなことは全くありません。
たとえあなたがエンジニアになりたてだったとしても、そのOSSを使ったことがなくても、PRを出すチャンスはあります。

本トークでは、私が過去に数々のPHPライブラリに対して送ってきたPRを紹介しながら、PRを送りつけるときの心構えやチャンスの探し方を紹介したいと思います。

OSSの例:

• Symfony
• Guzzle
• AWS-SDK-for-PHP
• Monolog
• Ethna
• DietCake

本トークを聞けば、
「あ、こういうところにチャンスがあるのか」
「自分もやってみよう」
という気持ちになれるかもしれません。

その結果、PHPのエコシステムがどんどん良くなるといいなと思っています。

AWSのLambdaにCustom RuntimeでPHPの導入出来るようになってから日が経ち、私が関わった案件でもLambda for PHPを導入したシステムがあります。

別の開発者が初めて作成し初めて載せたものでどういった感覚で作られていたのか、そして実装面に対して問題等などは起きていなかったのか、といった部分を段階的に紐解いた話をいたします。
そして当時リリース優先でやらなかったUTについても実装を行い、そのUT実装に至るまでの手順などもお話します。

LambdaでCustom Runtimeで動かしたい方、またはLambdaには載せたけどUTの実装まで至らなかった方にはご参考になる情報を発信できればと思います。

みなさんはインフラ（またはクラウド）の構築、運用、整備を行ったことはありますか？
普段、サーバサイドエンジニアがインフラを兼任することはあまり多いケースではないと思います。
今回その多くないケースを踏み、インフラ面を兼務したことで得た利点、課題点、発展をそれぞれお話できればと思います。

インフラエンジニアという人の仕事がどういった業務を行い、私達サーバサイドがあまり気にしていなかったことや、気がかりだったところ等、
サーバサイドの視点を交えながら知見としてご参考いただければと思います。

みなさんは PHP にどのようなイメージをお持ちでしょうか。Web のイメージが強いのではないかと思います。
PHP はそれ以外の用途としてバイナリを書き込んで何かしらを行うことも可能だったりします。
例えば、java が実行する class ファイルのようなバイナリを PHP で生成して、 java コマンドで動かすことも可能です。
言い換えると java コマンドで動くバイナリファイルを PHP のみで生成する、つまりコンパイラを作るということです。
本トークでは、 class ファイルの構造やオペコード（プログラムを実行する命令のこと）を PHP だけを使い、
どのようにしてファイルに書き込んだら java コマンドで動くかをお話できたらと思います。

みなさんは PHP にどのようなイメージをお持ちでしょうか。Web のイメージが強いのではないかと思います。
PHP はそれ以外の用途としてバイナリを書き込んで何かしらを行うことも可能だったりします。
そう、例えば PHP のソースコード自体を PHP を使って Java のクラスファイルにコンパイルし、java コマンドで動かすようにすることも可能です。
言い換えると、 Kotlin や Scala のような JVM 言語を PHP のソースコードを用いて PHP で実装するということです。
本トークでは、 PHP を AST (抽象構文木、簡単に言うとソースコードがプログラムで理解されやすいように最適化した状態) に分解し、それを Java のクラスファイル（バイナリファイル）にコンパイルしてから java コマンドで動かすまでの一連の流れをお話できればと思います。

みなさんは PHP にどのようなイメージをお持ちでしょうか。Web のイメージが強いのではないかと思います。
PHP はそれ以外の用途としてバイナリを読み込んで何かしらを行うことも可能だったりします。
例えば mp3 の ID3 タグを取得する, zip を解凍する, jpg のメタデータを取得する、などなど。
しかし、これらは一般的にはライブラリや拡張機能が提供されていて、刺激が少ないかと思います。
そんな中で、今まで誰もやったことがなさそうなこととして PHP でバイトコードにコンパイルされた Python を動かしてみたいとは思いませんでしょうか。
私は動かしてみたいと思います。本セッションでは PHP でどのようにしてバイトコードにコンパイルされた Python を動かすのかをトークできればと思います。

PHP 7.4 より、PHP をビルドする際に使用されるオプションである --enable-zip が正式にバンドルされなくなりました。
これにより、 PHP で zip を展開したり、読み込んだりすることにハードルが上がってしまいました。
libzip は PHP 7.3 より、libzip 自体の野良ビルドが必要であったり、 cmake のバージョン自体もあげないといけなかったり、必要なモジュール導入のハードルが高くなっていました。
PECL に移ったとはいえ、ビルドするのはなかなか敷居が高いです。ではどうしたらいいのか。何もモジュールにこだわる必要はありません。 PHP 単体で zip ファイルを読めばいいのです。本セッションでは、 PHP でどのようにして zip ファイルを読み込むのかをトークさせていただければと思います。

CakePHPは2.xから3.xで大規模な変更を実施すると共にポストPHP5.6時代に十分に適応したソフトウェアに進化しました。4.xでは、「PHP7.2を必須とする」という方針が採用されています。
php-figのメンバーでもあるCakePHPは、どのように「時代に合わせた進化」を遂げてきたでしょうか？
これまでの軌跡を辿り、リリースが近づいている4.0(※)の概要、その先にある4.1/5.xへの言及にも触れながら、その思想の背景を読み解きます

※2019年11月時点。カンファレンスまでにstableが出ていると思います