フレームワーク使っていますか？
PHPで作るサーバーサイド、ブラウザで動作するWebフロントエンド、どちらの開発においてもフレームワークは開発の効率化(速度や品質)を強力にサポートしてくれます。
でもカンファレンスなどで発表される内容には、〇〇からXXに移行してみた、とかバージョンアップを頑張った、という話が多いなと感じることはないでしょうか？
もちろんフレームワークをまったく使わない開発というのは難しいかもしれません。
そこで標準インターフェースを意識することで少し遠回りになりますが、ライフサイクルの長いサービスのアプリケーションで壊滅的な技術困難を避けられる可能性が高まります。
このセッションでは、現時点で考えられるなかで、なるべくロックインせず効率的に開発するのに役立つ技術要素について紹介します。
サーバーサイド/フロントエンドのアプリケーション開発をしていく上での、1つの気づきになれば幸いです。

• 標準インターフェースとは？
• ライフサイクルの違い
• フレームワークとは
• SQLを意識する
• PHPでPSRを意識する
• Web標準を意識する
• 標準技術とコンポーネントがポータビリティを高める
• サーバーとクライアントの間でインターフェースを明確化する

Laravel において例外をハンドリングする処理は App\Exceptions\Handler に書きます。
本トークではその基底クラスで行われている処理を説明したり、カスタマイズする際の tips などを紹介します。

Laravel を使った開発の際に私が必ずインストールする便利な composer パッケージについて、導入手順、活用法を紹介します。

PHP のロギングライブラリである Monolog の基本概念（Handler, Processor, Formatter など）について理解し、ロギングを自在にカスタマイズできるようになりましょう！

Docker を用いて Laravel を動作させるには Laradock を使う、という方法が挙げられます。
しかし Laradock にはありとあらゆるものが含まれているため、Docker についての理解が浅いと全体で何が起きているのかを把握しにくいという問題があります。
本トークでは 1 から Laravel が動く最低限の構成（php/apache/MySQL）の環境構築手順を説明します。
最終的には Docker の基本概念を理解し、Laradock の後ろにある仕組みを理解できるようになることを目指します。

Webアプリケーションの脆弱性は、どこに潜んでいて、いつ狙われるのか分かりません。ひとたびサイト改ざん・情報漏えいが発生したらビジネスに及ぼす影響は甚大です。

未然防止策として外部脆弱性診断・検査ツールなどがあり、脆弱性の発見・事前検知ができます。WAF (Web Application Firewall)を導入することで、外部からの不正な攻撃からWebアプリケーションを守ることも出来ます。

しかし、それで本当に万全でしょうか? いえ、そうは思いません。根底として大切なのは、各エンジニアがWebセキュリティの正しい知識を持ち、安全なアプリケーション開発を行うことであると考えます。そして理想を言えば、脆弱性の嗅覚を持ち、自らサービスの脆弱性を見つけ、穴を塞いでサービスを強固にしていくことです。

Webアプリケーションエンジニアの皆さん、今改めてWebセキュリティを一緒に見直しませんか。本セッションでは、Webアプリケーションエンジニアが遭遇しやすい脆弱性の概要と危険性、そして対策方法についてお話します。

みなさんは PHP で値を取り出すときにどのようにしますか？パッと思い浮かぶのは foreach で値が見つかるまでループし続ける、
だったり、用途にとっては array_search だったりするかと思います。また用途によっては array_column で取れたりするものもあります。
また別のケースとして、特定の値を除いた合計値を計算したい場合、あなたはどうしますか？foreach で if 文を使って合計値を求めますか？
それ実は array_reduce 単体や array_sum と array_filter でできたりします。
これ以外のケースだと、例えば、 [1, 1, 0, 1, 1, 1, 0] のような配列があり、連続する同じ値の個数の最大値を求める場合あなたならどうしますか？
これ実は array_reduce で簡単に求めることが可能です。
このようにいろんなケースがある中で、実行速度とコードの理解のしやすさのバランスをみて、
こんな時、どんな関数を使えばいいの？どの関数を使えば計算量が少なくすむのか？といったセッションができればと思います。

