トーク

非同期処理、IO多重化、平行、並列...これらの言葉は、同期処理がメインのPHPウェブアプリケーション開発者にとっては理解が難しく、近寄りがたい雰囲気を持っています。しかし、コンピューターの資源を余すこと無く使って、資源利用効率の高いアプリケーションへの要望は高まってくるばかりです。近年のPHP界隈においても Swoole , Amp, ReactPHP, RoadRunner 等、非同期処理を行うためのツール、フレームワークがたくさん生まれています。また、PHP 8.1 においては軽量スレッドと呼ばれる Fiber も実装されます。

本トークでは、仕事で同期処理ばかり書いているエンジニアが、Echoサーバーのような簡単なサンプルプログラムの作成を通して、非同期処理を理解するための第一歩を踏み出す方法を紹介します。

このトークでお話すること

• 非同期処理とはなんなのか
• Swoole, Amp, ReactPHP は何を目指しているのか
• Generator とは何か
• Fiber で何が出来るようになるのか

Discord Channel: track2-7-a-php-async

PHP 7.4 から FFI がサポートされるようになりました。これまで、Cのライブラリを経由して何がしかの処理を行う場合は、PHP拡張を作るしかありませんでしたが、FFIを使うことで、直接PHPからCのライブラリをコールすることが出来るようになりました。

このLTでは、Webカメラの操作を題材にしてPHP-FFIが開くPHPの新しい可能性について紹介します。

PHPといえば、Web開発。
Web開発と切っては切り離せないのが「データベース」と「SQL」です。

このトークは、オライリー・ジャパン出版の名著「SQLアンチパターン」で紹介されている25のアンチパターンを「超特急」で学ぶものです。
わずか4分のLTで、25個のアンチパターンをおさらいします。
東京2020オリンピックのピクトグラムパフォーマンスのようなスピード感のある超特急LTをお楽しみください。

大事なところだけをギュッとして、明日からすぐ使える知識としてお届けできたら幸いです。

PHPといえば、Web開発。
Web開発と切っては切り離せないのが「データベース」と「SQL」です。

このトークは、オライリー・ジャパン出版の名著「SQLアンチパターン」で紹介されている25のアンチパターンを駆け足で学ぶものです。
「SQLアンチパターン」では、データベース設計やSQL記述の際に避けるべき事柄をアンチパターンとして紹介しています。
「アンチパターンを知っていれば問題を防げたな・・・」という場面は、きっとあなたの今までの開発経験の中にもあるはずです。

あなたは、すべてアンチパターンを全て覚えていますか？

このトークを聞くことで、「へー、そんなアンチパターンがあるんだ」「あ、そういえばそんなのあったな！」という気づきを得られるはずです。

また、このトークでは実際の開発で直面した問題や、プロダクト開発に生かした例も交えてご紹介いたします。
明日からすぐ使える知識としてお届けできたら幸いです。

めざせ、SQLアンチパターン・マスター！

Have you wondered how Laravel and Symfony started? This talk will cover the history of both frameworks. We will also cover documentation and examples on how these frameworks work. Let's dive into the details of the design patterns and features both have to offer.

Do you need to develop a backend API quickly with PHP? Then this is the talk for you. We will cover all the major PHP frameworks out there such as API Platform, Laravel and more. We will cover how to develop APIs quickly and how to support frontend teams to interact with your API easliy.

Are you still using Apache/Nginx and a bunch of virtual hosts to create your own shared hosting server? Stop tinkering with configs on your server because this talk is just for you. In this talk I’ll share how I manage my sites with EasyEngine. EE is a docker setup that uses Nginx, php-fpm, and Redis to spin up sites in a blazing fast and repeatable way. I’ll go over how I use EasyEngine with Google Cloud Compute, Terraform, and Namecheap to create a server, point a domain, and create a site in just a handful of steps. This has allowed me to be able to migrate sites in a super fast way to new operating systems and keeping security patches in tip top shape. I’ll go over how to use LetsEncrypt which is built right into EasyEngine for free SSL certificates and how you can backup/migrate sites quickly. After this talk, you will be ready for lift off with EasyEngine!

