トーク

SQLServerの操作って大変ですよね。基本GUIのツールを使う必要がありますし。
MySQLみたいに、簡単にクライアントから接続できて、気軽にSQL発行出来たらなぁ...

それPHPで出来ます！
Readlineを使って、mssqlコマンドを作っちゃいましょう！

パワポを使用する業務、大変じゃありませんか？全スライドのフォントを整えたり、座標を調節したり、画像の配置を変えたり、本来の業務の時間を割いてやるのは時間がもったいないです。
そこで、自動化をしたいと考えたことはありませんか？でも VBA 難しいしな… と思う必要はありません。
そう PHP でパワポの生成や全スライドのフォントを整えたり、座標を調節したり、画像の配置の変更を自動化すればいいのです。
本セッションでは PHP でパワポのファイル生成をどのようにやるのかを解説します。

ワードを使用する業務、大変じゃありませんか？フォントを整えたり、画像の配置を変えたり、本来の業務の時間を割いてやるのは時間がもったいないです。
そこで、自動化をしたいと考えたことはありませんか？でも VBA 難しいしな… と思う必要はありません。
そう PHP でワードファイルの生成やフォントを整えたり、画像の配置の変更を自動化すればいいのです。
本セッションでは PHP でワードファイルの生成をどのようにやるのかを解説します。

エクセルを使用する業務、大変じゃありませんか？方眼紙にして入力したり、セルの枠を調整したり、本来の業務の時間を割いてやるのは時間がもったいないです。
そこで、自動化をしたいと考えたことはありませんか？でも VBA 難しいしな… と思う必要はありません。
そう PHP でエクセルの生成やセルの調整などを自動化すればいいのです。
本セッションでは PHP でエクセルファイルの生成をどのようにやるのかを解説します。

MySQLも8.0になって、5.xの頃とはだいぶレプリケーションの定石も変わってきたような気がします。

• Non-GTIDなレプリケーションを(新規で)選ぶ理由ってある？
• master.info, relay-log.infoがどっかいった？
• Cloneプラグイン + GTIDでレプリケーションを増やすのが自動化できそう

令和時代のレプリケーション詰めて「令プリケーション」の現在を紹介します。
（このセッションは割とインフラ寄りです）

MySQL 8.0にはついにCTE(WITH句)とWindow関数が実装されました。
とはいえ「今までなかったもの」は使い方も想像がつかぬもの、どんな用途に使えるのか、そもそもCTEやWindow関数の名前をここで初めて聞いた！ みたいな人もいるかも知れません。

それぞれの構文の詳解/説明や「こんなことに使えるんじゃない？」のような提案をしたいと思っています。

PHPでAPIサーバーを作っていますか？
APIの仕様書は書いていますか？何を書いていますか？
たとえばJSONデータをPOSTするときに、JSONデータの仕様書も書いていますか？
APIサーバーをPHPで作り、フロントエンドをTypeScriptで作っていれば型を導入できますが、APIで送受信するJSONデータについて共通した型定義は導入できません(JSONスキーマを使っていれば別ですが)。
Protocol Buffersを使うことで、APIで送受信するデータに型を導入できるようになります。
このセッションでは、Protocol Buffersの紹介から、実際にPHPやTypeScriptでどのように使うのか、サンプルコードを交えて解説します。

みなさんのアプリケーションはたくさんのライブラリの力を借りて実装されていると思います。
しかし、安易にライブラリに依存した実装をすると、ライブラリをアップデートしようとしても変更箇所が多すぎてなかなかアップデートできないなんてことがままあります。
では一体どうですればいいのでしょうか？ライブラリを使わずに実装すればいいのでしょうか？

いいえ、そんなことはありません。
このトークでは、ライブラリへの依存を極力抑えたままライブラリを活用する方法について解説します。

Serverless は僕達をサーバー管理から開放してくれます。

未来の投資として非常に有益だと考えているのですが、構築するには様々な知識が必要になります。

今回はMicrosoft Azureを利用した Full Serverless Applicationを構築する為の方法をご紹介しようと思います。

このトークによりみなさんがサーバー管理から解放される一歩を踏み出せればと考えています。

■お話する内容

• アーキテクチャ説明
• 開発手法
• 認証
• テスト
• CI/CD

■関連技術

• Azure Functions
• Azure Storage
• Azure Cosmos DB
• Azure Active Directory
• Azure Resource Manager

プロダクト開発に置いて、様々なデータを集め、取得し、分析、活用していくのが当たり前になってきました。
しかし専属の分析担当/チームがある会社もまだ多くはないかもしれません。

そういった場合に取得と分析を誰がどうやっていくのかがいいのでしょうか。

例えば下記のようなケースもあるかと思います。

• エンジニアが分析担当を兼任し、ビジネスサイドは関与しない
• ビジネスサイドから欲しいデータの抽出をエンジニアに依頼、ビジネスサイドが分析していく

私達はスピードと柔軟性のためにビジネスサイドもエンジニアも一緒にやっていくことを選びました。
それを実現するにはビジネスサイドもSQLを活用できないといけません。

