トーク

GraphQLをご存知でしょうか。名前は聞いたことあったり、実際に使用した経験のある方も多いかもしれません。
GraphQLは2015年にFacebookにより開発されたRESTとは異なる新しいAPIフォーマットです。
クエリ言語を用いてデータを操作することで、取得過剰や取得不足と言ったRESTの問題を解決し、本当に必要なリクエストを得られるようになると注目を浴びていました。

しかしながら2020年現在、PHPが得意とする領域においてはまだまだRESTが使用されているアプリケーションの方が多いかと思います。
今回は実際にLaravel + Lighthouseを用いてGraphQLによるWebアプリケーションを開発した際に得られた知見をもとに、なるべく実装コストや学習コストを下げた開発方法や実装する際の注意点、アンチパターンなどをお話しさせていただきます。

PHPでのGraphQL APIの開発はここまでやりやすくなったよ！というのを皆様にお伝えできればと思います。

Track ID: Track4-4-B
Discord Channel: #track4-4-b-laravel-lighthouse

カンファレンス開催の頃には満を持してリリースされているPHP8。より厳密な処理が書きやすくなり、実行速度は速くなり、メタプログラミングに使いやすい機能も増えました。

本トークでは、Webアプリケーション開発を取り巻く環境の変化やPHP8の新機能を考察しながら、PHP8時代にも次々と出てくるであろう新しいWebアプリケーションフレームワーク（以下単にFW）の動向や既存のFWの変化について独断と偏見により予想します。

また、FWの内部の仕組みに触れることで、独自FWの作成に興味を持つ方が増えれば幸いです。

●お話したいこと

• FWの共通部分の仕組み
• PHP8の新機能の軽い紹介とFWへの活用
• FWの"個性"
• デプロイターゲットの多様化
• オレオレFWのすゝめ

●お話しないこと

• 次に流行るFWの具体名の予想

Track ID: Track5-4-B
Discord Channel: #track5-4-b-php8-framework

既存の大規模システム、とくに自動テストがないレガシーシステムにおいては、静的解析のCI導入は改善の足掛かりとして非常に有用です。
しかしながら、既存システムへの静的解析のCI導入は一筋縄ではいきません。
厳しすぎるルールで導入しても、大量のエラーやワーニングでチームが疲弊してしまいますし、
逆にルールがゆるい状態で導入しても、静的解析の良いメリットが得られません。

本セッションでは、静的解析ツールの特徴に合わせて、効率的なCIの導入パターンを紹介します。
具体的には、最低限のルールから自動的にルールを厳しくする方法や、
既存コードにはゆるいルールを適用しつつ、新規ファイル・新規コードには厳しいルールを適用する方法を紹介します。

Track ID: Track2-5-A
Discord Channel: #track2-5-a-static-analysis-ci

PhpStorm を使って Laravel案件の開発をするとき、どのくらいコードを書いてますか？

便利なプラグインを入れ、案件に合った設定を行い、自動生成されるものも活用すると
こんなにも、コード補完でコードが書けちゃうんです。

っていう実演をしようと思います。

Track ID: Track3-5-A
Discord Channel: #track3-5-a-php-storm

As we move more and more to microservices communication between services becomes more important.
Using messaging is an effective way and gives us a lot of freedom & benefits, especially when using Apache Kafka.
This helps services to be very resilient and being able to scale without losing the control and overview.

Track ID: Track6-5-A
Discord Channel: #track6-5-a-service-communication

PHPを書きながらフロントエンドも書いている！という人も多いのではないでしょうか？わたしも最近そんな感じでバックエンドはLaravel、フロントエンドはNuxt.jsを使って開発をしています。

APIはPHPに任せてフロントをNuxt.jsで実装しているとかなり責務が分かれていい感じだなと思っているのですが、その分Nuxt.js側でのCSSの変更などによるデグレが気になるようになりました。そこで最近取り入れているのがAtomicDesignとビジュアルリグレッションテストです。AtomicDesignの採用によりコンポーネント単位で実装するようになるので、そのコンポーネント単位で見た目のテストができ意図しない変更に気付きやすくなります。

このセッションでは、わたしがStorybook、REG-SUIT、CodeBuild、Github Enterpriseを組み合わせて構築したビジュアルリグレッションテスト環境の技術要素や運用状況についてご紹介します。

Track ID: Track2-5-B
Discord Channel: #track2-5-b-visual-regression-test

去る9/19〜9/21にiOSDC Japan 2020という技術カンファレスがオンラインで開催され、60本のトークと20本のLTが実施されました。
実施された60本のトークはすべて事前収録され、それを当日に再生する形でカンファレンスを開催しましたが、60本の動画の編集にかかった日数は3日ほどでした。動画編集に詳しい方であればちょっと驚く期間かと思います。

この高速編集を支えたのはPHPでした。

このトークでは私がどの様にPHPでオンラインカンファレンス向け録画システムを構築したのか、そして、同じ様なシステムを作りたい方のためのサービス連携のコツをお話しします。

• Zoom, YouTube Live, Dropbox を連携させた収録システムの作り方
• GD, ffmpeg を使用したオンラインカンファレンス用動画編集システムの作り方
• PHPでサービス連携するためのコツ

このトークを聞いたみなさんが、PHPで高度なシステム連携アプリを作るきっかけになることを期待しています！

参考:
iOSDC Japan 2020
https://iosdc.jp/2020/
iOSDC Japan 2020 トーク動画
https://www.youtube.com/playlist?list=PLod2oSGQp3W4BV6sLUdMwlZD0NHt9mHP7

Track ID: Track3-5-B
Discord Channel: #track3-5-b-online-conference-system

How to measure the quality of unit tests? Code coverage is not necessarily a good indicator to answer this question. What other options do we have? Do we need tests to test the quality of our tests? In some way, yes we do. In this session, I will introduce you to the concept of mutation-based testing and how this technique can be used to improve the quality of your test suite.

Track ID: Track6-5-B
Discord Channel: #track6-5-b-how-good-are-my-test