Have you still not upgraded to PHP 8? We will learn all the great features PHP 8 has to offer. Let's dive into all the details on PHP 8 and 8.1 features. We will also talk about what is deprecated so you can upgrade your code. Let us upgrade to the best version of PHP yet.

Discord Channel: #track4-4-a-php8
Joind.in: https://joind.in/event/php-conference-japan-2021/what-is-new-in-php-8

Laravel7系から導入されたBlade Componentsと近年注目されているUtility FirstをコンセプトとしたTailwindCSSを利用して再利用性の高いコンポーネントの作り方を紹介します。
Blade ComponentsはVue.jsのSFC（Single File Component）のような使い方をBladeで実装できる機能です。
対象者はこれからLaravelを触る方やまだLaravel7系以前の@extend,@yield,@sectionを利用してレイアウトを作ってる方となります。

Discord Channel: #track4-3-b-laravel-tailwind

速度は求めたい。ユーザのためである。
設計方針は崩したくない。開発者のためである。
「速度も求めつつ、既存の設計方針を守り、ユーザに価値を届ける。そんな方法が欲しい。」

こちらはそんな思いから生まれたテクニックを紹介するセッションです。

Domain Repository は Domain Entity もしくはそのEntityのリストのみを返して良いという制約があるとする。
なんらかのリストをユーザに見せる時、アプリケーション層で複数の種類のEntityを取りまとめてData Transfer Object（以下
DTO）として情報を固めて渡したいということがよくある。
愚直にやるのであればアプリケーション層で最初のEntityを取り(①)、さらに他のEntityのIDから他のEntityを取得する(②)という形であろう。
仮に、最初のEntityが1個、次に取りたいEntityが1個、そういう場合は全く問題はないのだ。

しかし、最初に取得するのがEntityのリスト(①)の場合に困ってしまうのだ。このリストを元にループを回して、次に取りたいEntityを逐次取得(②)しDTO を組み上げるとする。そうすると①のリストの長さの分だけ、②のEntityを取得するためのRepositoryを叩くことになる。

理想的にはDomain Repositoryの裏に隠れているインフラの層は隠蔽されており、知ったことではないのだ。しかし、実際のところ多くのケースで裏でDBから取得しているであろう。いわゆるN+1問題だ。

以下のような方法論で問題は緩和されたり、避けられるかもしれない。

• キャッシュをする
  • ②の Repository の get() などにキャッシュを差し込む。N回キャッシュ問い合わせがあることは変わらない
• 一覧にページネーションを追加する
  • Nを減らすアイディア。問題の緩和にはなるが、ビジネス要件によっては難しい。
• Command Query Separation を使う
  • Query で Repository を通さないで DTO を直接取得してしまう方法。一見根本解決ように見えるが、すでに Repository で get 系を書いていると取得処理が重複管理になり、管理不能になりがち

これらの方法には一長一短ある。
私は、Repositoryを使った設計パターンは崩したくない。けど速度は欲しい。そう考えた。

第4の選択肢としてHash Map Attachment法を提唱する。名前は独自命名だ。
Repository から取得したEntityから Query Service で DTO に変換する時にN+1問題とO(N^2)に陥らないようにするテクニックである。

Discord Channel: #track3-7-a-repository-pattern

PHPを始めたばかりの初心者の方は1つのファイルにすべての処理を書き込むところからスタートすると思います（フラットなPHP）
一方で、プロダクトは一度作って終わりではなく必ず改修が必要になります。フラットなPHPで開発するとぶち当たる改修の難しさを軽減し、より良いプロダクトを作るためにオブジェクト指向という考え方があります。
「オブジェクト指向」という言葉を聞いたことはあっても「なんとなく難しそう…」と二の足を踏んでいる人も多いでしょう。この機会に入門してみませんか？
概念の説明だけでなく、実際にフラットなPHPに書かれている処理をオブジェクト指向を使ってクラスに分けて書くやり方を、実際にコードを書きながら解説します。

※私自身オブジェクト指向について学問的に学んだことがあるわけではありません。日々PHPで開発するのに必要な概念のみ話す予定ですが、学問的には間違った内容が含まれる可能性が少しあります。