みなさんは PHP で非同期処理をする方法をご存知でしょうか？非同期処理は厳密には並列処理や並行処理とは異なります。
さて、以前は pthreads といった拡張機能があり、 PHP で並列処理を実現するには主にこの拡張を使用していました。
一方で非同期処理に関しては、最近だと Swoole が注目されているかと思います。
Swoole はイベントドリブンに PHP で非同期処理を行うことができます。例えば、 stream_socket_server / stream_socket_client などが該当します。
pthreads では比較的難しかったデータの受け渡しなどのサポートもしています。
また、 pthreads の導入はいくつかのハードルがありますが、Swoole は一般的な拡張機能の導入と同じなため、ハードルが低くかつ、非同期処理を簡単に実現することが可能です。
本セッションでは、 phtreads と Swoole を比較しつつ、実際に今まで触れてきたり、 pthreads の導入に挫折はしたもののプロダクションに導入しようとしたり、
Swoole を使って実際にアプリケーション開発をした過程をノンフィクションでトークできればと思います。

みなさんはブラウザテストをする際に、どのようにテストされていますでしょうか？
ブラウザテストをする際に有名なソフトウェアとして Selenium があります。
また、 PHP では Selenium と繋ぐための OSS として Facebook WebDriver があります。
Selenium を使うことにより、リンク切れが発生していないかの確認をしたり、動的に生成される DOM の検証を行ったり、
フォームに自動で値を入れたりなど様々な用途でテストを行うことができます。
さらに、 Selenium は JavaScript をその場で実行できたり、 Chrome, Firefox, IE などブラウザごとのテストを行うことも可能です。
そして、実際に私が以前勤めていた会社や複業先に導入した経験をもとに Selenium と Facebook WebDriver と PHPUnit を使ったテストの方法や、
導入するにあたってどのような苦労があったのかをトークできたらと思います。

PHPでURLルーティングを自作したことがありますか？
普段は外部の有用なパッケージにお世話になっているのではないでしょうか？
私もそうです。自作せずとも世の中には素晴らしいルーティングライブラリが沢山あります。
でも自作してみたいと思いませんか？私は思ってしまいました。
URLルーティングの自作の楽しさと車輪の再発明の意義を5分でお伝えしたいと思います！

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

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

セッションの内容（予定

表示速度をとりまく状況
バックエンド？フロントエンド？ひと目で原因を切り分ける方法
フロントエンドでの表示速度最適化の手法
改善ポイントを見つけ出す
改善ポイント別対応例
サーバーサイドプログラムでできるフロントエンドの速度改善

想定している対象者

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

東京で働いていたPHPエンジニアがあるきっかけで沖縄で働くことになり、
またあるきっかけで東京に戻ることになった。
そんな中で「給料」、「家族」、「仕事」、「副業」などの変遷や、
東京でSaaSサービスを展開する企業のリアルな現場感（開発/PM）を
お伝えしたいと考えています。

LaravelのJob Queueを用いて、処理の負荷を軽減させた話をさせて頂きます！
具体的にはバッチ処理で毎日、大量にスクレイピングの処理が走る中で、
PHPメモリエラーになる可能性が高い箇所があり、その部分をJob Queue化しました。
実装する中で工夫した点やノウハウ、難しかった部分などを細かくお話できればと思います。

普段皆さんはPHPをどのような環境で実行してますか？

Apache を使って mod_php ですか？
Nginx と php-fpm の組み合わせですか？

意外と知られていませんが、php-src の sapi にはこれらの他に litespeed というものがあり、LiteSpeed というWebサーバーと組み合わせて使うことができます。

公式サイトでは Apache よりも Nginx よりも WordPress がはやい！というベンチマークがでている LiteSpeed について、あまり日本では紹介されていないので、これをつかうとどういうところがうれしいのかという点に関してお話したいと思います。

特に秘伝のタレの rewrite ルールがあるという方に耳寄りのものになると思います！

ICTがこれだけ発達し、政府が地方創生や働き方改革を提唱し、実際にリモートワークできる環境が整っていながら、
日本では仕事も、企業も、PHPerも、何もかもが東京に集まっています。

首都圏を除く地方にもPHPerが一定数いますが、
・地方の開発プロジェクトが東京の企業に発注されてしまう
・運良く見つかったお仕事がレガシーな体制/コードで書かれていて絶望する
・評価を得るためにクラウドソーシングサービスで安請け合いをする人が続出している