ビジネスサイドとエンジニアが協力をして実際にどういうことを行ったか、
ビジネスメンバーはどういうことからはじめて、どれくらいのことができるようになったのか、エンジニアとどういう分担をしているのか、
そしてそれらを行っていく中でうまくいった点や改善点についてPHPerのエンジニアが話します。

※ 具体例としてDBはBigQuery,データはFirebaseで収集したアプリのイベントを使います。

想定する聴講者

• 経験や職種関係なくSQLを活用して、データ抽出を行いたい、ダッシュボードを作りたい方
• SQLの活用を他のメンバーにも広めたいエンジニア

話さないこと

• PHP
• 分析の詳細
• SQLの詳細の文法

2019年11月、GitHub Universe 2019で「GitHub Actions」がついに正式版になったことが発表されました。
これまではベータ版として公開されており、v1, v2と大きな仕様変更を経て正式版公開となったわけですが、興味はあるもののしっかりとキャッチアップできている人はまだまだ多くないのではないでしょうか？

本トークではGithub Actionsを1から解説し、実際にこれまでCircleCIやTravisCIで行っていたPHPアプリケーションのCI/CDを、Github Actionsを利用して実現できないかを検証します。
Dockerコンテナを活用しつつ、PHPUnitによるテストや、phpcs・phpstanといったQAツールを実行する具体例として参考となるものにできればと思います。

PHP Code Snifferはコミュニティで広く支持を得て、活用されています。その為の仕組みや資産、例えばCI上での活用tipsに始まり、IDEとの連携・支援も拡がりました。これらの状況は、導入を考える人たちを強く励ますものです。
多くの場合は、「そのまますぐ使える」という土台が整っているとも言えます。フレームワークが提供しているrulesetを用いたり、PSR-12を適用するのは合理的な判断です。

しかしながら、このツールはあくまで「開発者を支援する」ものであり、「開発者を支配する」ものではありません。世間の標準に乗っかるだけでなく、チームやプロダクトの事情に応じて、本当に欲しいルールを手に入れるべきです。

そう考えた際に、独自のルールを作成できると夢が広がりませんか？
例えば、「PHP Code Sniffer」「PHP_CodeSniffer」「PHP CodeSniffer」正しいのはどれでしょうか？少なくとも言えるのは、チームでの正解はチームが決めれば良いのです。

ルールを自作する力を得て、より踏み込んだ活用の可能性を見つけませんか。

パフォーマンス・スケーラビリティ・開発・運用、
これら多角的な観点から「マスタデータ」を考えます。

都道府県マスタ : 1:北海道／2:青森／3:岩手／4:宮城 …
金融機関コード : 1:みずほ銀行／5:三菱UFJ銀行／9:三井住友銀行 …
ポケモン一覧 : 1:フシギダネ／2:フシギソウ／3:フシギバナ／4:ヒトカゲ …
カテゴリ一覧 : general:一般／social:世の中／economics:政治と経済 …

変わらないデータでしょうか？変わるデータでしょうか？変わるとしたらいつでしょうか？運用するの誰でしょうか？

データの特性を捉えた適切な実装により、開発と運用の双方を効率化できます。その方法をご紹介します。

注)この話はフィクションです。きっと。

■対象
・今最新を使っている人(メインターゲットです)
・これからやる人
・もうやって、あるある話を聞いて涙したい人

皆さん、バージョンアップしてますか？
PHPや、Laravel、古くなってきたからバージョンアップしよう。
よくある話ですね。

でも、何も考えずにプログラムを書くと、あとで痛い目を見ます。

これは、本当にあったかはわからない、バージョンアップで悲しみを背負った人の話。

■内容
・vendor配下をいじった報い
・コードをコピペで拡張した悲しみ
・Laravelを見捨ててPHP上げたらLaravelがお亡くなりに
・テストコードなんてなかった
・このライブラリはもう居ない
・消えた機能
・見つからない変更点
・再度襲いかかるコピペの悲しみ
・見えない終わり
・把握できない予算、見積もり
・PHPのアプデは簡単だったという圧力
・本当はマイナーバージョンアップではない誤解
・把握できないバージョンアップの利点

ユーザ投稿型の音声配信サービス内のひとつの機能として、あるユーザにとって好きな投稿をレコメンドすることになりました。
分析の結果、「好きな投稿＝よく聴く投稿に似ているもの」であるだろうと仮定し、似ている投稿とは何なのかの研究が始まりました。
投稿データは音声の波形データであるので、その音声データを解析して特徴ベクトル化し、それを用いて似ている投稿を学習により推定することにしました。
そして最終的に、音声知識が皆無である中、音声データの解析手法やベクトル化手法とその実装について試行錯誤し、最終的にはサービスにそのまま組み込むのではなく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がセッションを多用すると、中堅エンジニアから「セッションは危ないから多用しないように」とアドバイスされることも多いと思いますが、それは何故でしょうか？

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

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

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

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

セッションの内容（予定

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

想定している対象者

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

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

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