グループとチームは違う、と言われます。
その違いは「ただ人が集まっている状態の集合体」と「共通の目的を持ち、取り組む集合体」のように説明されます。

仕事の文脈では、色々な場面で「チーム」が組成されると思います。
しかし、実態は「与えられたタスクをバラバラにこなす、個人ワークがメインで・・」というのも、よくある話ではないでしょうか。
目的やメンバーのレベルによってはそれでも問題なく、むしろ最適な場合もあると思います。でも「チームとして動いた方が良いのにできていない」のであれば勿体ないことです。

このあたりの話は、世の中に多くのノウハウやパターンが出回っています。インセプションデッキもそうだし、スクラムのフレームワークも透明性・検査・適応の実現の過程で「チームで動く」ためのコミュニケーション設計が成されているように感じます。

「じゃあ明日からチームになっていこう！」と思った際に、何から手を付けましょうか？
このセッションでは、私自身がこれまでに参加した「チーム」や、リーダーの立場で実際に行い・フィードバックを得た経験も交えながら、「 そもそも、なぜチームになる事が求められるのか」「グループではなくチームになるために大事にしたこと、やってみてよかったこと」をお伝えしたいと思います。

皆さんは、Composerをご存知ですか？利用していますか？では、その中身を読んで遊んでいるでしょうか？

Composerの世界においての中核的な概念は、「Repository」と「Package」です。
これらを組み合わせると、「何がインストール済みなのか」「composer.lockに指定されているもの、composer.jsonに指定されているものは何か」「このシステムの環境は要件を満たしているだろうか」「packagist.orgだけではなく、GitHubレポジトリやローカルファイル(path)も見に行くぞ！」という複合的な課題にそれぞれ応えることが可能になります。

システム開発は、PHPのソフトウェアも多分にもれず「どういう問題を、どのように抽象化し、組み合わせ、解決するか」という活動です。一見複雑そうに見える・・・という問題を、エレガントに解けるのも「モデリング」の力です。

本セッションでは、Comopserを例にしながら「どういう風に問題を切り取って、どういう風に抽象を定義し、それを具体的な世界に落とし込むか！！」という思考を味わってみようと思います。
世界中で利用されているソフトウェアの「シンプルさ」を感じ取ってもらえたら幸いです。

何らかの理由によって「既存のクラスやAPIの使い方が変更された、それに対応しないといけない！」という場面が、
しばしば開発の現場には発生します。
その時に、なるべく「人間の目と手で作業する」という負担は避けたい・・面倒くさいな・・と思うのが人の心情ではないでしょうか。

https://github.com/rectorphp/rector は、既存のPHPコードのリファクタリングやアップグレードを自動実行するツールです。
こいつを上手く使えれば、あの退屈で機械的な作業を真の意味で「機械の作業」にする夢が叶うかも知れません！！

本セッションでは、Rectorについて紹介し、具体的に活用するための方法を話したいと思います。

おしながき

• Rectorってなに？
• どういう仕組で動いてるの？
• 独自ルールを作ってみる

vimeo/php-mysql-engine は、「MySQLを使わないでMySQLの処理を動くようにしちゃおう！」という野心的な何かです。
コンセプトや利用イメージなどの概要については、日本語であればピクシブ株式会社様のブログエントリーを参考にすることが出来ます。

ピクシブ百科事典のテストにphp-mysql-engineを導入しました - pixiv inside

しかし、とても不思議ですね・・・？
一体どうしたら、こんな処理を実現できるのでしょうか。
気になったので、調べてみました！

本セッションでは実装面からphp-mysql-engineの挙動を読み解いていきたいと思います。

Xdebugを活用していますか？ステップ実行の機能については、利用経験者も多いかと思います。
公式サイトを開き、トップページを見ると「Step Debugging」「Improvements to PHP's error reporting」「Tracing」「Profiling」「Code Coverage Analysis」と主要機能が列挙されています！

本LTでは、「知っているといざという時に便利！！」なTracing・Profilingの機能を紹介します。
Tracingを使いこなせば「この処理どう動いているんだ？？？」を効率的に理解するのに役立ちますし、Profilingを使いこなせば「どこの処理がボトルネックになっているんだ？？？」をパパパっと理解できるようになっちゃいます。