こうした課題を乗り越え、地方のPHPerはいかにして付加価値を高めながら生き残るか？

このセッションでは開発者として13年目／フリーランサーとして8年目を迎えた大阪在住のおっさんが
GAFAM、大阪万博、自治体などとコラボした事例に触れながら、参加者のみなさんと双方向でやりとりできればと思っています。

ゴール設定

どの言語も生でコーディングはしんどいし、つらみなので、FWの素晴らしさを再認識したことを伝えたい

構成

• 生PHPで簡単なログインフォームを作ってみた
  　 ステップ数をざっと見ていただく
  　 動作をざっと見ていただく
• 攻撃実演　※攻撃手法を見せるのがまずい場合は伏せます。
  　 XSS
  　 SQLインジェクション
  　* セッションハイジャック
• FW（Laravel）でログインフォームを作ってみた
  　* ステップ数をざっと見ていただく
• 再度、攻撃
• FWは素晴らしい。Laravel大好き

ペット、かわいいですよね。私はハムスターを二匹飼っています。それぞれキンクマとジャンガリアンです。
可愛すぎて「常時見ていたい…」そのような気持ちになることはありませんか？
ありますよね。更に、ストリーミングで常に見れたらうれしいですよね。
そんなニーズに答えるため、 PHP の拡張の Swoole と Raspberry Pi を使用して、ストリーミング再生で常に最新の情報が送られるようなハムスター監視システムをつくってみました。
実装までの過程で、Swoole や Raspberry Pi で乗り越えた壁や、どのような形で開発をしたのか一つのドラマとしてトークします。

みなさんは、PHP をどのような用途に使っていますか？ウェブサイトなどのウェブサービスを作成する目的でしょうか？
PHP ではウェブサービス以外の用途にも使用できます。例えば、Laravelをご利用の方は arisan コマンド、 CakePHP をご利用の方は bake コマンドなど、用途は多岐にわたるかと思います。
それ以外にも、PHPではソケット通信を行うことができます。ソケット通信でできることといえば、例えば PHP を HTTP サーバーそのものにする、PHPで WebSocket を実装する、サーバーへ SSH ログインするなどができたりします。他には ルーターと接続して、 UPnP の設定を行い、いわゆるポート開放を行ったり、ストリーミングで動画配信などもできます。
私がこれらを創ってきた経験から PHP でソケット通信に関するトークをできればと思います。

メタプログラミングとは、目的のロジックをプログラムとしてそのままコーディングするのではなく、プログラムを生成するようなロジックを書くことで目的を達成する技法のことです。メタプログラミングを効率よく採用することで単純なコーディングを避けたり、テストの省力化などの御利益があります。

PHPはWeb開発に利用されるほかの動的スクリプト言語(Python, Ruby, Lisp)と比べても静的な性質が強く、IDEや静的解析ツールによるエラー検査の恩恵を受けやすい言語です。ではPHPはそのような動的言語と比較してメタプログラミングの余地はないのでしょうか？いいえ、PHPにもメタプログラミングに活用できる機能はいくつもあります。

このトークではメタプログラミングに活用できるPHPの言語機能と発表者による実用例、既存ツールの紹介、魔術、そして戒めについて30分に濃縮してお伝えします。

長く続くシステムを運用していくと、テストが書かれていないコードや何百行・何千行に渡るメソッドが存在するコードが随所に存在するシステムに対して運用・改修をしていく必要が出てくることがあります。
それらに対して、根本治療的に構造を改善するなどが必要とわかりつつも、工数感・改善するための技量の問題などで、既存のコードベースと同様のやり方を踏襲してしまってさらに状況を悪化させてしまうという経験をしたことのある方は多いのではないでしょうか。このトークでは、レガシーコード改善の手法を一部を活用して、いかに「次の改善につなげる余地を残した状況」に保つかを話します。具体的には、「スプラウトメソッド」・「非推奨機能の回避・明示」・「仕様化テスト」などが挙げられます。このトークを通じて、「今のコードに引きずられずに思考して自分の仕事をコードに反映するか」という考え方について伝えらればとおもっています。