ぜひ、プログラマーの道具箱に入れておきたいですよね！

静的解析、利用していますか！
PHPStanやPhan、あるいはPhpStormのコードインスペクション機能によって、普段から色々な恩恵を受けている人、「もうコレなしではダメなの！！！」なんて人もいるかも知れません。

では、チームで活用できていますか？既存プロダクトに”後から”静的解析を導入したいんだが・・・と、悩んだことはありませんか？
個人的に、静的解析は「入れたら当たり前になるもの」「でも導入までは面倒くさいもの」に思われがち、という印象を持っています。
最初の導入にはいくつか無視できない壁があると思いますが、その1つは「チームメンバーで合意を得る(場合によっては説得を伴う)」ことではないでしょうか？

しっかりと「静的解析、こんな場面で便利！」と説明する必要があります。
それも、抽象的な原則や一般論的な「○○べき」で押し付けるだけでは、モヤモヤが残るだけかも知れません。
欲しいのは「ほら、お前もコレ観たことあるよな？・・・それ静的解析で出来るよ！！！」という魅力です(多分)。
また、その後のフォローとして「こうやったらちっちゃく入れられ始めるよ」というポイントも押さえておきたいものです。

あなたは既に「静的解析を知っている」し、「使ってみたいと思っている」とします。
その上で、「チームメンバーにどうやって良さを伝えたものか・・・」で悩んでいるのです。
私は、そんな人達を応援したい！！！と思いました。

本セッションでは、「静的解析を入れたいけど説明や説得が面倒だぁ・・」という人に向けて、「どうやったら良い感じに巻き込めそうかな？」を考えてみます！

CakePHPというフレームワークがあります。現在のstableは、4.2です。
Packagistのstats を見ると、まだまだ3.xの方が利用数が多いようです。

ですが、4.0->4.1->4.2と堅実に進化を遂げています！
また、4.2の次期バージョンでも「お、遂にそこにメスを入れるんですね？！」という変化も予定されています。
まだまだロードマップも未策定ですが(※2021年7月現在)、どうやら5.xに向けた開発も動き始めているようです。
(「じゃあ姿が見えてきたってことか？」というと微妙なので、それはカンファレンスまでにどのくらい進捗するのか・・・次第です。楽しみですね！！)

このセッションでは、主にCakePHP利用者向けに「最近＆ちょっと先のCakePHP」の話をします。

PHPを業務や趣味で使っていると、「PSR(PHP Standards Recommendations)」という単語を目にする場面があるかもしれません。
こいつは一体なにものなのでしょうか・・？

PSRは、「PHP-FIGが策定し、運用する 何か」です。 また新しい単語が出てきました。PHP-FIGってなにものでしょうか・・？

PHP-FIGやPSRが誕生した背景、そしてこれまでに辿ってきた歴史、そして今現在のPHP-FIG/PSRを取り巻く状況を理解してみることで、「PSRとは何か」を感じられるようになるかも知れません。

本セッションでは、PHP-FIG/PSRの歴史を振り返ります。

みなさんの開発・運用しているシステムでは、障害・・起きていますか！
障害は恐ろしいものです。その一方で逃げられないものでもあります。
逃げられないのであれば、付き合っていきながら打ち克っていくしかありません。

障害を小さくし・防ぎ・減らしましょう。
そのためには、「透明性」を担保し、「検査」と「適応」を繰り返して進化していきたいものです。

では、どうやって取り組んで、どこから変わっていけるものでしょうか？
「(自分たちの根ざす)マインドセットの獲得」と「(自分たちの作る)システムの見える化」、そして「(自分たちの取り組む)プロセスの改善」から始めていきませんか。
スキルやプロダクトについては積み上げていくしかないものであり、一朝一夕では変えられません。
ですが、組織やチームの持つ「ルール」と「やり方」「仕組み」は、「やるぞ！！」という気持ちを持てた瞬間が、変わるときです。

本セッションでは「障害と向き合って、提供するものの品質を整えていくために、チームでやっていきたいこと」を取り上げていきます。